邮件服务器问题之邮件积压、传递延迟解决

症状描述:
邮件服务器A和邮件服务器B,作前后端设置,前端接收邮件后,投递给后端服务器内的邮箱,当前前端接收外部邮件后,无法投递给后端邮箱,导致邮件积压在前端服务器,内部邮件传递需要延迟25分钟左右到达。

邮件服务器故障症状描述:

最早是一台ip为192.168.0.1下称a)的服务器做单独的dc,一个单dc域环境,在防火墙netscreen)做nat,这个dc又作为外部mailex2k)服务器,后来又添置两台ibm服务器,做了另外两个dc,ip分别是
192.168.0.6作为代理服务器ISA,下称b),192.168.0.10作为邮件服务器ex2k,下称c),全局编录gc是a
192.168.0.1),pdc,rid,基础结构都是a,后来我想把a降级,停用,把全局编录,pdc,rid,基础结构服务器都设置成b,重启服务器以后,把a从网络中移开,发现客户端登陆域非常慢后来发现是某些客户端的网关指向a,更改即可),并且outlook登陆ex2k无法通过,提示找不到exchange服务器。服务器上总共出现三个典型一点的错误日志,分别是event
id:9176,5778和36872,后两种的内容如下:
事件类型: 警告
事件来源: Schannel
事件类别目录: 无
事件识别码: 36872
日期: 2003/8/14
时间: 下午 07:19:58
使用者: 不适用
计算机: b
描述:
这个系统不存在适合的预设服务器认证。这样会防止
预期利用系统预设认证的服务器应用程序接受 SSL 联机。
目录服务器就是这样的一个例子。管理自己认证的应用程序, 例如 internet
信息服务器不受这个影响。
事件类型: 信息
事件来源: NETLOGON
事件类别目录: 无
事件识别码: 5778
日期: 2003/8/14
时间: 下午 07:14:28
使用者: 不适用
计算机: b
描述:
ƉRD01′ 尝试借着寻找 IP 地址 (192.168.0.131) 来判定它 在 DS
Configuration\Sites\Subnets 容器中的站台。找不到和 这个 IP
地址相符的子网络。请考虑为这个 IP 地址新增一个子网络对象。
我找了9176的解决办法,微软称:
XADM:错误消息:Network Problems Are Preventing Connection to the
Microsoft Exchange Server Computer
这篇文章中的信息适用于:
· Microsoft Exchange 2000 Server
症状
重建全局编录服务器后,MAPI 客户端如 Microsoft Outlook)无法连接到
Exchange 2000 Server 计算机。Outlook 客户端可能收到下列错误消息之一:
The name could not be resolved.Network problems are preventing
connection to
the Microsoft Exchange Server Computer.Contact your system administrator
if
this condition persists.
Unable to expand the folder.The set of folders could not be opened.The
information store could not be opened.
您或许能够使用 Internet 消息访问协议版本 4rev1 (IMAP4) 和邮局协议版本 3
(POP3) 访问邮箱。
在 Exchange 2000 Server 的应用程序日志中,可能记录下列事件:
Event Type: Error
Event Source: MSExchangeSA
Event Category: (11)
Event ID: 9176
Date: 9/30/2000
Time: 9:58:21 AM
User: N/A
Computer: EXCHANGESRVR
Description:NSPI Proxy can contact Global Catalog GCName but it does not
support
the NSPI service.After a Domain Controller is promoted to a Global
Catalog, the
Global Catalog must be rebooted to support MAPI Clients.Reboot GCName as
soon as possible.
For more information, click
.
如果您重新启动全局编录服务器,并不能修复该问题。在该问题发生前连接到该服务器的
Outlook 2000
和更高版本的客户端仍然可以连接。然而,新的客户端连接尝试不会成功。出现该行为的原因在于由智能客户端功能和目录服务检索RFR
接口)生成的缓存值。
原因
出现该问题的原因在于名称服务提供程序接口 (NSPI)
不是由全局编录服务器公布的。
解决方案
该问题在 Windows 2000 Service Pack 3 (SP3) 中得到修复。
替代方法
要解决该问题,请将域控制器从全局编录服务器身份降级,重新启动全局编录服务器,然后将该域控制器再次升级为全局编录服务器。
备注:有关将 Windows 2000 域控制器升级为全局编录服务器的信息,请参阅
Windows 2000 Server 联机帮助。
在该域控制器报告它再次作为全局编录服务器成功公布通过在目录服务事件日志中记录事件
ID 1119)之后,请重新启动该服务器以公布 NSP 接口。
停止然后重新启动 Exchange 服务,或重新启动 Exchange Server
计算机。Exchange Server 现在应该能够连接到全局编录服务器。
更多信息
有关目录服务检索的其他信息,请单击下面的文章编号,以查看 Microsoft
知识库中相应的文章:
256976 XCLN:How MAPI Clients Access Active DirectoryMAPI 客户端如何访问
Active Directory)
302914 XCCC:How Outlook 2000 Accesses Active DirectoryOutlook 2000
如何访问 Active Directory)
有关在将 Windows 2000 域控制器升级为全局编录服务器时 Exchange 2000
的相关注意事项,以及有关如何使用全局编录 Partition Occupancy
注册表值指示全局编录升级进程,在公布自身之前,完成所有名称上下文的完整复制的其他信息,请单击下面的文章编号,以查看
Microsoft 知识库中相应的文章:
304403 XADM:Exchange Considerations for Promoting a Domain Controller
to a Global Catalog
Server将域控制器升级为全局编录服务器时 Exchange 的相关注意事项)

