如何解决 Exchange Server 中的邮件中继问题

简介 %26#8226; 邮件中继问题的症状 %26#8226; NDR 包含错误代码 500、571 或 573 的可能原因 %26#8226; 出现事件 1701、1709、1710、4001 和 7004 的可能原因 %26#8226; 如果将您的 Exchange 计算机配置为可发送未经请求的商业电子邮件的开放邮件中继 %26#8226; 如果邮件中继源自未配置为开放邮件中继的 Exchange 计算机上的帐户 %26#8226; 如何为传入邮件和中继邮件设置 SMTP 域 %26#8226; Exchange 组织的本地域 %26#8226; Exchange 组织的非本地域 %26#8226; 可在您的 Exchange 组织和另一台 SMTP 服务器之间共享的域
%26#8226; 如何解决 NDR 包含错误代码 571 或 573 的问题 %26#8226; 方案 1：不允许经过身份验证的计算机中继邮件 %26#8226; 方案 2：对 SMTP 虚拟服务器的匿名访问被禁用 %26#8226; 方案 3：未正确配置 DNS 功能 %26#8226; 方案 4：没有与代理地址相匹配的收件人策略 %26#8226; 方案 5：目标服务器要求进行其他身份验证 %26#8226; 方案 6：ISA Server 2000 SMTP 发布规则未更新
%26#8226; 参考
本页 概要 简介 邮件中继问题的症状 NDR 包含错误代码 500、571 或 573 的可能原因 出现事件 1701、1709、1710、4001 和 7004 的可能原因 如果将您的 Exchange 计算机配置为可发送未经请求的商业电子邮件的开放邮件中继 如果邮件中继源自未配置为开放邮件中继的 Exchange 计算机上的帐户 如何为传入邮件和中继邮件设置 SMTP 域 Exchange 组织的本地域 Exchange 组织的非本地域 可在您的 Exchange 组织和另一台 SMTP 服务器之间共享的域 如何解决 NDR 包含错误代码 571 或 573 的问题 方案 1：不允许经过身份验证的计算机中继邮件 方案 2：对 SMTP 虚拟服务器的匿名访问被禁用 方案 3：未正确配置 DNS 功能 方案 4：没有与代理地址相匹配的收件人策略 方案 5：目标服务器要求进行其他身份验证 方案 6：ISA Server 2000 SMTP 发布规则未更新 参考 这篇文章中的信息适用于:
概要 可以将运行 Microsoft Exchange Server 2003 或 Microsoft Exchange 2000 Server 的计算机配置为邮件中继。因此，可通过 Exchange 计算机将发送到其他域或发自其他域的邮件转发到目标。但是，如果将 Exchange 计算机或 Exchange 计算机中的帐户配置为开放邮件中继，则可能会出现某些问题。此外，如果未正确配置邮件中继，也可能会出现某些问题。
可以使用配置为开放邮件中继的 Exchange 计算机发送未经请求的商业电子邮件（也称为垃圾邮件）。如果其他邮件服务器将您的 Exchange 计算机识别为未经请求的商业电子邮件服务器，则可能会将该计算机添加到禁止列表中。因此，在将邮件发送到其他域时可能会遇到问题。要解决此问题，必须将 Exchange 计算机重新配置为非开放邮件中继。然后，必须从禁止列表中删除 Exchange 计算机。
如果 Exchange 计算机不是一个开放邮件中继，则可以使用 Exchange 计算机中的帐户发送未经请求的商业电子邮件。因此，必须防止有人使用损坏的帐户。
本文介绍邮件中继问题的症状，并提供纠正 Exchange 计算机配置的步骤。 简介 本文介绍以下内容： %26#8226; 如何解决 Microsoft Exchange Server 2003 和 Microsoft Exchange 2000 Server 中的邮件中继问题。 %26#8226; 如何防止将 Exchange 计算机用作开放邮件中继。 %26#8226; 如何在 Exchange 中为传入邮件和中继邮件设置 SMTP 域。
Exchange 提供完整的简单邮件传输协议 (SMTP) 邮件服务。Exchange SMTP 服务器可用于接收邮件并将其中继到网络上的其他 Exchange 计算机或 Internet 上的其他 SMTP 服务器。邮件中继允许 Exchange 邮件客户端将邮件发送给其他组织中的用户。如果不允许邮件中继，则 Exchange 计算机只能接收和发送与自己位于相同邮件域中的用户的邮件。
如果允许中继邮件，则 Exchange 计算机可以对发送到自己所在域之外的邮件域中的邮件进行转发。此行为使得 Exchange 可以将邮件转发给任何内部或外部网络 SMTP 服务器。
如果 Internet 用户可以访问您的 Exchange 计算机，则一定要小心。因为不道德的用户会将您的 Exchange 计算机用作邮件中继。这些用户可将邮件转发到您的 Exchange SMTP 服务器，从而将未经请求的商业邮件（也称为垃圾邮件）分发到大量计算机中。这可能会对用于 Internet 连接的带宽产生不利影响，并会导致将您的 Exchange 计算机添加到开放邮件中继的“黑洞”列表中。如果您的 Exchange 计算机被添加到这样的列表中，其他邮件服务器就可能无法接收来自您所在域的邮件。
邮件中继问题的症状 如果遇到邮件中继问题，则可能会出现下列一个或多个症状： %26#8226; 收到包含错误代码 500、571 或 573 的未送达报告 (NDR)。 %26#8226; 无法将邮件发送到数量渐增的域中。 %26#8226; 未经请求的商业电子邮件出现在邮件队列中，并且您检测到 Exchange 计算机可发送未经请求的商业电子邮件。 %26#8226; 远程域会通知您，它收到来自您的 Exchange 计算机的未经请求的商业电子邮件。 %26#8226; 应用程序日志中记录了下列一个或多个事件：
类型: 警告 来源: MSExchangeTransport 类别: SMTP 协议 事件 ID: 1709 计算机: Computer_Name 描述: SMTP 客户端在试图发送邮件之前未进行身份验证。拒绝访问。数据: 0000: 05 00 07 80
类型: 警告 来源: MSExchangeTransport 类别: SMTP 协议 事件 ID: 1710 计算机: Computer_Name 描述: 已作为用户“NT AUTHORITY/ANONYMOUS LOGON”通过身份验证的 SMTP 客户端试图代理“Userone @ domainedu”进行发送。拒绝访问，原因是已通过身份验证的客户端不具有以此 SMTP 地址进行“代理发送”的权限。数据: 0000: 05 00 07 80
类型: 错误 来源: MSExchangeTransport 类别: SMTP 协议 事件 ID: 7004 日期: Date 时间: Time 用户: N/A 计算机: Computer_Name 描述: 事件 ID (7004)的描述(在资源(MSExchangeTransport)中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索此描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分: 1, 1, from, helo, 571 from IP Address We do not relay from you,HELO Domain_Namecom 您将找到滞留在远程传递队列中的发往远程域的邮件，事件日志不会为您提供有关远程域名的任何详细信息。如果您远程登录到端口 25 上的远程域，将发现连接会立即断开，且上面的事件日志项中会显示相同的错误消息：571 from IP Address We do not relay from you
日期: Date 来源: MSExchangeTransport 时间: Time 类别: (3) 类型: 警告 事件 ID: 4001 用户: N/A 计算机: Computer_Name 描述: 无法将邮件传递到远程域“MailExampleCom”。错误消息为“出现 SMTP 协议错误”。, MAIL, 553 530 Mail from ip address refused, see >微软Exchange 2000的备份与恢复
我们应该理解，备份和恢复程序可以允许管理员有效的进行当出现损耗或者灾难的时候所要进行的意外的计划。本文将描述在 Microsoft® Exchange® 系统中基础性的交互作用和描述使用VERITAS NetBackupTM for Exchange来简化日常备份，恢复重要数据，使损失最小化的作用。
--------------------------------------------------------------------------------
任何一个计算环境都需要在损耗或灾难发生后恢复数据或整个系统的能力。有规律的备份将为成功的恢复作出显著的贡献。Microsoft® Exchange® 2000的备份和恢复程序提供的机制可以使用户在Exchange的环境下保持系统的持续及最小化的中断。 VERITAS NetBackupTM for Exchange是用于备份和恢复Exchange 2000的数据库和邮件箱的。
了解微软Exchange 2000 环境
我们应该理解Microsoft Exchange 2000和Microsoft Windows® 2000 Active Directory® 之间的交互作用可以使的Exchange 2000环境下的维护和恢复变得非常容易。同样的，我们应该理解数据库文件，处理记录和补丁还有检查文件的作用是帮助管理员们从失败或从特定的时间点来恢复数据。
Active Directory 和Exchange 2000 服务器
在活动目录里，域或者森林结构作为一个整体拥有所有的对象。如果一个单独的域控制器被删除了，该目录下不会有任何目标丢失（除非该服务器是现存的该域的最后一个域控制器）。 活动目录对象是作为剩余的域控制器的拷贝而存在；一个域里的每一个域控制器都是所有其他的完整的备份。
Exchange 2000 需要连接到储存在Windows 2000 活动目录里的对象。因此，经常对活动目录进行备份和额外的域控制器对于Exchange 2000环境的生存是至关重要的。有时候管理员需用调用一些旧的信息，比如他们不小心删除了一个重要的目录或者是安装了一个没用的程序。在这种情况下，活动目录的早期备份可以帮助恢复这些信息。活动目录提供了权威的修复能力。
即使是最小的Windows 2000环境也应该有至少两个域控制器来提供两个活动目录数据库的备份。更大的机构里在每个域下应该有不少于三个域控制器来提供冗余。
正确的执行备份后将把每一个域的活动目录拷贝到一个安全的位置。在对活动目录有明显的改动之前或者之后至少对每一个域进行一次备份，例如安装Exchange 2000。
如果有多于一个的活动目录的备份，那么在灾难恢复工作中将会大大获益。目录之一的损坏并不会中断对客户的服务；因此，恢复过程就不是一个紧急的过程。管理员还可以获得一些恢复的选项。他们可以从一个备份中恢复，重建该服务器并把该服务器再次作为域控制器加入到域中，或者增加一个第三方服务器作为域控制器的替代。
Exchange 2000 数据库文件
微软Exchange 2000 兼容多达20种数据库存储，每两个数据库文件的组合又一种edb后缀的文件来验证。
在一般的工作中，数据库文件本身永远不是最新的。存储服务将管理一个巨大的内存里的缓存空间来储存数据同时周期性的把修改的数据记录到磁盘上。可是，这种方法导致了正常激活的数据库文件与更新磁盘上的数据库文件之间的延迟。如果一个突然的系统错误发生那么这个延迟将危及数据库的完整性。
把数据存储到处理记录文件将确保修改的数据记录到磁盘上。这一技术比更新数据库要快（这将导致更新多个索引，随机磁盘读取和其他问题）同时允许Exchange在高负荷下保持传输的高性能。
当存储服务正常停止的时候，它将把所有数据库缓存中被修改的数据存储到数据库文件中，在服务中止以前使得文件处以一个一致的状态。如果存储服务非正常停止了（崩溃），数据库将保持在一个不一直或者未知的状态，但是处理记录将包括所有恢复数据库所需要的信息。对数据库重放这些记录将使它回到一个一致的状态- 就好象正常关机后所达到的情况。
Exchange 2000 流数据库
流数据库是Exchange2000的新功能。在Exchange55下，每一个来自Internet的信息都被转化到Messaging Application Programming Interface （MAPI）格式，这要求将Multipurpose Internet Mail Extensions （MIME）内容转换成一种Exchange 数据库可以索引，管理和识别的格式。Exchange2000将收到的Internet信息存储在流数据库里。这种文件有一个stm的后缀，同时是edb 数据库文件的一个合作文件。
这种stm文件包括原始内容；它并不包括索引和属性。当一个信息到达的时候，Exchange2000只是将信息索引和管理到edb文件中。 Exchange2000 接下来将记录该stm文件的位置，使用户可以到那里去阅读该信息。这种方法将使Internet信息更快的传输，同时减少信息格式的转换。edb和stm 文件是组成一套的并且应该被作为一个单独的文件来对待。如果一个管理员在备份edb文件时丢失了stm文件，那么该edb文件就是没用的了。
Exchange 2000 处理记录
微软Exchange数据库使用处理记录来接受，跟踪和维护数据。所有处理工作都首先被写入处理记录和内存，然后最后记录到数据库。处理记录可以在数据库失败或损坏后帮助恢复信息存储数据库。
信息存储包括两个分开的数据库，但是处理记录是被保存在一个单独的组里。因为所有处理首先被写入edblog文件然后再写入数据库，实际的数据库可以是一个在处理记录文件里没有被提交的处理和实际的edb数据库文件的混合体。当edblog文件被数据充满的时候（大约在5MB），它将被改名然后一个新的edblog文件被建立。当edblog文件被改名，被改名的记录文件被保存在相同的子目录下。被改名的记录文件使用一个连续的数字顺序来命名（例如： edb00014log， edb00015log，然后使用十六进制继续下去）
当服务正常的中止时记录在记录文件里的处理将被提交到各自的edb文件。记录文件不能被人工的清除；最好通过备份 *** 作来清空记录文件。
与相应的Exchange在线备份磁盘相结合，记录文件可以让管理员能够掌握当天的处理同时可以不丢失任何信息的恢复一个数据库。
处理记录没有长期的价值；只有当它们是在最近一次在线备份时创建的才是有用的。单独把处理记录文件备份或者恢复，而不考虑用它们相关联的数据库，那样是毫无意义的。
在备份中的处理记录： 在备份的过程中提交了的处理记录将被微软Exchange删除。既然这些记录已经被提交到数据库文件同时他们已经被写入到备份媒介中，那么这些记录就不在需要了。如果处理记录文件变的损坏了，管理员在数据库恢复后将失去将之前移的能力。
在恢复中的处理记录： 在恢复Exchange2000 数据库时管理员有两个选择。
首先，他们可以保存现有的记录文件同时覆盖任何存在的记录文件。在文件被恢复，服务启动以后，数据库将把处理提交到恢复的记录中。如果在服务器上存在与恢复的记录文件编号相邻的记录文件，那么那些处理也将被提交。如果记录文件的文件名的编号顺序有间隔出现，那么间隔之前的记录文件没有任何处理会被提交。
处理记录完好无损而数据库需要恢复的情况是非常有用的。通过保存的记录文件，微软Exchange服务器可以恢复到错误发生的点而不是上一次全部或增量备份的时候（微分增量备份或累计增量备份）
第二个选择是删除现存的处理记录。在很多情况下，例如恢复信息存储到另一个服务器，或者是恢复到早先的日期而不重新提交所有仍然在磁盘上的记录，或者是执行一次全面恢复，需要删除现存的处理记录。
Exchange 2000 数据库补丁文件
数据库补丁文件可以在备份的过程中 *** 作处理写入到数据库。如果一个处理导致了edb文件部分更新，但该文件已经被备份了，这时候它将被写入到该数据库的补丁文件中。只有在备份的过程中补丁文件才会存在。在微软Exchange服务器进行恢复的过程中，补丁文件将把在备份过程中的处理更新到恢复的数据库文件中去。
检查文件
检查文件可以恢复，或者运行从处理记录到edb文件的数据。检查点是记录在edbchk文件中用来指明那些记录被提交了。不管是什么时候数据从记录文件写入到edb文件，该edbchk文件将更新一个信息来说明该处理已经被成功的提交到了相关的edb文件。在恢复的过程中，Exchange将通过读取 edbch文件或者直接读取处理记录文件（在这种情况下不需要edbchk文件）判断哪些处理还没有被提交。
信息存储和目录服务使用各自的edbchk文件，它们在启动的时候读取该文件。他们可以使用处理记录来运行任何没有被提交到edb文件的记录。举例来说，如果一个Exchange服务器发生了损耗，而处理被记录到了处理记录而不是数据库文件，Exchange将尝试在启动的时候通过自动记录从记录文件到数据库文件的处理来进行恢复。
备份Exchange2000
管理员可以备份Exchange服务器上的所有数据库，或者一个指定的数据库组，或者存储集团。管理员同样可以选择恢复一个Exchange服务器上的所有信息或者恢复一个单独的数据库或者存储集团。
尽管管理员可以个别的备份所有的数据库，但是建议一次备份全部的存储集团。个别的数据库备份需要多个备份记录文件，同时当备份或者恢复Exchange2000数据库时，管理员不能在一个单独的存储集团里运行多个备份或者恢复 *** 作。
以下步骤将在一次全面备份中发生：
将数据库文件写入备份媒介。
在备份过程中创建补丁文件来更新数据库。
将处理记录写入备份媒介。
将补丁文件写入备份媒介。
删除已提交的处理记录。
图1描述了一次Exchange2000数据库备份的过程。
图1、 Exchange 2000 数据库备份流程
备份类型
VERITAS NetBackup可以实现全面的，拷贝，增量的，和微分的备份。数据的重要性决定了备份的类型。在数据存储，性能和所需时间上每一种备份类型都具有优点和缺点。两种常见的方式是在线和离线。
在线备份： 在线备份允许数据库在数据备份的过程中继续运行。一次在线备份不会影响用户或中断 *** 作。一次在线备份可以是部分的也可以是全部的。全面备份将拷贝数据库中的所有东西，而部分备份只拷贝记录文件。
一次在线的全面的备份是备份的首选类型。一次全面的备份将拷贝Exchange的数据库文件和Exchange的记录文件。它将删除包含已经提交到服务器数据库的处理的处理记录文件。从全面备份来进行恢复一般只涉及到一种备份类型。
离线备份： 一次离线备份让管理员可以保存一份数据库的拷贝而不拷贝记录文件。一次离线备份通常是第二位的选择。管理员必须在执行备份前停止数据库，在这一过程中用户将不能收发邮件。
Exchange 2000配置文件的备份
除了备份Exchange数据库，管理员还应该备份所有的关键性数据例如用户信箱的内容和运行Exchange服务器所必需的配置数据。管理员还应该经常性的备份Exchange2000的配置数据，包括下列：
Web存储系统数据库和支持文件
活动目录
系统状态，包括微软Internet信息服务（IIS）数据库，其中包含Exchange2000所要使用的协议的信息。
备份的验证和确认
恢复数据和服务器的能力取决于备份的质量；因此，确认备份程序的成功是非常重要的。对于完全的错误承受，根据情况和数据的级别来确认一次备份程序。
恢复Exchange2000
不同的灾难都可以折磨Exchange环境。例如管理员也许需要恢复一个被删除或损坏的信箱，或者他们需要恢复一个或更多的数据库或是存储集团。如果一个严重的灾难发生了，管理员也许需要使用/disasterrecovery开关来恢复整个Exchange服务器。这个程序包括确认活动目录仍然完好，恢复Exchange2000系统状态和恢复所有Exchange数据库。
管理员可以使用VERITAS NetBackup从备份中来恢复被损坏的数据库，存储集团，或者整个Exchange服务器。
Exchange 2000 数据库的恢复
一次恢复加上处理前移是在一次中断后恢复Exchange2000数据库的最简单和某些情况下唯一的方法。图2描述了恢复一个Exchange2000数据库的过程。
图 2 Exchange 2000 数据库恢复流程
管理员不应该同时恢复微软Exchange Mailbox和微软Exchange服务器。如果一个管理员停止了Exchange服务来恢复Exchange服务器的数据库，那么信箱对象的恢复将会失败。或者，如果恢复Exchange信箱在恢复Exchange数据库开始之前完成了，那么恢复数据库将清除被恢复的信箱对象。
在一个单独的存储集团里多个数据库的恢复
管理员同时只可以运行一次的备份或者恢复程序在一个特定的存储集团上。多个同时发生的备份和恢复程序必须运行在多个存储集团。因此：
在一个给定的存储集团内管理员一次只能恢复一个备份的数据库。
管理员可以同时恢复和备份多个存储集团。
当在同一个存储集团里恢复多个数据库时，在进行下一个数据库的恢复前首先应该设置好刚刚恢复的数据库。举例来说，数据库A，B，C是在同一个存储集团里并且被一起备份。要恢复数据库A，只需要设置恢复数据库A。如果一个管理员决定恢复数据库B，数据库A必须首先被恢复并设置好。一旦数据库A被设置好，管理员可以开始恢复数据库B。要同时恢复两个数据库，管理员必须首先标志数据库A和数据库B用于恢复。
恢复的过程将创建一个Restoreenv文件在临时目录里，而当数据库成功的设置好以后该文件将被删除。如果管理员选择恢复数据库A和B，这个 Restoreenv文件将包含两个数据库的信息。但是，当管理员个别的恢复数据库时，对应数据库A的Restoreenv文件必须在数据库B恢复程序开始以前完成处理。
全服务器恢复
一个全服务器恢复涉及到恢复Exchange2000服务器或Windows 2000服务器或者两者都涉及。在Exchange2000下的多个存储集团和数据库将使恢复过程变得复杂。
当进行一个全服务器恢复时，管理员首先必须在恢复Exchange数据以前，在灾难恢复模式下重新安装微软Exchange2000服务器。灾难恢复模式将从活动目录里提取信息来正确的重新安装Exchange。
管理员应该知道恢复不同类型的服务器所需要的程序。Exchange2000服务器可以指定一些特定的任务，例如运行关键管理服务器（KMS）或是站点复制服务（SRS）。这些服务可以在Exchange服务器启动并运行后重建。
需要注意的是，Exchange服务器运行在不同的模式下也许需要一些额外的恢复步骤。举例来说，恢复一个Exchange2000集群服务器需要比恢复一个单独的Exchange2000成员服务器要多几个步骤。
使用NetBackup for Exchange
VERITAS NetBackup利用微软Exchange API 来在线执行对微软Exchange信息存储和目录以及所有相关的处理记录文件的备份工作。NetBackup支持先进的Exchange前进或回溯 *** 作，因此管理员可以恢复Exchange数据库到任何时间，这是对于大范围的Exchange环境的一个关键性的要求。
要使用NetBackup for 微软Exchange服务器，管理员必须添加至少一个微软Exchange服务器级到NetBackup来定义对于该级的合适的时间安排。管理员同时必须设置NetBackup来执行对于个别的信箱和目录的备份和恢复任务。
微软Exchange服务器级的大部分要求和文件系统备份的要求一样。关于设置指令的细节请参考NetBackup 34系统管理员指南 for Windows NT/2000。
NetBackup for Exchange 的功能
以下部分将介绍NetBackup for Exchange的一些功能。
在线备份。 管理员不需要在备份微软Exchange服务器数据和处理记录时让服务器离线。这一能力确保了在微软Exchange服务器进行备份时微软Exchange服务和数据的可用性。
缩短的备份时间。管理员可以执行一次全面的或是增量的备份（微分增量备份或是累计增量备份）。一次全面备份需要相当长的时间，所以管理员很少进行它。作为过渡，自从上次全面备份后的更新可以被很快的备份起来，而增量备份可以只备份处理记录。当失败发生时，全面的和增量的备份将被恢复。
在恢复过程中，微软Exchange服务器可以更新数据库，提交被记录的处理到数据库。在微软Exchange服务器完成恢复后，系统将把状态调回到最后一次增量备份执行时的情况。
微软Exchange服务器备份支持。 NetBackup支持所有的微软Exchange服务器备份方法：全面备份，累计增量备份，微分增量备份，和拷贝。
中央管理。 管理员可以在一个中央的位置上定义，备份，和恢复微软Exchange服务器或其他的NetBackup客户机。
媒介管理。 NetBackup主服务器支持微软Exchange服务器备份所直接存储到那些很广泛的多种多样的存储设备上。
自动备份。管理员可以通过网络确定对本地或远端的客户机自动的，无人的备份的时间表。这些备份可以是全面的也可以是增量的并且完全是被NetBackup服务器在中央位置进行管理的。管理员也可以手动备份客户机。要确保备份的一致和准确，要在备份数据库前经常检查数据库的一致性。
恢复任务。 只需要几个简单的 *** 作，管理员就可以使用NetBackup客户端来浏览微软Exchange服务器的备份并选择恢复哪些。
个别的信箱备份和恢复。 管理员可以在个别的信箱和目录上执行备份和恢复 *** 作。这一功能包括下列能力：
对个别信箱和目录的定时备份。
对个别信箱和目录的用户直接备份。
基于服务器或客户端的个别信箱，目录或信息的恢复。
恢复不同的信箱和目录。
不同的客户端恢复个别的信箱，目录或信息。
备份的软件压缩。
备份的多个数据流。
The Exchange Messaging API （MAPI）允许VERITAS NetBackup for Exchange执行对Exchange信箱的"砖块级"备份。这个能力使得恢复个别信箱，目录，或电子邮件信息非常容易。管理员不再需要依靠一个备用的服务器来恢复个别的Exchange信息。
简单的数据保护
我们必须理解，备份和恢复过程和系统的其他元素是交互作用的，来允许管理员执行高效的针对损耗或灾难的意外计划。在产品环境里执行任何备份解决方案之前，要在测试实验室环境下测试所有提议的备份解决方案来配合现存的产品环境。
VERITAS NetBackup for Exchange这样的工具将使日常备份变的简单，帮助公司们恢复重要数据，使Exchange环境的中断可能最小化。VERITAS提供自由的选择和简单化的管理，提供可以确保在多个应用程序，服务器，存储器或是网络之间传输的数据的连续的可用性。
VERITAS 软件有限公司 是一家数据可用性软件解决方案的领先的提供商，它可以使客户保护和访问他们的关键性商务数据

一般情况下直接填用户的Exchange用户名和密码就可以。Exchange server 的AutoDiscover服务会自动帮用户找到服务器地址，并匹配用户的用户信息。
如果不行，就需要手动配置了，配置信息可以在网页登录OWA，设置里面寻找。
Exchange Server 是微软公司的一套电子邮件服务组件，是个消息与协作系统。 简单而言，Exchange server可以被用来构架应用于企业、学校的邮件系统。Exchange是收费邮箱，但是国内微软并不直接出售Exchange邮箱，而是将Exchange、Lync、Sharepoint三款产品包装成Office365出售。Exchange server还是一个协作平台。在此基础上可以开发工作流，知识管理系统，Web系统或者是其他消息系统。

---