IT博客-leon19821015-文章分类-Exchange

简化 Outlook Web Access URL

Leon19821015 — Wed, 20 Sep 2006 09:09:00 GMT

1. 使用 Internet 服务管理器，打开"默认网站 "的属性。
　　
2. 单击"主目录"选项卡，然后选择"重定向到 URL"。
　　
3. 在"重定向到"中，键入 /目录名，然后单击"输入的 URL 下的目录"。
　　
例如，如果要将 http://mail/ 请求重定向到 http://mail/exchange，应在"重定向到"中键入 /exchange。
　　
4. 若要求用户使用 SSL，请在"重定向到"中，键入 https://mail/目录名，然后单击"上面输入的准确 URL"选项。
　　
此设置对服务器的名称进行硬编码。因此，如果将客户端请求重定向到 https://mail，客户端必须能够解析"mail"这一名称。
　　
有关将客户端重定向到 SSL 的另一方法的信息，请参阅 Microsoft 知识库文章 279681："How to Force SSL Encryption for an Outlook Web Access 2000 Client"(http://support.microsoft.com/?kbid=279681)（英文）。

Leon19821015 2006-09-20 17:09 发表评论

在exchange2000中的那一套在OWA里面加入“密码修改”一项在exchange2003里面不适用。

Leon19821015 — Wed, 20 Sep 2006 08:39:00 GMT

1. 首先，你要确认服务器端已经安装了证书服务组件，没有的话，安装企业根证书。接着安装IIS的SSL安全功能
打开IIS管理器，选择默认WEB站点-->属性-->目录安全性-->安全通信-->服务器证书，创建一个新证书，然后选'立即发送请求到一个在线证书颁发机构'，下面根据提示操作，需要注意的是：站点的功能名称一定要用你的ExChange服务器对外网站的域名。

2. 添加密码管理虚拟目录
给IIS添加一个虚拟目录名称为IISADMPWD（名称不能修改），目录路径指定为 Windows安装目录下面的system32inetsrviisadmpwd 目录即可。一定不能有任何错误。

3. 通过regedit.exe设置修改密码的显示和隐藏

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeWEB项中
值名: DisablePassword
值类型: REG_DWORD
默认值是1，修改为0就行
说明：1代表隐藏OWA里的'更改密码'按钮、0代表显示OWA里的'更改密码'按钮

4. 设置用户验证方式
打开IIS，选择默认站点-->Exchange-->右键-->属性-->目录安全性-->匿名访问和验证控制-->编辑-->选择基本验证和集成windows验证，填写你的基本验证域，就是服务器AD域名称。
打开IIS，打开Exchange虚拟目录的属性，打开“目录安全性“，点击最下面的一个“编辑”按钮，在跳出的对话框中选中'需要安全通道'复选框。

5. 通过这样的设置后，已经可以在用户前端界面的选项中看到'修改密码'按钮了，但是你试着更改密码，会提示你“密码太短，或不满足密码唯一性限制”的错误信息（这个错误信息有些误导，有时候并不是该原因出错，注意密码最短使用期限的设置），仍然无法正常修改密码。这是由于域安全策略的问题，可以通过修改域安全策略来实现。
如果以上修改未能生效，请重新启动下IIS admin service 和 Microsoft Exchange Information Store Service 即可。

Leon19821015 2006-09-20 16:39 发表评论

全备份不能删除事务日志

Leon19821015 — Tue, 12 Sep 2006 08:20:00 GMT

原因应该是Check文件损坏，通过重建可以解决
1.停止Exchange服务
2.把.chk移到其他地方
3.启动Exchange服务
http://support.microsoft.com/kb/184578/en-us

Leon19821015 2006-09-12 16:20 发表评论

改变OWA语言

Leon19821015 — Tue, 12 Sep 2006 03:02:00 GMT

http://support.microsoft.com/kb/263668/en-us

Leon19821015 2006-09-12 11:02 发表评论

2个SMTP虚拟服务器环境下添加免责声明

Leon19821015 — Wed, 06 Sep 2006 09:17:00 GMT

环境:1台Exchange有2个SMTP虚拟服务器，一个监听25端口，外连26端口；一个监听26端口，外连25端口
需求:第一个服务器对香港；深圳，没有免责申明，第二个服务器对外，要有免责申明。
操作:1.把下面这段存为***.vbs

      2.安装Exchange SDK，在命令行导航到C:\Program files\Exchange SDK\SDK\Support\CDO\Scripts
      3.输入命令:cscript smtpreg.vbs /add 1(说明:1为第一个) onarrival SMTPScriptingHost CDO.SS_SMTPOnArrivalSink "mail from=*@your-domain-here.com"
                          cscript smtpreg.vbs /setprop 1(同上) onarrival SMTPScriptingHost Sink ScriptName "C:\***.vbs"
     如要取消:cscript smtpreg.vbs /remove 1(同上) OnArrival SMTPScriptingHost

Leon19821015 2006-09-06 17:17 发表评论

Exchange Server 灾难恢复准备

Leon19821015 — Mon, 28 Aug 2006 05:40:00 GMT

环境:Name:wtszmail IP:10.10.11.204 Role:5种FSMO,GC,Exchange,FAX,Symantec for Exchange
UpDate:补丁存放在本机D:\华高\Exchange Server UpDate
有一台BDC:Name:wtszhr IP:10.10.11.205 Role:GC
1.情景:服务器Down机，需重装系统
1.重装Windows Server2000系统的同时,在wtszhr上夺取5种FSMO角色(ntdsutil)并且删除原服务器的数据
2.安装完系统后打上所有补丁,使用/disasterrecovery安装Exchange
3.KB313184

Leon19821015 2006-08-28 13:40 发表评论

Exchange服务器系统盘空间不足的原因

Leon19821015 — Wed, 23 Aug 2006 08:00:00 GMT

原因:Exchange安装在系统盘，启用了Message Tracking,每天都有Log，目前情况是1个月1G左右，而且Exchange2000又不能改变这个日志的存放地点
解决方法:定期备份日志，存放到其他地方

Leon19821015 2006-08-23 16:00 发表评论

Exchange 2003 使用队列查看器的秘籍

Leon19821015 — Tue, 22 Aug 2006 01:38:00 GMT

    单击“队列查看器”窗口底部的“设置”按钮，选择屏幕自动更新时间间隔。也可以手动更新队列查看器屏幕。要刷新队列查看器屏幕，请单击左窗格中的“队列”，然后按F5键。在每个队列的“操作”菜单上，有以下两个选项：“冻结邮件”-停止传递队列中的所有邮件；“取消邮件冻结”-恢复传递队列中的邮件。还可以强制处于重试状态的队列立即进行重试。可以更新查看每个队列，并按照下面的步骤对进行排队的邮件执行操作。 1. 单击包含要控制的邮件的队列。 2. 右键单击该队列，然后单击“查找邮件”。可以删除邮件并选择生成或不生成传递状态通知 (DSN) 消息。可以停止传递每个邮件，或者释放邮件以进行再次传递。
    以下是可在 Exchange Server 2003 中使用的队列列表。该列表包含常见问题说明及相关疑难解答信息。
    队列：待提交邮件
    首先提供于：Exchange 2000 Service Pack 2
    说明：本队列保存已被 SMTP 服务确认和接受的邮件。此队列中的邮件尚待处理。
    疑难解答：如果邮件经常堆积，说明可能存在性能问题。CPU 性能中偶尔出现的峰值会导致邮件间歇性地出现在队列中。通常，事件接收器存在的问题（例如，用于防病毒屏蔽和免责声明的自定义 SMTP 处理代码）会导致邮件堆积在此队列中。

    队列：等待目录查找的邮件
    首先提供于：Exchange 2000
    说明：此队列所包含邮件的收件人尚未得到Microsoft Active Directory目录服务的解析。在展开通讯组列表的同时，邮件仍保存在此队列中。
    疑难解答：由于高级队列引擎无法对邮件加以分类而导致邮件堆积在此队列中。高级队列引擎可能无法访问全局编录服务器或收件人信息。全局编录服务器也可能无法访问或性能缓慢。提高MSExchangeDSAccess 服务和MSExchangeTransport服务的诊断日志记录级别，以收集有关分类程序组件的信息。要提高组件的诊断日志记录级别，请查看本文“更多信息”一节开头列出的步骤。

    队列：等待路由的邮件
    首先提供于：Exchange 2000
    说明：此队列可保存邮件，直到确定了这些邮件的下一个目标服务器为止。这些邮件会被移动到它们各自的链接队列中。
    疑难解答：如果Exchange路由存在问题，邮件便会堆积在此队列中。例如，邮件路由可能被备份。请禁用所有不必要的连接器限制，因为这些限制会显著降低服务器性能。对于某些限制，可能必须打开CheckConnectorRestrictions注册表项。
有关该注册表项的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：277872 XCON：连接器传递限制可能无法正常工作

    队列：“本地传递”（可能会出现域名）
    首先提供于：Exchange 2000
    说明：此队列包含的邮件已在 Exchange Server 计算机上排队，以便本地传递到Exchange邮箱。
    疑难解答：如果信息存储不接受本地传递邮件，则邮件可能会堆积在此队列中。如果邮件传递不仅缓慢而且时有时无，则表明存在循环邮件或性能问题。提高“SMTP存储驱动程序”组件的MSExchangeIS服务和MSExchangeTransport服务的诊断日志记录级别。

    队列：“远程传递队列”（此队列包含带有域的目标服务器或连接器的名称）
    首先提供于：Exchange 2000
    说明：此队列包含准备进行远程传递的邮件。队列的名称与远程传递目标相匹配。
    疑难解答：如果队列处于重试状态，请单击队列以查看“其他队列信息”。此信息位于右窗格的底部。请使用 NSlookup 实用工具检查域名系统 (DNS) 解析可能存在的问题。对于连接和协议问题（如“不能访问主机”错误），请使用Telnet.exe尝试连接到目标计算机。要纠正协议错误，请提高“SMTP 协议”组件MSExchangeTransport服务的诊断日志记录级别，并检查日志以查找错误。此外，也可使用网络监视器工具获得有关网络连接错误的信息。要重现此问题，可能必须强制队列重试。
有关如何使用“Microsoft 网络监视器”的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
301989 如何在Windows中利用网络监视器捕获WAN通信
有关 NSLookup 实用工具的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
200525 使用 NSlookup.exe
有关如何使用Telnet解决连接问题的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
169790 如何诊断排除基本的 TCP/IP 问题

    队列：不能到达目的地的邮件
    首先提供于：Exchange 2000
    说明：队列中的邮件无法到达其最终的目标服务器。例如，Exchange 无法确定到最终目的地的路由或连接器，或者所有可用路由或连接器都被标记为停用。
    疑难解答：如果没有供邮件传递的路由，邮件便会堆积在此队列中。此外，如果Exchange连接器或远程传递队列不可用，或者它在一段时间内处于重试状态，并且不存在到连接器或远程目的地的可用备用路由，新邮件便会被移入此队列中。管理员可解决此问题，或定义一条备用路由。使用WinRoute工具有助于确定可用路由和路由状态。
有关WinRoute工具的其他信息，请查看Microsoft知识库中相应的文章：281382 如何使用 WinRoute 工具
要排除引起此问题的队列存在的故障，请重新启动SMTP虚拟服务器，重设连接器状态并重试进行排队的邮件。要重新启动 SMTP虚拟服务器，请按照下列步骤操作： 1. 单击“开始”，依次指向“程序”、“Microsoft Exchange”，然后单击“系统管理器”。2. 依次展开 “服务器”容器、您的 Exchange Server 计算机和“协议”，然后展开“SMTP”。3. 右键单击 SMTP 虚拟服务器，然后单击“停止”。4. 再次右键单击 SMTP 虚拟服务器，然后单击“启动”。

    队列：推迟传递的排队邮件
    首先提供于：Exchange Server 2003
    说明：此队列包含排队等候以便日后传递的邮件。其中包括在设置此选项时由较旧版本的Microsoft Outlook发送的邮件。较新版本的Outlook会在信息存储中对这些类型的邮件进行排队。这些邮件保留在此队列中，直至达到它们的计划传递时间。
    疑难解答：下列情况也可导致邮件堆积在此队列中： • 接收邮件的用户邮箱正在被移动。• 用户还没有邮箱，并且该用户的主帐户安全ID (SID) 也不存在。有关禁用的用户帐户的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：316047 XADM：解决在启用由ADC生成的帐户时出现的问题 • 管理员配置SMTP的方法不正确，导致邮件循环。SMTP 将这些邮件移入此队列。这使得管理员可以解决此问题，从而避免在邮件立即返回时出现“超出了最大跃点计数”错误。将邮件移动到此队列还有助于防止对服务器资源造成过多性能影响。

    队列：等待提交的 DSN 邮件
    首先提供于：Exchange Server 2003
    说明：此队列包含正在等待 Exchange 呈现的传递状态通知 (DSN)。传递状态通知又称为未送达报告 (NDR)。
    疑难解答：如果存在下列任一情况，邮件便会堆积在此队列中： • 信息存储服务不可用或者没有运行。 • 没有安装专用信息存储。• IMAIL Exchange 存储组件存在问题。IMAIL 是执行邮件转换的组件。请查看 Windows 应用程序事件日志，以确定 Microsoft Exchange Information Store 服务是否存在错误。

    队列：邮件重试失败
    首先提供于：Exchange Server 2003
    说明：无法进行队列提交的邮件将被移入此队列。通常，在完成其他处理过程后，邮件才能成功进行队列提交。默认情况下，队列中的邮件会在 60 分钟后被重新处理。邮件损坏或系统资源不足可导致邮件出现在此队列中。
    疑难解答：请检查所安装的第三方程序或可能影响邮件队列或邮件准确性的事件接收器。如果计算机响应缓慢，请使用 Windows 任务管理器确定进程是否使用了过多的系统资源。在确定引发此问题的根本原因之前，重新启动 Internet Information Server 服务可以暂时缓解此问题。要重新启动 Internet Information Server 服务，请按照下列步骤操作： 1. 单击“开始”，然后单击“控制面板”。2. 双击“管理工具”。3. 双击“服务”。4. 右键单击“Internet Information Server”，然后单击“重新启动”。

    队列：“SMTP 邮箱存储”(X.400)
    首先提供于：Exchange 2000
    说明：此队列包含由 SMTP 组件进行处理的邮件。邮件传输代理 (MTA) 接收和处理的邮件也必须由 SMTP 组件处理，即便邮件的目的地是由 MTA 提供服务的远程位置。为了将邮件提交给 SMTP，MTA 将邮件放在信息存储内部的 SMTP 邮箱中。
    疑难解答：确保至少安装了一个邮箱存储，并且已启动了 Microsoft Exchange Information Store 服务。要纠正协议错误，请提高 MSExchangeMTA 组件的诊断日志记录的级别。要提高组件的诊断日志记录级别，请查看本文“更多信息”一节开头列出的步骤。

    队列：“PendingRerouteQ”(X.400)
    首先提供于：Exchange 2000
    说明：此队列包含在出现临时链接故障之后正在等待重新路由的邮件。
    疑难解答：如果没有到连接器、到其他邮件系统或到某台 Exchange 5.5 计算机的可用路由，邮件便会堆积在此队列中。
有关如何查看 Microsoft Exchange Server 2000 中队列的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：259762 XCON：如何在 Exchange 2000 中使用队列查看器

Leon19821015 2006-08-22 09:38 发表评论

Exchange 2000中共享SMTP地址空间

Leon19821015 — Mon, 21 Aug 2006 09:10:00 GMT

    假设Exchange2000从Internet接受传入的邮件，在Exchange组织中查找匹配的收件人，然后将邮件转发给外部邮件系统。接收系统也可能执行同样操作：它可以查找匹配的收件人，然后将邮件转发给第三个电子邮件系统。请一定记住：此链中的最后一个系统必须对该域具有管理权。也就是说，最后一个接收系统必须查找匹配的收件人，如果找不到，则必须为该邮件生成未送达报告 (NDR)。如果接收系统查找匹配的收件人，并且在找不到时将邮件转发回最初的系统，则会出现循环邮件。如果 Exchange2000是链中的最后一个系统，则不要使用下列过程配置Exchange2000。最后一个接收系统必须为任何未解析的地址返回NDR，而这是Exchange2000的默认操作。如果Exchange2000是链中的最后一个系统，最好在Active Directory中为所有外部系统收件人创建联系人，以确保他们的目标SMTP地址类似于 @SMTPAddressSpace.domain.com，其中 SMTPAddressSpace提供附加地址信息，以区分地址空间与典型的“@domain.com”名称空间。例如： @external.domain.com-或者-@sendmail.domain.com ，有两种方法可以配置 Exchange 2000 以共享 SMTP 地址空间。第一种方法是只共享所选的 SMTP 地址空间，而 Exchange 2000 保留对其他地址空间的管理权。该方法有更大的灵活性，因此是首选方法。同时，如果在 Active Directory 中创建联系人以便将邮件发送给外部收件人，并且如果此类外部收件人的目标SMTP地址与Exchange2000的收件人策略中配置的 SMTP 域的地址匹配，则必须使用这一方法。也就是说，如果在一个收件人策略中有地址@companyname.com，并且想要用目标地址user@companyname.com创建联系人，则必须使用本文稍后介绍的选择性共享方法（方法1）共享 @companyname.com 域名。第二种方法是共享所有地址空间。该方法的灵活性较差，但是配置较简单，可以应用在小型环境中。如果存在外部收件人的相应联系人，则不能使用该方法。有关在共享的SMTP 域中使用联系人的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 319759 XADM:How to Configure Exchange 2000 Server to Forward Messages to a Foreign Messaging System That Shares the Same SMTP Domain Name Space

方法1：共享所选的 SMTP 地址空间
    首先需要了解Exchange2000处理电子邮件的方式是不同的，这取决于 Exchange 2000 对特定 SMTP 地址空间是否具有管理权。要查看此设置，请执行以下操作：
    1. 打开收件人策略的属性，单击电子邮件地址选项卡，单击SMTP地址，然后单击编辑。
    2. 检查“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框的设置。如果该复选框被选中，则Exchange2000 拥有SMTP域的管理权。如果该复选框未选中，则Exchange2000没有管理权。有关Exchange2000中有管理权和无管理权的 SMTP域的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
315591 XCON:Authoritative and Non-Authoritative Domains in Exchange 2000 Exchange 2000
必须始终有默认收件人策略中主SMTP地址（以粗体表示）的管理权。否则，本地邮件可能无法流动。当您共享所选的 SMTP 地址空间时，共享的地址空间在 Exchange 2000 中被设置为无管理权。如果您要共享的地址空间不是默认收件人策略中的主地址，请单击以清除该域的“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框。如果要共享默认收件人策略中的主 SMTP 地址，请将另一个地址设置为默认收件人策略中的主地址。您可能要添加一个 Exchange 2000 专为此目的而将拥有其管理权的新 SMTP 地址。该地址可能类似于“@localhost”或“@exchange.domain.com”，以便其目的是纯粹用于 Exchange 组织中的邮件流动。要添加这样的一个策略，请使用下面的过程。请注意，仅在要共享的地址空间当前被设置为默认收件人策略中的主 SMTP 地址时，才必须添加这样的策略。否则，只需要为有问题的域清除“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框。
    1.单击默认收件人策略属性上的电子邮件地址选项卡。
    2. 单击新建，单击 SMTP，然后单击确定。
    3. 在地址框中，键入 @localhost 或 Exchange 组织可以对其有管理权的某些其他地址空间。常见的选择有：@localhost、@owa.domain.com 或 @exchange.domain.com，其中 domain.com 是您的 Internet 域。如果 Active Directory 域名与您的 Internet 域名不同，也可以使用 Active Directory 域名。
    4. 确保选中“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框。必须对所有用户标记该域，以便他们可以登录默认 Microsoft Outlook Web Access (OWA) 虚拟服务器。
    5. 单击确定。
    6. 单击新 SMTP 地址，然后单击“设为主地址”。既然您有 Exchange 2000 拥有其管理权的另一个主 SMTP 地址，则可以共享另一个地址空间。要共享不是默认收件人策略中主 SMTP 地址的地址，则请执行以下操作：
    1. 打开收件人策略的属性，然后单击电子邮件地址选项卡。
    2. 单击要共享的 SMTP 地址空间，然后单击编辑。
    3. 通过单击以清除“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框，取消 Exchange 2000 对该 SMTP 地址的管理权。
    4. 单击确定两次。此时，您可能要创建优先级更高的收件人策略，以确保用户获得正确的主（回复）地址。为此，请按照下列步骤执行操作：
    5. 为“电子邮件地址”创建新的收件人策略，将其命名为类似于“用户地址”的名称。
    6. 在筛选选项卡上，单击修改，并设置筛选器以便将策略应用到所有适用的用户。如果此策略必须应用到所有用户，则请单击查找 Exchange 收件人屏幕上的确定。
    7. 在电子邮件地址(策略) 选项卡上，将共享的域设为主代理，将 @local 域保留为辅助代理。
    8. 单击确定。由于 Exchange 2000 现在没有该域的管理权，当 Exchange 2000 在 Active Directory 中找不到匹配的地址时，它会尝试查找该名称空间的外部路径，方法是：首先寻找连接器，然后检查域名服务器 (DNS)。除非该域的 MX 记录已经指向 Exchange 2000 的假定发送目标服务器（在很多情况下，MX 记录指向 Exchange 2000 服务器本身），否则请创建一个 SMTP 连接器，以将邮件路由到特定主机。为此，请按照下列步骤执行操作：
    9. 在 Exchange 系统管理器中，右键单击连接器容器，单击新建，然后单击 SMTP 连接器。
    10. 键入适当的名称，然后单击“将通过此连接器的所有邮件转发到下列智能主机”选项。在方括号 ([]) 中，键入要将共享 SMTP 地址空间的电子邮件路由到的服务器的合格域名 (FQDN) 或 IP 地址。
    11. 单击添加，然后选择桥头。
    12.单击地址空间选项卡，单击添加，单击 SMTP，然后单击确定。
    13. 在“电子邮件域”框中，键入不含 @ 符号的 SMTP 地址空间。例如: nwtraders.com     14. 因为 Exchange 2000 还必须为该域接收邮件，所以请单击以选中“允许将邮件中继到这些域”复选框。此设置允许桥头选项卡上列出的所有 SMTP 虚拟服务器为该域接收邮件。
    15. 单击确定。完成这些设置后，当 Exchange 2000 在该 SMTP 域中找不到本地地址匹配项时，Exchange 2000 会将邮件转发给在拥有匹配地址空间的 SMTP 连接器中指定的主机

方法 2：共享所有地址空间
    该配置比较简单，但灵活性较差。在该配置中，Exchange 2000 对所有地址空间拥有管理权。您的目录中的任何联系人都不能有满足以下条件的目标地址：该地址与 Exchange 2000 对其有管理权的域相匹配。要应用该方法，请执行以下操作：
    1.打开默认 SMTP 虚拟服务器的属性。
    2.单击邮件选项卡。
    3. 在“Forward all messages with unresolved recipients to host”（将所有带有未解析收件人的邮件转发给主机）框中，在方括号 ([]) 中键入将要接收未解析邮件的服务器的 FQDN 或 IP 地址。
    4. 单击确定。
    5. 在所有 Exchange 2000 服务器上为该默认 SMTP 虚拟服务器重复该过程，任何充当其他系统的入站网关的虚拟服务器除外。建议该服务器上不要有任何邮箱。同时请注意，该设置只影响有管理权的域。因此，对于任何有管理权的域，发送给未解析地址的邮件都被转发到在 SMTP 虚拟服务器上指定的服务器。该设置不会影响任何在 Exchange 2000 中无管理权的域。发送给无管理权域中未解析地址的邮件被路由到匹配的 SMTP 连接器（如果存在）。如果找不到匹配的 SMTP 连接器，则将邮件发送到在 DNS 中找到的 MX 记录中指定的服务器。
有关如何在 Exchange 2000 中路由有管理权和无管理权的域的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章： 315591 XCON:Authoritative and Non-Authoritative Domains in Exchange 2000

Leon19821015 2006-08-21 17:10 发表评论

在Exchange 2003中优化内存

Leon19821015 — Mon, 21 Aug 2006 02:14:00 GMT

ExchangeServer2003上安装了1GB以上的物理内存，则必须确保ExchangeServer2003可以有效地使用该内存。存储进程启动时执行最佳内存配置检查。如果内存设置不是最佳的，事件查看器中将会出现事件9665。如果存在下列任一条件，则会显示此消息：
1.服务器正在运行MicrosoftWindows2000Server，并且注册表中的SystemPages值超出了24000到31000这一范围。
2.服务器具有1GB或更多内存，并且没有/3GB开关。
3.服务器正在运行MicrosoftWindowsServer2003，具有1GB或更多内存，并且设置了/3GB开关，但是不存在/USERVA设置或者该设置超出了3030到2970这一范围。
检查注册表中的SystemPages和HeapDeCommitFreeBlockThreshold设置，并检查Boot.ini文件中的/3GB开关和USERVA设置。下列各部分包含对所有这些设置的推荐设置。如果要关闭内存配置检查，可以创建以下注册表项：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

参数：Suppress Memory Configuration Notification
类型：REG_DWORD
设置：1
运行MicrosoftSBS的服务器上不会发生内存配置检查。当引发9665事件时，DWORD会作为附加数据写入事件日志中。

虚拟地址空间概念
ExchangeServer2003中的信息存储(Store.exe)进程可以处理的内存数量是有限制的，这与硬件配置、服务器上的数据库数量以及用户数量无关。此数量称为虚拟地址空间。信息存储区使用的此虚拟地址空间决定ExchangeServer2003邮箱服务器的总体性能和可伸缩性。对于中小型服务器，ExchangeServer2003会自动使平衡达到最佳状态。但是，对于大型服务器，您可能需要手动调整一些优化参数。
如果您的ExchangeServer2003计算机安装了1GB或更多内存，并且如果计算机是邮箱或公用文件夹的宿主，请确保向服务器上的Boot.ini文件添加/3GB开关。如果服务器上没有任何邮箱或公用文件夹（如邮件网关），请不要使用/3GB开关。默认情况下，MicrosoftWindows 2000AdvancedServer和WindowsServer2003操作系统保留2GB虚拟地址空间供内核模式使用，保留2 GB供用户模式使用。特定进程的虚拟地址空间在启动时分配，并且在操作期间随着内存使用的增加而增加。通常情况下，进程实际使用的内存（工作集）大大少于分配给该进程的地址空间。在安装有 1GB 或更多内存的、运行ExchangeServer2003的计算机上，必须修改Windows2000AdvancedServer和WindowsServer2003操作系统，以便有3GB的用户模式内存空间可用。您可以通过在Boot.ini文件中使用/3GB开关来完成此操作。
如果您运行的是Windows2000ServerStandardEdition，请不要设置/3GB开关。Windows 2000 Server Standard Edition 不支持此内存调整开关。如果您这样做，服务器不会生成错误信息，但是设置此开关会导致存在假内存地址空间。如果某个进程试图访问这个较大的地址空间，蓝屏上则会出现一条“Stop”（停止）错误信息，服务器将停止响应。
Windows Server 2003的所有版本（包括WindowsServer2003StandardEdition）都支持 /3GB 调整开关Microsoft 知识库中相应的文章：266096XGEN:Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM
如果您在基于WindowsServer2003的计算机上运行ExchangeServer2003，并且设置/3GB开关，则Microsoft建议您在 Boot.ini文件中设置/USERVA=3030参数。这样，服务器上就可以有更多的系统页目录项 (PTE)。有关/USERVA开关的其他信息，请查看Microsoft知识库中相应的文章：

810371XADM:Using the /Userva Switch on Windows 2003 Server-Based Exchange Servers

确保Store.exe进程不会将虚拟地址空间用尽。当虚拟地址空间耗尽时，即使有大量物理 RAM 可用，内存分配也将失败。要解决此问题，您必须重新启动信息存储服务。例如，具有2GB物理RAM、但没有在Boot.ini文件中设置/3GB开关的服务器在Store.exe进程所使用虚拟地址空间达到2GB时将会出现内存不足的情况。在这种情况下，Windows任务管理器可能会显示实际只使用了大约1.5GB的内存。但是，服务器确实内存不足，并且必须重新启动信息存储服务。
当Store.exe进程的虚拟内存不足时，ExchangeServer2003服务器的性能可能会大大降低。当最大的可用虚拟内存块减至32 MB时，事件查看器的应用程序日志中会生成事件ID9582警告事件。如果您看到此事件，下次有机会时最好重新启动Store.exe 进程。如果最大内存块减少的更多，只有16MB，则事件查看器的应用程序日志中会生成事件ID9582错误事件。如果发生此事件，则服务器已接近临界操作条件，下次有机会时必须重新启动服务器。发生此错误后，内存可能会在几个小时内耗尽。如果您没有响应这些事件，可能会遇到下列症状中的一个或多个：
间歇性消息传递故障。
由事件ID12800指示的间歇性 Internet 邮件 (IMAIL) 转换过程故障。
某些支持Exchange的防病毒程序可能会生成错误信息或事件。

最大化虚拟地址空间
要确保性能和稳定性不会降低，最好监视大型邮箱服务器上信息存储的虚拟地址空间。完成此操作的最简单方法是，在“性能”实用工具中监视MSExchangeIS性能对象的虚拟内存最大块大小计数器。该值以字节为单位进行显示。启动计算机后，通常应查看最大虚拟内存块大小是否明显减少。但是，经过一两天的运作后，该值会接近通常的操作级别。如果最大可用虚拟内存块的值大于200,000,000 字节（大约200MB），则表示服务器运行正常。如果您发现值小于该数值，请更加亲切地监视服务器。如果您遇到虚拟地址空间不足的情况：
如果您安装了1GB或更多物理内存，当服务器满足下列条件时，请确保在Boot.ini文件中设置/3GB开关：
服务器是邮箱或公用文件夹的宿主。

操作系统是Windows2000AdvancedServer或WindowsServer2003。

如果服务器上没有任何邮箱或公用文件夹（如邮件网关），请不要使用/3GB开关。
如果ExchangeServer2003安装在基于WindowsServer2003的服务器上，并且它设置了/3GB开关，请确保在Boot.ini 文件中设置/USERVA=3030开关。如果ExchangeServer2003安装在基于Windows2000的服务器上，请确保该服务器运行的是 Windows2000ServicePack3或更高版本。
如果您安装了1GB或更多物理内存，请在以下注册表项中配置HeapDeCommitFreeBlockThreshold ，然后重新启动服务器：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager值名称：HeapDeCommitFreeBlockThreshold
数值类型：REG_DWORD
值数据：0x00040000（推荐）
默认值：不存在有关如何使用和配置此注册表值的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

315407XADM:The "HeapDecommitFreeBlockThreshold" Registry Key

通常情况下，前面的步骤可以解决虚拟地址空间使用问题。不过，在一些较大的服务器上，您可能必须对“存储数据库缓存大小”进行其他调整，才可重新平衡性能与可伸缩性之间的差距。
存储数据库缓存大小
存储数据库缓存也称为ESE缓冲区，在数据库事务被提交到存储区之前，该缓冲区为这些事务提供较大的缓存区域。默认情况下，ExchangeServer2003会查询本地计算机的内存配置，然后分配896MB的RAM（如果Boot.ini文件中设置/3GB开关），或者分配576MB 的RAM（如果没有设置/3GB开关）。如果服务器负载过重，或者如果磁盘性能不是最佳，则使用较大的ESE缓冲区会提高系统的总体性能。根据您的配置，您可能必须增加或减小此缓冲区的大小，以便获得最佳的总体性能。如果Exchange Server2003所在的环境中存在其他服务器端程序，则它可能会独占可用的内存资源。“动态缓冲区分配”(DBA) 算法负责在其他程序需要内存时将内存归还给操作系统。不过，您可以通过减小ESE缓冲区手动限制ExchangeServer2003使用的内存。在具有2GB以上内存的服务器上，增加 ESE 缓冲区大小可能会有所帮助。由于虚拟地址空间限制，该值不能大于1,200MB。增加最大缓冲区大小之前，最好使用Windows“性能”实用工具监视具有典型负载的服务器上的内存。为此，请监视以下性能对象和值：

性能对象：进程
性能计数器：虚拟字节
实例:STORE

在性能监视期间收集的信息可提供Store.exe进程已分配的虚拟地址空间的准确值。在Boot.ini文件中设置了/3GB开关的服务器上，“性能”实用工具中显示的值通常小于2.8GB。在Boot.ini文件中设置/3GB开关的服务器上，显示的值通常小于1.8 GB。在安装了1GB或更多内存的服务器上，最好向Boot.ini文件中添加/3GB开关。如果您看到的任一配置的值大于以前注意到的那些值，则不要增加最大缓冲区大小。如果看到的任一配置的值小于以前注意到的那些值，可能需要增加数据库最大缓冲区大小。
例如，如果您的服务器在 Boot.ini 文件中配置了 /3GB 开关，而且性能监视在服务器负载过重时显示 2.5 GB 的虚拟字节计数，则您或许可以将最大缓冲区大小增加 300 MB 左右，使总大小为 1,200 MB。增加缓冲区大小可能会对服务器性能产生不利影响。缓冲区越大，意味着使用的虚拟地址空间越多。因此，如果您的服务器遇到虚拟内存地址空间限制，增加缓冲区大小可能会导致操作系统不稳定。在非常大的邮箱服务器上，可能必须减小默认的缓冲区大小才可防止系统不稳定。

如何修改ESE缓冲区大小
    msExchESEParamCacheSizeMax参数控制ESE缓冲区大小。它的值以页计数的形式表示，并且必须设置为8192的精确倍数才可实现最大效率:
    设置了/3GB开关的服务器上的默认大小:229376(896MB)
    没有设置/3GB开关的服务器上的默认大小:147456(576MB)
    推荐使用的最大值:307200(1.2GB)
    具有地址空间限制的大型服务器上的推荐值:196608(768MB)
注意：如果 ESE 缓冲区大小设置的较大，事务日志的重放速度会大大加快。如果需要进行灾难恢复，可能需要将 ESE 缓冲区大小暂时增大为 307200。
    如果已经将Exchange5.5Serve计算机就地升级到了Exchange2000Server，您可能会注意到为 msExchESEParamCacheSizeMax参数分配了一个异常高的值。在有些服务器上，该值等于2,048MB。在这种情况下，请删除该参数或将其重置为更适当的值。要修改存储数据库缓存大小，请执行下列操作：
   1.启动“ADSI 编辑”实用工具
   2.在“配置容器[servername.example.com]下”，展开“CN=Configuration, DC=example, DC=com”。
   3.依次展开“CN=Services”、“CN=Microsoft Exchange”、“CN=组织名称”、“CN=Administrative Groups”、“CN=第一个管理组”、“CN=Servers”和“CN=服务器名称”。
    4.在“CN=服务器名称”下，右键单击“CN=InformationStore”，然后单击“属性”。
    5.在“请选择要查看的属性”列表中，单击“两者”。在“请选择要查看的属性”列表中，单击“msExchESEParamCacheSizeMax”。
    6.注意:msExchESEParamCacheSizeMax属性超出了“请选择要查看的属性”列表宽度。确保不要无意中单击“msExchESEParamCacheSizeMin”属性。在“编辑属性”框中，键入要分配给此属性的值。确保您输入的值是8,192的倍数。单击“设置”，然后单击“确定”。
    7.退出“ADSI 编辑”实用工具，然后留有足够的时间以便将该值复制到整个ActiveDirectory林中。
    8.在Exchange服务器上重新启动MicrosoftExchange信息存储服务.

Leon19821015 2006-08-21 10:14 发表评论

在Exchange中配置SMTP连接器

Leon19821015 — Sun, 20 Aug 2006 04:02:00 GMT

    Exchange2000和Exchange2003与ExchangeServer5.5的工作方式不同。在ExchangeServer5.5中，SMTP是通过 Internet邮件服务添加的附件。而在 Exchange 2000 和 Exchange 2003 中，SMTP是本机的-一切都基于SMTP。默认的 SMTP 虚拟服务器本身就可以处理所有的 Internet 通讯量（入站和出站）。通常情况下，使用SMTP的主要原因是要以特定方法将邮件发送到特定域（例如，只将邮件转发到该域的特定的智能主机，或者发送 HELO 而不是 EHLO）。
    配置SMTP连接器:
   1.启动 Exchange 系统管理器。
   2. 展开“管理组”容器。为此，请单击该容器左边的加号 (+)。
   3. 单击您想使用的管理组，然后展开它。
   4. 展开“路由组”容器。
   5. 单击您想使用的路由组，然后展开它。
   6. 单击连接器容器。右键单击连接器容器，然后单击新建。
   7. 单击 SMTP 连接器。
   8. 在常规选项卡上，为该连接器提供一个适当的识别名。
   9. 选择使用 DNS 或转发到智能主机（如果您在通过 Internet 服务提供商的发送邮件服务器进行中继）。
   10. 在本地桥头下，单击添加。添加将成为路由组桥头服务器的服务器。将一个 SMTP 虚拟服务器指派为 SMTP 连接器的桥头服务器。
   11. 单击地址空间选项卡。在连接器作用域下，单击整个组织或路由组。而在较早版本的 Exchange Server 中配置 Internet 邮件服务时，要单击添加，单击 SMTP，然后单击确定。除非您需要出站电子邮件域限制，否则请接受默认设置 (*)，并且让成本保留为 1。
   12. 如果您已经选择将所有邮件转发到智能主机，则请单击高级选项卡。单击出站安全选项卡，然后为中继主机选择适当的身份验证方法。默认设置是“匿名访问”。
   13. 单击确定退出“出站安全”选项卡。
   14. 单击确定退出高级选项卡。
   15. 单击确定退出 SMTP 连接器。
   16. 退出 Microsoft Exchange 路由引擎服务和 SMTP 服务，以让这些更改生效。

Leon19821015 2006-08-20 12:02 发表评论

浅谈Exchange Server邮件存储系统-技巧篇

Leon19821015 — Fri, 18 Aug 2006 03:55:00 GMT

Exchange存储系统软硬件的选择和设计
    当数据库损坏时，通过还原磁带上的备份和利用系统现有的日志文件，可以把数据库恢复到发生问题之前的一个状态。因此，数据库文件和日志文件需要存放在不同的物理磁盘之上。通常企业中重要的服务器存储系统一般都采用通过硬件系统来实现的RAID阵列。常用的RAID系统有RAID 5和RAID 1。这两种的系统特点如下：
    RAID 5：向阵列中的磁盘写数据，奇偶校验数据存放在阵列中的各个盘上，允许单个磁盘出错。RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为（n-1/n）%。
    RAID1 把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID 1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。
    RAID 5偏重于数据的安全性；RAID 1（镜像磁盘）在数据的安全得到保障的前提之下，强调了读写速度。
下图是微软推荐的Exchange Store系统存储硬件需求。

520)this.width=520;" style="ZOOM: 90%" onclick="javascript:window.open(this.src);" src="http://www.51cto.com/files/uploadimg/20051206/1011280.gif" onload="javascript:if(this.width>560)this.style.width=560;" align="absMiddle" border="0" />

    数据库文件置于RAID 5的系统之上；Log文件的存放是采用了每一个Storage Group一套RAID 1的策略。对于数据库文件，这些文件的尺寸往往非常的大，并且在日常的运行过程中，需要被非常频繁的读写。从安全的角度考虑，数据库文件的重要性要远远大过日志文件。因此，采用RAID 5系统保存数据文件，可以最大限度的保证文件的数据安全：在频繁的读写时，能通过校验位来保证数据不会发生错误；在磁盘硬件故障发生时，能使系统不受影响。对于日志文件，需要尽快写入到硬盘中，对于保存日志文件的磁盘系统，它的读写压力并不是非常的大，但是要求有非常快的写入速度。非常快的写入速度由两点来得到保证：第一，采用具有较快写入速度的RAID 1系统（相对于RAID 5，不需要计算校验位，这节省了大量的时间）；第二，每一个Storage Group独占一个RAID 1系统（既该RAID 1阵列只用来保存特定的Storage Group的日志文件，别无它用），这样做，我们就把磁盘上的碎片数量降低到了最小的限度。理想情况下，日志文件每个扇区都是紧挨着的，磁盘在写数据时，不需要因为磁盘碎片的缘故而重新定位磁头，这最大的提高了写入的性能。
    存放数据库文件的RAID 5系统的磁盘空间容量由实际的邮箱数量和邮箱的大小决定。我们需要考虑如下的因素：
    第一： Delete Item的保留时间。如果想掌握服务器上每一个邮箱的动态，可以使用一个名为“Quest Reports”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：http://www.quest.com/messagestats/

