john zuh's questions

作为确保我们公司安全通信的一部分，我们正在尝试将 Digicert 颁发的 SMIME 证书导出给我们的客户，但在通过 certmgr 控制台导出过程中，我们遇到了一些关于未包含或无法导出私钥的问题。

以下是错误的简要描述以及各种故障排除尝试。

在导出过程中，我注意到选择个人信息交换 - PKCS #12 (.PFX) 选项在证书导出向导上显示为灰色，如 证书导出向导下面的屏幕截图所示

我尝试通过首先检查导入的证书是否存在相应的私钥来解决该问题，但如下面的屏幕截图所示，没有可用的私钥。 Certmgr 证书

我通过执行 certutil -repairstore 我的“serial”命令进一步尝试在证书存储上进行修复工作，以便修复证书损坏的情况，但出现以下错误 certutil Repairstore 错误

正如这篇 Digicert 文章https://knowledge.digicert.com/solution/SO1335.html中所建议的，我尝试通过在文件夹中使用记事本打开密钥容器路径 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys 中的每个文件来检查权限对应于各个密钥容器。访问被拒绝，正如您在Machinekeys 权限下方的屏幕截图中看到的消息一样

我检查了 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys 文件夹的权限，并在Machinekeys 文件夹的 icacls下得到了以下结果有趣的是，该文件夹的权限类型符合 Microsoft 建议的所需默认权限，如此处记录https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders

此时，我有点不确定该采取什么行动。是否有可能在没有附带密钥的情况下导入证书？我不这么认为，因为将相同的证书复制到另一个客户端后导出会产生预期的结果。是否可以想象证书已损坏或密钥容器内的子文件夹的访问继续被拒绝？有趣的是，这种情况似乎相当零星，因为它在不同位置的某些客户端上正常运行。功能组可能是属于特定组的特定用户或客户端，该特定组在客户端、网络或域上本地拥有必要的权限，这可能是合理的吗？我将不胜感激任何提示或建议。

我们的组织正在将 Ecosia 设置为所有浏览器的默认搜索提供程序，我们希望通过您在此处的链接https://ecosia.zendesk.com/hc/en-us/articles/使用 GPO 模板来实现这一点214140705-The-Ecosia-Group-Policy-Template-for-Chrome。当我下载并提取模板时，我收到一条错误消息

“命名空间 'Google.Policies.Chrome' 已定义为商店中另一个文件的目标命名空间。”

我什至进入了chrome.admx模板文件来修改这一行以避免冲突

    <policyNamespaces>
    <target namespace="Google.Policies.Chrome" prefix="chrome"/>
    <using namespace="Google.Policies" prefix="Google"/>
    <using namespace="Microsoft.Policies.Windows" prefix="windows"/>
  </policyNamespaces>

因为我在ChromSearchProdviderEcosia.admx模板文件中意识到也定义了这个命名空间，所以我将命名空间重命名为其他名称，然后在出现几次错误后再次尝试，但没有成功。

<policyNamespaces>
    <target namespace="Google.Policies.Chrome" prefix="chrome"/>
    <using namespace="Microsoft.Policies.Windows" prefix="windows"/>
  </policyNamespaces>

我怀疑命名空间有冲突，因为我已经将一些 google chrome 策略模板下载到同一位置 -> ADMX/ADM 商店。有没有办法我们可以覆盖模板的这一部分以避免这种冲突？或者重新定义名称空间的可能性，以便在意识到谷歌已经存在之后不会触发冲突？

由于此错误，我无法将 Ecosia 模板添加到存储中。我已经联系了 Ecosia 支持，但欢迎提出一些一般性建议。

我使用组策略禁用了 Outlook 2010 和 Outlook 2016 中的“全部回复”按钮。我通过使用各个版本的 Office 的 ADM/ADMX 模板中的设置来禁用命令栏 ID 来做到这一点。

当我使用 Office 2016 管理模板并禁用命令栏 ID 355（全部回复）时，它会按预期禁用按钮，但是根据文档应该与 2010 兼容的相同管理模板无法按预期工作。（全部回复）按钮在设置为禁用后仍处于活动状态。

然后我检查了 Outlook 2010 版本，发现它们大多是 32 位版本，这可能是原因，是否有不同的方法来禁用这些按钮。

然后我决定尝试通过 Reg 路径禁用，因为有人用这种方法取得了成功并推荐了它 Computer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\14.0\outlook\disabledcmdbaritemscheckboxes

名称：TCID1，类型：REG_SZ，值：355

彻底验证后，受影响的客户端上不存在此密钥。添加它也没有禁用回复按钮。

