gOxiA=苏繁=SuFan Blog

因计算机名过长导致无法正常使用设备管理器

        这几天在处理一台 Dell R220 服务器，因为是交易环境使用，所以按照要求设定了一个比较长的计算机名，没想到却引发了不必要的故障问题。

        系统为 Windows Server 2008 R2 Standard，当打开设备管理器时遇到警告提示“由于您在远程计算机上运行设备管理器，设备管理器在只读模式中运行。要卸载设备或改变设备属性或驱动程序，必须在要进行改动的计算机上运行设备管理器。”

        当时一下就晕了，因为之前机器手动或网络部署了两次系统都发现有问题，而且还感觉显示分辨率不太对劲，无法与当前在用的 Dell 宽屏匹配，怀疑是不是自己手动安装系统有些问题呢？！咨询了 Dell 技术支持，说该机器建议使用 Lifecycle Controller 进行安装，所以老老实实重新照做了一遍，可惜结果还是一样。

        静下心想想，再仔细观察，发现了问题所在，设备管理器中的计算机名与实际计算机名并不对应，之前使用长计算机名进行命名时给出过警告，没想到会对设备管理器产生影响，既然对系统自身都产生了不良影响，那就应该直接限制使用长名称来命名！随后在 Windows Server 2012 R2 上进行了测试，却发现并未出现该问题，所以目前怀疑是个 Bug。

SharePoint Foundation 2013 创建自定义主机头的网站集

        SharePoint Foundation 2013 创建“Web 应用程序”时会生成首个网站集（如：http://sps.contoso.com），当再基于该 Web 应用程序创建网站集时会发现“网站地址”只能设置为“http://sps.contoso.com/sites/xxxx”的形式。当交付用户使用时由于 URL 过于复杂，会大大降低用户的体验度。

        其实在 SharePoint 上可以使用命令行管理程序来创建自定义主机头的网站集。在 TechNet SharePoint 资源库的 New-SPSite 命令参考中给出了示例，参考如下：

PS:

        该示例将为创建一个主机头为“cmcc.contoso.com”的网站集，该网站集的名称为“CMCC”，所有者为“goxia”，隶属于“sps.contoso.com”Web 应用程序。现在到 SharePoint 管理中心查看所有网站集就能看到这个刚创建的自定义主机头的网站集。

        因为前面的命令行并未指定模板，所以在第一次访问这个网站集时会要求选择网站模板，在完成初始化后便能够正常访问网站。虽然使用自定义主机头访问该网站集，但实际上 SharePoint 并不会在系统的 IIS 上创建新的站点，整个处理过程都是由 SharePoint 自身完成的，因为同在一个 Web 应用程序下，所以是共用的一套 Web 应用程序配置和数据库。

排错 Windows Server 2012 Essentials SSTP VPN 0x80092013 故障

        Windows Server 2012 Essentials 可通过配置向导来启用 VPN 服务，使公司用户能够在外网通过 VPN 接入到内部。当客户端基于 SSTP 协议连接 VPN 时可能会遇到 0x80092013 故障“由于吊销服务器已脱机，吊销功能无法检查吊销。”

        这是证书服务的一种安全机制，类似我们使用 IE 访问一些 HTTPS 网站时也会遇到类似的提示，但是用户可以略过警告，或者通过 IE 的高级配置将其屏蔽。

        按照这个思路，开始尝试通过禁用证书的 OCSP 检测来解决问题，运行 MMC 并加载证书管理，找到这个根证书进入其属性，切换到详细信息选项卡，并点击“编辑属性”。

        在 OCSP 选项卡中勾选“禁用证书吊销列表”，之后重新连接 VPN 测试，发现无效。也许正如前面提到的是因为安全机制要求 SSTP VPN 必须验证证书吊销。

        回到起点分析 0x80092013 故障，因为吊销服务器脱机导致无法获取证书吊销列表（CRL），那就先从访问吊销服务器开始排错。

        首先，查看此 CA 办法的证书，可访问 Essentials 的 RWA 站点，可从证书的详细信息中查到 CRL 分发点信息，如下图所示 CRL 分发点是一个 URL 地址，在内网访问该地址是正常的，能够下载 CRL。由于该地址并不是一个完整的 Internet 网址，所以用户无法从外部正常访问，从而未能获得 CRL。

        既然如此，只要保证用户在外部能够获取到 CRL 就应该能够解决问题，根据现有 CRL 的 URL 地址，对照 Essentials 的 RWA 结构，该 CRL 外部的访问地址应该类似“http://remote.contoso.com/certenroll/contoso-ess-ca.crl”，果断从外部访问该 URL 成功拿到了 CRL。那么就可以为此根证书指定 CRL 的位置，为此回到前面提到的 OCSP 设置位置，手工添加这个 CRL 外部可访问的 URL 地址，再次测试发现又失败了！

        搜索了知识库找到了 KB961880，故障分析结果倒是完全相同，不过官方给出的解决办法是配置证书服务器，在 CA 服务器属性的扩展选项卡中添加新的可供外部访问的 CRL 分发点地址，并确认复选“包括在 CRL 中，客户端使用它来寻找增量 CRL 的位置”，“包含在颁发的证书的 CDP 扩展中”，“包括在已发布的 CRL 的 IDP 扩展中”。如下图所示：

        此外，要将之前已存在的基于 HTTP 发布的 CRL 地址复选框都去掉，接下来就是等待，默认是 1 周的时间。当然如果实在等不及，也可以修改“吊销的证书”属性中的 CRL 发布参数，将其改为 1 小时，等生效后再恢复默认设置即可。

        现在连接 VPN 已经不会再出现 0x80092013 故障了！