520)this.width=520;" style="ZOOM: 100%" onclick="javascript:window.open(this.src);" src="http://www.51cto.com/files/uploadimg/20051206/1011281.gif" onload="javascript:if(this.width>560)this.style.width=560;" align="absMiddle" border="0" />

    第二：数据库维护时所需要的空间。在我们进行Exchange Server数据库的离线碎片（Offline defrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。
    因此，存放数据库文件的RAID 5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。

存储引擎的性能检测和优化
    作为管理员，我们需要密切的监控Exchange Server Store的性能状态。下面的一些性能计数器是我们需要时刻关注的：

MSExchangeIS\Active User Count

MSExchangeIS\User Count

上面这两个计数器，反映了当前服务器上的活动用户数和登陆用户数。一般性，Active User Count总是小于User Count。由于Exchange Server内部使用了一些系统邮箱用来进行服务器间通信，因此即使没有任何使用者在线，User Count也总是维持在20左右，这是正常的。

MSExchangeIS\RPC Averaged Latency

MSExchangeIS\RPC Operations/sec

MSExchangeIS\RPC Packets/sec

MSExchangeIS\RPC Requests

上面四个计数器，反映了Exchange Server Store的RPC处理响应能力。这几个计数器，最能体现当前服务器的负载和响应速度。RPC Operations/sec、RPC Packets/sec分别表示服务器每秒接收到的RPC请求（所有Outlook MAPI客户端连接在读取、发送邮件时都会向服务器发送大量的RPC请求）。RPC Requests表示Exchange Server当前正在处理的请求，一般情况下，Exchange Server最多能同时处理100个请求，因此如果这个计数器超过了100，Exchange Server将会有严重的性能问题。最后一个也是最重要的一个，RPC Averaged Latency，这个计数器表示当前时刻之前的1024个RPC请求的平均响应时间，这个时间的单位是毫秒，一般性，这个计数器应该小于20。如果该计数器大于100并且持续较长的时间，客户端Outlook的响应速度将变得很慢甚至死机。
对RPC Averaged Latency有影响的因素很多。执行备份、在线碎片整理、防病毒软件扫描数据库等等都会使RPC Averaged Latency的值升高。另外，值得注意的是，网络环境的不正确配置，也会引起问题。笔者曾遇到过由于交换机端口的速度与Exchange Server上的网卡速度不匹配而引起的严重性能问题。详细的情况是这样的，客户邮件系统的性能突然大幅度的下降，RPC Averaged Latency的值高达5位数，所有用户都不能打开邮箱。在排除Exchange和Windows的问题后，我们从客户处了解到，他们前一天更换了与 Exchange Server相连的交换机。按理说，Exchange Server是应用层的软件，它不会也不应该对数据链路层的设备有任何的依赖。但是查过微软的知识库以后，我们找到这了这篇文章：“Poor Performance When Network Adapter Is Set to Auto Sense”，文章的知识库号码为330343。文中提到，对于Exchange Server，如果网卡或者交换机端口设置为自动检测速度，这可能会造成严重的性能问题。首先查看Exchange Server，其网卡的设定为100M 全双工，符合微软的要求；再连接到交换机上察看，发现交换机上跟Exchange Server网卡相连的那个端口，被设定为Auto即自动检测速度，当前的连接情况为100M 半双工。改为固定的100M全双工设定以后，故障立刻消失，RPC Averaged Latency的值恢复到了20以下，用户收发邮件都没有问题了。
事后我们分析，对于Exchange Server的系统，有可能微软在传送RPC信息时，使用了一些特殊格式的数据包，因此对网络链路有较高的要求。交换机一般都是上电之后直接使用，对它的设定往往很容易被管理员们所忽略。

