Chapter 1 Before You Begin

Microsoft® Exchange 2000 Server represents a significant advance in messaging software. Architectural improvements in Exchange and Microsoft Windows® 2000 make Exchange more flexible and scalable than ever before. You need to learn about these architectural changes and enhancements to understand how they affect your organization. Microsoft Exchange 2000 Server Planning and Installation is the place to begin.

© 2000 Microsoft Corporation. All rights reserved.


About This Book

This book provides planning and installation information for novice and intermediate administrators using Exchange 2000 Server. Administrators and planners responsible for deploying Exchange should read this book from start to finish before deploying Exchange. With the exception of installation procedures in Part 3, the content in this book is conceptual. Often, a concept in one chapter depends on concepts that another chapter describes; therefore, it is a good idea to read the entire book before you install Exchange.

This book assumes you have a basic knowledge of messaging systems. Throughout the book, there are references to earlier versions of Exchange; the book includes these references to help administrators who are familiar with earlier versions of Exchange. If you have not used earlier versions of Exchange, the references may help reinforce your understanding of Exchange concepts.

This book also assumes you have an understanding of the fundamentals of Windows 2000 Server networking, administration, security, and Active Directory™. Before you read this book, you should understand the following Windows 2000 networking concepts: Domain Name System (DNS), sites, and the relationship between the global catalog and Active Directory. This book provides some conceptual information about Windows 2000 when it is necessary to explain or enhance an Exchange concept.

Microsoft Exchange 2000 Server Planning and Installation introduces you to the new features, concepts, terminology, and architecture of Exchange. This is not a how-to book; it provides the background information you need to plan your Exchange organization. For planning information that has become available since this book was printed, visit the Exchange Web site at http://www.microsoft.com/exchange.

Server Edition and Enterprise Edition

There are two versions of Exchange 2000 Server: a Server Edition and an Enterprise Edition. The following table lists features of the two versions.

Feature | Enterprise Edition | Server Edition
Storage | Unlimited | Limited to 16 GB
Multiple database support | Yes | No
Connectivity to other systems | Yes | Yes
X.400 connector | Yes | No
Microsoft Outlook® 2000 | Yes | Yes
Development Kit | Yes | Yes
Instant Messaging | Yes | Yes
Chat Service | Yes | No
Front-end and back-end architecture support | Yes | No
Windows Clustering support | Yes | No
Licensing maintenance | Yes | No

This book covers all features of Exchange. With the exception of this table, the book does not distinguish between the two versions.

Organization

Microsoft Exchange 2000 Planning and Installation consists of the following three parts and appendixes:

Part 1 Introducing Exchange 2000 Server This part provides an overview of the enhancements and new functionality in Exchange 2000 Server.

Part 2 Planning Your Deployment This part contains chapters that provide more detail about new Exchange 2000 Server functionality and how Exchange interacts with Windows 2000. This information includes the main architectural features of Exchange 2000 Server and is a good starting point for further research.

Part 3 Installing Exchange 2000 Server This part provides quick installation instructions, detailed installation instructions, and information about installing Exchange with Windows Clustering.

Part 4 Appendixes The appendixes contain supplementary information including:

  • Lists of languages available for Exchange 2000 Server and related clients

  • Naming convention restrictions

  • Accessibility options available in the product, from Microsoft, or from other sources


Additional Resources

You can use the following resources to help you with your planning and installation process:

Online documentation Exchange online documentation contains processes and procedures you need to perform to maintain Exchange. It also provides detailed configuration information. Exchange 2000 Server Setup automatically installs Exchange online documentation in HTML format. You can open it from the Help menu in System Manager.

Online Help Online Help contains information and instructions on how to administer Exchange. You can access Help from the Help menu in System Manager or by pressing F1.

Exchange 2000 Server Software Development Kit (SDK) Information about developing applications for Exchange 2000 Server is located in the Messaging and Collaboration section of the Microsoft Platform SDK. The Platform SDK is an integral part of Microsoft Developer's Network (MSDN™), which is available in CD format through subscriptions, as part of Microsoft Visual Studio®, and online at http://msdn.microsoft.com. For the latest Exchange development information, including technical articles, samples, tools, and documentation, visit the MSDN Exchange Developer Center at http://msdn.microsoft.com/exchange.

Exchange Web site The Exchange Web site, which is located at http://www.microsoft.com/exchange, is a central source for information about Exchange 2000 Server and earlier versions of Exchange. The Web site provides in-depth product information, tools, and technical materials for administrators who build and manage messaging and collaboration systems. This site includes information about migration, collaboration, deployment and administration, support, resources, news and events, international considerations, business solutions, and third-party solutions. The Web site also contains a copy of this book.

Windows 2000 documentation The following sources provide information about Windows 2000 Server:

  • Windows 2000 online Help

  • Windows 2000 Server Getting Started

  • Windows 2000 Advanced Server Getting Started

  • Windows 2000 Server Resource Kit, available through Microsoft Press®, which contains the following books:
    • Deployment Planning Guide

    • Distributed Systems Guide

    • TCP/IP Core Networking Guide

    • Internetworking Guide

    • Server Operations Guide
  • Microsoft Internet Information Services 5.0 Documentation

  • Microsoft Internet Explorer 5 Resource Kit


Document Conventions

To help you locate and interpret information easily, this book uses the following conventions.

Convention | Description
ALL CAPITALS | Acronyms, abbreviations, and names of certain commands and keys on the keyboard.
Bold | Menus and menu commands, command buttons, tab and dialog box titles and options, command-line commands and options, and portions of syntax that you must type exactly as shown.
Initial Capitals | Names of applications, programs, files, servers, and named windows; and directory names and paths.
Italic | Information you provide, terms that this book introduces, and book titles.
Monospace
 Examples, sample command lines, program code, and program output.


Product Support Services Worldwide

If you are outside the U.S. and have a question about a Microsoft product, first:

  • Check the information in Help or the product manual.

  • Check the Readme files that come with your product disks. These files provide general information that became available shortly before the product was released.

  • Go to Support Online at http://www.microsoft.com/support and click International Support.

If you cannot find a solution, you can receive information on how to obtain product support by contacting the Microsoft subsidiary office in your area.

Contacting a Subsidiary

When you call your local Microsoft subsidiary, you should be at your computer and have the appropriate product documentation available. Be prepared to provide the following information:

  • Product version

  • Type of hardware, including network hardware, if applicable

  • Operating system

  • Exact wording of any messages that appeared on your screen

  • A description of what happened and what you were doing when the problem occurred

  • A description of how you tried to solve the problem

    Important Phone numbers for Microsoft subsidiaries are subject to change. For the most recent listing, visit the support Web site at http://www.microsoft.com/support. If there is no Microsoft subsidiary office in your country or region, contact the establishment from which you obtained your product.

Argentina
Microsoft de Argentina S.A.
Customer Service: (54) (11) 4316-4600
Fax: (54) (11) 4316-1922
Technical Support: (54) (11) 4316-4664

Armenia
See Russia

Austria
Microsoft Ges.m.b.H.
Phone: (43) (1) 610-64-0
Fax: (43) (1) 610-64-200
Standard Support:
Installation and Handling: (43) (1) 50222-2255

Azerbaijan
See Russia

Belgium
Microsoft NV
Phone: (32) (2) 730-39-11
Fax: (32) (2) 726-96-09
Microsoft Support Network Info. Center:
0800-18307
TechNet Subscription: (353) (1) 703-8738
MSDN Subscription: (353) (1) 708-8690
Microsoft Information Center: (32) (2) 481-52-52
Technical Support:
(32) (2) 513-32-74 (Dutch)
(32) (2) 502-34-32 (English)
(32) (2) 513-22-68 (French)
Web: www.microsoft.com/benelux/support

Belarus
See Russia

Bolivia
See Uruguay

Central America
Technical Support: (506) 298-2020
Support E-mail: mscasup@microsoft.com
Customer Service: (506) 298-2000
Customer Service E-mail:
msccatus@microsoft.com

Chile
Microsoft Chile S.A.
Phone: (56) (2) 330-6000
Fax: (56) (2) 330-6190
Customer Service: (56) (2) 800-330600
Personal Operating System and Desktop
Applications:
Phone: (56) (2) 330-6222
Fax: (56) (2) 341-1439

Colombia
Microsoft Colombia
Phone: (57) (1) 618-2245
Fax: (57) (1) 618-2269
Technical Support:
Línea de Respuesta Microsoft
Phone: (57) (1) 523-0022
Fax: (57) (1) 523-1220
Voice Mail: (57) (1) 503-4216

Croatia
Microsoft Hrvatska d.o.o.
Phone: (385) (1) 304-555
Fax: (385) (1) 335-051
Technical Support:
(Contact the subsidiary.)

Czech Republic
Microsoft s.r.o.
Phone (42) (2) 611-97-111
Fax: (42) (2) 611-97-100
Technical Support:
(42) (2) 215-03-222

Denmark
Microsoft Denmark
Phone: (45) 44-89-0100
Fax: (45) 44-68-5510
Technical Support:
Phone: (45) 44-89-0111
Microsoft Sales Support: (45) 44-89-0190
Microsoft FastTips: (45) 44-89-0144
(Document 303030 in FastTips contains detailed instructions)

French Polynesia
See France

Georgia
See Russia

Germany
Microsoft GmbH
Phone: (49) (89) 3176-0
Fax: (49) (89) 3176-1000
Telex: (17) (89) 83 28 MS GMBH D
Information: (49) (89) 3176 1199
Web: www.microsoft.com/germany

Greece
Microsoft Hellas, S.A.
Phone: (30) (1) 6806-775 through
(30) (1) 6806-779
Fax: (30) (1) 6806-780
Technical Support:
Phone: (30) (1) 9247-030
Fax: (30) (1) 9215-363

Hong Kong SAR
Microsoft Hong Kong SAR Limited
Fax: (852) 2560-2217
Product support Faxback Service:
(852) 2535-9293
Microsoft Club Hotline: (852) 2804-4277
Technical Support: (852) 2804-4222

Hungary
Microsoft Hungary
Microsoft Magyarország Kft.
Phone: (36) (1) 437-2800
Fax: (36) (1) 437-2899
Technical Support:
(36) (1) 267-4636

Japan
Microsoft Company Ltd.
Technical Support (Standard Support):
(81) (424) 41-8700
(Technical Support options/ Support Contract)
Phone: 0120-37-0196 (toll free domestic only)
Channel Marketing Information Center:
(Presales Product Support)
Tokyo Phone: (81) (3) 5454-2300
Osaka Phone: (81) (6) 245-6995
Customer Service Phone:
(Version upgrade/Registration)
Phone: (81) (48) 226-5500
Fax: (81) (48) 226-5511

Kazakhstan
See Russia

Kyrgyzstan
See Russia

Korea
Microsoft CH
Phone: (82) (2) 531-4500
Fax: (82) (2) 531-1724
Customer Service: 080-022-7337
(toll free domestic only)
Technical Support:
Office Technical Support:
(82) (2) 508-0040
Windows Technical Support:
(82) (2) 563-0054
Developer Technical Support:
(82) (2) 566-0071
Microsoft FastTips: (82) (2) 3453-7555
Support Sales: (82) (2) 531-4544

Latin America
Microsoft
Latin American Headquarters (U.S.A.)
Phone: (305) 489-4800
Fax: (305) 491-1616
Customer Service: (425) 936-8661
Technical Support: (214) 714-9100
Web: www.microsoft.com/latam/soporte

Netherlands
Microsoft BV
Technical Support:
(31) (20) 500-1005 (Dutch)
(31) (20) 500-1053 (English) Web:
www.microsoft.com/benelux/support

New Zealand
Microsoft New Zealand Ltd
Phone: (64) (9) 357-5800
Fax: (64) (9) 358-3726
Technical Support:
Phone: (64) (9) 357-5575
Fax: (64) (9) 307-0516 and 357-5577

Northern Ireland
See United Kingdom

Norway
Microsoft Norway AS
Phone: (47) (22) 02-25-00
Fax: (47) (22) 95-06-64
Technical Support: Standard:
(47) (22) 02-25-50
Priority: (47) (22) 02-25-45
Premier: (47) (22) 02-25-46
Microsoft Sales Support:
(47) (22) 02-25-80
Microsoft MSDL: (47) (22) 18-22-09
Microsoft FastTips: (47) (22) 02-25-70
(Document 404040 in FastTips contains detailed instructions)

Panama
Technical Support:
(506) 298-2020
Support E-mail: mscasup@microsoft.com
Customer Service: (506) 298-2000
Customer Service E-mail:
msccatus@microsoft.com

Papua New Guinea
See Australia

Romania
Microsoft s.r.l.
Phone: (40) (1) 222-90-16
Fax: (40) (1) 222-90-12
Technical Support: (40) (1) 312-09-48

Russia
Microsoft Z.A.O.
Microsoft Information Center:
(7) (095) 916-7171
Russia: 125252
Moscow: Postbox 70
Technical Support:
Moscow: (7) (095) 745-54-45
St.Petersburg: (7) (812) 118-36-36
Novosibirsk: (7) (3832) 119-019
Web: www.microsoft.com/rus/

Saudi Arabia
Microsoft Saudi Arabia
Phone: (966) (1) 488-1165
Fax: (966) (1) 488-1576
Technical Support:
(Personal Operating System and Desktop Applications only):
Phone: (800) 124-0500 (toll free within Saudi Arabia)
Fax: (966) (1) 474-0576

Scotland
See United Kingdom

Singapore
Microsoft Singapore Pte Ltd
Phone: (65) 337-6088
Fax: (65) 337-6788
Customer Services:
Phone: (65) 324-5255
Fax: (65) 324-6181
Product Support Services:
Phone: (65) 378-3600
Fax: (65) 378-3662

Slovakia
Microsoft Slovakia s.r.o.
Phone (421) (7) 37 63 02
Fax: (421) (7) 37 66 71
Technical Support: (421) (7) 531 20 83

Switzerland
Microsoft AG
Phone: (41) (1) 839-61-11
Fax: (41) (1) 831-08-69
Prices, updates: (41) (1) 839-61-11
Documentation:
Phone: (41) (1) 155-59-00
Web: www.microsoft.com/switzerland

Tajikistan
See Russia

Taiwan
Microsoft Taiwan Corp.
Phone: (886) (2) 504-3122
Fax: (886) (2) 504-3121
Technical Support:
Phone: (886) (2) 508-9501
Fax: (886) (2) 508-9575
Web: www.microsoft.com/taiwan/support

Thailand
Microsoft (Thailand) Limited
Phone: (66) (2) 266-3300
Fax: (66) (2) 266-3310
Product Support:
Phone: (66) (2) 613-7208 through 11
Fax: (66) (2) 613-7198

Turkey
Microsoft Turkey
Phone: (90) (212) 258-59-98
Fax: (90) (212) 258-59-54
Support Hotline:
Phone: (90) (212) 258-96-66
Fax: (90) (212) 258-95-99
Bulletin Board Service:
(90) (212) 227-93-90

Uruguay
Technical Support: (598) (2) 77-4934
Fax: (598) (2) 77-4935

Uzbekistan
See Russia

 Australia
Sales Information Centre:
(61) (2) 9870-2100
Web: www.microsoft.com.au
Technical Support: (61) (2) 9870-2131
Fax: (61) (2) 9805-0519

Brazil
Microsoft Informatica Ltda.
Phone: (55) (11) 5514-7100
Fax: (55) (11) 5514-7106/5514-7107
Technical Support: (55) (11) 5506-8087
Fax: (55) (11) 5506-7621
Automatic Fax: (55) (11) 5506-8506
Technical Support Bulletin Board Service:
(55) (11) 5506-1234
Customer Support: (55) (11) 822-5764
Customer Services Fax:
(55) (11) 822-6227

Canada
Microsoft Canada Co.
Head Office Phone: (905) 568-0434
Customer Information Centre:
(800) 563-9048
Technical Support:
Desktop Systems including Microsoft Windows 95: (905) 568-4494
Microsoft Office and Office Components:
(905) 568-2294
Other Standard Technical Support:
(905) 568-3503
Priority Support Information:
(800) 668-7975
Text Telephone (TTY/TDD) (905) 568-9641
Technical Support Bulletin Board Service:
(905) 507-3022

Caribbean
Microsoft Caribbean, Inc.
Phone: (809) 273-3600
Fax: (809) 273-3636
Technical Support: (408) 953 8086
Support E-mail: mscarsup@microsoft.com
Customer Service: (800) 297 5982 for area codes (787) & (809) only
Customer Service E-mail: msccatus@microsoft.com

Dominican Republic
See Central America

Ecuador
Corporation Microsoft del Ecuador S.A.
Phone:
(593) (2) 460-447, (593) (2) 460-451
Customer Service:
(593) (2) 460-453, (593) (2) 460-458
Technical Support: (593) (2) 463-094

Egypt
Microsoft Egypt
Phone: (20) (2) 594-2445
Fax: (20) (2) 594-2194
Technical Support:
Personal Operating Systems and Desktop Applications only:
Phone: (20) (2) 261-3991
Fax: (20) (2) 403-2718

England
See United Kingdom

Estonia
See Germany
Technical Support: (372) 650-49-99

Finland
Microsoft OY
Phone: (358) (0) 9-525-501
Fax: (358) (0) 9-878-8770
Technical Support:
Phone: (358) (0) 9-525-502-5026
Standard: (358) (0) 9-525-502-500
Priority: (358) (0) 9-525-502-20
Premier: (358) (0) 9-525-502-03
Microsoft MSDL: (358) (0) 9-878-77-99
(Swedish and English):
(358) (0) 9-455-03-66
Microsoft FastTips:
(358) (0) 9-525-502-550
(Swedish and English)

France
Microsoft France
Phone: (33) (1) 69-86-46-46
Fax: (33) (1) 64-46-06-60
Telex: MSPARIS 604322
Technical Support:
Phone: (33) (1) 69-86-10-20
Fax: (33) (1) 69-28-00-28

Iceland
See Denmark

India
Microsoft India
Phone: (91) (80) 559-5733,
(91) (11) 646-0767, (91) (11) 646-0694
Fax: (91) (80) 559-7133,
(91) (11) 647-4714

Indonesia (SP)
Microsoft Indonesia - Jakarta
Technical Support:
Phone: (62) (21) 5704254
Fax: (62) (21) 5208122

Ireland
See United Kingdom

Israel
Microsoft Israel Ltd.
Phone: (972) (3) 613-0833
Fax: (972) (3) 613-0834

Italy
Microsoft SpA
Phone: (39) (2) 7039-21
Fax: (39) (2) 7039-2020
Microsoft Rome Office: (39) (6) 5095-01
Fax: (39) (6) 5095-0600
Microsoft by Fax (Fax-on-demand service):
(39) (2) 70-398-888
Customer Service (New product info, product literature): (39) (2) 70-398-398
Dealer Support (Customer Service for resellers only): (39) (2) 70-398-388
Technical Support: (39) (2) 70-398-398
Microsoft Consulting Service:
(39) (2) 7039-21

Liechtenstein
See Switzerland (German, French, Italian)

Luxembourg
Microsoft NV
Phone: (32) (2) 730-39-11
Microsoft Support Network Info. Center: (31) 800-9977-57
TechNet Subscription: (353) (1) 703-8738
MSDN Subscription: (353) (1) 708-8690
Microsoft Information Center:
(32) (2) 481-52-52
Technical Support:
(32) (2) 513-32-74 (Dutch)
(32) (2) 502-34-32 (English)
(32) (2) 513-22-68 (French)
Web: www.microsoft.com/benelux/support

Malaysia (SP)
Microsoft (Malaysia) Sdn Bhd:
Phone: (60) (3) 793-9595
Fax: (60) (3) 791-6080

México
Microsoft México, S.A. de C.V.
(52) (5) 267-2110 Atencion a Distribuidores
(52) (5) 265-3380 Atencion a Clientes
(52) (5) 265-3399 Soporte Sistemas Operativos y Applicaciones de Escritorio
(52) (5) 267-2190 Soporte de Servidores y Herramientas de Desarrollo
Fast Tips: (52) (5) 261-2199

Morocco
Microsoft Afrique Du Nord
Phone: (212) (2) 47-10-72
Fax: (212) (2) 47-10-86

Paraguay
See Uruguay

People's Republic of China
Microsoft Asia Regional Engineering Center
20th Floor, Metro Tower
No. 30 Tian Yao Qiao Road,
Shanghai, 200030, P.R.C.
Phone: (86) (21) 6469-1188
Fax: (86) (21) 6469-1166
Faxbase: (86) (21) 6469-1188 Ext. 6988
Web: www.microsoft.com/china/support

Peru
Centro de Servicio al Cliente
Central de Soporte: (51) (1) 422-4116
Fax: (51) (1) 221 9052
Central de Informacion (51) (1) 242-5980
Fax: (51) (1) 447-8591

Philippines (SP)
Microsoft Philippines
Phone: (63) (2) 811-0062
Technical Support:
Phone: (63) (2) 892-2295,
(63) (2) 892-2495 and (63) (2) 813-2494
Fax: (63) (2) 813-2493

Poland
Microsoft Sp. z o.o.
Phone: (48) (22) 661-54-00
Fax: (48) (22) 661-54-34
Information Service: (48) (22) 865-99-33
Technical Support: (48) (22) 865-99-66

Portugal
Microsoft Portugal MSFT, Lda.
Phone: (351) (1) 440-9200
Fax: (351) (1) 441-2101
Technical Support:
Standard Support: (351) (1) 440-9280 through (351) (1) 440-9283
Fax: (351) (1) 441-1655

Puerto Rico
Technical Support: (408) 953-8086
Support E-mail: mscarsup@microsoft.com
Customer Service: (800) 297-5982 for area codes 787 & 809 only
Customer Service E-mail:
msccatus@microsoft.com

Slovenia
Microsoft d.o.o.
Phone: (386) (61) 1-800-800
Fax: (386) (61) 1-800-822
Technical Support:
(386) (61) 1-853-449

South Africa
Microsoft South Africa
Phone: (27) (11) 445-0000
Fax: (27) (11) 445-0046
Technical Support:
(Toll free): 0802-11-1104
(27) (11) 445-0000
Fax: (27) (11) 445-0343

South East Africa and Indian Ocean Islands
See South Africa

Spain
Microsoft Iberica SRL
Phone: (34) (1) 807-9999
Fax: (34) (1) 803-8310
Technical Support: (34) (1) 375-4004
Customer Service: (34) (1) 375-4004
From Spain only: 902-187-198
Fax Back telephone: (34) (1) 375-4004

Sweden
Microsoft AB
Phone: (46) (0) 8-752-56-00
Fax: (46) (0) 8-750-51-58
Technical Support:
Standard: (46) (0) 8-752-09-29
Priority: (46) (0) 8-751-09-80
Premier: (46) (0) 8-632-57-01
Sales Support: (46) (0) 8-752-56-30
Microsoft MSDL: (46) (0) 8-750-47-42
Microsoft FastTips: (46) (0) 8-752-29-00
(Document 202020 in FastTips contains detailed instructions)

Turkmenistan
See Russia

United Arab Emirates
Microsoft Middle East
Phone: (971) (4) 513-888
Fax: (971) (4) 527-444
Technical Support:
Personal Operating Systems and Desktop Applications ONLY:
Phone: (971) (4) 524-488
Fax: (971) (4) 524-495
E-mail: mts@emirates.net.ae
Priority Support Information:
(971) (4) 555-752
Customer Service Center:
(Version upgrade / TechNet and MSDN subscription)
Phone: (971) (4) 655-082
Fax: (971) (4) 655-097

United Kingdom
Microsoft Limited
Fax: (44) (870) 60-20-100
Phone: (44) (870) 60-10-100
Microsoft KeyData:
(Bulletin Board Service)
(44) (870) 50-30-200
(up to 28.8Kbaud, n, 8, 1)
Microsoft KeyFax:
(Faxback Information Service)
(44) (870) 50-30-100
Technical Support:
Desktop Applications, Home Products, Desktop Systems and hardware:
(44) (870) 50-10-100
Developer Products: (44) (870) 50-10-200
Business Systems: (44) (870) 50-10-300
Minicom Line (44) (870) 50-30-400
Pre-Sales Information:
Microsoft Connection (44) (345) 00-2000

Venezuela
Corporation MS 90 de Venezuela S.A.
Other information: (58) (2) 265-9922
Fax: (58) (2) 265-0863
Technical Support: (58) (2) 993-6755

Wales
See United Kingdom


Chapter 2 What's New

Microsoft Exchange 2000 Server includes significant architectural and feature-oriented enhancements and changes. This chapter provides an overview of what's new in Exchange 2000 Server. The chapters that follow contain detailed information.

Planning for, installing, configuring, and maintaining Exchange requires a highly trained individual or team to take advantage of the enhancements and integrated functionality that Exchange and Microsoft Windows 2000 offer. You can use this chapter to help you plan an approach to learning about Windows 2000 and Exchange 2000 Server.


Active Directory

Unlike earlier versions of Exchange, Exchange 2000 Server does not include its own directory service. It is integrated with the directory in Windows 2000 called Active Directory.

Centralized administration A separate directory for Exchange is no longer necessary, and administrators can administer Exchange and Windows 2000 Server at the same time.

Scalable design From an administrative perspective, Active Directory is organized by organizational units, domains, trees, and forests. From a topological perspective, subnets and sites that cross administrative boundaries can be defined. The flexibility of this structure allows you to adapt Active Directory for any size organization or any configuration.

Security Security is integrated with Active Directory through logon authentication and permissions for objects in the directory. With a single network logon, administrators can manage the organization of the directory and directory data throughout their network, and authorized users can access resources anywhere on the network.

Permissions Active Directory applies permissions directly to every object. Rather than cycling through Active Directory to check a user’s permissions for an object, the object contains the permissions information.

Advanced search capabilities Users and administrators can search Active Directory to locate network objects, such as users, computers, and printers. When users search Active Directory, they can search on specific attributes of an object, not just the object.


Administration

Exchange 2000 Server includes several enhancements that make Exchange easier for you to administer.

Microsoft Management Console Both Windows 2000 and Exchange are managed through Microsoft Management Console (MMC). MMC is a tool used to create, save, and open collections of administrative tools. These tools contain items such as snap-ins, extension snap-ins, monitor controls, tasks, wizards, and documentation, which administrators use to manage many of the hardware, software, and networking components of your Windows 2000 system.

Flexible administrative model In earlier versions of Exchange, connectivity between Exchange servers defines sites, which determine message routing and the administrative model. With Exchange 2000 Server, connectivity and administration are no longer bound to each other. Instead, physical network topology determines message routing and the needs of their organization determine the administrative model. Administrators can use administrative groups and routing groups to create a flexible administrative model in Exchange. Administrative groups define a collection of Exchange objects that share a common set of permissions. Routing groups define a collection of servers that communicate directly with one another.

Users and mailboxes Administrators use Active Directory in Windows 2000 to create and modify users, mailboxes, security settings, distribution groups, and resources within an organization’s directory. This is done using an MMC snap-in called Active Directory Users and Computers.


Messaging

Exchange 2000 Server uses Simple Mail Transfer Protocol (SMTP) as its primary messaging protocol. The SMTP service is part of Windows 2000 and is installed by default. When Exchange 2000 Server is installed, SMTP becomes a peer of X.400 and is extended with added features, such as advanced queuing, message tracking, and intelligent routing.

SMTP virtual server Each Exchange server can host a number of SMTP virtual servers. Each virtual server has its own configuration information, such as bound IP addresses, port number, and authentication settings.

To communicate with different domains, each requiring its own authentication levels or connection limits, you can customize the parameters on each of your virtual servers to meet the needs of remote domains.

Extensibility With Exchange 2000 Server, programmers can extend Exchange to provide features not already present, or they can customize existing features to meet their needs. When certain events occur, such as sending or receiving a message, custom programs are called. These programs can add a disclaimer to messages, rewrite SMTP addresses, check for specific files attached to messages, and archive messages.

Connecting to other systems Exchange 2000 Server includes the tools necessary to coexist with another messaging system while you are migrating to Exchange.


Internet Connectivity and Web Support

If your Windows 2000 Server infrastructure is configured to communicate with the Internet, you can send and receive e-mail over the Internet as soon as Exchange is installed.

Because SMTP is the default messaging protocol used by Exchange and is native to the Windows 2000 Server operating system, interacting with and connecting to the Internet is less of administrative burden than with earlier versions of Exchange.

Integration with Internet Information Services (IIS) Exchange provides a consistent administration model with Windows 2000 IIS. IIS allows access to the Exchange Information Store through HTTP, Post Office Protocol version 3 (POP3), Internet Message Access Protocol, Version 4rev1 (IMAP4), and Network News Transfer Protocol (NNTP). IIS works with your Exchange messaging system. If you are familiar with setting up a Web server through IIS, this familiar functionality is maintained in Exchange.

HTTP extensions support read/write on the Web Distributed Authoring and Versioning (WebDAV) is an extension to the HTTP 1.1 protocol. It allows a client to perform file-system type operations on a remote server and provides what is needed for simple publishing. You can define a virtual root in the Exchange public folder store and then give users a URL so they can access documents there. This allows the Web to become an extension of your messaging system.

Outlook Web Access Outlook Web Access for Exchange 2000 Server provides users with access to e-mail, personal calendars, group scheduling, contacts, and collaboration applications by using a Web browser. Outlook Web Access is redesigned to provide improved performance and a streamlined user interface that is consistent across multiple platforms. Drag-and-drop functionality, rich-text editing, and new right-click menu options provide an environment similar to the Microsoft Outlook client.

Internet security In addition to the Internet security features that Windows 2000 Server offers, Exchange provides flexibility in how you configure Internet security to defend your messaging system from outside threats from the Internet. For example, anti-relay functionality allows an administrator to configure the virtual servers to prohibit outside entities from using your messaging system to route messages to other places.


Information Store

A number of enhancements have been made to the Information Store technology in Exchange 2000 Server.

Web Storage System The Microsoft Web Storage System is a storage platform that provides a single repository for managing multiple types of unstructured information within one infrastructure. The Web Storage System combines the features and functionality of the file system, the Web, and a collaboration server (such as Exchange) through a single URL addressable location for storing, accessing, and managing information and for building and running applications. The Exchange 2000 Information Store is the foundation of the Web Storage System platform.

Multimedia messages and unified Inbox Exchange provides support for multimedia content types; for example, voice mail, sound bytes, and video clips. This allows users to access multimedia data quickly through file streaming interfaces. Instead of downloading an entire multimedia message to the client computer before the message is accessible to the user, Exchange 2000 Server allows the user to begin listening or watching the message immediately, while the rest of the message continues to load in the background.

With multimedia support enabled in Outlook 2000 and Outlook Web Access with Microsoft Internet Explorer 5.0, users can click a button to add video and audio content to their messages.

Multiple databases per server In earlier versions of Exchange, administrators can configure only one public database and one private database for each installation of Exchange. With Exchange 2000 Server, administrators can configure multiple databases for each server. Multiple databases per server can significantly reduce backup and restore time for each database, reduce system down time, and increase server reliability because you can recover individual databases while leaving others online.

Integrated full-text search Integrated full-text search is a new feature that provides a significant increase in search performance. When full-text indexing is enabled, searches take less time to complete in Outlook or any application that uses the Search API in the message body and message subject. In addition, full-text indexing makes message attachments such as Microsoft Word and Microsoft PowerPoint® files searchable.


Real-Time Communication

Exchange 2000 Server meets the demand for real-time collaboration services by offering two different yet complementary real-time collaboration services.

Instant Messaging Users can have private, one-to-one conversations and subscribe to each other’s presence information, which indicates a person’s online status. You use Instant Messaging the same way you now use the telephone, with the added advantage of knowing beforehand whether the person you want to contact is available.

In addition, applications such as workflow engines can use the presence database so that intelligent routing decisions can be made.

Chat Service Users can join live chat rooms or channels. An Exchange server can host several chat communities, each serving a different business organization or public interest. Chat communities are of particular benefit to ISPs that want to offer full-featured and secure chat services to subscribers.


Custom Solution Development

You can customize templates provided with Exchange and write your own solutions using Collaboration Data Objects (CDO), ActiveX® Data Objects (ADO), OLE DB, and other APIs. You can even add event sinks that customize how Exchange processes messages and documents. Exchange is particularly useful in creating Web-based solutions.

You can develop custom solutions using scripting languages such as VB Script and JavaScript, and object-oriented languages such as Microsoft Visual Basic® and Microsoft Visual C++®.

The following are some of the enhancements made to custom solution development capabilities in Exchange 2000 Server:

  • If you have existing solutions developed for Exchange 5.5 using CDO version 1.2.1 or Outlook Web Access, you can use these solutions without modifying them.

  • In the Information Store, customizable events include documents and messages being added to folders, and messages being sent. You can register event sinks to customize the way the Information Store handles these events.

  • In Outlook Web Access, you can create custom forms that the browser displays instead of the default Outlook Web Access forms, or you can create custom Active Server Pages (ASP) solutions.

  • The SMTP and NNTP transports in Exchange allow you to create custom event sinks. These event sinks can modify any of the SMTP and NNTP protocol events, such as establishing a connection and posting a message.


Windows Clustering

Exchange 2000 Server makes it easy for you to cluster multiple Exchange servers. Using Cluster service, Exchange provides up to 4-way active/active clustering, enabling all of the computers in a cluster to actively process messaging requests until a failure occurs and triggers rollover recovery. The ability to use all servers at all times reduces system costs while increasing reliability because dedicated failover-only servers are not needed.


International Support

Server and client applications are available in many languages to address user and administrator requirements for working in multi-lingual environments. For a complete list of supported languages, see Appendix A, “Exchange Language Support.”

Multi-lingual administration Exchange 2000 Server supports multi-lingual administration. You can choose from among six languages to administer Windows 2000, MMC, and Exchange.

Multi-lingual clients Clients of many different languages can connect to a single server, regardless of the server language. This applies to Outlook 2000, Outlook Web Access, and the Instant Messaging client.

Localized address book Exchange 2000 Server installs all the Outlook language templates by default so clients can view mailbox properties their own language. It is not necessary to install the Address Book templates from the Outlook client compact disc.

Browser access Clients can connect to Outlook Web Access from any supported browser anywhere in the world and view the user interface in 22 languages. Users no longer need to install a client.


Chapter 3 Deployment and Administration Roles

When planning your Microsoft Exchange 2000 Server deployment and its ongoing administration, a discussion of roles can help you to organize and focus on the tasks that you need to accomplish. In this chapter, roles refer to the responsibilities of each of your team members during the Exchange deployment process and for continuing administration after the deployment process is complete. Evaluate the roles in your organization in relation to the network topology and administrative model you choose for your Exchange organization.

Often, business requirements for messaging and collaboration determine the network and server design you need to deliver the necessary features and satisfy anticipated demand; however, if your organization spans multiple physical locations or requires divisions within the Exchange system for business reasons, your Exchange organization may require complex designs and more extensive deployment resources.

Even though later chapters describe the Exchange features and technology in depth, this chapter mentions features as it introduces considerations for creating your deployment and administration teams.


Working with Windows 2000 Teams

Unlike earlier versions of Exchange, you do not administer Exchange 2000 Server independently of the operating system. Because Windows 2000 and Exchange 2000 Server both use Active Directory, new deployment and administrative issues exist.

Consider how the following capabilities affect the way you organize your deployment and administration roles:

  • You can create one master plan for installing or upgrading to Windows 2000 Server and Exchange 2000 Server. Ideally, your organization has one combined team or two deployment teams that share members. Extensive communication and cooperation between teams is necessary if your organization has a separate team for each platform.

  • One administrator can perform tasks for both Windows 2000 Server and Exchange 2000 Server.

  • You can organize and administer users based on security considerations, permissions, location, domains, forest, or other requirements. Exchange 2000 architecture provides this flexibility.

  • You may be able to simplify your administrative model by consolidating multiple existing domains into fewer Windows 2000 Server domains.

  • You can combine resources for administering Windows 2000 Server and Exchange 2000 Server or you can manage these resources separately.

Once again, integrating Windows 2000 Server with Exchange 2000 Server is a factor not only in decisions about your network topology, but also in your decisions about deployment and continuing administration. Later chapters in this book introduce concepts that expand on and clarify these issues, so that you can make the best choices for your organization.


Deployment Roles

Microsoft Consulting Services recommends basic roles and responsibilities for information technology professionals working in organizations that are deploying Exchange. The first step is to establish a deployment team that designs the system and architecture, makes the bandwidth and network decisions, and secures the resources to implement the deployment plan. When the deployment team completes its work, an administration team assumes responsibility for daily tasks to keep the system running smoothly and to monitor the system for problems.

This table represents the roles that should be present within your team. Depending on your organization’s needs, a single individual may perform several roles or you can delegate a single role to a specialized team. You can also use this table as a planning tool for administering your organization once you complete your deployment.

Role | Responsibility
Product Manager | Sets objectives, sets the budget, and manages external relationships.
Program Manager | Maintains overall responsibility for Exchange network design and implementation and specifies functional requirements for the Exchange messaging system.
Exchange Engineering | Determines specific configuration of all Exchange components.
Testing and Quality Assurance | Ensures that the Exchange messaging system conforms to functional requirements and corporate standards.
Operations Development | Develops procedures, policies, and programs that monitor and control the Exchange network.
Technical Consulting (third-level technical support) | Provides consulting services and problem resolution for internal business units.
Training Development | Develops training materials and documentation for users and technical support personnel.
Deployment Planning | Determines the most efficient way to deploy Windows 2000 Server and Exchange 2000 Server, promotes efficient implementation, and minimizes deployment costs.
Migration Planning | Determines the tasks necessary to migrate the existing messaging system to Exchange. (This may include porting mail-enabled applications and translating existing user data.)
Implementation Management | Manages the implementation of Exchange and associated components.
End-User Technical Support | Provides users with technical support for Exchange–related problems and questions.
Messaging Transport Operations | Maintains, operates, monitors, and repairs the Exchange environment after installation.
Marketing and Customer Relations | Acts as a client advocate in design meetings and develops and implements the Exchange deployment marketing program, which includes product demonstrations, newsletters, and pilot site coordination.
Financial Control | Monitors financial aspects of the project and tracks expenses against budget allocations.


Administration Roles

After deployment, the administration team manages and maintains Exchange as requirements change and the system grows to meet your organization’s needs. Again, depending on the size of your organization, the administration team may consist of one or two individuals or a series of interdependent groups.

User Management

Identify who performs administrative tasks, such as user account management and daily operation of Exchange. Because Exchange 2000 Server and Windows 2000 use Active Directory, some of these tasks are an extension of Windows 2000 administration. If one person manages all Windows 2000 users, consider having this person also manage Exchange recipients, because these tasks are closely related.

Identify people performing administrative tasks for different groups of users or servers. You might consider using multiple administrative groups to make it easier to assign permissions to a set of Exchange objects for special circumstances. For more information about administering users and servers, see Chapter 5, “Active Directory,” and Chapter 6, “Administration.”

Administration and Routing

Identify who manages administration and routing in your Exchange system. When you first install Exchange 2000 Server, it runs in mixed mode, which allows servers running earlier versions of Exchange to coexist within the Exchange organization. Exchange organizations that no longer coexist with earlier versions of Exchange can run in native mode. The administrative model for organizations in native mode separates routing and administration: you can organize servers in administrative groups to manage permissions and apply system policies, and you can assign servers to routing groups that span administrative groups to most efficiently manage message traffic. For more information about administrative groups and routing groups, see Chapter 6, “Administration.”

Data Management

Identify who manages mailbox stores and public folder stores. Depending on how you organize your system, you may have multiple public folder hierarchies that are divided according to regions or divisions within your organization. You can use permissions to define who administers each public folder hierarchy in your organization. Backup and restore accountability may rest with Exchange administrators or with another group. For more information about managing information and backing up, see Chapter 7, “Information Store,” and Chapter 14, “Backup and Restore.”

Real-Time Collaboration

If you plan moderate to extensive use of Chat, Instant Messaging, or Unified Messaging components, assign a network topology specialist to evaluate and monitor bandwidth considerations. These components affect network resources. For more detailed information about topology planning, see Chapter 11, “Instant Messaging and Presence Monitoring” and Chapter 12, “Chat Service.”


Chapter 4 Clients and Internet Protocols

When you are planning an installation of Microsoft Exchange 2000 Server for your organization, deciding which clients and protocols you will use to access the server is among your first considerations. On one hand, the protocols you can use over your network may already be determined. In this case, you can choose compatible clients that best deliver the features you want. On the other hand, business requirements for certain features may require you to choose clients that provide the functionality you need.

This chapter provides an overview of the clients, protocols, and authentication methods that Exchange 2000 Server supports. This chapter also describes virtual servers, which you can use to make protocols available and manage messaging services. Depending on the scale of your deployment, you may also use front-end and back-end architecture to maintain a consistent namespace and for load balancing several servers.


Clients

E-mail clients that are compliant with Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol version 4 (IMAP4) can access messages in the Information Store. Microsoft Outlook 2000 is optimized for Exchange, but you can use a number of other clients that offer varying degrees of functionality. Keep in mind that clients vary not only by the functionality they offer, but also by the kind of users they serve. While Outlook is best suited for a desktop environment, other clients are designed for roaming or remote users, such as a traveling sales force. In other scenarios, users may have older computers with limited memory or processing power, or they may not need a collaborative client. These considerations are just as important as the features a client provides.

The following sections describe recommended clients for Exchange 2000 Server. Resource requirements and supported features vary, and in some cases so do the protocols that the clients support. Later sections in this chapter describe Internet protocols in detail.

Outlook 2000

Outlook 2000 is the premier messaging client for Exchange, providing the most complete client support. In addition, Outlook uses MAPI, which includes support for native Internet features such as HTML e-mail and iCalendar.

Outlook offers Lightweight Directory Access Protocol (LDAP) compatibility, server synchronization, and offline support. You should use Outlook 2000 in Corporate/Workgroup mode (also known as MAPI mode) to take advantage of all of the scheduling and collaboration features Exchange offers. Outlook 2000 can also operate in Internet mode, but this mode provides only e-mail functionality and limited group scheduling.

Outlook 2000 integrates Microsoft Office applications with e-mail, personal organization, and workgroup software. It provides support for collaboration applications so that you can develop and deploy workgroup applications based on Microsoft Office. Exchange 2000 Server also supports Outlook 97 and Outlook 98, but Outlook 2000 provides a more extensive set of features. Only Outlook 2000, for example, supports multimedia messaging.

Outlook supports these Internet protocols: Network News Transfer Protocol (NNTP), POP3, IMAP4, SMTP, LDAP, and HTTP.

Outlook Express

Outlook Express is available with Microsoft Internet Explorer versions 4.0 and 5.0. Like Internet Explorer, Outlook Express is free, easy to use, and has lower hardware requirements than Outlook. Outlook Express allows users the freedom to send and receive e-mail from anywhere that is convenient, making it well suited for home use and for occasional e-mail users. Keep in mind that Outlook Express does not offer the full range of collaborative and scheduling features that Outlook 2000 does. Outlook Express supports e-mail in Secure/Multipurpose Internet Mail Extension (S/MIME) and HTML format.

Other Internet protocols that Outlook Express supports are POP3, IMAP4, SMTP, NNTP, and LDAP.

Outlook Web Access

Outlook Web Access provides access to e-mail, a personal calendar, group scheduling, contacts, and collaboration applications using a Web browser. Outlook Web Access is a cross-platform solution, which users can access at their own computers or from other workstations that have limited capabilities.

Outlook Web Access in Exchange 2000 Server provides a user interface consistent with Outlook 2000 and faster performance than earlier versions of Outlook Web Access. For more information about Outlook Web Access functionality and compatible browsers, see Chapter 10, “Outlook Web Access.”

Instant Messaging Clients

Instant Messaging users need computers with an Intel Pentium or Pentium-compatible processor. No version of the Instant Messaging client is currently available for Digital Alpha computers. Instant Messaging users must use computers running Windows 95 or later, Windows NT® 4.0 Server or later, or Windows NT 4.0 Workstation.

Users who want to send and receive instant messages need the following software:

  • Internet Explorer version 5.0, which you can download from http://www.microsoft.com/

  • Microsoft Winsock 2.0 (if users use Instant Messaging outside your Exchange organization)

    Note Winsock 2.0 must be installed on computers running Windows 95. Install the Windows Socket 2 Update from http://www.microsoft.com/windows95.

  • The Exchange Instant Messaging client, which is available in the \Instmsg\I386\Client directory on the Exchange 2000 Server compact disc

After you install Instant Messaging Service, notify your users when the service is available and tell them how to get the software they need.

Chat Clients

Chat Service is fully compatible with many chat clients, including:

  • PIRCH, mIRC, and other clients that use the Internet Relay Chat (IRC) protocol.

  • Microsoft Chat (also known as Comic Chat) version 2.1 and later, which uses Extended IRC (IRCX), Microsoft's proposed extensions to the standard IRC protocol. For more information about IRCX, see the Internet draft “Extensions to the Internet Relay Chat Protocol (IRCX).”

You must make chat client software available to users and provide instructions for logging on to the service. If you are hosting more than one chat community, give users the TCP port number of each community.

Considerations for Multimedia Content

When you choose clients, consider how your organization uses multimedia content in messaging. Exchange 2000 Server supports multimedia content. Outlook 2000 and Outlook Web Access (with Internet Explorer 5.0 or later) are the best clients for using multimedia with Exchange. Other clients can also use multimedia in conjunction with third-party applications.

Exchange uses streaming to transfer multimedia content to clients with minimum impact on network performance. Exchange uses Voice Profile for Internet Mail (VPIM) to transfer voice data between Exchange servers and the Internet. This section briefly discusses streaming and VPIM to provide you with background information for client considerations related to multimedia messaging.

Streaming Content

Exchange uses HTTP and streaming to allow users to preview multimedia content embedded in messages. Exchange sends the first few seconds of audio or video to the client, and the remaining content follows in pieces just large enough to provide uninterrupted playback; for example, streaming allows a user to play the first 10 seconds of a 20 MB multimedia presentation. The user can then decide whether to continue listening to the presentation or stop playback. Stopping the playback halts the streaming and the resulting usage of network bandwidth. Without streaming, users must download the entire message to the client before reviewing any content.

VPIM Messages

VPIM is a message format that allows voice-messaging systems to transmit voice and fax messages within a corporate intranet or across the Internet. Exchange accepts messages in VPIM format and stores them in the Exchange multimedia message format. Before messages are sent to an external voice mail system, Exchange converts the message back to VPIM. This VPIM interoperability allows Exchange users to forward all their voice mail to their Exchange mailboxes. Thus, users can check any kind of messages using a computer, but only their voice mail messages using a telephone. With third-party software, users can check all messages using a telephone for true unified messaging.


Internet Protocols

An Internet protocol is a set of standards designed to enable different types of computers to communicate with one another and to exchange information over the Internet. This section briefly describes the protocols Exchange supports and set-up considerations for implementing them. A later section describes the authentication methods you can choose for each protocol to ensure that only authorized users can access your servers over the Internet.

Supported Protocols

Exchange supports the following protocols:

  • SMTP

  • NNTP

  • HTTP

  • POP3

  • IMAP4

Each of these protocols communicates through Internet Information Services (IIS), a Windows 2000 component that Exchange uses. Clients use POP3 and IMAP4 protocols to retrieve mail from a server. Exchange 2000 supports these protocols because they are very common and many organizations use them.

You can configure independent instances of each protocol by creating virtual servers. A virtual server is a collection of services that appears as a physical server to clients. A virtual server typically includes all of the resources necessary to run a particular application, including a Network Name resource and an IP Address resource.

Note Although all Internet protocols are enabled for all users and virtual servers by default, you can restrict the use of one or more protocols for a specific user or virtual server.

The Internet protocols in Exchange 2000 Server support several authentication types in addition to Transport Layer Security (TLS) for transmission encryption. For details, see “Authentication” later in the chapter.

SMTP

SMTP serves two functions in Exchange 2000 Server. It is the native protocol for mail submission and it is the native transport protocol. This means that clients use SMTP to submit messages and servers use it to route messages and exchange replication information and other data. Exchange 2000 Server uses remote procedure call (RPC) to communicate with earlier versions of Exchange.

Clients submitting messages must establish an SMTP connection on TCP port 25, which is the standard SMTP port. The client sends a series of commands to the server and the server replies to each command. Typical SMTP commands notify the server of the sender's domain and host name, the sender's e-mail address, and the identity of one or more recipients of the message. It is possible for the server to reject a message based on the information these commands contain.

SMTP, which is based on specifications in Request for Comments (RFC) 821 and 822, is installed by default as an Internet Information Services (IIS) transport stack when you install Windows 2000 Server. When you install Exchange, it adds elements to the SMTP service, such as a routing engine and increased message queuing functionality. Windows 2000 includes a basic message categorizing utility, which is deactivated by default. Exchange activates and extends this utility and it becomes part of the queuing engine, providing advanced address resolution, among other things. After installing Exchange, you set remote domain settings on the SMTP connector rather than on the IIS virtual server. These enhancements give you greater control over your messaging system at every transport stage.

Message Queues

Exchange enhances SMTP by allowing you to view each virtual server’s queues. In System Manager, you can display a tree view of every queue the virtual server has on other servers. In addition to viewing the number of messages and other properties for each queue, you can perform actions such as freezing all messages or deleting messages with or without sending a non-delivery report (NDR).

SMTP Setup Consideration

If you are currently using SMTP on a computer running Windows 2000 Server for mail relay services or for Web site e-mail using an application such as CDONTS, for example, you must record your SMTP configurations prior to installing Exchange. When you install Exchange, the SMTP service reverts to the default SMTP settings.

NNTP

Microsoft NNTP Service, which is part of the Windows 2000 operating system, supports Internet standard NNTP. Exchange extends the NNTP capabilities of IIS, allowing your Exchange server to host news feeds in public folders.

Note Internet protocols that can access public folders can also access newsgroups hosted in the default public folder hierarchy in Exchange 2000 Server.

NNTP enables users running third-party applications that support NNTP to read and post items, such as messages and documents, to USENET newsgroups. Other USENET users around the world can read and respond to the items. To distribute the processing load in your organization, you can use a master server and subordinate server configuration. In this configuration, a master server receives the news feed and propagates the information to a number of subordinate servers throughout the organization.

There are push news feeds, in which USENET servers regularly send articles to your organization’s NNTP virtual servers, and there are pull news feeds, in which you configure your NNTP virtual servers to contact USENET servers for new articles. For more information about creating and maintaining news feeds, see the Exchange online documentation.

Public Folders

You can use public folders to organize newsgroups and articles. Although you can use the file system to store news articles, public folders provide a convenient hierarchy that make reading, moving, and posting articles easier for your users.

Note When you maintain newsgroups in public folders, administration for some NNTP properties, such as Expiration Policy, is transferred from the NNTP virtual server to the public folder store.

NNTP Setup Considerations

Newsgroups require a large amount of storage space; therefore, the Exchange server running the NNTP service should be able to support the number of users you expect to use the newsgroup public folders. Also, a USENET news feed can send hundreds of gigabytes of data across your network. Make sure that your Internet connection has the bandwidth to support a news feed without disrupting other network traffic, such as e-mail.

For best performance, use multiple drives for news storage. This prevents bottlenecks when the server is processing large amounts of data. Most organizations reserve three drives for hash tables and at least eight drives for transaction log storage.

Public folder replication is another issue you need to consider. The directory and public folder store replicate changes on a schedule. Whenever you create a new public folder on a server, the resulting change in the public folder hierarchy replicates to all other servers in the organization. If your network topology includes remote routing groups that are connected over low-bandwidth connections, make sure that replication does not saturate the connections when you set up a news feed. If the news feed includes a large number of newsgroups, you may need to phase in the new folder over several days to prevent a flood of replication messages from saturating your network.

With multiple storage groups in Exchange 2000, you can create a news feed on a public folder store and place it in a different storage group than the one containing your users’ mailboxes. Thus, you can enable circular logging for the news feed to save disk space without compromising the reliability of other storage groups.

Note Only the default public folder hierarchy is MAPI-enabled. Creating a news feed in a separate storage group requires users to use non-MAPI clients to read articles.

For more information about storage groups, public folders, and circular logging, see Chapter 7, “Information Store.”

HTTP

Exchange 2000 Server has native support for HTTP 1.1, an Internet standard (RFC 2616) that provides access for Web browsers and other services. Exchange also supports an extension to HTTP 1.1 called Distributed Authoring and Versioning (WebDAV). WebDAV, which is also an Internet standard (RFC 2518), allows clients to perform file-system operations on a remote server and provides the capability for simple publishing. WebDAV transmits data in Extensible Markup Language (XML) format. Using WebDAV, developers can create custom workflow and collaboration applications.

HTTP allows users to access the Information Store and use Exchange as a central repository for e-mail and Microsoft Office documents. With Office 2000 applications, users can open and save documents in the Information Store. The Office 2000 Web Folders feature provides a solution for shared document access and collaborative authoring on your intranet or over the Internet.

Note Web Folders in Office 2000 become My Network Places after you install Windows 2000.

With HTTP support in the Information Store, all items can have a URL address, including a user's inbox, calendar, or even an individual message. This also makes remote mailbox access and manipulation possible for Outlook Web Access or any Internet client.

You can allow Internet client access to part of a public folder hierarchy by pointing to the virtual root defined for the HTTP virtual server. A virtual root is a directory that a user sees when connected to an Internet server. For more information about HTTP, see “Virtual Servers” later in this chapter.

POP3 and IMAP4

Exchange supports any client compliant with POP3 or IMAP4. POP3, a simple protocol designed primarily for offline use, allows users to read their messages from the server. A user connects to a server and downloads all of his or her e-mail from an inbox to the client. It is possible for a POP3 client to leave e-mail in the server inbox, but users cannot access other folders on the server. When a POP3 client sends a message, SMTP routes messages to the computer running Exchange or to other SMTP hosts, depending on the recipient's address.

IMAP4 works like POP3, but with a few enhancements. It is well suited for environments in which downloading all of a user’s mail to a specific computer is impractical. The protocol enables clients to access and manipulate messages stored within mailboxes. Unlike POP3, IMAP4 allows a user to access public folders or multiple e-mail folders, search through a mailbox, and maintain read and unread message flags. In addition, a user can download an entire message or a portion of a message, such as an attachment. IMAP4 clients use SMTP to send outbound messages from Exchange.

Authentication

Authentication is the process by which users who claim to have accounts on your system are verified. Organizations commonly implement this security method for remote users who connect to the system over the Internet. You can set authentication methods on virtual servers for each instance of a protocol running on an Exchange server.

Anonymous

You can configure Exchange to support anonymous access for all Internet protocols except POP3. With anonymous access, Exchange does not prompt users for a password or other credentials. Anonymous authentication allows non-validated users to access data stored in Exchange; for example, if you want to make certain public folders available to IMAP4 users outside your organization, you can enable anonymous authentication at the public folder level. Users connecting to Exchange anonymously use the Windows 2000 account IUSR_computer name, in which computer name is the name of the Exchange server they are connecting to. By controlling permissions on that account, you can control permissions for anonymous users.

Basic

Basic authentication requires that the user submit a user name and password. This transaction is completed in clear (unencrypted) text, so it’s not very secure. Nonetheless, Basic authentication is the most widely used authentication method.

Basic with SSL

If you use Basic authentication, Microsoft recommends you use Secure Sockets Layer (SSL) encryption, an industry-standard protocol that provides privacy between a client and a server over the Web. When someone wants to access your system over the Internet, the session begins with a handshake phase, in which an encryption algorithm and session keys are negotiated. Before data is transmitted, the data is encrypted using the session keys.

Note SSL encryption is not available for every Internet protocol that Exchange and IIS support. The SMTP protocol, for example, uses TLS to encrypt session data in a manner that is similar to SSL encryption.

Note that using SSL encryption or any transport-layer security substantially increases the processing load on your Exchange servers.

NTLM Protocol

NTLM protocol is the default method for network authentication in Windows NT 4.0. Windows 2000 supports NTLM protocol for compatibility with earlier clients and servers. This method uses Windows NT 4.0 and Windows 2000 credentials along with an encrypted password for authentication. You activate NTLM protocol when you select Integrated Windows authentication for the virtual server. In a native Windows 2000 environment, however, the same setting activates Kerberos V5 protocol instead.

Note For NTLM protocol to work, clients connecting over the Internet must use Outlook Express or Internet Explorer version 3.0 or later.

Computers running Windows 3.11, Windows 95, Windows 98, or Windows NT 4.0 use NTLM protocol for network authentication in domains running Windows 2000. Computers running Windows 2000 use NTLM protocol when authenticating servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

Kerberos V5 Protocol

Kerberos V5 protocol is more flexible and secure than NTLM protocol. The implementation of the protocol in Windows 2000 is based on standards recommended to the Internet Engineering Task Force (IETF). Therefore, this implementation lays the foundation for very secure interoperability with other networks using Kerberos V5 authentication.

The advantages of Kerberos V5 protocol over NTLM protocol include:

Mutual authentication Servers verify the identity of clients as they do with NTLM protocol, but in addition, clients verify the identity of servers.

Faster connections Servers don’t have to contact the domain controller to verify each client. They can use the credentials the client presents.

Delegated authentication Kerberos V5 protocol has a mechanism that allows a service to impersonate its client when connecting to other services. In a front-end and back-end server configuration, for example, a client can use Kerberos V5 protocol to authenticate with the front-end server, which then relays that authentication information to access data on the back-end server. This is not possible with NTLM protocol.

Note To get a Kerberos V5 service ticket for authentication with a server, a client must first contact the Key Distribution Center (KDC) for the domain of that server (usually the domain controller). Because the client must contact the KDC directly, Kerberos V5 protocol is better suited for intranets than for the Internet. An exception is a client using point-to-point tunneling protocol (PPTP) to connect to a virtual private network (VPN).

Digest authentication

Digest authentication is available for HTTP in IIS. Digest authentication is similar to Basic authentication, except it sends a hash value over the network instead of a password. For more information on Digest authentication, see the Windows 2000 documentation.


Virtual Servers

You configure the protocols Exchange supports primarily through virtual servers. An HTTP virtual server, for example, is an instance of the HTTP protocol running on an Exchange server. Each protocol can have more than one virtual server running on a single computer. By default, Exchange configures one virtual server for each protocol. You cannot delete a default virtual server for any protocol unless you first create a new virtual server to take its place.

Important The default HTTP virtual server, Exchange Virtual Server, also appears under Default Web Site in IIS. You must administer the settings for this virtual server (for example, set folder paths and permissions) in IIS. When you create additional HTTP virtual servers in Exchange, you can create virtual roots that expose mailboxes. Creating additional HTTP virtual servers through IIS, however, exposes only public folders.

Each virtual server must be uniquely identified by a combination of its IP address and TCP port (the default TCP port varies for each protocol). Virtual servers can use the same TCP port provided they do not also share an IP address, or they can share an IP address provided they do not use the same TCP port. HTTP virtual servers have a third unique identifying characteristic, host name.

Multiple virtual servers do not necessarily increase message throughput; however, you may want more than one virtual server for each protocol in certain situations. For example, if you’re hosting an organization that has different SMTP domain names, additional virtual servers allows you to have additional default domains. Virtual servers append the default domain onto incomplete addresses (a message to user is stamped user@defaultdomain.tld). NDR notices likewise display the correct domain name. There are a number of settings for each virtual server, so having more than one virtual server allows you to vary settings for different groups or servers.

Virtual server settings vary depending on the protocol, but they all include parameters such as access controls, IP addresses, TCP ports, and connection settings. Other options are protocol-specific, such as newsgroup settings on NNTP virtual servers.


Front-End and Back-End Servers

In Exchange, IIS manages the Internet protocols. If your organization requires multiple servers in one location, consider using a series of protocol servers to handle the incoming client connections and another series of servers dedicated to mailbox stores and public folder stores. This front-end and back-end architecture makes it possible for IIS to manage the Internet protocols on servers separate from the ones on which the data reside.

A front-end server sends requests from a client to a back-end server. The front-end server first performs a lookup in Active Directory to determine which back-end server receives the request, and then relays the request to the appropriate server. All front-end servers appear as one computer to Internet clients. When a client sends a request, the first available front-end server responds and sends the request to the correct back end server. You can configure front-end servers to handle client authentication.

Front-end and back-end architecture creates a consistent namespace. Users do not need to remember which servers their mailboxes are on, and you do not need to notify users when moving users’ mailboxes.

Note MAPI clients don't use front-end and back-end architecture because MAPI provides a similar consistent namespace.

In front-end and back-end architecture, all front-end servers can respond to the same URL. You can accomplish this with round-robin Domain Name System (DNS), Network Load Balancing (part of the Windows 2000 operating system), or a hardware solution.

Note Microsoft recommends Network Load Balancing. If a server with Network Load Balancing fails, remaining servers seamlessly take over that server's load. In contrast, if a front-end server using round-robin DNS fails, clients continue to send requests to the inoperable front-end server.


Chapter 5 Active Directory

Active Directory in Microsoft Windows 2000 is a significant enhancement over the directory services provided in earlier versions of Windows NT. You can use it to manage your network from one location, allowing you to add, remove, and relocate users and resources easily. Active Directory is also the most significant change in Microsoft Exchange 2000 Server because it replaces the Exchange directory service.

You can use Active Directory to design a directory structure tailored to your organization’s administrative needs. Active Directory can include every object, server, and domain in a single WAN or several WANs. You can scale Active Directory from a single computer to a network, or to many networks.

Before installing Active Directory, you should examine your organization’s business structure and operations. You will use this information to create a plan for deploying Active Directory and Exchange 2000 Server. You will have decisions to make that are based on whether your company’s network administration structure is centralized, decentralized, or a combination of both.

This chapter describes the basics of Active Directory, how it is integrated with Exchange, and what is involved in coexisting with earlier versions of Exchange. This information will help you identify the issues you need to consider when planning your Active Directory deployment.


Active Directory Components

Some concepts and terms that describe Active Directory are new, while others may seem familiar. Some of the familiar terms may have more than one meaning. It is important for you to understand these concepts and terms within the context of Active Directory, even if they seem familiar.

Active Directory separates the logical structure of the domain hierarchy from the physical structure of the network. Active Directory is based on these concepts.

Logical Structure

In Active Directory, you organize resources in a logical structure; for example, you organize domains for administrative purposes. This logical structure enables you to define and group resources so you can locate them by name instead of by physical location. In earlier versions of Exchange, for convenience of administration, resources were organized by sites and servers. The same basic concept applies to Exchange 2000 Server, except that more options are available to you for organizing your resources, and the organization you set up is integrated with the organization of the operating system instead of existing in two separate structures. Windows 2000 includes objects, organizational units, domains, trees, and forests. In Exchange 2000 Server, these are important elements in your Active Directory structure.

Object

An object is the basic unit of Active Directory. It is a distinct, named set of attributes that represents something concrete, such as a user, printer, computer, or application. Attributes are the characteristics of the object; for example, a network printer is an object and its attributes include its location, whether it can print in color, and its print job capacity. A user is also an object. In Exchange, a user’s attributes include the user’s first name (Adam), the user’s last name (Barr), and the user’s e-mail address (adamb@winery-co.co). User attributes can also include whether the object can receive e-mail, the type of e-mail it can receive, and the location where it can receive e-mail.

Organizational Unit

An organizational unit is an Active Directory container into which you can place objects such as user accounts, groups, computers, printers, applications, file shares, and other organizational units. You can use organizational units to hold groups of objects, such as users and printers, and you can assign specific permissions to them. An organizational unit cannot contain objects from other domains and is the smallest unit you can assign or delegate administrative authority to.

You can use organizational units to create containers within a domain that represent the hierarchical, logical structures within your organization. This enables you to manage how accounts and resources are configured and used, based on your organizational model. Because organizational units can contain other organizational units, you can extend a hierarchy of containers to model your organization’s hierarchy within a domain; for example, an organizational unit can contain all of the printers in a single building or a set of color printers located in multiple buildings.

Domain

Active Directory consists of one or more domains. A domain is a security boundary of a Windows 2000 computer network. Permissions that you grant in one domain do not carry over to other domains. All objects and organizational units exist within a domain; therefore, a Windows 2000 domain, which is similar to a Windows NT 4.0 domain, can contain computers, user accounts, groups, and contacts.

You can use domains to:

  • Set administrative rights and permissions that do not cross domain boundaries. This isolates administrative permissions to specific domains.

  • Delegate administrative authority by domain or organizational unit to reduce the number of administrators with sweeping authority.

Domain controllers can receive changes to Active Directory and replicate them to all other domain controllers in the domain. In Exchange, an organization can span multiple domains and still replicate information.

Unlike previous versions of Windows NT, all domain controllers in Windows 2000 hold a writeable copy of Active Directory. Also, there is no longer a distinction between primary domain controllers and backup domain controllers. In Windows 2000, all domain controllers are peers.

Domains can be combined into structures called domain trees and forests.

Trees

A domain tree is a hierarchical arrangement of one or more Windows 2000 domains that share a common naming structure. Endpoints on the tree are usually objects. Nodes in the tree are points at which the tree branches and are containers that hold a group of objects or other containers. A tree shows how objects are related to one another.

Domain name service (DNS) domain names represent the tree structure; for example, exchange.microsoft.com. The first domain in a tree is called the root domain. Additional domains in the tree are called child domains. A domain immediately above another domain in the same domain tree is called the parent domain of the child domain. For example, in the DNS name, exchange.microsoft.com, microsoft.com is the root domain and exchange.microsoft.com is a child domain of microsoft.com.

Active Directory is called a namespace. A namespace, which is similar to the directory service in earlier versions of Exchange, is any bounded area in which a given name can be resolved. The DNS name creates a namespace for a tree or forest; for example, microsoft.com. All child domains of microsoft.com, such as exchange.microsoft.com, share the microsoft.com namespace. In Exchange 2000 Server, Active Directory forms a namespace in which the name of an object in the directory can be resolved to the object. All domains that have a common root domain form a contiguous namespace. This means the domain name of a child domain is the child domain name appended to the name of the parent domain.

Forests

A forest consists of one or more domain trees that do not form a contiguous namespace. Forests allow organizations to group divisions that operate independently but still need to communicate with one another. Forests have a root domain, which is the first domain in a forest, and which is necessary to establish trust relationships across domain trees. A forest exists as a set of objects and trust relationships between the member trees. Domains in trees and forests also share a common schema and common configuration information; therefore, an Exchange organization can span an entire forest.

A forest is the outermost boundary of Active Directory, because the directory cannot be larger than the forest. You can create multiple forests and then create trust relationships between specific domains in various forests. This allows you to grant access to resources and accounts that are outside of a particular forest; however, an Exchange organization cannot span multiple forests. When you plan the topology of your Exchange organization, you must work within this restriction. Organizations that need to support disjointed DNS names, which are domains with different namespaces, must form a forest.

The following illustration shows the relationship between domains, trees, and forests. The forest contains two trees that do not share a contiguous namespace. The two trees, microsoft.com and msft.com, contain child domains. A two-way transitive trust exists between the root, microsoft.com, and the tree, msft.com.

Figure 5.1 Windows 2000 forest

A two-way trust is a relationship in which both domains trust each other. All two-way trusts in the same domain tree or forest are automatically two-way transitive trusts. A transitive two-way trust allows a member computer to recognize users and groups from any domain and apply the permissions they have in the trusted domain. By default, when trusts are established between child and parent domains, permissions do not transfer from one domain to another. Two-way transitive trusts allow child domains to use trusts that exist for parent domains; for example, if domain A trusts domain B, and domain B trusts domain C, then domain A trusts domain C. A direct trust link between each child domain and its parent is automatically established when the child domain is created. For trees with different namespaces to exist in a forest, you must create trust relationships.

For more information about domains, trees, forests, and trusts, see the Windows 2000 documentation.

Physical Structure

The physical structure of Active Directory (for example, server locations based on network considerations and geographical locations) is based on domain controllers and Windows 2000 sites. This enables organizations to optimize replication traffic across their WANs and to assist client workstations in finding the closest domain controller to validate logon credentials. It also allows organizations flexibility in designing their directory structures but also requires careful planning.

Domain Controller

A domain controller is a computer running Windows 2000 that manages user access to a network, which includes logging on, authentication, and access to Active Directory and shared resources. Active Directory must reside on a domain controller. A domain controller stores a complete copy of all Active Directory information for that domain, manages changes to that information, and replicates those changes to other domain controllers in the same domain. Schema and infrastructure configuration information is replicated between all domain controllers in a forest.

Although the concept of primary and backup domain controllers is eliminated from Windows 2000 networking, you should still plan to deploy at least two domain controllers to ensure that if one domain controller fails, the other can provide service to your users.

Global Catalog

The global catalog is the central repository for information about objects in the forest. Through the replication process, Active Directory automatically generates the contents of the global catalog from the domain controllers that are included in the directory. The global catalog holds a replica of every object in Active Directory, but it holds a limited number of attributes for each object. The attributes replicated to the global catalog include a base set defined by Microsoft. You can specify additional attributes to meet the needs of your organization.

The global catalog enables users and applications to find objects in an Active Directory domain tree if the user or application knows one or more attributes of the target object. By default, the attributes stored in the global catalog, such as a user’s first name, last name, and login name are those most frequently used in search operations. As a result, you can use the global catalog to locate an object anywhere in the network without replicating all domain information between domain controllers.

When you install Active Directory on the first domain controller in a new domain, that domain controller is a global catalog server by default. Partial replicas are Active Directory attributes that are enabled for global catalog replication. Partial replicas are stored on the global catalog server, but the domain controllers in a domain still hold a full replica, or all attributes, of the objects in the domain.

Active Directory replication automatically builds the global catalog and generates the replication topology. A base set of attributes is replicated to the global catalog, but you can specify additional attributes to meet the needs of your organization. Changes to an Exchange user’s account information are replicated automatically to all domain controllers in the domain and when changes are made to partial replica attributes, to global catalog servers across the forest.

The more global catalog servers you have, the greater the replication traffic; however, additional servers can provide quicker responses to user inquiries. By default, each domain in your forest has a global catalog server. Exchange 2000 servers and Outlook clients require efficient access to global catalog servers. As a general rule, you should designate at least one domain controller in each Windows 2000 site as a global catalog server.

Windows 2000 Sites

A Windows 2000 site consists of one or more reliable and fast TCP/IP subnets. Setting up Windows 2000 sites is necessary to maximize network efficiency and to allow for appropriate fault tolerance.

The concept of a Windows 2000 site is different from the concept of a site in earlier versions of Exchange, except that both rely on permanent, high-bandwidth connectivity. Unlike sites in earlier versions of Exchange, Windows 2000 sites do not depend on namespace and domains.

Windows 2000 sites also help clients find the closest domain controller to validate logon credentials; for example, a Windows 2000 site is defined as the subnet ranges 192.168.10.0/24 to 192.168.20.0/24. Another Windows 2000 site on the other side of a WAN link is defined as the subnet ranges 172.20.10.0/24 to 172.20.20.0/24; however, both sites can be part of the same Windows 2000 domain.

Important Because Exchange 2000 Server uses Active Directory information on global catalog servers, it is important for you to consider where your global catalog servers reside in relationship to your Windows 2000 sites. For efficient communication, Exchange 2000 Server requires direct access to a global catalog server in your LAN.

You create sites in Windows 2000 Active Directory Sites and Services. No direct relationship exists between Windows 2000 domains and sites, so a single domain can span multiple sites and a site can span multiple domains.

One of the benefits of Active Directory is that domains can span physical locations with different topologies that are connected by WAN links and still remain transparent to the user. However, available WAN bandwidth is always a consideration. By defining groups of local subnets as sites, you can control replication traffic between the subnets, and therefore, between the sites.

Schema

All objects that can be stored in Active Directory are defined in the schema. For each type of object, which is called a class, the schema contains:

  • A definition of the attributes that an instance of the class has

  • Additional attributes an instance of the class can have

  • What class of object can be the parent of another class

Installing Active Directory on the first domain controller in a network creates a schema. The schema contains definitions of commonly used objects and attributes, such as user accounts, computers, printers, and groups. The schema also contains definitions of objects and attributes that Active Directory uses internally to function. When you install Exchange 2000 Server, the schema extends to support information that Exchange needs, such as office location, phone number, and Simple Mail Transport Protocol (SMTP) address. Updates to the schema require replication of the schema across the forest and also to all domain controllers in the forest.


Exchange and Active Directory

This section describes the relationship between Exchange and Active Directory.

Forests

Exchange administers users, contacts, and groups within the Windows 2000 architecture of domains, trees, and forests. In Exchange, some special considerations exist for forests.

With earlier versions of Exchange, users find other users through the Global Address List, which is a collection of all users. With Exchange 2000 Server, the global catalog generates the Global Address List.

By default, the global catalog shows only objects within a single forest; therefore, an Exchange organization must be within the boundaries of a single Windows 2000 forest. This is different from earlier versions of Windows NT and Exchange. For example, if you have two Windows NT 4.0 domains with no trust relationships between them, a single Exchange 5.5 organization can be deployed across the two domains because they do not rely on an underlying security structure.

Because of how earlier versions of Exchange perform mail-based directory replication between Exchange sites, users in both domains have information about all users within the same organization, and therefore, the Global Address List. With Active Directory and Exchange 2000 Server, the security structure is integrated, which means that a single Exchange organization cannot span forests but it can span domains.

If your Active Directory domains belong to the same forest, you can form a single Exchange organization. This is important if you need a single messaging system in your organization.

Domain Name System

For Exchange 2000 Server to function, a DNS service must be running in the organization. Outlook Web Access, SMTP connectivity, and Internet connectivity use DNS.

In earlier versions of Windows NT, Windows Internet Name Service (WINS) was the preferred location service because it provided dynamic publishing and full name to network address mapping. Windows 2000 Active Directory uses the DNS locator service. The DNS naming scheme is standards-based (Request for Comments 1034 and 1035) and provides maximum interoperability with Internet technologies.

Each computer on the network is represented as a full DNS name, which is registered automatically if you are using the Microsoft dynamic update service.

Note Organizations with an investment in Microsoft network basic input/output system (NetBIOS) technology may need to rename computers. The Windows 2000 naming convention uses the Internet DNS standard.

DNS names must be unique at each domain level, but individual name labels can be reused in other domains; for example, the name mailserver can be used in both the exchange.microsoft.com and microsoft.com domains.

In Windows 2000 domains using DNS, a domain name such as europe.microsoft.com does not affect the e-mail addresses for Exchange mailboxes created within that domain. Although a user’s logon name might be someone@europe.microsoft.com, you can control how e-mail addresses are generated using the recipient policies tabs in System Manager and Active Directory Users and Computers.

It is strongly recommended that in your domain names, you use only characters that are part of the Internet standard character set for DNS host naming. These characters include all uppercase letters A through Z, lowercase letters a through z, numerals 0 through 9, and the hyphen (-).

For more information about DNS servers and naming conventions, see the Windows 2000 documentation.

Schema

The Active Directory schema can be updated dynamically; that is, an application such as Exchange can extend the schema with new attributes and classes that can be used immediately. Exchange 2000 Server extends the schema once when you initially install it. In addition, if you are upgrading from an earlier version of Exchange, you must run the Exchange version of Active Directory Connector (ADC), which also extends the schema. You extend the schema by creating or modifying schema objects that are stored in Active Directory. In earlier versions of Exchange, user and mailbox changes are not made in a single location. With Exchange 2000 Server, changes to user or mailbox information are made in a single place — Active Directory.

Exchange extends the Windows 2000 Active Directory schema with new object attributes and classes, such as SMTP address, office location, and display name. You must have the appropriate permissions to modify schema objects.

Directory Object Names

The terminology that describes objects in earlier versions of Exchange has changed in Exchange 2000 Server because of the integration with Active Directory in Windows 2000. The terminology for objects in Exchange 2000 Server is now the same as the terminology for Windows 2000.

User

A user is a user account that consists of all the information that defines a user to Windows 2000. It can have Exchange e-mail addresses and an Exchange mailbox. User accounts contain logon passwords, group memberships, and permissions on network resources. A user in Windows 2000 is the equivalent of a mailbox in earlier versions of Exchange.

Contact

A contact is an Active Directory representation of a user that can have a target e-mail address and Exchange e-mail addresses, but cannot log on and does not have access to resources. A contact in Windows 2000 is equivalent to a custom recipient in earlier versions of Exchange.

Group

A group is a collection of users, groups, and contacts. A group in Windows 2000 is roughly equivalent to a distribution list in earlier versions of Exchange. There are two types of groups: security groups and distribution groups. A security group is a security principle that defines a collection of users and groups that the Windows 2000 security subsystem uses to allow or deny access to resources. A distribution group is a simple distribution list and not a security principle. Both types of groups can have Exchange e-mail addresses and Exchange mailboxes.

You use Active Directory Users and Computers to create accounts for users and to enable Exchange mailboxes for user accounts. In Windows 2000 and Exchange 2000 Server, users, contacts, and groups (objects) are mail-enabled or mailbox-enabled. These designations determine what users can do in Exchange.

Mail-Enabled

A mail-enabled object is an Active Directory object that has at least one e-mail address defined. If the user is mail-enabled, the user has an associated e-mail address but does not have an associated Exchange mailbox. The user sends and receives e-mail using a third-party messaging system, not Exchange. Users can retrieve the e-mail address from the global catalog, but the address is for a user on a remote system.

Mailbox-Enabled

A mailbox-enabled object is an Active Directory object that has an Exchange mailbox associated with it; therefore it can both send and receive messages. In Exchange, only a user object can have a mailbox. An object that is mailbox-enabled is also mail-enabled.

Directory Replication

With earlier versions of Exchange, when attributes of directory objects are changed, the entire object, and not just the changed attribute, is replicated again throughout the organization. This is because earlier versions of Exchange support only object-level replication, which results in greater network traffic for minimal changes.

With Exchange 2000 Server, directory replication occurs through Active Directory. Active Directory can replicate each changed attribute rather than the entire object; for example, if a change is made to an attribute, the attribute is replicated to other domain controllers in the domain. If the attribute is global in scope, such as an office location or phone number, the attribute is replicated to the other global catalog servers.

The following illustration shows Active Directory replication in an Exchange 2000 Server organization. A change is made to the phone number, office location, and mailbox retention period of a user. Two attributes, the user’s phone number and office location, are replicated to the local domain controller and all global catalog servers in the forest. The mailbox retention period attribute is replicated only to the local domain controllers because it is not global in scope.

Figure 5.2 Active Directory replication

Replicating individual attributes instead of entire objects has a number of benefits and implications in Exchange. Users, groups, and contacts are objects in Active Directory. Whether an object is mail-enabled or mailbox-enabled is now an attribute of the object. Attributes, such as the ability to receive mail, are added to the object. This means that:

  • Changes to an object’s attributes, for example, an office location, can be made more often.

  • Changes can be targeted to specific items, such as a specific permission; for example, mailbox size.

  • Only the changed attribute is replicated, not the entire object. This results in less network traffic.

Coexistence

Coexistence describes a scenario in which:

  • Different versions of Exchange are installed in a Windows 2000 forest.

  • Seamless communication occurs between servers.

The first task in setting up an Exchange 2000 Server organization that coexists with earlier versions of Exchange is to plan your Windows 2000 upgrade. For more information about planning your Windows 2000 upgrade, see the Windows 2000 Server Resource Kit Deployment Planning Guide.

After you upgrade to Windows 2000, you can set up ADC to provide coexistence between Active Directory and earlier versions of Exchange.

For more information about coexisting and upgrading, see Chapter 16, “Upgrading and Coexisting.”

ADC

For organizations using earlier versions of Exchange, coexistence between the directory in the earlier version of Exchange and Active Directory is a critical prerequisite to upgrading to Exchange 2000 Server.

Multiple directories can be costly and difficult to manage. Because Exchange 2000 Server uses Active Directory as its directory service, directory information is managed in one location. ADC is the Windows 2000 service that synchronizes the Exchange 5.5 directory with Active Directory. This allows you to administer your directory from Active Directory or the Exchange 5.5 directory service. You can also use ADC to migrate objects from the Exchange directory service to Active Directory. You can use ADC to replicate directory information to Active Directory, which decreases the time it takes to implement Active Directory.

Active Directory generates the Global Address List for those users who have mailboxes on an Exchange 2000 Server; therefore, it is important that all mail objects be present within Active Directory.

For more information about ADC, see Chapter 16, “Upgrading and Coexisting. “

Connection Agreements

ADC uses connection agreements to control replication between an Active Directory domain controller and a recipient container in an Exchange 5.5 site. You configure connection agreements to contain the server names to contact for replication, the object classes to replicate, the target containers, and the replication schedule. A single ADC can host multiple connection agreements between different Active Directory domain controllers and recipient containers in an Exchange 5.5.site.

Each connection agreement defines a relationship between an Active Directory domain and an Exchange 5.5 site. Multiple Exchange recipient containers can be defined in a connection agreement to replicate with an Active Directory organizational unit. Multiple Active Directory organizational units can be defined in a connection agreement to replicate to an Exchange recipient container. You can use multiple connection agreements to replicate different object types between Active Directory and a single Exchange 5.5 site.

Replication can occur from Exchange to Windows 2000, from Windows 2000 to Exchange, or in both directions simultaneously. If you want to use two-way replication to centrally manage all objects, you must define a connection agreement to every Exchange 5.5 site.

The following illustration shows how ADC synchronizes and replicates directory information between the Exchange 5.5 directory service and Active Directory through a connection agreement.

Figure 5.3 ADC synchronization and replication of directory information

If you want to replicate Exchange directory information to Active Directory only, you can configure a one-way connection agreement from Exchange. Because ADC does not write information back to the Exchange directory service in this scenario, you can replicate recipient containers from multiple Exchange 5.5 sites using a single connection agreement. This is useful when many Exchange sites from previous versions of Exchange exist in the organization, or when a distributed security model exists.


Chapter 6 Administration

Part of the planning process for deploying Microsoft Exchange 2000 Server in your organization is determining how to administer it. With the introduction of Active Directory, you can separate the administration of servers from the administration of recipients. Understanding this separation is important in deciding how to administer Exchange. In addition, understanding the new administration models is necessary to administer servers and recipients effectively.

This chapter provides an overview of administering Exchange 2000 Server. In addition, it includes an overview of hardware issues that are important for you to consider when planning a strategy for managing your servers. For detailed operational procedures related to the concepts described in this chapter, see the Exchange online documentation.


Administering Exchange

You manage Exchange using Microsoft Management Console (MMC). MMC is a tool used to create, save, and open collections of administrative tools, which are called consoles. Consoles contain items such as snap-ins, extension snap-ins, monitor controls, tasks, wizards, and documentation for managing the hardware, software, and networking components of your Windows 2000 system. A snap-in is software that comprises the smallest unit of MMC extension providing administrative functionality. You can add items to an existing MMC console, or you can create new consoles and configure them to administer a specific system component.

MMC provides a hierarchical representation of tools, components, and administrative information logically organized into containers. Containers hold either other containers or objects that you place in the containers using a drag-and-drop operation.

MMC provides a flexible management interface that you can customize. For information about how to maximize the functionality of MMC, see the MMC online documentation.

Note You can access the MMC online documentation on any computer that is running Windows 2000 by clicking Start, pointing to Run, and then typing mmc in Open. When MMC starts, click the Help icon.

You manage Exchange using two main snap-ins: System Manager and Active Directory Users and Computers.

System Manager is the Exchange administration component that is installed during Setup if you select Microsoft Exchange System Management Tools on the Component Selection screen of Microsoft Exchange 2000 Installation Wizard. If you install SMTP, you can install System Manager on any computer running Windows 2000 that you use to manage your Exchange organization. This includes any computer running Windows 2000 Professional if Windows 2000 Administration Tools is installed.

Active Directory Users and Computers is installed by default when you promote a Windows 2000 server to a domain controller.

Permissions

Exchange permissions are based on the Windows 2000 permission model. You can assign permissions that a user or group has on an object and on the object’s child objects.

When an object is created in Windows 2000, the object inherits permissions from its parent object. This inheritance feature simplifies managing permissions in the following ways:

  • Inheritance eliminates the need to manually apply permissions to child objects as they are created.

  • Inheritance ensures the permissions attached to a parent object are applied to all child objects consistently.

  • When you need to modify permissions on all objects in a container, you only need to change the permissions once on the parent objects. The child objects inherit those changes.

  • The permissions model for Exchange 2000 Server gives you more control over the permissions that users are granted on Exchange containers and objects. For example, you can give an engineer write permission on a container that is read-only for help desk staff.

The Windows 2000 Active Directory security model is extended in Exchange by using extended permissions. In earlier versions of Exchange, after a user is granted access, the user has access to all objects in that container. In Exchange 2000, you can specify user and group access by object class; for example, you can grant administrators permission to view the status of the mailbox store but not the size of a user's mailbox.


Administering Recipients

With the releases of Windows 2000 Server and Exchange 2000 Server, recipients are defined as objects within Active Directory and can take advantage of Exchange functionality. Recipients include Active Directory objects users, groups, and contacts. You create mailboxes, new users, distribution groups, and perform other related tasks in Active Directory Users and Computers because these objects are contained in and managed by Active Directory.

For more information about users, groups, and contacts as they relate to Exchange, see Chapter 5, “Active Directory.” For a thorough discussion about administering objects in Active Directory, see the Windows 2000 documentation.

Interoperability with Earlier Versions of Exchange

Mailbox management includes creating, modifying, and deleting mailboxes, e-mail addresses, and related properties. In Exchange 2000, mailbox management is integrated with Active Directory recipient management. Exchange 2000 Server does not provide a separate mailbox management tool as earlier versions of Exchange do.

The recommended method for managing recipients in a mixed environment with Exchange 2000 Server and earlier versions of Exchange is to use Active Directory Users and Computers. To manage recipients using Active Directory Users and Computers, all recipient information in your existing Exchange organization must be replicated to Active Directory using Active Directory Connector (ADC) and connection agreements.

Note To use Exchange 2000 Server in an organization running earlier versions of Exchange, you must have at least one computer running Exchange 5.5 Service Pack 3 (SP3).

During the upgrade and migration process, you can continue to manage recipients that have not been replicated to Active Directory using the management tools in Windows NT and earlier versions of Exchange.

For information about upgrading to Exchange 2000, see Chapter 16, “Upgrading and Coexisting. ”


Administering Servers

In earlier versions of Exchange, the Administrator program had to be connected to an Exchange server to extract configuration information from the directory service and make changes. With Active Directory, you can use System Manager to connect to any Windows 2000 domain controller and extract information from Active Directory.

Depending on the changes you are making, the administrative model, and the user's permissions, the changes you make may be restricted to the single Exchange server. Active Directory can replicate changes across the entire Exchange organization, giving you the ability to perform administration across the forest from a single point of control. On the other hand, by combining and applying permissions, access control, and Windows security group functionality, you can fine-tune access and control to objects. This provides you with a new level of flexibility not possible with earlier versions of Exchange.

System Manager

In Exchange 2000 Server you administer all facets of Exchange configuration centrally through System Manager. System Manager is a saved console file that is launched from the Start menu after Exchange is installed. You can configure servers, connectors, public folders, address lists, protocols, and policies in System Manager.

By default, System Manager connects to the closest available domain controller to obtain the appropriate configuration information and populate the snap-ins.

Administrative Groups and Routing Groups

In Exchange 2000 there are two ways to organize servers: administrative groups, which are based on a logical grouping of servers for administration; and routing groups, which are based on a physical grouping of servers for routing. In earlier versions of Exchange, the concept of a site represented the boundary for administrative topology and routing topology.

Administrative Groups

An administrative group is a collection of Active Directory objects that are grouped together for the purpose of permissions management. An administrative group can contain policies, routing groups, public folder hierarchies, servers, and chat networks. The content of an administrative group depends on choices you make during installation. Unless Exchange 2000 is installed into an existing Exchange organization, administrative groups are disabled in System Manager. You can enable administrative groups if you need to divide the administration of your Exchange organization.

A typical reason you create an administrative group is to define the scope of permissions for the objects in the administrative group. For example, if your organization has two sets of administrators that manage two sets of Exchange servers, you can create two administrative groups that contain these two sets of servers. To establish permissions, you can add the appropriate Windows 2000 users and groups to the security settings on the two administrative groups. Then, Active Directory propagates these settings to all the configuration objects within the administrative group.

An administrative group can contain multiple servers and multiple routing groups, but you cannot move servers between administrative groups. The administrative group is similar to a folder in which you can organize Exchange system management tools. This is similar to the way you can use folders to organize files in Windows Explorer.

Note Administrative groups function differently in a mixed environment with earlier versions of Exchange and Exchange 2000 Server.

Routing Groups

A routing group is a collection of Exchange servers that have full-time, reliable connections. Messages sent between any two servers within a routing group go directly from source to destination. Similar to administrative groups, routing groups are optional and are not visible in System Manager unless you enable them.

The primary reason you create routing groups is to define single-hop routing within your Exchange organization; however, you can also create routing groups between servers to manage messages and control the flow of messages across administrative boundaries.

Interoperability with Earlier Versions of Exchange

Exchange 2000 operates in mixed mode when you first install it. Mixed mode allows Exchange 2000 servers and servers running earlier versions of Exchange to coexist in the same organization. It allows interoperability between versions by limiting functionality to features that both products share.

If your entire organization is running only Exchange 2000 Server and you do not intend to join earlier versions of Exchange into your organization, you can switch to native mode. Native mode means you have a pure Exchange 2000 Server organization and it allows you take full advantage of Exchange 2000 Server functionality. Native mode offers the following benefits:

  • Although a server can belong to an administrative group for management purposes, that server does not have to belong to one of the routing groups within that administrative group. An administrative group does not have to contain any routing groups.

  • A single administrative group can contain all routing groups within the organization.

  • You can move mailboxes between servers in the organization.

Important If you change the operation mode of an Exchange 2000 Server organization from mixed mode to native mode, you cannot reverse the change and the organization is no longer interoperable with earlier versions of Exchange. It is important to consider this in your planning.

For more information about operating in mixed mode, see Chapter 16, “Upgrading and Coexisting.”

Address Lists

Exchange address lists provide a mechanism to partition mail-enabled objects in Active Directory for the benefit of specific groups of users. For example, if your organization is spread across a wide geographical area, you can specify an address list that extracts mail-enabled objects according to location. For a user who searches for users, groups, and contacts that reside within a common geographical area, providing a condensed version of Active Directory specific to location streamlines the user’s search. Exchange address lists support Microsoft Outlook 2000, Outlook 98, and Outlook 97, but not Outlook Express.

Types of Address Lists

There are two types of address lists: default and custom.

Default address lists are created automatically based on the values of specific attributes of Active Directory objects. These address lists are available to Exchange users without any administrator action. The following table describes each default address list.

List | Description
Global Address List | Recipients in the organization
All Users | Users within the organization (mail-enabled and mailbox-enabled)
All Groups | Groups within the organization (mail-enabled)
All Contacts | Contacts within the organization (mail-enabled)
All Conference Resources | Conferences resources within the organization
Public Folders | Public folders within the organization (mail-enabled)

You create custom address lists to help users who need a custom view of recipients within the Exchange organization. For example, you can create an address list that includes only employees in North America, or you can create an address list that includes only employees in the marketing department.

Address List Management

You create and manage address lists using System Manager. Managing address lists is simple because you do not need to add individual members to default or custom address lists. Address list memberships change dynamically and are based on Active Directory queries that are specified for each address list. When you create or modify address lists, Recipient Update Service updates the recipient object.

Policies

A policy is a collection of configuration settings that you apply to one or more Exchange configuration objects. Policies simplify the administration of Exchange by controlling the configuration of settings across servers or other objects in an Exchange organization. After you define and implement policies, editing the policy and applying the changes alters the configuration of all servers and objects the policy covers.

There are two types of policies: system policies and recipient policies.

System Policies

System policies affect Exchange configuration objects that are typically thought of as server-side objects, such as mailbox stores, public folder stores, and servers.

You create a system policy, define the settings the policy implements, associate the policy with one or more objects of the same class, and then apply the policy using System Manager. System policies apply configuration settings to items in the Windows 2000 Configuration container, which is replicated to every domain controller and optimized to apply settings to hundreds of objects.

Recipient Policies

You apply recipient policies to mail-enabled objects to generate e-mail addresses. You can define them to apply to thousands of users, groups, and contacts in Active Directory using a Lightweight Directory Access Protocol (LDAP) query interface in a single operation.

Recipient policies are for objects typically thought of as user-side, such as users, groups, and contacts. Exchange 2000 Server includes a single recipient policy that automatically generates e-mail addresses for mail-enabled Exchange objects, such as users, groups, contacts, public folders, mailbox stores, and public folder stores.

Real-Time Collaboration

You can use System Manager to manage real-time collaboration components such as Chat Service and Instant Messaging. For more information about how to administer these components, see the Exchange 2000 online documentation.

System Maintenance

A critical element of Exchange administration is maintaining your system. Before you install Exchange, you should create a plan for system maintenance.

Maintaining your system involves:

  • Backing up and restoring your servers and consistently monitoring how well your servers are functioning.

  • Monitoring performance and setting up appropriate notifications.

Exchange 2000 Server uses the Windows 2000 Backup utility to back up and restore the Information Store. This utility enables you to protect data from accidental loss or hardware failure. It uses a storage device to back up and restore information located on any local server in your organization or over the network. For more information about backup and restore, see Chapter 14, “Backup and Restore.”

Windows 2000 provides a System Monitor snap-in and a Performance Logs and Alerts snap-in you can use to measure the performance of computers on your network.

System Monitor and Performance Logs and Alerts provide detailed data about the resources used by specific components of the operating system and server programs, such as Exchange. Graphs provide a display for performance monitoring data; logs provide recording capabilities for the data. Alerts send notifications to users by means of the Messenger service when a counter value reaches, rises above, or falls below a defined threshold.

Microsoft Technical Support often uses the results of performance monitoring to diagnose problems; therefore, Microsoft recommends that you monitor system performance as part of your administrative routine. For more information about System Monitor and Performance Logs and Alerts, see the Windows 2000 documentation.


Administrative Models

The examples in this section illustrate models of administrative groups and routing groups that relate to different organizational configurations. You can use these administrative group and routing group implementations as examples when planning your Exchange deployment.

Distributed Management

The distributed management model shows complete control over management of the Exchange organization distributed to company regions or divisions. This model is similar to the site model in earlier versions of Exchange. It is often used by organizations that have branch offices operating independently.

Typically, a central group manages standards and guidelines but not administration. In this model, there is at least one administrative group for each region or division. In a mixed environment with Exchange 2000 and previous versions of Exchange, administrative groups and routing groups are automatically arranged in this way because existing Exchange sites are mapped one-to-one to administrative groups and routing groups when you upgrade to Exchange 2000 Server.

The following illustration shows an Exchange 2000 Server organization with four administrative groups for four different regions. Each administrative group has one or more routing groups and one or more servers running Exchange. Each location has its own group of administrators, which the administrative groups define, and the administrators are restricted to their respective administrative groups.

Figure 6.1 Distributed management model in an Exchange organization

The following illustration shows how the distributed management model appears in System Manager.

Figure 6.2 Distributed management model as it appears in System Manager

Centralized Management

In a centralized management model, a single central group maintains complete control of administration. In this model, there is only one administrative group, but there can be many routing groups.

The following illustration shows an Exchange 2000 Server organization with a centralized administration model. A single administrative group administers routing groups in six regions.

Figure 6.3 Centralized management in a single administrative group containing multiple routing groups

The following illustration shows how the centralized management model appears in System Manager. Note that the CorporateHQ administrative group contains all of the routing groups.

Figure 6.4 Centralized management model as it appears in System Manager

Mixed Distributed and Centralized Management

Mixing distributed and centralized management is the most common scenario in organizations with multiple divisions or offices dispersed geographically. In this environment, you can use special administrative groups for one or both of the following:

  • Centralized routing management

  • Centralized policy management

Centralized Routing Management

Because of the importance and complexity of routing topology, you may restrict routing management to a special group of professionals, who usually belong to the central group of administrators. This is typical when the central group is responsible for the messaging backbone and regional administrators are responsible for day-to-day administration of servers and other services.

Centralized Policy Management

A central group of administrators is responsible for the policies that enforce standard configuration across the organization. The regional administrators are responsible for day-to-day management and monitoring of servers. A variation on this scenario is to have the central group define some organization-wide policies, and have the regional administrators control the remaining policies.


Hardware Considerations

Another aspect of administering servers in Exchange is understanding the different hardware components and the considerations associated with them. You can install and run Exchange in a variety of physical configurations. Server capabilities and Exchange requirements can determine how you allocate your hardware resources.

Using Performance Monitor is an important method of determining the effectiveness of your hardware. You can use System Monitor to set up and monitor the loads placed on your servers. Performing regular system monitoring should be an important part of your planning.

Setting up monitoring on your servers is the first step in determining the efficiency of your hardware. After you set up System Monitor, you can examine the usage levels of the following server areas. For more information about setting up System Monitor, see the Windows 2000 documentation.

Processor

All Exchange 2000 services and server functions use a computer’s processor. One of the most effective methods of determining the efficiency of your hardware is to monitor the usage level of the processor. If the results indicate the processor is close to maximum output for an extended period of time, increasing the number of users on this server will cause slower overall performance and degrade performance further for all users on the server. You should upgrade a processor that is constantly at maximum usage.

Disk I/O

As your Exchange server continuously reads and writes information to the hard drive, the amount of disk input and output (I/O) increases. Disk I/O traffic is created by Exchange, Windows 2000, and other applications you install on the server. Slow disk I/O can increase the time required for applications such as Exchange to access information stored on the hard drive. Performance monitoring gives you information about the effectiveness of your physical storage and how quickly it responds to requests.

Memory

Monitoring how much RAM the applications on your server consume helps you determine whether the amount of RAM currently installed is adequate for the current level of usage.

If RAM usage is high and the amount of RAM is inadequate, your Windows 2000 servers not only run slowly, but require paging of memory to compensate for the lack of RAM. When memory is paged, it not only uses physical storage space, it increases disk I/O and processor usage. Having adequate RAM is important to the efficiency of your Windows 2000 servers and the applications you install on them.

Physical Storage

Applications such as Exchange use physical storage to store users’ mail. As the number of users on your server increases, the amount of available physical storage decreases and the demands of Exchange increase. You should monitor your available hard disk space regularly to ensure that disk space is available when you add additional users.


Chapter 7 Information Store

In Microsoft Exchange 2000 Server, the Information Store is responsible for data storage and management. Its new architecture and feature set make it possible for you to create reliable Exchange systems that scale to large numbers of users with new levels of administrative control and precision.

The Information Store supports access through Internet protocols such as HTTP and WebDAV (an extension of HTTP 1.1) and native storage for data formats such as XML and Multipurpose Internet Mail Extensions (MIME). Integration with Microsoft Office 2000 and Microsoft Windows 2000 Server is built in, as is support for APIs such as Collaboration Data Objects (CDO), ActiveX Data Objects (ADO), OLE DB, and Active Directory Services Interfaces (ADSI).

Changes to the architecture of the Information Store make new methods of accessing data that Exchange stores possible. With support for any Windows or Internet client and various APIs, the Information Store is more than the place where data is stored; it becomes a Microsoft Web Storage System, a single repository in which you can store and manage documents, collaborate with other team members, and run business applications. You can organize information of all types by topic in a single folder instead of by storage technology in several locations.

The following illustration shows that clients use protocols to communicate with the Information Store and that custom applications use APIs to communicate with the Information Store. The illustration also shows two storage groups, which contain mailbox stores and public folder stores.

Figure 7.1 Information Store architecture

This chapter describes the functions of the Information Store. The following sections include issues that you need to consider when planning your Exchange system:

  • Multiple databases and storage groups

  • Public folder stores

  • Installable File System (IFS)

  • Full-text indexing


Multiple Databases and Storage Groups

Exchange 2000 supports multiple mailbox stores and public folder stores instead of a single private information store and public information store as in earlier versions of Exchange. Because every mailbox or public folder store is contained in an Exchange database, you can design your storage so that individual databases are smaller, which allows for faster backup and restore and increased flexibility in managing backups.

Storage groups, a new feature of Exchange 2000 Server, provide additional flexibility. With a storage group, you can organize a collection of mailbox stores, public folder stores, and the set of transaction log files associated with each storage group as a single administrative unit. Exchange manages each storage group with a separate server process. A transaction log file records every message stored and provides fault tolerance if you need to restore the data.

An Exchange database consists of a rich-text .edb file and a native multimedia content .stm file. You can administer databases independently of one another by dismounting the mailbox or public folder store you want to work with. Once you have finished working with the database, you can mount it, making the mailbox or public folder store available to users. Because of this flexibility, damaged databases do not prevent the Information Store from running. Exchange can run with the remaining mailbox or public folder stores functioning while you take the damaged store offline for maintenance or troubleshooting.

Native Support for MIME Content

E-mail messages today can include anything from a simple piece of text to extremely large audio and video messages. Multimedia messages enrich the messaging and collaboration experience for many users and also place new demands on the messaging system.

Exchange supports multimedia messages by storing MIME content directly in an .stm file. Clients using standard protocols such as HTTP, Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), and Internet Message Access Protocol version 4rev1 (IMAP4) can store audio, video, voice, or other multimedia formats as streams of MIME data without converting them to a common format. If a MAPI client requires information from an .stm file, Exchange converts the data and sends it to the client as an attachment.

Single Instance Message Storage

Exchange supports single-instance message storage for messages written to the same mailbox store. If the message is sent to one or more mailboxes in different mailbox stores, the message is written once to each mailbox store. If mailbox stores containing the same message are in different storage groups, the message is added to each mailbox store and to the set of transaction logs for each storage group.

Single instance storage is not maintained if you move a mailbox to a different mailbox store, even if that mailbox store resides within the same storage group.

Data Recovery and Transaction Logging

Mailbox stores and public folder stores in the same storage group share a single set of transaction log files. Each transaction in an underlying database is marked with an identifier to enable you to recover individual databases within a storage group. Using the Windows 2000 Backup utility or a third-party backup product, you can back up any storage group, mailbox store, or public folder store while it is running. When you back up a mailbox or public folder store, you should also include its transaction log files. To back up a database and its transaction log files, back up the storage group containing the database, and the transaction log files are automatically included.

The following sections describe concepts that help you plan the purpose and number of drives you need for good server performance in your environment.

Drives for Transaction Log Files

You can significantly improve performance by placing the transaction log files for each storage group on a separate drive. Because these files are critical to the reliability of your system, you can protect the drives against failure, ideally with hardware mirroring by using Redundant Array of Independent Drives (RAID).

The following illustration shows a sample configuration for two storage groups. Notice that each storage group has a corresponding drive for transaction log files that is mirrored between two disks within RAID. The storage groups in this illustration share a physical drive, D.

Figure 7.2 Transaction log drive configuration

Because each storage group has its own set of transaction logs, the number of drives for transaction log files on your server should exceed the number of storage groups you plan to create. Although you can place multiple sets of transaction log files on the same drive, server performance can suffer.

Note Always format transaction log drives with NTFS 5.0.

Circular Logging

Circular logging overwrites transaction log files after the data they contain is written to the database. By enabling circular logging, you reduce disk space requirements for transaction log files.

Caution If you enable circular logging, you cannot recover changes to the database that occur after the last full backup.

To increase your backup options and data recovery ability, keep circular logging disabled. For more information about data recovery, see Chapter 14, “Backup and Restore.”

Drives for Data

When you deploy multiple storage groups, it is more important that each storage group have a dedicated drive for transaction log files than it is that the data volume have more drives. Although a separate drive array for each storage group’s set of transaction logs can increase performance, it can be costly to implement for smaller servers, and it may not increase performance significantly.

The number of drives that servers require also depends on the number of users the server hosts and the volume of data your applications require. For an Exchange server dedicated to few users, a single drive array consisting of three of four drives may be appropriate; a server that a data center or service provider uses may require multiple drive storage arrays.

Although you can have numerous storage groups on a single drive, you should protect the array. Although RAID5 (striping with distributed parity) is very cost-effective for providing fault-tolerance and good performance, environments with very frequent transactions can experience a performance bottleneck. This bottleneck is evident when you restore data to a RAID5 array. You may want to investigate the cost of using RAID6 or RAID10 (hardware striping and mirroring) for the best performance and reliability.

Planning Considerations

You can use the flexibility of multiple mailbox or public folder stores so that you can have several smaller databases. Smaller databases increase the flexibility of your backup schedule and reduce the backup and restore times for each database. This can help your organization adhere to its service level agreements; however, more databases also increase administrative requirements. If your system currently has a large, multiple gigabyte public folder or mailbox store, consider dividing it into separate mailbox or public folder stores when you upgrade.

The following sections contain information to help you meet your requirements for performance and control.

Separating Stores for Improved Performance

Faster restores Several small mailbox or public folder stores restore faster than a large one.

Priority service Create mailboxes for very important people (VIPs) that need the fastest restores possible; however, remember that creating a mailbox store for a single mailbox is not recommended, because of its low benefit compared to its increased administrative cost.

Minimize indexing overhead Place information requiring content indexing in a separate mailbox or public folder store. Enable content indexing for that store to serve the set of users who use the index. Remember that the resource overhead associated with content indexing affects administrative and hardware requirements.

Minimize disk space requirements Maximize single-instance message storage. Place similar users in the same mailbox store, such as users in the same department who use Reply All or users who frequently send large attachments to each other.

Separating Stores for Improved Administrative Control

Different restore schedules for mailbox or public folder stores Segregate data requiring specific restore times; for example, if you have a service level agreement requiring a four hour restore time for some of your data, use database sizes and the transfer rates of your restore equipment to calculate service level agreement conformance.

Consolidate dedicated servers into one Consolidate the public and private information stores on dedicated servers (mailbox-only, public folders-only, or NNTP-only servers) running earlier versions of Exchange onto a single server running Exchange 2000 Server.

Different stores for organizational units Create separate mailbox or public folder stores for departments, work groups, or cross-functional teams. Identify the number of mailbox or public folder stores that balance administrative control with reliability requirements.

Separating Storage Groups for Improved Performance

Faster servers When each storage group has its own dedicated drive for transaction log files, server performance is faster.

Parallel restores You can restore storage groups concurrently if you have not reached your storage group limit; for example, if you have three storage groups, you can restore two at the same time if you have one storage group available in addition to the storage group that Exchange reserves for restores.

Separating Storage Groups for Improved Administrative Control

Multiple companies hosted on each server ISPs often host multiple customers on the same server. Each customer can have his or her own partition or drive, storage groups, transaction log files, public folders, and so on.

Multiple backup schedules You can use different backup schedules for different sets of data, and the storage group is the best unit for backup.


Public Folders

In addition to supporting multiple public folder stores, Exchange supports multiple public folder hierarchies. A public folder hierarchy is the set of public folders within a single public folder store. You can keep a public folder hierarchy on one server or you can specify additional servers to which the hierarchy replicates.

Exchange 5.5 supports only one public folder hierarchy that replicates to all servers. For some organizations, this hierarchy can be difficult to manage and navigate.

When you first install Exchange, it has one public folder store containing one public folder hierarchy, which is named Public Folders. This public folder hierarchy is accessible from IMAP and MAPI mail clients, browsers using WebDAV, and from standard applications using IFS. Any additional public folder hierarchies that you create are accessible only from standard applications that use individual folders mapped as network drives. Use these public folder hierarchies as file repositories for departments, groups, or projects. For information about naming public folder stores, see Appendix B, “Naming Convention Restrictions.”

Internet Publishing from Public Folders

With the new support for native MIME content, you can host Web sites from public folders. The HTML or Active Server Pages (ASP) files reside in the .stm file of a public folder store, where they are accessible from Internet browsers. You can replicate public folder stores containing Web sites to other servers.

Web page performance is better when pages are served from a public folder instead of from a file system, because of the addition of IFS to Exchange.

Use Microsoft FrontPage® or any authoring tool to create Web sites using standard ActiveX or Dynamic HTML (DHTML) controls. Because Exchange stores these Web pages, they can contain Exchange-specific functionality such as calendars and custom applications.


Installable File System

IFS is a storage technology that functions as a filing system. It makes mailboxes and public folders available as traditional folders and files through standard 32-bit Windows processes such as Microsoft Internet Explorer and the command prompt. IFS makes it possible for you to map Exchange folders as shared network drives.

The real benefit of IFS is how you can use it with other features of the Information Store. When combined with custom document properties, full-text indexing and HTTP client support, Exchange becomes a document repository with advanced search capabilities. Users with clients such as Microsoft Outlook 2000 or Outlook Web Access can search for document properties, get the results much faster than in earlier versions of Exchange or NTFS, and see the results rendered in a Outlook-style views. For more information about clients that support HTTP and can use IFS, see Chapter 4, “Clients and Internet Protocols.”

You can apply additional custom properties or metadata to Exchange objects. For example, if you have a document management system using Exchange as the repository, you can add custom properties to the documents. These properties are automatically added to the Information Store along with the documents; however, these properties are not included when you copy or move the documents from the Information Store.

You can share drive M, which is the IFS folder hierarchy, on the computer running Exchange. Users can map local drives to their folders or mailbox in the IFS hierarchy. When users map local drives, they can share the drives to give others access to their data.

The IFS hierarchy contains two folders: \Public Folders and \Mbx.

  • You can list items in \Public Folders with the standard dir command and manipulate them with other file system operations such as copy and delete. All standard message items appear as files with .eml file extensions. You can display individual messages by using the type command.

  • The \Mbx folder is the root for all mailboxes on the Exchange server. If you have permissions you can access mailboxes by explicitly specifying mailbox names within the \Mbx folder.


Full-Text Indexing

The Information Store can create and manage indexes for common key fields (Subject, Body, From, To, and E-mail Address) for fast searches and lookups. Earlier versions of Exchange search every item in every folder, so search times increase as database size increases. With full-text indexing, every word in the mailbox or public folder store is indexed, making faster searching possible. Outlook users can search documents in the Information Store as easily as they can search for e-mail messages, because text in attachments is also indexed.

Additionally, advanced searches are possible using the custom properties feature of the Information Store. Users can search on any document property, such as author or department, because these are automatically added to the index.

Indexing several gigabytes of data is a resource-intensive operation that can be time consuming. Because indexes are created for each database, creating multiple small databases balances the resource load. You can schedule index builds and updates for times the server is not subject to heavy load. An indexed database requires approximately 20 percent more drive space than a non-indexed database.

When multiple messages are stored as a single instance in a mailbox store, each message is indexed only once.

Note An individual index is not backed up with the database or storage group. You must rebuild an index if it is damaged.


Chapter 8 Routing

Your routing topology is the basis of your messaging system. You must plan your routing topology with network, bandwidth, and geographical considerations in mind. Use this chapter to understand how routing works in Microsoft Exchange 2000 Server, to create a routing topology that works with your existing systems and network, and to design connectors for communicating with recipients outside your organization.

Topics in this chapter appear in order of increasing complexity; for example, if your organization exists in a single location and does not use routing groups, the first half of the chapter is most relevant for you. If your organization deploys multiple Exchange servers across several locations and uses routing groups, read the entire chapter, including “Single Routing Group Deployment.” Read the last section, “Mixed and Native Modes,” if your organization is upgrading from earlier versions of Exchange.


Routing Overview

A routing group is a collection of Exchange servers linked by full-time, reliable connections. Within a routing group, all mail is transferred directly between servers. If you have a single Exchange server or if all your servers are connected over full-time, reliable connections, you do not need to create multiple routing groups. However, the topics in this chapter are useful for understanding how Exchange transfers messages within your organization and for future planning.

Architecture

Routing describes how Exchange transfers messages from one user to another. This includes messages to servers within an Exchange organization and servers outside Exchange messaging systems. Most Exchange installations require configuring multiple servers to:

  • Share the processing load for mailbox stores and public folder stores.

  • Perform specific functions, such as certificate management or connecting to other messaging systems.

  • Support sets of users in separate locations.

  • Serve as front-end protocol servers for HTTP, Post Office Protocol version 3 (POP3), and Internet Message Access Protocol Version 4rev1 (IMAP4).

If you have multiple Exchange servers in different locations, you must decide how to connect the servers so that they can communicate with each other. When planning your routing topology, you need to understand how messages are transferred within Exchange and plan a topology that allows the most efficient transfer of messages. You also need to plan the locations of connectors to messaging systems outside your Exchange organization. Careful planning can reduce the volume of network traffic and optimize Exchange and Microsoft Windows 2000 services.

In earlier versions of Exchange, an Exchange site represents both administrative and routing topology boundaries. In Exchange 2000 Server, two distinct entities exist: the administrative group and the routing group.

Information from Active Directory

Because Exchange uses Active Directory, it is crucial that you consider your Windows 2000 network topology as you plan your Exchange deployment. For best performance, make sure you have at least one global catalog server in each Windows 2000 site. Multiple domain controllers within domains decrease Exchange replication and look-up traffic on the network and provide redundancy if a domain controller fails. For more information about planning Windows 2000 sites, domains, and domain controllers, see the Windows 2000 Server documentation.

Servers within each routing group get routing information about other servers in the organization from the configuration portion of Active Directory. Exchange uses directory-wide services, including authentication, to control access to mailboxes and other resources. Furthermore, Exchange uses Active Directory Connector (ADC) to populate Active Directory with routing information from earlier Exchange organizations, allowing different versions of Exchange to coexist on the same messaging network.


Native Message Transport

Simple Mail Transfer Protocol (SMTP) is now the native transport protocol for Exchange. SMTP serves three functions in Exchange 2000 Server: clients use it to submit messages and servers use it to route messages and to exchange replication information and similar data. Exchange still uses remote procedure call (RPC), but only for communication with servers running earlier versions of Exchange.

The SMTP service is an Internet Information Services (IIS) transport stack. When you install Exchange, you add a routing engine and increased message queuing functionality to the SMTP service. Exchange activates and extends a basic Windows 2000 message categorizing utility to provide advanced address resolution. Exchange administrators now have greater control over their messaging systems at every stage of transport.


Single Routing Group Deployment

If you have only a single group of servers in one location with full-time, reliable connectivity, you do not need special routing groups; however, you may choose to create routing groups between such servers to manage the flow of messages across administrative boundaries. Unless you enable and create routing groups, the Routing Groups container in System Manager does not appear. Instead, you see only the Connectors container.

Even if you do not define SMTP connectors in your Exchange organization, each server automatically attempts to connect to remote SMTP servers using Domain Name Service (DNS). If you define an SMTP connector but it does not match the address space of an outgoing message, the server attempts to use DNS.

The following sections describe in detail how Exchange handles message routing in an organization with a single routing group. One routing group, called First Routing Group, exists by default but remains hidden unless you explicitly enable routing groups in System Manager.

Same Server Delivery

The routing process begins when an Exchange server receives a message from a user, another Exchange server, or another messaging system through a connector or gateway. The server looks up the recipient in Active Directory and routes the message to the recipient's mailbox.

If the Exchange server determines that the recipient is on the same server, it passes the message to the mailbox store on the server, which delivers the message to the recipient’s mailbox.

Same Routing Group Delivery

Message transfer within a routing group is point to point, which means that the originating server communicates directly with the recipient’s server. When the recipient’s server receives the message, it looks up the recipient in Active Directory and delivers the message to the recipient’s mailbox.

Outside Organization Delivery

If a message must reach a recipient whose mailbox resides on a different system or in an independent Exchange organization, the message must travel over a connector. The following illustration shows an Exchange server that receives a message destined for a domain that is not part of the Exchange organization. The server locates a connector for the message based on the recipient address and address type. The server then routes the message to the bridgehead server and the message travels over the connector.

Figure 8.1 Routing a message outside an organization

Depending on the destination mail system, the message may travel over multiple servers and connectors.

Rerouting Mail and Retries

When a message is routed to a connector that fails (after a retry period) to connect to the remote system, the message is immediately rerouted along another path, if one exists. If no other path is available, the message moves to a queue, where it sits until a route is available or until the message expires. If the message expires (its age equals the expiration timeout set on the virtual server), the message is returned to the sender with a non-delivery report (NDR).

Note Scheduled connectors function differently from connectors that are not working. Scheduled connectors are considered to be available for purposes of routing calculation. As a result, a message routed to a connector with an activation schedule with Queue mail for remote triggered delivery selected is not rerouted unless the activation schedule changes while the message is in the queue. Messages wait in the queue on the bridgehead server until the connector becomes available.


Connectors to External Systems

Exchange offers several ways to route messages outside your organization. You can route messages to the Internet or to other SMTP systems within an organization using an SMTP connector. You can route messages to an X.400 provider or other X.400 systems using an X.400 connector. You can also connect to any of the following non-Exchange systems using the appropriate connector:

  • Lotus Notes

  • Lotus cc:Mail

  • MS Mail

You can use an existing connector that Exchange 2000 Server doesn’t provide by including a server and connector from an earlier version of Exchange in your organization.

Note Using a server running an earlier version of Exchange requires you to run Exchange in mixed mode. In mixed mode, a single routing group replaces each Exchange site in your organization.

For more information about connecting Exchange to other systems, see Chapter 17, “Migrating to Exchange,” and the Exchange online documentation.

Connector Types

You can use the following connectors to connect to servers outside your Exchange organization or to different routing groups within your organization. You can find more information about routing functionality with multiple routing groups later in this chapter.

SMTP Connector

The primary function of an SMTP connector is to provide messaging connectivity between an Exchange organization and a non-Exchange system (or the Internet). SMTP connectors link one or more bridgehead servers directly to a smart host or a remote server that stores recipient addresses. Typically, when connecting to a non-Exchange system, a DNS mail exchanger (MX) record is set up to point to one or more servers in the non-Exchange system. The SMTP connector then uses that MX record to send messages to one or more servers in the order defined in the MX record.

SMTP connector options include issuing authentication before sending mail, specifying Transport Layer Security (TLS) encryption, and issuing a command to remove mail from the queue on the remote server.

Smart Host vs. DNS Lookup

You can route outgoing messages for remote domains through a smart host instead of sending them directly to the domain. A smart host, also known as a relay host, is a host that has a full-time connection to the Internet to relay mail for your server. If your server has an intermittent or dial-up connection to the Internet, a smart host handles retries for undeliverable messages, removing this burden from your system. A smart host usually requires configuration to allow your system to relay mail. Usually, your ISP provides you with a hostname for a smart host.

If you do not use a smart host, every address to which the SMTP connector sends mail requires a DNS lookup.

Internet Message Content Configuration

When a Microsoft Outlook client in Corporate/Workgroup mode (also known as MAPI mode) sends a message to an Internet user, the message must be converted into an Internet message format. Exchange allows you to choose the content type for messages sent outside the Exchange organization. In System Manager, under Global Settings and Internet Message Formats, you can define one or more domains. By default, Exchange provides the * domain, which matches domains not otherwise specified.

You can select properties specifying how each domain receives Multipurpose Internet Mail Extensions (MIME) and Exchange Rich Text Format (RTF) messages from your organization.

MAPI properties that cannot be converted or have no SMTP equivalent, such as RTF, are encapsulated using transport-neutral encapsulation format (TNEF) and are sent as a standard MIME file attachment called Winmail.dat.

Exchange RTF allows users to use advanced formatting and special message types, such as calendaring and tasks. If a recipient whose messaging system does not support RTF receives an RTF message, the message may appear as a plain text message with a Winmail.dat attachment. In addition, any attachments included with the message may be encapsulated within the Winmail.dat attachment and may not be readable. Note that without RTF, some text formatting is possible with MIME and HTML.

If the receiving messaging system is Exchange, RTF messages appear normally. Alternatively, if a recipient’s computer is running Outlook 98 or later in Internet Only mode, the recipient can read RTF messages regardless of the messaging system.

Upgrading Internet Mail Service

When you upgrade Exchange 5.5, Internet Mail Service becomes an SMTP connector, and any Internet Mail Service address spaces are added to one SMTP connector. Some information may not transfer during an upgrade from Exchange 5.5, but the upgrade log provides details about what is not transferred. For example, when upgrading from Internet Mail Service that has a list of domains for content configuration, the information moves into the global configuration. The content configuration information on subsequent upgraded servers does not move to the global list. The upgrade log of the second Internet Mail Service includes any information that does not transfer. In most cases, all instances of Internet Mail Service have the same configuration and any exceptions stem from configuration errors.

X.400 Connector

You can use an X.400 connector to establish an X.400 messaging route between Exchange and another X.400 system.

Before you define an X.400 connector, you must first configure an X.400 transport stack. You can configure the following transport stacks:

TCP/IP Use the TCP/IP X.400 transport stack when the underlying protocol is TCP/IP, such as when the X.400 connector is established over the Internet.

X.25 Use the X.25 X.400 transport stack when the underlying protocol is X.25.

DRAS Use the Dynamic RAS (DRAS) X.400 transport stack when the underlying protocol is RPC over Remote Access Service (RAS) and you use a dial-up modem.

For more information about configuring transport stacks, see the Exchange online documentation.

Connector Configuration

When you use a connector, you need to specify parameters that define what it connects to. The following sections explain some of the ways you can configure your connectors. For information about naming connectors, see Appendix B, “Naming Convention Restrictions.”

Address Spaces

You add an address space to a connector to indicate that messages to a particular group of addresses should be routed over the connector. Each connector is capable of delivering messages that match the address space that you define on the connector. Each SMTP or X.400 connector has at least one address space and can have one or more connected routing groups associated with it. You define an address space by an address type, such as SMTP, X400, or CCMAIL, and an address, such as *.edu, *.com, *.microsoft.com.

You can use address spaces to control which messages travel over a connector. When you use multiple connectors, you can use address spaces to balance the messaging load; for example, if you have two SMTP connectors for transferring mail to the Internet, you can designate one to process messages destined for the *.com address space and another to process messages destined for the *.bank address space. You can specify multiple local bridgehead servers for any SMTP connector for load balancing and fault tolerance.

The following illustration shows that the address space type is SMTP and the address is *.com; thus, this connector accepts and processes only SMTP messages addressed to recipients in the .com domain.

Figure 8.2 SMTP address space for connector

In another example, a computer running Exchange 2000 Server is connected to a computer running Exchange Server 5.5 by an X.400 connector. To transfer messages between the two servers, you must specify an X.400 connector and at least one X.400 address space.

The following illustration shows that the address space type is X.400 and the address is o=North America; p=Microsoft; a=Telecom Company; c=US; therefore, the connector accepts and processes only X.400 messages with an organization (o) of North America, a private management domain (p) of Microsoft, an administrative management domain (a) of Telecom Company, and a country code (c) of US.

Figure 8.3 X.400 address space for connector

Setting Connector Cost

If more than one connector is available for a given destination, the routing engine chooses a connector based on the lowest cost and other restrictions. A connection cost represents the preference for one route over others. The routing engine tries connectors with a cost of zero first and connectors with a cost of 100 last. The routing engine tries all target connectors before Exchange reroutes the message. To influence which connector is used most frequently, you can adjust the cost value assigned to each connector.

Specifying Delivery Restrictions

You can specify that a connector accept or reject outbound messages from any sender listed in Active Directory by setting delivery restrictions for the connector

Delivery restrictions are optional and affect only outgoing messages. By default, Exchange accepts all messages from all senders. For more information about delivery restrictions, see the Exchange online documentation.

Scheduling Connectors

Connectors have two schedules: one for messages under a size threshold that you set, and one for messages that are over that threshold. You can set both schedules to always run, never run, or run at a specified time.


Multiple Routing Groups

Routing groups define sets of Exchange servers according to physical network connectivity and bandwidth constraints.

Note From a topological perspective, routing groups are similar to sites in earlier versions of Exchange.

The most efficient routing group designs use messaging traffic analysis to determine which sets of users (and therefore, which servers) communicate with each other most often.

For example, if a constant stream of user or public folder replication traffic exists between two departments within the organization, you should place servers for those departments within the same routing group. However, full-time, reliable connections between Exchange servers are not always feasible; for example, servers in a European office may be connected to a North American subsidiary by a slower link. Routing group topology is not effective if servers within a routing group have slow or intermittent connections.

Continuing with the previous example, you can place servers in the central office in one routing group and servers in the subsidiary in a separate routing group. Within each routing group, servers are connected by full-time, reliable connections with a slower or intermittent connection between the routing groups.

You may choose to set up multiple routing groups in your organization if:

  • Exchange servers do not have full-time, reliable, and direct SMTP connectivity to one another.

  • You must control the protocol and path for messages that travel between servers.

  • Tracking requirements dictate the messaging path.

Naming Routing Groups

Routing groups should have unique names that relate to their location or the function of the servers within the routing group. Routing group names can contain up to 64 characters. For a list of restricted characters see Appendix B, “Naming Convention Restrictions.”

Multiple Routing Group Delivery

Message routing in an organization with multiple routing groups is the same as message routing in an organization with a single routing group; however, an additional scenario exists for messages traveling between routing groups.

If a server determines that a recipient is on a server in a different routing group, it identifies a route for the message to take and sends the message to the appropriate connector. If you define bridgehead servers for each connector in the path, the message travels to the source bridgehead server, which sends the message over the lowest cost connector to the next routing group.

Each server maintains a table of link state information that the server uses to determine the best path for a message. The status and cost of connectors is transferred among servers within a routing group and among servers in connected routing groups. Because each server has complete information about the routing topology, loop-free routing is possible.

In the following illustration, the message follows the path over the links with costs of one and three because the total cost (four) is lower than the total cost (five) for the path over the links with costs of two and three.

Figure 8.4 Routing a message between routing groups

When a bridgehead server in another routing group receives the message, the routing process repeats in the remote routing group until the message arrives in the recipient’s mailbox. Depending on the path a message takes, the message may travel over multiple servers and routing groups.

Connectors Between Routing Groups

You establish communication between servers in different routing groups with connectors. If you define bridgehead servers, all message traffic that leaves a routing group leaves through one of the bridgehead servers. Similarly, all message traffic coming into that routing group enters through a bridgehead server.

One advantage of identifying multiple servers as bridgehead servers is that Exchange can use another bridgehead server within the routing group if the first bridgehead server is unavailable. For additional information about how alternate routes are determined, see “Link State Tables” later in this section.

When planning the connectors for your routing group, you should take into consideration the parameters of the connector, such as cost, message size, transmission scheduling, address spaces, and restrictions. For more information about configuring connectors, see “Connector Configuration” earlier in this chapter.

Communication between routing groups usually, though not always, takes place over slower or intermittent links. You may use any of the following connectors to connect two routing groups:

  • Routing Group connector (preferred)

  • SMTP connector

  • X.400 connector

To create adequate load balancing and fault tolerance, you can configure multiple connectors between two routing groups. For more information about SMTP and X.400 connectors, see “Connector Types” earlier in this chapter.

Routing Group Connector

The Routing Group connector is the preferred connector for linking routing groups together, because it is the simplest to configure and offers multiple source and destination bridgehead servers for fault tolerance. The Routing Group connector (similar to the Site Connector in earlier versions of Exchange) has the fewest settings, which makes it easy to connect two routing groups.

SMTP is the native transport for the Routing Group connector and obtains its routing and next hop information from the Link State table. A Routing Group connector is unidirectional; therefore, you must create two Routing Group connectors to properly link two routing groups. When you create a Routing Group connector, System Manager can automatically configure the second connector.

You can define zero, one, or multiple bridgehead servers for a Routing Group connector. If you do not define a source bridgehead server, all servers in a routing group act as source bridgehead servers. If you want all mail to flow through one server for the purposes of tracking or archiving messages, use a single bridgehead server. Multiple bridgehead servers provide load balancing and fault tolerance in the event of a bridgehead server failure. Using bridgehead servers helps you control which servers send and receive messages between routing groups.

SMTP Connector

You can use an SMTP connector to fine-tune your routing configuration to a greater extent than you can with a Routing Group connector. Additionally, you use an SMTP connector to specify that the connector use SMTP. When you use a Routing Group connector to connect an Exchange 2000 server with an Exchange 5.5 server, the Exchange 2000 server automatically uses RPC communication, because it cannot detect whether the Exchange 5.5 server has Internet Mail Service.

Options for SMTP connectors include issuing authentication before sending mail, specifying TLS encryption, and issuing a command to remove mail from the queue on the remote server.

X.400 Connector

You can use an X.400 connector to establish an X.400 messaging route between two Exchange routing groups

When you use an X.400 connector to connect two routing groups, the bridgehead server in each routing group is configured to provide the connection. You can configure multiple X.400 connectors, each using different transport types.

Link State Tables

In Exchange 2000 Server, each server maintains a Link State table to determine the best route for a message. Because each server has complete information about the routing status from the source to the destination, it generates a loop-free route for the message. Additionally, if no route is available (because of a link failure), the message remains on the source server in a queue until the link is available.

To maintain the Link State tables across the entire messaging system, Exchange tracks one master for each routing group. If the master fails, you can manually set a different server as the master.

Servers receive updated link state information in two ways:

  • Within a routing group, the master updates the other servers over TCP port 691. When the master receives an update from another server, it immediately sends that update to each server in its routing group

  • Within and between routing groups, each server compares link state information with other servers when transferring messages with SMTP. Exchange 2000 Server extends SMTP to include an additional SMTP verb to compare and update link state information. Similarly, Exchange 2000 Server extends the X.400 protocol so that X.400 connectors used as routing group connectors can update this information; thus, as messages flow, the link states are automatically updated. Even if no messages travel over a connector between two routing groups, a periodic poll updates the link state.

Public Folder Affinity

You place your public folder servers into routing groups. A public folder server is a server that maintains public folders locally or maintains replicas of other public folders.

When a MAPI client, such as Outlook in Corporate or Workgroup mode, opens a public folder, the user’s Exchange server processes the request. If the server doesn’t have a replica of the public folder locally, the server refers the client to another server that has a replica. This referral causes a connection to the closest replica, based on the total cost of connectors between the first server and the server with the replica. You can configure a connector to not allow public folder referrals; otherwise, any connector that connects routing groups can make public folder referrals.


Routing and Connectivity in Mixed Mode

Upon installation, Exchange 2000 Server operates in mixed mode. Mixed mode operation allows Exchange 2000 Server and earlier versions of Exchange to coexist as one Exchange organization. There are some topology and routing issues that you need to consider when your organization operates in mixed mode.

Coexistence with Earlier Exchange Servers

In Exchange 2000 Server, the primary message routing protocol is SMTP, although Exchange 2000 Server still uses RPC when communicating with earlier versions of Exchange. Exchange uses the SMTP service included in the Windows 2000 operating system but enhances this service with features to route messages within the Exchange system and to other messaging systems.

In addition, in earlier versions of Exchange, you assign servers to sites according to physical topology and administrative control. With Exchange 2000 Server, you can assign servers to routing groups according to physical topology, and to administrative groups according to administrative control.

If you upgrade an existing Exchange site, the Exchange site becomes a single administrative group and a single routing group, both with the same name as the existing Exchange site. While Exchange coexists with earlier versions in mixed mode, you can create multiple routing groups in an administrative group as long as the servers in the routing groups are members of the administrative group.

For more information about upgrading earlier versions of Exchange, see Chapter 16, “Upgrading and Coexisting.”

Connectivity

When running Exchange 2000 Server in an organization with earlier Exchange sites, ADC matches an Exchange 2000 Routing Group connector to an Exchange 5.5 Site Connector and vice versa. When Exchange 2000 Server uses a Routing Group connector to connect to an Exchange 5.5 server, it automatically uses the RPC communication that the Exchange 5.5 server uses; thus, Exchange 5.5 servers can use Exchange 2000 Routing Group connectors and Exchange 2000 servers can use Exchange 5.5 Site Connectors.

If you create multiple routing groups within an administrative group, the individual routing groups do not appear in the Exchange 5.5 Administrator program. Exchange 5.5 interprets each administrative group, and any routing groups within it, as a single site. For more information about administering Exchange in mixed mode, see Chapter 16, “Upgrading and Coexisting.”

The following illustration shows how Routing Group connectors and a Site Connector provide connectivity in a mixed-mode Exchange organization. The Site Connector is configured on a bridgehead server running Exchange 5.5 in the Exchange 5.5 site. This server interacts with the Routing Group connector in the combined Exchange 5.5 site and administrative group as though it is another Site Connector. Similarly, the Routing Group connector interacts with the Site Connector as though it is a Routing Group connector.

Figure 8.5 Routing in a mixed-mode organization

Both routing groups in the illustration are configured so that no single server acts as bridgehead server; thus, the Routing Group connector applies to the entire routing group. This allows dynamic load balancing among servers in the routing group for incoming and outgoing mail.


Chapter 9 Internet Connectivity

Many of the services that Microsoft Exchange 2000 Server offers can be used over the Internet. If computers running Exchange are connected to the Internet, your users have several options for retrieving their mail from remote locations and your organization can communicate with remote external systems.

Exchange 2000 Server uses the Internet connectivity services that Microsoft Windows 2000 provides. This chapter describes how Exchange uses these services and discusses the security issues that can occur when computers running Exchange are connected to the Internet. This chapter also describes the client options that are available for remote access.


Security Considerations

Messages routed to and from Exchange servers and other external systems travel across your local network and over the Internet. Securing your connections can prevent malicious Internet users from intercepting your organization’s mail and attacking your servers.

You can use one of the following methods for Internet connectivity:

  • Use the SMTP Connector to provide Simple Mail Transfer Protocol (SMTP) e-mail connectivity between your organization and other external systems.

  • Use the SMTP Connector, X.400 Connector, or Routing Group connector to connect Exchange routing groups within your organization over the Internet.

  • Allow Exchange clients to access mailboxes on a computer running Exchange in your organization over the Internet using Internet mail protocols or Outlook Web Access.

Types of Attacks

E-mail systems are susceptible to the following types of attacks.

  • Theft or tampering with data

  • Forgery and mail relaying

  • Denial of service

  • Trojan horses and viruses

Theft or Tampering with Data

Unencrypted traffic that travels on your network or over the Internet can be viewed by applications that sniff packets on your network. Enclosing your internal network is one way to reduce the number of packets that are visible to users on the Internet. You can achieve this type of protection using a network topology that provides a firewall between your LAN and the Internet. Software such as Microsoft Proxy Server can control the access your computers have to the Internet, allowing only authorized traffic through. With this type of network implementation, only outbound packets are visible on the Internet; all internal traffic is protected.

Another way to protect the traffic on your network is to use encryption. Exchange 2000 Server supports Transport Layer Security (TLS) and Secure Sockets Layer (SSL). Exchange also supports Internet Protocol security (IPSec), a transport encryption system in Windows 2000 that automatically encrypts traffic between servers. For more information about TLS, SSL, and IPSec, see the Windows 2000 documentation.

Forgery and Mail Relaying

Exchange 2000 Server has a feature that prevents third parties from relaying mail through your server. Relay control allows you to specify a list of incoming remote IP address and mask pairs with permission to relay mail through your server. Exchange checks an incoming SMTP client’s IP address against the list of IP networks allowed to relay mail. If the client is not allowed to relay mail, only mail addressed to local recipients is allowed.

In addition, you can configure the Exchange server to match incoming SMTP clients against part of a domain name. Each time a message to be submitted through your SMTP virtual server is received, the from address is validated using reverse Domain Name Service (DNS) lookup. Reverse DNS lookup verifies the sender’s domain name and checks your list of approved relay domains. If the address is not authorized to relay mail, the server does not accept the incoming message. For information about enabling SMTP relay control, see the Exchange online documentation.

Internet users that send unsolicited mail can use the domain names of other organizations as the return address. SMTP does not always include verification of the from address in mail to be delivered. This makes it easy for those who wish to impersonate your domain by sending messages on behalf of your domain. Using an SMTP server to submit messages, these malicious Internet users can send hundreds or thousands of messages to users over the Internet using your domain name as the from address. These messages can be traced to your organization, even if the mail was not sent by a user in your organization.

Denial of Service

Another form of attack is denial of service to your users. Malicious Internet users can overwhelm your Exchange servers with SMTP messages or connections to your Internet Message Access Protocol, Version 4rev1 (IMAP4), Post Office Protocol version 3 (POP3), and Network News Transfer Protocol (NNTP) virtual servers. These attacks can debilitate your CPU and clog your virtual servers. Exchange allows you to accept or deny connections to your virtual servers using lists of IP addresses and domain names that you specify. If your organization is continuously bombarded by an IP address or domain, you can explicitly deny access to that IP address or domain. Exchange uses reverse DNS lookup to check this list.

If you believe your virtual servers are being attacked, you can monitor the number of connections the servers are receiving and where they are from. You can also enable logging and monitor your CPU and process usage levels. For more information about monitoring, see the Exchange online documentation.

Trojan Horses and Viruses

With the added convenience of using e-mail attachments come threats of attack to your systems. Trojan horse viruses are the most common viruses to come in contact with your computers through e-mail.

After an e-mail attachment is executed on a computer, the virus can copy itself to the computer and use e-mail to send copies of the virus to other users. Deploying virus detection software can help prevent viruses from infecting your organization.

Firewalls

A firewall prevents unauthorized access to data on servers behind the firewall. Firewall planning is important for organizations setting up a new network and organizations with existing networks.

Using software such as Microsoft Proxy Server, you can route all Internet traffic through a single location and protect servers inside your organization. While this requires more setup and planning than a simple direct Internet connection, it increases security.

You can use a firewall to allow only essential Internet traffic through ports that you specify; for example, you can configure your network to allow only SMTP (port 25) traffic to pass through your firewall, preventing connections on all other ports. You can connect an Exchange server to the Internet with an SMTP virtual server. Your Exchange server can accept connections only on port 25 because the firewall blocks all other ports.

Exchange can operate in a firewall environment; however, there are requirements you need to be aware of to maintain Internet connectivity, specifically with remote clients. Firewalls can filter certain TCP ports or block them entirely. For remote clients and servers to communicate through a firewall, you cannot change or block the port assignments for the various protocols that Exchange supports.

If you do not implement a firewall connection to the Internet, you must consider how this affects server security; all servers running Exchange that are connected to a network with a direct connection to the Internet are exposed to the Internet. For more information about firewalls, see Chapter 13, “System Security.”

Bridgehead Servers

If your organization implements a firewall, you should include bridgehead servers in your deployment planning. For example, you can use a bridgehead server to provide Internet connectivity to a routing group. This scenario is shown in the following illustration.

Figure 9.1 Providing Internet connectivity to a routing group

If you implement the type of routing group shown in this illustration, the bridgehead server is an Exchange server with a connection to the Internet and DNS running. The SMTP connector is installed on this server and provides incoming and outgoing message delivery for your organization over the Internet. The external DNS that your organization exposes to the Internet must list this server as your domain’s mail server. This allows clients on the Internet to connect to your bridgehead server when requesting e-mail for your domain. In this scenario, it is not necessary for every Exchange server to have Internet connectivity. This increases security because only the bridgehead server is exposed to the Internet.

Internet connectivity must exist on the server running Windows 2000. After the server running Windows 2000 has Internet connectivity, you can configure the bridgehead server to handle outgoing and incoming Internet e-mail. In many cases, the Exchange bridgehead server has two separate SMTP virtual servers with two network interface cards: one bound to the internal IP address, and the other bound to the external IP address. The virtual server with the internal IP address allows relaying for clients on other internal IP addresses. The external virtual server allows relaying only for the IP addresses of the internal virtual server. This helps prevent external domains from relaying e-mail from your servers.


Exchange Services Over the Internet

Exchange 2000 Server can offer some of its services over the Internet, provided the appropriate connectivity exists. To establish Internet connectivity, you must have DNS running in your organization in addition to a physical connection to the Internet.

To establish DNS name resolution, you must set up DNS on a Windows 2000 server or point your Windows 2000 servers to your existing DNS. This provides your server with the capability to resolve domain names down to their IP addresses and allows remote servers to do the same. DNS configurations and Internet connectivity make Exchange services such as Outlook Web Access accessible to users over the Internet. For more information about Outlook Web Access, see Chapter 10, “Outlook Web Access.”


Client Options

Users who need remote access to their Exchange e-mail can use IMAP4 and POP3 clients.

IMAP4 is useful as a client for users who need to access e-mail from a remote location. You can use IMAP4 if downloading all e-mail to a specific computer is impractical or if hardware limitations prevent you from using an Outlook client. With an IMAP4 client, users can send and retrieve mail and access multiple mailboxes on an Exchange server. Microsoft Outlook Express can function as a POP3 client and as an IMAP4 client. Exchange 2000 Server supports all IMAP4 clients.

Users who need only basic remote access to their Exchange e-mail can use a POP3 client. Because POP3 clients such as Outlook Express must be online only when retrieving and sending messages, Outlook Express is a convenient option for offline access. Exchange 2000 Server supports all POP3 clients.

For more information about IMAP4 and POP3, see Chapter 4, “Clients and Internet Protocols.”


Virtual Private Networks

Routing and Remote Access for Windows 2000 is an open, extensible platform for routing and internetworking. It offers remote access to organizations in LAN and WAN environments or over the Internet by using secure virtual private network (VPN) connections. VPNs are secure, authenticated links across public or private networks such as the Internet.

The Windows 2000 Remote Access Service (RAS) and Routing and Remote Access Service (RRAS) utilities offer options that remote users can use for dial-up Internet access. These access services work with a method of remote connection called Point-to-Point Tunneling Protocol (PPTP) and an Internet connection to create a VPN.

PPTP is designed to support VPNs. VPNs are less expensive to start up and support than traditional WANs because of Digital Subscriber Line (DSL) and cable modem Internet connections. A VPN eliminates long-distance telephone charges while offering secure connections, mutual authentication, and packet filtering.

After a PPTP server authenticates a remote client, the VPN connection opens. The PPTP session acts as a tunnel through which network packets flow. The packets are encrypted at the sender, travel over the tunnel, and are decrypted at the receiver; for example, an organization can allow remote clients to connect to a corporate network across the Internet using a VPN. Using technologies such as DSL or cable modems, remote users can establish a VPN connection to a corporate network and use the corporate network from a remote location as if they are actually connected.


Chapter 10 Outlook Web Access

Outlook Web Access for Microsoft Exchange 2000 Server provides users access to e-mail, personal calendars, group scheduling, contacts, and collaboration applications by using a Web browser. Outlook Web Access offers cross-platform client access for roaming users, users with limited hardware resources, and users who do not have access to their own PCs. Cross-platform access refers to the capability of Outlook Web Access to allow user access from a variety of client operating systems and Web browsers.

This chapter describes planning and network considerations for deploying Outlook Web Access.


Supported Browsers

Outlook Web Access supports any browser that is fully compliant with the HTML 3.2 and European Computer Manufacturers Association (ECMA) script standards. Because earlier browsers are not fully compliant with these standards, Microsoft recommends using Microsoft Internet Explorer 4.0 or later or Netscape Navigator 4.0 or later. These browsers have been tested with Outlook Web Access. For the best Outlook Web Access user experience, Microsoft recommends using Internet Explorer 5.0, which supports DHTML.

Internet Explorer 5.0

Internet Explorer 5.0 provides a folder hierarchy for displaying public and mailbox folders. This hierarchy is easy to navigate and users can expand or collapse it. Users can also drag and drop items between folders. In addition, rich-text editing provides an environment similar to the familiar Microsoft Outlook client.

For many Outlook Web Access commands, Internet Explorer 5.0 can perform the function instead of sending a request to the server. Internet Explorer 5.0 assumes some of the processing load locally at the client, minimizing traffic between the client and server.

Note Internet Explorer 5.0 can run slowly on computers with limited hardware resources. If you have clients that lack the processing power necessary to run Internet Explorer 5.0, consider using Internet Explorer 4.0.

Other Browsers

Although other supported browsers don’t offer the complete functionality that Internet Explorer 5.0 does, the Outlook Web Access user interface is still more similar to Outlook than in earlier versions of Outlook Web Access. Other browsers now operate in a two-frame mode, with a navigation panel on the left that remains constant. Only the right pane renders pages, which reduces network traffic. These browsers display both public and mailbox folders. Users can move or copy the contents of private folders to other private folders.


Limitations

Outlook Web Access is not a replacement for the full-featured Outlook messaging client. Outlook Web Access does not support the following Outlook features:

  • Offline use

  • Tasks

  • Journal

  • Printing templates

  • Outlook rules

  • Copying between public and mailbox folders

  • Telephony options and user-defined fields when accessing contacts

  • Mail features of spell checking, “Do not deliver before,” and expiration options

  • Reminders and the ability to type and edit directly in Calendar view


Topology Planning

Outlook Web Access is installed by default when you install Exchange. You must decide between a single-server or multiple-server deployment of Outlook Web Access. This decision also affects how you upgrade from earlier versions of Outlook Web Access. For more information about upgrading Outlook Web Access, see Chapter 16, “Upgrading and Coexisting.”

Note There is no longer a check box in the product that enables or disables Outlook Web Access on your Exchange servers. For more information about disabling Outlook Web Access, see the Exchange online documentation.

Single-Server Environment

When you use Outlook Web Access in a single-server environment, clients connect directly to the Exchange server that stores their mailboxes. An exchange virtual root and a public virtual root are added to Internet Information Services (IIS). These virtual roots point to their corresponding directories in Exchange.

Accessing a Mailbox From an Intranet

Users must type the following address in a Web browser to access their mailboxes from within a corporate intranet:

http://servername/exchange/

Servername is the name of the Exchange server and exchange is the virtual root that points to your users’ private folders. By default, when users log on using Internet Explorer 4.0 or Internet Explorer 5.0, the browser reads their Windows logon credentials and Outlook Web Access automatically connects the users to their mailboxes. Netscape Navigator and other browsers prompt users to provide their user aliases and passwords before granting access.

Integrated Windows authentication is enabled in IIS by default. Internet Explorer does not connect automatically if you use an authentication method other than Integrated Windows authentication. For more information about Integrated Windows authentication, see Chapter 4, “Clients and Internet Protocols.”

Note Use simple server names because users type the name of the Exchange server into their browsers each time they use Outlook Web Access.

You can access a mailbox directly by typing the following address in a Web browser:

http://servername/exchange/userid

Userid is the user’s alias. This also works if a user has permission to access another user’s mailbox and the server is using Integrated Windows authentication; for example, user A can type user B’s userid. If user A has permission to access user B’s mailbox, Internet Explorer reads user A’s authentication credentials and connects the user automatically. Netscape Navigator or other browsers prompt the user for authentication.

It is common for one user to give another user permission to see a specific folder in his or her mailbox, such as the calendar. In Exchange, users can access all Outlook Web Access items, such as folders and individual messages and appointments, using a URL address. If another user gives you permission to access his or her calendar, you can access it by typing the following address in a Web browser:

http://servername/exchange/userid/calendar

Userid is the other user’s user name.

Accessing a Mailbox Over the Internet

Users must type the following address in a Web browser to access their mailboxes over the Internet. Append the fully qualified domain name (FQDN) to the server name.

http://servername.domain.com/exchange/

Accessing Public Folders

Users must type the following address in a Web browser to access public folders:

http://servername/public/foldername/

Servername is any Exchange server hosting public folders that the user has permission to access. The server name does not have to be the name of the server on which the user’s mailbox is stored. The foldername is the name of the folder the user wants to access. To go to the root of the public folder hierarchy, the user does not need to type a folder name.

Multiple-Server Environment

When you use Outlook Web Access in a multiple-server environment, consider the following when planning your Outlook Web Access topology. Each consideration is described in detail later in this chapter.

  • Use front-end and back-end architecture for your Exchange servers.

  • Use load balancing software or hardware to efficiently respond to user requests and improve server availability.

Using Front-End and Back-End Architecture

If you are using multiple servers in your organization, Microsoft recommends using front-end and back-end server architecture to deploy Outlook Web Access. With this type of topology, the front-end server sends HTTP requests to a back-end server running Outlook Web Access. First, the front-end server checks Active Directory to determine which back-end server should receive the request.

The primary advantage of front-end and back-end server architecture is that you can define a single namespace for users to access their mailboxes. The alternative to a single namespace is to tell users the name of the server storing their mailbox, as you do in a single-server scenario. This complicates administration and compromises flexibility because each time your organization changes and you move mailboxes to another server, you must inform the users. With a single namespace, you can add and remove servers and move mailboxes from server to server, and users can still use the same URL. Creating a single namespace also ensures that Outlook Web Access remains scalable as your organization grows.

Front-end and back-end server architecture provides an additional advantage for organizations that use Secure Sockets Layer (SSL) encryption. All encryption and decryption processing can be handled by the front-end servers, which improves network performance by removing processing tasks from the back-end servers.

Configuring front-end and back-end architecture for Outlook Web Access requires an HTTP virtual server located under the HTTP protocol in System Manager. The default virtual mail directory is exchange. The hostname you provide for the virtual server is important because it determines the URL that users type to access their mailboxes. The hostname, TCP port, and IP address uniquely identify a virtual server.

Accessing a Mailbox From an Intranet

Users must type the following address in a Web browser to access their mailboxes from within a corporate intranet:

http://hostname/exchange/userid/

Hostname is the host name you assign to the HTTP virtual server and the Domain Name Service (DNS) entry that points to the computer running Outlook Web Access, and userid is the user’s alias. Make sure these names are easy for users to remember.

If you change the name of the virtual server’s virtual mail directory to something other than exchange, the URL is:

http://hostname/maildirectory/userid/

Accessing a Mailbox Over the Internet

Users must type the following address in a Web browser to access their mailboxes over the Internet. Append the FQDN to the host name.

http://hostname.domain.com/exchange/userid/

Accessing Public Folders

In most cases, users must use the public virtual root and type the name of the folder instead of their userid to access a public folder. Users must type the following address in a Web browser to access public folders:

http://hostname.domain.com/public/foldername

Note If the replica of a public folder isn’t on the server the user specifies, the request is redirected to the next available server that has a replica of the folder.

If your organization plans to use a mixed deployment of Exchange 5.5 servers and Exchange 2000 servers, Outlook Web Access users can only access public folders on Exchange 2000 servers. Microsoft recommends that you configure all of your organization’s public folders (or public folders that Exchange 2000 Outlook Web Access users access) to replicate to an Exchange 2000 server. If you don’t configure all your public folders to replicate to an Exchange 2000 server, Outlook Web Access users cannot access Exchange 5.5 public folders.

Using Load Balancing

Load balancing allows multiple servers to handle requests addressed to a single IP address or name. Load balancing has the following advantages:

  • Users need only one URL to access their mailboxes. The load balancing software or hardware determines which server handles user requests.

  • Users are directed to another server if a server running Outlook Web Access stops responding.

    Note The server must have round-robin DNS.

  • Load balancing software or hardware efficiently distributes users across multiple servers, so users do not overload a single server.

One common method of load balancing is round-robin DNS, in which hostname is mapped in the DNS to several front-end servers. If one of those servers stops responding, incoming client requests keep going to the computer that is not responding.

For more reliable load balancing, many organizations use hardware or software solutions. A number of third-party vendors offer load balancing hardware. Microsoft recommends using Network Load Balancing, which is available with Microsoft Windows 2000. For more information, see the Windows 2000 documentation.


Network Security

If Outlook Web Access clients access an Exchange server over an Internet connection, Microsoft recommends protecting the server. A firewall prevents unauthorized access to data on servers behind the firewall.

Microsoft recommends that you implement a firewall for Exchange front-end and back-end servers in one of the following ways. These recommendations are in ascending order: from low security and low maintenance to high security and high maintenance.

  • Place a firewall between the front-end server and the Exchange back-end server.

  • Place a firewall between the client and the front-end server.

  • Use two firewalls — one on either side of the front-end server. This is the most secure deployment.

For a detailed description of each of these firewall scenarios, see Chapter 13, “System Security.”

Roaming Users

If several users share a computer to use Outlook Web Access, Microsoft recommends disabling local caching on the browser. If you do not disable caching, messages a user accessed during the previous Outlook Web Access session can remain on the local disk, making it possible for one user to see another user’s messages. Disabling caching affects Outlook Web Access performance and results in slower response time.

For increased security, Microsoft recommends not using the Save Password feature in Internet Explorer 5.0.

For information about disabling local caching and the Save Password feature, see the user documentation for your Web browser.

Important For security reasons, all Outlook Web Access users should close their browsers after every session. On computers running Windows 95, Windows 98, Windows NT, and Windows 2000, Microsoft recommends logging out after each session.


Chapter 11 Instant Messaging and Presence Monitoring

Microsoft Exchange 2000 Server Instant Messaging Service offers a fast and simple way for users on a TCP/IP network to communicate instantly. Instant Messaging complements e-mail in a way similar to the way telephone service complements postal mail; however, Instant Messaging also provides information about whether your contacts are present and available at their computers when you send a message.

Users can set their availability status to any of the following: Online, Invisible, Busy, Be Right Back, Away, On the Phone, Out to Lunch, or Appear Offline. If you have not used your computer during the last 20 minutes, Instant Messaging Service automatically sets your status to Away.

With Instant Messaging, you can invite more than one online contact to join an Instant Messaging conversation. All messages that you send and receive in an Instant Messaging session appear in a scrolling history pane until you end the session. Instant Messaging works with MSN™ Messenger Hotmail™ contacts also.

This chapter provides an overview of how to install Instant Messaging Service. Further details about Instant Messaging topology, security, installation, configuration, and clients follow the overview. For additional information about specific procedures and settings, see the Exchange online documentation.


Deployment Overview

This section describes the high-level process for deploying Instant Messaging in your environment:

  1. Plan the Instant Messaging network, including its topology and server resources. Determine how many Instant Messaging home servers and Instant Messaging routers you need to support your users (home servers host user accounts and Instant Messaging routers route messages to the home servers).

  2. Establish a naming convention for your Instant Messaging home servers and routers.

  3. Install Instant Messaging Service on every server.

  4. Create Instant Messaging home servers and routers in System Manager using New Virtual Server Wizard.

  5. Create Domain Name System (DNS) resource records, if necessary.

  6. Set the necessary permissions for those administering Instant Messaging.

  7. Enable users to access Instant Messaging. Create new Instant Messaging accounts or enable existing user accounts for Instant Messaging.

  8. Make the Instant Messaging client available to users.


Network Topology

Depending on your organization’s size, security requirements, network connectivity, and business needs, you can implement a variety of Instant Messaging topologies. Factors that determine the topology you choose include:

  • The number and types of servers you need for your users.

  • Whether you need an Instant Messaging system that is connected to the Internet.

  • The type of inbound and outbound security and Internet connectivity you need.

Your topology consists of three fundamental elements: clients, which send and receive instant messages and query presence information; Instant Messaging home servers, which communicate with clients and maintain presence information; and Instant Messaging routers, which send messages between home servers and communicate with the Internet. You organize all of these elements within one or more Instant Messaging domains.

The simplest topology, which consists of clients and one home server, is suitable for pilot deployments, test deployments, or small business production deployments. For example, a small business has a single Instant Messaging server named im.msft.com. This server hosts all Instant Messaging users and acts as the Instant Messaging router in the im.msft.com domain.

The following illustration shows a basic Instant Messaging topology for an educational institution with a moderate number of users and heavy Instant Messaging traffic. Communication occurs between the clients and home servers, between clients and the router, between home servers and the router, and between the router and the Internet. This illustration does not show a firewall or other security measures.

Figure 11.1 Educational institution deployment

Instant Messaging Service relies on Instant Messaging routers and home servers being continuously connected to a WAN and clients logged on to the service being continuously connected to the network through low- or high-bandwidth connections.

Instant Messaging Domains

An Instant Messaging domain is a DNS name that identifies user accounts. Instant Messaging routers answer queries for an Instant Messaging domain and make Instant Messaging available to internal and Internet users. You must associate each Instant Messaging domain with at least one router, which routes messages for the domain.

The number of Instant Messaging domains you need to create corresponds to the number of e-mail domains in your organization. Many organizations have one e-mail domain and consequently, require only one Instant Messaging domain. For example, a company called Northwind Traders uses a single e-mail domain named msft.com. For Northwind Traders, the administrator needs to create only one Instant Messaging domain, im.msft.com.

Multinational companies often maintain separate e-mail domains for each country or region in which they have an office; for example, suppose Northwind Traders has offices in the United States, Japan, and Great Britain, each with its own e-mail domain (us.msft.com, jp.msft.com, and gb.msft.com). The corresponding Instant Messaging domains are im.us.msft.com, im.jp.msft.com, and im.gb.msft.com.

Instant Messaging Routers

An Instant Messaging router is a virtual server that receives messages, determines their destination home server, and forwards or redirects the messages to user accounts on the home server. Instant Messaging routers provide strong security because you can avoid exposing home server names on the Internet.

Because an Instant Messaging router answers queries arriving at only one Instant Messaging domain, at least one Instant Messaging router must exist for each e-mail domain.

The following illustration shows the Instant Messaging topology for an organization with two e-mail domains. Instant Messaging routers from different Instant Messaging domains can communicate with the same home servers. A reverse proxy server exists for each Instant Messaging domain. For more information about proxy servers, see “Security Considerations” later in this chapter.

Figure 11.2 Multiple e-mail domains

You may want to use an Instant Messaging router even if you have only one home server to allow for future expansion, reorganization, or Internet connectivity.

Instant Messaging Home Servers

An Instant Messaging home server is a virtual server that hosts Instant Messaging user accounts and communicates directly with clients to send and deliver instant messages and presence information. Home servers also cache information from the Instant Messaging routers, so the client does not have to communicate with the router often.

The number of Instant Messaging home servers you need depends primarily on the number of users who are concurrently online. If you have fewer than 10,000 concurrent users, you need only one home server to host all Instant Messaging user accounts. If you anticipate more than 10,000 concurrent users, you need two or more home servers and at least one Instant Messaging router.

Note For best performance, Microsoft recommends one Instant Messaging router for every two Instant Messaging home servers. To avoid possible deployment issues, install each virtual server on a separate computer.

When calculating the number of users, consider that an Instant Messaging user is online only when logged on to Instant Messaging. In a typical business, employees log on during the workday and up to 80 percent of users log on during peak hours. In a service provider setting, only 5 to 10 percent of subscribers may log on concurrently.

If you have groups of users separated by low-bandwidth or expensive network connections, you can deploy at least one Instant Messaging home server in each area. For example, suppose an organization has a large number of users in Asia, South America, North America, and Europe. If low-bandwidth or expensive links connect the continents, you can deploy one home server for each continent even though two home servers can accommodate the total number of users.

You can set up your Instant Messaging system’s connection to the Internet at one location. You can centralize all Instant Messaging routers because clients typically communicate with Instant Messaging routers less often than they do with home servers.

The following illustration shows a topology with users dispersed on two continents. In this example, home servers host users in their respective geographical area and automatic client caching of home server information reduces the long-distance bandwidth required between continents. The Instant Messaging routers, proxy server, and firewall can exist in a single location on either continent.

Figure 11.3 Geographically dispersed users

Another common scenario is a company with several small branch offices of 10 to 100 users. Each branch office typically has a continuous, low-bandwidth connection to a WAN. In such cases, although the branch offices may administer their own Exchange servers, the branch offices do not need their own Instant Messaging home server.

This topology is possible because Instant Messaging communications are low-bandwidth, are of short duration, and can succeed over long distances, such as across continents.


Security Considerations

You can enable Instant Messaging with other businesses outside your network, such as Exchange installations that your business partners, suppliers, or customers maintain. If you want to confine Instant Messaging to your intranet, you can place the entire Instant Messaging infrastructure behind a firewall and never expose it to the Internet. If you want Internet connectivity, you can protect the internal Instant Messaging network with inbound and outbound firewalls.

Inbound Internet Connectivity

Instant Messaging routers receive all inbound messages. These are the only servers that are visible from the Internet, so any security measures you implement relate to Instant Messaging routers.

Caution If you want a secure Instant Messaging system, never allow direct Internet connections to home servers.

You can use reverse proxy servers, packet filters, or perimeter networks to secure inbound Instant Messaging traffic.

Important Any method you use to secure inbound traffic must allow HTTP traffic through TCP port 80 to the Instant Messaging routers.

Reverse proxy server You can place an HTTP reverse proxy server between the Internet and the Instant Messaging routers. The reverse proxy server accepts all inbound Instant Messaging traffic and relays it to the Instant Messaging routers. A reverse proxy server is similar to a regular proxy server that you normally use for outbound traffic, except that it relays connection requests from the outside your network.

The following illustration shows a reverse proxy server handling all inbound traffic to Instant Messaging routers.

Figure 11.4 Reverse proxy server

Packet filters A packet filter examines inbound TCP/IP traffic and allows only packets that meet certain criteria, such those with a specific IP address or port number, to pass through.

Perimeter Network or Demilitarized Zone (DMZ) A perimeter network is an area within a network that has limited external connectivity. If you deploy Instant Messaging in an organization with a perimeter network, you place the Instant Messaging routers inside the perimeter network.

If you use a perimeter network for the topology in figure 11.4, the Instant Messaging routers exist inside the perimeter network and the proxy servers form the outside boundary of the perimeter network.

Outbound Internet Connectivity

If you enable Internet connectivity for Instant Messaging, you can secure outbound communication with HTTP proxy servers or Winsock proxies.

  • HTTP proxy servers that you use for Internet Web access are also appropriate for Microsoft Instant Messaging. Because Instant Messaging clients use the proxy settings in Internet Explorer, ensure that Internet Explorer clients bypass proxy servers when communicating with Instant Messaging servers. For more information about bypassing proxy servers, see “Proxy Auto-Detection and Exclusion” later in this chapter.

  • Winsock proxies are transparent to client computers, so no special configuration is necessary.

Instant Messaging does not support proxy servers between clients and their home servers or users logging on from outside a network secured by a firewall.

  • Home servers must be able to open connections to clients at any time, which cannot occur if firewalls separate clients from their home servers; thus, an ISP deploying Instant Messaging cannot support users logging on from external networks with firewalls.

  • Users cannot log on to Instant Messaging accounts from outside a firewall unless they use Digest authentication. NTLM protocol authentication requires that users log on from within the network. Remote users can access the network through Remote Access Service (RAS) or Point-to-Point Tunneling Protocol (PPTP). For information about virtual private networks (VPN), see the Windows 2000 documentation.

Proxy Auto-Detection and Exclusion

If the Instant Messaging servers in an organization have fully qualified domain names such as im.msft.com, clients must determine whether to connect to the server directly or through a proxy server. If you use NTLM protocol for authentication, clients must connect directly to home servers. Although clients can connect to Instant Messaging routers with or without a proxy server, connecting through a proxy server takes longer and needlessly consumes resources required for Web access.

The Instant Messaging client relies on Microsoft Internet Explorer 5.0 to determine whether a proxy server is necessary. By default, if a host name contains a fully qualified domain name instead of a WINS address such as IMNWTRADERS1, Internet Explorer connects through a proxy server. Therefore, use WINS addresses for host names to ensure that clients bypass proxy servers.

Consider the example in figure 11.2; if Northwind Traders wants user connections to its home servers (imhome1, imhome2, and imhome3) and routers (im.us.msft.com and im.jp.msft.com) to bypass proxy servers, browsers must exclude the names im.us.msft.com and im.jp.msft.com using one of the following methods:

  • Internet Explorer can use Web Proxy Auto-Detect (WPAD) to bypass the proxy server for specific addresses. This requires no user involvement if you configure these settings for users automatically.

  • Internet Explorer also supports a routing script that is available from a URL located anywhere on your intranet. Users can set the location of the routing script manually, or you can use other Internet Explorer configuration tools. For information about Internet Explorer configuration, see the Microsoft Internet Explorer 5 Resource Kit, which is available from Microsoft Press.

  • Users can type the names of Instant Messaging servers in their Internet Explorer proxy exclusion list. To add names to this list, click Tools, and then click Internet Options. Click the Connections tab, click LAN Settings, and click Advanced. Type the names in Exceptions.


Naming Conventions

Establish a consistent and intuitive naming convention for your Instant Messaging domains, home servers, routers, and user addresses. For information about characters that you cannot use in names, see Appendix B, “Naming Convention Restrictions.”

Naming Instant Messaging Domains and Routers

Microsoft recommends that Instant Messaging domains correspond with e-mail domains. For example, users with an e-mail address ending in @msft.com belong to the Instant Messaging domain im.msft.com. With this convention, users can derive Instant Messaging addresses from existing e-mail addresses. For example, a user can use an existing Simple Mail Transfer Protocol (SMTP) address, someone@msft.com, or an extended Instant Messaging address, someone@im.msft.com, to communicate with Someone.

Adding the prefix im. to the e-mail domain name allows users outside your organization to infer the extended Instant Messaging addresses from SMTP e-mail addresses. If multiple e-mail addresses exist for users, use the domain of the primary or external e-mail address.

Note For test deployments, the Instant Messaging domain need not correspond to an e-mail domain.

When you set up an Instant Messaging virtual server, the Instant Messaging router takes the DNS name of the Instant Messaging domain that it supports; for example, im.msft.com. This name is usually different than the Windows computer name of the physical server.

Naming Instant Messaging Home Servers

When naming home servers, you should use the WINS name of the computer on which you install the home server.

Alternatively, you can use a fully qualified domain name (FQDN) for each home server name, but if the FQDN is different from the full computer name, you must also create a DNS A record for each home server.

In addition, if you use FQDNs, you must ensure that Internet Explorer bypasses your proxy server. For more information, see “Proxy Auto-Detection and Exclusion” earlier in this chapter.

Instant Messaging User Addresses

Instant Messaging Service identifies users with unique URL addresses. Because users are familiar with SMTP e-mail addresses, Instant Messaging supports SMTP Instant Messaging addresses.

For example, a user whose SMTP e-mail address is someone@microsoft.com is identified with the URL http://im.microsoft.com/instmsg/aliases/someone/; however, users refer to this person by the Instant Messaging address someone@microsoft.com. Depending on how you name your Instant Messaging domain and configure DNS, you may need to use a more fully qualified Instant Messaging address, such as someone@im.microsoft.com.

DNS SRV Record

Instant Messaging uses a DNS service location resource (SRV) record to identify the host names for other services. For example, suppose Bob in the microsoft.com domain wants to use Instant Messaging to communicate with a colleague whose e-mail address is salman@msft.com. Bob adds the SMTP address salman@msft.com to his Instant Messaging contact list. Bob’s client performs an SRV lookup at the msft.com DNS zone for the RVP service, and learns that the host for Instant Messaging Service in this zone is im.msft.com. Bob’s client then constructs the Instant Messaging URL http://im.msft.com/instmsg/aliases/salman. In this way, Instant Messaging uses the SRV record to construct an Instant Messaging address from an e-mail address.

Default Host Name

When an organization limits DNS queries to external hosts, it is not possible to perform SRV lookups on external hosts. If an SRV lookup fails, the Instant Messaging client uses the Instant Messaging domain that is the same as the domain the user entered as part of the Instant Messaging address.

For example, suppose Alice in the airlines-10.com domain wants to add salman@msft.com to her contact list. If airlines-10.com limits DNS lookups on external hosts, Alice’s client cannot perform the SRV lookup for the msft.com zone. To add Salman to her contact list, Alice must use the fully qualified Instant Messaging address salman@im.msft.com. Alice’s client cannot perform the SRV lookup on the host, but the client uses im.msft.com as the Instant Messaging domain and uses that domain name to construct the URL.


Installation and Configuration

This section explains the process for installing and configuring Instant Messaging Service. Depending on the needs of your organization, you can consider deploying Instant Messaging for small groups of users at a time. For detailed information about configuration and settings, see the Exchange online documentation.

Software Requirements

You must install the following software on each server before you install Instant Messaging Service:

  • Microsoft Windows 2000 Advanced Server. Specifically, the server should be a member server of a Windows 2000 Server domain. (You can install Instant Messaging Service on a domain controller, although you would not typically do so.)

  • IIS. IIS is installed with Windows 2000 Server. Instant Messaging Service uses the IIS logging and HTTP services.

Installing Instant Messaging Service

Instant Messaging Service requires a minimum installation of Exchange 2000 Server. To install Exchange, run Exchange Setup from the Exchange 2000 Server compact disc.

In Exchange Setup, select Microsoft Exchange, Microsoft Exchange System Management Tools, and Microsoft Exchange Instant Messaging Services in the Component Selection screen.

Note You must install Microsoft Exchange Messaging and Collaboration Services on at least one server in the Exchange organization.

For detailed information about installing Exchange and Exchange Setup, see Chapter 19, “Installing Exchange.”

Configuring DNS

You must create DNS A records for any FQDNs you create for Instant Messaging servers. An A record is a DNS resource record that matches a server’s host name to its IP address.

Organizations typically maintain separate DNS servers for resolving internal and external addresses; for example, the host im.msft.com may have a different IP address depending on whether the DNS query originates inside or outside the corporate intranet.

If you maintain separate DNS servers for internal and external addresses and do not use HTTP reverse proxy servers, both internal and external DNS A records must refer to the Instant Messaging routers.

If you use HTTP reverse proxy servers, external queries must pass through the reverse proxy servers; therefore, external DNS A records must refer to the reverse proxy server, and internal DNS A records for the same fully qualified domain names must refer directly to the Instant Messaging routers.

If you use DNS SRV records to allow users to use SMTP Instant Messaging addresses, each DNS zone containing an e-mail domain must have a DNS SRV record that refers to the fully qualified host name for that zone’s Instant Messaging domain. For more information about SRV records, see “DNS SRV Record” earlier in this chapter and see the Exchange online documentation.

Setting Administrative Permissions

To configure and manage Instant Messaging Service, you must have the following permissions:

  • To manage Instant Messaging users, you must be a member of the Domain Admins security group for the domain that hosts the users.

  • To manage global Instant Messaging settings, such as firewall topology, proxy server configuration, and Instant Messaging home servers and routers in your organization, you must also be a member of the Exchange Admins security group.

Setting Alternate Authentication

NTLM protocol is the default method of authenticating Instant Messaging users. You can also use Digest authentication; however, to use Digest authentication you must enable Instant Messaging Service to retrieve unencrypted user passwords from Active Directory. To do this, you must change the domain controller’s password policy to store the passwords in a reversible, encrypted format.

Note Any users whose accounts you create before changing the password policy must reset their passwords.

For more information about password policy, see the Exchange online documentation.


Client Requirements

Instant Messaging users must have computers with Intel Pentium or Pentium-compatible processors. No version of the client is currently available for Digital Alpha computers. Instant Messaging users must have computers running Windows 95 or later, Windows NT 4.0 Server or later, or Windows NT 4.0 Workstation.

Users who want to send and receive instant messages need the following software:

  • Internet Explorer version 5.0, which can be downloaded from http://www.microsoft.com/

  • Microsoft Winsock 2.0 (if users use Instant Messaging outside your Exchange organization)

    Note Winsock 2.0 must be installed on computers running Windows 95. Install the Windows Socket 2 Update from http://www.microsoft.com/windows95/.

  • Exchange Instant Messaging client, which is available from the \Instmsg\I386\Client directory on the Exchange compact disc

After you install Instant Messaging Service, notify your users that the service is available and tell them how to get the software they need.


Chapter 12 Chat Service

Microsoft Exchange 2000 Chat Service furnishes organizations of almost any size with an informal and immediate means of communication. Although the basic version of this service imposes almost no restrictions on users, optional controls protect chat users and servers.

Chat Service is based on Internet Relay Chat (IRC), a client-server protocol that supports real-time conversation between two or more users over a TCP/IP network. Chat Service also supports extended IRC (IRCX), which is a set of extensions developed by Microsoft that enhance the functionality of the IRC protocol and add several new commands you can use to manage users and channels on a chat server.

A chat community is a set of users and channels (chat rooms) that are configured for an instance of Chat Service. You can customize each chat community as a virtual entity with its own administrative controls.

This chapter describes the process for planning, installing, and configuring Chat Service and chat communities in your organization. For specific information about upgrading your existing Exchange Chat Service, see Chapter 17, “Upgrading and Coexisting.”


Deployment Overview

The following steps outline the tasks you need to perform to deploy Chat Service:

  1. Plan chat communities, including required network and server resources.

  2. Establish a naming convention for your chat communities and channels (chat rooms).

  3. Install Chat Service.

  4. Upgrade existing Exchange 5.5 Chat Service (Service Pack 3 or later), if necessary.

  5. Configure the chat community on the server.

  6. Create registered channels and if necessary, user bans and classes.

  7. Grant administrative permissions. Give administrative access (Sysop and Administrator) to selected members of your organization.

  8. Make chat client software available to users.


Topology and Resource Planning

Issues to consider when planning your Chat Service deployment include how to distribute chat communities across servers, how to plan for and monitor the number of users you anticipate, and how to name your communities and channels.

If you connect your Chat Service to the Internet and your intranet is protected by a firewall, you can install the service on computers that are outside the firewall. This is necessary for service providers and organizations that provide customer service over the Internet. Be certain to take security precautions to protect your servers.

Community Topology

Chat Service supports the following topologies for multiple chat communities:

Chat Communities Running On One Server

For this scenario, you install Chat Service software on one server. Most organizations can use this type of single-server deployment. Consider setting up two or more chat communities on a server. If one community is unavailable or fails, another chat community can handle users until the failed community is working again.

To run more than one chat community on a single server, the IP address or port number settings must be different for each community; for example, you can have one community on port 6667 and another on port 6668, but both communities can use the same IP address. Conversely, both communities can be hosted on port 6667 if they use different IP addresses.

The following illustration shows two chat communities on the same server. Both communities are using the default port 6667, but each community has a separate IP address.

Figure 12.1 Two chat communities on a server

Chat Communities Running On Multiple Servers

To handle very large numbers of users, you can create a separate instance of a chat community, each with a separate user list and channel list, on more than one server. Exchange 2000 Chat Service doesn’t support a single chat community running on multiple servers.

Capacity Planning

Use the information in this section to plan for the number of chat users you anticipate. Although performance varies depending on your hardware and number of users, Chat Service running on a Pentium 500 MHz computer with four microprocessors and 512 MB of RAM is capable of handling up to 20,000 users.

Chat Communities

You can set the maximum number of connections for a chat community to maintain good performance. If identical chat communities exist on multiple servers, you can set the limit independently for each server.

Channels

Set the member limit for each registered channel to accommodate anticipated use of the channel. If you allow dynamic channels in a chat community, you can limit the number of users who can join a dynamic channel. The default limit for dynamic channels is 25 users.

Performance Considerations

To make sure your Chat Service meets your needs, periodically examine the Chat Service performance counters to ensure that your hardware has sufficient processing power and memory to adequately handle Chat Service. For further information about monitoring Chat Service performance, refer to the Exchange online documentation.

Naming Conventions

Establish a consistent and intuitive naming convention for your chat communities and channels.

Chat Communities Name your chat community to reflect the owner, users, or purpose of the community; for example, Finance-net or Corp-Support. Do not use spaces in the chat community name. For additional chat community naming restrictions, see Appendix B, “Naming Convention Restrictions.”

Channels Name your channels using the standard IRC channel naming convention. A channel name can contain up to 200 ASCII characters or 100 double-byte characters. You can use any character except null, bell, carriage return, line feed, space, comma, and backslash. Also, the name must not end with a number because of potential conflicts with cloned channels.

In addition, you must precede each channel name with a one or two character prefix that identifies the channel type.

Prefix | Channel Type
#, & | IRC channel
%#, %& | IRCX channel

Extended channels are visible only to clients supporting the IRCX protocol, such as Microsoft Chat version 2.5, and have names that contain UTF-8 encoded Unicode characters.


Installation and Configuration

Chat Service is installed as a part of Exchange Setup. For more information about upgrading an existing Chat Service, see Chapter 16, “Upgrading and Coexisting.”

Software Requirements

You must install the following software before you install Chat Service:

  • Microsoft Windows 2000 Server. Specifically, you must configure the computer as a member of a Windows 2000 Server domain or as a domain controller.

  • Exchange 2000 Server. Microsoft Exchange Messaging and Collaboration Services must be installed on at least one server in the same domain as Chat Service.

  • System Manager. You must install System Manager on computers you use to administer Chat Service.

Installing Chat Service

Chat Service requires a minimum installation of Exchange 2000 Server. To install Exchange, run Exchange Setup from the Exchange 2000 Server compact disc.

To install Chat Service, complete the following steps:

In Exchange Server Setup, on the Component Selection screen, select Microsoft Exchange, Microsoft Exchange System Management Tools, and Microsoft Exchange Chat Services.

For detailed information about installing Exchange and Exchange Setup, see Chapter 19, “Installing Exchange.”

Configuring Chat Service

You can use System Manager to create and configure chat communities and channels, set channel topics and properties, and set access restrictions for each chat community. You can create additional custom administrative tools by using the Chat Service Administration COM interfaces.

For more information about configuring Chat Service, see the Exchange online documentation.

Configuring a Chat Community

Before you can configure and manage Chat Service, you must be a member of the Exchange Admins security group.

You can use the default community and modify it to meet your needs or you can create a new community in System Manager. For most deployments, the configuration settings for the default community are sufficient.

Note If you create two or more chat communities and host them on the same physical server, verify that you assign a different client IP address or a different TCP port to each one.

Creating Channels

You can create one or more registered channels in a chat community. You create a registered channel with a predefined configuration, an established topic, or a limited number of users. You can also configure registered channels to start automatically each time Chat Service starts.

You can create moderated and auditorium channels when necessary for chat events by using the channel Modes tab:

  • You can use moderated channels for small chat events like meetings or training. A chat user can’t post messages to a moderated channel, but the user can see messages that the speakers post; however, a speaker who moderates a channel can grant speaking permission to specific users.

  • You can use auditorium channels for large chat events like celebrity chats. Once again, a chat user can’t post messages to an auditorium channel, but the user can see messages that the speakers post. Only the speakers, as channel hosts, are notified when event participants join or leave an auditorium channel.

As an administrator, you can also decide whether to allow users with sysop permissions to create dynamic channels on a chat community (sysop permissions are described later in this chapter). You can create a dynamic channel while using a chat client. A dynamic channel disappears after all users leave the channel.

For further information about registered channels and channel modes, refer to the Exchange online documentation.


Security and Access Control

When you first install Chat Service, it imposes no logon restrictions for chat users. Any user can establish an anonymous client connection with the chat server; however, you can provide security for chat communities by restricting user access. This can be done in a variety of ways.

User Authentication

As an administrator, you can set up secure chat communities and require each participant to authenticate, thereby preventing unauthorized members from sending messages to the community. In this case, users must log on to the server from a chat client using a clear-text (unencrypted) password or Integrated Windows authentication. For further information about setting up authentication, see the Exchange online documentation.

User and Administrative Access

After you configure authentication, you can configure user and administrative access to a chat community. You can assign the following permissions on the community’s Security tab :

User A user can log on to the community from a chat client as an authenticated member. Assign this the permission level to those who want to use the chat community.

Sysop Sysops use a chat client to monitor and control a server’s dynamic channels in addition to any registered channels to which they have access. Assign Sysop permissions to those whom you want to be able to administer the service using chat protocol commands (MODE, ACCESS, KILL, and so on) from a chat client.

Important Sysops have no special permissions in a channel unless you select Chat Sysop joins as owner in the Modes tab of the channel.

Administrator Administrators become the owners of any channels they join and cannot be denied access to or removed from any channel. Administrators can also use administrative commands not accessible to other users and can override any action a sysop initiates, such as a user ban.

Using Bans to Restrict User Access

A ban allows you to restrict users with a specific user name or nickname, or from a specific domain from participating in a chat community. A ban can be in effect always or only during a specific time of day. Because you define bans for specific chat communities, a user ban in one chat community does not affect other communities.

Using User Class to Protect Chat Servers and Users

You can create a user class to impose restrictions on chat users. A user class is a logical collection of chat users whose membership in the class is based on one or more of the following criteria:

  • Whether the user is logged on to the service as an authenticated user or as an anonymous user

  • The user’s identity mask (for example, domain, nickname, user name, or domain or IP address)

  • IP address and subnet mask

To determine whether a user who is logging on belongs to a class, Chat Service searches the existing classes in alphanumeric order. If a user matches any of the selection criteria associated with a class, Chat Service adds the user to that class and imposes the restrictions of the class on the user.

A user class allows you to protect a chat server and its users from flooding and other types of attacks. With user classes, you can control a user’s ability to log on to the server, create or join dynamic channels, or become a channel owner or host. You can also regulate the processing of messages from members of a user class, limit the number and type of channels they can create on the server, and set up an attack protection mechanism.

Controlling User Access

Because security and access to chat communities is very important, this section summarizes the methods you can use to control user access to a registered channel:

  • Limit the number of client connections from anonymous users.

  • Restrict connections to allow only authenticated users; users must log on to the server using a clear-text password or Integrated Windows authentication.

  • Limit the number of client connections from authenticated users.

  • Require a password to join a channel; only the designated owner, channel host, or users who know the password can join a channel.

  • Assign joining restrictions to the channel; you can limit access to a channel to authenticated users or only those who are invited.

  • Restrict connections to allow only anonymous clients; no authenticated user can log on to the server.

  • Use bans and classes to restrict and control user access to the server. For example, you can prevent users from joining dynamic channels by making them members of a user class that cannot join dynamic channels.

For more information about controlling user access, see the Exchange online documentation.


Chat Clients

Chat Service is fully compatible with many chat clients, including the following:

  • PIRCH, mIRC, and other clients that use the IRC protocol. Shareware versions of these two clients and others are available on the Internet.

  • Microsoft Chat (also known as Comic Chat) version 2.1 and later, which uses IRCX, Microsoft’s proposed extensions to the standard IRC protocol. For more information about IRCX, see the Internet draft “Extensions to the Internet Relay Chat Protocol (IRCX).”

As an administrator, you should make chat client software available to users and provide instructions about logging on to the service. If you are hosting more than one chat community, give users the TCP port number of each community.

Microsoft also provides Chat SDK version 2.0, a collection of ActiveX® and Java controls that allow you to embed chat interfaces in a Web page. You can download Chat SDK 2.0 from http://msdn.microsoft.com/downloads.


Chapter 13 System Security

This chapter touches on several important aspects of security. Because every organization’s architecture and security requirements are different, one or several of the approaches this chapter discusses may apply to your organization. Some design considerations have implications for your organization’s security model, so read this chapter in conjunction with your overall planning process.

This chapter first discusses basic security concepts and fundamental practices to keep your Microsoft Exchange 2000 Server organization secure. It then introduces Microsoft Windows 2000 technologies that provide user authentication and application security. Several examples illustrate firewall technology and overall network security as it applies to Exchange. Finally, this chapter covers message security features, including encryption, signing, and Key Management Services.


Security Overview

As your messaging system grows and technology evolves, successfully guarding your organization against information theft and corruption depends on three security concepts: availability, confidentiality, and integrity.

Availability The resources on your network must always be accessible to people in your organization. This applies to everything from servers and services to the information stored in a particular database. An unauthorized user can compromise your system and fill mailboxes with unsolicited commercial e-mail or disable large portions of your intranet. Limiting the number of entry points to your network and restricting the number of people with access to these resources are two key methods for ensuring that your resources remain available.

Confidentiality Most organizations must provide information to some individuals while blocking access for everyone else. Only users who need to view sensitive information are authorized to do so. Encryption ensures confidentiality by rendering intercepted information unreadable. Confidentiality can also mean blocking outsiders who are trying to get in, and controlling access to information among individuals or groups within your organization; for example, only employees in the legal department can see legal documents, whereas only a group of designated executives can view salary information.

Integrity Data integrity methods ensure that no one can alter or tamper with information, whether maliciously or accidentally, as it travels between senders and recipients. Digital signatures validate a user’s identity, so that message recipients can be sure that message senders are who they say they are. Digital signatures also provide strong evidence that the message has not been altered since it was signed.

Network Security vs. Message Security

Traditionally, network security involves protecting an organization against threats from outside. While firewalls and remote authentication are important for maintaining system integrity (these are discussed later in this chapter), it is also important for you to take preventative steps inside the organization. Firewalls can’t protect against such things as an unauthorized employee looking at, modifying, or deleting sensitive e-mail or documents. Message security includes certificates and Exchange Key Management Service, which are vital for both internal and external security.

Secure Administration Design

Permissions, policies, and administrative groups are three Exchange features that you need to be aware of, particularly when planning security. Careful implementation of permissions, policies, and administrative groups makes administering and updating your organization’s security measures easier.

Permissions

Within an Exchange organization, permissions control access to resources. A permission provides specific authorization to perform an action. Permissions are a key component of Exchange administration, and because they grant and deny access throughout an entire organization, they should be one of your first security considerations.

Delegation Wizard is an Exchange 2000 tool that simplifies assigning permissions to Exchange objects. Rather than assign permission to administrators individually, you can create groups of administrators and use Delegation Wizard to assign a set of administrative permissions to each group. Creating security groups with descriptive names and adding specific users to those groups simplify managing permissions across the organization.

If you need more control over permissions than Delegation Wizard provides, you can first use Delegation Wizard, then administer Active Directory permissions directly on Exchange objects by using System Manager. A security descriptor manages all security information, including the permissions you associate with an object. For more information about security descriptors, see the Windows 2000 documentation. In addition to these Windows 2000 security descriptors, Exchange 2000 Server features extended permissions. Extended permissions are specific to Exchange objects that are added to the standard Active Directory object schema. Permissions are also inheritable; all objects in a hierarchy inherit the same permissions as the objects above them.

Applying permissions at the highest possible level of the object hierarchy maximizes inheritance of permissions throughout the hierarchy. If you’re planning a folder hierarchy of six tiers, it’s easier to set the permissions at the top level and have each new folder inherit them than it is to build the hierarchy and then set each folder’s permissions manually.

In Exchange 5.5, if you assign a role to a user or group, that user or group has the same permissions for all objects in that container. In Exchange 2000, you can specify user and group access by object class; for example, a user might have access to protocols and mailbox stores for a particular server, but not to security settings. If you have resources that require separate permissions, you can assign permissions to implement security policies that are as complex as you need them to be.

Policies

A policy is a collection of configuration settings that you can apply across any number of objects. Making a change in a policy enacts that change on every object to which the policy applies. System Policies affect server-side objects such as mailbox stores, public folder stores, and the servers themselves. To apply changes to System Policies, you must have permissions on all applicable objects beneath the System Policy objects. Recipient Policies affect objects such as users and groups. Because policies can cause changes across dozens or even hundreds of servers in your organization, they play an important role in Exchange security.

Administrative Groups

Administrative groups are collections of Exchange servers and configuration objects that you group together for a common administrative purpose. If your organization has two distinct sets of administrators who manage two different sets of Exchange servers, you can create an administrative group for each set. Grouping objects that are related allows you to administer them collectively rather than individually. Active Directory propagates permissions and other settings that you define for an administrative group to all users and objects that you place in the group.

For more information about policies and administrative groups, see Chapter 6, “Administration.”


Windows 2000 Security Services

Exchange runs as a set of services on Windows 2000 Server. As an administrator, you can use one or more of the Windows 2000 Server security options available to protect your Exchange organization. This section describes some basic Windows 2000 concepts that comprise fundamental security for all services running on Windows 2000 Server.

The information here is intended as a guide. If you decide to use one or more of these Windows 2000 features to secure your system, see the Windows 2000 Server documentation and the white papers available at http://www.microsoft.com/security/ for more information.

User Accounts and Authentication

Before users or processes can access Exchange, they must log on to Windows 2000 Server by supplying a unique user name and password. The system must authenticate this logon information. When a user logs on, Windows 2000 Server identifies a security context. The security context determines the extent of the user’s access to system services.

A user logs on only once to gain access to Windows and Exchange. This is in contrast to other security models, which require separate passwords for different resources, including printers, file servers, and messaging systems. Pass-through authentication makes it possible for users to access domains in which they do not have accounts.

Each Exchange server is a member of a Windows 2000 Server domain. To enable users to access the entire network, you can establish trust relationships between domains. Domains with trust relationships share account information and validate rights and permissions. In a trust relationship, one domain (the trusting domain) trusts the other (the trusted domain). You can give users from the trusted domain rights and permissions to objects in the trusting domain as though the users are members of the trusting domain.

Groups

You can organize user accounts into groups, which makes granting permissions easier. You perform only one action to give permissions to a group of users; for example, if a group of administrative assistants needs to access the same mailbox, you can define a group called Admin Assistants and create a mailbox called Assistants. You can then give the Admin Assistants group permission to use the Assistants mailbox.

Windows 2000 provides built-in global, local, and universal groups, which you can customize. Adding a user to a predefined group provides the user with all of the access rights of that group. Changing the access rights of the group automatically changes the rights of all group members. Although you can define custom groups, use built-in groups whenever possible. For more information about predefined groups, see the Windows 2000 Server documentation.

Auditing

Auditing refers to the system’s ability to detect breaches in security. Because Exchange is a Windows 2000 service, it uses the auditing capabilities of the operating system. Windows 2000 Server can track significant events related to the operating system itself, such as logon activities and changes to system files. Exchange administrators do not need permission to administer Windows 2000 Server use its auditing capabilities.

Security Configuration Tool Set

The Security Templates snap-in and the Security Configuration and Analysis snap-in provide tools for security related administrative tasks. Together, these are called the Security Configuration Tool Set. You can use this set of tools to configure and analyze security on one or more computers running Windows 2000 Server.

The Security Configuration and Analysis snap-in can configure and analyze the following items:

Account Policies | System Services
Local Policies | Registry
Event Log | File System
Restricted Groups |

The Security Templates snap-in allows you to use the defaults or tailor security settings to suit your needs for each of these items.

Group Policy

The security configurations you define and maintain with the Security Configuration Tool Set create local security policies for individual computers. By integrating these policies with Windows 2000 Group Policy, your security policies propagate to every domain and organizational unit in Active Directory.

Administering security through Windows 2000 Group Policy allows you to set policies for Exchange and have Windows 2000 apply the policies on clients. Similarly, you can place all computer accounts for your Exchange servers in an organizational unit and then define security policies for all your servers by setting policies once at the organization level.

Note You can apply Group Policy to Windows 2000 Active Directory-based domains only.

For more information about implementing Group Policy in Windows 2000 Server domains, see the Windows 2000 Server documentation.

Internet Protocol Security

The Internet Engineering Task Force (IETF) developed Internet Protocol security (IPSec), which defines encryption and signature requirements for IP packets between a source computer and various destination computers. IPSec provides network-level authentication, data integrity, and encryption for complete end-to-end network security.

Packets containing data are encrypted with keys known only to the sending and receiving computers, protecting the data as it travels across the network. IPSec is transparent to users and provides Windows 2000 security safeguards for all applications across your network. Most importantly, it provides security for all TCP/IP communications on both sides of your firewall.

Kerberos V5 Authentication Protocol

Kerberos V5 is an authentication protocol developed at MIT in the late 1980s. Kerberos V5 authentication is the default for network authentication on computers running Windows 2000 Server and Windows 2000 Professional. In Windows NT 4.0, NTLM protocol is the default for network authentication.

Note Windows 2000 supports NTLM protocol for compatibility with earlier clients and servers.

For more information about Kerberos V5 authentication, see Chapter 4, “Clients and Internet Protocols.”


Network Security

One of the greatest benefits of Exchange is the close integration with the Internet that it can provide; however, this versatility increases your need to protect your Exchange servers from unauthorized access. One simple and effective way to defend your system against unauthorized access is to use strong passwords.

This section describes additional methods of securing your messaging system, including using authentication, monitoring protocols, building firewalls, protecting against viruses, and securing Simple Mail Transfer Protocol (SMTP) virtual servers.

Authentication

In this context, authentication is the process a virtual server uses to determine whether to grant a user permission to connect to the system. For a client to log on to Exchange, at least one of the authentication methods that the client supports must be enabled on the server. You can apply the following types of authentication to your virtual servers:

  • Anonymous

  • Basic (clear-text)

  • Basic over Secure Sockets Layer (SSL)

  • Integrated Windows authentication

Note NTLM protocol is enabled if you have a mixed-mode Windows 2000 deployment, while Kerberos V5 is enabled in a native-mode Windows 2000 environment.

Digest authentication is also available in Internet Information Services (IIS) for HTTP. Digest authentication is similar to Basic authentication but uses hash values to encrypt authentication data during transmission. For more information about Digest authentication, see the IIS online documentation.

For more information about authentication methods, see Chapter 4, “Clients and Internet Protocols.”

Protocol Logging

IIS works in conjunction with Exchange to support a number of Internet protocols in your messaging system. IIS includes a utility for logging commands made on SMTP, Network News Transfer Protocol (NNTP), and HTTP virtual servers. Protocol logs track the commands the virtual server receives from clients. In combination with Windows 2000 Event Logs, you can use protocol logging to audit users and commands throughout your intranet as a further precautionary and preventative measure.

Firewalls

  • Firewalls remain one of the best ways to protect your system from attack by users on the Internet. A firewall separates your LAN or intranet from the Internet, letting authorized users pass through while blocking trespassers. Firewalls can also analyze traffic between your network and the Internet.

Firewall Architecture

This section contains three examples of common firewall deployments using an Outlook Web Access front-end and back-end architecture; however, these firewall configurations are not limited to Outlook Web Access. These examples describe what happens when a remote client attempts to contact your organization over the Internet. Keep in mind that the more security your firewall deployment provides, the more maintenance and administration it requires.

Firewall Between Front-End Server and Back-End Server

A firewall between the front-end server and the back-end server is practical if you already have several Web-enabled applications deployed on the front-end server. But keep in mind that while the back-end Exchange server and Windows 2000 domain controllers are protected in this configuration, your front-end server is exposed to the Internet; thus, anyone can access the front-end server without going through the firewall. The front-end server accepts authorized requests from clients and sends the requests through the firewall to the appropriate back-end server.

In the following illustration, the front-end server receives an HTTP request from an Internet client over port 80, and then sends an Lightweight Directory Access Protocol (LDAP) query through the firewall to Active Directory over port 3268. Once Active Directory identifies the appropriate back-end server, the front-end and back-end servers communicate over HTTP port 80. You may want clients to use SSL encryption to secure transmissions between the client and the front-end server, in which case they communicate over port 443, the secure HTTP port. Clients can also use port 80 and port 443. Anytime you’re passing data over the Internet, SSL encryption is recommended, provided that your front-end servers can handle the extra processing load that SSL encryption requires.

Note Although LDAP requests are normally passed through port 389 to a domain controller, this allows a client to search only within the local domain. Queries to the global catalog server over port 3268 allow clients to search within the entire Windows 2000 forest.

Figure 13.1 Firewall between front-end and back-end servers

If you are running a native Windows 2000 environment that includes Windows 2000 Professional clients, you can use Kerberos V5 authentication. If you use Outlook Web Access, you can use can use Kerberos V5 authentication only if clients are running Internet Explorer 5.0 or later. Unlike NTLM protocol authentication, Kerberos V5 requests can be routed through a proxy server between a front-end and back-end server; therefore, you need to open a third port in the firewall for Kerberos V5 tickets: TCP and UDP ports 88. Remember, however, that a client must begin a Kerberos V5 session by directly contacting a Key Distribution Center (KDC), which is usually a domain controller. As with other authentication methods, the client must receive a Kerberos V5 service ticket from the KDC before the front-end server can authenticate with the back-end server on the client’s behalf.

Firewall Between Client and Front-End Server

For a higher level of security, another common firewall configuration requires that user requests go through the firewall to access both the front-end and back-end servers. This configuration secures all information that flows to the front-end server, because all incoming packets must pass through the firewall or packet filter.

Unlike the previous example, this configuration prevents Internet access to all applications and services running on your front-end servers. The firewall is located outside the Exchange organization to prevent attacks and unwanted access. You can configure the firewall to allow HTTP communication on TCP port 80 and on TCP port 443 if you want to enable SSL encryption.

The following illustration shows the browser connecting through the firewall over TCP port 80 or port 443. That’s the only firewall port you need to configure unless you enable Kerberos V5 authentication, in which case you must also open TCP and UDP ports 88. Once a request passes the firewall, the front-end server looks up information directly on the global catalog server before passing the request to the back-end server. The front-end server receives the requested data from the back-end server and sends it through the firewall and over the Internet on TCP port 80 or port 443.

Figure 13.2 Firewall between client and front-end servers

Perimeter Network

The most secure firewall configuration places a firewall on either side of your front-end servers. This isolates the front-end servers in a perimeter network, commonly referred to as a demilitarized zone (DMZ). A perimeter network has a connection to the Internet through an external firewall and a connection to the internal network through an interior firewall.

Using Outlook Web Access as an example in the following illustration, the HTTP client request passes through the first firewall to connect to a front-end server. HTTP clients can use SSL encryption on TCP port 443 or unencrypted information on port 80.

Using LDAP, the front-end server queries the global catalog server through the second firewall over port 3268. Once the appropriate back-end server is determined, the front-end and back-end servers communicate through the second firewall over port 80. Once inside the first firewall, SSL isn’t necessary between the front-end and the back-end servers, particularly because of the burden that transport-layer security places on the network.

If you’re using Kerberos V5 authentication, you also need to open TCP and UDP ports 88 in both firewalls. Remember that Kerberos V5 authentication works only in a native Windows 2000 environment with clients running Windows 2000 Professional and Internet Explorer 5.0 or later.

Figure 13.3 Perimeter network for front-end servers

Note Depending on your clients’ needs, you may have to open additional ports in your firewalls to allow remote procedure call (RPC) communication.

Firewall Technology

A firewall can range from a simple packet filter to complex bastion hosts that analyze traffic for each application type. A bastion host is any computer that must be secure because it is accessible from the Internet and exposed to attack. Essentially, the bastion host acts as a protective relay for mail between the Internet and your internal users. A firewall can be a single router, a computer, or a combination of components including routers, computers, networks, and software.

There are several types of software and hardware you can use to protect your organization from outside attacks, including:

  • Proxy servers

  • Dual-homed systems

  • Packet filtering

  • Firewall software

  • DNS

Proxy Servers

Generally, allowing clients inside your network to connect directly to hosts on the Internet is not safe. One solution is to use a proxy server to communicate with external servers on the client’s behalf. The client communicates with the proxy server, which in turn relays approved client requests to servers and then relays responses back to the client. External hosts do not connect directly to clients in your network.

Exchange and many other messaging systems use a store-and-forward design, which inherently functions like a proxy server. Clients connect to servers that reside on the local network, and servers communicate with each other to transfer e-mail messages. Separate proxy services are unnecessary for securing traditional messaging when Exchange is configured correctly.

Dual-Homed System

You can use the bastion hosts described earlier as dual-homed computers, which have a connection to two networks but do not route packets between them. The connection to your internal network allows communication with other servers and clients. The connection to the Internet allows communication outside your network; thus, information from the Internet can be downloaded to the dual-homed computer. Clients in your organization can connect to the trusted dual-homed computer and retrieve that information rather than retrieving it directly. You can run Exchange on a dual-homed computer to safely provide e-mail connectivity to the Internet.

Packet Filtering

Putting a packet filter between the Internet and your network can add a layer of security. If you have a router that screens packets, you control the ports and IP addresses that external systems can use to contact your Exchange organization; however, if an intruder gets past the router, your network is vulnerable to attack.

To minimize this risk, many organizations implement a perimeter network. Computers that are linked to the perimeter network have limited access to both the Internet and the internal network. This architecture is convenient if multiple hosts require direct Internet access.

This configuration provides three layers of defense. If an intruder compromises the external router and a bastion host on the perimeter network, the intruder still does not gain unlimited access to your internal network, because the internal router limits access.

Firewall Software

There are many commercial firewall products on the market that provide proxy services. Some of these support SMTP e-mail. There are also free implementations of SMTP proxies that forward messages between internal and external systems. The advantage of these products is that because security is their sole purpose and they are usually simple applications with limited functionality, they are less likely to have security weaknesses. However using such software also has disadvantages. If you upgrade your internal SMTP virtual servers with new features, you must also upgrade the firewall software to take advantage of those features.

Organizations with existing networks and firewalls, or organizations setting up networks and firewalls, must verify network access over certain TCP ports for Exchange messaging to function. Part of your planning should include verifying that firewalls do not block these ports.

Exchange 2000 Server provides Microsoft Outlook Express and third-party messaging clients with the capability to communicate locally and remotely. This is achieved through TCP port assignments as outlined in Request for Comments (RFC) specifications, which describe how protocols such as Internet Message Access Protocol version 4rev1 (IMAP4) and Post Office Protocol version 3 (POP3) communicate.

When you install Exchange, the default configuration is POP3 on port 110, SMTP on port 25, and NNTP on port 119. Exchange allows users to change these ports but doing so can prevent third-party clients from connecting.

Domain Name System

If your system accepts mail directly from other hosts on the Internet, your system must be listed in DNS. Create a DNS mail exchange (MX) record that routes all messages sent to your registered domain to the hosts that process incoming mail. Unless you are forwarding all outbound Internet mail to a smart host, your server must also query DNS to route messages to the proper destinations. You can configure your Exchange server to use DNS services from your Internet service provider, or you can use your own DNS servers. If you maintain your own DNS servers, you must register them with your Exchange organization’s parent domain.

If you are using DNS and do not want DNS queries from the Internet to return information about computers in your internal network, you can configure DNS so that external hosts can query for information about your Internet server but not about other hosts. To do this, set up an external DNS server that you register with your parent domain, and create address and MX records for your bastion hosts. Set up a second internal DNS server for clients in your network. Configure this DNS server to forward queries it cannot resolve to the external DNS server, so that clients in your network can resolve Internet host names. Your bastion host should also use the internal server for DNS so that it can resolve internal and external names. If you divide DNS information this way, you can protect most of your computers from external DNS queries by simply not creating records for them on the external DNS server.

Virus Awareness

Any system that is accessible through the Internet is subject to attempts to infiltrate the operating system’s security or to exploit security weaknesses in any of the services running on the system.

Computer viruses attack the software of a computer and attempt to damage or destroy it, particularly operating system software. In most cases viruses do not affect computer applications. Over the past few years, however, a new type of virus has emerged, which is designed to affect your applications and your data. These macro viruses are written in the internal macro language of applications. As an administrator, you must be aware that malicious macros can damage large amounts of data.

Viruses often spread when users share documents and files. Many current applications allow users to attach macros or scripts to files. When users share these files, they also share the macros. Research shows that most macro viruses run when a user first opens the file, even if the damage doesn’t appear right away. It’s possible that by the time the user realizes the file contains a macro virus, the virus has spread to other documents on the user’s computer or to other computers.

Caution Virus detection software cannot scan messages that are encrypted for security purposes. A virus contained in an encrypted message escapes normal virus detection methods and can be activated when someone in your organization opens it.

Among the most basic and effective precautions you can take is to educate users to always learn where a document originates before opening it and to scan attachments before opening them. For information on virus awareness and steps your organization can take to ensure a virus-free environment, see the Microsoft Security Web site at http://www.microsoft.com/security/.

SMTP Virtual Server Controls

SMTP is the primary messaging transport protocol in Exchange 2000 Server; therefore, your SMTP virtual servers are instrumental in the movement of information within your organization. Besides the protocol logging capabilities of SMTP virtual servers mentioned earlier, there are other configuration settings you can use to protect your mail.

Relay Restrictions By default, SMTP virtual servers relay e-mail only from successfully authenticated users. Among the other benefits SMTP virtual servers provide, this prevents your organization’s servers from relaying unsolicited commercial e-mail.

Connection Control Connection control allows you to grant or deny single computers, subnets, or entire domains the use of any SMTP virtual server. You can allow all but a few users to access your virtual servers, or you can allow only a few users while excluding everyone else.

Note Connection Control is available for all virtual servers except those running HTTP.

Limiting Connections You can limit the number of incoming and outgoing connections on all SMTP virtual servers, and you can limit the duration that a connection can be idle to prevent someone from causing excessive network traffic or making numerous connections from an unattended remote workstation.

Message Restrictions SMTP virtual servers allow you to limit the size of each message or the amount of data that can be transferred in any given session. You can also limit the number of recipients any message can reach.

Smart Hosts You can forward outgoing mail from an SMTP virtual server to a smart host with Internet connectivity; thus, the smart host contacts the remote destination over the Internet while your mail server remains safely behind your firewall. You can do this for all outgoing messages or only for messages intended for a particular remote domain.


Message Security

Securing messages circulating within your organization is just as important as setting up strong network security. Even if your organization is impenetrable, you still need to protect information when you send it outside a firewall. Users who send information outside your organization or using the Internet must be aware of security issues. Although administrators often worry most about external attacks, inadvertent actions by authorized users can also release sensitive data or cause a flood of messages, which often causes the worst breaches in security.

Encrypted RPC

Earlier versions of Exchange use RPC for communication between the client and the server or between servers in a site. Exchange 5.5 uses the security built into RPC to authenticate client-server and server-server connections.

Although Exchange 2000 Server now uses SMTP as its native transport protocol, there are still instances in which it uses RPC. You can encrypt RPC to protect all client-server communication for secure mailbox access over the Internet in the following circumstances:

  • A MAPI client with encryption enabled connects to Exchange 2000 Server.

  • Exchange 5.5 Server connects to another server in the same site or over Site Connector.

  • Exchange 2000 Server connects to Exchange 5.5 Server in the same mixed-mode site and routing group or over Site Connector and Routing Group connector.

Encrypting RPC communication provides protection for data only as it travels from point to point on the network, whereas advanced security encryption provides protection for data until the recipient decrypts the data using the client. Encrypted RPC communication provides increased security for messages in transit on internal networks and over the Internet.

Certificate Services

A certificate is an electronic credential that authenticates a user on the Internet and on intranets. Certificates ensure the legitimate online transfer of confidential information or other sensitive materials by means of public encryption technology. If someone in your organization connects to a Web site or a server in another company, and that server has a certificate signed by an authority you trust, you can be confident that the company the certificate identifies actually operates the server. Likewise, servers can use certificates to verify a client’s identity. In either case, you safeguard your intranet against forgery or impersonation by an outside party. Also consider that by issuing certificates to employees, coworkers and internal resources can verify a user’s identity internally as well.

Certificates are an integral part of message security because they also allow users to generate digital signatures and encrypt e-mail. Digital signatures not only validate the sender’s identity, they ensure the message contents have not been altered. No one can tamper with a digitally signed message without detection. When the sender encrypts a message, only the recipient is able to decrypt it and read its contents. For more information about digital signatures and encryption, see “Advanced Security Keys” later in this chapter.

Windows 2000 Server Certificate Services allows an organization to act as its own certification authority (CA). A CA is an issuer of digital certificates that provides and assigns the unique strings of numbers that make up the keys that digital certificates use. A CA can issue its own certificates to clients and servers and revoke certificates when the private key associated with the certificate is compromised or when the subject of the certificate leaves an organization.

Note Certificate Services issues X.509 version 3 certificates. Key Management Service, which can issue X.509 version 1 certificates for backwards compatibility, is discussed later in this chapter.

Certificates and Public Keys

Public keys must be certified by a CA. Any CA can issue certificates to an Exchange organization. A certificate binds the user’s public key to his or her mailbox.

Each X.509 certificate includes:

  • A unique serial number.

  • The distinguished name of the CA.

  • The name of the user, which is referred to as the subject of the certificate.

  • The validity period of the certificate.

  • Version 3 extensions.

Version 3 extensions are the standard certificate format that Windows 2000 Server certificate-based processes use. They can include information related to key identifiers, key usage, certificate policy, alternate names and attributes, certification path, constraints, and enhancements for certificate revocation.

Advanced Security Keys

Exchange uses public key technology to provide advanced security. Keys digitally sign and encrypt data. Each mailbox has two pairs of keys: one for encrypting and decrypting, and the other for signing and verifying. Each pair of keys consists of a public key (publicly available and published in the certificate) and a private key (available only to the key’s user). The Key Management server generates encryption keys and Microsoft Outlook generates signing keys.

The public encryption key encrypts a message, and the public signing key verifies the source. When a user encrypts a message, each recipient’s public encryption key completes the process. When a user receives a signed message, the public signing key verifies the identity of the person who signed the message.

Private keys reside in an encrypted location on the user’s computer. When a user receives an encrypted message, the private encryption key decrypts the message. When a user signs a message, the mail client uses the private signing key.

Key Management Service

Exchange 2000 Server uses advanced security, in the form of Key Management Service, to provide the following benefits:

  • Sender to recipient authentication ensures that a signer’s identity is authentic.

  • Encryption ensures that only intended recipients can read the message.

  • Digital signatures ensure that the content of a message hasn’t changed since the message was signed.

  • Storage of all keys in an encrypted database and backup database protects certificates.

  • Support for the Data Encryption Standard (DES), CAST encryption algorithms, and the Secure/Multipurpose Internet Mail Extensions (S/MIME) messaging format provides compatibility with other systems.

  • Support for X.509 version 1 certificates, which are compatible with Outlook 97 and earlier clients.

Every user of Exchange Key Management Service has at least two certificates:

  • The encryption certificate contains the public encryption key and is an attribute of the user object in Active Directory.

  • The signing certificate contains the public signing key and is stored locally in a secure location on the client.

New Key Management Service Features

Key Management Service is closely integrated with Windows 2000 Server Certificate Services and other operating system utilities such as Group Policy. In addition, Key Management Service features give administrators greater flexibility without compromising the security and reliability of the service.

Certificate Trust Maintained by Operating System

Earlier versions of Key Management Service manage the certificate trust list. A certificate trust lists keeps track of all trusted CAs, even those that are outside your organization. Windows 2000 Server now maintains the certificate trust list for Key Management servers. Now Exchange administrators can import external certificates to Windows 2000 Server Group Policy objects, and from there, certificates are published to Active Directory. Any computer in the forest running Windows 2000 Server can download a certificate and trust it.

Windows 2000 Professional clients find the certificate trust list on their domain controllers. For clients running earlier versions of Windows, the Key Management server publishes the certificate trust list so that Outlook clients can access it whenever encryption is used in messaging. Windows 2000 Server or Key Management Service manages the certificate trust list without intervention in either case.

Service Start-Up Password Change

When you install Key Management Service with Exchange 2000 Server, you receive a password that you must use every time you start the service. This password protects the database that contains the private keys of everyone in your organization. Unlike earlier versions of Exchange, you can now change the database password if necessary.

Enrollment Through Active Directory

In Exchange 2000 Server, Key Management servers work in conjunction with Active Directory to enable or recover multiple users at once. Administrators are no longer confined to enabling or recovering only one person or an entire recipient container of users. Unlike Exchange 5.5, each session requires you type the administrative passwords only once.

One Key Management Server per Administrative Group

With Exchange 2000 Server, you can now have one Key Management server for every administrative group in your organization. With Exchange 5.5, you can have one Key Management server for each Exchange site.

Moving Users

Another feature of Key Management Service in Exchange 2000 Server is the capability to import or export users from one Key Management server to another. If you have a large organization with multiple administrative groups and someone is transferred to another department, you may need to move the user to another administrative group. That may entail moving that user’s keys to a different Key Management server. The export and import feature makes it possible for you to move one or more person’s keys securely and without risk of misdirection.

Important Because a user can exist on only one Key Management server, you must first export a user or group of users before you can import them on another server.

Common Encryption Formats

International organizations that use Exchange in several countries can mix and match the types of encryption they use. This is possible because Exchange maintains information in Active Directory about the type of encryption used by every user in the organization. If a message is addressed to multiple recipients using different types of encryption, Outlook automatically attempts to encrypt the message using the type of encryption that all recipients share; for example, if a message is addressed to one recipient using CAST 40 and another recipient using CAST 64, the message is encrypted using CAST 40. If you address a message to a recipient who is not using advanced security, you can choose not to send the message to that recipient or to send the message in plain-text format.

Configuring Key Management Server

To use the advanced security features provided by Key Management Service, you must configure at least one computer in your organization to store and manage the security database. This server is called the Key Management server. You can configure one Key Management server for each administrative group.

To use Key Management Service with Exchange 2000 Server, your CA must be running Windows 2000 Server Certificate Services. You cannot install the Key Management Service on a computer running Exchange 2000 Server unless you have already installed Windows 2000 Server Certificate Services.

Important After installing Exchange 2000 Server, Key Management Service installs and displays your start-up password. You can display and record this password manually or you can specify a floppy disk or fixed disk on which to save the password. Keep track of the start-up password because you cannot start Key Management Service without it.

After you configure the Key Management server, you must enable advanced security for your users. You give users temporary tokens so that they can complete the advanced security process. Users use tokens only once to authenticate the client on the Key Management server. You can enable advanced security for users individually or in bulk. You can automatically distribute tokens through e-mail.

Note For maximum security, Microsoft recommends distributing tokens in person or by using voice mail.

Certificate Trust List

With a certificate trust list, an organization can ensure that the CA issuing the certificate can be trusted, even if the CA is in another organization. This is the most secure way to verify the source of messages sent from another organization. It is also transparent to users — they don’t need to perform any additional steps to send a digitally signed message to a user in a trusted organization.

Because certification establishes trust between CAs, security keys sent between users in certified organizations are automatically trusted. On the other hand, if a user receives a digitally signed message from a CA not on his or her certificate trust list, the recipient cannot rely on that signature.

Note Key Management servers in Exchange 2000 Server now use the Windows 2000 Server Certificate Services to maintain certificate trust lists.

Multiple Password Policy

The multiple password policy prevents administrators from making changes to the Key Management server without the authorization of one or more other administrators; for example, you can set your Key Management server so that the cooperation of three administrators is necessary to recover or revoke a user’s key.

You can require multiple passwords to perform the following tasks:

  • Add or delete administrators who can manage the Key Management server.

  • Recover or revoke a user’s security keys.

  • Import or untrust another CA’s certificate.

Revocation

Revocation checking warns users when they verify signed messages that contain a revoked certificate. Revoking a user’s advanced security is not the same as deleting a user, and you should do this only if the security of the user is compromised; for example, you should consider revoking advanced security if it appears that someone is signing messages on behalf of another user or if someone has gained access to the user’s security file and password. You can enable security again by assigning another temporary token to the user.

A revocation list contains the serial number and expiration date of each revoked user’s certificate. The Key Management server stores the revocation list in the key management database and then writes it to Active Directory. The revocation list in the directory is then cached on the client and updated daily.

You should limit the use of revocation. As the revocation list grows larger, the client’s advanced security performance degrades, because each time the client verifies a message’s signature it must check the revocation list.


Chapter 14 Backup and Restore

Backing up the Information Store is an important part of creating a fault-tolerant messaging system. The backup and restore features in Microsoft Exchange 2000 Server help you recover from various types of data loss with minimal downtime for your mail system.

Exchange uses the Microsoft Windows 2000 Backup utility to back up and restore the Exchange Information Store. The Windows 2000 Backup utility enables you to protect data from accidental loss or hardware and media failure by using a storage device to back up and restore data on any server in your organization locally or over the network.

Enhancements in Exchange 2000 Server ensure that backing up and restoring data is efficient and reliable; for example, you can restore one or more mailbox stores or public folder stores without shutting down the Information Store.

You can make sure your organization is prepared to recover from data loss by performing proper planning and implementation. This chapter describes how to develop a backup and restore strategy. Developing a backup and restore strategy consists of the following steps. Each step is described in detail later in this chapter.

  1. Understand Exchange 2000 Server database and storage group technology.

  2. Design a backup plan.

  3. Develop disaster recovery strategies.

  4. Restore data.

For operational procedures relating to backing up and restoring your Exchange organization, see the Exchange online documentation. For information about the Windows 2000 Backup utility, see the Windows 2000 documentation.


Exchange Database Technology

Understanding the underlying database technology Exchange uses will help you understand the backup and restore process. An important enhancement in Exchange 2000 Server is the concept of multiple storage groups and multiple mailbox stores or public folder stores within each storage group. A database contains data in a mailbox store or a public folder store. You can back up and restore databases in a storage group individually or together. A single set of log files contains entries for all databases in the storage group.

Exchange uses fault-tolerant, transaction-based databases to store messages and write-ahead transaction log files to improve write performance of server data. Write-ahead is the process of writing transactions to transaction logs sequentially before writing them in bulk to the database. This improves performance and ensures that committed transactions are not lost because copies are stored in the log files.

Data for a mailbox store or public folder store is written simultaneously at high speed to a sequential transaction log file and a memory cache. The data in the cache is later written to the database as necessary. If a power outage or abnormal system shutdown occurs before data in the cache is written to the database, Exchange reconstructs the database from transaction log files when you restart the computer. When a transaction log file reaches 5 megabytes (MB), a new log file is generated. Log files have names consisting of hexadecimal serial numbers.

Note The size of log files is always 5 MB. You cannot determine whether a log file is filled to capacity by checking the file size.

Transaction log files are important for data recovery. If a database is damaged, you can use the transaction log files to restore the database from a backup if an uninterrupted sequence of transaction log files exists since the time of the last backup.

When circular logging is off, transaction log files accumulate sequentially until a full or incremental backup is performed, during which log files with transactions that have been committed to the database are deleted. During differential or copy backups, transaction log files are backed up but remain on the server. For more information about the various backup routine options, see “Choosing a Backup Routine” later in this chapter. For more information about circular logging, see “Understanding Circular Logging” later in this chapter.


Backup Plan Design

Designing your backup plan should include the following tasks. Each task is described in detail later in this section.

  1. Partition data.

  2. Determine a service level agreement for recovery.

  3. Understand circular logging.

  4. Choose backup devices.

  5. Choose a backup routine.

  6. Perform timely backups.

  7. Understand the Exchange data verification process.

  8. Verify and validate backups.

  9. Verify the integrity of configuration data.

  10. Document and archive backups.

Partitioning Data

Exchange offers flexibility in partitioning your data for purposes of restoring it. There are important tradeoffs to consider: recoverability, administrative complexity, and performance.

Each storage group has a set of log files associated with it. Generally, for performance reasons, it is recommended that you place the log files for each storage group on a dedicated mirrored disk device. Within a storage group, data can be partitioned into multiple databases. It is recommended that you maintain these databases at a size that facilitates a reasonable restore time.

It is recommended that you back up an entire storage group at the same time. This makes the backup process easier to manage because the databases within the storage group share the same set of log files. The log files can be truncated only after all databases have been backed up.

You can restore a single database without affecting the other databases in a storage group. The other databases continue to run and service clients; however, if databases share underlying physical devices, such as striped disk set, hardware failures can occur that affect multiple databases. If this type of failure occurs, you may need to restore multiple databases. Partitioning databases across separate physical disks or disk arrays can isolate potential hardware failure to a single database.

To prepare for a failure of all storage related to a server, you can partition data into separate storage groups and back up these storage groups to different media. As long as you initiate separate restore sessions for each storage group, Exchange can restore multiple storage groups at the same time. The storage groups should also be hosted on separate physical disks or disk arrays so the physical disk media does not become a bottleneck for the restore. This is known as a parallel restore.

Note Exchange reserves a single storage group for restore. If you plan to perform a parallel restore of multiple storage groups, you must reserve additional storage groups by configuring fewer than the total available number of storage groups on a server.

Determining a Service Level Agreement

A service level agreement is an agreement that exists between an information technology service provider and a client. It defines the scope, level, and complexity of information technology service that the client receives from the provider. Most service level agreements that include messaging and collaboration include a clause that defines the maximum time the client can be without messaging service if a failure occurs. Service level agreements for restoring messaging data vary and depend on how critical messaging is to the client's business; for example, a company that depends heavily on its messaging system might establish a service level agreement that guarantees a maximum of four hours without messaging functionality.

After you negotiate a service level agreement for your organization, you should perform a test restore of your largest Exchange server. This will help you determine the time it takes to restore data. If you do not meet your service level agreement for restoring your server, you can make changes to your Exchange environment. You can use the following strategies to reduce the time it takes to restore data.

  • Distribute your messaging system to multiple Exchange servers.

  • Partition your Exchange data logically and physically into separate storage groups or databases. This enables you to restore data more quickly; for example, if you have 500 users, 50 gigabytes (GB) of data on a server, and a service level agreement of four hours, you could consider partitioning the users onto more than one hard disk. If you divide your users into three separate storage groups and have each storage group on its own hard disk, Exchange can restore each of the storage groups simultaneously.

  • Upgrade your server hardware. Installing faster hard disks and more memory can improve restore time.

Understanding Circular Logging

When developing your backup plan, you should consider the implications of using circular logging. When you enable circular logging, transaction log files are recycled by overwriting the log files with new transactions that are committed to the database. This prevents the continuous buildup of transaction log files and reduces the disk space required to store them, which is typically less than 100 MB.

CAUTION If you enable circular logging, you can restore data only up to the last backup. You cannot restore data from the last backup to the point of the failure because the required log files are not available. In addition, when you enable circular logging, you can perform only full backups, not incremental or differential backups. By default, circular logging is disabled. In most cases, you should keep circular logging disabled to increase your backup options and your ability to restore data.

Although circular logging has disadvantages, you may want to enable it if your server has limited hard disk space, or if you are using Exchange as a news server that contains only non-critical data.

Choosing Backup Devices

When designing your backup plan, you should choose backup devices that best meet the needs of your organization. You can use the Windows 2000 Backup utility to back up files to a variety of storage devices. The backup medium can be a logical drive, a removable disk, or recordable CD-ROMs. If you do not have a separate storage device, you can back up your data to another hard disk or to a floppy disk.

When choosing backup devices, verify that the media is reliable and adequate to meet the needs of your organization; for example, you should choose a tape drive that is large enough and fast enough to efficiently support the amount of data you need to back up. Most storage device manufacturers publish recommended media brands that are tested and certified on their storage devices. Media reliability reports are also available from many computer trade publishers.

Choosing a Backup Routine

Backup routine options include full (normal), copy, incremental, and differential. Most organizations use a combination of these routines.

A full (normal) backup backs up the entire storage group and the log files. It deletes the transaction log files with transactions that are committed to the server database. Restoring from a full backup requires only the full backup file. This is generally the preferred backup method.

A copy backup is the same as a full backup except that log files are not deleted. Create a copy backup if you want a full backup without disturbing the state of other ongoing incremental or differential backups.

Note Consider creating periodic copy backups and adding them to your archives to provide additional protection. You could create and archive copy backups once a month and after you significantly change server configurations.

An incremental backup backs up only data from the transaction log files that has changed since the last full or incremental backup. It deletes the transaction log files with transactions that are committed to the database. Restoring from an incremental backup requires the last full backup and each incremental backup.

A differential backup backs up only data from the transaction log files that has changed since the last full backup. Transaction logs are not deleted. Restoring from a differential backup requires the last full backup and the most recent differential backup.

The advantages and disadvantages of each backup routine are described in the following table.

Backup Type | Advantages | Disadvantages
Full (normal) | Easy backup to schedule Easiest method from which to restore data Removes transaction log files | Can impact server performance Takes more time to perform than other types of backups Requires the most storage space and frequent storage media replacement
Copy | Does not disturb ongoing incremental or differential backups Useful when done periodically for archive purposes | Requires a large amount of storage space Does not remove transaction log files
Incremental | Minimal impact on server performance Removes transaction log files Requires minimal storage space | Results in a longer and more complex restore process
Differential | Minimal impact on server performance Easier to restore data from than incremental backups Requires minimal storage space | Does not remove transaction log files Results in a longer and more complex restore process Does not remove transaction log files

Considerations

You should consider the following when choosing a backup routine:

  • Time required to perform the backup

  • Time required to restore data

  • Performance impact on servers

  • Amount of data to back up

  • Storage device capability and capacity

  • Personnel required to administer and perform backups

  • Value, priority, and security of the data to be saved

Rotations

Many organizations rotate full backups with differential or incremental backups. A daily rotation requires full backups every day. A weekly rotation requires one full backup followed by differential or incremental backups on the remaining days of the week. A three-day rotation requires a full backup followed by two days of differential or incremental backups. A mixed rotation requires a full backup followed by a rotation of differential and incremental backups on the remaining days of the week.

Note A rotation including both differential and incremental backups can help minimize the amount of time it takes to backup and restore your server, but doing so adds complexity to the backup rotation and restore process.

The following chart illustrates several backup rotations.

Sample Backup Rotations
F = Full, I = Incremental, D = Differential
Rotation | Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday
Daily | F | F | F | F | F | F | F
Weekly | F | I or D | I or D | I or D | I or D | I or D | I or D
3-day | F | I or D | I or D | F | I or D | I or D | Repeat cycle
Mixed | F | D | D | I | D | D | I

Performing Timely Backups

The most important thing you can do to ensure you can recover from disasters is to perform timely backups. Your backup strategy should include choosing a backup routine and systematically performing and verifying backups. Depending on server load, you should back up the Information Store as often as possible, preferably once every day. Timely backups should include online daily backups of the Information Store using the appropriate backup rotation.

Understanding the Exchange Data Verification Process

The data verification process Exchange provides during backup ensures that the Exchange data is valid. Exchange reports a 1018 error if it detects the possibility of data damage caused by the operating system or by failure of one of the underlying hardware subsystems on which Exchange runs.

Without this level of error detection, your data could become damaged by the failing subsystem without your knowledge. This can result in unknowingly backing up damaged, unrecoverable data. If a 1018 error occurs, a lower level subsystem other than Exchange is failing and needs attention.

Verifying and Validating Backups

Your ability to restore data and servers depends on the quality of your backups; therefore, it is important to verify the success of your backup procedure. For complete fault tolerance, you should verify your backup procedure at two levels.

Verification of the event It is important to verify that the backup occurred without errors. Examine the Windows 2000 Backup log for the backup event you are verifying. In addition, thoroughly review the events in the Windows 2000 event log to ensure your backup has completed as scheduled without errors. You should research and resolve errors or inconsistencies in the logs as soon as possible.

Verification of data Verifying data includes restoring the data from the storage device to another computer to verify that the backup worked correctly. Verifying all backups from all servers in a large installation is not feasible; however, by rotating a restore process to include various servers or backup devices, you can verify the integrity of the system and identify potential problems before you lose data. This process can also help you train administrators on how to perform restore procedures.

Verifying the Integrity of Configuration Data

When you back up your Exchange data, you are not backing up server configuration information. Most server configuration information is stored in Active Directory and Internet Information Services (IIS) on the local computer.

Note Periodic backups of the entire server file system while offline (including the Windows 2000 registry) can also help preserve changes to the configuration of the local server.

Active Directory

It is strongly recommended that there is a replica domain controller because Active Directory stores essential information. You should also perform regular tape backups of Active Directory. If you lose all instances of Active Directory, you cannot restore an Exchange server. For more information about backing up and restoring Windows 2000 and Active Directory, see the Windows 2000 documentation.

IIS

Exchange stores some configuration information, such as Internet protocol configuration and message routing information, on the local computer. For disaster recovery to work successfully, you must back up the IIS metabase.

Documenting and Archiving Backups

It is important to document your backup strategy and provide step-by step instructions describing how to use backups to restore data. Backup and disaster recovery procedures should also specify escalation procedures and the person or persons who can approve escalating the situation if any part of the process fails. Label backup media and store them in a secure location. For maximum reliability, archive full backups to a separate location, preferably offsite.


Disaster Recovery Strategies

Disasters can cause you to lose key components or critical data in your messaging system. Disaster recovery is the process of restoring data that has been lost. A disaster recovery strategy requires that your organization be prepared for a variety of disasters. An example of a minor disaster is the need to restore a single message or an entire mailbox. A mid-level disaster is losing your Information Store because your hard disk failed. A major disaster is the loss of an entire data center during a catastrophic event. You can minimize and even eliminate data loss if you implement the appropriate backup and restore plans.

The following tasks can help you recover from disasters and minimize downtime and productivity loss. Each task is described in detail later in this chapter.

  1. Design a disaster recovery plan.

  2. Create a recovery toolkit.

  3. Train administrators to implement the disaster recovery plan.

  4. Consider server design and configuration to prevent disasters.

Designing a Disaster Recovery Plan

Your organization should develop procedures to recover from common disasters, such as hardware failure or a damaged Information Store. You should also develop contingency plans to recover from major disasters, such as fires, hurricanes, and earthquakes.

One way to determine how extensive your disaster recovery plan should be is to determine how much your organization depends on electronic communications; for example, if your organization relies on electronic communications, your ability to restore critical data is extremely important. Your organization may consider the loss of messaging for more than a few minutes a disaster. In such an environment, you must have a minimally or fully functioning e-mail system available immediately after a disaster occurs. In other organizations, the loss of electronic communications for a day might be merely an inconvenience to a few users. In this case, the recovery strategy can be much less intensive.

Your organization's plan also depends on your location; for example, an international organization with facilities in Los Angeles, California should develop contingency plans for earthquakes and the potential loss of facilities and services. Its plan could require reserve capacity and duplicate services in facilities in Denver, Colorado or London, England. If an earthquake occurs in California, the system continues to operate normally for the remainder of the organization.

It is recommended that you research your disaster recovery options, including the costs and benefits of different strategies.

Creating a Recovery Toolkit

Create a recovery toolkit to ensure all the materials you need are available if a disaster occurs. A recovery kit includes:

  • Operating system configuration sheets

  • EISA/Micro Channel Architecture (MCA) configuration disks

  • Redundant Array of Inexpensive Disks (RAID) configuration sheets

  • Hardware configuration sheets

  • Exchange server configuration sheet

  • Windows 2000 emergency repair disk

  • Detailed escalation paths for hardware issues both externally with the system vendor and internally

Training Administrators

Your organization should implement a program to train administrators on disaster recovery plans. This program should include escalation procedures, training on all disaster recovery procedures, and periodic drills simulating disaster recovery scenarios.

Considering Server Design and Configuration to Prevent Disasters

Although you cannot prevent all disasters, properly designing your system and configuring your servers can prevent some disasters from occurring. The following practices can help reduce the risk and impact of disasters.

  • Install servers in adequate, safe, and secure environments.

  • Avoid making an Exchange server a domain controller.

  • Maintain transaction log files for storage groups on separate hard disks.

  • Use hardware RAID5 or mirroring.

  • Protect servers with uninterruptible power supplies (UPSs).

  • Leave circular logging at default settings (off) for all storage groups.

  • Tightly control the configuration of all Exchange servers.

  • Document all server configurations and keep a record of changes.

  • Equip production servers and recovery servers with sufficient disk space.

  • Fully test all third-party software before using it in a production environment.

  • Ensure that server hardware is always updated.

  • Ensure that software service packs are applied.

  • Check event logs for error messages on a regular basis.

For information about maintaining the Information Store, see the Exchange online documentation.


Data Restore

After you implement the backup plan for your Exchange servers, you can restore data using the Windows 2000 Backup utility if data loss occurs. You can restore a single item such as a mailbox, public folder, message, or mailbox folder. You can also restore the data on an entire server to a repaired computer or a separate computer. The following sections provide overviews of some types of data restore that you can perform with Exchange. For more information and procedures, see the Exchange online documentation.

Restoring a Database to the Same Server

Restoring a mailbox store or public folder store to the same server on which you perform the backup is useful if one of your databases becomes damaged. This involves taking the damaged database offline, replacing it with the database from the last successful backup, and then placing the database back online.

Restoring Messages and Mailboxes

If you set a deleted item retention period on a mailbox store object or a public folder object, users can easily restore messages after they have been deleted from their mailbox by using options in Microsoft Outlook. By default, the deleted item retention period is 0 days. If you do not set a deleted item retention period or if that retention period has expired, you can still restore deleted messages. You do this by restoring the appropriate mailbox store to an alternate server, moving the messages to a .pst file, and then making the .pst file available to the user.

Restoring a Database to a Different Server

Restoring a database to an Exchange server that is different from the one on which you performed the backup enables you to recover individual items from a backup without restoring over a server that is in use. This is a last-resort method for retrieving items from individual mailboxes or public folders. This method requires an additional computer with enough hard disk space to restore the entire backup and meets the minimum hardware requirements to run Exchange.

Restoring Information After a Catastrophe

If a catastrophe occurs that destroys a server, you need to perform a complete server restore. This type of disaster recovery involves four important steps.

  1. Reinstall Windows 2000 Server into a domain with an instance of Active Directory.

  2. Run Exchange 2000 Setup in disaster recovery mode.

  3. Recover your IIS configuration.

  4. Recover the databases using the Windows 2000 Backup utility (NTBackup.exe).


Chapter 15 Custom Solution Development

Custom solutions can provide your organization with information and tools that match the way your organization works. Typical custom solutions use common resources such as directories of people, the capability to generate and send messages, and the capability to present customized forms to users. A development platform provides these common resources so that you can focus your development efforts on the unique aspects of your solution.

When you plan custom solutions, you need to consider performance, security, and deployment issues, in addition to the skill sets of your developers. This chapter describes the custom solution development capabilities of Microsoft Exchange 2000 Server. This chapter also describes performance, security, and deployment issues that you need to consider while planning your custom solution. Use this information to decide whether you want to perform a task manually or create a custom solution.


Exchange Development Platform

Exchange offers many resources for building custom solutions. Depending on your needs, you can develop solutions using one or more of the following:

  • Collaboration Data Objects (CDO) for Exchange 2000 Server. CDO includes objects that simplify creating and processing messages, calendar information, and contacts. You can use these objects to create Web-based solutions and other solutions that run on the server.

  • CDO Exchange Management. You can write programs that automate administrative tasks such as creating mailboxes.

  • CDO Workflow for Microsoft Exchange. You can build custom workflow and routing solutions to automate the flow of forms through your organization. You can create a batch import utility using CDO Workflow in a simple script.

  • Outlook Web Access. Outlook Web Access automatically renders information in the Information Store as a Web page when you enter the URL of an Information Store resource in a Web browser. You can create custom Web forms that are displayed instead of the default Outlook Web Access forms.

  • Information Store event handling. You can create event sinks that are invoked when specified events occur in the Information Store. You can register sinks that are called when messages are received, sent, deleted, moved, and so on.

  • Transport and protocol event handling. You can create event sinks that are invoked when specified Simple Mail Transfer Protocol (SMTP) and Network News Transfer Protocol (NNTP) transport and protocol events occur. Event sinks are programs that run when specific events trigger them. These events include establishing a connection with the server, posting a message, or even new protocol elements that you define.

  • Active Directory Services Interface (ADSI). Programs can access directory information using ADSI. Active Directory stores all Exchange directory information.

Scripting languages are ideal for quickly deploying programs that run infrequently. For synchronous event sinks, a higher performance language such as C++ or Microsoft Visual Basic is more appropriate. A frequently used program that makes many requests to the Exchange server may require you to use a faster computer or a dedicated server.

Any program that accesses data from Information Store or Active Directory must have permissions for the folder or item the program accesses. If a program has permission to access multiple mailboxes or other private information, you should verify that the program does not allow unauthorized access to information about other users.

Depending on your Exchange configuration, you may need to install a server-based solution on every Exchange server or only on specific servers. You must deploy client-based solutions on every client computer that uses the solution. Web-based solutions run on the server computers, but you may need to download Microsoft ActiveX controls to clients to support more complex solutions.

CDO for Exchange 2000 Server

CDO for Exchange 2000 Server is a set of objects that simplify the process of writing programs that work with messages, calendars, and contacts. Unlike earlier versions of CDO, which are client/server object models, CDO for Exchange 2000 Server is a server-based object model designed for Web and administrative applications. CDO is based on the Component Object Model (COM) and runs on the Exchange server.

If you want to automatically send an e-mail message to an administrator when a particular event occurs, you can use the CDO Message object to easily build and send the message.

CDO uses the credentials of the program that uses it. Your CDO program must have permission to access the appropriate folders and items in the Information Store.

The CDO program is the Exchsrvr\Bin\Cdoex.dll file. The primary functions of CDO are described in the following sections.

CDO Messages

The CDO message functions include creating, processing, forwarding, replying to, and deleting messages. CDO supports the full range of Multipurpose Internet Mail Extensions (MIME) messages, including attachments and rich text.

You can configure CDO to send messages using the Exchange server or the SMTP server component of Microsoft Windows 2000. If you are sending messages to recipients on your Exchange server, you should send them using Exchange. If you are sending messages to recipients over the Internet, you can send the messages more quickly if you use an SMTP server.

CDO Calendars

The CDO calendar functions include creating appointments and accepting and declining meeting requests. By default, Exchange creates a calendar folder for each mailbox.

A common method for managing physical resources such as conference rooms is to create a mailbox and calendar for the conference room. You can also create calendars for teams or resources in public folders.

CDO Contacts

The CDO contact functions include creating, adding information to, and deleting contacts in the Information Store and Active Directory.

CDO Exchange Management

CDO Exchange Management is a set of objects that simplify the task of writing programs that manage an Exchange server. You can develop custom solutions that create and delete mailboxes and that modify mailbox properties such as message limits.

The CDO Exchange Management program is the Exchsrvr\Bin\Emo.dll file.

CDO Workflow for Exchange

CDO Workflow for Exchange is a set of objects that simplify document tracking and approval. A typical workflow solution is used for employee expense reporting. Employees fill out an expense report form, which is routed to managers for approval, and then to the accounting department for payment.

A workflow solution consists of a set of rules that you place on a folder and its association with an event sink. This set of rules is called a process definition, the association is called an event registration, and event sink is called the CDO Workflow Event Sink. The application is driven by events in the folder caused by saving, deleting, or expiring documents in the folder. The event sink calls the workflow engine to handle the transition of the work item.

When your action table includes scripts and COM objects that run on your server, security is important. To protect your server while allowing users the flexibility to design their own workflows, CDO Workflow uses two workflow security modes: restricted and privileged.

Use the restricted mode for untrusted workflows; users can set up a simple document route or filter incoming mail to their inboxes. Use the privileged security mode only for solutions created by authorized individuals create.

Web Forms

Outlook Web Access is a Web-based client program included with Exchange. It displays messages, appointments, and other information in the Information Store using default forms. The form Outlook Web Access displays used depends on several factors, including the content class of the item and the Web browser on the client.

Outlook Web Access uses the user's credentials supplied through the user's Web browser to access the Information Store.

Instead of using the default forms, you can register new custom forms to display specific types of items. You can build forms using Microsoft FrontPage 2000 or another Web authoring tool.

For more information about using Outlook Web Access, see Chapter 10, “Outlook Web Access.”

Information Store Events

You can register event sinks on folders in the Information Store that run when a specified event occurs; for example, you can create a sink that runs whenever a message is added to a folder. Events can be synchronous or asynchronous. The Information Store waits for synchronous events to complete, and a synchronous event can cancel the event; for example, a synchronous event can block a message from being saved in a folder.

You register event sinks by creating a registration file in the target folder. If you register more than one event on a folder, you can specify the order in which the event sinks run. Because an Information Store event sink can cause problems with performance and security, you need to manage event registration carefully.

For more information about Information Store event sinks, see “Customizing Information Store Event Handling” later in this chapter.

Transport and Protocol Events

You can register event sinks for events in the SMTP and NNTP transports. These can be protocol events, such as the EHLO command in SMTP, or transport events, such as a message being sent. Transport and protocol events are synchronous events, and can block a message or command.

You register event sinks using Server Extension Objects (SEO). Because an Information Store event sink can cause problems with performance and security, you need to manage event registration carefully.

For more information about transport protocol event sinks, see “Customizing Transport and Protocol Event Handling” later in this chapter.

Active Directory Services Interface

The Active Directory Services Interface (ADSI) is a set of objects that simplify getting information into and out of Windows 2000 Active Directory. ADSI is particularly useful when you use it with CDO Exchange Management to create and manage users and mailboxes.

Additional Information

For programmer's guides and reference information about developing custom Exchange solutions, see Messaging and Collaboration in the Microsoft Platform SDK. The Platform SDK is an integral part of the Microsoft Developer's Network (MSDN). You can access it online at http://msdn.microsoft.com. The Platform SDK is also available in CD format through a MSDN quarterly subscription. For the latest Exchange development information, including technical articles, samples, tools, and documentation, visit the MSDN Exchange Developer Center at http://msdn.microsoft.com/exchange.


Using Existing Solutions Developed for Exchange 5.5

In Exchange 5.5, most custom solutions use the MAPI protocol, either directly or through CDO 1.2.1 and Outlook Web Access. Exchange 2000 Server supports the MAPI protocol and any solutions you have written for Exchange 5.5. Existing MAPI solutions that you have written for Exchange 5.5 can coexist with new CDO for Exchange 2000 Server solutions.

Exchange 5.5 uses a single private information store to hold mailboxes. Exchange 2000 Server supports multiple mailbox stores. If Exchange 2000 Server has multiple mailbox stores, they appear to MAPI programs as a single store.

CDO 1.2.1

CDO for Exchange 2000 Server offers many functions that are similar to CDO 1.2.1; however, CDO for Exchange 2000 Server uses a different code base. CDO for Exchange 2000 Server uses Internet-standard protocols instead of MAPI.

No new features are planned for CDO 1.2.1; however, you can continue to use it to develop custom solutions.

The CDO 1.2.1 DLL is installed and registered by default on computers running Exchange 2000 Server. To run CDO 1.2.1 on a client computer, you need to install the CDO 1.2.1 DLL and Microsoft Outlook 97 or later on that computer. The Outlook setup program optionally installs the CDO 1.2.1 DLL, or you can download and register it manually.

Outlook Web Access

Outlook Web Access is redesigned for Exchange 2000 Server. Unlike in Exchange 5.5, custom Outlook Web Access forms are preserved when applying maintenance to Exchange; for example, when you apply service packs or QFE patches. A forms registry in the Exchange 2000 Server mailbox store or public folder store is used to display the correct form for any resource in the mailbox store or public folder store.

Although you can run customized Outlook Web Access forms from Exchange 5.5 with the Exchange 2000 Server Information Store, the benefits of converting forms usually outweigh the costs of conversion.

Exchange 2000 Server supports saving and running Active Server Pages (ASP) in the Information Store. If you created custom ASP pages for Exchange 5.5, you can run them in an Exchange 2000 Server folder. ASP pages run in the security content of the user who views them.

Event Scripting and Routing Objects

Existing event scripts and routing maps that you developed for Exchange 5.5 will work with Exchange 2000 Server. By default, Microsoft Exchange Event Service starts manually; change this service to start automatically if you need to support Exchange 5.5 event scripts.

The new CDO Workflow objects enable you to write simpler and more robust workflow applications. Unless you need backward compatibility with Exchange 5.5, you should use CDO Workflow objects for new workflow applications. CDO Workflow objects use built-in support in the Information Store; they do not require a separate event service.


Developing Server-Based Solutions

Server-based solutions run on the Exchange server. These solutions communicate with the Information Store using the Exchange OLE DB provider, Exoledb.dll.

CDO for Exchange 2000 Server, CDO Workflow for Exchange, and CDO Exchange Management use the OLE DB provider, or you can use the provider directly.

Security Issues

If your solution accesses only one mailbox, it can run using the credentials of the owner of that mailbox. Using the mailbox owner's credentials, the program cannot access information about other users.

If your solution accesses multiple mailboxes, it must run using the Exchange Server permission. This permission allows the program to access and delete information from any mailbox on the server, so you should use it should with caution.

Public folder solutions run using the permissions you specify for the public folders they access.


Developing Client-Based Solutions

Because the Exchange OLE DB provider works only with programs on the local computer, you cannot use it directly for client-based solutions. Instead, you can use Web-based programs that run on the server computer to develop solutions for client computers.

Client computers use a Web browser to view pages on the server computer. The scripts and forms behind those Web pages then access the Information Store on the server computer.

The script on the server computer uses the credentials supplied through the client's Web browser. Clients must have permissions for the mailboxes or public folders they access.

Using ASP Pages

ASP pages contain scripts that can receive input from the client and return output in HTML format. The scripts use interfaces such as CDO on the server computer to read and write to the Information Store.

Because ASP solutions typically use interpreted scripting languages, performance is usually slower than with an equivalent compiled solution. You may need a faster computer for servers running heavily used ASP solutions.

Using Web Forms

Outlook Web Access is a Web client for Exchange. When the client Web browser requests a specified URL, the Windows 2000 Web server passes the request to the corresponding Outlook Web Access program. Outlook Web Access gets the appropriate information from the Information Store and returns output in HTML or XML format to the client.

Outlook Web Access uses different forms to display information based on the type of information requested and parameters passed with the URL.

You can specify different forms based on the type and language of the Web browser. This enables you to support the broadest possible range of clients while taking advantage of the latest browser technologies.

Using FrontPage 2000

FrontPage 2000 server extensions enable you to create Web forms that run on Exchange without writing code. Web forms that you create with FrontPage 2000 automatically support multiple Web browser types and versions.


Customizing Information Store Event Handling

Events sinks in the Information Store can perform simple tasks such as sending a message when a file is added to a public folder, or they can perform complex tasks such as checking all outgoing messages for compliance with corporate regulations.

Event sinks can be synchronous or asynchronous. The Information Store waits for synchronous event sinks to run. A synchronous event sink can change or delete an item in the Information Store. The Information Store does not wait for asynchronous event sinks. Asynchronous event sinks cannot delete or modify the item that triggered them. When an event occurs in the Information Store, synchronous event sinks run first, followed by folder rules, and then asynchronous event sinks. The priority value you register for each event sink determines the order in which synchronous events run. You cannot specify the order in which asynchronous events run.

The item that triggers the event is passed to the event sink. For synchronous event sinks, the event sink is also passed to the session of the user who changed the item that triggered the event. The session can be used to access any information in the Information Store that the user has permission to access; for example, if a synchronous event sink runs in a user's calendar folder, the event sink has access to all of the folders in that user's mailbox.

Capabilities

Each synchronous event sink is called twice: once before a change is made to the Information Store, and once after a change is made or canceled by an event sink. You can register synchronous event sinks for events such as saving an item to a folder or deleting an item from a folder.

Each asynchronous event sink runs once after a change to Information Store is finished. You can register asynchronous Information Store event sinks for events such as when the Information Store is started and when a specified time interval has elapsed.

Performance Issues

Information Store event sinks can be written using scripting languages, Visual Basic, and C++. For simple asynchronous event sinks that run occasionally, a scripting language can provide adequate performance; however, for frequently used event sinks, and particularly synchronous event sinks, you should use Visual Basic or C++ to ensure acceptable performance.

Security Issues

To register an event sink in a folder, you need owner permission for the folder.

You install event sinks you have written in Visual Basic or C++ as DLLs and register them on every server computer on which they run. To install and register an event sink DLL, you need Administrator permission for the server computer.

Event sinks you have written in a scripting language run using the script host Exoledbesh.dll. This script host is installed and registered by default when you install Exchange.

When you register an event sink for a folder, you can register the sink for only the specified folder or for all child folders in the hierarchy. This means that you can register event sinks for child folders regardless of permissions on individual child folders. You should plan your folder hierarchy accordingly.

An event sink can prevent itself from being registered under specified conditions. When an event sink is registered, an interface on the event sink is called, and the sink cancels the registration if appropriate.

Because the event sink registration is stored in the folder on which you register the sink, if you move the folder, the registration moves with the folder and is automatically updated with the new location.

Event sinks that check for viruses or other unauthorized content in messages should run as the last synchronous event sink. This allows the sink to detect a virus or other content that another event sink has added to the message.


Customizing Transport and Protocol Event Handling

The SMTP and NNTP transports that Exchange uses support event sinks for both transport and protocol events. Transport events, such as a message arriving, occur as a message moves through the SMTP or NNTP transport. Protocol events occur when the client connects to the server and issues commands such as EHLO or DATA.

Capabilities

You can use transport events to intercept messages after the SMTP or NNTP service receives them but before they are delivered or relayed. You can redirect or block messages that match some criteria, restrict the number of recipients, or copy messages to an archive. Unlike Information Store events that work only with messages on an Exchange server, transport and protocol events work with any message using the SMTP or NNTP transport on Windows 2000 Server. A typical application of a transport event is adding disclaimer text to all outgoing messages.

You can use protocol events to modify how protocol commands are processed, or to add your own protocol commands.

You can use some of the SMTP event interfaces included in the CDO for Windows 2000 library with Visual Basic or scripting languages. The remaining SMTP and NNTP transport and protocol events support only C++.

In addition to the events that CDO for Windows 2000 provides, you can register events at each stage of Exchange message processing. Event sinks have access to the message stream and message properties, and can modify the message or block its delivery.

Performance Issues

All transport and protocol events are synchronous. Because the transport waits for the event sink to finish processing, it is important to write efficient code for these event sinks.

Security Issues

Transport and protocol event sinks have full access to the contents of every message passing through your SMTP and NNTP transports. They can make copies of any message and route information to other addresses. They can discard any message or block any SMTP or NNTP connection attempt. It is important to restrict who can register event sinks and to ensure that sinks do not create security exposures.


Chapter 16 Upgrading and Coexisting

This chapter explains the process of upgrading to Microsoft Exchange 2000 Server and discusses strategies you can use to allow earlier versions of Exchange to coexist with Exchange 2000 Server.

This chapter is divided into four sections:

Directory Concepts This section explains the relationship between the earlier Exchange directory service and Windows NT user accounts and describes how that association relates to Active Directory. In addition, this section provides an overview of the tools and strategies you can use to populate Active Directory.

Preparing for Exchange 2000 Server This section provides an overview of important Active Directory planning concepts that intersect with Exchange 2000 planning concepts.

Upgrading Your Exchange Organization This section explains strategies you can use to upgrade your current Exchange infrastructure to Exchange 2000 Server.

After the Upgrade This section provides a high-level overview of coexistence functionality between Exchange 4.0 and 5.x and Exchange 2000 Server.


Directory Concepts

Although many components and features are upgraded in Exchange 2000 Server, one of the most important aspects of your upgrade is the synchronization between the Exchange 5.5 directory service and Active Directory. Thus, before you read this chapter, you should understand the concepts behind Active Directory. At minimum, read the Active Directory documentation that is included with Windows 2000 Server. In addition, Microsoft recommends that you understand Active Directory and concepts related to synchronizing Active Directory with the Exchange directory service. For more information about these topics, see the Windows 2000 Server Resource Kit Deployment Planning Guide.

Managing Two Directories

Although directory synchronization is important for several reasons, perhaps the most practical reason is that when you install the first instance of Exchange 2000 Server, users with mailboxes on the server must have a complete global address list that displays users residing in Active Directory and users residing in the directory service of earlier versions of Exchange.

The following sections explain the relationship between the directory service for earlier versions of Exchange and Windows NT user accounts and describe how this association relates to Active Directory. Understanding these relationships helps you make informed decisions as you plan the upgrade strategy for your existing Exchange organization.

Exchange Directory Service and Windows NT User Accounts

In Windows NT 4.0 and earlier versions of Exchange, when you create a user and give that user a mailbox, you associate a Windows NT user account with a mailbox object in the Exchange directory. A Windows security identifier (SID) is a unique number that makes this association. Every computer and user account on a network running Windows NT has a SID.

The following illustration shows the relationship between an Exchange 5.5 mailbox and a Windows NT user account. Note that these objects are for illustrative purposes only; they do not include all of the attributes present in an Exchange mailbox object.

Figure 16.1 Earlier versions of Exchange and Windows NT

When you upgrade to Windows 2000 Server, Active Directory preserves the SID from Windows NT accounts.

Active Directory User Objects

Unlike earlier versions of Exchange and Windows NT, Active Directory contains a single object that has default user attributes and Exchange-specific attributes. The following illustration shows a partial representation of an Exchange-enabled object.

Figure 16.2 Exchange-enabled Active Directory object

Notice that the Active Directory object contains a SID attribute. Exchange attributes include MailboxStore and StorageLimits.

Directory Synchronization

When you populate Active Directory with user objects in an environment that includes an earlier version of Exchange, the user objects in Active Directory do not include Exchange-specific attributes. When you install Exchange 2000, Exchange extends user objects in Active Directory to include Exchange-specific attributes.

Active Directory Connector (ADC) populates and synchronizes Active Directory with mailbox, custom recipient, distribution list, and public folder information from the Exchange 5.5 directory. ADC also populates and synchronizes the Exchange 5.5 directory with user, contact, and group information from Active Directory.

Populating Active Directory

Before synchronization can occur, you must populate Active Directory with user information from your existing directory service. You can consider Active Directory populated when Windows NT 4.0 user account information and Exchange-specific object information from the Exchange 5.5 directory service reside in Active Directory.

Your deployment plan may require combining the following methods.

User Information from Windows NT

You can use two methods to populate Active Directory with Windows NT user account information from an existing Windows NT 4.0 deployment:

  • Upgrade existing Windows NT 4.0 user accounts

  • Use Active Directory Migration Tool to create cloned user accounts that preserve security information

    Important Regardless of how you populate Active Directory, you must run ADC to synchronize the directories.

Upgrade Existing User Accounts

One method of populating Active Directory is to upgrade the Windows NT primary domain controller in the domain with your user accounts to a Windows 2000 domain controller. When you upgrade a Windows NT user account, you preserve all account information, including the SID.

Active Directory Migration Tool

The second method of populating Active Directory is to use Active Directory Migration Tool to clone the accounts in Active Directory.

A cloned account is an account in a Windows 2000 Server domain for which account properties and group memberships have been copied from a Windows NT 4.0 source account to a new (cloned) user object in Active Directory. Although the new user object has a different SID than the source account, the SID of the source account is copied to the new user object’s SIDHistory attribute. Populating the SIDHistory attribute with the SID of a source account allows the new user account to access all network resources available to the source account, providing that trusts exist between resource domains and the cloned account domain.

When you run Active Directory Migration Tool, you specify a source Windows NT account (or domain) and a target container in Active Directory in which Active Directory Migration Tool creates cloned accounts.

For more information about Active Directory Migration Tool, visit the Microsoft Web site at http://www.microsoft.com.

User Information from Exchange

With ADC, you configure connection agreements to synchronize the Exchange directory with Active Directory. ADC synchronizes Active Directory objects that have the same SID as objects in the Exchange directory.

If ADC finds a user object in the Exchange directory without a matching SID in Active Directory, ADC creates a user object in Active Directory and stores the existing SID in the SIDHistory attribute of the new object.

Note ADC matches objects in both directories. By default, ADC searches for the Windows NT User account SID before searching for a new object's SID history. For more information about customizing ADC search criteria, see the Exchange online documentation.

Strategies for Populating Active Directory

After you run ADC connection agreements, all user accounts from your earlier Exchange organization are represented in Active Directory. Until you run ADC, you have the option of populating Active Directory by upgrading existing user accounts or by using Active Directory Migration Tool to create cloned accounts.

Note In this discussion of upgrade strategies, Active Directory user accounts refers to Active Directory user objects. For clarity, the term user accounts refers to both Windows NT accounts and Active Directory user objects.

Depending on the objects that exist in Active Directory, you may need to run Active Directory Account Cleanup Wizard after you create the ADC connection agreement. Also, you may not need to upgrade remaining Windows NT user account domains after you create the ADC connection agreement. How you populate Active Directory depends on your domain structure, deployment timeline, Windows upgrade plan, and business needs. Be sure to work out a thorough plan before you implement any of the following strategies.

The following table shows five strategies that you can use to populate Active Directory. Notice that the strategies implement the methods described in the previous section. Your situation may require you to use more than one of these strategies.

 | Phase 1 | Phase 2 | Phase 3
1 | Perform Windows NT 4.0 in-place upgrade. | Run ADC to synchronize Exchange 5.5 mailboxes with Windows 2000 accounts. |
2 | Use Active Directory Migration Tool to create new Windows 2000 accounts. | Run ADC to synchronize Exchange 5.5 mailboxes with Windows 2000 accounts.
3 | Run ADC to synchronize Exchange 5.5 mailboxes with new disabled Windows 2000 accounts. | Perform Windows NT 4.0 in-place upgrade. | Use Active Directory Account Cleanup Wizard to merge accounts created by ADC with upgraded Windows 2000 accounts.
4 | Run ADC to synchronize Exchange 5.5 mailboxes with new disabled Windows 2000 accounts | Use Active Directory Migration Tool to create new cloned Windows 2000 accounts | Use Active Directory Account Cleanup Wizard to merge accounts created by ADC with cloned Windows 2000 accounts
5 | Run ADC to synchronize Exchange 5.5 mailboxes with new disabled Windows 2000 accounts. | Enable accounts created by ADC. | Run Active Directory Migration Tool to match Windows NT 4.0 accounts to accounts created by ADC.

These strategies provide a phased approach to populating Active Directory for Exchange 2000 Server. While these are comprehensive in scope, this chapter does not describe them in detail. Using these strategies as a template, you can select a strategy that works in your situation. You can find conceptual and procedural details about these phases in the Windows 2000 documentation.

Active Directory Population Strategy 1

The first two strategies begin with populating Active Directory with Windows NT account information and running ADC.

The following illustration shows two steps for the first strategy:

  1. Upgrade the Windows NT user account domain to a Windows 2000 Server domain.

  2. Run ADC to synchronize directories and Exchange 5.5 mailboxes with Windows 2000 accounts.

Figure 16.3 Active Directory population strategy 1

If your user accounts are consolidated into user domains, one method you can use to populate Active Directory is to upgrade the primary domain controller in these domains to a Windows 2000 Server domain controller. This upgrades Windows NT user accounts to Active Directory user accounts and preserves the original SIDs in the Active Directory user accounts.

To synchronize the Exchange 5.5 directory service with Active Directory and to add information from the Exchange 5.5 directory service to the user accounts in Active Directory, you must establish connection agreements with ADC.

Active Directory Population Strategy 2

If you use Active Directory Migration Tool to populate Active Directory, use the strategy that the following illustration shows:

  1. Create a Windows 2000 Server domain.

  2. Run Active Directory Migration Tool to create cloned user accounts in the Windows 2000 Server domain.

  3. Run ADC to synchronize directories and add Exchange-specific information to cloned Windows 2000 user accounts.

Figure 16.4 Active Directory population strategy 2

This strategy allows you to deploy Exchange 2000 Server in your organization before you upgrade your entire Windows NT domain structure. After you run ADC, you can install Exchange 2000 or upgrade to Exchange 2000 immediately.

Active Directory Population Strategy 3

You begin the remaining strategies by running ADC to create disabled user accounts in Active Directory. The third strategy allows you to deploy Exchange 2000 before you upgrade your Windows NT domain infrastructure because you can deploy Exchange 2000 after you run ADC. The following illustration shows the four steps of this strategy:

  1. Create a Windows 2000 Server domain.

  2. Run ADC to synchronize directories and create disabled user accounts that contain Exchange-specific information in the new domain.

  3. Upgrade Windows NT user account domains. You do not have to upgrade all domains at the same time.

  4. As you upgrade each domain, run Active Directory Account Cleanup Wizard to merge accounts created by ADC with upgraded Windows 2000 accounts.

Figure 16.5 Active Directory population strategy 3

This strategy includes two Windows 2000 Server domains. One domain serves as the target for ADC, while the other is the domain that you upgrade to Windows 2000 Server; one of these domains is a transition domain. A transition domain is a domain that you create during the migration and upgrade phases of deployment to serve as a holding place for Active Directory objects and configuration information. Depending on your deployment strategy, after you deploy Windows 2000 Server and Exchange 2000 Server, you can disable the transition domain. It is important to include a transition domain in your overall deployment strategy.

After you upgrade the Windows NT user account domain, two user objects reside in Active Directory for each user:

  • A disabled user object, created by ADC, which contains Exchange-specific information

  • An enabled user object, created by the in-place upgrade, which contains Windows NT user account information

To merge these two objects you must run Active Directory Account Cleanup Wizard. For more information about Active Directory Account Cleanup Wizard, see “Active Directory Account Cleanup Wizard” later in this chapter.

Active Directory Population Strategy 4

In this strategy, instead of upgrading the Windows NT user accounts, Active Directory Migration Tool creates cloned user accounts in Active Directory. The following illustration shows the four steps of this strategy:

  1. Create a Windows 2000 Server domain.

  2. Run ADC to synchronize directories and create disabled user accounts that contain Exchange-specific information in the new domain.

  3. Create a transition domain and run Active Directory Migration Tool to create cloned Windows 2000 user accounts in the transition domain.

  4. Run Active Directory Account Cleanup Wizard to merge user accounts created by ADC with the cloned Windows 2000 user accounts.

Figure 16.6 Active Directory population strategy 4

This strategy includes two Windows 2000 Server domains. One domain contains user accounts with Exchange-specific information from ADC and the other domain contains cloned user accounts that Active Directory Migration Tool creates; one of these domains is a transition domain.

Active Directory Population Strategy 5

In this strategy, you enable the accounts that ADC creates and then merge these accounts with existing accounts using Active Directory Migration Tool. The following illustration shows the four steps of this strategy:

  1. Create a Windows 2000 Server domain.

  2. Run ADC to synchronize directories and create disabled user accounts that contain Exchange-specific information in the Windows 2000 Server domain.

  3. Enable the user accounts created by ADC.

  4. Run Active Directory Migration Tool to match to existing Windows NT 4.0 user accounts with user accounts created by ADC in the new Windows 2000 Server domain.

Figure 16.7 Active Directory population strategy 5


Preparing for Exchange 2000 Server

Although Exchange 2000 Server requires Active Directory to be running, you do not have to fully deploy Windows 2000 and Active Directory before you install Exchange 2000. Exchange requires only that a base directory be in place. In other words, you don’t need to upgrade your entire Windows NT 4.0 infrastructure to Windows 2000 Server before you can upgrade to Exchange 2000; however, you should not design and deploy Active Directory independently for Exchange unless you are setting up a test domain for pilot purposes only.

Running Active Directory in your organization consists of installing Windows 2000 Server and establishing a forest. You can do this by upgrading an existing Windows NT 4.0 domain or by creating a new Windows 2000 domain.

This section provides an overview of Windows 2000 concepts to consider as you plan your upgrade strategy.

Group Management Domain

When you run Exchange 2000 Server, universal security groups perform the same function as distribution lists. In earlier versions of Exchange, you can use distribution lists to send mail to groups and set permissions on Exchange objects such as public folders. Exchange distribution lists can include members from any Exchange site and can exist within other distribution lists. Exchange distribution groups are analogous to universal groups in Windows 2000.

To preserve distribution group functionality for controlling access to Exchange resources in your Windows 2000 and Exchange 2000 environment, you must create a group management domain. A group management domain is a Windows 2000 Server domain running in native mode that uses ADC to maintain distribution list data from an Exchange 5.5 site. You can use any Windows 2000 Server domain running in native mode as a group management domain.

Note If your strategy for populating Active Directory includes creating a transition domain, you can use the transition domain as a group management domain.

Your topology dictates whether you need more than one group management domain. If you have multiple domains that manage distribution lists, you must set up an ADC connection agreement to each of these domains before you upgrade to Exchange 2000 Server.

If you do not want to use universal security groups or switch a Windows 2000 Server domain to native mode, you can use domain local or domain global groups to control public folder access. This method requires continual maintenance and administration as your organization changes. For more information about group management and security, see the Exchange online documentation.

Windows 2000 and Active Directory

Because Exchange 2000 depends on Active Directory, three primary requirements must be fulfilled before you install Exchange 2000 Server:

  • You must install Exchange 2000 Server on a computer running Windows 2000 Server in a Windows 2000 Server domain.

  • Each Exchange 2000 server must have a high-speed connection to a global catalog server.

  • ADC connection agreements must synchronize Active Directory objects with user or mail-specific objects that you need access to in Exchange 2000 Server.

In addition, if you need a group management domain, one Windows 2000 Server domain in your forest must run in native mode.

As you plan your strategy for deploying Active Directory, keep in mind that the first Windows 2000 Server domain within a forest plays an important role:

  • The name of the first Active Directory domain is the name of the forest.

  • You cannot create parent domains above the first domain.

  • You cannot remove the first domain.

Windows 2000 Sites

Do not confuse the meaning of the term site in Windows 2000 with the meaning of the term site in earlier versions of Exchange. Although both concepts of a site rely on full-time, high-bandwidth connectivity, a site in Windows 2000 is different than a site in earlier versions of Exchange. Sites in Windows 2000 do not involve administering namespaces and domains.

The way you define your sites in Windows 2000 affects the performance and scalability of your Exchange organization. All servers running Exchange 2000 must have a high-bandwidth connection to a global catalog server. In most cases, this requires that at least one global catalog server exist in each Windows 2000 site. If more than one global catalog server exists in a single Windows 2000 site, Exchange balances requests to these servers. If two Windows 2000 sites have a high-bandwidth connection, you may be able to run an Exchange 2000 server in the site in which no global catalog server exists. Exchange clients also use global catalogs for address book lookups.

For more information about sites in Windows 2000, see the Windows 2000 documentation.

Schema

The schema defines all objects in Active Directory. For each type of object (called a class), the schema contains a definition of the attributes an instance of that class must have, any additional attributes an instance of the class can have, and whether an instance of that class can be the parent of another class.

The schema is updated twice during your Exchange 2000 upgrade process: once when you install the Exchange 2000 version of ADC, and once when you install the first instance of Exchange 2000 Server in your organization. For more information about the Exchange 2000 version of ADC, see the following section.

You may choose to update the schema prior to installing the first instance of Exchange 2000 Server in your organization. If you delegate schema administration to someone else, consider having the schema administrator run ForestPrep, a utility that updates the schema prior to the first installation of Exchange 2000 Server.

If you update the schema before you install Exchange 2000, the first person to install Exchange 2000 does not have to be a member of the Schema Admin security group.

In addition, if you have multiple domains in your forest, you do not need to update the schema on all domain controllers; this occurs automatically after you update the schema. Thus, if you update the schema first, schema replication can occur before you install Exchange for the first time. For more information about ForestPrep, see Chapter 19, “Installing Exchange.”

Active Directory Connector

There are two versions of Active Directory Connector (ADC): one for Windows 2000 Server and one for Exchange 2000 Server. The version included with Windows 2000 Server populates Active Directory with users and contacts for use with Windows 2000. The version included with Exchange 2000 Server adds enhanced Exchange 2000 functionality that updates the Windows 2000 schema when you install Exchange for the first time.

If you have already upgraded your operating system to Windows 2000 Server across your organization, you may have already installed the version of ADC included with Windows 2000 Server.

If you are installing Exchange 2000 in an organization running an earlier version of Exchange, you must run at least one instance of the Exchange 2000 ADC before performing your upgrade. As you upgrade your earlier Exchange organization, you should also upgrade other user connection agreements that are running the version of ADC included with Windows 2000. Using only the version of ADC included with Exchange 2000 is recommended but not required.

User Connection Agreements

User connection agreements that you configure for ADC exchange recipient information between an Exchange 5.5 site and a Windows 2000 domain controller. The user connection agreement is commonly called a connection agreement. There is also a second kind of connection agreement, called a configuration connection agreement, which Exchange 2000 configures automatically during installation. The following section discusses configuration connection agreements. For a comprehensive discussion on creating user connection agreements, see the Exchange online documentation.

Even if you do not create all necessary connection agreements, Exchange generates user connection agreements for mixed-mode organizations after you manually configure at least one connection agreement. Exchange creates these connection agreements only when you install Exchange in an existing organization in which Exchange 5.5 sites with no connection agreements exist. Connection agreements that Exchange generates are set to Never replicate so that you can review the settings before ADC replicates data.

If you configure the necessary connection agreements between your Exchange 5.5 organization and Active Directory, no additional user connection agreements appear.

Configuration Connection Agreements

During an upgrade, Exchange 2000 Setup creates a configuration connection agreement between Active Directory and the earlier Exchange site. Exchange creates configuration connection agreements automatically.

The following illustration shows the Active Directory Connector Management snap-in with three connection agreements. The second item in the results pane, Config CA_Houston_SAUELAB15C, is a configuration connection agreement created by Exchange 2000 Setup. The other connection agreements are created before you run Setup.

Figure 16.8 Active Directory Connector Management snap-in

Prerequisites for Active Directory Connector

To use Active Directory, each Exchange site must have at least one server running Exchange 5.5 Service Pack 1 (SP1) or later; for example, if you are running multiple versions of Exchange Server 5.0 or earlier within a site, your first step in the upgrade process is to upgrade at least one server to Exchange 5.5 SP1.

Important Although ADC requires a connection to a server running Exchange 5.5 SP1 or later, upgrading to Exchange 2000 requires a server running Exchange 5.5 SP3. For more information about upgrade requirements, see “Upgrading Your Exchange Organization” later in this chapter.

After all sites have at least one server running Exchange 5.5 SP1, you can use ADC to create a connection agreement from each Exchange 5.5 site to Active Directory.

Active Directory Account Cleanup Wizard

You may encounter a situation in which a Windows 2000 Server domain contains several Windows NT accounts for the same individual. This can happen if you use different tools to populate Active Directory with account information. You can create new accounts when you upgrade a Windows NT 4.0 domain to Windows 2000; when you run Active Directory Connector, Exchange mail connectors, Exchange Migration Wizard, or Active Directory Migration Tool; or when you use other network tools for Windows 2000. Each account referring to the same individual contains different information based on the application that created it.

For example, when you upgrade the first Exchange 5.5 server to Exchange 2000, and ADC is installed between the Exchange 5.5 servers and Active Directory, ADC populates Active Directory with user accounts for every item in the Exchange 5.5 system, effectively upgrading the Exchange 5.5 directory to Active Directory. ADC matches Exchange 5.5 users with existing Active Directory accounts if an account was upgraded from Windows NT before you installed ADC.

Active Directory Account Cleanup Wizard is a tool that performs the following functions:

  • Searches a Windows 2000 forest for possible duplicate Windows NT accounts

  • Allows you to review and change the duplicate accounts

  • Allows you to manually match duplicate accounts

  • Merges duplicate accounts into a destination account that you select

When you merge duplicate accounts, group and distribution list membership is preserved, access to existing resources is unaffected, and all available attributes are retained.

Important Active Directory Account Cleanup Wizard searches and merges accounts only within the same forest.


Upgrading Your Exchange Organization

This section provides you with a high level plan for upgrading to Exchange 2000 Server. For step-by-step procedures that explain Exchange Setup, see Chapter 19, “Installing Exchange.”

Prerequisites

This section assumes the following:

  • Exchange 5.5 mailboxes are synchronized with Active Directory.

  • At least one instance of Exchange 2000 ADC is running in your forest.

  • Exchange servers that you are upgrading are running Exchange 5.5 SP3.

  • Exchange servers that you are upgrading meet the minimum requirements described in Chapter 19, “Installing Exchange.”

  • ForestPrep and DomainPrep utilities have been run. If you have the appropriate permissions and you are installing Exchange in the root domain of the forest, you do not need to run ForestPrep and DomainPrep. For more information about ForestPrep and DomainPrep, see Chapter 19, “Installing Exchange.”

If you are running connectors to other mail systems in your current environment, and if Exchange 2000 does not support these connectors, be sure to plan your deployment accordingly. You can keep Exchange 5.5 servers with connectors in your Exchange 2000 deployment as bridgehead servers. Note that Setup does not upgrade an Exchange 5.5 server to Exchange 2000 if the Exchange 5.5 server is running connectors that Exchange 2000 doesn’t support. For more information about which connectors are supported in Exchange 2000 Server and migration strategies, see Chapter 17, “Migrating to Exchange.”

In addition, note that you cannot add an Exchange 5.5 server in an administrative group that contains only Exchange 2000 servers.

Exchange Namespace

When you install the first instance of Exchange 2000 Server in your existing Exchange infrastructure, all existing Exchange sites are matched one-to-one with Exchange 2000 administration groups and routing groups. The following illustration shows the Exchange 5.5 Administrator program interface on the left and the System Manager interface on the right.

Figure 16.9 Exchange Administrator program and System Manager

The three sites (Houston, NewYork, and Seattle) in the illustration match administration groups and routing groups after Exchange 2000 is installed in the Exchange 5.5 organization. Although routing groups exist, they are not visible in the interface.

Site Replication Service

Site Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directories in earlier versions of Exchange. To earlier versions of Exchange, an Exchange 2000 server running SRS appears as an Exchange server that supports intra-site and inter-site directory replication. SRS runs only in a mixed-mode administrative group. SRS is required because ADC does not synchronize configuration; it synchronizes only user information.

SRS performs additional functions, such as detecting and reacting to directory replication topology changes and ensuring that ADC is configured correctly.

SRS is enabled automatically in two situations:

  • On the first Exchange 2000 Server you install in an Exchange site running earlier versions of Exchange

  • When you upgrade an Exchange 5.5 server that is the directory replication bridgehead for a site

You can enable and disable SRS using System Manager. For more information about SRS, see the Exchange online documentation.

Upgrade and Coexistence Methods

All of the methods for upgrading and coexistence that this section describes assume that your organization meets the minimum requirements for installing Exchange 2000 Server. The following table shows where to find information about the issues you need to consider and the requirements your organization must meet before you install Exchange 2000 Server in an existing Exchange 5.5 site and upgrading Exchange 5.5 to Exchange 2000.

Consideration or requirement | Location of information
Minimum hardware requirements | Chapter 19, “Installing Exchange”
Active Directory, Active Directory Connector | Chapter 16, “Upgrading and Coexisting,” Chapter 20, “Synchronizing Active Directory with Exchange Server Directory Service,” in the Microsoft Windows 2000 Server Resource Kit Deployment Planning Guide.”
Setting up connection agreements | Exchange online documentation
Schema concepts | Chapter 16, “Upgrading and Coexisting”
Upgrading the schema | Chapter 19, “Installing Exchange”
Permissions required to install Exchange 2000 Server | Chapter 19, “Installing Exchange”

There are four upgrade and coexistence methods:

  • Join Exchange 2000 Server to an Exchange 5.5 site

  • In-place upgrade of an Exchange 5.5 server

  • Move mailbox

  • Leapfrog

The method you chose depends on your hardware, acceptable downtime, and bandwidth considerations.

Join an Exchange 5.5 Site

When you run ForestPrep, Exchange 2000 Setup allows you to join an Exchange 2000 server to an existing Exchange 5.5 site. After you install the first instance of Exchange 2000 Server in your Exchange 5.5 organization, you can specify for subsequent installations which site you want the new instance of Exchange 2000 Server to join by selecting the corresponding administration group during Setup.

When you join Exchange 2000 Server to an existing Exchange 5.5 site, you must connect to a computer running Exchange 5.5 SP3. For more information about ForestPrep and installing Exchange 2000, see Chapter 19, “Installing Exchange.”

In-Place Upgrade

You can perform an in-place upgrade for servers in your organization running Exchange Server 5.5 SP3. This method involves upgrading the operating system to Windows 2000 Server, taking the server offline, and running Setup.

When you perform an in-place upgrade, Setup does not allow you to add additional components to the existing Exchange 5.5 configuration. After the upgrade, you can run Setup again to add additional components.

If the hardware on which your existing Exchange server runs does not fulfill the minimum requirements for running Exchange 2000, you should consider the move mailbox method that the following section discusses. For more information about performing an in-place upgrade, see Chapter 19, “Installing Exchange.”

Move Mailbox Upgrade

The move mailbox upgrade method involves installing Exchange 2000 on new hardware, joining an existing Exchange site, moving the data to Exchange 2000, and then decommissioning the old Exchange servers. This method offers a number of advantages, which include reduced disruption for users and reduced potential risk. Disadvantages include the cost of purchasing new hardware. You might choose to use this migration method if you want to update your hardware.

You can move mailboxes to an Exchange 2000 server from computers running Exchange 4.0 or later. The following illustration shows the four steps for moving mailboxes to Exchange 2000:

  1. Install Exchange 2000 Server on new hardware.

  2. Instruct the users whose mailboxes you are moving to exit Microsoft Outlook and other mail applications.

  3. Move mailboxes to the Exchange 2000 server.

  4. Instruct the users to log back in to Outlook. Client profiles are updated automatically.

  5. Remove the Exchange 5.5 server and use it elsewhere.

Figure 16.10 Move mailbox upgrade method

Following are the steps you need to take to move public folders to Exchange 2000:

  1. Replicate existing public folders on the server to the new Exchange 2000 server.

  2. Remove the public folders from the existing server.

Users automatically connect to the Exchange 2000 public folder the next time they log on.

Leapfrog Upgrade

The leapfrog upgrade method is similar to the move mailbox method described earlier. One of the main drawbacks of the move mailbox method is that purchasing new servers can be costly. If your existing servers meet Exchange 2000 hardware requirements, you can use the leapfrog upgrade method, which requires that you purchase only one or two new computers to upgrade the entire organization.

The following illustration shows the five steps of the leapfrog upgrade method:

Servers X and Y are running earlier versions of Exchange.

  1. Install Exchange 2000 Server on server Q.

  2. During a period of low activity, move all of the users on server X to server Q.

  3. Use the in-place upgrade method to upgrade server X.

  4. During a period of low activity, move all users on server Y to server X.

  5. Use the in-place upgrade method to upgrade server Y for another set of users.

Figure 16.11 Leapfrog upgrade method

The advantage of the leapfrog upgrade method is that mail service is never suspended; instead, users’ mailboxes are inaccessible only for the amount of time it takes to move their mailboxes from one server to the next.

Outlook Web Access Upgrade

If you are currently running Microsoft Outlook Web Access on a server running Exchange 5.5, upgrading to Exchange 2000 automatically replaces your existing configuration.

Important If you have customized the Outlook Web Access .asp files, these pages no longer work after you upgrade to Exchange 2000 Server. The customized .asp files remain in the Exchsrvr\Webdata directory.

To preserve customization of Outlook Web Access, you can run Exchange 5.5 Outlook Web Access with Exchange 2000 back-end servers; however, you receive none of the scalability or performance improvements available with Exchange 2000 Server. Using earlier versions of Outlook Web Access is recommended as a temporary measure only; for example, when you are upgrading an Exchange back-end server.

When you upgrade your Outlook Web Access front-end and back-end architecture to Exchange 2000, you can avoid disrupting service or changing your users’ URL addresses by deploying Exchange 2000 in stages.

Important You cannot perform an in-place upgrade for an Outlook Web Access front-end server without first upgrading the corresponding back-end server.

One option is to upgrade some of your front-end and back-end servers to Exchange 2000 Server. In the following illustration, early adopters in your organization (users who don’t mind learning a new URL for Outlook Web Access) can connect to an Exchange 2000 front-end server to reach their mailboxes that are on an upgraded back-end server. Meanwhile, remaining users can continue using Exchange 5.5 Outlook Web Access with earlier versions of Exchange running on the back-end servers. Their URL does not change and ASP customization is preserved until these servers are upgraded.

Figure 16.12 Upgrading Outlook Web Access in stages

If you don’t want to perform an upgrade in stages, all users can continue using Exchange 5.5 Outlook Web Access in an Exchange 2000 environment. Once your back-end servers are upgraded and you’re ready to move your Outlook Web Access users to Exchange 2000, you have two choices. You can take Outlook Web Access offline for the amount of time necessary to upgrade the server to Exchange 2000 or you can prepare another Exchange 2000 front-end server and change Domain Name Service (DNS) to point users to the new server. The users’ URLs do not change and Outlook Web Access is available continuously.

Note You cannot install additional Exchange 5.5 front-end servers if the corresponding back-end server is running Exchange 2000.

Chat Service Upgrade

If you run Chat Service with Exchange 5.5, you may have settings or configurations that you want to continue using after you install Exchange 2000 Chat Service. The chat migration tool enables you to create a new chat community on an Exchange 2000 server and retain the name, most of the settings, and the configuration of the Exchange 5.5 chat server.

Note The migration tool does not migrate extension data from the earlier version of Chat Service; therefore, if you have a Profanity Filter or Transcription Extension, you must migrate these manually so that they work with Exchange 2000 Chat Service.

The chat community you create with the migration tool is separate from your Exchange 5.5 chat server. Also, if your Exchange 5.5 chat installation consists of one Chat Service that spans a network of two or more Exchange servers, you must now create similar chat communities on each of your Exchange 2000 servers. Each Exchange 2000 chat community in your domain must operate separately, with separate user lists and channel lists.

To migrate to Exchange 2000 Chat Service from an earlier version:

  1. Install Windows 2000 Server on your target server and either create a new domain or configure the server as a member server of an existing domain.

    Note For this procedure, the source of the migration tool is the server running the earlier version of Chat Service; the target of the migration tool is the server running Exchange 2000 Chat Service.

    If you are installing Exchange 2000 on a network of servers on which the earlier version of Chat Service spans two or more servers, upgrade all computers to Windows 2000 Server and either create a new domain or configure each computer as a member server of an existing domain. All servers must belong to the same domain.

  2. Exchange 2000 Chat Service and earlier versions of Chat Service have the same display name. If you are installing Exchange 2000 Chat Service on a computer with the earlier version of Chat Service, you must modify the name as follows:
    • Open the properties on the earlier version of Chat Service and modify Display Name using the Services node of the Computer Manager Microsoft Management Console (MMC) snap-in.

      Note A possible name to use is Microsoft Exchange Chat 5.5, but you can type any name you choose.

    • Reconfigure the ports so that the earlier version of Chat Service does not use the default port 6667 or the alternate default port 7000.
  3. Install Exchange 2000 Chat Service on each target computer.
  4. Run the Chat migration tool, Chatmig.exe, from the Exchsrvr\Bin directory, and specify the target. The target must be the administration group to which you want to migrate Chat Service.

    After you run the migration tool, a new chat community is created on the Exchange 2000 server with the name of the existing chat server. The new chat community has similar server, channel, ban, and class configurations. Until you are ready to use the Exchange 2000 server, both versions of Chat Service can run simultaneously.

    • If you are installing Exchange 2000 Chat Service on a server that is separate from the one on which the earlier version of Chat Service exists, copy the migration tool from the Exchsrvr\Bin directory on the target server to the source server. Run the Chat migration tool, identifying the earlier Chat Service directory as the source and the Exchange 2000 Chat Service directory as the target.

    • If you are installing Exchange 2000 Chat Service on a network on which the earlier version of Chat Service spans two or more servers, select one server to use for the base configuration. Run the chat migration tool on the base server first.
  5. Verify that all configuration information has migrated to the Exchange 2000 Chat Service using the MMC snap-in.

    Note You can also check the Chatsetup.log file that the migration tool produces. This log is located in the Exchsrvr directory.

    If you are installing Exchange 2000 on a network of servers on which the earlier version of Chat Service spans two or more servers, do the following:

    • On the server you are using for the base configuration, use the MMC snap-in to make sure the new chat community and its associated configuration exists.

    • On the base server, using the System Manager IRCX protocol snap-in, verify that the community created during migration is set to be hosted by this server.

    • On all the other servers in the existing chat network, using the System Manager IRCX protocol snap-in for each server, configure the server to host the chat community you created during the migration of the first server. Configure the IP address, ports, and any extensions.

    • Run the migration tool on each of the other servers in the existing chat network, creating a new Exchange 2000 chat community on each server.
  6. Uninstall the earlier version of Chat Service using the uninstaller.


After the Upgrade

Now that your server is running Exchange 2000 Server, you can take advantage of the new features in Exchange. Some actions to consider include:

  • Creating multiple storage groups and dividing users between storage groups to improve recovery times.

  • Configuring Instant Messaging and Chat Service for real-time collaboration.

  • Creating or modifying applications to use new features, such as URL access to objects in the Information Store and specific permissions for items and properties in public folders.

For more information about configuring these and additional features, see the Exchange online documentation.

Administering Two Versions of Exchange

After you introduce Exchange 2000 Server into your existing Exchange infrastructure, you must administer the messaging functionality of each version of Exchange through its own user interface; however, the exception to this is when you are administering user objects. Once you install Exchange 2000 and configure the proper connection agreements, Microsoft recommends that you perform all user management with the Active Directory Users and Computers snap-in, including user management for those users who are still using earlier versions of Exchange.

The entire messaging organization appears in the interface of both System Manager (Exchange 2000) and the Administrator program (earlier versions of Exchange). If you try to configure an Exchange 2000 object that appears in the Administrator program, the changes you make appear to succeed; however, those changes are not carried out on Exchange 2000 objects. System Manager does not allow you to change objects that are managed only by earlier versions of Exchange.

When administering earlier versions of Exchange and Exchange 2000 Server in the same organization it is important to:

  • Administer Exchange 2000 servers from System Manager.

  • Administer Exchange 5.5 servers from the Administrator program.

  • Manage users from the Active Directory Users and Computers snap-in (recommended).

Switching to Native Mode

Running your Exchange organization in mixed mode ensures future interoperability between Exchange 2000 servers and earlier versions of Exchange; however, running in mixed mode limits the functionality of Exchange 2000 Server. You should maintain your organization in mixed mode only if your organization must interoperate with earlier versions of Exchange currently and in the future.

For more strategies and information about how to achieve coexistence between Exchange 5.5 and Exchange 2000, see the Exchange online documentation.

You should change your Exchange 2000 organization to native mode if:

  • Your organization will never require interoperability between Exchange 2000 servers and earlier versions of Exchange. (Connectors can provide connectivity to earlier Exchange servers, but the administration and namespace of earlier Exchange servers is separate.)

  • Earlier versions of Exchange exist in an Exchange organization that is separate from your Exchange 2000 servers.

Important After you switch an Exchange 2000 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode.


Chapter 17 Migrating to Exchange

Many organizations have a messaging system in place when they decide to deploy Microsoft Exchange 2000 Server. In addition, some organizations have a business requirement to send messages to and share directory information with other messaging systems. To make it easy for you to deploy Exchange in your organization, Exchange includes a suite of tools that support the following business scenarios:

  • Coexisting with an earlier version of Exchange

  • Coexisting with another mail system while you are migrating to Exchange

  • Long-term messaging connectivity with other mail systems

This chapter focuses on how organizations can migrate to Exchange while coexisting with another mail system. It provides an overview of the things you need to consider when planning, implementing, and testing a coexistence and migration strategy for your organization.

For information about coexistence between earlier versions of Exchange and Exchange 2000 Server, see Chapter 16, “Upgrading and Coexisting.” For information about long-term messaging connectivity with other mail systems, see the Exchange online documentation.


Understanding Coexistence

Exchange connectors support message transfer, directory synchronization, and calendar querying. When you use connectors between Exchange and another messaging system, the two systems coexist. This period of coexistence may be short; perhaps you only need time to migrate users from your existing messaging system to Exchange. In other cases, you may want long-term coexistence; perhaps a permanent connection to the messaging system of another department that is not moving to Exchange.

When connectors to other messaging systems are in place, the user experience is similar on both messaging systems. The exchange of e-mail and other information between Exchange and the other messaging system is transparent to the user, even if the two systems function differently.

In addition to the connectors that Exchange provides, there are third-party connectors and gateways that you can use to connect Exchange to your existing messaging system.

Connecting to Other Systems

Maintaining messaging connectivity between Exchange and another messaging system is one of the primary goals of any coexistence strategy. Exchange uses the following connectors to provide messaging connectivity over LAN, asynchronous, or X.25 connections:

  • Exchange Connector for Lotus Notes

  • Exchange Connector for cc:Mail

  • Exchange Connector for Novell GroupWise

  • Microsoft Mail Connector for PC Networks

  • Microsoft Schedule+ Free/Busy Connector

In addition to message transfer, the connectors for Lotus Notes, cc:Mail, GroupWise, and Microsoft Mail support directory synchronization.

Calendaring functions such as meeting invitations are supported for Lotus Notes, Novell GroupWise, and Microsoft Mail (using the Schedule+ Free/Busy Connector).

For more information about connectors and how to use multiple connectors, see the Exchange online documentation.

Directory Synchronization

Directory synchronization is the process of propagating directory information for Exchange users from Microsoft Windows 2000 Active Directory to the directory of another messaging system, while propagating information for users of the other messaging system to Active Directory for Exchange to use. When directory synchronization is finished, each system has a complete copy of the directory for your entire organization. This ensures that users on one system can send e-mail to users on the other system.

Active Directory uses directory objects to represent Exchange users and users on other messaging systems that are synchronized with Exchange. When you configure directory synchronization using a connector, users, contacts, and groups can be added to Active Directory. For more information about users, contacts, and groups, see Chapter 5, “Active Directory.”


Understanding Migration

Migration is the process of moving your existing messaging system to Exchange. It involves making a copy of your existing mailboxes, messages, and other data, and importing that information into Exchange.

Microsoft provides many tools to allow you to migrate users, messages, calendar information, and custom applications from your existing messaging system. You can use these tools to prevent system downtime, minimize the impact on users, and prevent data loss.

Migration Wizard

The primary Exchange migration tool is Migration Wizard, a stand-alone application that you can install on your computer while running the Exchange Setup program. You can use Migration Wizard to migrate users from the following systems:

  • Microsoft Mail for PC Networks version 3.x

  • Lotus cc:Mail database versions DB6 and DB8

  • Lotus Notes version 4.x

  • Novell GroupWise versions 4.x and 5.x

  • Any Lightweight Directory Access Protocol (LDAP) compliant Internet directory service

  • Any Internet Message Access Protocol, Version 4rev1 (IMAP4) compliant Internet messaging system

  • Collabra Share versions 1.x and 2.x

How Migration Wizard Works

Migration Wizard consists of two types of components: source extractors and the migration file importer.

Source extractors copy directory information, messages, calendar information, and collaboration data from existing messaging systems and save the data in a set of files using migration file format. This is the first step of migration.

After the information is in migration file format, the migration file importer imports the information so it is accessible to Exchange users. This is the second step of migration. You can complete this two-step process in separate stages or by running the Migration Wizard once.

When Migration Wizard imports data into Exchange, it adds messaging and calendar data to the Information Store. It adds user information from the directory of the other messaging system to Active Directory.

Although Migration Wizard serves as both the source extractor and migration file importer for data from many types of messaging systems, third-party and custom source extractors are also available. If you use a separate source extractor to create migration files, you can still use Migration Wizard to import your migration files into Exchange.

For information about using Migration Wizard, see the Exchange online documentation.

Migration and Active Directory

When Migration Wizard imports directory information from your existing messaging system into Exchange, it writes information to Active Directory. Migration Wizard copies the user information from the source directory, searches Active Directory to find matches, and adds the information to the matching object or creates a new object based on the migrated information.

Although Migration Wizard compares existing Windows user accounts in Active Directory to accounts it is migrating from your source directory, duplicate accounts may be created during migration. In addition, because there are many ways to populate Active Directory, for example, by upgrading a Windows NT domain or using Active Directory Connector (ADC) or Exchange connectors, multiple user accounts for the same user may be created in the same Windows 2000 forest. Each account contains information specific to the application that created the account.

To help you manage duplicate user accounts, Exchange provides Active Directory Account Cleanup Wizard. This wizard searches a Windows 2000 forest for possible duplicate Windows 2000 accounts and allows you to change duplicate accounts. Active Directory Account Cleanup Wizard is located in the Support\Adclean\I386 directory on the Exchange compact disc. The file name is Adclean.exe. For more information about the Active Directory Account Cleanup Wizard, see the Exchange online documentation.

Additional Migration Tools

In addition to Migration Wizard and Active Directory Account Cleanup Wizard, Exchange includes the following migration tools:

  • Additional source extractors, which complement the import functionality of Migration Wizard for the IBM PROFS, NetSys (formerly Verimation) MEMO, Digital ALL-IN-1 host systems, and Microsoft Mail for AppleTalk Networks.

  • Personal message archive importers, including the Microsoft Outlook 2000 Import feature and Microsoft Importer for Lotus cc:Mail Archives, which allow you to import personal mail archives.

  • Exchange Application Converter for Lotus Notes, a set of tools that enables you to migrate complex Notes applications into Outlook 2000.

For more information about these tools, see the Exchange online documentation.


Managing a Successful Migration

There are many factors to consider in planning a migration, all of which impact the success of the migration. It may be helpful to create a document that describes your migration strategy in detail and potential problems and solutions.

A typical migration should include the following:

  1. Creating a migration team.

  2. Choosing when and how to move users (single- or multi-phase migration).

  3. Using connectors for coexistence.

  4. Planning a coexistence strategy.

  5. Identifying key migration tasks and planning their completion.

  6. Testing migration.

Creating a Migration Team

The following table represents the roles that need to be present within the migration team. A single individual may perform several roles, or a single role may be delegated to a specialized team, depending on the needs of your organization.

Role | Responsibilities
System architect | Coordinates the design, testing, and implementation of Exchange. Writes the migration plan and distributes it to the team.
Windows 2000 Server and Exchange support specialist | Keeps the servers running, backed up, and optimized.
Client desktop support specialist | Solves client problems.
Network and telecommunications specialist | Understands the existing network, telephone, and modem needs.
Help desk trainer | Trains the support staff to use Exchange.
End user trainer | Trains end users to use Exchange client components.
Testing and implementation specialist | Tests the migration plan and deploys Exchange.
Coexistence specialist | Understands the existing system and how it interacts with Exchange.
Application upgrade specialist | Implements or replaces the existing system’s applications in Exchange.
Deployment consultant | Provides deployment expertise. Contact Microsoft Consulting Services or consulting firms that have Microsoft Solution Provider status to find a consultant.
Training specialist | Handles installation questions.

You may also need additional support people immediately after migrating a large group of users. You might want to train several extra people to be local experts in each group of your organization.

Choosing the Type of Migration

You can move users from your existing messaging system to Exchange in a single phase or in multiple phases. Migrating in multiple phases allows for comprehensive testing of the process and the new system, but also requires more planning and a clear understanding of the requirements for successful coexistence.

Single-Phase Migration

Single-phase migration moves all users on your existing messaging system to Exchange at the same time. Single-phase migration may be a good choice if you have:

  • An organization with fewer than 500 users or 5 post offices, or little or no data to move from your existing system.

  • A larger organization with a large amount of data on the existing system, the hardware resources to move all users at the same time, and enough time during non-business hours to perform the migration.

  • All of the hardware and software necessary for your Exchange deployment, including client software.

During a single-phase migration, you may need to use Migration Wizard only once for your entire organization. The wizard first extracts data from your existing system and creates migration files. Then, the wizard imports those files into Exchange. After the data is imported into Exchange, users can begin using Outlook or another client to access messages, calendar information, and public folders from their Exchange mailboxes.

Multi-Phase Migration

Multi-phase migration moves users in groups at different times. Multi-phase migration may be a good choice if you:

  • Have a large existing system and are unable to migrate all users to Exchange at the same time.

  • Need to train your users on new clients and working procedures.

  • Need to make hardware available in the early phases of migration for reuse during the later phases.

  • Cannot migrate everyone in the organization within an acceptable period of system downtime.

  • Want to pilot test the migration process on a group of experienced users first.

During a multi-phase migration, you must have a connector or gateway configured between Exchange and the other messaging system to allow users on both systems to communicate with one another.

Using Connectors for Coexistence

To connect the two systems during a multi-phase migration, you must use a gateway or connector. If your existing system also connects to other systems, you can route messages through your existing system or through an Exchange connector or gateway.

Routing Messages Through Your Existing System

If your existing system has a gateway to another system, Exchange users may be able to send and receive e-mail by using your existing system as a backbone. This scenario is shown in the following illustration.

Figure 17.1 Using your existing system as a backbone

Whether you can route messages through your existing system depends on the capability of the system and the gateway or connector that links it to Exchange.

You should test any configuration that uses the existing system as a backbone, taking into consideration the following questions:

  • Will Exchange mailboxes have addresses for this gateway?

  • How will mail for Exchange mailboxes be routed through the existing system?

  • Will migrated mailboxes be able to retain their old external addresses without having routing problems?

Routing Through Exchange

You can use an Exchange server as a gateway to the other external system. Users on the existing system can exchange mail with the other system through Exchange. This scenario is shown in the following illustration.

Figure 17.2 Using an Exchange server as a gateway to an external system

When you configure a connector between Exchange and another system, Exchange generates proxy addresses for the new user or contact objects that may be different from their old addresses. If you use Exchange as a backbone between two systems that previously shared a connection and are therefore using old addresses, mail may not be delivered. To use Exchange as a backbone, do one of the following:

  • Create the user or contact objects using their existing proxy addresses by editing the default mapping rule files, or modify the new addresses using Active Directory Users and Computers.

  • After creating the user or contact objects, inform the users of their new addresses and advise them to provide the addresses to people with whom they exchange e-mail.

Planning a Coexistence Strategy

This section describes several issues that you need to consider when planning your coexistence strategy. The goal is to cause as little user disruption as possible.

Increased Message Traffic Affects Message Routing

When some users are on your existing messaging system and some are on Exchange 2000 Server, network message traffic increases, which can slow down the routing of messages. To avoid this you can:

  • Configure multiple gateways or connectors between systems.

  • Move users from your existing system to Exchange in groups or departments that typically send mail to each other.

  • Dedicate high-bandwidth connections and high-performance hardware for use by the gateway or connector.

  • Restrict the size of messages across the connector.

    Note You should consider solutions that are transparent to the user, such as adding additional connectors, before restricting message size.

Some Features May Not Be Supported

The gateway or connector that you are using may not support all of the features normally available to Exchange or your existing messaging system. Review the documentation for your connector or gateway to determine which features it supports. Try to move groups that use specific unsupported features to Exchange together to minimize the inconvenience to users.

Connection Is Unstable

Connectors or gateways may not be as reliable as your stand-alone messaging system. If your connection is unstable:

  • Consider using a different gateway or backbone.

  • Use monitors to assess message traffic and queue size.

  • If necessary, restrict the traffic across the connection to keep it to a minimum.

  • Minimize the time the connection is used.

Developing a Migration Task List

After you create a team and develop a migration strategy, you need to pay attention to the details of the migration process. These details are important when you decide how you want to use Migration Wizard.

After you consider the following issues, you can complete your migration plan and begin testing. Each issue is described in detail later in this chapter.

  • Establishing naming conventions

  • Maintaining external addresses

  • Handling messages directed to the system you are migrating

  • Moving calendar and resource information

  • Moving personal mail archives

  • Converting custom applications

  • Handling distribution groups

  • Moving remote users

Establishing Naming Conventions

Migration may be a good time to make changes to the architecture of your directory. You may want to consider the naming scheme you have in place for your existing directory before you migrate to Exchange. If you are creating all new Windows user accounts in Active Directory, you may want to create a new naming scheme to standardize user names across your organization.

When you use Migration Wizard, you can avoid creating duplicate user accounts by ensuring that individual accounts in the source directory are correctly matched with Active Directory accounts. To avoid conflicts, choose unique object names in both your source directory and Active Directory.

Maintaining External Addresses

If your users often receive mail from outside your organization or from other systems within your organization, the external addresses of your users should be preserved. For example, if your existing system receives e-mail from the Internet, every mailbox in your system has a Simple Mail Transfer Protocol (SMTP) address. By default, Migration Wizard attaches SMTP addresses to the migrated mailboxes. If you choose not to preserve these addresses, all users must provide their new addresses to everyone with whom they exchange e-mail.

Address Lists

Exchange 2000 address lists provide a mechanism to partition mail-enabled objects in Active Directory for the benefit of specific groups of users. For more information about address lists, see Chapter 6, “Administration.”

As you migrate users from other systems to Exchange, you add them to Active Directory as users or contacts. Depending on the type of migration you use and how you configure it, existing distribution lists may translate to groups in Active Directory.

As you read the following sections, remember that items that appear in address lists are objects in Active Directory.

Handling Messages Directed to the System Being Migrated

After you migrate a mailbox, the old mailbox may receive mail that was in transit during the migration. Some systems can forward mail or reply to mail with the new address. If your existing system doesn’t have these features, use the source extractor and Migration Wizard to forward the mail, or have users periodically connect to their old mailboxes. When a user replies to a migrated message, there are three possible results.

Action | Result
A display name matches the display name in the message | The address is resolved.
More than one display name matches the display name in the message | The user is presented with a list of choices.
No display name matches the display name in the message | The user needs to find the new address in the list.

For a user to reply to a migrated message, all names must exist in the Exchange address list, either as contact addresses for users on the existing system or as mailboxes for users on the new system, but not as both. Any mail moved from your existing system contains the display names of the sender and recipients.

Moving Calendar and Resource Information

If your existing scheduling application supports resource accounts, for example, for reserving meeting rooms, you must also move these accounts. Some Exchange source extractors move resource accounts and their calendar data, but some configuration may be required; for example, you may need to assign a user as manager of the resource. After you migrate the resource accounts, a user with the appropriate permissions must open each mailbox and configure the calendar properties.

Moving Personal Archives

To make the migration process easier for users, Microsoft has integrated some migration tools into Outlook 2000. Using the Import feature, you can import messages from Lotus cc:Mail Archives, Internet mail clients (for example, Eudora, Netscape, and Outlook Express), and other messaging applications.

Depending on your messaging system, you may also be able to use some of the other migration tools provided with Exchange, including the Microsoft Importer for Lotus cc:Mail Archives and the Lotus Notes Mail Importer.

For more information about the migration tools included in Outlook, see the Outlook documentation.

Converting Custom Applications

As part of your migration strategy, you should evaluate your existing messaging applications. Converting messaging applications is complex and should be considered separately from the migration of mailboxes and e-mail. If users move to a new set of applications, it is important to build user awareness and perform training before migrating users to the new system.

During a coexistence period when users within the organization are split between Exchange and the existing messaging system, you may need to develop an application for different network operating systems that can be used during coexistence. Exchange supports applications based on MAPI, Common Mail Calls (CMC), and Collaboration Data Objects (CDO). You can replace some workgroup applications with public folders or custom forms, and you can modify other applications to work with Exchange 2000 Server; for example, you can convert Lotus Notes applications using the Exchange Application Converter for Lotus Notes tool. You may need to redevelop other applications.

When you migrate an application, consider the following questions:

  • How does the application interact with the existing system?

  • Can you replace the application with public folders or custom forms, or modify it to use MAPI?

  • Does your organization use this application across different network operating systems?

  • Does the application need to coexist during multi-phase migration?

For information about developing applications for Microsoft Exchange 2000 Server, see Messaging and Collaboration in the Microsoft Platform SDK. The Platform SDK is an integral part of the Microsoft Developer's Network (MSDN) and can be accessed online at http://msdn.microsoft.com. The Platform SDK is also available in CD format through a MSDN quarterly subscription. For the latest Microsoft Exchange development information, including technical articles, samples, tools, and documentation, visit the MSDN Exchange Developer Center at http://msdn.microsoft.com/exchange.

Handling Distribution Groups (Distribution Lists)

Migration Wizard does not migrate distribution groups in Exchange (formerly called distribution lists). During a multi-phase migration, when distribution groups and addresses are changing, you can ensure correct routing to distribution group members by using one or more of the following methods. Each method is described in detail later in this section.

  • Re-create groups and synchronize directories.

  • Set up a forwarding scheme.

  • Convert distribution groups to public folders.

  • Maintain duplicate distribution groups on both systems.

  • Disable distribution groups until migration is finished.

Re-create Groups

With this method, you re-create all distribution groups before migration and run directory synchronization so that users on Exchange and the other messaging system can use them.

The advantages of this method are:

  • When users on the other messaging system are migrated, their contact information is updated automatically in the Exchange distribution groups with the same rules and exceptions.

  • When the migration process is finished, the complete distribution group is recognized by Exchange.

The disadvantage of this method is that it increases network traffic. Initially, the membership of the distribution group consists of users on the other messaging system, so mail sent to the list is transferred to Exchange through the connector, expanded, and then delivered back to the other system.

Setting Up a Forwarding Scheme

Instead of maintaining distribution groups during migration, you can preserve existing distribution groups and mailboxes until your move is finished. Then you can re-create the distribution groups and configure the existing system to forward all mail to the new Exchange mailboxes.

The advantages of this method are:

  • Maintenance is not required during migration.

  • You can solve problems related to gateway pass-through, replies to sent mail, and personal address books.

The disadvantages of this method are:

  • You must re-create the distribution groups after the move is finished.

  • Messages sent from Exchange to distribution groups, which contain Exchange-enabled objects, cross the connection twice.

  • Messages are forwarded individually, leading to multiple copies of messages in Exchange.

Converting Distribution Groups to Public Folders

You can use public folders to replace distribution groups so that users can view a history of recent messages in a public folder.

The advantages of this method are:

  • New users see a history of recent mail.

  • The transition to public folders is part of the migration.

The disadvantages of this method are:

  • The rules and permission maintenance must be done in Outlook; changes aren’t made automatically.

  • Mail sent to the public folder from the existing system crosses the gateway twice to reach members on the existing system.

To move users from distribution groups to public folders, perform the following steps:

  1. Create public folders that correspond to distribution groups on your existing system.

  2. Add a rule on each public folder to forward all new items to all members of the distribution group who have mailboxes that have not been migrated to Exchange.

  3. Give user permissions on a public folder to all Exchange members of the corresponding distribution group.

  4. After the name of a public folder is visible in the existing system, remove the corresponding distribution group.

Maintaining Duplicate Groups

To keep network traffic to a minimum, you can have copies of distribution groups on the existing system and Exchange. To avoid duplicate names in the address lists, distribution groups are excluded from directory synchronization between the two systems. Only the Exchange distribution groups appear in its address list, and only the existing system’s groups appear in its directory. This method works well if you use an automated process to modify distribution groups.

The advantages of this method are:

  • Users and contacts are updated automatically in the Exchange distribution groups with the same rules and exceptions.

  • When migration is finished, Exchange recognizes the complete distribution group.

  • Exchange sends mail to the distribution group, so that only one copy of a message is delivered to each messaging system.

The disadvantages of this method are:

  • The existing system may lack distribution group features.

  • Maintaining duplicate distribution groups can require more effort than maintaining one group on one system.

Disabling Distribution Groups Manually

You can save the list of distribution group members and then delete or disable all distribution groups on the system you are migrating. After migration is finished, you create the distribution groups with new addresses. This does not require maintenance during migration, but may disrupt normal e-mail traffic.

The advantages of this method are:

  • Fewer resources are needed during migration.

  • No maintenance is required during migration.

The disadvantage of this method is that some groups may have a critical need for distribution groups and cannot wait for a multi-phase migration to be completed.

Moving Remote Users

Your plans should include users at branch offices and users who access e-mail from remote locations. For remote users, consider the following questions:

  • Will hardware and software upgrades be required?

  • Will hardware be purchased locally or by a central site?

  • How and when will remote users be moved and trained?

  • How will routing and directories be maintained during migration?

  • Will a local team or a mobile team handle planning and implementation?

Testing Migration

Your migration strategy may include two levels of testing. You can run the first test in a test lab that is not connected to your production environment. You should use test accounts created from copies of real data. This test will help you identify missing steps and familiarize your team with the product and procedures.

You can run the second test if you are migrating in multiple phases. In this case, you can run a pilot test with a select group of users, most likely including the migration team. The pilot testing period is a good time to implement user training within the organization and to inform users about new policies and the migration schedule.

In general, the pilot test group should consist of administrators and users working in Outlook, because administrators will be maintaining Exchange. Ensure that the group can use the existing and new systems at the same time. The group should understand how migration affects the day-to-day use of e-mail and how messages are routed inside and outside the organization. During testing, administrators should set policies on new features, such as public folders, rules, scheduling, and security.

During this time, you can also:

  • Determine whether public folder applications can replace certain system applications.

  • Determine the throughput of data from Migration Wizard and gateways.

  • Find out how long directory synchronization takes in your organization, and use that information to plan directory synchronization scheduling.

  • Ensure that connectors are routing messages correctly. After migration, users should be able to respond to messages in their inboxes that were received prior to migration.

Creating a Contingency Plan

Using a contingency plan can minimize downtime if hardware failure or network problems occur. Test as much of your plan as possible in the test lab and consider the following in your contingency planning:

  • Anticipate problems and plan resources accordingly.

  • Keep spare parts available or ensure you can obtain them quickly.

  • Plan to back up both the existing and new systems.

  • Devise a method and a schedule for restoring these backups. For more information about backup and restore, see Chapter 14, “Backup and Restore.”


$ Chapter 18 Quick Installation

This chapter provides simplified instructions for small organizations that are installing an initial messaging system. After you configure Microsoft Windows 2000 Server to communicate with the Internet, you can run Microsoft Exchange 2000 Server Setup to install a messaging and real-time collaboration system that works immediately. Information in this chapter may also be useful for organizations that are deploying a test environment.

In addition to providing messaging functionality, Exchange 2000 Server offers the following features:

Internet connectivity After you install Exchange, Simple Mail Transfer Protocol (SMTP) port 25 receives incoming mail from the Internet. To send mail, Exchange uses Domain Name System (DNS) to route outgoing Internet mail.

Real-time collaboration If you install real-time collaboration services during Exchange Setup, and you have the correct client software and hardware installed, your users can send and receive instant messages and chat online with friends and business associates.

Multi-media messaging Exchange supports multiple protocols and messaging formats. If your users are running Outlook 2000 or Outlook Web Access with Microsoft Internet Explorer version 5.0, they can send and receive multi-media messages.


$ Before Installing Exchange

Before you can install Exchange 2000 Server, you must plan the functionality you need, set up Windows 2000 Server and related systems, and address system security and maintenance issues.

Installation Prerequisites

These quick installation instructions require that this is the first and only messaging server in your organization. If you are upgrading from an earlier version of Exchange or if you have another messaging system, you need more comprehensive information. For more information about upgrading Exchange, see Chapter 16, “Upgrading and Coexisting,” and for more information about other messaging systems, see Chapter 17, “Migrating to Exchange.”

Before installing Exchange, you must:

  • Install Windows 2000 Server. Exchange must be installed in a domain that contains a Windows 2000 Server configured as a domain controller with a global catalog. To configure a Windows 2000 Server as a domain controller and global catalog, see the Windows 2000 documentation.

    Important During Windows 2000 Server Setup, you must install Network News Transfer Protocol (NNTP) Service.

  • Run DNS resolution in your domain. Exchange uses DNS resolution for many of its basic functions. If DNS is not present on your system, Exchange Setup does not allow you to install the messaging and collaboration components. For information about configuring Windows 2000 Server as a DNS server, see the Windows 2000 documentation.
  • Configure Windows 2000 Server to communicate with the Internet. Without Internet connectivity, Exchange can still send messages over a LAN, but it cannot send or receive mail from the Internet. If you have configured a firewall between your network and the Internet, you need to configure the firewall to allow communication with the Internet over port 25. For more information about how to configure an SMTP virtual server, see the Exchange online documentation.

Security Considerations

There are many security issues to consider when connecting to the Internet. You need to ensure that your system is safe from external attacks. Before installing Exchange, be sure you understand basic security for messaging, real-time collaboration, and Internet connectivity. This is important if your Internet connectivity plan includes a firewall or proxy server. For information about security issues for Internet connectivity, see Chapter 9, “Internet Connectivity.”

Because security issues for specific components are described in the component chapters, read the chapters that discuss the services that you are installing. For information about security for Windows 2000 Server and Exchange, see Chapter 13, “System Security.”

Maintenance Considerations

You need to consider post-installation tasks and maintenance issues for the components you install. Regardless of which components you install, a maintenance schedule in addition to a backup and restore plan helps to protect your messaging system against power outages, natural disasters, and human error. Microsoft recommends that you have a backup and restore plan in place before you install Exchange. For information about recovery strategies you can implement, see Chapter 14, “Backup and Restore.”


$ Installing Exchange

To install Exchange, you must log on to Windows 2000 Server with an account that is a member of the following Windows 2000 security groups:

  • Domain Admins

  • Enterprise Admins

  • Schema Admins

To start Installation Wizard:

  1. Log on to the Windows 2000 Server on which you want to install Exchange. Insert the Exchange 2000 Server compact disc into your CD-ROM drive.

  2. On the Microsoft Exchange Server 2000 screen, click Setup, and then click Exchange Server Setup.

  3. On the Welcome screen, click Next.

  4. On the End User License Agreement screen, read the agreement. If you accept the terms, click I agree, and then click Next.

  5. On the Product Identification screen, enter the 25-digit CD key that is located on a sticker on the back of the product CD, and then click Next.

The following illustration shows the Component Selection screen in Exchange Setup.

Figure 18.1 Component Selection screen

The following table describes the components listed on the Component Selection screen in Setup. The connectors listed under Microsoft Exchange Messaging and Collaboration Services connect Exchange to other mail systems. This chapter assumes that this is the first messaging system installed in your organization so these connectors are not described in the following table. For more information about using connectors, see the Exchange online documentation.

If you want a basic messaging system, install Microsoft Exchange Messaging and Collaboration Services and Microsoft Exchange System Management Tools. You can run Setup later to add additional components.

Component | Function
Microsoft Exchange 2000 | Components required for every Exchange server.
Microsoft Exchange Messaging and Collaboration Services | Basic messaging components (also required to install Instant Messaging Service or Chat Service).
Microsoft Exchange Key Management Service | Exchange-specific security enhancements for Windows 2000 Server Certificate Services. For more information about Certificate Services, see Chapter 13, “System Security.”
Microsoft Exchange System Management Tools | Tools, including System Manager, for managing Exchange components.
Microsoft Exchange Chat Service | Components necessary for hosting chat communities. For more information about Chat Service, see Chapter 12, “Chat Service.”
Microsoft Exchange Instant Messaging Service | Components necessary for Instant Messaging. For more information about Instant Messaging Service, see Chapter 11, “Instant Messaging and Presence Monitoring.”

To choose Exchange components and complete installation:

  1. On the Component Selection screen, click the Action column next to the component that you want to install, and click Install.

    Important To add components in addition to those provided with Typical, click Typical, click Custom, and then select the components you want to install. You must select Microsoft Exchange Messaging and Collaboration Services and Microsoft Exchange System Management.

  2. To change the drive for the installation, select Microsoft Exchange 2000,and then click Change Folder. For information about available drives and available disk space, click Disk Information.

  3. On the Licensing Agreement screen, read the licensing agreement. To continue, click I Agree.

  4. On the Installation Type screen, select Create a new Exchange Organization.

  5. On the next Organization Name screen, type a name for your Exchange organization. This will be the permanent organization name. You cannot change this name during subsequent installations.

  6. On the Installation Summary screen, verify your information.

    Setup now installs Exchange. A box appears after approximately 30 seconds that prompts you for verification to update the schema.

    Important When Exchange Setup updates the Active Directory schema, the additional fields for user accounts result in increased storage requirements for Active Directory. You cannot reverse the schema change and the update may require several hours if user accounts already exist in Active Directory.

  7. On the completion screen, click Finish.


$ Post-Installation Tasks

After you install Exchange, you must do the following:

  • Delegate administrative permissions.

  • Create mailboxes for users.

  • Configure real-time collaboration services (optional).

  • Back up your system.

Delegating Administrative Permissions

If you are the only administrator for your organization, you do not need to delegate Exchange-specific administration permissions. However, if you want to delegate specific administrative tasks, such as creating mailboxes to others in your organization, you can run Exchange Administration Delegation Wizard. For more information about Delegation Wizard, see the Exchange online documentation.

Creating Mailboxes

When you create a user in Active Directory after installing System Manager, you can also create a mailbox for that user.

Note You can run Exchange Setup on any computer running Windows 2000 Server in your domain and install System Manager without installing any other Exchange components.

In the Active Directory Users and Computers snap-in, type the user's name and basic information. A screen appears with default mailbox information. To create a mailbox for the new user, select Create Exchange Mailbox.

In order for users that existed in Active Directory before Exchange was installed to receive mail, you must add an Exchange mailbox to the user’s account.

To add a mailbox to an existing user account:

  1. On the Start menu, point to Programs, point to Administrative tools, and then click Active Directory Users and Computers.

  2. Click the Users container.

  3. Right-click the user account you want to add an Exchange mailbox to, and click Exchange Tasks.

    A welcome screen appears. Click Next.

  4. Point to Available Tasks, and then click Create Mailbox.

  5. Type a different e-mail alias, if necessary.

Configuring Real-Time Collaboration Services

This section explains how to provide your organization with basic real-time collaboration services. For information on advanced configuration and customization of these services, see the Exchange online documentation.

Instant Messaging

Use the following process to install and work with Instant Messaging Service.

  • Create a home server.

  • Create user accounts and give users access to the service.

  • Install the client software and log on to the Instant Messaging home server.

For detailed procedures about how to set up Instant Messaging Service, see Chapter 11, “Instant Messaging and Presence Monitoring” and the Exchange online documentation.

Chat

If you install Chat Service, complete the following tasks:

  • Start System Manager. Open Chat Communities and create one or more channels (chat rooms) under the default chat community.

  • Notify your users that the service is available and tell them how to download chat clients that you support. Provide them with the name of the Exchange server and TCP client port so that they can connect to the chat community and join channels.

For more information about hosting chat communities, see Chapter 12, “Chat Service” and the Exchange online documentation.

Backing Up Your System

After you install and configure Exchange, you must back up your server. If you install or configure additional Exchange components in the future, back up your system after installation is complete.

It is important to establish and maintain a regular backup schedule. In addition, you must design a reliable disaster recovery plan and test it periodically.

If you are running only one instance of Windows 2000 Server in your organization, print the Windows 2000 documentation that describes how to restore the domain controller so that it is available in the event of a disaster. Your disaster recovery plan should include printed documentation for all aspects of backing up and restoring your system. For more information about developing backup and restore strategies, see Chapter 14, “Backup and Restore.”

The following section describes the minimal steps necessary to back up your configuration data.

Backing Up Configuration Data

Because so much of the Exchange configuration information is stored in Active Directory, it is important that you back up Active Directory on a regular basis. This procedure describes how to back up System State using the Windows 2000 Server Backup program on a domain controller. When System State is backed up, the following information is included:

  • Registry

  • COM+ Class Registration database

  • System boot files

  • Active Directory directory services database

  • SYSVOL directory

To back up System State:

  1. Click Start, point to Programs, point to Accessories, point to System Tools, and then click Backup.

  2. Click the Backup tab and select System State.

    Windows 2000 backs up the System State data.

Backing Up Data

In addition to backing up configuration data, it is also important to back up user data on a regular basis. For more information about backing up Windows 2000 Server, see the Windows 2000 documentation. For more information about backing up Exchange, see the Exchange online documentation.

Additional Resources

For more information about | See
Maintaining and monitoring your system | Exchange online documentation
Creating and managing public folder hierarchies | Exchange online documentation
Deploying real-time collaboration clients | Chapter 4, “Clients and Internet Protocols,” and the Exchange online documentation
Using multiple mailbox stores or public folder stores | Chapter 7, “Information Store”
Outlook Web Access | Chapter 10, “Outlook Web Access”
Securing your system | Chapter 13, “System Security”
Backing up and restoring data | Chapter 14, “Backup and Restore”
Adding a server to your Exchange organization | Chapter 19, “Installing Exchange”


Chapter 19 Installing Exchange

A successful installation of Microsoft Exchange 2000 Server depends on many factors and variables. Earlier chapters discuss the decisions you must make before installing Exchange. It is important that you read chapters that discuss features relevant to your Exchange organization before installing Exchange in your production environment.

This chapter contains three sections to guide you through the installation process:

  • Before the Installation

  • Installing Exchange

  • Post-Installation Tasks


Before the Installation

Before you install Exchange, you must ensure that your hardware is capable of running Exchange and you must prepare your Microsoft Windows 2000 Server forest and domains.

System Requirements

The following are the requirements for each computer running Exchange 2000 Server. For system requirements specific to a cluster environment, see Chapter 20, “Installing with Windows Clustering.”

  • Intel Pentium or compatible 133 MHz or higher processor

  • Microsoft Windows 2000 Server operating system

  • 256 MB of RAM recommended minimum; 128 MB supported minimum

  • 500 MB of available disk space on the drive on which you install Exchange

  • 200 MB of available disk space on the system drive

  • CD-ROM drive

  • VGA or higher-resolution monitor

Preparing Active Directory

Before you install Exchange, you must prepare the forest and each domain into which you want to install Exchange. Preparing your organization requires two Setup utilities, ForestPrep and DomainPrep. ForestPrep is run once per forest to extend the Active Directory schema and DomainPrep is run once per domain to identify the address list server and set permissions within the domain. You do not need to run DomainPrep in a domain until you are ready to install Exchange.

Some messaging administrators have only the network permissions necessary to perform discrete administrative functions on the network. Similarly, those responsible for planning and implementing the Windows forest and domain structure have only the permissions necessary to manage Active Directory. Because installing Exchange and its components involves both specific messaging tasks and far-reaching architectural changes, ForestPrep and DomainPrep simplify the permission management logistics for deploying Exchange.

Preparing a Single Administrator Deployment

If a single person or group that is responsible for deploying Exchange also has permissions to modify the Active Directory schema and control domains, there are few preparation tasks.

If the account that you use to install the first instance of Exchange belongs to the Schema Admins, Enterprise Admins, and Administrators (for the first server) security groups, you don't need to run ForestPrep.

The first instance of Exchange must be installed into the domain where the schema master resides. By default, the schema master runs on the first Windows 2000 domain controller installed in a forest. For more information about the schema master, see the Windows 2000 documentation.

For subsequent installations, the account that is installing Exchange must be a member of the Enterprise Admins security group or a member of both the Domain Admins security group for the domain in which you are installing Exchange and a Full Exchange Administrator. The account must also belong to the local machine administrator group.

Preparing the Forest

If you do not belong to the Schema Admins and Enterprise Admins security groups, you must request that a member of those groups run ForestPrep in the domain where the schema master resides. The schema master runs on the first Windows 2000 domain controller installed in a forest by default. For more information about the schema master, see the Windows 2000 documentation.

To run ForestPrep, you must be a member of the Enterprise Admins and Schema Admins security groups. In addition, you must belong to the Administrators security group and have administrative rights on the computer running ForestPrep.

ForestPrep accomplishes different tasks depending on whether you are installing Exchange 2000 into an Exchange 5.5 organization or you are creating a new Exchange organization.

If you are creating a new Exchange organization in a forest, running ForestPrep will:

  • Extend the Active Directory schema to include Exchange-specific information. This affects the entire forest and may take a considerable amount of time to replicate changes to every domain and domain controller.

  • Prompt for and create the Exchange organization name and object in Active Directory. When Exchange is installed, provided that DomainPrep runs in each domain where Exchange is to be installed, Setup queries Active Directory for configuration information. This simplifies deployment of Exchange throughout the forest.

  • Assign Exchange Full Administrator permissions for the account that you specify. This account has the authority to install Exchange throughout the forest. After the first installation of Exchange 2000, you can use this account to run Exchange Administration Delegation Wizard, which configures Exchange-specific roles for administrators throughout the forest.

To run ForestPrep in a forest with no earlier versions of Exchange:

  1. Insert the Exchange compact disc (CD) into your CD-ROM drive.

  2. On the Start menu, click Run and type E:\setup\i386\setup /ForestPrep, where E is your CD-ROM drive.

  3. On the Welcome screen, click Next.

  4. On the End User License Agreement screen, read the agreement. If you accept the terms, click I agree, and then click Next.

  5. On the Installation Type screen, click Create an Exchange 2000 Organization.

    Figure 19.1 Installation Type screen

  6. On the Organization Name screen, type the name of your new organization. Remember that once you type a name for your Exchange organization, you cannot change it.

    Figure 19.2 Organization Name screen

  7. On the Exchange 2000 Administrator Account screen, type the name of the user or group that is responsible for installing Exchange. The account that you specify will also have permission to create all types of Exchange administrator accounts with Exchange Administration Delegation Wizard. Click Next.

    Figure 19.3 Exchange 2000 Administrator Account screen

    ForestPrep begins and then a prompt asks you to verify to the schema update.

  8. On the Completion screen, click Finish.

If your are running ForestPrep in a forest that is running an earlier version of Exchange, running ForestPrep will:

  • Extend the Active Directory schema to include Exchange-specific information. This affects the entire forest and, depending on the size of Active Directory, may take a considerable amount of time to replicate changes throughout the forest.

  • Create the Exchange Organization object in the Active Directory schema based on configuration information from your Exchange 5.5 organization.

  • Assign Exchange Full Administrator permissions for the account that you specify. This account has the authority to install Exchange throughout the forest. After the first installation of Exchange, you can use this account to run Exchange Administration Delegation Wizard, which configures Exchange-specific roles for administrators throughout the forest. You may want to consider granting existing Exchange 5.5 administrators these permissions.

The following procedure explains how to configure ForestPrep if an Exchange 5.5 organization already exists. Before running ForestPrep, read Chapter 16, “Upgrading and Coexisting.”

To run ForestPrep in a forest with earlier versions of Exchange:

  1. Insert the Exchange CD into your CD-ROM drive.

  2. One the Start menu, click Run and type E:\setup\i386\setup /ForestPrep, where E is your CD-ROM drive.

  3. On the Welcome screen, click Next.

  4. On the End User License Agreement screen, read the agreement. If you accept the terms, click I agree, and then click Next.

  5. On the Installation Type page, select Join an existing Exchange 5.5 Organization.

    Figure 19.4 Installation Type screen

  6. On the Select a Server from an Exchange 5.5 Organization screen, type the computer name of a server that resides in an existing Exchange 5.5 site. You must install your first instance of Exchange 2000 Server into this Exchange 5.5 site. The server that you specify must be running Exchange 5.5, SP3.

    Figure 19.5 Select a Server screen

  7. On the Exchange 2000 Administrator Account screen, enter the name of the user or group that will be responsible for installing Exchange. This user or group will be able to create Exchange administrator accounts throughout the forest by using Exchange Administrator Delegation Wizard.

    Figure 19.6 Exchange 2000 Administrator Account screen

  8. On the Service Account page, type the account name and password for the existing Exchange 5.5 service account, and click Next.

    Figure 19.7 Service Account screen

    ForestPrep begins; a box appears after approximately 30 seconds that prompts you for verification to update the schema.

  9. On the Completion page, click Finish.

Preparing Domains

After running ForestPrep, you need to run DomainPrep in each domain where you want to install Exchange 2000, including the same domain where you ran ForestPrep. To run DomainPrep, your account must be a member of the Domain Admins security group for the domain and Administrator security group on the computer from which you are running DomainPrep.

The procedure for running DomainPrep is the same whether or not your forest includes earlier versions of Exchange. When you use the following procedure, DomainPrep will:

  • Prompt for the address list server responsible for this domain.

  • Create the global security group, Domain EXServers.

  • Create the domain local security group, All Exchange Servers.

  • Add Domain EXServers group to the All Exchange Servers group.

  • Grant appropriate rights to the address list server.

To run DomainPrep in a domain

Note If you are running DomainPrep in the same domain where you ran ForestPrep, skip steps 4 and 5.

  1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any computer running Windows 2000 Server in the domain.

  2. From Command Prompt, enter E:\\setup\i386\setup /DomainPrep, where E is your CD-ROM drive.

  3. On the Welcome page, click Next.

  4. On the End User License Agreement (EULA) page, read the EULA. If you agree to the terms, click I agree, and then click Next.

  5. On the Recipient Update Server screen, type the name of the computer that will be your Exchange Recipient Update server for this domain. This computer must not be installed yet, but a computer account must exist in the Active Directory Users and Computers snap-in. When you install the first instance of Exchange in this domain, it must use the computer account that you enter in this step. Click Next.

    Figure 19.8 Recipient Update Server screen

  6. On the Completion page, click Finish.


Installing Exchange

This section explains the installation procedure after you have prepared your organization: you have run ForestPrep and you have run DomainPrep in each domain where you want to install Exchange 2000.

Because you ran ForestPrep and DomainPrep, Exchange Setup detects the Exchange-specific configuration information in Active Directory. The only information that you need to specify during Setup is which components you want to install and which administrative groups and routing groups you want your servers to join.

There are three basic Exchange installation types:

  • First installation

  • Subsequent installations

  • Upgrade installations

After you install the first instance of Exchange into your enterprise, Microsoft recommends that you:

  • Run Administration Delegation Wizard to assign appropriate Exchange-specific roles to administrators. For more information about Administration Delegation Wizard, see “Administrative Roles and Permissions” later in this chapter.

  • Create administrative groups and routing groups for your Exchange organization. After this infrastructure is in place, you can specify appropriate administrative groups and routing groups during Setup on subsequent installations of Exchange.

Exchange Components

The following table describes the components listed on the Component Selection screen in Exchange Setup. The connectors listed under Microsoft Exchange Messaging and Collaboration Services connect Exchange to other mail systems. For more information about using connectors, see the Exchange online documentation.

Component | Function
Microsoft Exchange 2000 | Components required for every Exchange server.
Microsoft Exchange Messaging and Collaboration Services | Basic messaging components (required to install Instant Messaging Service or Chat Service).
Microsoft Exchange Key Management Service | Exchange-specific security enhancements for Windows 2000 Server Certificate Services. For more information about Certificate Services, see Chapter 13, “System Security.”
Microsoft Exchange System Management Tools | Tools, including System Manager, for managing Exchange components.
Microsoft Exchange Chat Service | Components necessary for hosting chat communities. For more information about Chat Service, see Chapter 12, “Chat Service.”
Microsoft Exchange Instant Messaging Services | Components necessary for Instant Messaging. For more information about Instant Messaging Service, see Chapter 11, “Instant Messaging and Presence Monitoring.”

To start Installation Wizard:

  1. Log on to the Windows 2000 Server on which you want to install Exchange. Insert the Exchange 2000 Server CD into your CD-ROM drive.

  2. On the Microsoft Exchange Server 2000 screen, click Setup, and then click Exchange Server Setup.

  3. On the Welcome screen, click Next.

  4. On the End User License Agreement (EULA) screen, read the EULA. If you agree to the terms, click I agree, and then click Next.

  5. On the Product Identification screen, enter the 25-digit CD key that is located on a sticker on the back of the product CD, and then click Next.

  6. On the Component Selection page, click the node in the Action column that corresponds with the component that you want to install. Click Install.

  7. To change the drive location of the installation, select Microsoft Exchange, and then click Change Folder.

    Note For information about available drives and their corresponding available disk space, click Disk Information.

    Figure 19.9 Component Selection screen

First Installation

The following procedures explain the process for installing Exchange 2000 for the first time. If an earlier version of Exchange is running, the procedures vary slightly.

The following procedures assume the following:

  • You have deployed Windows 2000 and domain name service (DNS) according to the Windows 2000 documentation.

  • You have run ForestPrep and DomainPrep.

  • You are installing Exchange on the same computer that you specified as the Address List Server when you ran DomainPrep.

  • If you are upgrading from Exchange 5.5, you have installed ADC and have run connection agreements according to the instructions in Chapter 16, “Upgrading and Coexisting,” and in the Exchange online documentation.

To install Exchange 2000 in a forest with no earlier versions of Exchange:

  1. Start Installation Wizard and select the components you want to install.

  2. On the Licensing Agreement page, read the Per Seat licensing agreement. To continue, click I Agree, and then click Next.

  3. On the Installation Summary page, verify your information, and then click Next.

  4. On the completion page, click Finish.

To install Exchange 2000 in a forest with earlier versions of Exchange:

Important When you install Exchange 2000, the account that you use to install must have Exchange Full Administrator rights for Exchange 2000 and Exchange 5.5. Thus, before you install Exchange, make sure that you grant the appropriate account Service Account Admin rights on the Site and Configuration objects across your Exchange 5.5 organization. For information about granting permissions in the Administrator program, see the Exchange 5.5 documentation.

  1. Start Installation Wizard and select the components you want to install.

  2. On the Licensing Agreement page, read the Per Seat licensing agreement. To continue, click I Agree, and then click Next.

  3. On the Administrative Groups page, select the administrative group that corresponds to the Exchange 5.5 site name where the computer that you specified in ForestPrep resides, and then click Next.

  4. On the Routing Groups page, select the routing group that corresponds to the Exchange 5.5 site name where the computer that you specified in ForestPrep resides, and then click Next.

  5. On the Installation Summary page, verify your information, and then click Next.
  6. On the completion page, click Finish.

Subsequent Installations

After the initial installation of Exchange, the only difference in procedure for subsequent installations is the selection of administrative groups and routing groups.

By default, in those organizations where no previous versions of Exchange exists, Exchange Setup creates First Administrative Group and First Routing Group. These will not be displayed in System Manger unless specifically enabled. Once you enable administrative groups and routing groups to be visible, you can add new administrative groups and routing groups to fit your deployment strategy.

After you create an administrative group or routing group in System Manager, you can select them during Setup when you install additional servers.

If you are not using multiple administrative groups and routing groups in your organization, select the default groups, First Administrative Group and First Routing Group, during Setup.

To install additional Exchange 2000 servers:

  1. Start Installation Wizard and select the components you want to install.

  2. On the Licensing Agreement page, read the Per Seat licensing agreement. To continue, click I Agree, and then click Next.

  3. On the Administrative Groups page, select the administrative group in which you want to install Exchange, and then click Next.

  4. On the Routing Groups page, select the routing group in which you want to install Exchange, and then click Next.

  5. On the Installation Summary page, verify your information, and then click Next.
  6. On the completion page, click Finish.

Upgrade Installations

When you run Exchange 2000 Setup on a computer that is running Windows 2000 Server and Exchange 5.5 SP3, it installs the files necessary to upgrade to Exchange 2000 Server. This requires that you configure connection agreements with Active Directory Connector before you install Exchange.

You cannot add components that are not already installed on the server during the upgrade. However, you can run Setup after the upgrade to add components such as connectors and real-time collaboration services.

If Exchange 2000 does not include connectors that are running on your existing server, those connectors will not be available after you upgrade.

After you run ForestPrep, administrative groups and routing groups represent your Exchange 5.5 topology. For more information about upgrading and upgrade topology, see Chapter 16, “Upgrading and Coexisting.” For more information about creating administrative groups and routing groups, see the Exchange online documentation.

In-place Upgrade

Before you perform the following procedure, you must run ForestPrep and DomainPrep.

To perform an in-place upgrade:

  1. Upgrade the operating system to Windows 2000 Server.

  2. Start Installation Wizard. You cannot add components or switch installation drives during an in-place upgrade. Click Next to continue through the wizard. Setup will begin installing Exchange 2000.

    Note If this is the first installation of Exchange 2000 in your existing Exchange organization, a box appears after about 30 seconds that prompts you for verification to update the schema.

  3. On the Completion page, click Finish.

Single Server In-place Upgrade

If you are running Exchange 5.5 on a Windows NT Primary Domain Controller (PDC), you must change the Lightweight Directory Access Protocol (LDAP) port that the Exchange 5.5 directory service is using to avoid port conflicts. Although you can do this anytime before you upgrade to Exchange 2000, Microsoft recommends that you change the port before you upgrade the operating system to Windows 2000 Server. After you change the LDAP port, you must change the port number on the ADC connection agreements that are configured on the computer.

Upgrading a Windows NT 4.0 PDC running Exchange 5.5 Server to Windows 2000 Server and Exchange 2000 Server consists of the following steps:

  1. Change the LDAP port in the Exchange 5.5 Administrator program.

  2. Upgrade the operating system to Windows 2000 Server.

  3. Setup and configure ADC connection agreements.

  4. Change LDAP port in ADC connection agreements to match the LDAP port in step 1.

  5. Upgrade to Exchange 2000 Server.

To change the LDAP port in Exchange 5.5:

  1. Open the Exchange 5.5 Administrator program.

  2. Expand the Site container, expand the Configuration container, expand the Protocols container, and then double-click LDAP (Directory) Site Defaults.

  3. On the General tab, change the value in Port to a value other than 389.

  4. Open Control Panel, double-click Services, select Microsoft Exchange Directory, and then click Stop.

  5. After the service stops, click Start. Verify that service has restarted, and then click Close.

To upgrade Windows NT 4.0 to Windows 2000 Server, consult the Windows 2000 documentation.

To setup and configure ADC connection agreements, see Chapter 16, “Upgrading and Coexisting,” and the Exchange online documentation.

To change the LDAP port in the ADC connection agreement:

  1. Open Active Directory Connector Manager and double-click the connection agreement that is connected to the Exchange server that you are upgrading.

  2. Click the Connection tab.

  3. Under Exchange Server Information, type the same value in Port that you entered in the LDAP (Directory) Site Defaults in the Exchange 5.5 Administrator program, and click OK.

  4. Verify that the Connection Agreement replicates before you upgrade to Exchange 2000 Server.

To upgrade Exchange 5.5 to Exchange 2000, refer to the earlier procedure, “In-Place Upgrade.”

International Installation

The following table lists the language versions for Windows 2000 Server on which you can install international versions of Exchange 2000 Server. Windows 2000 MultiLanguage Version is a specialized version of Windows 2000 Server that allows individuals to change the language of the interface without installing additional software.

Note Windows 2000 Multilanguage Version is available only through volume licensing programs; it is not available through retail channels.

Exchange 2000 language | Windows 2000 Server languages
English | Any language and Windows 2000 MultiLanguage Version
French | French, English, and Windows 2000 MultiLanguage Version
German | German, English, and Windows 2000 MultiLanguage Version
Italian | Italian, English, and Windows 2000 MultiLanguage Version
Japanese | Japanese
Spanish | Spanish, English, and Windows 2000 MultiLanguage Version


Post-Installation Tasks

After you have installed the first instance of Exchange, you can configure administrative groups and routing groups to suit your deployment strategy. In addition, you can assign Exchange administrative roles to users and groups throughout your organization. For information about creating administrative groups and routing groups, see the Exchange online documentation.

For information about configuration and maintenance for Chat Service, Instant Messaging, or Key Management Service, see the Exchange online documentation. The online documentation contains routine operations information you need to maintain, optimize, and expand your Exchange organization.

Assigning Exchange Administrative Roles and Permissions

Exchange includes a tool called Administration Delegation Wizard that simplifies permission management for delegating the appropriate permissions to Exchange administrators. Administration Delegation Wizard is installed with Exchange, and cannot be run until the first instance of Exchange is installed in the organization.

When you start Administration Delegation Wizard, you can assign the roles in the following table to groups and users:

Role | Capabilities
Exchange Full Administrator | Administer all Exchange system information and modify permissions on Exchange objects
Exchange Administrator | Administer all Exchange system information
Exchange View Only Administrator | View Exchange configuration information
Mailbox Manager | Exchange-enable Active Directory users, groups, and contacts

Administration Delegation Wizard eases the administrative burden associated with assigning, creating, and maintaining permissions. Compared to earlier versions of Exchange, Administration Delegation Wizard reduces the amount of time necessary to manage permissions.

For more information about Administration Delegation Wizard, see the Exchange online documentation.


Chapter 20 Installing with Windows Clustering

Windows Clustering provides high availability for messaging services. A cluster is a group of independent computers that work together to run a common set of applications. It appears as a single system to clients and applications. In the event of a failure, Cluster service restarts or moves the affected services to a functioning node in the cluster. Windows Clustering is commonly adopted to allow you to perform maintenance on your servers without interrupting service.

This chapter describes how to plan for, install, and configure Microsoft Exchange 2000 Server on computers running Cluster service on Microsoft Windows 2000 Advanced Server.


Windows Clustering

There are two types of clustering functionality available with Windows 2000 Server: Network Load Balancing clusters and server clusters.

Network Load Balancing clusters provide high scalability and availability for TCP/IP based services and applications by combining up to 32 servers running Windows 2000 Advanced Server into a single cluster. You can use this type of clustering as a load balancing option for front-end Exchange servers that handle incoming requests in a front-end and back-end architecture. For an explanation of how to set up Network Load Balancing clusters, see the online documentation provided with Windows 2000 Advanced Server. The remainder of this chapter discusses server clusters.

To run Exchange with Windows Clustering, you must use Windows 2000 Advanced Server. To familiarize yourself with clustering functionality, concepts, and terminology before you read this chapter, see server cluster information in the Windows 2000 Advanced Server documentation.


Exchange and Server Clusters

A server cluster includes two or more computers, called nodes, which share storage resources, work together, and are administered as a single unit. In server clusters, a node is a computer running Windows 2000 Advanced Server that is an active or inactive member of a cluster. Server clusters enable you to create resource groups that are not bound to a specific computer and can fail over to another node. If a node hosting a resource group is decommissioned or fails, clients can still access its resources in the same manner on another node.

Microsoft Exchange 2000 Server supports active/active clustering. With active/active clustering, multiple instances of a component, such as Exchange, can run simultaneously in a cluster.

Exchange considers each resource group as a separate instance of Exchange, called a virtual server. A virtual server on a cluster is distinct from a protocol virtual server, which is discussed earlier in this book.

For planned outages, you can decommission a resource group manually and move it to another node. The client experiences an interruption of service only while the group transitions to the second node. The ability to use multiple servers at all times reduces system costs and increases reliability.

The following illustration shows a cluster in normal operation. Each node has a resource group that is an Exchange virtual server and shares storage groups, log files, and queues.

Figure 20.1 Cluster service architecture for Exchange

Each resource group in a cluster running Exchange must contain the following resources:

  • IP address

  • Network name

  • Disk

  • Exchange System Attendant

Load Planning

There are three basic strategies for load planning. The strategy you choose depends in part on the role you expect the cluster servers to perform. For example, if you are setting up a cluster because you need a mechanism for planned outages, you may select a different strategy than if you want optimal performance in the event of an unexpected failure. In either case, you must plan intelligently to ensure that unplanned outages do not compound disaster by exceeding your hardware capacity.

Your strategy for load balancing also affects administrative overhead, hardware resources, and the Exchange components that you host in a clustered environment.

Depending on your needs, you can run Exchange clusters at varying loads. Load is the computing burden a system carries. The optimal load for your server depends on the elements that determine server performance: processor speed, RAM, disk access speed, and so on. For cluster capacity planning in this chapter, percentages are expressed relative to the load at which you achieve optimal performance from your hardware. In reality, your optimal load may use only 80 percent of the computing resources of your hardware.

Important Do not configure your hardware to run using 100 percent of its computing resources in normal operation.

Full Load on Both Nodes

You can configure a cluster to run at 100 percent of the optimal load on both nodes of the cluster. On failover, the remaining active nodes run at more than 100 percent load and suffer a decrease in performance. Failover is the process of taking resources, either individually or in a group, offline on one node and brining them back online on another node.

Configuring for full load on both nodes is an acceptable strategy if you have planned outages for updating and maintaining server software and hardware. Under these circumstances, you can choose to manually fail over when there is little activity on your system. This strategy does not protect against unplanned outages. When there is a high level of activity, failover may cause remaining servers to run at excessive loads and possibly fail.

From an administrative perspective, this configuration is relatively simple to set up and maintain, but in the event of an unplanned outage, as the load increases on the remaining servers after a failover, the administrative costs increase.

Full Load with a Hot Spare Server

With this strategy, you configure a cluster with two nodes running at 100 percent of optimal load and one node, called a hot spare, runs at zero percent. On failover, the hot spare assumes the load from the failover node and runs at 100 percent.

This is the failover mechanism used in earlier versions of Exchange and is relatively simple to administer. However, you should not run other applications on the hot spare server, so this server usually remains idle.

High Availability with Static Load Balancing

With this strategy, you balance activity on your nodes such that remaining nodes run at 100 percent of optimal load after failover.

In the following two-node illustration, each node to runs at 50 percent of optimal load, so that on failover, the remaining node runs at 100 percent.

Figure 20.2 High availability failover

This strategy is safe in most cases. Although this strategy is more complex to configure, the additional administrative cost provides high availability and efficient use of hardware.

Failover Planning and Performance

In a cluster, the unit of failover is the resource group. Because Exchange allows each resource group, which appears to Exchange as a virtual server, to host multiple storage groups and because a node supports no more than four storage groups, you must be careful that on failover the total number of storage groups does not exceed four.

In Figure 20.2, if node 1 contains two storage groups and node 2 contains four storage groups before failover, the storage groups cannot mount on failover.

For faster performance and increased reliability of your storage resources, you can place transaction log files and storage groups on separate drives.

Because domain controllers demand substantial computing resources, Microsoft recommends that you do not run domain controllers in a cluster with Exchange. For more information about running domain controllers on a cluster, see the Windows 2000 Advanced Server documentation.

Clustering Support

The level of clustering support varies for different Exchange components. The following table details which components are supported, and in some cases, the type of clustering they are capable of supporting. The following terms are used to describe the level of functionality that each component supports.

Active/passive: only one instance of the component can run in a cluster.

Active/active: multiple instances of the component can run in a cluster.

Component | Functionality | Notes
Exchange System Attendant | Active/active | Multiple virtual servers per node
Information Store | Active/active | After failover: each node is limited to four storage groups
Message Transfer Agent (MTA) | Active/passive | One instance per cluster. The MTA will be in only one cluster group
POP3 | Active/active | Multiple protocol virtual servers per node
IMAP | Active/active | Multiple protocol virtual servers per node
SMTP | Active/active | Multiple protocol virtual servers per node
HTTP | Active/active | Multiple protocol virtual servers per node
NNTP | Not supported |
Key Management Service | Not supported
Full-text indexing | Active/active
Instant Messaging | Not supported
Chat | Active/passive | Does not require a System Attendant resource in virtual server

Note You can configure multiple protocol virtual servers using System Manager and IIS. Each Exchange cluster virtual server can host multiple protocol virtual servers.

An Exchange cluster can support connectivity using the Simple Mail Transport Protocol (SMTP), X.400, and Routing Group connectors; however, the connectors that allow connectivity to other mail systems are not supported in an Exchange cluster. Thus, as you plan your cluster strategy, arrange your Exchange clusters to connect using the appropriate connectors. For example, you can use a non-clustered version of Exchange 2000 as a bridgehead server to communicate with other systems.


Setting Up Windows Clustering

You must complete the following procedures in order to create an Exchange cluster:

  1. Install and configure cluster service on two computers running Windows 2000 Advanced Server.

  2. Install Exchange on the clustered computers (nodes).

  3. Create Exchange virtual servers in a cluster group.

Install and Configure Windows Clustering

For information about installing and configuring Cluster service, see the Windows 2000 Advanced Server release notes and documentation. You must install Cluster service after you install Windows 2000 Advanced Server, and before you install Exchange. You cannot convert a stand-alone, non-clustered Exchange server to a cluster server.

Note To move existing users to a clustered version of Exchange, you must use Exchange Task Wizard in the Active Directory Users and Computers snap-in.

Additional System Requirements

Windows Clustering has system requirements in addition to the requirements for Exchange. You must have a separate physical storage device for each resource group that you create. Microsoft does not support clustering on hardware that is not on the hardware compatibility list at http://www.microsoft.com. For additional system requirements, see the Windows 2000 Advanced Server documentation.

Install Exchange on a Cluster

Cluster service requires that you install Exchange on one node completely before installing on the second node. You must install Exchange using the same account you use to install Cluster service and the account must belong to the Domain Admins security group or have Exchange Full Administrator permissions.

Install Exchange on the same drive letter and directory on both computers and shared storage device (disk) in the cluster; the default installation directory (for binary files, which are not shared) is the local system drive.

The Installable File System (IFS) must be assigned the same drive letter on both nodes in the cluster. When you install Exchange, Setup assigns IFS to the M drive by default. If the M drive is not available, Setup assigns IFS to the next available drive after the M drive. Therefore, after you have configured your shared cluster drives, make sure that either M is unassigned on both nodes or that the next available drive letter after M is the same on both nodes.

You must install the same Exchange components on both nodes. At minimum, you must install Microsoft Exchange Messaging and Collaboration and Microsoft Exchange System Management Tools on both nodes.

Restart each computer after you install Exchange. For more information about installing Exchange, see Chapter 19, “Installing Exchange.”

Create a Resource Group

The following procedures describe how to create a resource group. These steps are required to create an Exchange virtual server:

  • Creating a group for the cluster resources

  • Creating the IP, network name, disk, and Exchange System Attendant resources

These tasks are completed from Cluster Administrator. You install Cluster Administrator automatically when you install Cluster service.

Create a Group

When Windows Clustering is installed, a default group, called Cluster Group, is created. Microsoft recommends that you do not use Cluster Group for Exchange. Create a new group instead.

To create a group:

  1. On one node, click Start, point to Administrative Tools, and then click Cluster Administrator.

  2. Right-click the Groups container, point to New, and then click Group.

  3. In New Group Wizard, in the Name box, type Your VS 1. Your VS 1 represents the name you give your resource group. In the Description box, you can type a description of the group.

    Note Microsoft recommends that you name this group based on its server name. For example if the Exchange virtual server name that clients use in their profile is MailServ1, then consider naming this group, MailServ1 VS.

  4. On the Possible Owner screen, verify that both cluster nodes are listed in the Available nodes box, and then click Finish.

    Your VS 1 appears under Groups.

Follow the previous procedure to create multiple groups. You must have an independent drive and an IP address for each group that you create. The number of groups that you can create on a cluster is limited to the number of independent drives that you have attached to the cluster and the number of storage groups that you have in each group. Each node can support up to four storage groups; however, it is recommended that you limit storage groups to three per node for the non-failover state. You cannot reuse any resource name in a cluster.

Important There can be only one public folder store in the cluster. After adding additional resource groups, you must delete the public folder store in new groups before you bring the groups online.

Assign Cluster Resources

Each virtual server in an Exchange cluster must be associated with a cluster group containing the following resources:

  • IP address

  • Network name

  • Disk

  • Exchange System Attendant

The following procedures describe how to assign these resources to your cluster group. If you already have a drive associated with the group, you can drag the drive into the group. If you do not have a disk resource, you can create an additional disk resource, see the Windows 2000 Advanced Server clustering documentation.

Note Except for protocol virtual servers, do not add more than one instance of an Exchange resource to a group.

To create an IP address resource:

  1. Right-click the group you created (Your VS 1), point to New, and then click Resource.

  2. In New Resource Wizard, on New Resource screen, in Name, type Your VS 1 IP. In Description, type a description. In Resource type, select IP Address.

    The Group box displays Your VS 1.

  3. On the Possible Owners screen, verify that both nodes appear in the Possible owners box.

  4. On the Dependencies screen, verify that no resources appear in the Resource dependencies box.

  5. On the TCP/IP Address Parameters screen, type the unique static IP address and subnet mask for this virtual server. This is the IP address for the virtual server running Exchange on your network; it does not refer to the physical computer. In Network, select the appropriate network card for this network connection, and then click Finish.

    This IP address is now associated with the Your VS 1 resource group.

To create a network name resource:

  1. Right-click Your VS 1, point to New, and click Resource.

    The New Resource Wizard starts.

  2. On the New Resource screen, in Name, type Exchange Network Name. The name you type is the display name; it is not the actual unique network name that identifies this virtual server on the network. In Resource type, click Network Name.

    Your VS 1 appears in the Group box.

  3. On the Possible Owners screen, both nodes appear in Possible owners. Click Next.

  4. On the Dependencies screen, in Available resources, click Your VS 1 IP, and then click Add.
  5. On the Network Name Parameters screen, in Name, type a name for the Exchange virtual server. This is the network name that uniquely identifies this Exchange virtual server on your network. Click Finish.

To assign a disk resource:

  1. Open Cluster Administrator.

  2. Click Groups.

  3. In the Groups container, select the container that contains the drive that you want to move to the cluster group node. Drag the drive into the Exchange Group container.

    After you move a drive into the Exchange Group container, click Exchange Group to see the drive in the result pane.

To create Exchange System Attendant resource:

Important Before creating Exchange System Attendant, the disk, IP address, and Network name resources must be online.

  1. Right-click Exchange Group, point to New, and then click Resource.

    The New Resource Wizard starts.

  2. On the New Resource screen, type a name and a description of the resource. In Resource Type, click Microsoft Exchange System Attendant. In Group, select Your VS 1.

  3. On the Possible Owners screen, verify that both of the servers on which you installed Exchange appear in Possible owners.

  4. On the Dependencies screen, add Exchange Network Name and Disk to Resource dependencies by selecting each one and clicking Add.

  5. On the first Exchange screen, select the administrative group and routing group in which you want to manage the virtual server.

  6. On the Data Directory screen, verify the location of the data files and then click Next. Be sure that this directory is empty.

    The configuration may take a few minutes. The Exchange service instances appear in the result pane.

  7. To bring the service online, right-click Exchange Group, and click Bring Online.

Important Do not use Service Control Manager, the command line, or System Manager to start or stop services or protocol virtual servers; use Cluster Administrator to perform these tasks.


Optional Configurations

After you create resource groups, you can configure Exchange. The following procedures are specifically for configuring Exchange running on server clusters.

Configuring Protocol Virtual Servers

Use this procedure to create additional protocol virtual servers after you install and configure Exchange cluster virtual servers.

  1. Create the protocol virtual server in System Manager, but do not bring the protocol online.

    For information about protocol virtual servers and supporting messaging clients, see the Exchange online documentation.

  2. In Cluster Administrator, right-click Exchange Group, point to New, and then click Resource.

    The New Resource Wizard starts.

  3. On the New Resource screen, type a name and a description of the resource. In Resource Type, select the protocol that matches the protocol virtual server that you created in step 1.

  4. On the Possible Owners screen, verify that both of the servers on which you installed Exchange appear in Possible owners.

  5. On the Dependencies screen, click Exchange Information Store, and then click Add.

    Exchange Information Store appears in Resource dependencies.

  6. On the Virtual Server Instance screen, select the protocol virtual server that you created in step 1, and click Finish.

  7. Right-click the protocol virtual server and then click Bring online.

Important When you run Exchange in a clustered environment, the System Manager Start, Stop, and Pause commands do not work for the protocols. You must control protocol virtual servers from Cluster Administrator (there is no pause functionality in Cluster Administrator).

Setting Up Full-Text Indexing

When you create the System Attendant resource for a resource group, the Exchange MS Search Instance, which is the full-text indexing feature of Exchange, is added to the group.

Important Do not delete Exchange MS Search Instance from your group unless you are sure that you never want to enable it.

To reinstall the Exchange MS Search Instance after it has been deleted, you must delete and recreate the Information Store resource on the virtual server. Even if you are not using full-text indexing, keeping Exchange MS Search Instance disabled on your virtual server does not affect performance.

To enable full-text indexing:

  1. In System Manager, open Servers, open Server Name, open Storage Group, right-click Mailbox Store, and then click Create Full-Text Index.
  2. In the Mailbox Store (Server Name) box, verify that the full-text index catalog will be created on the shared storage device, and click OK.

Removing Exchange from a Cluster

To remove all instances of Exchange from a cluster you must first delete all groups from the cluster. If you only want to remove a node, move all of the groups to other nodes and then remove Exchange.

If you are removing Exchange from a cluster, do not delete the first Exchange resource group (virtual server) created in the cluster until you remove all subsequent groups. The first group configured in a cluster contains the Exchange MTA, which must be removed last. If you want to maintain a group (virtual server) that is not running the MTA resource, delete the MTA resource and recreate it on the group (virtual server) that you want to maintain.

To delete a group from a node:

  1. In Cluster Administrator, select the group that you want to delete.

  2. Right-click the Exchange System Attendant resource, and then click Take Offline.

  3. Click the Exchange System Attendant resource, and then click Delete.

  4. Click Yes to delete all of the dependent resources.

To remove Exchange:

  1. Insert Microsoft Exchange 2000 Server compact disc into the CD-ROM drive.

  2. On the splash screen, click the Setup tab, and then click Exchange Server Setup.

  3. On the Component Selection screen, click the Action column next to the component that you want to remove, and then click Remove All.


Upgrading an Exchange 5.5 Cluster

When you upgrade an Exchange 5.5 cluster to an Exchange 2000 cluster, the Exchange 5.5 system files are removed from the local system drive and the Exchange 2000 system files are installed on the local system drive. Exchange points to the existing user data that is preserved on the shared disk resource.

When Exchange is in a clustered environment, it may coexist with earlier versions of Exchange as long as the two following conditions are met:

  • The Exchange cluster is not the first instance of Exchange 2000 Server within an Exchange 5.5 site.

  • The Exchange cluster does not serve as a bridgehead to an Exchange 5.5 site.

Therefore, for every Exchange 5.5 cluster in a different site, before you upgrade the cluster, you must first join a non-clustered Exchange 2000 server to the site.

This upgrade procedure assumes that the cluster operating system has already been upgraded to Windows 2000 Advanced Server, and is running in a Windows 2000 Server domain. For information about upgrading Windows NT 4.0 Cluster service, see the Windows 2000 Advanced Server documentation. This procedure also assumes that you have run Active Directory Connector to populate Active Directory with the Exchange 5.5 mailbox information. For more information about upgrading and running Active Directory Connector, see Chapter 16, “Upgrading and Coexisting.”

To upgrade an Exchange 5.5 cluster:

  1. Back up all user and configuration data on the cluster.

  2. In Cluster Administrator, bring the Exchange 5.5 Cluster group offline.

  3. From My Computer, go to H:\Exchsrvr, where H is the letter of the shared cluster drive, and rename the Mdbdata directory. If you do not rename this directory, the directory will be removed in step 4.

  4. Remove Exchange 5.5 Server from both nodes by running Exchange 5.5 Setup and selecting Remove all on the Installation Options screen.

    This removes the Exchange 5.5 system files. For more information about removing Exchange 5.5 Server, see the Exchange 5.5 documentation.

  5. From My Computer, go to H:\Exchsrvr, where H is the letter of the shared cluster drive, and change the directory that you renamed in step 3 back to Mdbdata.

  6. Install Exchange 2000 on both nodes of the cluster. For more information about installing Exchange on a cluster, see the earlier section, “Install Exchange on a Cluster.” After you finish installing a node, restart the node. Do not restart both nodes at the same time.

  7. Create a resource group in the same cluster group that the Exchange 5.5 virtual server was in, but do not bring the group online. For more information about creating resource groups, see the earlier section, “Create a Resource Group.”

  8. From My Computer, go to H:\Exchsrvr\Mdbdata, where H is the letter of the shared cluster drive.

  9. In the Mdbdata directory, delete all the files except for Priv.edb and Pub.edb. Rename these files Priv1.edb and Pub1.edb respectively.
  10. In Cluster Administrator, right-click the resource group, and then click Bring Online.

Note Do not attempt to upgrade a non-clustered Exchange 5.5 server and include it in a cluster. Also, do not attempt to add users by mounting a database from another Exchange server on a cluster.


Appendix A Exchange Language Support

Microsoft Exchange 2000 Server is available in the following languages:

English | German | Japanese
French | Spanish | Italian

Microsoft Outlook 2000 is available in the following languages:

Arabic | French | Korean | Swedish
Brazilian | German | Norwegian | Thai
Czech | Greek | Polish | Traditional Chinese
Danish | Hebrew | Portuguese | Turkish
Dutch | Hungarian | Russian |
English | Italian | Simplified Chinese
Finnish | Japanese | Spanish

Outlook Web Access is available in the following languages:

Czech | German | Norwegian | Spanish
Danish | Greek | Polish | Swedish
Dutch | Hungarian | Portuguese (Brazilian) | Traditional Chinese
English | Italian | Portuguese (Iberian) | Turkish
Finnish | Japanese | Russian |
French | Korean | Simplified Chinese

The Instant Messaging client is available in the following languages:

Arabic | Finnish | Italian | Simplified Chinese
Basque | French | Japanese | Slovak
Brazilian | German | Korean | Slovenian
Czech | Greek | Norwegian | Spanish
Danish | Hebrew | Polish | Swedish
Dutch | Hungarian | Portuguese | Traditional Chinese
English | Icelandic | Russian | Turkish


Appendix B Naming Convention Restrictions

Some characters are not permitted in the object name or display name of the following Exchange items:

  • Exchange organization

  • Internet Message Formats domain display names

  • Policies

  • Address lists

  • Offline address lists

  • Administrative groups

  • Routing groups

  • Storage groups

  • Mailbox stores

  • Public folder stores

  • SMTP and X.400 connectors

  • Public folder hierarchies

  • Instant Messaging virtual servers

  • Instant Messaging user addresses

  • Chat communities

When you name these items, use no more than 64 characters and omit the following symbols:

Symbol | Description
# | Number sign
; | Semicolon
, | Comma
“ ” | Quotation marks
/ | Slash mark
\ | Backslash
< > | Angle brackets
+ | Plus
* | Asterisk


Appendix C Accessibility for People with Disabilities

Microsoft is committed to making its products and services easier for everyone to use. This appendix provides information on the following features, products, and services that make Microsoft Windows 2000 and Microsoft Exchange 2000 Server more accessible for people with disabilities:

  • Features and hints for customizing Windows

  • Microsoft services for people who are deaf or hard-of-hearing

  • Microsoft product documentation online, or on audiocassette, floppy disk, or compact disc

  • Third-party utilities that enhance accessibility

  • Other products and services for people with disabilities

Note The information in this appendix applies only if you acquired this product in the United States. If you acquired Windows outside the United States, your package contains a subsidiary information card listing the telephone numbers and addresses of Microsoft support services. You can contact your subsidiary to find out whether the products and services this appendix describes are available in your area.


Customizing Windows

There are many ways you can customize Windows to make your computer more accessible.

  • Beginning with Windows 95, accessibility features are built in to Windows. These features are useful for individuals who have difficulty typing or using a mouse, have moderately impaired vision, or are deaf or hard-of-hearing. You can install the features during setup, or you can add them later from the Windows installation compact disc. Look up accessibility in the Windows Help Index for information about installing and using these features.

  • Many of the features that make Windows accessible can be added to earlier versions of those products, and to MS-DOS, through Access Pack files. You can download these files or you can order them on disks from Microsoft. For more information about these files, see "Accessibility Notes and Utilities to Download" later in this appendix.

  • You also can use Control Panel and other built-in features to adjust the appearance and functioning of Windows to suit varying vision and motor abilities. Options include adjusting colors and sizes, sound volume, and the functioning of the mouse and keyboard.

  • In Windows 98, you can adjust the majority of accessibility settings through Accessibility Wizard or Control Panel. Accessibility Wizard presents features sorted by disability, making it easy to customize Windows to meet the needs of each individual. Accessibility Wizard also enables you to save your settings to a file that you can use on another computer.

  • Dvorak keyboard layouts make the most frequently typed characters on a keyboard more accessible for users who have difficulty using the standard QWERTY layout. There are three Dvorak layouts: one for users who type with both hands, one for users who type with their left hands only, and one for users who type with their right hands only. You do not need to purchase any special equipment to use these features.

The specific features available, and whether they are built-in or whether you must obtain them separately, depend on which operating system you are using.

For complete documentation on the accessibility features available in the operating system you are using, obtain the documents listed below. The Microsoft Windows 95 Resource Kit, the Microsoft Windows 98 Resource Kit, the Microsoft Windows NT Resource Kit, and the Microsoft Windows 2000 Resource Kit also contain documentation on accessibility features.

Accessibility Notes and Utilities to Download

The following documents explain how to customize Microsoft Windows for users with disabilities. Specific instructions for downloading the files immediately follow this table.

For | You Need
Customizing Windows for Individuals with Disabilities (describes all of the other documents in this list and includes links to download them; this article is updated when new versions of Microsoft operating systems are released) | Microsoft Knowledge Base article Q165486
Customizing Microsoft Windows 95 for individuals with disabilities | Cst_W95.exe
Customizing Microsoft Windows NT 4.0 for individuals with disabilities | Cst_NT4.exe
Customizing Microsoft Windows NT 3.1 and 3.5 for individuals with disabilities (includes Access Pack for Microsoft Windows NT, which provides features for people who have difficulty using a keyboard or mouse, or who are deaf or hard-of-hearing) | Cst_NT3x.exe
Customizing Microsoft Windows 3.1 for individuals with disabilities | Cst_W3x.exe
Customizing Microsoft Windows for Workgroups 3.1 for individuals with disabilities | Cst_WG3x.exe
Customizing Microsoft Windows 3.0 for individuals with disabilities | Cst_W30.exe
Access Pack for Microsoft Windows 3.0 and 3.1, which provides features for people who have difficulty using a keyboard or mouse, or who are deaf or hard-of-hearing | ACCP.exe
Dvorak keyboard layouts for people who type with one hand (already included in Windows NT version 3.5 and later) | GA0650.exe

Downloading the Files

If you have a modem or another type of network connection, you can download the accessibility files from the following network services:

  • The Microsoft Accessibility and Disabilities Web site on the Internet, http://microsoft.com/enable.

  • Support Online from Microsoft Technical Support at http://support.microsoft.com/support. Select the search option: in My search is about, select All Microsoft Products, and in My question is, type Q165486. The search results display a link to the Knowledge Base article, "Customizing Windows for Individuals with Disabilities," which includes links to all of the documents listed in the previous table.

    For other accessibility articles, select the appropriate application from My search is about, and in My question is, type kbenable.

  • Microsoft Internet server at ftp.microsoft.com, in /softlib/mslfiles.

  • Microsoft Download Service (MSDL), which you can reach by dialing (425) 936-6735 any time except between 1:00 A.M. and 2:30 A.M. Pacific time.

    MSDL supports 1200, 2400, 9600, or 14400 baud rates (V.22bis, V.32, V.32bis, and V.42), with 8 data bits, no parity, and 1 stop bit. MSDL does not support 28800, 56K or Integrated Services Digital Network (ISDN) connections.


Microsoft Services for People Who Are Deaf or Hard-of-Hearing

If you are deaf or hard-of-hearing, complete access to Microsoft product and customer services is available through a text telephone (TTY/TDD) service.

Customer Service

You can contact the Microsoft Sales Information Center on a text telephone by dialing (800) 892-5234 between 6:30 A.M. and 5:30 P.M. Pacific time, Monday through Friday, excluding holidays.

Technical Assistance

For technical assistance in the United States, you can contact Microsoft Technical Support on a text telephone at (425) 635-4948 between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday, excluding holidays. In Canada, dial (905) 568-9641 between 8:00 A.M. and 8:00 P.M. eastern time, Monday through Friday, excluding holidays. Microsoft support services are subject to the prices, terms, and conditions in place at the time you use the service.


Microsoft Documentation in Alternative Formats

Documentation for many Microsoft products is available in several formats to make it more accessible.

Exchange 2000 Server documents are also available as Help on the compact disc that the product includes, and on the Exchange Web site at http://www.microsoft.com/exchange.

If you have difficulty reading or handling printed documentation, you can obtain many Microsoft publications from Recording for the Blind & Dyslexic, Inc. (RFB&D). RFB&D distributes these documents to registered, eligible members of their distribution service on audio cassettes or on floppy disks. The RFB&D collection contains more than 80,000 titles, including Microsoft product documentation and books from Microsoft Press. You can download many of these books from the Microsoft Web site at http://microsoft.com/enable/

For more information, contact RFB&D at the following address or phone numbers.

Recording for the Blind & Dyslexic, Inc.
20 Roszel Road
Princeton, NJ 08540 		URL:
Phone:
Fax: 		http://www.rfbd.org/
(609) 452-0606
(609) 987-8116


Utilities to Enhance Accessibility

A variety of hardware and software products are available that make personal computers easier to use for people with disabilities. Among the different types of products available for MS-DOS, Windows, Windows NT, and Windows 2000 are:

  • Programs that enlarge or alter the color of information on the screen for people with visual impairments.

  • Programs that describe information on the screen in Braille or synthesized speech for people who are blind or have difficulty reading.

  • Hardware and software utilities that modify how the mouse and keyboard function.

  • Programs that enable people to type with a mouse or by voice.

  • Word or phrase prediction software that allow users to type more quickly and with fewer keystrokes.

  • Alternative input devices, such as single switch or puff-and-sip devices, for people who cannot use a mouse or a keyboard.


Getting More Accessibility Information

In addition to the features and resources this appendix describes, other products, services, and resources for people with disabilities are available from Microsoft and other organizations.

Microsoft

Microsoft provides a catalog of accessibility aids that can be used with Windows. You can obtain this catalog over the Internet or by telephone.

Microsoft Sales Information Center
One Microsoft Way
Redmond, WA 98052-6393 		URL:
Voice telephone:
Text telephone: 		http://microsoft.com/enable/
(800) 426-9400
(800) 892-5234

Macintosh Disability Solutions

Information on products and services for the Macintosh that are available for people with disabilities is available by telephone or over the Internet.

Disability Solutions URL:
Voice telephone:
Text telephone: 		http://www.apple.com/disability/
(800) 600-7808
(800) 755-0601

Trace Research and Development Center

The Trace Research and Development (R&D) Center at the University of Wisconsin-Madison publishes a database of more than 18,000 products and other information for people with disabilities. The database is available over the Internet. The Trace R&D Center also publishes a book, titled Trace Resourcebook, which provides descriptions and photographs of approximately 2,000 products.

To obtain these materials, contact Trace R&D Center by mail, telephone, or over the Internet.

Trace R&D Center
University of Wisconsin
S-151 Waisman Center
1500 Highland Avenue
Madison, WI 53705-2280 		URL:
Fax:
 http://trace.wisc.edu/
(608) 262-8848


Chapter 1 Before You Begin

Microsoft® Exchange 2000 Server represents a significant advance in messaging software. Architectural improvements in Exchange and Microsoft Windows® 2000 make Exchange more flexible and scalable than ever before. You need to learn about these architectural changes and enhancements to understand how they affect your organization. Microsoft Exchange 2000 Server Planning and Installation is the place to begin.


Organization

Microsoft Exchange 2000 Planning and Installation consists of the following three parts and appendixes:

Part 1 Introducing Exchange 2000 Server This part provides an overview of the enhancements and new functionality in Exchange 2000 Server.

Part 2 Planning Your Deployment This part contains chapters that provide more detail about new Exchange 2000 Server functionality and how Exchange interacts with Windows 2000. This information includes the main architectural features of Exchange 2000 Server and is a good starting point for further research.

Part 3 Installing Exchange 2000 Server This part provides quick installation instructions, detailed installation instructions, and information about installing Exchange with Windows Clustering.

Part 4 Appendixes The appendixes contain supplementary information including:

  • Lists of languages available for Exchange 2000 Server and related clients

  • Naming convention restrictions

  • Accessibility options available in the product, from Microsoft, or from other sources


Server Edition and Enterprise Edition

There are two versions of Exchange 2000 Server: a Server Edition and an Enterprise Edition. The following table lists features of the two versions.

Feature | Enterprise Edition | Server Edition
Storage | Unlimited | Limited to 16 GB
Multiple database support | Yes | No
Connectivity to other systems | Yes | Yes
X.400 connector | Yes | No
Microsoft Outlook® 2000 | Yes | Yes
Development Kit | Yes | Yes
Instant Messaging | Yes | Yes
Chat Service | Yes | No
Front-end and back-end architecture support | Yes | No
Windows Clustering support | Yes | No
Licensing maintenance | Yes | No

This book covers all features of Exchange. With the exception of this table, the book does not distinguish between the two versions.


Contacting a Subsidiary

When you call your local Microsoft subsidiary, you should be at your computer and have the appropriate product documentation available. Be prepared to provide the following information:

  • Product version

  • Type of hardware, including network hardware, if applicable

  • Operating system

  • Exact wording of any messages that appeared on your screen

  • A description of what happened and what you were doing when the problem occurred

  • A description of how you tried to solve the problem

    Important Phone numbers for Microsoft subsidiaries are subject to change. For the most recent listing, visit the support Web site at http://www.microsoft.com/support. If there is no Microsoft subsidiary office in your country or region, contact the establishment from which you obtained your product.

Argentina
Microsoft de Argentina S.A.
Customer Service: (54) (11) 4316-4600
Fax: (54) (11) 4316-1922
Technical Support: (54) (11) 4316-4664

Armenia
See Russia

Austria
Microsoft Ges.m.b.H.
Phone: (43) (1) 610-64-0
Fax: (43) (1) 610-64-200
Standard Support:
Installation and Handling: (43) (1) 50222-2255

Azerbaijan
See Russia

Belgium
Microsoft NV
Phone: (32) (2) 730-39-11
Fax: (32) (2) 726-96-09
Microsoft Support Network Info. Center:
0800-18307
TechNet Subscription: (353) (1) 703-8738
MSDN Subscription: (353) (1) 708-8690
Microsoft Information Center: (32) (2) 481-52-52
Technical Support:
(32) (2) 513-32-74 (Dutch)
(32) (2) 502-34-32 (English)
(32) (2) 513-22-68 (French)
Web: www.microsoft.com/benelux/support

Belarus
See Russia

Bolivia
See Uruguay

Central America
Technical Support: (506) 298-2020
Support E-mail: mscasup@microsoft.com
Customer Service: (506) 298-2000
Customer Service E-mail:
msccatus@microsoft.com

Chile
Microsoft Chile S.A.
Phone: (56) (2) 330-6000
Fax: (56) (2) 330-6190
Customer Service: (56) (2) 800-330600
Personal Operating System and Desktop
Applications:
Phone: (56) (2) 330-6222
Fax: (56) (2) 341-1439

Colombia
Microsoft Colombia
Phone: (57) (1) 618-2245
Fax: (57) (1) 618-2269
Technical Support:
Línea de Respuesta Microsoft
Phone: (57) (1) 523-0022
Fax: (57) (1) 523-1220
Voice Mail: (57) (1) 503-4216

Croatia
Microsoft Hrvatska d.o.o.
Phone: (385) (1) 304-555
Fax: (385) (1) 335-051
Technical Support:
(Contact the subsidiary.)

Czech Republic
Microsoft s.r.o.
Phone (42) (2) 611-97-111
Fax: (42) (2) 611-97-100
Technical Support:
(42) (2) 215-03-222

Denmark
Microsoft Denmark
Phone: (45) 44-89-0100
Fax: (45) 44-68-5510
Technical Support:
Phone: (45) 44-89-0111
Microsoft Sales Support: (45) 44-89-0190
Microsoft FastTips: (45) 44-89-0144
(Document 303030 in FastTips contains detailed instructions)

French Polynesia
See France

Georgia
See Russia

Germany
Microsoft GmbH
Phone: (49) (89) 3176-0
Fax: (49) (89) 3176-1000
Telex: (17) (89) 83 28 MS GMBH D
Information: (49) (89) 3176 1199
Web: www.microsoft.com/germany

Greece
Microsoft Hellas, S.A.
Phone: (30) (1) 6806-775 through
(30) (1) 6806-779
Fax: (30) (1) 6806-780
Technical Support:
Phone: (30) (1) 9247-030
Fax: (30) (1) 9215-363

Hong Kong SAR
Microsoft Hong Kong SAR Limited
Fax: (852) 2560-2217
Product support Faxback Service:
(852) 2535-9293
Microsoft Club Hotline: (852) 2804-4277
Technical Support: (852) 2804-4222

Hungary
Microsoft Hungary
Microsoft Magyarország Kft.
Phone: (36) (1) 437-2800
Fax: (36) (1) 437-2899
Technical Support:
(36) (1) 267-4636

Japan
Microsoft Company Ltd.
Technical Support (Standard Support):
(81) (424) 41-8700
(Technical Support options/ Support Contract)
Phone: 0120-37-0196 (toll free domestic only)
Channel Marketing Information Center:
(Presales Product Support)
Tokyo Phone: (81) (3) 5454-2300
Osaka Phone: (81) (6) 245-6995
Customer Service Phone:
(Version upgrade/Registration)
Phone: (81) (48) 226-5500
Fax: (81) (48) 226-5511

Kazakhstan
See Russia

Kyrgyzstan
See Russia

Korea
Microsoft CH
Phone: (82) (2) 531-4500
Fax: (82) (2) 531-1724
Customer Service: 080-022-7337
(toll free domestic only)
Technical Support:
Office Technical Support:
(82) (2) 508-0040
Windows Technical Support:
(82) (2) 563-0054
Developer Technical Support:
(82) (2) 566-0071
Microsoft FastTips: (82) (2) 3453-7555
Support Sales: (82) (2) 531-4544

Latin America
Microsoft
Latin American Headquarters (U.S.A.)
Phone: (305) 489-4800
Fax: (305) 491-1616
Customer Service: (425) 936-8661
Technical Support: (214) 714-9100
Web: www.microsoft.com/latam/soporte

Netherlands
Microsoft BV
Technical Support:
(31) (20) 500-1005 (Dutch)
(31) (20) 500-1053 (English) Web:
www.microsoft.com/benelux/support

New Zealand
Microsoft New Zealand Ltd
Phone: (64) (9) 357-5800
Fax: (64) (9) 358-3726
Technical Support:
Phone: (64) (9) 357-5575
Fax: (64) (9) 307-0516 and 357-5577

Northern Ireland
See United Kingdom

Norway
Microsoft Norway AS
Phone: (47) (22) 02-25-00
Fax: (47) (22) 95-06-64
Technical Support: Standard:
(47) (22) 02-25-50
Priority: (47) (22) 02-25-45
Premier: (47) (22) 02-25-46
Microsoft Sales Support:
(47) (22) 02-25-80
Microsoft MSDL: (47) (22) 18-22-09
Microsoft FastTips: (47) (22) 02-25-70
(Document 404040 in FastTips contains detailed instructions)

Panama
Technical Support:
(506) 298-2020
Support E-mail: mscasup@microsoft.com
Customer Service: (506) 298-2000
Customer Service E-mail:
msccatus@microsoft.com

Papua New Guinea
See Australia

Romania
Microsoft s.r.l.
Phone: (40) (1) 222-90-16
Fax: (40) (1) 222-90-12
Technical Support: (40) (1) 312-09-48

Russia
Microsoft Z.A.O.
Microsoft Information Center:
(7) (095) 916-7171
Russia: 125252
Moscow: Postbox 70
Technical Support:
Moscow: (7) (095) 745-54-45
St.Petersburg: (7) (812) 118-36-36
Novosibirsk: (7) (3832) 119-019
Web: www.microsoft.com/rus/

Saudi Arabia
Microsoft Saudi Arabia
Phone: (966) (1) 488-1165
Fax: (966) (1) 488-1576
Technical Support:
(Personal Operating System and Desktop Applications only):
Phone: (800) 124-0500 (toll free within Saudi Arabia)
Fax: (966) (1) 474-0576

Scotland
See United Kingdom

Singapore
Microsoft Singapore Pte Ltd
Phone: (65) 337-6088
Fax: (65) 337-6788
Customer Services:
Phone: (65) 324-5255
Fax: (65) 324-6181
Product Support Services:
Phone: (65) 378-3600
Fax: (65) 378-3662

Slovakia
Microsoft Slovakia s.r.o.
Phone (421) (7) 37 63 02
Fax: (421) (7) 37 66 71
Technical Support: (421) (7) 531 20 83

Switzerland
Microsoft AG
Phone: (41) (1) 839-61-11
Fax: (41) (1) 831-08-69
Prices, updates: (41) (1) 839-61-11
Documentation:
Phone: (41) (1) 155-59-00
Web: www.microsoft.com/switzerland

Tajikistan
See Russia

Taiwan
Microsoft Taiwan Corp.
Phone: (886) (2) 504-3122
Fax: (886) (2) 504-3121
Technical Support:
Phone: (886) (2) 508-9501
Fax: (886) (2) 508-9575
Web: www.microsoft.com/taiwan/support

Thailand
Microsoft (Thailand) Limited
Phone: (66) (2) 266-3300
Fax: (66) (2) 266-3310
Product Support:
Phone: (66) (2) 613-7208 through 11
Fax: (66) (2) 613-7198

Turkey
Microsoft Turkey
Phone: (90) (212) 258-59-98
Fax: (90) (212) 258-59-54
Support Hotline:
Phone: (90) (212) 258-96-66
Fax: (90) (212) 258-95-99
Bulletin Board Service:
(90) (212) 227-93-90

Uruguay
Technical Support: (598) (2) 77-4934
Fax: (598) (2) 77-4935

Uzbekistan
See Russia

 Australia
Sales Information Centre:
(61) (2) 9870-2100
Web: www.microsoft.com.au
Technical Support: (61) (2) 9870-2131
Fax: (61) (2) 9805-0519

Brazil
Microsoft Informatica Ltda.
Phone: (55) (11) 5514-7100
Fax: (55) (11) 5514-7106/5514-7107
Technical Support: (55) (11) 5506-8087
Fax: (55) (11) 5506-7621
Automatic Fax: (55) (11) 5506-8506
Technical Support Bulletin Board Service:
(55) (11) 5506-1234
Customer Support: (55) (11) 822-5764
Customer Services Fax:
(55) (11) 822-6227

Canada
Microsoft Canada Co.
Head Office Phone: (905) 568-0434
Customer Information Centre:
(800) 563-9048
Technical Support:
Desktop Systems including Microsoft Windows 95: (905) 568-4494
Microsoft Office and Office Components:
(905) 568-2294
Other Standard Technical Support:
(905) 568-3503
Priority Support Information:
(800) 668-7975
Text Telephone (TTY/TDD) (905) 568-9641
Technical Support Bulletin Board Service:
(905) 507-3022

Caribbean
Microsoft Caribbean, Inc.
Phone: (809) 273-3600
Fax: (809) 273-3636
Technical Support: (408) 953 8086
Support E-mail: mscarsup@microsoft.com
Customer Service: (800) 297 5982 for area codes (787) & (809) only
Customer Service E-mail: msccatus@microsoft.com

Dominican Republic
See Central America

Ecuador
Corporation Microsoft del Ecuador S.A.
Phone:
(593) (2) 460-447, (593) (2) 460-451
Customer Service:
(593) (2) 460-453, (593) (2) 460-458
Technical Support: (593) (2) 463-094

Egypt
Microsoft Egypt
Phone: (20) (2) 594-2445
Fax: (20) (2) 594-2194
Technical Support:
Personal Operating Systems and Desktop Applications only:
Phone: (20) (2) 261-3991
Fax: (20) (2) 403-2718

England
See United Kingdom

Estonia
See Germany
Technical Support: (372) 650-49-99

Finland
Microsoft OY
Phone: (358) (0) 9-525-501
Fax: (358) (0) 9-878-8770
Technical Support:
Phone: (358) (0) 9-525-502-5026
Standard: (358) (0) 9-525-502-500
Priority: (358) (0) 9-525-502-20
Premier: (358) (0) 9-525-502-03
Microsoft MSDL: (358) (0) 9-878-77-99
(Swedish and English):
(358) (0) 9-455-03-66
Microsoft FastTips:
(358) (0) 9-525-502-550
(Swedish and English)

France
Microsoft France
Phone: (33) (1) 69-86-46-46
Fax: (33) (1) 64-46-06-60
Telex: MSPARIS 604322
Technical Support:
Phone: (33) (1) 69-86-10-20
Fax: (33) (1) 69-28-00-28

Iceland
See Denmark

India
Microsoft India
Phone: (91) (80) 559-5733,
(91) (11) 646-0767, (91) (11) 646-0694
Fax: (91) (80) 559-7133,
(91) (11) 647-4714

Indonesia (SP)
Microsoft Indonesia - Jakarta
Technical Support:
Phone: (62) (21) 5704254
Fax: (62) (21) 5208122

Ireland
See United Kingdom

Israel
Microsoft Israel Ltd.
Phone: (972) (3) 613-0833
Fax: (972) (3) 613-0834

Italy
Microsoft SpA
Phone: (39) (2) 7039-21
Fax: (39) (2) 7039-2020
Microsoft Rome Office: (39) (6) 5095-01
Fax: (39) (6) 5095-0600
Microsoft by Fax (Fax-on-demand service):
(39) (2) 70-398-888
Customer Service (New product info, product literature): (39) (2) 70-398-398
Dealer Support (Customer Service for resellers only): (39) (2) 70-398-388
Technical Support: (39) (2) 70-398-398
Microsoft Consulting Service:
(39) (2) 7039-21

Liechtenstein
See Switzerland (German, French, Italian)

Luxembourg
Microsoft NV
Phone: (32) (2) 730-39-11
Microsoft Support Network Info. Center: (31) 800-9977-57
TechNet Subscription: (353) (1) 703-8738
MSDN Subscription: (353) (1) 708-8690
Microsoft Information Center:
(32) (2) 481-52-52
Technical Support:
(32) (2) 513-32-74 (Dutch)
(32) (2) 502-34-32 (English)
(32) (2) 513-22-68 (French)
Web: www.microsoft.com/benelux/support

Malaysia (SP)
Microsoft (Malaysia) Sdn Bhd:
Phone: (60) (3) 793-9595
Fax: (60) (3) 791-6080

México
Microsoft México, S.A. de C.V.
(52) (5) 267-2110 Atencion a Distribuidores
(52) (5) 265-3380 Atencion a Clientes
(52) (5) 265-3399 Soporte Sistemas Operativos y Applicaciones de Escritorio
(52) (5) 267-2190 Soporte de Servidores y Herramientas de Desarrollo
Fast Tips: (52) (5) 261-2199

Morocco
Microsoft Afrique Du Nord
Phone: (212) (2) 47-10-72
Fax: (212) (2) 47-10-86

Paraguay
See Uruguay

People's Republic of China
Microsoft Asia Regional Engineering Center
20th Floor, Metro Tower
No. 30 Tian Yao Qiao Road,
Shanghai, 200030, P.R.C.
Phone: (86) (21) 6469-1188
Fax: (86) (21) 6469-1166
Faxbase: (86) (21) 6469-1188 Ext. 6988
Web: www.microsoft.com/china/support

Peru
Centro de Servicio al Cliente
Central de Soporte: (51) (1) 422-4116
Fax: (51) (1) 221 9052
Central de Informacion (51) (1) 242-5980
Fax: (51) (1) 447-8591

Philippines (SP)
Microsoft Philippines
Phone: (63) (2) 811-0062
Technical Support:
Phone: (63) (2) 892-2295,
(63) (2) 892-2495 and (63) (2) 813-2494
Fax: (63) (2) 813-2493

Poland
Microsoft Sp. z o.o.
Phone: (48) (22) 661-54-00
Fax: (48) (22) 661-54-34
Information Service: (48) (22) 865-99-33
Technical Support: (48) (22) 865-99-66

Portugal
Microsoft Portugal MSFT, Lda.
Phone: (351) (1) 440-9200
Fax: (351) (1) 441-2101
Technical Support:
Standard Support: (351) (1) 440-9280 through (351) (1) 440-9283
Fax: (351) (1) 441-1655

Puerto Rico
Technical Support: (408) 953-8086
Support E-mail: mscarsup@microsoft.com
Customer Service: (800) 297-5982 for area codes 787 & 809 only
Customer Service E-mail:
msccatus@microsoft.com

Slovenia
Microsoft d.o.o.
Phone: (386) (61) 1-800-800
Fax: (386) (61) 1-800-822
Technical Support:
(386) (61) 1-853-449

South Africa
Microsoft South Africa
Phone: (27) (11) 445-0000
Fax: (27) (11) 445-0046
Technical Support:
(Toll free): 0802-11-1104
(27) (11) 445-0000
Fax: (27) (11) 445-0343

South East Africa and Indian Ocean Islands
See South Africa

Spain
Microsoft Iberica SRL
Phone: (34) (1) 807-9999
Fax: (34) (1) 803-8310
Technical Support: (34) (1) 375-4004
Customer Service: (34) (1) 375-4004
From Spain only: 902-187-198
Fax Back telephone: (34) (1) 375-4004

Sweden
Microsoft AB
Phone: (46) (0) 8-752-56-00
Fax: (46) (0) 8-750-51-58
Technical Support:
Standard: (46) (0) 8-752-09-29
Priority: (46) (0) 8-751-09-80
Premier: (46) (0) 8-632-57-01
Sales Support: (46) (0) 8-752-56-30
Microsoft MSDL: (46) (0) 8-750-47-42
Microsoft FastTips: (46) (0) 8-752-29-00
(Document 202020 in FastTips contains detailed instructions)

Turkmenistan
See Russia

United Arab Emirates
Microsoft Middle East
Phone: (971) (4) 513-888
Fax: (971) (4) 527-444
Technical Support:
Personal Operating Systems and Desktop Applications ONLY:
Phone: (971) (4) 524-488
Fax: (971) (4) 524-495
E-mail: mts@emirates.net.ae
Priority Support Information:
(971) (4) 555-752
Customer Service Center:
(Version upgrade / TechNet and MSDN subscription)
Phone: (971) (4) 655-082
Fax: (971) (4) 655-097

United Kingdom
Microsoft Limited
Fax: (44) (870) 60-20-100
Phone: (44) (870) 60-10-100
Microsoft KeyData:
(Bulletin Board Service)
(44) (870) 50-30-200
(up to 28.8Kbaud, n, 8, 1)
Microsoft KeyFax:
(Faxback Information Service)
(44) (870) 50-30-100
Technical Support:
Desktop Applications, Home Products, Desktop Systems and hardware:
(44) (870) 50-10-100
Developer Products: (44) (870) 50-10-200
Business Systems: (44) (870) 50-10-300
Minicom Line (44) (870) 50-30-400
Pre-Sales Information:
Microsoft Connection (44) (345) 00-2000

Venezuela
Corporation MS 90 de Venezuela S.A.
Other information: (58) (2) 265-9922
Fax: (58) (2) 265-0863
Technical Support: (58) (2) 993-6755

Wales
See United Kingdom


Chapter 2 Overview

What's New

Microsoft Exchange 2000 Server includes significant architectural and feature-oriented enhancements and changes. This chapter provides an overview of what's new in Exchange 2000 Server. The chapters that follow contain detailed information.

Planning for, installing, configuring, and maintaining Exchange requires a highly trained individual or team to take advantage of the enhancements and integrated functionality that Exchange and Microsoft Windows 2000 offer. You can use this chapter to help you plan an approach to learning about Windows 2000 and Exchange 2000 Server.


Data Management

Identify who manages mailbox stores and public folder stores. Depending on how you organize your system, you may have multiple public folder hierarchies that are divided according to regions or divisions within your organization. You can use permissions to define who administers each public folder hierarchy in your organization. Backup and restore accountability may rest with Exchange administrators or with another group. For more information about managing information and backing up, see Chapter 7, "Information Store," and Chapter 14, "Backup and Restore."


User Management

Identify who performs administrative tasks, such as user account management and daily operation of Exchange. Because Exchange 2000 Server and Windows 2000 use Active Directory, some of these tasks are an extension of Windows 2000 administration. If one person manages all Windows 2000 users, consider having this person also manage Exchange recipients, because these tasks are closely related.

Identify people performing administrative tasks for different groups of users or servers. You might consider using multiple administrative groups to make it easier to assign permissions to a set of Exchange objects for special circumstances. For more information about administering users and servers, see Chapter 5, "Active Directory," and Chapter 6, "Administration."


Real-Time Collaboration

If you plan moderate to extensive use of Chat, Instant Messaging, or Unified Messaging components, assign a network topology specialist to evaluate and monitor bandwidth considerations. These components affect network resources. For more detailed information about topology planning, see Chapter 11, "Instant Messaging and Presence Monitoring" and Chapter 12, "Chat Service."


Administration and Routing

Identify who manages administration and routing in your Exchange system. When you first install Exchange 2000 Server, it runs in mixed mode, which allows servers running earlier versions of Exchange to coexist within the Exchange organization. Exchange organizations that no longer coexist with earlier versions of Exchange can run in native mode. The administrative model for organizations in native mode separates routing and administration: you can organize servers in administrative groups to manage permissions and apply system policies, and you can assign servers to routing groups that span administrative groups to most efficiently manage message traffic. For more information about administrative groups and routing groups, see Chapter 6, "Administration."


Outlook 2000

Outlook 2000 is the premier messaging client for Exchange, providing the most complete client support. In addition, Outlook uses MAPI, which includes support for native Internet features such as HTML e-mail and iCalendar.

Outlook offers Lightweight Directory Access Protocol (LDAP) compatibility, server synchronization, and offline support. You should use Outlook 2000 in Corporate/Workgroup mode (also known as MAPI mode) to take advantage of all of the scheduling and collaboration features Exchange offers. Outlook 2000 can also operate in Internet mode, but this mode provides only e-mail functionality and limited group scheduling.

Outlook 2000 integrates Microsoft Office applications with e-mail, personal organization, and workgroup software. It provides support for collaboration applications so that you can develop and deploy workgroup applications based on Microsoft Office. Exchange 2000 Server also supports Outlook 97 and Outlook 98, but Outlook 2000 provides a more extensive set of features. Only Outlook 2000, for example, supports multimedia messaging.

Outlook supports these Internet protocols: Network News Transfer Protocol (NNTP), POP3, IMAP4, SMTP, LDAP, and HTTP.


Supported Protocols

Exchange supports the following protocols:

  • SMTP

  • NNTP

  • HTTP

  • POP3

  • IMAP4

Each of these protocols communicates through Internet Information Services (IIS), a Windows 2000 component that Exchange uses. Clients use POP3 and IMAP4 protocols to retrieve mail from a server. Exchange 2000 supports these protocols because they are very common and many organizations use them.

You can configure independent instances of each protocol by creating virtual servers. A virtual server is a collection of services that appears as a physical server to clients. A virtual server typically includes all of the resources necessary to run a particular application, including a Network Name resource and an IP Address resource.

Note Although all Internet protocols are enabled for all users and virtual servers by default, you can restrict the use of one or more protocols for a specific user or virtual server.

The Internet protocols in Exchange 2000 Server support several authentication types in addition to Transport Layer Security (TLS) for transmission encryption. For details, see "Authentication" later in the chapter.

SMTP

SMTP serves two functions in Exchange 2000 Server. It is the native protocol for mail submission and it is the native transport protocol. This means that clients use SMTP to submit messages and servers use it to route messages and exchange replication information and other data. Exchange 2000 Server uses remote procedure call (RPC) to communicate with earlier versions of Exchange.

Clients submitting messages must establish an SMTP connection on TCP port 25, which is the standard SMTP port. The client sends a series of commands to the server and the server replies to each command. Typical SMTP commands notify the server of the sender's domain and host name, the sender's e-mail address, and the identity of one or more recipients of the message. It is possible for the server to reject a message based on the information these commands contain.

SMTP, which is based on specifications in Request for Comments (RFC) 821 and 822, is installed by default as an Internet Information Services (IIS) transport stack when you install Windows 2000 Server. When you install Exchange, it adds elements to the SMTP service, such as a routing engine and increased message queuing functionality. Windows 2000 includes a basic message categorizing utility, which is deactivated by default. Exchange activates and extends this utility and it becomes part of the queuing engine, providing advanced address resolution, among other things. After installing Exchange, you set remote domain settings on the SMTP connector rather than on the IIS virtual server. These enhancements give you greater control over your messaging system at every transport stage.

Message Queues

Exchange enhances SMTP by allowing you to view each virtual server’s queues. In System Manager, you can display a tree view of every queue the virtual server has on other servers. In addition to viewing the number of messages and other properties for each queue, you can perform actions such as freezing all messages or deleting messages with or without sending a non-delivery report (NDR).

SMTP Setup Consideration

If you are currently using SMTP on a computer running Windows 2000 Server for mail relay services or for Web site e-mail using an application such as CDONTS, for example, you must record your SMTP configurations prior to installing Exchange. When you install Exchange, the SMTP service reverts to the default SMTP settings.

NNTP

Microsoft NNTP Service, which is part of the Windows 2000 operating system, supports Internet standard NNTP. Exchange extends the NNTP capabilities of IIS, allowing your Exchange server to host news feeds in public folders.

Note Internet protocols that can access public folders can also access newsgroups hosted in the default public folder hierarchy in Exchange 2000 Server.

NNTP enables users running third-party applications that support NNTP to read and post items, such as messages and documents, to USENET newsgroups. Other USENET users around the world can read and respond to the items. To distribute the processing load in your organization, you can use a master server and subordinate server configuration. In this configuration, a master server receives the news feed and propagates the information to a number of subordinate servers throughout the organization.

There are push news feeds, in which USENET servers regularly send articles to your organization’s NNTP virtual servers, and there are pull news feeds, in which you configure your NNTP virtual servers to contact USENET servers for new articles. For more information about creating and maintaining news feeds, see the Exchange online documentation.

Public Folders

You can use public folders to organize newsgroups and articles. Although you can use the file system to store news articles, public folders provide a convenient hierarchy that make reading, moving, and posting articles easier for your users.

Note When you maintain newsgroups in public folders, administration for some NNTP properties, such as Expiration Policy, is transferred from the NNTP virtual server to the public folder store.

NNTP Setup Considerations

Newsgroups require a large amount of storage space; therefore, the Exchange server running the NNTP service should be able to support the number of users you expect to use the newsgroup public folders. Also, a USENET news feed can send hundreds of gigabytes of data across your network. Make sure that your Internet connection has the bandwidth to support a news feed without disrupting other network traffic, such as e-mail.

For best performance, use multiple drives for news storage. This prevents bottlenecks when the server is processing large amounts of data. Most organizations reserve three drives for hash tables and at least eight drives for transaction log storage.

Public folder replication is another issue you need to consider. The directory and public folder store replicate changes on a schedule. Whenever you create a new public folder on a server, the resulting change in the public folder hierarchy replicates to all other servers in the organization. If your network topology includes remote routing groups that are connected over low-bandwidth connections, make sure that replication does not saturate the connections when you set up a news feed. If the news feed includes a large number of newsgroups, you may need to phase in the new folder over several days to prevent a flood of replication messages from saturating your network.

With multiple storage groups in Exchange 2000, you can create a news feed on a public folder store and place it in a different storage group than the one containing your users’ mailboxes. Thus, you can enable circular logging for the news feed to save disk space without compromising the reliability of other storage groups.

Note Only the default public folder hierarchy is MAPI-enabled. Creating a news feed in a separate storage group requires users to use non-MAPI clients to read articles.

For more information about storage groups, public folders, and circular logging, see Chapter 7, “Information Store.”

HTTP

Exchange 2000 Server has native support for HTTP 1.1, an Internet standard (RFC 2616) that provides access for Web browsers and other services. Exchange also supports an extension to HTTP 1.1 called Distributed Authoring and Versioning (WebDAV). WebDAV, which is also an Internet standard (RFC 2518), allows clients to perform file-system operations on a remote server and provides the capability for simple publishing. WebDAV transmits data in Extensible Markup Language (XML) format. Using WebDAV, developers can create custom workflow and collaboration applications.

HTTP allows users to access the Information Store and use Exchange as a central repository for e-mail and Microsoft Office documents. With Office 2000 applications, users can open and save documents in the Information Store. The Office 2000 Web Folders feature provides a solution for shared document access and collaborative authoring on your intranet or over the Internet.

Note Web Folders in Office 2000 become My Network Places after you install Windows 2000.

With HTTP support in the Information Store, all items can have a URL address, including a user's inbox, calendar, or even an individual message. This also makes remote mailbox access and manipulation possible for Outlook Web Access or any Internet client.

You can allow Internet client access to part of a public folder hierarchy by pointing to the virtual root defined for the HTTP virtual server. A virtual root is a directory that a user sees when connected to an Internet server. For more information about HTTP, see "Virtual Servers" later in this chapter.

POP3 and IMAP4

Exchange supports any client compliant with POP3 or IMAP4. POP3, a simple protocol designed primarily for offline use, allows users to read their messages from the server. A user connects to a server and downloads all of his or her e-mail from an inbox to the client. It is possible for a POP3 client to leave e-mail in the server inbox, but users cannot access other folders on the server. When a POP3 client sends a message, SMTP routes messages to the computer running Exchange or to other SMTP hosts, depending on the recipient's address.

IMAP4 works like POP3, but with a few enhancements. It is well suited for environments in which downloading all of a user’s mail to a specific computer is impractical. The protocol enables clients to access and manipulate messages stored within mailboxes. Unlike POP3, IMAP4 allows a user to access public foldersor multiple e-mail folders, search through a mailbox, and maintain read and unread message flags. In addition, a user can download an entire message or a portion of a message, such as an attachment. IMAP4 clients use SMTP to send outbound messages from Exchange.


Authentication

Authentication is the process by which users who claim to have accounts on your system are verified. Organizations commonly implement this security method for remote users who connect to the system over the Internet. You can set authentication methods on virtual servers for each instance of a protocol running on an Exchange server.

Anonymous

You can configure Exchange to support anonymous access for all Internet protocols except POP3. With anonymous access, Exchange does not prompt users for a password or other credentials. Anonymous authentication allows non-validated users to access data stored in Exchange; for example, if you want to make certain public folders available to IMAP4 users outside your organization, you can enable anonymous authentication at the public folder level. Users connecting to Exchange anonymously use the Windows 2000 account IUSR_computer name, in which computer name is the name of the Exchange server they are connecting to. By controlling permissions on that account, you can control permissions for anonymous users.

Basic

Basic authentication requires that the user submit a user name and password. This transaction is completed in clear (unencrypted) text, so it’s not very secure. Nonetheless, Basic authentication is the most widely used authentication method.

Basic with SSL

If you use Basic authentication, Microsoft recommends you use Secure Sockets Layer (SSL) encryption, an industry-standard protocol that provides privacy between a client and a server over the Web. When someone wants to access your system over the Internet, the session begins with a handshake phase, in which an encryption algorithm and session keys are negotiated. Before data is transmitted, the data is encrypted using the session keys.

Note SSL encryption is not available for every Internet protocol that Exchange and IIS support. The SMTP protocol, for example, uses TLS to encrypt session data in a manner that is similar to SSL encryption.

Note that using SSL encryption or any transport-layer security substantially increases the processing load on your Exchange servers.

NTLM Protocol

NTLM protocol is the default method for network authentication in Windows NT 4.0. Windows 2000 supports NTLM protocol for compatibility with earlier clients and servers. This method uses Windows NT 4.0 and Windows 2000 credentials along with an encrypted password for authentication. You activate NTLM protocol when you select Integrated Windows authentication for the virtual server. In a native Windows 2000 environment, however, the same setting activates Kerberos V5 protocol instead.

Note For NTLM protocol to work, clients connecting over the Internet must use Outlook Express or Internet Explorer version 3.0 or later.

Computers running Windows 3.11, Windows 95, Windows 98, or Windows NT 4.0 use NTLM protocol for network authentication in domains running Windows 2000. Computers running Windows 2000 use NTLM protocol when authenticating servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains.

Kerberos V5 Protocol

Kerberos V5 protocol is more flexible and secure than NTLM protocol. The implementation of the protocol in Windows 2000 is based on standards recommended to the Internet Engineering Task Force (IETF). Therefore, this implementation lays the foundation for very secure interoperability with other networks using Kerberos V5 authentication.

The advantages of Kerberos V5 protocol over NTLM protocol include:

Mutual authentication Servers verify the identity of clients as they do with NTLM protocol, but in addition, clients verify the identity of servers.

Faster connections Servers don’t have to contact the domain controller to verify each client. They can use the credentials the client presents.

Delegated authentication Kerberos V5 protocol has a mechanism that allows a service to impersonate its client when connecting to other services. In a front-end and back-end server configuration, for example, a client can use Kerberos V5 protocol to authenticate with the front-end server, which then relays that authentication information to access data on the back-end server. This is not possible with NTLM protocol.

Note To get a Kerberos V5 service ticket for authentication with a server, a client must first contact the Key Distribution Center (KDC) for the domain of that server (usually the domain controller). Because the client must contact the KDC directly, Kerberos V5 protocol is better suited for intranets than for the Internet. An exception is a client using point-to-point tunneling protocol (PPTP) to connect to a virtual private network (VPN).

Digest authentication

Digest authentication is available for HTTP in IIS. Digest authentication is similar to Basic authentication, except it sends a hash value over the network instead of a password. For more information on Digest authentication, see the Windows 2000 documentation.


Chat Clients

Chat Service is fully compatible with many chat clients, including:

  • PIRCH, mIRC, and other clients that use the Internet Relay Chat (IRC) protocol.

  • Microsoft Chat (also known as Comic Chat) version 2.1 and later, which uses Extended IRC (IRCX), Microsoft's proposed extensions to the standard IRC protocol. For more information about IRCX, see the Internet draft "Extensions to the Internet Relay Chat Protocol (IRCX)."

You must make chat client software available to users and provide instructions for logging on to the service. If you are hosting more than one chat community, give users the TCP port number of each community.


Considerations for Multimedia Content

When you choose clients, consider how your organization uses multimedia content in messaging. Exchange 2000 Server supports multimedia content. Outlook 2000 and Outlook Web Access (with Internet Explorer 5.0 or later) are the best clients for using multimedia with Exchange. Other clients can also use multimedia in conjunction with third-party applications.

Exchange uses streaming to transfer multimedia content to clients with minimum impact on network performance. Exchange uses Voice Profile for Internet Mail (VPIM) to transfer voice data between Exchange servers and the Internet. This section briefly discusses streaming and VPIM to provide you with background information for client considerations related to multimedia messaging.

Streaming Content

Exchange uses HTTP and streaming to allow users to preview multimedia content embedded in messages. Exchange sends the first few seconds of audio or video to the client, and the remaining content follows in pieces just large enough to provide uninterrupted playback; for example, streaming allows a user to play the first 10 seconds of a 20 MB multimedia presentation. The user can then decide whether to continue listening to the presentation or stop playback. Stopping the playback halts the streaming and the resulting usage of network bandwidth. Without streaming, users must download the entire message to the client before reviewing any content.

VPIM Messages

VPIM is a message format that allows voice-messaging systems to transmit voice and fax messages within a corporate intranet or across the Internet. Exchange accepts messages in VPIM format and stores them in the Exchange multimedia message format. Before messages are sent to an external voice mail system, Exchange converts the message back to VPIM. This VPIM interoperability allows Exchange users to forward all their voice mail to their Exchange mailboxes. Thus, users can check any kind of messages using a computer, but only their voice mail messages using a telephone. With third-party software, users can check all messages using a telephone for true unified messaging.


Outlook Express

Outlook Express is available with Microsoft Internet Explorer versions 4.0 and 5.0. Like Internet Explorer, Outlook Express is free, easy to use, and has lower hardware requirements than Outlook. Outlook Express allows users the freedom to send and receive e-mail from anywhere that is convenient, making it well suited for home use and for occasional e-mail users. Keep in mind that Outlook Express does not offer the full range of collaborative and scheduling features that Outlook 2000 does. Outlook Express supports e-mail in Secure/Multipurpose Internet Mail Extension (S/MIME) and HTML format.

Other Internet protocols that Outlook Express supports are POP3, IMAP4, SMTP, NNTP, and LDAP.


Instant Messaging Clients

Instant Messaging users need computers with an Intel Pentium or Pentium-compatible processor. No version of the Instant Messaging client is currently available for Digital Alpha computers. Instant Messaging users must use computers running Windows 95 or later, Windows NT® 4.0 Server or later, or Windows NT 4.0 Workstation.

Users who want to send and receive instant messages need the following software:

  • Internet Explorer version 5.0, which you can download from http://www.microsoft.com/

  • Microsoft Winsock 2.0 (if users use Instant Messaging outside your Exchange organization)

    Note Winsock 2.0 must be installed on computers running Windows 95. Install the Windows Socket 2 Update from http://www.microsoft.com/windows95.

    • The Exchange Instant Messaging client, which is available in the \Instmsg\I386\Client directory on the Exchange 2000 Server compact disc

After you install Instant Messaging Service, notify your users when the service is available and tell them how to get the software they need.


Outlook Web Access

Outlook Web Access provides access to e-mail, a personal calendar, group scheduling, contacts, and collaboration applications using a Web browser. Outlook Web Access is a cross-platform solution, which users can access at their own computers or from other workstations that have limited capabilities.

Outlook Web Access in Exchange 2000 Server provides a user interface consistent with Outlook 2000 and faster performance than earlier versions of Outlook Web Access. For more information about Outlook Web Access functionality and compatible browsers, see Chapter 10, "Outlook Web Access."


Copyright

Copyright and Trademarks

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2000 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, FrontPage, Hotmail, Microsoft Press, MSDN, MSN, Outlook, PowerPoint, Visual Basic, Visual C++, and Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


Exchange 2000 Server - Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z