我有一台 Exchange 2019 服务器，它已经运行了很长时间。在过去的几天里，它随机开始收不到电子邮件，尽管您仍然可以发送并且 POP3 和 IMAP 上的所有客户端仍然可以连接。
在接收日志中，每封电子邮件都会出现以下错误：-
消息或连接已确认，状态为重试并响应 451 4.4.397 与目标主机通信时出错。-> 421 4.2.1 无法连接 -> SocketConnectionRefused：套接字错误代码 10061。
然后突然在随机时间后它又开始自行接收。
现在从我的角度来看，我没有改变任何配置，也无法找到原因。
任何帮助将不胜感激。
我最近似乎对微软推动尝试将所有内容强制进入他们的在线服务有越来越多的问题。
到今天为止，我突然有两个工作站拒绝与 Exchange 保持连接。这是一个本地域和本地 Exchange 服务器。出乎意料的是，他们现在在启动时弹出一个 Microsoft 在线登录窗口。如果我关闭窗口，帐户状态将从愉快地连接到 Exchange 变为“需要密码”。
登录框预先填充了[email protected]，然后尝试单击下一步只是“此帐户不在我们的系统上”的错误（是的，令人惊讶的是，它是本地域，本地交换，与 Microsoft 在线无关）。
我该怎么办？如今，让我的用户连接到他们的本地交换帐户而不需要 Outlook 要求他们登录不存在的 Microsoft 在线帐户的正确方法是什么？
我在虚拟机中安装了以下功能集合
| 服务器名称 | 已安装功能 |
|---|---|
| 电子Dom | 活动目录、NFS 文件共享 |
| E-科尔 | Exchange 服务器、Sharepoint、PBX 服务器 |
| 电子安全 | NPS，证书颁发机构 |
| 电子艺术 | 线鲨 |
我可以使用一些建议，是否可以将这些功能中的每一个添加到同一个 VM 或另一个 VM/更需要专用 VM？例如，我了解到不建议将 Active Directory 和 Exchange Server 驻留在同一 VM 上。与 Active Directory 混合的证书颁发机构也是如此，但我不知道为什么。Sharepoint 服务器与 Exchange Server 和 PBX Server 与 Exchange Server 一起存在同样的问题。
我认为 PBX 服务器需要它的专用 VM，但它的关键性质可以与 Exchange 服务器同等匹配，它们都不能承受失去互联网连接/宕机的后果。
我们的任务是更改我们公司的电子邮件域。Active Directory 将保持不变。我已创建（但未应用）一个新的电子邮件地址策略，用于指定新域。唯一的其他电子邮件地址策略是我们原始域的默认设置。
当我们迁移时，我需要能够一次将其应用于用户，以帮助他们更新他们的设备。谷歌让我失望了。有没有人有这个过程的经验/提示？
概述：
我们有一个安装了 Exchange 2019 的演示环境。Exchange 2019 服务器设置为经典混合模式，并启用了集中式邮件传输。入站电子邮件已成功通过 Office 365 流向我们的本地 Exchange 邮箱。但是，外部收件人不会收到出站邮件（从本地邮箱发送）。
重现步骤：
到目前为止完成的故障排除：
问题）：
我最近为我们主要用于测试的几个用户设置了一个内部 Exchange 2019 服务器。那里只有 5 个帐户，在一种情况下，我从 PST 文件导入了用户整个现有的电子邮件备份。这个备份大约是 10GB，尽管它实际上并没有完全导入，因为它遇到了“TooManyLargeItems”错误。我对此并不太在意，因为我有每个用户邮箱的 PST 副本作为离线存档。
几天后，我为该用户启用了在线存档，在独立存档数据库上使用了 >2 年的所有默认值。在此之后，我注意到 Exchange 驱动器正在快速填满。几天之内，它已经增长到我分配的 300GB 中的 100GB。最终我意识到这是存档数据库使用了过多的空间，并发现该用户的存档只是在不断增长。几天后，它达到了 50GB -
Name FolderSize ItemsInFolder
---- ---------- -------------
Top of Information Store 0 B (0 bytes) 0
Calendar 124.1 MB (130,100,547 bytes) 10241
Deleted Items 29.06 KB (29,756 bytes) 3
ExternalContacts 0 B (0 bytes) 0
Files 0 B (0 bytes) 0
Inbox 22.47 GB (24,125,848,037 bytes) 193193
Sent Items 27.09 GB (29,090,235,340 bytes) 224726
Sync Issues 0 B (0 bytes) 0
Conflicts 379.5 MB (397,940,955 bytes) 5483
Recoverable Items 0 B (0 bytes) 0
Calendar Logging 136.1 MB (142,698,692 bytes) 20681
Deletions 2.763 GB (2,967,210,171 bytes) 23899
Purges 0 B (0 bytes) 0
Versions 0 B (0 bytes) 0
近 25 万个已发送项目和 20 万个收件箱......这似乎并没有停止，我现在被迫简单地禁用该用户的存档。
有没有人知道一个邮箱应该只有 <=10GB 的电子邮件是如何创建这样一个失控的存档的，或者我可以使用什么其他方法来理解它为什么会发生？
我已安装 Exchange 2019 用于测试目的。我已经购买了域名和证书。我安装后，状态显示：无效。谢谢你。
这是 certutil -verify 的结果
Issuer:
CN=ZeroSSL RSA Domain Secure Site CA
O=ZeroSSL
C=AT
Name Hash(sha1): 082e3ff9058cfe8a7c18bd13efdf1d1660707a6b
Name Hash(md5): ab1639dd9160fab0f92496ffe91dc2aa
Subject:
CN=mail.belxchange.com
Name Hash(sha1): e5b331beff7e2e09aeef22bae49b7edad6ef3ec7
Name Hash(md5): 00ff0b4da8f724bc70646e3b026e45d1
Cert Serial Number: e28ee3f7a40f789620b258aae02b60dd
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 17 Hours, 19 Minutes, 5 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 17 Hours, 19 Minutes, 5 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=ZeroSSL RSA Domain Secure Site CA, O=ZeroSSL, C=AT
NotBefore: 6/28/2021 8:00 PM
NotAfter: 9/27/2021 7:59 PM
Subject: CN=mail.belxchange.com
Serial: e28ee3f7a40f789620b258aae02b60dd
SubjectAltName: DNS Name=mail.belxchange.com
Cert: beffb40c51aa7de210779220bf6b98be69d67911
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CRL (null):
Issuer: CN=ZeroSSL RSA Domain Secure Site CA, O=ZeroSSL, C=AT
ThisUpdate: 6/29/2021 4:50 PM
NextUpdate: 7/6/2021 4:50 PM
CRL: 2e9f37d78d9ae1a9e435760e1d9b006b55dafe3c
Issuance[0] = 1.3.6.1.4.1.6449.1.2.2.78
Issuance[1] = 2.23.140.1.2.1
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
NotBefore: 1/29/2020 8:00 PM
NotAfter: 1/29/2030 7:59 PM
Subject: CN=ZeroSSL RSA Domain Secure Site CA, O=ZeroSSL, C=AT
Serial: 6c55abdbd00792c79d070cd8119ed6bf
Cert: c81a8bd1f9cf6d84c525f378ca1d3f8c30770e34
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CRL (null):
Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
ThisUpdate: 6/30/2021 4:28 AM
NextUpdate: 7/7/2021 4:28 AM
CRL: 33d94bdc17a67be0286bea0e96cfe3b6ad7c3284
Issuance[0] = 1.3.6.1.4.1.6449.1.2.2.78
Issuance[1] = 2.23.140.1.2.1
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
NotBefore: 1/31/2010 8:00 PM
NotAfter: 1/18/2038 7:59 PM
Subject: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
Serial: 01fd6d30fca3ca51a81bbc640e35032d
Cert: 2b8f1b57330dbba2d07a6c51f70ee90ddab9ad8e
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.3 Code Signing
Application[2] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
Application[3] = 1.3.6.1.5.5.7.3.4 Secure Email
Application[4] = 1.3.6.1.5.5.7.3.6 IP security tunnel termination
Application[5] = 1.3.6.1.5.5.7.3.7 IP security user
Application[6] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[7] = 1.3.6.1.5.5.7.3.8 Time Stamping
EV[0] = 1.3.6.1.4.1.6449.1.2.1.5.1
EV[1] = 2.23.140.1.3
Exclude leaf cert:
Chain: a126b04b452a7f46b037e93b530914e84dd20f84
Full chain:
Chain: 480ccb6aae924c7427e4e32e37bf45e8261459bf
------------------------------------
Verified Issuance Policies:
1.3.6.1.4.1.6449.1.2.2.78
2.23.140.1.2.1
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
PS C:\Users\Administrator>
我们有多个当前仍在使用 MapiOverRpc 的 Exchange 2019 服务器。来自 Internet（Mapi、ActiveSync、Owa）的连接是通过 Sophos UTM 网关（“Web 应用程序防火墙”）的反向代理功能进行的。
我们现在想切换到 MapiOverHttps。问题是我们仍然希望使用 NTLM/Kerbersos 作为身份验证方法，但是我们的反向代理无法转发这些方法，只能转发“基本身份验证”。如果我们启用此功能，所有内部和外部用户在每次打开 Outlook 时都会被要求输入密码。MAPI 虚拟目录是唯一一个我无法为内部和外部访问设置不同身份验证方法的目录。
我的问题：有什么方法可以在内部使用 MapiOverHttps，而使用 OutlookAnywhere 进行外部连接？或者一种使用 MapiOverHttps 和基本身份验证进行外部访问和 NTLM/Kerberos 进行内部访问的方法？
我已经尝试阻止/mapi反向代理上的 url，希望这将回退到 OutlookAnywhere。这不起作用，Outlook 只是没有连接。
由于软件依赖性，我在尝试清理陈旧帐户时对我的环境有一个奇怪的要求。我想从环境中删除所有陈旧的 AD 用户和 Exchange 邮箱，但是，我需要以某种方式为陈旧的帐户保留 SMTP 地址，以便以后无法将该地址分配给另一个邮箱（可能是具有相同的新用户姓名）。我正在寻找最好的策略。技术细节不是我关心的。
我最终采用了以下两种策略（我认为仍然必须有更好的方法，请指教）：
将每个邮箱转换为联系人。脚步：
通过将每个电子邮件地址添加为虚拟用户的代理地址来保留所有电子邮件地址。脚步：
另一种方法可能是“禁用然后启用邮箱”策略，该策略将删除所有旧邮箱内容、保留地址并保留用户帐户。就像前面提到的 <1> 方法一样，它实际上并没有清理多少。
您认为在 Exchange Server（或 Active Directory）中保留大量电子邮件地址并避免在删除原始邮箱后将这些地址分配给新用户的最佳方法是什么？
我们遇到了一个非常奇怪的问题，我们找不到解决方案。
我们在 11 台裸机 MS Server 2019 机器上安装了 11 台 Exchange 2019 Server。它们都在一个 DAG 中，我们有 3 个 DC，它们也都是 GC。
有时，某些 Exchange 服务器会失去与 GC 的连接，但 EMS 中会失去 OLNY。例如，如果我们尝试获取邮箱，我们会收到以下消息：
Microsoft.Exchange.Data.Directory.ADTransientException：在林 X 中找不到任何可用的全局编录
其中 X 是森林的名称。
它完全随机发生，但服务器运行的时间越长，此问题发生的时间越长且越频繁。
GC 和 Exchangerserver 位于不同的网络中，但防火墙在它们之间的每个端口上都有一个 ALLOW ANY <-> ANY 策略。
我们将另一个 DAG 放在与其他 Exchange 服务器相同的网络中，他们遇到了同样的问题。我们重新创建了虚拟目录，但问题仍然存在。我们清理了 DNS，没有留下旧条目。我们将一些服务器踢出 AD 并重新加入它们，没有任何改变。
所有服务器都获得了最新的 CU，下面的 Windows 服务器获得了最新的更新
有没有人暗示可能是什么问题？问候