Windows Server 2003 | Windows Server 2008 | Small Business Server | Server Core | Windows Server 2008 R2 | Windows Server 8 | Windows Home Server | Windows Server 2012 | Windows Server 2012 R2 | Windows Server 2016

IESEC

HOWTO: 利用组策略禁用 IE ESC(Internet Explorer 增强的安全配置)

        Internet Explorer Enhanced Security Configuration(即:IE ESC,Internet Explorer 增强的安全配置),自 Windows Server 2008 开始提供的一项服务器安全配置,旨在有效降低来自基于 Web 的不安全内容攻击的风险,直至 Windows Server 2012 R2 该安全配置默认都为启用。

        IE ESC 默认情况下为 Administrators 组和 Users 组启用,当这些组用户在使用 IE 浏览网站时会收到警告提示,被告知该网站中的一些内容被阻止,此时可以去除“网站内容被阻止时继续提示”的复选框已减少干扰,加入用户信赖该网站,则可以将该网站添加到信任网站中,那么下次再访问的时候就不会在提示安全警告。

2015-12-02 (6)

2015-12-02 (5)

        IE ESC 其实是一项非常不错的功能,但是在一些测试环境中,可能会略显繁琐,通过手工方式关闭简单有效,但是如果环境中创建了多台 Windows Server 虚机就会很麻烦,毕竟要一步一步执行操作。

2015-12-02 (7)

        如果当前正好是一个域环境,那么我们可以利用组策略来为禁用 IE ESC,接下来就可以编辑现有组策略或新建一个组策略!IE ESC 提供两个注册表项分别为 Administrators 组和 Users 组定义配置:{A509B1A7-37EF-4b3f-8CFC-4F3A74704073} 和 {A509B1A8-37EF-4b3f-8CFC-4F3A74704073},他们位于:HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components下,所以我们需要在组策略中创建两个注册表项的预定义,将其下的“IsInstalled”根据需要改为“00000000”,如下图所示:

2015-12-02 (8)

        如果还不知道如何在组策略中添加注册表配置,请参考下图:

2015-12-02 (9)

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 故障了!

logo_winserver2012

Top Support Solutions for Windows Server 2012 Essentials and Windows Server 2012 R2 Essentials

1. Solutions related to Remote Web Access:

2. Solutions related to Office 365 integration issues:

3. Solutions related to installation issues:

4. Solutions related to Migrating SBS to a new server or to new servers:

5. Solutions related to Server activation:

 

原文出处:http://blogs.technet.com/b/topsupportsolutions/archive/2014/08/11/top-support-solutions-for-windows-server-2012-essentials-and-windows-server-2012-r2-essentials.aspx

WS08-R2_v_rgb

Top Support Solutions for Windows Server 2008 and Windows Server 2008 R2

1. Solutions related to bugchecks, stop errors, and unexpected restarts:

2. Solutions related to Active Directory issues:

3. Solutions related to Active Directory replication:

4. Solutions related to DNS:

5. Solutions related to Active Directory Federation Services (AD FS):

6. Solutions related to File Replication Technologies (FRS and DFSR):

7. Solutions related to installing Windows updates or hotfixes:

8. Solutions related to system hangs:

9. Solutions related to Active Directory Certificate Services:

10. Solutions related to TCP/IP communications issues:

 

原文出处:http://blogs.technet.com/b/topsupportsolutions/archive/2014/08/11/top-support-solutions-for-windows-server-2008-and-windows-server-2008-r2.aspx

ws2012r2-logo

HOWTO: 为 Work Folders 添加自定义端口

        Work Folders  - 工作文件夹,是 Windows Server 2012 R2 的一个新角色,在 gOxiA 看来 Work Folders 是一个易于部署和应用的低成本云同步存储解决方案,它不同于 OneDrive 等其他同步存储服务,有一定的局限性,可以阅读“Windows Server 2012 R2 - Work Folders 概述”获取更详尽的信息。

