当我们的 Windows 10 设备从 Microsoft Edge 打印时，打印会进入 Window Server 2012 打印队列，并在打印/假脱机时挂起。这种情况一直持续到我手动清除队列并重新启动打印后台处理程序。据我所知，唯一存在打印问题的程序是 Edge。
这是驱动问题吗？从哪里开始解决这个问题？
我有一个 Exchange 2016 服务器，其间大约有 14 天的蓝屏死机。服务器是虚拟的，存在于通过 iSCSI 存储的集群 vmware 环境中。我们运行的其他 Windows 服务器（包括 Exchange 的被动副本）都没有蓝屏。被动 Exchange 正在备份并清除被动和主动节点上的事务日志。
- 我已经尝试安装最新的关键补丁（还没有可选的）
- 我已尝试将有问题的 VM 迁移到新主机。
这是 BSoD 查看器给我的信息：
052716-21921-01.dmp 27.05.2016 10:22:16 CRITICAL_PROCESS_DIED 0x000000ef ffffe000`de10d080 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\052716-21921-01.dmp 8 15 9600 138 150 27.05.2016 10:22:47
051516-25765-01.dmp 15.05.2016 10:11:06 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`0ad80900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\051516-25765-01.dmp 8 15 9600 138 150 15.05.2016 10:11:41
042816-19328-01.dmp 28.04.2016 22:36:50 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`3da4f900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\042816-19328-01.dmp 8 15 9600 294 472 28.04.2016 22:39:45
041916-23859-01.dmp 19.04.2016 08:43:53 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`23101900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\041916-23859-01.dmp 8 15 9600 294 472 19.04.2016 08:47:04
我在不同的网站上看到了一个有同样问题的帖子，但没有人真正回答这个问题，而且帖子已经过时了。
有人对如何解决这个问题有任何指示吗？我是否必须安装另一台 Exchange 服务器并迁移到其中？这将是非常不幸的..
我已经设置了一个与 Exchange 2010 和 Exchange 2016 共存的环境。
目前邮件流似乎没有任何问题，我已经将两个测试用户从 2010 年迁移到 2016 年。
SMTP 流量和 HTTPS 是从新的 Exchange 2016 安装代理的 - 并且适用于后面的 2010 用户。
我的问题是，当用户迁移时，outlook 2016 在连接到新服务器时出现问题。
当我打开 Outlook 时，它仍然对旧服务器使用 RPC/HTTP。
如果我删除旧的配置文件，并使用自动发现重新创建它，它工作正常。
然后我看到 MAPI 流量，它按预期访问了新服务器。
如果我必须手动为我们公司的所有用户重新创建配置文件，这将导致问题..
有没有人有任何指示？
编辑了更多信息：
我迁移了自己的用户，并打开了 Outlook。我收到消息说我的盒子已迁移，我需要重新启动 Outlook；所以我做到了！我的手机和 OWA 工作正常，只是我的 Outlook 客户出现了问题。它发生在我连接到同一邮箱和同一用户（家庭和办公室计算机）的两台计算机上。
打开我的 Outlook 客户端时，我收到带有旧服务器内部名称名称的证书警告消息（例如：Exch2010.domain.local），并且正在使用的证书用于我们的 FQDN，即 mail.company.com。
第二次编辑：
我刚刚从 2010 年迁移了一个测试用户，关闭了 Outlook，并尝试从外部网络连接。它问我是否要允许https://mail.company.com/autodiscover/autodiscover.xml编辑我的设置。我点击了“允许”，什么也没发生。邮箱保持断开状态，连接状态有一个连接状态为“已建立”。该连接是通过 mail.company.com 和 Exch2010.company.local 代理的。我重新启动了Outlook，同样的事情发生了。
然后我把客户端从外网移到了我们的内网。现在它给了我同样的信息“允许这个网站配置[email protected]服务器设置？” 但使用 URL 格式的新交换服务器的本地名称，例如“ https://exch2016.company.local/autodiscover/autodiscover.xml ”。我允许并接受了证书警告（因为它说它再次使用本地名称 - exch216.company.local; 这与 SSL 证书不匹配）。
Outlook 仍然无法运行并且处于“断开连接”状态。我自己的邮箱已“建立”但没有更新。
出于好奇，我通过运行以下命令检查了服务器：
Get-AutodiscoverVirtualDirectory | fl
这三个的 InternalURL 和 ExternalURL 都是空白的。我没有足够的经验来判断这是否正确。
出于某种原因，服务器似乎在内部宣布它们的本地名称，而不是正确的“mail.company.com”。
我还通过运行检查了服务器：
Get-ClientAccessServer -Identity SERVER | fl
他们都将 AutoDiscoverServiceInternalUri 设置为“ https://mail.company.com/autodiscover/autodiscover.xml ”。
所有这些的 FQDN 都设置为它们的本地主机名 (servername.company.local)。
我不知道接下来要尝试什么..
编辑三号；作为对@Sembee 的回复： 你好@Sembee；感谢您的回复。我把它们留空，没有做任何改变。我检查了所有三台服务器上 clientaccessserver 的 InternalURI，它们是相同的。自动发现测试完全没有问题，并且从一开始就这样做了。重新配置用户 Outlook 使 Outlook 再次工作（来自自动发现的新数据）。目前所有流量都通过 2016 服务器（afaik），并且代理 OK 到 2010 服务器。没有人提到任何问题。迁移到 2016 后，Outlook 无法正常工作，而无需重新创建配置文件并运行新的自动发现。
第四次编辑： 当我今天上班时，我自己的笔记本电脑（昨天/星期天不工作）和我用来测试的笔记本电脑（星期六不工作）都工作得很好。可能是某种延迟同步对我这样做？我目前正在设置另一个测试，看看它是否以相同的方式运行 - 以及是否有可能以某种方式计时。任何指针将不胜感激。
我尝试将主电子邮件地址从一个邮箱移动到一个新邮箱。让我们打电话给旧地址：[email protected]
我将此帐户和 SMTP 地址重命名为 [email protected]，并将旧的“[email protected]”地址移至新邮箱。
新邮箱的名称为 [email protected]，现在别名为“[email protected]”。
从外部来源发送电子邮件时，电子邮件会出现在新邮箱中。从我们的组织内部从任何@company.com 地址发送时，即使我在“to：”字段中键入“[email protected]”，它似乎也会点击“[email protected]”。
谁能解释为什么？以及如何解决这个问题？当运行 Get-MessageTrackingLog 并将我自己的地址过滤为发件人时，我可以看到我的测试邮件，但“收件人”字段显示为“[email protected]”，即使我 100% 确定我输入“[email protected]”。
更改不到 24 小时。会不会是一些需要更新的内部地址列表？旧帐户的域用户名为 Department.old；以与主 SMTP 地址相同的方式。
我正在尝试基于 IP 子网发现计算机。管理服务器与客户端不在同一个工作组或活动目录中，因此这是唯一的方法。
我可以发现大约 1/3-1/2 的计算机。
我尝试在其中一台计算机上完全禁用 Windows 防火墙，它似乎将自己添加到不受管理的计算机列表中。
当只为 ICMPv4 打开时，管理服务器可以 ping 目标客户端计算机，但它不起作用。
看起来我缺少一些需要在 Windows 防火墙中打开的端口 - 但伟大的互联网无法告诉我哪些端口！
以前有没有人这样做过，并且知道我缺少哪些端口？为所有客户端禁用 Windows 防火墙，安装卡巴斯基防火墙并不是什么好办法.....
我正在尝试让两台新的戴尔 R620 服务器在 10Gbit 接口上运行。这些服务器随附两个用于 10Gbit 的 PCI 网卡。
目前，iDRAC 安装并报告的网卡为：
- NIC SLOT 1 - Intel(R) 以太网 10G 2P X520 适配器
- NIC SLOT 2 - Intel(R) 以太网 10G 2P X520 适配器
- 集成网卡 1 - Intel(R) 2P X520/2P I350 rNDC
集成卡有 4 个端口。其他每个卡都有 2 个端口，每个端口用于 10Gbit。可用端口总数为 8。
问题 1：我只能看到 vmware 中 8 个端口中的 7 个。
由于某种原因缺少 Vmnic4。
实际连接起来的两个网卡在 RJ45 上，用于管理。
问题 2：其中一个 vmnic 连接到的交换机在 10Gbit 上获得了指向服务器的链接，但 vmware 清楚地声明了其他内容！
从上图中，连接的三个端口中只有两个获得了链接。目前已连接两个 RJ45 和一个光纤 10Gbit。
所连接的交换机是 Alcatel-Lucent 7210 SAS-M。连接到该服务器的端口状态如下：
端口号：1/2/2
管理员状态：向上
链接：是的
端口状态：向上
我如何以及为什么会在 switchport 上获得 OK，但在 vmware 中却不行？当前运行从戴尔软件页面下载的 5.5 版。
已通过将 SFP 放入 EqualLogic 磁盘机柜中对 ALU 交换机进行了测试，并检查了双方是否以 10G 的速度连接。EQL 获得了相同类型的 SFP，并且工作正常。
这可能是网卡固件问题吗？vmware中的驱动程序？
任何指针都会非常有帮助。
我们已经设置了一个 md3220i SAN 以用于 vmware 5.1。在此 SAN 上的虚拟机内部时，我们尝试多次复制文件以创建多个/会话流。这样做时，只有最新的流运行，所有其他流都暂停，直到活动流结束。
这是您可以在 vmware 中更改的内容吗？还是控制器问题/设置？我们有 4 个 lun，每个 lun 有 8 条路径。如果您需要任何其他信息 - 只需询问！:)
环境：4 个 Exch 2010 Sp1 托管模式 MBX、2 个 CASHUB、HLB infront。
此设置为多个不同的客户运行多个域。可以通过 mail.ourhostingdomain.com 访问 HLB，它是所有客户端连接的地方（因为这会平衡 CAS 服务器的负载）。当我们针对不同于托管域的我们自己的域运行自动发现测试时，我们的主域的 WEBSERVER 使用它的 SSL 证书进行回复。这会导致错误的自动发现，并警告用户出现问题。
我正在使用 [email protected] 运行测试，它连接到 HLB，因为它应该在 mail.ourhostingdomain.com 上。为什么 ourprimarydomain.com 的网络服务器会回复而不是获得正确证书的 exchange/hlb？
Ourprimarydomain.com 有一个 _autodiscover SRV 记录将请求抛给 mail.ourhostingdomain.com （这似乎部分有效，因为我们连接到正确的服务器？）
如果有人可以解释这种行为，将不胜感激！
（不，autodiscover.ourprimarydomain.com 没有 A 或 CNAME，只有 SRV）
同样的事情发生在同一平台上的其他人身上，他们都得到了指向 mail.ourhostingdomain.com 的 SRV 记录。