MSExchangeIS\VM Largest Block Size

MSExchangeIS\VM Total 16MB Free Blocks

MSExchangeIS\VM Total Free Blocks

MSExchangeIS\VM Total Large Free Block Bytes

这四个计数器跟Exchange Server Store进程的内存使用情况有关。我们都知道，在Exchange Server上，store.exe进程往往是内存消耗的大户，ESE数据库引擎为了提高它的性能，需要申请大量的内存作为其缓存空间，在有300个以上用户的Exchange Server系统上，store.exe进程的物理内存占用量一般都在1GB以上。在Windows操作系统中，内存分为物理内存和虚拟内存。物理内存指机器上安装的内存条；虚拟内存指CPU可以寻址的内存范围。对于Windows 2000来说，物理内存的大小由安装的内存多少决定，虚拟内存默认情况下都是4GB。（关于Windows 2000内存的更进一步知识，读者可以参考Inside Windows 2000这本书的第六章：内存管理。）如下图的左面部分所显示，每一个进程都有4GB的地址空间，默认情况下，2GB为操作系统所有，2GB为应用程序使用。

520)this.width=520;" onclick="javascript:window.open(this.src);" src="http://www.51cto.com/files/uploadimg/20051206/1011282.gif" width="520" onload="javascript:if(this.width>520)this.width=520;" align="absMiddle" border="0" />

