我们有一个旧的AD 用户帐户，该帐户具有静态密码，用于多台机器上的计划任务和服务。我知道 gMSA 更好，并且正在单独安装它，但这个帐户需要再运行一段时间。
回到此帐户：我想更改密码以满足当前密码强度标准并确保 AES 哈希值，但我不确定是否需要在两次更改之间间隔 10 小时进行更改，或者是否可以连续更改密码并将密码更新推送到受影响的端点。
如果有人可以澄清 2x、10 小时间隙重置方法，或者是否可以为此目的背靠背进行，我将不胜感激。
谢谢！
我们有一个 Exchange 2019 混合服务器，可以为我们的 AD 用户启用远程邮件，并从某些旧版应用程序将出站邮件发送到我们的邮箱。虽然我们的用户都是 AD 绑定的，但我们直接在 EOL/M365 中创建一些邮箱（例如共享邮箱）（也称为无 AD 对象）。
混合服务器可靠地将邮件发送到我们所有 AD 绑定的远程邮箱，但是一旦我们将收件人更改为直接在 EOL 中创建的共享邮箱（无 AD 对象），我们就会得到如下内容：
<550 4.4.7 QUEUE.Expired; message expired in unreachable destination queue. Reason: A matching connector cannot be found to route the external recipient>
另外，值得一提的是，我在邮件跟踪日志中注意到，当我们发送“ [email protected] ”地址时，成功发送的路由源会解析为“ [email protected] ”。我们的共享邮箱是直接在 EOL 中创建的，默认情况下只有“ [email protected] ”。
在我撰写本文时，我尝试通过 EOL 添加“ [email protected] ”辅助 SMTP，并发送另一条测试邮件，但混合主机仍将共享邮箱视为外部收件人。
如果有人经历过这个并提出建议，我将不胜感激。谢谢！
我们正在 M365 中运行带有远程邮箱和存档的 Exchange 混合模式。我们的一名员工几个月前离职，因此他们的邮箱被软删除/保留。他们的 AD 对象仅被禁用（从未删除），因此当它通过 Entra Connect 恢复并同步回来时，会创建一个具有相同别名但（空）邮箱的新 M365 用户（这很好）。
我们的问题是，AD 用户仍然拥有该用户之前的 msExchArchiveGUID，并且该存档在 EOL 中仍然被软删除，但同样，M365 中的用户是不同版本的用户。我需要弄清楚如何告诉 AD 为现在处于活动状态的 M365 用户创建一个新的（空）存档。
细节：
在东非共同体：
如果我运行：Get-RemoteMailbox returningUser | fl displayname, ArchiveGuid它会从 AD 中的 msExchArchiveGUID 属性进行报告：
ArchiveGuid : some-legit-archive-guid-number
在停产中：
如果我运行：Get-Mailbox returningUser | fl archiveguid我得到：
ArchiveGuid : 00000000-0000-0000-0000-000000000000
但是，如果我运行：Get-EXOMailbox -SoftDeletedMailbox -Archive | where { $_.alias -eq 'returningUser' } | select Guid
我得到：
Guid
---
some-legit-archive-guid-number
我尝试过的操作：删除基于混合的存档，同步，然后重新添加：
在 EAC: 中Disable-RemoteMailbox returningUser -Archive，运行 Entra Connect，一切看起来都很好。AD 中的 msExchArchiveGUID 为空。当我运行Enable-RemoteMailbox returningUser -Archive令人讨厌的先前 msExchArchiveGUID 返回时。
我读过很多不匹配的示例，其中解决方案是告诉 EAC 使用 EOL 版本的存档 GUID，但在这种情况下，EOL 似乎无法使用 EAC 版本的 GUID，因为它已被软删除并与先前的工件用户绑定。
如果有人知道如何告诉 EAC 停止寻找（无论它在哪里寻找）先前的 ArchiveGUID 并仅发布新的存档，我将不胜感激！
谢谢！
最后注意：如果我运行这个：
Get-MsolUser -HasErrorsOnly | fl DisplayName,UserPrincipalName,@{Name="Error";Expression={($_.errors[0].ErrorDetail.objecterrors.errorrecord.ErrorDescription)}}
错误是：
{The value "some-legit-archive-guid-number" of
property "ArchiveGuid" is used by another recipient object.
Please specify a unique value.}
（又名相同的软删除 GUID）
我们是混合模式的M365租户，只有Exchange Online邮箱，通过Entra Connect同步邮箱属性。我们收购了另一家公司（不是 M365 租户）。我们已经接管了他们的 DNS 并将他们的旧公司邮箱复制到我们租户的 EOL 邮箱中，这些邮箱已经使用我们自己的自定义域作为他们的主要地址。
此时，我们只想将他们的旧域电子邮件地址添加为辅助 smtp，以便他们可以直接在我们的租户中接收对旧线程的邮件回复。
初始测试：如果我们现在通过 EntraConnect 添加旧地址并同步，我们不会在 M365 管理面板中看到额外的别名（但毫不奇怪，我们在本地 Exchange Hybrid 中看到）。Set-ADUser userMailbox -add @{ProxyAddresses='smtp:[email protected]'}
显然，我们仍然需要将他们的自定义域添加到我们的 M365 租户中，以便管理面板“查看”该域，但问题是，在那之后，通过 Set-ADUser 添加这些 proxyAddresses 是否会同步到 EOL，或者我们是否必须使用 EntraConnect 做其他事情，或者我们是否可以单独运行一个来匹配它？Set-Mailbox userMailbox -EmailAddresses @{add="[email protected]"}
另请注意：我知道我们可以在 AD 域和信任中添加 UPN 后缀并以这种方式同步域后缀，但这纯粹是为了邮箱别名，而不是身份；没有人会使用该域作为 UPN 登录 AD 或 M365... https://learn.microsoft.com/en-us/answers/questions/781907/add-new-email-domain-to-office- 365-混合动力
预先感谢任何这样做过的人！
通过 CERTLM 导入设备证书/私钥时，GUI 似乎选择了一个已弃用的加密服务提供商 (CSP)，称为“Microsoft Strong Cryptographic Provider”；我想知道是否有办法通过向导或组策略或（其他方式）将其更改为“Microsoft Software Key Storage Provider”。
更多详细信息：供应商要求我通过以下行命令语法将 PFX 导入 Windows 11 本地计算机证书存储：
certutil -csp "Microsoft Software Key Storage Provider" -importpfx MyPathToCertificate.pfx NoExport
这与他们的软件配合得很好，但是当我之前尝试导入相同的 PFX 时，我使用 CERTLM (GUI) 将证书导入到同一位置（本地计算机/个人存储）。这在当时似乎有效（证书出现在那里），但导致了解密错误，如供应商日志中所示。
以下是我通过 CERTLM 导入的方式：
- 我通过 UAC / 选择证书启动命令提示符（本地计算机）
- 我使用默认选项将 PFX 导入到个人商店
运行以下命令后：
Certutil -store My
我注意到证书有以下行：
Provider = Microsoft Strong Cryptographic Provider
而 certutil 命令明确选择“Microsoft Software Key Storage Provider”
根据https://www.pkisolutions.com/understanding-microsoft-crypto-providers/，“Microsoft Strong Cryptographic Provider”是一个已弃用的旧提供程序，而“Microsoft Software Key Storage Provider”是使用新密钥的现代首选。
不同的 CSP 解释了为什么供应商的应用程序在原始导入后无法工作，我理解为什么 MS 会选择“旧”提供程序作为向后兼容性的默认提供程序，但我很好奇是否有方法在执行时指定 CSP今后将通过 CERTLM 进行导入。
如果您使用 Exchange 2016 混合主机，但仅用于云邮箱管理和出站中继，那么是否“值得”交换 Exchange 2019 混合主机？
更多详细信息：不久前，有人帮助我们最初设置了 Azure AD Connect 和 Exchange 2016 Hybrid，用于云邮箱设置以及从复印机和旧应用程序的出站中继。除了 SMTP Auth 之外，没有任何客户端或服务曾经访问过混合主机（并且所有都是内部出站到 EXO）。我们没有来自先前本地 Exchange 托管的人员可能拥有的公共文件夹或其他任何内容。（我们确实在内部管理通讯组列表，但通过 AADConnect 同步）。那个人走了，我一直在保持累积更新并保持 AADConnect 和 EX2016 混合动力顺利运行。
Exchange 2016 扩展支持将于 2025 年 10 月结束。既然 Exchange 2019 CU12 拥有免费的混合许可证并支持 Windows 2022 Server，我不知道是否值得冒险将其换成面向未来的保护。
由于我没有直接设置初始环境，我担心我过于简化了所需的内容。我对这个过程的理解是这样的：
- 不理会 EX2016：在单独的主机上，安装 Windows 2022 和 Exchange 2019 CU12 - 此过程显然涉及扩展 EX2019 的 AD 架构
- 运行最新的在线混合配置向导（“HCW”）只要足够长的时间即可获得免费许可证
- 配置第 3 方 SSL 证书、（重新）创建接收连接器、测试从内部应用程序的中继输出
- 重新运行 HCW，继续将连接转移到这台新的 EX2019 主机（与 EX2016 主机）
我不知道的事情：
- 我们是否必须手动导出 2016 年的证书并导入到 2019 年，或者 HCW 是否使用 2019 年盒子上的当前证书进行处理
- HCW 是否拉入先前的接收连接器或从 EX2016 到 EX2019 的任何其他有用设置
- 混合主机更改后我们是否需要再次重新运行单独的 AADConnect 设置
- 哪个 MS 实体负责处理支持？Exchange Online 支持不包括混合问题（即使我们仅使用混合盒进行 EXO 中继和云邮箱连接）。由于我们不托管本地 Exchange，因此该团队也不处理支持。
如果有人在 2016 年至 2019 年期间进行过“交换”，请告诉我我离基地有多远。
我知道我有时间 - 另一个明显的计划是在未来两年内减少对内部中继的任何需求，同时越来越多的遗留应用程序和设备开始跟上 SMTP Auth（例如 OAuth）的变化。谢谢！