FileSyncSolutions

        如果您已经对 Work Folders 有了直观的了解和认识,那么不妨看看“Windows Server 2012 R2 - Work Folders 体验”以了解如何安装和应用 Work Folders。

        在了解上述的信息后,我们会了解到 Work Folders 默认使用 HTTPS 协议,而 HTTPS 协议默认端口是 443,如果 Work Folders 仅在企业内部或通过 VPN 接入到企业内部来使用的化,那么采用默认配置是最佳的做法。但是当用户离开企业网,身处外部时经常会接收到关于 Work Folders 的提示,通知用户 Work Folders 当前无法访问,相信久而久之用户便会产生反感。

        面对这一个问题,为何不采用将 Work Folders 发布到公网上供用户使用的方式呢?!便捷、灵活……

        对于公网 IP 资源贫乏的国内公司而轻言,如果前端部署有 TMG 这类防火墙系统,倒是可以通过域名形式继续发布,如果仅是通过端口发布,就会占用宝贵的 443 端口。

        好在 Server & Management Blogs 分享了一篇非常有价值的文章“Windows Server 2012 R2 – Resolving Port Conflict with IIS Websites and Work Folders”。文中提到可以为 Work Folders 修改默认的端口,问题迎刃而解!!!

        以下是操作步骤:

  1. 停止 Work Folders 服务,“net stop syncsharesvc”  
  2. 修改“c:\windows\system32\syncsharesvc.config”配置文件,为 Work Folder 添加自定义端口,可参考下图:
    image  
  3. 对端口进行授权,“netsh http add urlacl url=https://*:12345/ user=”NT Authority\LOCAL SERVICE””  
  4. 因为本例是新绑定了一个端口,所以还需要为这个端口配置证书,“netsh http add sslcert ipport=0.0.0.0:12345 certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY”,添加后的配置信息如下:
    image

        现在,可以将 Work Folders 用于外网访问的端口发布出去了,客户端只需要在配置 Work Folders(工作文件夹)时为 URL 补充上端口号即可,如下图所示:

client_workfolders

        参考资料:

logo_winserver2012_thumb[1]

Windows Server 2012 Essentials 因执行 SFC 引发的 RWA 访问故障

        前端时间在测试 RDS,所以在现有生产环境内部署了一台 RDS,访问都很正常,计划将其发布到外网已方便从 Internet 上直接访问,所以需要 RDG(Remote Desktop Gateway),而当前环境下的域控是基于 Windows Server 2012 Essentials(WS2012Ess)的,默认启用了 RWA,也就能够提供 RDG 的角色。

        当在 RDS 上添加这台 WS2012Ess 作为 RDG 时遇到了错误,提示“无法执行操作,因为操作 ResetRunspaceState无效……”,排错无果向 MSFT 提交了 Case,具体细节不再叙述,只提重点!按工程师的建议对 WS2012Ess 执行了dism /online /cleanup-image /checkhealth、/scanhealth、/restorehealth,以及 sfc /scannow 检查和修复的操作,当时也确实发现了问题并得到了修复,最后在此配置 RDS 便成功了。

Screenshot_2014-04-12-00-08-37

        RDS 是好了,但没想到 RWA 又出了故障,第二天才发现用户在访问 RWA 时报错“未能加载文件或程序集 WSSg.Web.Internal, Version=6.2.0.0, Culture=neutral, PublickKeyToken=31bf3856ad364e35 或它的某一个依赖项。系统找不到指定的文件”。

ESS1

        使用 WS2012Ess 仪表板对 RWA 进行了修复,但总是失败!只得求助搜索引擎,没想到这个问题还真的有解,并且还是已知问题。

ess2

        KB2828269 描述了这一问题,并提供了解决方案,只需执行如下 PowerShell 命令行即可。

$BinDir = [System.Environment]::ExpandEnvironmentVariables("%programfiles%\windows server\bin")

$WebDir = [System.Environment]::ExpandEnvironmentVariables("%programfiles%\windows server\bin\WebApps")