有没有人成功禁用 Outlook 2010 的命令栏 ID，特别是 32 位版本？如果是这样，你是怎么做到的？

我遇到了一种情况，即打开 pdf 的默认应用程序更改为PDF-Xchange而不是 Adob​​e 和 Mail 更改为Outlook 2010、2016而不是内置的默认 Microsoft Mail 应用程序。这些更改是在通过 Reg Queries 检索两个应用程序的有效哈希，然后引用 App-assoc.xml 规范文件中的相应条目后进行的。这适用于所有目标计算机，但用户再次登录时仍将 pdf 重置为 adobe acrobat 的计算机除外。这意味着他必须始终手动设置他首选的默认 pdf 和 mailto 应用程序，这使得它非常麻烦，因为他总是在每次登录后重置为首选默认应用程序。

有没有人经历过这种情况并想分享一些可能的故障排除技巧？我在某处读到它可能是幕后的流氓应用程序，迫使这种行为。

从 NAS 迁移到基于 EMC isilon 的 NAS（在更改服务器名称和 IP 地址的过程中）导致对网络共享 UNC 路径名的影响后，是否有人遇到过 Microsoft 同步中心问题？我们有某些用户仍然让他们的家庭驱动器路径引用旧路径，即（\\server\oldshare而不是\\server\newshare仍然被引用）。我们确保正确定义旧 UNC 到新 UNC，并通过 GPO 实现文件夹重定向。此策略已在客户端上彻底实施，并在多次更新和重新启动后进行了测试。

由 IT 支持手动删除客户端上的旧引用仍会导致冲突，并最终在一段时间后回滚到引用旧路径。我们的结论是这在 Windows 10 上无法正常工作。

客户端无法对此进行控制，因为由于全局策略限制，该选项也已显示为灰色，因此无法在客户端进行此更改。有什么办法可以通过全局注册更新设置通过组策略解决？我们是否必须在客户端或通过 GPO 重新启动离线缓存？我还注意到，这影响了大多数从 Windows 7 -> 10 迁移的客户，大多数客户在公司网络之外通过 WiFi/VPN 离线工作或远程工作，或者由于出差几天没有在线。

我们在这里也坚持所有最佳实践。

我正在通过全局策略考虑可能的情况 - 通过 GPO 或通过客户端手动更新从 7 -> 10 的脱机缓存路径？

在迁移过程之前或期间触发手动离线同步缓存过程，以便文件在迁移完成时位于它们应该位于的位置。

我们还在这里找到了一个脚本，它可以手动触发此缓存，但需要用户没有的系统权限，我们希望避免让用户这样做。我们可能会将其包含在我们的迁移过程中。

本文中的信息是否相关？

我们正在将第三方 MDM（内部部署）与 AAD 门户中的 Autopilot 集成以启用 Windows 10 OOBE。我们希望通过利用 Azure 中的本地核心企业应用程序服务器来实现这一目标。到目前为止，我们已经配置了以下未按预期工作的配置。在“用户设备注册”或“DeviceManagement-Enterprise-Diagnostics-Provider”中也找不到任何相关的事件日志：

1. Autopilot 设备配置文件是通过将 ID 导入 Autpilot 创建的。
2. 具有授权用户的安全组，包括。MFA 启用身份验证
3. 重定向 URI 也在 Azure AD 使用的 MDM 应用程序中配置，以通过映射 Azure DRS 之一的相应 client_id 加入 Web 应用程序。
4. 还创建了使用条款 URL 和密钥。MDM 发现 URL 和 MDM 使用条款 URL 已正确设置，但尚未检查它们是否可通过 Internet 访问

注意：以上所有内容和许多其他要求都经过多次检查和测试。当 InTune 用作 MDM 服务器时，设备能够注册（通过将 InTune 应用程序添加到我的 Azure AD）

开箱即用的测试设备用于在 Azure 中运行以下测试场景，其中包含 E5。mdm + 安全订阅。

在我们的测试过程中，我们收到以下错误：

****> we are not able to enroll Azure AD due to : Redirect UI
> [https://login.microsoftonline.com/WebApp/CloudDomainJoin/10] is not
> formed correctly****

经过一些谷歌搜索后，我了解到这可能是由 DNS 问题、出站代理问题或各种其他原因引起的。

我还读到，如果租户管理员未安装应用程序或租户中的任何用户未同意，则可能会发生这种情况。我们可能将身份验证请求发送给了错误的租户，但今天与同事核实了这一点，并根据需要授予了所有必要的权限。没成功

我还读到这可能仅仅是由于一般的身份验证失败，这对我来说仍然很普通。

任何人都有关于如何根据报告的错误解决此类问题的任何线索。将不胜感激。