Exchange Server在运行过程中，会频繁的在它所拥有的2GB用户地址空间中分配和释放内存。这样会引起内存地址空间的“碎片”：内存地址中的空余的空间变得不连续。上述的四个计数器中，VM Largest Block Size表示用户地址空间中最大的连续空余内存块；VM Total 16MB Free Blocks表示尺寸在16MB以上的连续空余内存块的数目；VM Total Free Blocks表示总的空余内存块的数量；VM Total Large Free Block Bytes表示空余内存的总数量。
当VM Largest Block Size的数量小于32M时，事件察看器中会记录下编号为9582 的Warning日志；当VM Total 16MB Free Blocks为零也就是最大可分配内存空间小于16MB时，事件察看器中会记录下编号为9582的Error日志。

Source: MSExchangeIS

Category: Performance

ID: 9582

Type: Warning/Error

Description:

The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.

这种情况出现，说明Exchange Server的虚拟地址空间中已经存在了大量的碎片，由于无法满足内存的分配，Exchange Server的性能和稳定性都会出现问题。
对于这类问题，大家可以参考微软的知识库文档“Troubleshoot Virtual Memory Fragmentation in Exchange 2003 and Exchange 2000”，其文档代号为325044。这篇文章详细地分析了虚拟内存碎片产生的原因和应对办法。
为了满足服务器软件对内存的要求，微软公司的Windows 2000 Advanced Server和Data Canter版本的操作系统支持把用户地址空间扩大为3GB，这样可以有效的缓解虚拟内存碎片的问题。该项功能需要在系统分区的boot.ini中做一定的修改才可以开启，具体的操作方法请参考微软文档“A Description of the 4 GB RAM Tuning Feature and the Physical Address Extension Switch”其文章代号为291988。
对于Exchange 2000 Server，当服务器安装了1GB以上的RAM时，微软推荐开启操作系统的3GB开关，否则可能会有性能上的问题。参考文档：
266096 Exchange requires /3GB switch with more than 1 GB RAM
328882 Exchange memory use and the /3GB switch
Exchange Server Store性能优化的建议
1.确保Exchange Server的网卡和交换机端口设置正确。
2.有1GB以上物理内存的服务器要安装Windows 2000 Advanced Server版并在开启boot.ini中开启/3GB开关。
3.在可能的情况下，要尽量少的创建Storage Group。上一期文章中，我们知道，每一个Storage Group，都对应于一个ESE数据库引擎的实例。在store.exe中，每生成一个ESE数据库引擎的实例，都会消耗10M的内存空间。

数据库碎片整理的作用和注意事项
    Exchange Server在指定的时间在后台不断地进行在线碎片整理（Online Defrag）。在线碎片整理主要执行如下的操作：
    1.通过查询活动目录来确定Store中是否有被删除的邮箱。
    2.物理的删除所有超过保留时间的邮件和邮箱。
    3.执行在线碎片整理。
对于第一项操作，Exchange Server会向活动目录发起查询，以确保活动目录中的用户信息和Exchange Store中保存的邮箱信息是同步的，对于删除的邮箱，Exchange Server会作特殊的标记。这项操作不会对Exchange Server带来太多的额外负担，但是对活动目录的域控制器却有一定的压力。一般我们是在晚上进行在线碎片整理的操作，所以此时活动目录的负载不会有什么问题，但如果对于一些大型的跨国企业，其活动目录的域控制器往往要服务于各时区的用户时，在线碎片整理的时间需要认真地调整以避免给用户带来影响。
第二和第三项操作会对Exchange Server本身带来一定的负载，主要是一些密集的磁盘操作。在线碎片整理期间，用户访问邮箱的速度会明显的变慢。当Exchange Server的备份和在线碎片整理的时间发生冲突时，在线碎片整理会被终止并直到备份完成才能得以恢复。关于在线碎片整理的详细细节，请参考微软知识库文档“Understanding Performance and Scalability Characteristics of Exchange 2000 MDB Online Maintenance”，其文档代号为271222。
正常情况下，在线碎片整理会在管理员规定的时间停止，并在事件日志中记下如下的内容

Event: 1221

Source: MSExchangeIS Private

Type: Information

Category: General

Description: The database has nnn megabytes of free space after online defragmentation has terminated.

这表示Exchange Server在线碎片整理过程中发现并计算出数据库中含有的碎片空间的大小。在线碎片整理只会标示出碎片的位置并计算其空间，并不会物理的移动数据页面以消除这些碎片空间。如果需要物理的消除这些碎片空间，需要执行离线碎片整理。当上面事件中显示的碎片空间达到一定的比例时（占数据库文件的10% ~15%），我们需要执行离线碎片整理。
对于离线碎片整理，我们通常按照如下的流程：
1.在进行离线碎片整理之前，对所操作的Store进行全备份
2.Dismount Store
3.使用eseutil /mh确认edb和stm文件是“Clean shutdown”（在上期中有详细的论述）
4.执行如下的命令来进行碎片整理

C:\Program Files\Exchsrvr\BIN>eseutil /d

X:\Exchsrvr\Mdbdata\SG1MS1.edb

/tX:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /o /p <回车>

命令会有如下的输出：