$WebDir = get-childitem $WebDir –recurse

$List = $WebDir | where {$_.name -eq "web.config"}

foreach($listItem in $List){ if($listItem.DirectoryName -match "MacWebService") {continue;} ($a= Get-Content $listItem.FullName); $a = $a -replace "%SBSPRODUCTBINPLACEHOLDER%", $BinDir; remove-item $listItem.FullName; $f = [io.path]::Combine($listItem.DirectoryName, "Web.config"); $a >> $f}

ws2012r2-logo

HOWTO: 解决无法使用内置管理员账户打开 Internet Explorer

        上个月 gOxiA 与大家分享了 从初始 ServerCore 模式向 FullServer 转换 的经验。如果你亲身经历了这一转换过程,可能会遇到如下图的问题!

11

        当我们从开始界面打开 IE 时,系统会提示“无法使用内置管理员账户打开 Internet Explorer。请使用其他账户登录,然后再试依次。”出现这个问题的主要原因是当用户从 ServerCore 向 FullServer 转换时,系统策略会自动将开始界面的 IE 设置为以 Modern UI 方式来启动,而 Windows Server 2012 R2 的 FullServer 模式并未包含桌面体验的组件,如:应用商店、Modern UI 版的 IE……,导致用户无法启动 Modern UI 应用。

        而解决这个问题最为简单有效的做法就是进入“控制面板”打开“Internet 选项”,切换至“程序”选项卡,复选“IE 磁贴用于打开桌面上的 Internet Explorer”选项即可。

image

ws2012r2-logo

从初始 ServerCore 模式向 FullServer 转换

        还记得 12年12月 gOxiA 与大家分享的两篇关于 Windows Server 2012 运行模式的文章“HOWTO:切换至 Windows Server 2012 的 Minimal Server 模式”、“Windows Server 2012 的四种运行界面模式”,介绍了 Windows Server 2012 如何在几个运行界面模式下进行转换。当时的测试都是基于初始 FullServer 模式进行的,即:带有 GUI 的服务器完整模式。所以当我们执行模式转换时并不会遇到问题,如果 Windows Server 初始安装时是 ServerCore 模式,那么当我们要向 Minimal 或 FullServer 转换时就会遇到错误,如下图所示:

1

        出现这个错误的原因是以前的 Windows 版本中,即使禁用了某个服务器角色或功能,相应的二进制文件仍会保留在磁盘上,占用着磁盘空间,当然这一特性也使我们在日后重复安装角色或功能时而无需提供安装源。但在 Windows Server 2012 中则又有所改变,用户不仅可以禁用某个角色或功能,还可以完全删除相应的文件。即:要完全删除某个角色或功能时,在 Uninstall-WindowsFeature 中使用 –Remove 参数。

        正因为如此,当 Windows Server 初始安装选择的是 ServerCore 模式时,一些角色或功能的二进制文件并未存储在当前系统中,所以当使用常规命令行进行安装时便会出现错误。所以我们需要在执行 Install-WindowsFeature 时使用 –source 参数指定安装源。完整的命令行参考如下:

Install-WindowsFeature server-gui-mgmt-infra –source wim:d:\sources\install.wim:2

2

3

        其中,结尾“:2”为 Install.wim 映像索引 2,即 Windows Server 2012 R2 Standard,与本例初始安装的系统版本对应,如果需要确认 WIM 文件的信息,可以参考如下命令行:

dism /get-wiminfo /wimfile:d:\sources\install.wim

        查阅 TechNet Library 管理服务器核心服务器 资料,发现在 1.5 转换成“完全安装”模式 小节中提到如果希望使用 Windows 更新而不是某个 WIM 文件作为源,则只需要为 Install-WindowsFeature 使用 –Restart 参数,安装时便会自动从微软官方站点获取更新文件。(PS:有意思的方式,-Restart 可是重启参数啊!!!)不过实际测试此种方式并不实用,网络速度是最大的瓶颈!

4

        解决了一个小小的问题,却积累了多个经验!

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