任何人都可以在一个服务器上安装和配置Exchange Server。但是，简单安装与创建一个完美的Exchange部署是有很大区别的。在实际环境中部署Exchange需要精心的规划。你需要考虑从硬件维护到服务器监控的所有事情。正如你将在本文中看到的，稳定、强力的Exchange部署包括一些微软提供的与Exchange相关的外部工具，同样也需要精心的规划。
校验硬件兼容性
Windows Server 2003和Exchange只能运行在x86服务器或PC上，这也是微软硬件兼容性列表（HCL）存在的一个理由；它包含了一个硬件列表，微软对其进行了彻底的测试并保证它们与Windows Server OS 100%兼容。我建议您只使用微软认证的硬件。这仅仅是避免了兼容性问题，但是也许使你可以更容易获得技术支持。
当你采购服务器硬件时，你需要了解微软关于HCL列表硬件的策略。尽管HCL列举了独立组件（例如系统主板、SCSI控制器、显示卡等等），但是微软只认证完整的系统。如果你用未经微软认证的组件构建服务器，该服务器不会获得支持。但是微软允许你从一个经认证的服务器开始，然后向系统中添加未被HCL列出的组件。
规划你的部署
对于Exchange部署最重要的部分在规划阶段。要将规划部署所需要了解的所有事情完全展现，需要相当大一块面积的图纸，因此让我们只关注于冗余和灾难恢复。毕竟，不管你如何规划Exchange组织，总会发生某种类型的失败。在规划期间，你需要确定组织所能够容忍的失败级别。
群集。如果邮件是你所在组织的关键任务应用，并且无法接受任何级别的失败，则应该考虑使用群集数据库服务器。这样，如果一个数据库服务器失败，群集中的另一个服务器会接管工作。拥有一个群集还使你可以关闭一台服务器进行维护，同时不影响邮件服务的可用性。
有两种群集模式：主动/主动和主动/被动模式。在主动/主动模式中，所有的服务器同时并行工作，而在主动/被动模式中，至少有一台服务器在无故障情况下是待机的。主动/被动模式是首选的；在主动/主动模式下，如果发生失败，没有多余的服务器用来接管工作负载。在主动/被动模式下，剩余的群集节点会执行自己以及失败节点的工作。最糟的情况是，性能将会下降，工作负载也可能完全超出剩余节点的承受能力。但是要记住，主动/被动模式的群集可以多于两个群集节点。因此，当群集节点增加时，未使用的群集硬件会减少，除非你将多个节点设计为被动。
不熟练的Exchange管理员错误地认为群集数据库服务器可以防护任何类型的失败。但其实群集数据库服务器只能防护数据库服务器失败。你的组织可能遇到大量其它类型的失败点，例如DNS服务器、全局编目（GC）服务器、前端Exchange服务器，甚至是一个WAN连接。好消息是你可以利用冗余来克服所有这些故障。
正如你可以群集Exchange数据库服务器一样，你也可以群集Exchange前端服务器。在这种情况下，主动/主动模式和主动/被动模式都不适用，因为一个前端Exchange服务器实际只是一个托管Outlook Web Access（OWA）的Microsoft IIS服务器。因此你应该使用网络负载平衡（NLB）服务来群集前端Exchange服务器，就像群集其它Web服务器一样。
巩固AD、DNS和GC。记住Exchange完全依赖于AD，它也可能是一个失败点。如果AD失败，或者AD对于Exchange不可访问，Exchange也将失败。
如果你有多个域控制器（DC），你也许假设你的AD不会失败。这是一个好的开端，但是你仍然要关注AD的依赖性。也许最常见的问题就是AD没有DNS服务器就无法工作。因此，至少具有一个辅助DNS服务器是至关重要的，如果主要DNS服务器失败，AD仍然可以继续工作。许多大型组织会在每个分支部门放置DC和辅助DNS服务器，以便在WAN连接失败时分支部门内部的系统仍然可以相互通讯。当然，在分支部门放置DNS和DC服务器导致总部与分支部门之间WAN连接的与复制相关的传输。你需要考虑是否有足够的带宽来支持额外的传输。
当你在一个新的森林中创建第一个DC时，Windows将新的DC配置为一个DNS服务器（即假设你没有一台DNS服务器），同时它为该服务器指派了多个AD角色。这些角色中的大多数在整个森林中只能指派给一台服务器（森林级别的角色），或者只能是每个域中的一台服务器（域级别角色）。如果具有这样角色的DC不可挽回地失败，则这些角色总是可以被指派给其它的DC。但是如果是域中的第一台DC失败，那么你将遭遇噩梦，除非你事先曾对此进行过规划。默认情况下，这个DC主管所在森林和域的全部操作主机角色。该服务器通常也作为一个DNS服务器和GC服务器，缺少其中任何一个，Exchange都无法工作。我本人曾处理过这样的情况，并且它没有辅助DC和DNS服务器，确实很糟糕。
有多个原因使得GC服务器非常重要。例如，如果没有可用的GC服务器，则管理员将是唯一被允许登录的用户。另外，Exchange服务器必须查询GC服务器以便解析消息收件人的邮件地址。当Microsoft Outlook客户端打开全局地址列表（GAL）时，GC服务器也是至关重要的。
我的观点是你应该允许DNS服务器或GC服务器成为网络上的单一失败点，特别是两个服务位于同一台服务器时。好消息是将一台服务器指派为一个辅助DNS服务器很简单，同时你可以将任何DC配置为一个GC服务器。但是你肯定不想将组织中的所有DC配置为GC服务器，除非你的网络只有一个域。
基本上，你应该在任何包含一个Exchange服务器的AD站点放置一个GC服务器。例外情况是站点内的邮箱少于100个，并且你具有到其它包含GC服务器的站点的可靠WAN连接。当然，如果WAN连接失败，将没有GC服务器可以访问。当你规划GC服务器的位置时，你也要确保对于每4个Exchange CPU至少有一个GC服务器。这样可避免GC服务器过载。
测试你的规划
现在你已经具有了部署Exchange的思路，你需要测试你的设计方案。微软提供了名为System Center Capacity Planner的工具，非常适合于测试部署的潜力。
这个工具允许你创建一个部署的虚拟模型。不仅是Exchange组织拓扑以及服务器放置的模型，还可以包括服务器硬件提案以及网络连接速度等因素。你可以根据模型来进行模拟，比如在每个Exchange服务器上具有一定数量邮箱的用户，以及预期的每个用户的活动。进行了完全的模拟后，System Center Capacity Planner会显示设计方案中不能可靠满足预期工作负载的部分。
当然，你必须记住模拟仿真只是在模拟的硬件上的模拟用户，而不是真实的性能数据。模拟仿真并非完全精确，因为在实际情况下，服务器性能并不总是在预期的水平，用户通常也并不遵从预期的使用模式。因此，为了留出余地，我建议增加10%的预期工作负载。
显然，System Center Capacity Planner对于判定设计方案是否适合组织的需求来说是一个很好的工具。这个工具也允许你为未来进行规划。在测试了你的模型之后，并且你已确认了你的规划，则你可以进行不同“What if?”游戏。例如，你也许希望看到向特定服务器增加100个邮箱后的效果。如果你的网络使用冗余WAN连接，你甚至可以查看一个连接失败后的网络性能。System Center Capacity Planner不能从Microsoft Web站点下载，但是它包含在TechNet和MSDN订阅中。
优化调整
即便你为规划Exchange部署投入了全部精力，在部署完成之后，你仍然可能需要进行一些优化调整。你需要确保一切都如期望的那样执行，同时你的配置应该遵从微软建议的最佳实践。幸运的是，微软提供了一个非常适合于该任务的工具：Microsoft Exchange Best Practices Analyzer（ExBPA）。
ExBPA从多个源收集配置和性能数据，比如Windows注册表、AD、性能监视器以及元数据库。当它完成数据采集后，ExBPA将其与多个最佳实践规则进行对比。在此期间，ExBPA可以生成详细的报告，指导你一步一步地获得更好的性能、稳定性以及安全性。
维护
对Exchange部署进行了优化调整后，你可以将注意力转移到长期的监控和维护上，有多种理由说它很重要。首先，你的Exchange组织不可避免地随时间而改变。即使你并不计划增加服务器或者重新安排部署（尽管两种情况都有可能），使用的水平也仍然会变化。数据库将会增长，你可能会创建更多的邮箱。Exchange收到的垃圾数量也总是会不断波动。所有这些因素都会对Exchange组织的性能造成某种影响。
其次，常规维护对于确保可靠性至关重要。一个服务器的性能指标和事件日志经常包含潜在问题的线索，如果不及时处理，将会很快变为现实问题。保持跟踪这些信息可以使你在服务中断之前纠正问题。
许多组织忽视监视Exchange服务器的任务。全面的性能监视是一个全天候工作，并且要准确地解释数据，负责查询日志和性能指标数据的人员必须高度理解Exchange和Windows，因此许多公司只能手划十字并祈祷一切OK。几年以前，Microsoft Operations Manager （MOM）通过将服务器监视任务自动化改变了这一状况。MOM根据服务器健康标准监视性能指标和事件日志。MOM在许多场合下也能提前预示问题的发生。System Center Capacity Planner对于设计MOM服务器部署同样很有帮助。
关注关键地带
我不能过分强调精心规划和测试对于Exchange部署的重要性。我也并不装作能在此说明一个优秀的Exchange组织所涉及的全部方面，但是我希望我指明了特定的地带，对其进行精心的准备将会为你的组织的长期稳定性带来很大的帮助。