none
exchange 2016 执行get-queue很多条记录该如何处理 RRS feed

  • 问题

  • 您好

       请教下exchange 2016  CU19 dag架构,前端有edge服务器,当执行get-queue命令出来如下东西,该如何处理呢?

    [PS] C:\Windows\system32>Get-Queue

    Identity             DeliveryType                Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
    --------             ------------                ------ ------------ -------- --------- -------------- -------------
    EXHDB02\15         SmtpDeliveryToMailbox       Ready  0            0        Normal    0              EXHDATABASE03
    EXHDB02\22         SmtpDeliveryToMailbox       Ready  0            0        Normal    0              EXHDATABASE04
    EXHDB02\23         SmtpDeliveryToMailbox       Ready  0            0        Normal    0              EXHDATABASE01
    EXHDB02\24         SmtpDeliveryToMailbox       Ready  0            0        Normal    0              EXHDATABASE02
    EXHDB02\45         SmtpRelayWithinAdSiteToEdge Ready  0            0        Normal    0              edgesync - de...
    EXHDB02\Submission Undefined                   Ready  0            0        Normal    0              提交
    EXHDB02\Shadow\3   ShadowRedundancy            Ready  1            0        Normal    0              EXHdge01.JO....
    EXHDB02\Shadow\16  ShadowRedundancy            Ready  5            0        Normal    0              EXHDB01.JO....

    在exchange 2016 CU12未升级到CU19之前每次执行get-queue是没这个东西的。其中C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue下的mail.que文件十几个G,每台邮箱服务器都十几个G,边缘服务器小点大概三四个G


    • 已编辑 Tony Mu 2021年3月15日 5:46
    2021年3月15日 4:55

答案

  • 您好,

    mail.que文件在将所有电子邮件发送到目标之前将它们临时存储,这是一个ESE数据库,这意味着它在体系结构上类似于Exchange邮箱数据库edb文件。

    除了上面提到的ShadowRedundancyEnabled参数,还有SafetyNetHoldTime可能会造成mail.que快速增大,您可以运行Get-TransportConfig | select ShadowMessageAutoDiscardInterval 来检查是否仍为默认的2天。

    如果是工作环境,十几个G还算正常,但由于“queue file generates white space that can only be recovered by rebuilding it”, 如果某天mail.que文件过大,则只能通过重建来恢复其大小:

    1. 停止Microsoft Exchange Transport服务

    2. 移动C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue下的文件到别的路径

    3. 启动Microsoft Exchange Transport服务

    此致,

    Eric Yin


    如果以上回复对您有所帮助,建议您将其“标记为答复”. 如果您对我们的论坛支持有任何的建议,可以通过此邮箱联系我们:tnsf@microsoft.com.

    • 已标记为答案 Tony Mu 2021年3月16日 16:40
    2021年3月16日 8:59

全部回复

  • 您好,

    这个queue是卷影队列在邮件传输时会保留邮件的冗余副本,有关详细信息,请参阅Exchange Server 中的卷影冗余

    这个功能默认为开启状态,可能是之前您禁用了,升级到CU19后自动给您开启了,您可用用以下命令来禁用:

    Set-TransportConfig -ShadowRedundancyEnabled $false

    通常您不用手动清理这个queue,默认自动清除的时间为2天,也可以用命令修改:

    Set-TransportConfig -ShadowMessageAutoDiscardInterval dd.hh:mm:ss

    当然您也可以先不做修改,再观察一下,是否这个queue越积越多。

    此致,

    Eric Yin


    如果以上回复对您有所帮助,建议您将其“标记为答复”. 如果您对我们的论坛支持有任何的建议,可以通过此邮箱联系我们:tnsf@microsoft.com.

    2021年3月15日 8:41
  • 感谢Eric回复,那mail.que这个文件十几个G是否正常,升级之前没太关注这块,只关心队列里面有没有文件。看没有邮件就升级了,升级后发现系统C盘空间一下少了十几个G,不知道是不是因为这个。
    2021年3月15日 8:50
  • 您好,

    mail.que文件在将所有电子邮件发送到目标之前将它们临时存储,这是一个ESE数据库,这意味着它在体系结构上类似于Exchange邮箱数据库edb文件。

    除了上面提到的ShadowRedundancyEnabled参数,还有SafetyNetHoldTime可能会造成mail.que快速增大,您可以运行Get-TransportConfig | select ShadowMessageAutoDiscardInterval 来检查是否仍为默认的2天。

    如果是工作环境,十几个G还算正常,但由于“queue file generates white space that can only be recovered by rebuilding it”, 如果某天mail.que文件过大,则只能通过重建来恢复其大小:

    1. 停止Microsoft Exchange Transport服务

    2. 移动C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue下的文件到别的路径

    3. 启动Microsoft Exchange Transport服务

    此致,

    Eric Yin


    如果以上回复对您有所帮助,建议您将其“标记为答复”. 如果您对我们的论坛支持有任何的建议,可以通过此邮箱联系我们:tnsf@microsoft.com.

    • 已标记为答案 Tony Mu 2021年3月16日 16:40
    2021年3月16日 8:59
  • 那暂时这样了,谢谢eric
    2021年3月16日 16:40