Initiating DEFRAGMENTATION mode...

      Database: F:\Exchsrvr\Mdbdata\SG1MS1.edb

Streaming File: F:\Exchsrvr\Mdbdata\SG1MS1.STM

Temp. Database: F:\Exchsrvr\Mdbdata\SG1MS1_temp.edb

Temp. Streaming File: F:\Exchsrvr\Mdbdata\SG1MS1_temp.STM

            Defragmentation Status (% complete)

      0 10 20 30 40 50 60 70 80 90 100

      |-----|-----|-----|-----|-----|-----|------|------|------|------|

      .................................................................................

Note:

It is REQUIRED that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup.

Operation completed successfully in 13.110 seconds.

碎片整理的实际时间取决于数据库文件的大小，在Exchange 2000中，一般一小时可以处理7~10GB的数据。在碎片整理完成后，系统会根据制定的文件名生成两个不含碎片的edb和stm文件。
5.在把新的数据库文件Mount之前，需要确保其完整性，我们要执行如下的命令

C:\Program Files\Exchsrvr\BIN>eseutil /g X:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /sX:\exchsrvr\mdbdata\SG1MS1_temp.stm <回车>

其输出如下：

Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0

Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating INTEGRITY mode...

   Database: priv1.edb

Streaming File: priv1.stm

Temp. Database: TEMPINTEG3976.EDB

Checking database integrity.

               Scanning Status (% complete)

      0 10 20 30 40 50 60 70 80 90 100

      |-----|-----|-----|-----|-----|-----|------|------|------|------|

      .................................................................................

Integrity check successful.

Operation completed successfully in 9.62 seconds.

此项操作也需要较长的时间，一般的速度是10GB每小时。
6.文件改名。把旧的edb文件和stm文件从mdbdata文件夹中移走。把执行过碎片整理的临时文件改为同旧的edb文件和stm文件相同的名字。然后Mount数据库。
7.如果Mount数据库失败，最快的恢复办法就是把旧的edb文件和stm文件再复制到mdbdata文件夹。Defrag过程中，旧的edb文件和stm文件没有被更改，即使defrag失败，也可以恢复到defrag之前的状态。
关于碎片整理得更多细节，我们可以参考下面的文档：
192185 XADM: How to Defragment with the ESEUTIL Utility

如果避免Exchange Server的数据库文件损坏
对于数据库损坏的问题，防患于未然要远远比事后亡羊补牢来的有效。数据库的损坏一般可以分为物理损坏和逻辑损坏。
物理损坏往往是由磁盘介质、控制卡等硬件设备的故障引起的。这种类型的损坏都会引起数据丢失，唯一的解决办法就是从备份的磁带进行恢复。Exchange Server为了确保数据的一致性，会在向数据库写入内容时（写入的单位是4KB的页面），把根据数据内容计算得出的校验和跟实际的数据一并写入。当读取时，系统会重新计算校验和，并跟保存的校验和进行比较，如果这两个值不同，说明读出的数据和当初写入的数据相比，已经发生了变化。这种变化往往是由磁盘故障、控制器总线传输故障等引起的。为了排除干扰因素，当校验和不匹配的情况出现时，Exchange Server会再次到磁盘上去读取那个页面，如此循环16次。如果连续读取16次，校验和跟原始的值仍然无法匹配，Exchange Server就会认为数据库已经发生了物理损坏。在事件日志中，会有如下的内容被记录下来：

Event ID: 23

Source: EDB

Type: Error

Category: Database Page Cache

Description: MSExchangeIS ((455)) Direct read found corrupted page error -1018 ((1:251563) (0-2295758), 251563 379225672 381322824). Please restore the database from a previous backup.

另外，当事件日志的错误描述中出现如下的代码，基本上也可以认定数据库发生了物理损坏：

-1018 (JET_errReadVerifyFailure)

The data read from disk is not the same as the data that was written to disk.

-1022 (JET_errDiskIO)

The hardware, device driver, or operating system is returning errors.

-510 JET_errLogWriteFail

The log files are out of disk space or there is a hardware failure with the log file disk.

数据库的物理损坏往往会带来数据丢失和Exchange Server停机等损失。我们可以采取下面的一些建议来避免物理损坏的发生：
1.采用高质量的磁盘和磁盘控制系统，对硬件RAID系统进行正确的配置。
2.不要使用文件级别的工具或防病毒软件扫描数据库文件和日志文件。
3.避免使用磁盘控制卡上的写入缓存（Write-back caching）。
4.定期地进行全备份。全备份一方面保证了数据的安全，另一方面也能及早地发现数据库的物理损坏。在执行全备份时，备份程序会把数据库的每一个页面读取出来并重新计算校验和，如果有损坏的页面存在，管理员可以及早的发现问题并采取行动。
当物理损坏发生时，我们可以采取如下的步骤来进行恢复：
1.如果有全备份，一定要先从备份进行恢复。
2.在没有备份的情况下，可以使用Eseutil /p来进行手工的修复。但这是不推荐的做法，从备份恢复是最好的解决办法。
关于数据库的物理损坏，更详细的内容请参考微软知识库文档“Understanding and analyzing -1018, -1019, and -1022 Exchange database errors”，这篇文章的代号是314917。
另外一种常见的数据库损坏是逻辑损坏。数据库的内容本身没有问题，但是一些内部的视图、关联发生问题时，就会发生逻辑损坏。逻辑损坏的症状往往表现为：大部分用户使用正常，某些用户在点击特定的邮箱文件夹或者邮件时，会发生死机等现象。对于这种故障，一般可以使用ISINTEG命令来进行修复。
关于Exchange Server数据库的更多内容，大家可以阅读微软知识库文档“Overview of Exchange Server Database Architecture and Database Engine”这篇文章的代号是217987。

Leon19821015 2006-08-18 11:55 发表评论

Exchange 2k的安装

Leon19821015 — Fri, 18 Aug 2006 03:22:00 GMT

安装Exchange 2K
1.启动DOS命令行方式，导航到cdrom:\setup\I386
2.命令setup /forestprep，它将把大量的信息写入到你目前的Schema和Origination。把Exchange彻底整合到AD。
3.命令setup /domainprep，为安装Exchange做准备
4.命令setup，在选择安装类型时请选择自定义安装，并且在选择安装的组件时只选择Administrative Tools。
5. 在管理工具安装完成以后，你可以建立你的AG（管理组）和RG（路由组），在这里可以根据公司的具体情况和地域分布随意的给管理组命名。如果采用自动安装，将无法改变管理组的名称，并且整个的安装过程将会非常缓慢。
6.命令setup，此时你可以根据你的需要随意添加组件了。
查看服务:
SYSTEM ATTENDENT，它是Exchange最底层的服务，如果这个服务没有运行，那么你的Exchange安装就是失败的
INFORMATION STORE服务，如果这个服务没有运行，你将看不到Exchange自动映射的M盘（M盘是非常重要的，在这里将保存用户的所用数据，以及 Exchange用于数据恢复的Log文件。）；这个服务依赖于SYSTEM ATTENDENT服务。如果你的DNS配置出了问题，那么这两个服务可能无法正常工作，因为这两个服务的正常工作都需要WINDOWS 2000 Server的DNS的支持。至于其它的服务比如：POP3、SMTP、IMAP4等等，这些服务都将会自动启动。

Leon19821015 2006-08-18 11:22 发表评论

卸载Exchange 2003的步骤

Leon19821015 — Thu, 17 Aug 2006 08:49:00 GMT

前提条件:
1.具有管理组级别的 Exchange 管理员（完全控制）权限
2.有任何邮箱被分配给服务器上的存储组
3.组织中只有一台服务器运行收件人更新服务
4.混合管理组中只有一台服务器运行站点复制服务 (SRS)
5.某服务器是连接器的桥头服务器并且组织中有其他 Exchange 服务器
6.某服务器是路由主服务器并且组织中有其他 Exchange 服务器
7.服务器在一个管理组中，同时又在属于另一个管理组的路由组中，则您必须具有这两个管理组的权限（或具有 Exchange 组织的权限）
8.不能在无人值守模式下使用安装程序卸载 Exchange 2003

卸载:
1.添加/删除下
2.都选择删除

Leon19821015 2006-08-17 16:49 发表评论

将Exchange 2000移至新硬件并保持同一服务器名

Leon19821015 — Thu, 17 Aug 2006 08:21:00 GMT

将 Exchange 2000 移至新硬件：
1.对现有Exchange2000服务器上的所有Exchange2000存储组和站点复制服务(SRS)进行完整备份
2. 将现有服务器脱机
3.重置Exchange2000服务器的机器帐户( 启动Active Directory用户和计算机, 找到Exchange2000服务器机器帐户，用鼠标右键单击该机器帐户，然后单击重置帐户)
4. 将新服务器联机并使用同一服务器名
5. 使用Exchange2000管理员（完全控制）帐户登录到新服务器。安装Exchange2000所需的任何组件，如IIS服务和适当的 Microsoft Windows2000SSP。使用Setup /disasterrecovery运行 Exchange 2000 安装程序。对于邮件传输和协作服务以及 Exchange 系统管理工具，请确保单击操作-灾难恢复。安装完成后，请安装已在现有服务器上安装的 Exchange 2000 Service Pack。添加以下注册表字符串： HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Setup DWORD_NAME:ServicePackBuild SP1 HEX_VALUE:1268 SP2 HEX_VALUE:1682 SP3 HEX_VALUE:1869 安装任何已在现有服务器上安装的 Exchange 2000 Service Pack 后续修补程序。
6. 在单独的恢复作业中，从 Exchange 2000 服务器备份中恢复存储组和 SRS。
7. 恢复完成后，装入所有存储。请确保客户端可以连接，并且邮件可以流入。
备注：如果 Exchange 2000 服务器的 IP 地址发生更改，请确保更新域名系统 (DNS) 记录。如果不更新 DNS 记录，其他服务器可能试图连接到以前的地址。

就我个人感觉迁移比这安全

Leon19821015 2006-08-17 16:21 发表评论

Exchange Server邮件存储系统-原理篇

Leon19821015 — Wed, 16 Aug 2006 08:55:00 GMT

Information Store和Extensible Storage Engine的层次关系
    在Exchange Server中，Information Store Service是至关重要的。这个服务控制了对邮箱和公共文件夹数据库的操作请求。事实上Exchange Server的数据库系统是由Extensible Storage Engine的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，在微软的很多系统中都有应用：例如，AD的数据库（ntds.dit文件）、Windows DHCP、Windows WINS、SRS等，后台都是由ESE数据库来提供支持的。
       Exchange Server的数据库由edb文件、stm文件和众多的log文件组成。在这些文件内部，微软使用了名为“B+树”的内部数据结构，ESE引擎的任务之一，就是当Information Store服务请求访问数据库的时候，把这些请求转化成对内部数据结构的读写访问。B+树的特点是能够对存储在磁盘上的数据提供快速的访问能力。微软选用 B+树作为ESE后台结构的一个原因，就是尽可能提高访问数据时的I/O性能。这些B+树的结构对于Exchange Server Store服务来说是透明的，Store只需要把请求发给ESE即可，ESE会对这些数据结构进行操作。另外，作为一个数据库系统，ESE有责任提供事务（Transaction）级别操作的支持，并维护整个数据库的完整性和一致性。对于现代数据库系统，当我们提到事务时，一般用ACID这样的缩写来描述事务的特点：
      对于Information Store Service来说，ESE封装了对数据库操作的所有细节，IS只要根据ESE提供的接口进行调用既可。在Exchange Server 2000中，IS服务对应的进程是store.exe，每一个Storage Group会在store.exe进程中产生一个ESE引擎的实例。
Exchange Server 2000/2003 存储系统的新特点
   在微软发布Exchange Server 2000时，Exchange Server的存储系统得到了很大的更新和改进。从ESE引擎的角度来看，ESE的版本由5.5中的ESE97升级为ESE98，并且在如下方面得到了改进：
1.I/O性能得到进一步的优化和提高
2.对日志文件增加了计算校验和的操作，进一步降低了数据库出错的可能性
3.提高了ESEUtil等维护工具的速度
相比幕后的ESE引擎，Information Store方面的更新更加引人注意，例如：
1.在每台Server上提供多个Storage Group和Store的支持，这是区别于5.5的最大特征之一
2.数据库中stm流文件格式的引入，提高了操作Internet邮件的性能
3.Web Storage System的引入，用户可以使用多种协议访问数据库
EDB文件和STM文件的关系
   在Exchange5.5中，数据库只有扩展名为edb的文件。在Exchange5.5发布的时候，微软的重点还是企业内部的邮件传输系统，当时主推的协议是MAPI协议，这是微软的私有邮件协议，edb格式的数据库为此协议作了专门的优化。Exchange5.5为了支持Internet标准的SMTP邮件格式，必须在每次处理Internet邮件时将其转化为edb格式，这样做带来的巨大的性能损失。在Exchange2000中，微软加大了对Internet标准协议SMTP的支持力度。因此，适用于Internet格式邮件的存储就应运而生：这就是stm文件。MAPI格式的邮件是基于微软的RPC和二进制标准的，而Internet格式的邮件是由纯文本的邮件头和经过MIME编码的字符流组成的。这两者的特性就决定他们无法共存在一种数据库结构的文件中。因此，在Exchange Server 2000中，微软分别使用edb文件和stm文件保存这两种格式的邮件，并在edb和stm文件之间建立了关联和引用。对于用户来说，他的邮箱内容实际上是由跨越了edb和stm文件中的内容共同组成的。值得一提的是，edb文件中除了实际的信件信息以外，还保存了每个用户的邮箱结构、每一个文件夹的内容列表和视图等信息。这是区别于stm中只保存字符流的地方。