后来,在Friday哥哥得教导之下,知道迁移gc关键是要让新旧势力共存2个小时左右,于是又找了一天下午免费加班测试,
以前是将a的身份降下来,然后立即停掉后,所有客户端的outlook登陆时无法通过exchange2k验证,昨天我测试将a这台GC降级,将GC身份转移到b这台dc上面(包括操作主机,pdc,rid,基础结构).让2台dc并行2个小时左右,让原gc的信息充分复制到新的gc上面,发现以前的
outlook登陆exchange2k验证出错问题不存在了,但是可能是由于dns出错,所有用户不能浏览internet(包括server),a上出现event,id是1265,并且每十五分钟会出现一次.
事件類型: 警告
事件來源: NTDS KCC
事件類別目錄: 知識一致性檢查程式
事件識別碼: 1265
日期: 2003/8/18
時間: 18:46:31
使用者: 不適用
電腦: A
描述:
嘗試建立一個含有下列參數的複寫連結:
磁碟分割: CN=Schema,CN=Configuration,DC=gsmc,DC=com,DC=cn
來源 DSA DN: CN=NTDS Settings,CN=MAILSRV,CN=Servers,CN=gsmc,CN=Sites,
CN=Configuration,DC=gsmc,DC=com,DC=cn
來源 DSA 位址:
50231c98-b38f-459b-af50-bc9c6e1d1ed8._msdcs.gsmc.com.cn
站台間傳輸 (如果有的話): CN=IP,CN=Inter-Site
Transports,CN=Sites,CN=Configuration,DC=gsmc,DC=com,DC=cn
但這操作失敗,下列為失敗的狀態:
DSA 操作無法繼續,因為 DNS 對應失敗。
記錄資料是狀態碼。將會再重試這個操作。
資料:
0000: 4c 21 00 00 L!..
我查询相关资料,发现:
As per Microsoft: “If this error is being reported for Active
Directory
replication between two domain controllers of different domains which
have
a parent/child or tree root trust relationship, this error may be due to
an
absent critical object that represents the trust relationship between
the two domains.”
Status: “The DSA operation is unable to proceed because of a DNS lookup
failure.” See Q319202,
this issue occurs because the DNS Database does not have a service (SRV)
resource record for the
domain controller.
而微软的相关KB提示如下:
SYMPTOMS
When you try to replicate changes between replica partners in Active
Directory directory service
Sites and Services, you may receive the following error message:
The following error occurred during the attempt to synchronize the
domain controllers.
The naming context is in the process of being removed or is not
replicated from the specified server.
An event ID message that is similar to the following may also be logged
in the System event log:
Event ID: 1265
Source: NTDS KCC
Type: Warning
Category: Knowledge Consistency
The attempt to establish a replication link with parameters
Partition: DC=yourinfo,DC=yourinfo,DC=yourinfo,DC=com Source DSA DN:
CN=NTDS
Settings,CN=NT5-PCI-20,CN=Servers,CN=GSCIntranet,CN=Sites,CN=Configuration,DC=child,DC=yourdomain,DC=com
Source DSA Address:
YourDomainController. YourDomain.com
Inter-site Transport (if any):
failed with the following status:
The DSA operation is unable to proceed because of a DNS lookup failure.
The record data
is the status code. This operation will be retried. CAUSE
This issue occurs because the DNS Database does not have a service (SRV)
resource record
for the YourDomainController.YourDomain.com domain controller.
RESOLUTION
To resolve this issue, follow these steps:

