邮件服务器-邮件系统-邮件技术论坛(BBS)

标题: 向通讯组发送邮件时,存在"等待目录查找的邮件"队列中发不出? [打印本页]
作者: yangfan_78    时间: 2007-10-27 12:55
标题: 向通讯组发送邮件时,存在"等待目录查找的邮件"队列中发不出?
我们用的是EXCHANGE 2003,向其中一个通讯组(全公司的所有人员)发送邮件时,被放在队列里,出不去,队列名是:等待目录查找的邮件.

以下为错误信息:类别DAP,来源:MSExchangeDSAcces事件ID:2074
进程 STORE.EXE (PID=2080)。搜索或读取目录服务器 hansdc2.hanslaser.com 时返回对象“CN=hansall,OU=閫氳缁?OU=閭欢缁?DC=hanslaser,DC=com”，但该对象的 属性“member”在一次搜索中返回了太多的值。 请尽量减少此属性中包含的值的数目，以便能够正常操作。
但是向成员较少的通讯组发送时,就可以.我在全局设置-邮件传递-默认设置-收件人限制里选了”无限制”.


非常感谢!组成部分

[ 本帖最后由 yangfan_78 于 2007-10-27 12:57 编辑 ]
作者: royz24    时间: 2007-10-28 18:56
你一共有多少个邮箱用户？
作者: yangfan_78    时间: 2007-10-31 14:04
一个组为全部公司用户,1700个.
还有一个组700个左右,
都发不出去,在队列里了.
作者: abdxj    时间: 2007-11-1 09:17
我记得默认好像是500个，你可以自己更改
作者: yangfan_78    时间: 2007-11-1 09:21
请问如何更改?非常感谢!

原帖由 abdxj 于 2007-11-1 09:17 发表
我记得默认好像是500个，你可以自己更改
作者: zhuhong4723    时间: 2007-11-1 17:38
收件人限制有2处可以修改
1.全局设置-邮件传递-默认设置-收件人限制,默认5000
2.ADUC,用户属性,exchange常规，传递选项 ，这里的设置会代替全局设置

但是你的问题不应该是收件人限制
1.检查一下GC的性能
2.通讯组是否还嵌套了其他的通讯组
3.这是什么类型的通讯组
4.GC是否和exchange在同一个DOMAIN
作者: 钉子    时间: 2007-11-2 10:32
对于向多成员通讯组发送邮件出现"等待目录查找的邮件"问题时,有可以胆可以偿试:

1.检查你GC的性能,或是监视服务器性能,因为邮件在“等待目录查找”队列中排队，有可能是无法连接GC或是GC烦忙导致的.一般情况下分拣邮件,每个收件人使用大约 2 KB 的内存。当然这个内存使用是暂时的，但在每次展开通讯组时都会发生。如果将电子邮件发送到更大的、包含 100,000 个用户的基于查询的通讯组，则分类程序需要大约 200 MB 的 RAM。处理器速度和可用物理内存量会影响到展开后传递电子邮件所需的时间。


2.为通讯组指定展开服务器,如图:

[attach]3325[/attach]

有一个KB可以参考:
http://support.microsoft.com/kb/822897/zh-cn
作者: 钉子    时间: 2007-11-2 10:37
原帖由 abdxj 于 2007-11-1 09:17 发表
我记得默认好像是500个，你可以自己更改


这个限制应该是5000,特别是Windows 2000 年代存在5000个组成员关系的限制,Windows 2003下使用LVR改变了这个限制,但还是建议低于5000.



组成员关系的限制

如果你供职于一个大型或者中型企业，那么有可能在Windows 2000 AD中遭遇5000个组成员关系的限制。5000个组成员关系的限制与上面讨论过的其他限制不同，它实际上是一个最大值。是AD所采用的Jet数据库引擎在存储和复制大于一定数量的数据时，无法处理写操作的最大值。Windows 2003的AD通过引入Linked Value Replication(LVR)解决了这个问题。在使用了LVR之后，当组成员关系发生改变，AD不会复制所有的属性和值，而只是复制成员关系中个别的属性和值。除了克服5000个组成员关系的限制，新的复制方法与前一版本中的相比要有效率得多，不仅支持更低的带宽而且减少了DC的资源消耗。