我们分下面几种情况讨论edb和stm文件的使用：
1.用户使用Outlook 以MAPI协议的方式和发送和访问邮件
2.用户使用 SMTP/POP3等Internet协议访问Exchange Server。
情景一：
当邮件从MAPI协议的客户端(通常是Microsoft Office中的Outlook)提交到数据库后，邮件内容被保存在edb文件中。
当用户通过MAPI协议的客户端对邮箱中的邮件进行读取访问时，如果请求的邮件是保存在edb文件中的，那么信件被直接打开后返回给用户。如果被请求的信件保存在stm文件中（此信件是SMTP格式的），那么，Exchange Server数据库引擎首先会做一个转换，把stm文件中的数据格式转换成MAPI可以识别的格式，然后再发送给客户端。这个过程称之为“On- demand Conversion”。
情景二：
用户使用SMTP/POP3客户端（如Outlook Express, FoxMail等）跟邮箱连接。当SMTP协议向Exchange Server提交邮件时，邮件的内容被保存在stm文件中。前面提到过，edb文件中包含了用户邮箱的文件夹和信件内容列表，因此，当邮件被保存到stm 文件后，数据库引擎把这封邮件的一些重要信息（通常是邮件头中的内容和信件在stm文件中的位置）提取出来，保存到edb文件，这个过程称之为 “Property Promotion”。正是有了这个过程，用户才可以得到信箱内容的完整列表，MAPI客户端需要访问位于stm文件中的邮件时，由此能够得到stm文件中信件的正确保存位置。当用户使用POP3协议来读取邮件时，如果被访问的邮件位于edb文件中，同样，一个从MAPI到Internet格式的转化（“ On-demand Conversion”）也会在后台悄悄的发生。
    通过上面的描述，我们知道在实际的Exchange Server环境中，这两个文件是紧密关联的。在任何时候都不要单独的操作这两个文件，要始终把他们视为一个整体。edb文件中包含了每一个邮箱的内容列表（store tables），当客户端需要得到文件夹的内容时，都必须向edb文件发出请求。两种格式的文件，对两种类型的协议分别提供了支持，有效的减少了不必要的格式转换的发生。
Log文件的作用
    我们来看看这些日志文件到底有些什么作用。对于每一个Storage Group，Exchange Server会产生一系列与之对应的日志文件。这些日志文件的大小为5M，扩展名为log，他们的前缀为E0x,其中x是日志文件所对应的Storage Group的编号[脚注:虽然在Storage Group的属性中有“Log File Prefix”这一个文本框，但实际上这是不能更改的。因此第一个Storage Group的日志文件前缀为E00，第二个的为E01，依次类推。这样做的目的是当存在多个Storage Group时，可以避免管理员在维护的时候把日志文件”张冠李戴”。另外，除了连续的Log文件，我们还能看到E0x.chk、Res1.log、 Res2.log等文件。
1.作为一个企业级的邮件数据库系统，必须做到数据安全和完整性的万无一失。必须能够面对随时可能发生的崩溃和宕机，What happens if we crash? 要能够把数据的损失减少到最新程度。
2.必须提供高性能的邮件吞吐能力，对数据库中的邮件的事务操做在完成后必须马上被记录到存储介质上（事务的持久性）。
3.当灾难发生时，使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态。
    现在我们更进一步的来看一下，当我要修改邮箱中的内容时，被修改的内容首先被读取出来放到内存中。实际的修改发生在内存中，当修改完成后，这些内容必须被写回存储介质，才能表示一个修改成功地完成了。
    对于这样的修改过程，在数据库级别上，我们叫做一个“事务”。我们知道，为了确保数据库的完整性和一致性，事务的操作是“原子级别”的。如果一个事务成功，那么标志着他所作的改变被永久的保存下来了；如果一个事务失败，系统必须回到事务开始之前的状态。
    当系统在内存中完成修改时，事务并没有完成。如果这个时候宕机，数据库中保存的仍然是没有更改的内容。那么，怎么样确保在内存中完成的修改能够在第一时间写入到数据库呢（以达到数据库事务持久性的要求）？注意，这里的要是第一时间，也就是越快越好。如果我们直接向edb文件写入，无法做到最快，因为，edb 文件通常都很大，I/O系统在对大的文件进行随机写入操作时，会花费大量的时间在等待磁盘查找到合适的磁道和扇区，当系统繁忙时，这将会是一个瓶颈。因此，数据库系统使用日志文件，当内存中的更改完成后，首先写入到日志文件中。日志文件的尺寸很小，写入性能要远远优于庞大的edb文件。在写入完成后，事务也随之成功的保存在存储介质上了。Exchange Server 的数据库引擎会在后台把Log文件中的内容写入到数据库中，因为此时事务操作已经完成，即使此时掉电或者宕机，也不会使完成的事务遗失。这是日志文件的第一个作用：确保事务能够在第一时间保存到非易失存储介质上。（提供持久性Durable支持）
根据上面的描述，我们知道在运行中的Exchange Server数据库，是由三部分组成的
内存中已经完成修改但是还没有写入日志文件的内容（Dirt Page）。
还没有写入到数据库文件的日志文件内容。
Edb和stm文件。
对于内存中的数据（Dirt Page），这些数据会在系统掉电或者崩溃时遗失。
Exchange Server使用了一个名为E0x.chk（Check Point）的文件记录了那些Log文件已经写入到了数据库文件。这是一个类似指针的记录。
我们可以使用命令 ESEUTIL /MK来查看这个文件chk的内容

C:\...\Exchsrvr\BIN> ESEUtil /mk “C:\...\Exchsrvr\mdbdata\e00.chk”

Microsoft(R) Exchange Server(TM) Database Utilities

Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode...

Checkpoint file: C:\program files\exchsrvr\mdbdata\e00.chk

LastFullBackupCheckpoint: (0x0,0,0)

Checkpoint: (0x8,26DA,30)

FullBackup: (0x0,0,0)

FullBackup time: 00/00/1900 00:00:00

IncBackup: (0x0,0,0)

IncBackup time: 00/00/1900 00:00:00

Signature: Create time:03/28/2004 20:26:10 Rand:6519986 Computer:

Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)

( off, 202, 10100, 1365, 10100, 128, 10240, 40828)

Operation completed successfully in 1.47 seconds.

在命令的输出中， Checkpoint: <0x8,26DA,30>表示了当前提交到数据库文件的Log完全位置。其中，0x8是Log文件的序号，一般对应于E0x00008.log,剩下的两个参数是Log文件内部页面（page）的编号。
对于一般的系统，我们总是每周或者每天进行备份，那么，在备份之后和灾难发生之前这段时间的数据如何保护？答案是日志文件。我们知道，对于数据库的任何更改，都会先被写入到日志文件，然后再由日志文件更新到数据库中。我们现在假设有这样一套系统，在每天的3:00 AM进行备份，备份完成后，系统正常运转。如果在中午12:00的时候系统出现故障，管理员用3:00AM的磁带恢复了系统，那么，从3:00AM到 12:00AM这段时间的数据，将由log文件来填补的。具体的情况是，当3:00AM的备份恢复完成后，Exchange Server会自动扫描到跟这个store相关联的日志文件夹，如果发现有比当前数据库还新的日志存在，Exchange Server会自动把这些日志按照顺序写入到数据库中。因此，从3:00AM到12:00AM这段时间对数据库所作的更改，可以被恢复回来。这是日志文件第二个重要的作用。（前提是没有开启循环日志功能）
有人可能会问，如果数据库文件和日志文件同时损坏怎么办？答案是这样的：避免这种情况发生。首先，数据库文件损坏的概率要远远大于日志文件，另外，微软推荐的做法是把数据库文件和日志文件分别放置在不同的磁盘上。我们会在下一期的文章中着重讨论这个问题。
管理员针对日志文件的抱怨是，这些文件会每天不断的增长，大量消耗硬盘空间。对于这个问题，唯一合理的解决办法是：定期的做针对Storage Group的全备份或增量备份。因为Exchange Server会在全备份或增量备份完成后把这次备份之前产生的Log文件全部删除。很多管理员手动的删除日志文件，或者启动“循环日志”来减少对硬盘空间的消耗，这都是不正确的做法。残缺不全的日志文件会使系统在进行备份恢复的时候无法还原到最近的状态。如果你的系统是一周做一次全备份，而你碰巧又在备份后删除了一些日志文件，那么你就有可能在需要恢复的时候丢失备份以后的数据。记住，数据总是比磁盘空间更宝贵。

ESE数据库引擎以及Information Store服务的启动和关闭
在ESE 引擎加载数据库文件时，它会检查数据库文件的一个特殊标志位。这个标志位保存了数据库文件上次是否被正常关闭。这个状态由“ Consistent”或“ Inconsistent”来表示。对于一个正常关闭的数据库文件，所有在Log文件和内存中的内容都应该已经提交到数据库文件中，只有在这个时候，数据库才会被标记为“ Consistent”。有一点需要注意，在运行中的数据库，它的状态一定是“ Inconsistent”，因为在Log文件中肯定还有没提交到数据库文件内容。对于一个已经关闭并且状态被标示为“ Inconsistent”的数据库，并不意味着这个数据库库文件损坏了，“ Inconsistent”只是表示，还有未曾写入到数据库文件的内容保存在Log文件中。
使用命令 ESEUTIL /MH可以查常看数据库的关闭状态。

C:\...\Exchsrvr\BIN> ESEUtil /mh “C:\...\Exchsrvr\mdbdata\priv1.edb”

Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0

Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode...

Database: C:\program files\exchsrvr\mdbdata\priv1.edb

File Type: Database

Format ulMagic: 0x89abcdef

Engine ulMagic: 0x89abcdef

Format ulVersion: 0x620,9

Engine ulVersion: 0x620,9

Created ulVersion: 0x620,9

DB Signature: Create time:03/28/2004 20:26:24 Rand:6536656 Computer:

cbDbPage: 4096

dbtime: 63139 (0-63139)

State: Clean Shutdown <-----表示数据库关闭时的状态

Log Required: 0-0

Streaming File: Yes

Shadowed: Yes

Last Objid: 574

…<略> …

Operation completed successfully in 1.391 seconds.

State字段的“Clean Shutdown”表示数据库处在Consistent状态。
当ESE 加载数据库文件时，对于“Consistent”的数据库文件，它直接Mount其中的Store；对于“In consistent”的数据库文件，ESE将执行称之为“Soft Recovery”的过程，在这个过程中，未及时提交进数据库文件的日志内容将被写入数据库。当所有的日志都写入完毕，数据库才会被标记为“ Consistent”状态，然后正常加载。
Soft Recovery开始的时候，ESE会根据check point文件所指向的位置来进行Log文件的写入(如果check point文件也损坏或者不存在，那么数据库就从最旧的Log文件开始)。当ESE从Log文件向Store写入数据时，它会根据dbTime这个时间戳来决定是否需要把Log文件写入到数据库。
在这个过程中，Event Log中会有如下的记录

Event Type: Information

Event Source: ESE98

Event Category: Logging and Recovery

Event ID: 301

Date:          10/17/2001

Time:          5:52:11 AM

User:          N/A

Computer:

Description:    Information Store (XXXX) The database engine has begun replaying logfile ..\..\E0014553.log.

我们也可以针对已经“Dis-mount”的并且是处在“Inconsistent”的数据库手工地进行“Soft Recovery”。
具体的命令是“eseutil /r”，后跟数据库文件的路径。（推荐在掉电重启以后执行此命令，可以先运行eseutil /mh确定数据库状态，如果是“Inconsistent”，再执行此命令）
由此我们可以发现，Exchange Server有能力对未正常关闭的数据库进行“自我修复”。因此，ESE确保了即使在突然掉电的情况下，数据库仍然能够处在一个可恢复的状态，并且会在重启服务以后自动完成状态检测和恢复。