通过察看前后端服务器的各类服务,发现所有服务均正常,由于无法投递给后端服务器,所以首先判断可能是后端服务器出现了问题,决定重启动。

邮件服务器A和邮件服务器B,作前后端设置,前端接收邮件后,投递给后端服务器内的邮箱,当前前端接收外部邮件后,无法投递给后端邮箱,导致邮件积压在前端服务器,内部邮件传递需要延迟25分钟左右到达。
 
通过察看前后端服务器的各类服务,发现所有服务均正常,由于无法投递给后端服务器,所以首先判断可能是后端服务器出现了问题,决定重启动。
 
重启动耗时4分钟,这时候察看前端队列,发现已经正常投递给后端服务器,认为问题解决,可能是意外原因导致后端服务器服务不正常。
 
但是经过5分钟的观察,发现,问题仍然存在,外部投递邮件仍然积压在前端服务器上,于是又深层次查找问题,发现如下症状
在Message Submitted to Advanced Queuing 和 Started Message Submission to
Advanced Queue两步用时超过10分钟,在Message Submitted to Categorizer
和Message Categorized and Queued for Routing
之间历时接近10分钟,根据这个线索,查找资料,得到如下类似症状
 

  1. Ping the Domain Controller. To do so, type
    YourDomainController.YourDomain.com at the
    command prompt, and then press ENTER.
    If you receive a reply that the ping request could not find the host,
    the domain controller’s
    SRV record is not populated in the DNS Database.
  2. Check the configuration of DNS and make sure that Allow Dynamic
    Updates is enabled.
    To do this, follow these steps:
  3. Click Start, point to Programs, click Administrative Tools, and then
    click DNS.
  4. Expand the DNS folder.
  5. Expand the Forward Lookup Zones folder.
  6. Right-click the folder, and then click Properties.
  7. In the Allow Dynamic Updates box, click Yes.
  8. Click OK.
  9. Stop and then restart DNS.
  10. Stop and then restart the Netlogon service on YourDomainController.
    By doing this, you force the domain controller to register the
    appropriate SRV records. The
    change is then replicated to DNS.
    STATUS
    Microsoft has confirmed this to be a problem in Microsoft Windows
  11. 我检查a的dns-Forward Lookup
    Zones-Properties,已经是支持动态更新的了,并且我也重启了dns和netlogon服务.但是这个错误event还是每隔十五分钟出现一次.
    后来昨天终于发现一些问题了,大家注意事件1265里面得那个: CN
    =MAILSRV,话说这个mailsrv可有来头,是我来之前那个水货网管建立得一个测试服务器,最早是做单独得dc来用得.然后我到ad站点和域控制台一看,果不其然,有一个site,里面含有两台dc:mailsrv和mailserver.这两台dc现在根本就没有用到了.于是我点击右键删除之….结果提示:无法删除ads组件,狂晕一阵,然后到M$网站找到方法了,装win2k
    tools,然后用adsi修改,删除里面多余得dc,这样问题解决了,event里面再也没有出现错误提示了.
    现在我又开始进行我得初衷:将a彻底得从我得dc群组里面消失掉,发现一旦停掉a,普通用户还是会有那个无法找到exchange得错误.这个时候俺已经豁出去了,深呼吸一下,开始找一些问题点.突然发现在建立用户得时候要选择一个ex得母服务器,难不成是这个原因??于是,我新建一个用户,选择ex服务器是b,关掉a,测试———各位观众,ok了…一切正常了,那么原来选择exa得用户我可以用exchage
    tasks得move
    mailbox迁移邮箱到b.这样把a干掉.于是我手起刀落.唰…这个世界安静了……..
    综上所述:问题一共有这几个:gc,操作主机迁移造成dns错误提示,解决办法:删除作废得或者退位得dc.(需要安装windows2000
    surport tools利用里面得adsi edit)
    Ex2k迁移造成outlook登陆解析名称错误,解决办法:利用ex得tsks里面得move
    mailbox方法迁移邮箱.

