tb1's questions

[从 StackOverflow 移出]

我们使用 PSFTP 以及 ppk 文件和批处理命令文件将 CSV 上传到远程 SFTP 主机。这已经运行了很多个月，直到最近 -b 参数才失败，并显示“严重：无法打开”

详细信息：
我们使用批处理文件或命令提示符在 Windows 上运行 PSFTP.exe。

我们通过 -b 参数传递的批处理命令文件名为“sftpcommands.txt”，包含以下几行：

put "D:\batch\Upload.csv"
quit

以下是我们从批处理文件或命令提示符运行的内容：

psftp.exe -v -P 22 -i D:\batch\keyfile.ppk -b D:\batch\sftpcommands.txt [email protected]

结果如下：

Looking up host "SFTPHost.domain.com" for SSH connection
Connecting to hostIP port 22
We claim version: SSH-2.0-PuTTY_Release_0.82
Connected to hostIP (from localIP:35022)
Remote version: SSH-2.0-AWS_SFTP_1.1
Using SSH protocol version 2
No GSSAPI security context available
Doing ECDH key exchange with curve nistp256, using hash SHA-256 (SHA-NI accelerated)
Host key fingerprint is:
ssh-rsa 4096 SHA256:ajIF+morestuffhere
Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) outbound MAC algorithm
Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) inbound MAC algorithm
Reading key file "D:\batch\keyfile.ppk"
Using username "OurUser".
Offered public key
Offer of public key accepted
Authenticating with public key "keynameinformation here"
Sent public key signature
Access granted
Opening main session channel
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Opened main channel
Started a shell/command
Connected to some-host.server.transfer.us-east-1.amazonaws.com
Remote working directory is /
Fatal: unable to open
Session sent command exit status 0
Main session channel closed
All channels closed

现在奇怪的部分是：我们可以摆脱 -b 脚本语法，并sftpcommands.txt在提示符出现时手动输入在文件中找到的相同命令psftp>（例如）：

psftp.exe -v -P 22 -i D:\batch\keyfile.ppk [email protected]

Looking up host "SFTPHost.domain.com" for SSH connection
Connecting to hostIP port 22
We claim version: SSH-2.0-PuTTY_Release_0.82
Connected to hostIP (from localIP:35022)
Remote version: SSH-2.0-AWS_SFTP_1.1
Using SSH protocol version 2
No GSSAPI security context available
Doing ECDH key exchange with curve nistp256, using hash SHA-256 (SHA-NI accelerated)
Host key fingerprint is:
ssh-rsa 4096 SHA256:ajIF+morestuffhere
Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) outbound MAC algorithm
Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Initialised HMAC-SHA-256 (SHA-NI accelerated) inbound MAC algorithm
Reading key file "D:\batch\keyfile.ppk"
Using username "OurUser".
Offered public key
Offer of public key accepted
Authenticating with public key "keynameinformation here"
Sent public key signature
Access granted
Opening main session channel
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Remote debug message: SFTP: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Opened main channel
Started a shell/command
Connected to some-host.server.transfer.us-east-1.amazonaws.com
Remote working directory is /
psftp> put "D:\batch\Upload.csv"
local:D:\batch\Upload.csv => remote:/Upload.csv
psftp> quit
Session sent command exit status 0
Main session channel closed
All channels closed

第三方几个月前确实移动了 SFTP 服务器，但据我所知，-b 参数在他们的新主机上仍然有效（但我可能错了）。

据我所知，我们这边没有任何变化，并且如所示，我们正在使用相同的本地登录 Windows 用户、相同的本地文件等进行 A/B 测试。应该不存在本地权限问题，因为我们使用的是 Windows，并且登录的帐户正在打开/编辑/访问所有相关文件。我还尝试将 -b 参数移动到行命令中的不同位置。

这个错误可能是远程 SFTP 服务器上的安全、配置或格式设置导致与 -b 命令文件混淆吗？

注意：我已经与操作远程 SFTP 主机的人员开具了一张票据，以对该问题进行三角测量，如果我能解决这个问题，我会在这里发布答案，以防它能帮助其他人看到 -b 开关上的“致命：无法打开”

我们有一个旧的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 导入的方式：

1. 我通过 UAC / 选择证书启动命令提示符（本地计算机）
2. 我使用默认选项将 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，我不知道是否值得冒险将其换成面向未来的保护。

由于我没有直接设置初始环境，我担心我过于简化了所需的内容。我对这个过程的理解是这样的：

1. 不理会 EX2016：在单独的主机上，安装 Windows 2022 和 Exchange 2019 CU12 - 此过程显然涉及扩展 EX2019 的 AD 架构
2. 运行最新的在线混合配置向导（“HCW”）只要足够长的时间即可获得免费许可证
3. 配置第 3 方 SSL 证书、（重新）创建接收连接器、测试从内部应用程序的中继输出
4. 重新运行 HCW，继续将连接转移到这台新的 EX2019 主机（与 EX2016 主机）

我不知道的事情：

• 我们是否必须手动导出 2016 年的证书并导入到 2019 年，或者 HCW 是否使用 2019 年盒子上的当前证书进行处理
• HCW 是否拉入先前的接收连接器或从 EX2016 到 EX2019 的任何其他有用设置
• 混合主机更改后我们是否需要再次重新运行单独的 AADConnect 设置
• 哪个 MS 实体负责处理支持？Exchange Online 支持不包括混合问题（即使我们仅使用混合盒进行 EXO 中继和云邮箱连接）。由于我们不托管本地 Exchange，因此该团队也不处理支持。

如果有人在 2016 年至 2019 年期间进行过“交换”，请告诉我我离基地有多远。

我知道我有时间 - 另一个明显的计划是在未来两年内减少对内部中继的任何需求，同时越来越多的遗留应用程序和设备开始跟上 SMTP Auth（例如 OAuth）的变化。谢谢！