M盘的来龙去脉
在Exchange Server 2000发布时，微软提出了“Web Storage System”的概念，其核心就是提供多种途径来访问Exchange Server的数据库。这些途径包括
文件系统/IFS
Http WebDAV
ExOLEDB/ ADO
CDO
其中，提供文件系统服务的IFS技术是引起争议比较多的一个模块。在安装Exchange Server 2000后，系统会出现一个M盘。这个M盘，就是由微软通过IFS（Installable File System）技术实现的一个数据库到文件系统的映射。开发人员可以通过标准的文件操作API（如CreateFile, OpenFile等）来访问Exchange Server的邮箱和邮件。
打开M盘，你可以看到一个以你当前域名命名的文件夹。在这个文件加下面，你会看到一个包含了所有邮箱的文件夹，名为MBX。MBX下面，是以用户的姓名来命名的邮箱文件夹，在每个文件夹下面，都可以看到Inbox、 Outbox等邮箱的内容。每一封信件，都是以扩展名为EML的文件来表示的。
ExIFS使用了一个名为\\.\BackOfficeStorage的特殊共享名称来指向数据库文件。你可以在命令行中运行“Dir \\.\BackOfficeStorage\domain.con\MBX”，这个命令的实行结果跟直接使用M盘作为盘符是一样的。
我们可以通过修改注册表的方式所来改变Exchange Server所映射的盘符。

HLKM\System\CurrentControlSet\Services\ExIFS\Parameters

Name: DriveLetter

Data Type: REG_SZ

Value: Drive letter for IFS (盘符，不需要跟冒号)

在更改注册表以后，需要重启Information Store Service使更改生效。
我们也可以使用如下的命令行工具来改变M盘的映射：

Subst X: \\.\BackOfficeStorage 注释：把Exchange Store映射到X盘

Subst /d M: 注释：删除对M盘的映射

如果我们移除了M盘，我们还是可以通过\\.\BackOfficeStorage这个共享名字来访问Exchange Server的数据库。
ExIFS在Windows中是作为一个隐藏的服务来运行的。下面的注册表键值定义了这个服务的参数：

HLKM\System\CurrentControlSet\Services\ExIFS\Parameters

由于这是一个隐藏的服务，因此我们没有办法通过Service控制面板来对这个服务进行控制。但是我们可以通过命令行来做到：

NET Start ExIFS 注释：启动服务

NET Stop ExIFS 注释：停止服务

下面这张图表示了ExIFS的架构。

520)this.width=520;" onclick="javascript:window.open(this.src);" src="http://www.51cto.com/files/uploadimg/20051206/1005536.gif" width="520" onload="javascript:if(this.width>520)this.width=520;" align="absMiddle" border="0" />
ExIFS是使用运行在Windows内核模式的ExIFS.sys驱动程序来实现的。
我们知道，文件系统和Exchange Server的store是两个完全不同的体系结构。文件系统中的文件只包含比较少的属性，而保存在Store中的邮件，有其特定的属性，并且，在 Store中，邮件之间还有非常复杂的关联关系（跟邮箱的关系，邮箱文件夹的视图等）。因此，M中以EML形式存在的文件（邮件），只是反映了邮件所有属性和关系的一个子集。一些对于M盘的不适当操作，往往会破坏数据库内部的关系，造成数据库损坏。比较典型的例子是，防病毒软件扫描M盘，发现“嫌疑病毒” 并予以清除。根据微软技术支持部门的统计，这是造成Exchange Server Store数据库损坏的主要原因之一。因为防病毒软件在清除病毒文件（EML文件）时，采取“野蛮施工”手段，往往会破坏数据库内部的关联和邮件结构，进而造成数据库文件内部结构的损坏。另一个针对ExIFS的错误观点是：管理员认为对M进行备份即可保存Exchange Server的状态和所有数据。这是完全不正确的。M盘只是数据库内容在文件系统上的一个映射，M中所保存的“文件”，归根结底还是数据库中保存的邮件。由于映射到M盘，数据库中的邮件关联和关系都被去掉了，备份M盘，是没有办法恢复数据库的所有信息。

Leon19821015 2006-08-16 16:55 发表评论

Exchange Server 的CDO对象集合

Leon19821015 — Tue, 15 Aug 2006 07:16:00 GMT

Exchange Server 的CDO对象集合(1)
一:关于CDO对象集合的说明
    CDO对象集合是建立协作是应用程序的可靠的API,ADO可以用来存取WEB存储系统，但是他缺少协同作业最基本的功能，而CDO却可以处理一般的应用程序和高级的工作流应用程序解决方案，CDO甚至可以提供我们管理exchange的能力，以及与windows 2000的AD通讯。
       CDO:collaboration data objects,是一项可以用来建立用途广泛的协同作业应用程序的技术，能完成如:接受传送电子邮件、日程安排、联络人管理、工作流程以及exchange管理的应用程序。CDO并不是被封装成为一个单独的对象模块，相反的，它包含了3个不同的对象模块，每一个都有其特定的用途。可以同时或者单独使用这些物件模块。
三个对象模块的DLL文件信息:
CDO FOR EXCHANGE 2000 SERVER CDO.DLL
CDO FOR EXCHANGE MANAGEMENT CDOEXM.DLL
CDO WORKFLOW FOR EXCHANGE CDOWF.DLL

二:三个对象模块的基本功能
       1. CDO for exchange 2000 server
        最常用的CDO对象模块，该物件模块包括了一些协同作业应用程序中最常见的核心组件与接口。也可以使用该对象模块来建立与设定web存储系统中的文件夹，其中最上层的cdo对象常用来建立以下几种解决方案:
    文件夹:(folder)在信箱存放区或公用存放区的容器。
    人员:(person)WEB存储系统文件夹中的联络人类型的资料，或者是AD中的使用者或联络人对象。
    邮件:(message)电子邮件
    约会:(appointment)已经安排的约会或会议
    日历信息(日程安排):(calendar message)会议邀请
    收件者:(addressee)任何形式的电子邮件收件者或会议邀请的收件者
    出席者:(attendee)包含于约会或者会议中的人员
    所有最上层的对象都有两个重要的共同接口(interface)
    Iconfiguration:用来定义可以应用于多个对象的行为模块，
    Idatasource:每个CDO对象都公开Idatasource接口，用来管理、存放与存储资料。
      2. CDO for exchange management objects
         该对象模块是用来建立以及管理exchange信箱与exchange服务器组件的类别和接口所组成。当编写用来管理exchange收件者和信箱的程序代码时，会常用到。使用的对象是:
    IMailRecipient:针对使用者指定电子邮件如何传送与管理，此对象也可以使联络人与文件夹不需要信箱便可以接收电子邮件。
    IMailboxStore:指定如何建立、移动、删除exchange信箱，以及如何管理可使用信箱的收件者其可用来管理的属性。如果开发WEB架构的服务器管理工具，该对象模块提供让我们可以整体的管理服务器的对象，这些状况可用的最上层的对象有:
    ExchangeServer:管理exchange2000服务器与传回基本信息，如服务器类型与版本。
    FolderTree:管理服务其中的文件夹树状结构，包含任何副本。
    StorageGroup:管理储存群组，用来组织信箱存放区和公用存放区。
    MailboxStoreDB:管理单一使用者的信箱存放区可以使用此对象来连接、移动或中断连接信箱存放区，并传回有关存放区数据库的基本信息。
    PublicStoreDB:建立、管理与删除公用存放区，并传回有关存放区数据库的基本信息。
       3. CDO Workflow for Exchange
          该对象模块是由用来建立以及执行工作流程与路由应用程序的类别和接口所组成。建立工作流应用程序有两种方式:
    方式一:使用Workflow designer for Microsoft Exchange 2000 Server
    方式二:使用自行建立工作流程事件流程与事件接受的方式。
    我们使用前者，使用WorkFlow Designer我们就不需要大部分的工作流程对象，只有当编写回应各式各样工作流程动作的Script时，才需要使用这些对象，在我们的Script中最可能用到的对象如下:
    IWorkflowSession:提供工作流程引擎、动作的Script与所处理的工作流程项目(ProcessInstance)之间的执行期(run-time)通讯。
    IworkflowMessage:建立工作流程处理中要传送给收件者的通知邮件。
    AuditTrailEventLog:于应用程序记录档(log)中,建立有关工作流程事件动态的项目(entries)。
    如果使用Workflow Designer无法提供完成要设计的功能，那就要自行建立事件接受，如果自行建立事件接受还需要熟悉下列对象:
    ProcessDefinition:定义工作流程中的逻辑，包含状态与动作。
    ProcessInstance:控制、记录与监视移动于工作流程处理之间、个别独立的工作流程项目的状态。
三:开始使用CDO
        1. 由类别建立对象
     CDO由多种COM的类别所组成，是用来建立新对象的基础，当一个对象被建立的时候，这些类别会决定对象标准的预设功能。如:CDO的message类别是用来定义新的Message对象，每个Message对象都有相同的标准功能，允许对象被传送与接受。使用VB创建一个Message对象的例子:
     dim msg as cdo.message
     set msg=new cdo.message
使用Vbcript创建一个message对象:
     dim msg
     set msg=server.createobject(“cdo.message”)
这样我们就可以存取此类别预设接口中的属性与方法，以及任何该类别公开的其它接口。使用完对象变量之后应该释放对象变量占有的内存:set msg=nothing
        2. 使用介面(接口)
           界面定义了一个由属性和方法封装在一起的集合。类别通常有多个与其相关联的介面，包含一个预设(default)的介面，此预设介面拥有类别既定的预设功能。预设介面与该对象呈现的名称相似，只是在对象名称前多了一个字母I,表示这是一个相对于类别对象的介面，如person类别有一个管理所有属性与方法的 IPerson介面，特别用来定义与管理联络人类型的信息。这个预设的介面是由其所属对象直接公开，也就是我们可以由对象直接呼叫属性和方法。我们可以直接调用Person对象的e-mail属性，程序代码如下:
      dim prs as cdo.person
      set prs=new cdo.person
      prs.email=someone@domain.com

除了默认介面以外，大部分的类别至少使用一个以上的其他介面，这些预设介面也会被其他类别所使用。参照介面以后才能够存取其属性和方法，可以轻易的经由调用相关属性来实现。如;Idatasource介面经由Datasource被存取，代码如下;(VB)

dim dsrc as Idatasource

set dsrc = prs.datasource

VB:dim fld as cdo.folder

Dim rcp as cdoexm.imailrecipient

Set rcp=fld

Vbscript,不能为变量预先设定数据类型，必须使用getinterface方法存取介面，几乎每个CDO对象都公开用以存取介面的GetInterface方法，范例如下:

Set rcp = fld.getinterface(“imailrecipient”)

Exchange Server 的CDO对象集合(2)
四:存取结构描述属性

ADO需要使用fields对象集合才能存取结构描述属性，而CDO提供一种更简单的方式，许多比较一般的结构描述属性都可经由CDO属性来存取。如:我们可以存取Person对象中的urn:schema:contacts:HomePhone结构描述属性，代码如下:

prs.HomePhone=”555-555-0101”

对结构描述属性而言并没有相等的CDO属性，必须使用adofields对象集合，它具有相同的属性与方法。要存取对象集合中的特定属性，就要传送完整并且合格的结构描述属性名称，若有相同的CDO相关常数(constant)也要一起传递，这些常数以cdo开头且包含于CDO函数库中，可以使用这些常数以省去传送完整属性名称的麻烦，使用CDO常数来传送时，其名称并不需要加上引号，如下例存取urn: schemas:contacts:FTPSite的属性:

prs.fields(cdoFtpSite)=”somearchive.edu”

如果要存取的结构描述属性没有可用的CDO属性或常数，就必须传递完整且合格的结构描述属性名称给Fields对象集合。下面的例子和上面的程序代码效果相同:

prs.fields(urn:schemas:contacts:ftpsite)=”somearchive.edu”

为了使程序更容易读懂，当程序中使用的属性不存在CDO属性或没有建立结构描述常数，我们应该为应用程序定义自己的常数。

五:使用URL

与ADO一样，CDO也是依赖于URL以及ExOLEDB provider来存取Web存储系统中的资源，所要被存取的资源必须以完整的文件夹路径与显示名称(displayname)建构正确的URL地址，如果文件夹路径或项目的显示名称中有空格字符，那在URL中也必须保留名称中的任何空格字符。

CDO也支持相对的URL用法.

六:了解并使用Idatasource介面

IDataSource介面是使用CDO存取WEB存储系统中资源的关键，所有的CDO对象经由DataSource属性公开IDataSource介面，DataSource属性可以用来在WEB存储系统中开启资源、侦测与储存资源的变更，以及建立新资源。

IDataSource介面的属性与方法，下面是IDataSource介面公开的属性和方法

七:IDataSource介面的运作