重启动耗时4分钟,这时候察看前端队列,发现已经正常投递给后端服务器,认为问题解决,可能是意外原因导致后端服务器服务不正常。

由于全局编录服务器问题而导致邮件传递出现延迟
全局编录问题可能导致邮件传递出现延迟。在这种情况下,会生成 NDR
以通知发件人这一延迟。可以使用邮件跟踪中心来诊断这些问题。下面的示例显示了从邮件跟踪中心所收集到的数据:
6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01
6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store
6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through
SMTP
6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through
SMTP
6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to
Store
在上面的示例中,应注意到邮件在邮件分类程序中延迟了 30
分钟,之后才开始进行出站传输,并且最终被送达。在这些情况下,应通过运行
Nltest 工具来确定 Exchange
使用哪一台全局编录服务器。具体步骤在本主题前面的“通过使用移动邮箱工具将收件人移到
Active
Directory”中已说明。然后,调查所涉及到的全局编录服务器。下面是全局编录服务器的常见问题:
• 全局编录服务器超载或工作过度。
• 全局编录服务器出现性能问题。
• 内存不足。
www.hj8828.com,• 硬盘空间不足。
• Exchange 2000 与全局编录服务器之间出现暂时性的网络问题。
• 使用同一个全局编录服务器的 Exchange 服务器过多推荐的 Exchange
处理器与全局编录服务器处理器的比率是四比一)。

但是经过5分钟的观察,发现,问题仍然存在,外部投递邮件仍然积压在前端服务器上,于是又深层次查找问题,发现如下症状
在Message Submitted to Advanced Queuing 和 Started Message Submission to
Advanced Queue两步用时超过10分钟,在Message Submitted to Categorizer
和Message Categorized and Queued for Routing
之间历时接近10分钟,根据这个线索,查找资料,得到如下类似症状

要点:

邮件跟踪日志可能会起到一种误导作用。例如,如果全局编录服务器正常工作,并且邮件分类程序也正常工作,但是远程
SMTP
服务器不可用达三十分钟,则邮件跟踪日志可能与上面显示的示例日志类似。此外,如果邮件必须在本地传递,并且
Exchange
存储执行速度很慢,则邮件跟踪日志将显示出“邮件已提交到邮件分类程序”与“邮件已传递到本地存储”之间存在很大的时间差异。
重现问题时,应从全局编录服务器中使用系统监视器日志。这有助于您诊断这些问题。再次使用全局编录服务器可以解决这些问题。要解决这些问题,可以为每一台
Exchange 服务器指定一台全局编录服务器。 

由于全局编录服务器问题而导致邮件传递出现延迟
全局编录问题可能导致邮件传递出现延迟。在这种情况下,会生成 NDR
以通知发件人这一延迟。可以使用邮件跟踪中心来诊断这些问题。下面的示例显示了从邮件跟踪中心所收集到的数据:
6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01
6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store
6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through
SMTP
6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing
6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue
6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer
6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message
6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through
SMTP
6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to
Store
在上面的示例中,应注意到邮件在邮件分类程序中延迟了 30
分钟,之后才开始进行出站传输,并且最终被送达。在这些情况下,应通过运行
Nltest 工具来确定 Exchange
使用哪一台全局编录服务器。具体步骤在本主题前面的“通过使用移动邮箱工具将收件人移到
Active
Directory”中已说明。然后,调查所涉及到的全局编录服务器。下面是全局编录服务器的常见问题:
• 全局编录服务器超载或工作过度。
• 全局编录服务器出现性能问题。
• 内存不足。
• 硬盘空间不足。
• Exchange 2000 与全局编录服务器之间出现暂时性的网络问题。
• 使用同一个全局编录服务器的 Exchange 服务器过多推荐的 Exchange
处理器与全局编录服务器处理器的比率是四比一)。

注意:

