WS08-R2_v_rgb

诡异的 Windows Firewall 启动故障

        早先安装了两台面向 Internet 的业务服务器,基于 Windows Server 2008 R2,根据要求做了安全强化,关闭了一些无用的服务,再此之后系统运行一直都很正常,但是每当“Path Tuesday”重启服务器后,便无法再远程访问到服务器(Remote Desktop)而且所有的服务端口也都无法访问。之前通知机房运维人员检查,也并未检查出个所以然,只是说 Windows 防火墙服务未启动,手工启动后便恢复正常。查看日志,也并未记录相关有价值的警告或错误日志。由于是生产环境,不敢贸然测试,只能利用假期晚间逐个恢复之前停止的服务,当恢复了 Server 和 Workstation 服务,重启服务器后便能够正常访问了。随即查看 Windows Firewall 的依赖性,并未发现与 Server 和 Workstation 有关,实在诡异!

        在系统恢复正常后,也只能先作罢,随后在本地测试环境搭建了虚机,按照生产环境的配置停止了对应的服务进行测试,可再也无法重现那些故障,但是生产环境中的这两台服务器却都是同样的故障,也搜索了网上的资料没有任何结果,目前也只能先搁置在那里。

        如果大家有什么思路可以讨论讨论!

image

  

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

  

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

  

nvhm

  

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

  

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

  

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

logo_winserver2012_thumb[1]

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

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

vpn-1

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

image

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

vpn-2png

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

vpn-3

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

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

image

        既然如此,只要保证用户在外部能够获取到 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 扩展中”。如下图所示:

CRL

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

image

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

分页: 4/51 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]