使用CDO开启一个资源时，并非动态的连线到WEB存储系统，而是将资料由WEB存储系统中复制一个副本到本机的 CDO对象，所以实质上您会有两份资料，一份再WEB存储系统中，另一份再CDO对象中，使用CDO对象的属性方法对资料所作的任何改变都是本机上的资料副本，而不是WEB存储系统中的资料，直到使用IDataSource的储存方法明确地指定要对资料作变更WEB存储系统中的资料才会被变更。如不调用一个储存方法，则变更的资料副本就会丢失。

建立一个新的资源也是同样的道理。

八:使用CDO开启一项资源

使用CDO对象中的DataSource.Open方法，它是以record.open方法为基础的开启资源的方法。CDO使用的open方法语法如下:

open ( source url as string [,activeconnection as object] [，mode as connectmodeenum指定record如何被开启])默认以只读方式打开。

判断资料来源是否在本机被修改过:IDataSource介面的datasource.isdirty属性(boolean值)

可以使用该属性判断本机的CDO对象是否被变更，如果变更，则使用datasource.save方法保存变更。

九:使用CDO建立新资源

先为新资源建立一个URL,再将新资源的相关信息存储到该URL,datasource.saveto方法可以让您指定所建立资源的URL,URL必须是资源的精确的实际位置，还必须包含资源的DAV:displayname.

Datasource.saveto方法的语法:

Saveto(sourceurl as string [,activeconnevtion as object] [,mode as connectmodeenum] [,createoptions as recordcreateoptionsenum])

Mode,指定record如何被开启

Createoptions,指定资源如何被建立，adcreateoverwrite将会覆盖已经在URL上存在的相同名称的资源项目,如果不设这个常数，则如果URL已经存在此资源的话，将会返回一个错误。

Datasource.savetocontainer方法语法，该方法语法和saveto方法相同

两者的区别:saveto方法是具体知名资源项目的URL和DAV:displayname,然后将资源项目存放到指定的URL,名称为指定的DAV:displayname,而savetocontainer方法则是将资源存放到指定的URL,资源的DAV: displayname时exchange自动产生的一个名称。

该方法的用途:savetrocontainer方法在日程安排、建立约会时用得比较多，因为日程安排项目很多，时常有同名的约会名称，我们可能会将前面已经建立的越会覆盖掉，为了防止这样的事情发生，我们应该采用savetocontainer方法。

十:使用其他对象开启CDO对象

可以使用datasource.openobject方法由其他记忆体中的对象打开CDO对象，而记忆体中的对象可以是其他CDO对象或是其他函数库的对象，比如ADO2.5

openobject方法的语法如下:

openobject(soure as Unknown, InterfaceName as String)

Source:被要打开的对象所参照的已打开对象，例如一个ado record或一个已开启的电子邮件，通常是一个对象变量

InterfaceName:source所公开的介面名称字串，例如，假使source是电子邮件的bodypart对象，则InterfaceName就是BodyPart,这个参数区分大小写。

为什么会使用该方法:

当我们已经使用recordset对象来浏览WEB存储系统的时候，可能使用Connection对象执行SQL 查询来筛选所需要的项目，有或是批次的建立新项目，但是可能需要使用CDO来设定对象指定的属性，如果要修改使用openobject方法开启的CDO对象，需要使用DataSource.savetoobject方法将变更储存回parent对象，储存时传递openobject方法相同的参数给 savetoobject方法。

检查文件夹或项目是否存在:

使用ADO record的open方法，打开欲检查的URL,若成功打开，说明此URL已经有相同的资源，若不能打开，则说明资源或项目不存在

十一:使用CDO建立文件夹

使用CDO建立新的文件夹的时候，要建立新的CDO Folder物件，然后设定您希望其运作方式的相关属性，假如知道你要设定文件夹保存特定形态的项目，便要设定ContentClass属性为其中一个事先定义的内容类别，若要文件夹也可以被MAPI的用户端所使用，则要设定http: //schemas.microsoft.com/exchange/outlookfolderclass属性，假如有调用fields集合对象来设定属性，要先调用update方法，再使用saveto方法保存。

如果要删除一个文件夹或项目需要调用record的deletereocrd方法。

十二:使用文件夹接收电子邮件

当一个文件夹被建立时，预设并不能通过SMTP接受邮件，必须要明确地开启文件夹来接受电子邮件，CDO的IMailRecipient介面的MailEnable方法可以达到这个目的，exchange会自动指定一个电子邮件地址给文件夹.

如果在建立文件夹的同时就要开启文件夹接收电子邮件的功能的话，要先储存刚刚创建的文件夹，然后再调用MailEnable方法，如果使用已存在的文件夹，则不需要再将其存储一遍。

例程:

set fl=createobject(“cdo.folder”)

url=file://./backofficestorage/oaserver.exchange/

set rcp=fl.getinterface(“IMailRecipient”)

fl.datasource.save

set fl=nothing set rcp=nothing

计算文件夹中的内容:

使用ADO计算文件夹中的资源的时候，必须要浏览整个文件夹，这种方式忽视资源的内容是项目还是文件夹，而且当资源数量庞大时，会给服务器带来相当大的负荷

使用CDO可以避免程序中有不明确的状况发生，以及造成服务器负载过重，Folder对象提供三种计算文件夹内容的属性:

ItemCount:该属性计算文件夹中所有不包含子文件夹的项目的数量。

Unread ItemCount:该属性只计算未被标记为已读取的项目数量。

VisableCount:该属性只计算那些使用者可见并可存取的项目，忽略可能存储于文件夹中的系统隐藏项目。

Leon19821015 2006-08-15 15:16 发表评论

Exchange 2003中使用的端口

Leon19821015 — Tue, 15 Aug 2006 04:45:00 GMT

摘要: 服务（相关项目） ... 阅读全文

Leon19821015 2006-08-15 12:45 发表评论

保护Exchange免受缓冲溢出攻击

Leon19821015 — Tue, 15 Aug 2006 03:50:00 GMT

        大多数重要的补丁都是为系统防止缓冲溢出而设计的。在像做这样的设计时主要考虑是，一个攻击者可以使用一个恶意的代码片断作为执行他/她自己的代码的基础。这里有很多种缓冲溢出攻击的类型，但是他们都是基于恶意代码编写或者利用那些原来开发的代码编程语言上的漏洞。那些用C写的程序是最容易受到缓冲溢出攻击的，因为C程序产生运行时间错误，并且在大多数被使用的C资料库没有被缺省设计为在执行时作错误检查（这一点正在改变）。如果你能够保证你的输入是正确的，那么没有运行错误检查是好的做法。但是，黑客们已经发现当一个没有检查溢出C程序相应用户输入时，在程序执行失败时，可能会进入一个包括执行代码异常长的队列。这就是为什么我告诉你大多数的视窗操作系统和一些视窗服务器系统产品是用C写成的。
        两种最主要的缓存溢出攻击类型是堆栈攻击和堆攻击。堆栈攻击是最常用的，因为它们是最容易被执行的。一个基于堆栈的缓冲运行工作是因为程序使用内存对象作为一个堆栈来存储用户输入。通常，在程序请求用户输入之前，堆栈会被清空。在这一点，程序写出一个返回内存地址到堆栈，然后用户的输入被放置到堆栈的顶端。当堆栈被处理时，用户的输入获得发送到指定的返回地址。可是一个堆栈不具有无限制的大小。程序员编码一定要为堆栈预制指定的大小数量。如果用户的输入比喻预制指定的数量长，堆栈就会溢出。对于堆栈本身来说，溢出并不是什么大问题，但是当遇到恶意输入时，就会变成一个巨大的安全漏洞。
        假设举一个例子，一个程序希望用户输入他/她的名字。相比输入名字，黑客更愿意输入一个超过堆栈大小的可执行指令。这个指令通常都很简短。比如说，在Linux环境中指令通常是要求系统打开一个即时指令窗口（就像大家都知道的循环Linux 的root内核）。然而，一个可执行指令的缓冲溢出不是指指令要被执行。过程的另一方面是，攻击者必须指定一个返回地址指向恶意的指令。因此，程序损坏的一部分原因是因为堆栈溢出。程序试图去修复将要用到的返回地址，但是返回地址的指向已经被黑客改成了指到黑客制定的指令。意思就是黑客一定要知道恶意指令将要存放的位置。为了知道准确的地址，恶意指令常常被在NOP指示下的两部分填补。如果黑客指定的地址被填充，恶意指令将会被执行。
        最后一个部分是可执行程序的许可权限。众所周知，大多数流行的操作系统都有一些机制来控制用户的登录访问级别。可执行程序的典型要求是比普通的登陆的许可权限级别更高，因此运行在内核模式或者许可权限继承自服务账户。当一个堆栈溢出攻击运行指令在一个新的返回地址时，程序认为它一直在运行。这就意味着被打开的命令提示窗口正在运行相同的一批许可命令，作为危及安全的应用。通常讲，这个的意思就是攻击者将会获得对操作系统的所有控制。

保护自己的技巧
          那么，怎样能够保护你免受这一类的攻击呢？最容易和最紧急的技巧是保证你的操作系统，Exchange服务器和其他运行在服务器上的程序及时更新。这样将修复潜在的缓存溢出使用。
         另一个技巧是你谨慎地使用运行在其上的特殊应用软件。我曾看到过许多人使用域管理员账户作为服务账户。这样问题就会出现：如果服务被不正常的使用，这样黑客就会访问到你的整个域。最好运行服务作为本地系统。然而如果一个服务必须需要用一个用户帐号作为服务账号，用一个本地用户账号就比用一个域账号好。另一方面，如果服务被危及安全，那么攻击者将被限制到控制那一个服务器而不是整个的域的机器。
         你可用的最后一个技巧是用一个应用代理，在应用代理之后的方法是站在用户和应用之间并且过滤用户的输入，在字符串层和协议层来确定用户的输入是有效的。不幸的是你不可能去计算机里面为Exchange服务器存储并且购买一个应用代理。但是当正确配置的时候，在前端处理/后端处理配置中运行Exchange 能够达到作为一个应用代理的同样的目的。
         另外一个应用代理的例子是一个工具，叫做URLscan，虽然你不能完全理解，但是你可以从Microsoft的Web站点下载这个工具。这个工具可以监控进入你的IIS服务器（IIS是Exchange需要的）中去的请求，来确保请求不会过长并且请求中不包含恶意代码。

Leon19821015 2006-08-15 11:50 发表评论

Exchange2003SP1与坏邮件

Leon19821015 — Tue, 15 Aug 2006 03:24:00 GMT

在Exchange里的BADMAIL文件夹是用来存放那些不能成功交付的消息或者那些没有交付报告（NDRs）的消息。在UNIX的电子邮件体系里，这是大概和废弃的信件文件一样。
Exchange 2003 Service Pack 1改变了这种行为。在对接受用户的关于BADMAIL文件夹占用过多的服务器空间的反馈的很好的处理之后BADMAIL的缺省行为被改变。一旦Service Pack 1被应用，NDRs以及和它类似的消息都不会被写入BADMAIL；它们完全消失了。对那些大部分从来不为BADMAIL而费心的管理员来说，这是一个福音；他们可以清除这个文件夹并且忘掉它。如果要开启以前BADMAIL报告需要在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ SMTPSVC\Queuing里编辑一个DWORD设置。MaxBadMailFolderSize，要增加或改变的这个值是最大值，用千字节表示分配给每个BADMAIL文件夹。一旦这个空间数量被用在一个BADMAIL文件夹，消息就将不会被写入BADMAIL文件夹中。设置这个值为-1（小数）允许一个无限的文件夹值（也就是SP1之前的行为）。设置这个值为0（在SP1里缺省的）将根本不能写入到这个文件夹。注意新的消息不会删除就的那一个；一旦达到文件夹的值，将不会有新的消息写入。

Leon19821015 2006-08-15 11:24 发表评论

在2000域环境下新做一台2003DC

Leon19821015 — Mon, 14 Aug 2006 06:16:00 GMT

       公司的域控比较旧，昨天新买来了一台服务器给HR做HR System,所以拿来做了BDC,准备以后把exchange2000迁移到2003DC的exchange2003.
       1.新装一台2003server+sp1
       2.cdrom:\i386\adprep /forestprep 和cdrom:\i386\adprep /domain prep
       3.把2003加入域并且dcpromo为BDC,安装DNS Server

      DNS服务器是后装的，现在想想在dcpromo前装但不配置，等提升的时候自动复制应该好些

Leon19821015 2006-08-14 14:16 发表评论

分离DC2000和Exchange2000

Leon19821015 — Fri, 11 Aug 2006 03:55:00 GMT

环境:DC2000+Exchange2000在一台服务器上（A）,全新服务器（B）
需求:分离DC和Exchange
步骤:1.在B上建立额外域，GC
2.在A上执行dcpromo降级，会自动把A的5种主机角色传递给B
3.执行netdom query fsmo检查FSMO角色
结果:A为成员服务器及Exchange2000.B为DC

Leon19821015 2006-08-11 11:55 发表评论