要点:
邮件跟踪日志可能会起到一种误导作用。例如,如果全局编录服务器正常工作,并且邮件分类程序也正常工作,但是远程
SMTP
服务器不可用达三十分钟,则邮件跟踪日志可能与上面显示的示例日志类似。此外,如果邮件必须在本地传递,并且
Exchange
存储执行速度很慢,则邮件跟踪日志将显示出“邮件已提交到邮件分类程序”与“邮件已传递到本地存储”之间存在很大的时间差异。
重现问题时,应从全局编录服务器中使用系统监视器日志。这有助于您诊断这些问题。再次使用全局编录服务器可以解决这些问题。要解决这些问题,可以为每一台
Exchange 服务器指定一台全局编录服务器。
注意:
建议只有在要排除故障时才手动配置全局编录服务器。手动配置了全局编录服务器后,如果某个服务器不可用,Exchange
将无法检测到。
有关详细信息,请参阅如何指定全局编录服务器。
有关 DSAccess 的其他信息,请参阅 Microsoft 知识库中编号为 250570
的文章:“XCON: Directory Service Server Detection and DSAccess
Usage”。
ExchOwningPFTreeBL: CN=Public Information Store (PFREP55),CN=First
Storage
Group,CN=InformationStore,CN=PFREP55,CN=Servers,CN=FourthCoffee,CN=Administrative
Groups,CN=Lake District,CN=Microsoft
Exchange,CN=Services,CN=Configuration, DC=
cumbria,DC=extest,DC=microsoft, DC=com;
CN=Public Folder Store (PFREP57),CN=First Storage
Group,CN=InformationStore,
CN=PFREP57,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake
District,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;
CN=Public Information Store (PFREP56),CN=First Storage
Group,CN=InformationStore,CN=PFREP56,CN=Servers,CN=Coniston,CN=Administrative
Groups,CN=Lake District,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;

建议只有在要排除故障时才手动配置全局编录服务器。手动配置了全局编录服务器后,如果某个服务器不可用,Exchange
将无法检测到。
有关详细信息,请参阅如何指定全局编录服务器。
有关 DSAccess 的其他信息,请参阅 Microsoft 知识库中编号为 250570
的文章:“XCON: Directory Service Server Detection and DSAccess
Usage”。
ExchOwningPFTreeBL: CN=Public Information Store (PFREP55),CN=First
Storage
Group,CN=InformationStore,CN=PFREP55,CN=Servers,CN=FourthCoffee,CN=Administrative
Groups,CN=Lake District,CN=Microsoft
Exchange,CN=Services,CN=Configuration, DC=
cumbria,DC=extest,DC=microsoft, DC=com;
CN=Public Folder Store (PFREP57),CN=First Storage
Group,CN=InformationStore,
CN=PFREP57,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake
District,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;
CN=Public Information Store (PFREP56),CN=First Storage
Group,CN=InformationStore,CN=PFREP56,CN=Servers,CN=Coniston,CN=Administrative
Groups,CN=Lake District,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;

紫色字部分症状与我们的症状是一样的,所以,根据此结果,我们查询了两台邮件服务器获取账户的GC,通过命令
NLTEST /DSGETDC:suzsoft.com /GC
得到如下信息:
NLTEST /DSGETDC:suzsoft.com /GC
DC: \\w2kdc1.suzsoft.com
Address: \\10.0.15.11
Dom Guid: f4938c04-de3e-4db1-bbd6-b8a65eaeb77e
Dom Name: suzsoft.com
Forest Name: suzsoft.com
Dc Site Name: Default
Our Site Name: Default
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC
DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully

紫色字部分症状与我们的症状是一样的,所以,根据此结果,我们查询了两台邮件服务器获取账户的GC,通过命令
NLTEST /DSGETDC:suzsoft.com /GC
得到如下信息:
NLTEST /DSGETDC:suzsoft.com /GC
           DC: \\w2kdc1.suzsoft.com
      Address: \\10.0.15.11
     Dom Guid: f4938c04-de3e-4db1-bbd6-b8a65eaeb77e
     Dom Name: suzsoft.com
  Forest Name: suzsoft.com
 Dc Site Name: Default
Our Site Name: Default
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC
DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully
 
 
NLTEST /DSGETDC:suzsoft.com /GC
DC: \\w2kdc2.suzsoft.com
Address: \\10.0.15.12
Dom Guid: f4938c04-de3e-4db1-tt58-b8a666dwb07e
Dom Name: suzsoft.com
Forest Name: suzsoft.com
Dc Site Name: Default
Our Site Name: Default
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC
DNS_DOMAIN
DNS_FOREST CLOSE_SITE
The command completed successfully