实际上，5000个成员关系的限制不仅限于AD的用户组，其他任何包含成员的属性都存在此限制。由于组成员关系是应用最多的，所以也是被发现几率最大的。成员关系换而言之就是AD用户管理中的“隶属于”。例如：假设Sales组有三个组成员Tom，Dick和Harry。如果在AD中查看Tom，Dick和Harry对象，你会在每个用户的“隶属于”选项卡中看见他们都属于Sales组。这就是成员管理的典型例子。

要在Windows 2000的AD中解决这些限制，只能采用用户账号分层次、分组的方法。根据你公司的组织结构尽量将用户归纳入不同的组，再设置组嵌套。当然过多的组会增加管理难度，但这是唯一选择。
作者: 钉子    时间: 2007-11-2 10:58
标题: 基于查询的通讯组部署建议
　Exchange 展开基于查询的通讯组并运行查询所需的时间取决于下列几个因素：
　　
　　· 组织中部署的硬件类型：分类程序可能对每个收件人都需要 2 KB 的内存。这是一个比较保守的度量值，可以将它用作基准。在采用这一基准的前提下，如果将电子邮件发送到包含 6,000 个用户的基于查询的通讯组（意味着查询将返回 6,000 条记录），则分类程序仅仅展开基于查询的通讯组就需要 12 MB 的 RAM。虽然这种内存使用是暂时的，但在每次展开通讯组时都会发生。同样，如果将电子邮件发送到更大的、包含 100,000 个用户的基于查询的通讯组，则分类程序需要大约 200 MB 的 RAM。处理器速度和可用物理内存量会影响到展开后传递电子邮件所需的时间。

　　· 全局编录或展开服务器的可用性影响用户发送到基于查询的通讯组的电子邮件的展开和传递：如果所有全局编录服务器都不可用，则该邮件将置于分类程序的重试模式下，这意味着完整的展开过程将在一小时后重新启动。
　　
　　通常建议，将基于查询的大型通讯组划分成多个标准通讯组的组合，然后为每个较大的通讯组分配不同的展开服务器。下面的选项描述了完成此项任务的三种方法。
　　
　　选项 1：指定一个不包含邮箱的 Exchange 2003 服务器（如公用文件夹副本服务器或桥头服务器）作为基于查询的大型通讯组的展开服务器。由于这种服务器有更多的带宽和资源可以用来展开基于查询的通讯组，因此展开和传递过程的效率更高。
　　
　　选项 2：为每个 Exchange 服务器创建一个基于查询的通讯组，并限定每个基于查询的通讯组只包含所在 Exchange 服务器上的邮箱。将此同一服务器指定为展开服务器，可优化邮件传递过程。然后，使用以这些基于查询的通讯组为其成员的聚合标准通讯组。例如，要为所有专职雇员创建基于查询的通讯组，可以在每台服务器上为专职雇员创建一个基于查询的通讯组，并将它们分别命名为"Server1 Full Time"和"Server2 Full Time"。然后，创建一个由这些基于服务器的组组成的通讯组，并将其命名为"AllFullTime"。
　　
　　注意　 用来合并基于查询的通讯组的通讯组自身不能是基于查询的通讯组。
　　
　　选项 3：下面的示例说明了改善基于查询的大型通讯组处理的第三种方法。
　　
　　您想创建一个名为"All employees"的基于查询的通讯组，该通讯组包含 100,000 个用户。考虑将这个组划分成多个较小的基于查询的通讯组，然后将这些组合并成一个标准通讯组，如下所示：
　　
　　· "All Temps"10,000 个用户
　　· "All Vendors"5,000 个用户
　　· "All Full-Time"65,000 个用户
　　· "All Interns"2,000 个用户
　　· "All Contractors"18,000 个用户
　　
　　在此方案中，"All Full-Time"是一个较大的通讯组，因此可能需要为其分配一个特定的展开服务器。至于其他基于查询的通讯组，则可以根据用户在 Exchange 服务器上的分布情况来分配展开服务器。例如，如果所有实习员工都驻留在一个 Exchange 服务器上，那么可以将该服务器指定为"All Interns"的展开服务器。总之，这种推荐方法的执行效果，将比一个包含 100,000 个收件人的基于查询的通讯组的执行效果好得多。 bitsCN



欢迎光临 邮件服务器-邮件系统-邮件技术论坛(BBS) (http://bbs.5dmail.cn/) Powered by Discuz! X3.2