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

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

ws2012r2-logo

WorkFolders 错误 0x80c80001 传输的数据未采用正确的格式

        WorkFolders(工作文件夹) 是 Windows Server 2012 R2 提供的一项新功能,一种低成本、简便的文件同步存储解决方案。在 Preview 阶段 gOxiA 就开始关注 WorkFolders,早先也与大家分享了两篇文章“Windows Server 2012 R2 - Work Folders 概述”、“Windows Server 2012 R2 - Work Folders 体验”。在微软发布 Windows 8.1 GA Update 后,发现一旦系统更新了 GA 补丁,WorkFolders 就会出现故障,具体表现为 Windows 8.1 无法通过工作文件夹与服务器同步数据,而且“操作中心”会提示错误,无法忽略。开打工作文件夹会提示“同步已停止。发生了一个问题”,“传输的数据未采用正确的格式(0x80c80001)”。

workfolders_error

        在事件查看器中并未得到更多的有价值的信息,因为是新功能,所以网上也未能找到相关的信息。后来通过启用事件Debug日志,找到了具体的错误信息。经过一系列的排错,最终确定是由 GA 补丁引起的 Bug。

image

        庆幸的是在 GA 补丁发布一个月后,微软终于在本月发布的针对该问题的更新补丁,即:KB2887595。用户可以通过 Windows Update 进行更新,也可以单独下载安装。http://www.microsoft.com/zh-CN/download/details.aspx?id=41076(PS:这个更新是针对 Windows 8.1/Server 2012 R2 的补丁集,解决了不少问题,强烈推荐用户尽快更新。),此外在 KB2901069 中有关于 WorkFolders 问题的详细的解释!

ws2012r2-logo5315_powershell-logo_gif-550x0_thumb

        Windows PowerShell Web Access(PSWA)是 Windows Server 2012 中的新功能,充当 Windows PowerShell 网关,允许远程计算机基于 Web 方式(HTTPS)访问和操作目标计算机的 Windows PowerShell,以执行 PowerShell 命令和脚本,而且无需在客户端上安装 PowerShell、远程管理软件或浏览器插件。其角色有些像 Remote Desktop Gateway,且允许单机应用,并且支持工作组环境。

image_thumb3

        PowerShell Web Access 基于 Web 方式访问的,只要支持 JavaScript 和接受 Cookies 的浏览器基本都可访问操作。下面是整理出的一组浏览器兼容性测试的结果数据,参考微软官方。

        受支持的台式计算机浏览器:

  • IE 8、9、10、11  
  • Firefox 10.0.2  
  • Chrome 17.0.963.56m  
  • Safari  5.1.2

        经过最小限度测试的移动设备或浏览器

  • Windows Phone 7、7.5、8  
  • Google Android WebKit 3.1 Browser Android 2.2.1 (Kernel 2.6)  
  • iPhone 5.0.1 的 Safari  
  • iPad 2 5.0.1 的 Safari

        为工作组环境下的 Windows Server 2012 安装和配置 PowerShell Web Access 可参考下列步骤:

        首先,通过“服务器管理器”的“添加角色和功能”向导安装“Windows PowerShell Web 访问”。使用 PowerShell 命令行安装:“Install-WindowsFeature WindowsPowerShellWebAccess -IncludeManagementTools

image_thumb4

        然后,在 PowerShell cmdlet 下执行“Install-PswawebApplication”,以在 IIS 下创建其所需的 Web 应用程序。

image_thumb5

        注:前面提到 PowerShell Web Access 基于 Web 方式访问,并且使用的是 HTTPS 协议,所以需要为其准备一张证书,否则我们可以通过附加“-UseTestCertificate”创建一个自签名证书,该证书有效期为90天。

image_thumb6

        如果准备有其他证书,可通过 IIS 管理器对 Web 站点的绑定进行设置。

        接下来,需要使用“Add-PswaAuthorizationRule”为 PowerShell Web Access 配置授权规则。例如:

Add-PswaAuthorizationRule –ComputerName * –UserName “maytidesufan” –Configuration *

        其中“-ComputerName”是要授权通过 PowerShell Web Access 访问的计算机名称,也可使用“ComputerGroupName”指定一个计算机组;“-UserName”即允许访问的用户,而“UserGroupName”为用户组;“-Configuration”即允许的会话配置

        现在,我们便可打开浏览器访问 PowerShell Web Access,进行计算机管理。

image_thumb7

image_thumb8

参考资料:“部署 Windows PowerShell Web 访问”、“使用基于 Web 的 Windows PowerShell 控制台

windowsserver2012

Windows Server 2012 R2 – Work Folders 体验

        在“Work Folders 概述”中 gOxiA 向大家简述了 Windows Server 2012 R2 新角色 – Work Folders(工作文件夹)的主要功能、应用范围,并介绍了其工作的机制、以及部署等方面的资讯。关注 Work Folders 的朋友应该已经有了一定的认识,而本文将引领大家安装和配置 Work Folder,以及如何在 Windows 8.1 客户端上配置访问 Work Folder。

SingleServerDeployment

        本实验将采用单服务器部署方式,除了一台 Work Folders 服务器外,还需要准备一台 Windows 8.1 客户端。为了简化实验步骤,选择在现有 AD 环境下进行安装部署,所以 AD 环境的搭建不再复述,系统架构可参考上图。Work Folders 更详细的软件需求可参考:http://technet.microsoft.com/en-us/library/dn265974.aspx。整个环境都是基于 Hyper-V 平台的虚拟化

安装 Work Folders 服务器

  1. 准备一台 Windows Server 2012 R2 服务器用于 Work Folders。
  2. 在分区下创建一个用于存储同步数据的目录,如:D:SyncShare。
  3. 启动“添加角色和功能”向导,在“文件和存储服务”-“文件和iSCSI服务”下找到并勾选“Work Folders”进行安装,也可以使用 PowerShell 进行安装“Add-WindowsFeature FS-SyncShareService”。安装 Work Folders 角色的同时还会添加额外所需的功能,如下图所示会安装 Web 服务器核心部分。需要注意的是 Work Folders 虽然用到了 IIS,但并不使用 IIS 来提供 Https(SSL)的连接!!!
    WorkFolders_FS-SyncShareService

创建同步共享目录

  1. 在“服务器管理器”上切换到“工作文件夹”,如下图所示。单击“任务”创建新同步共享。
    1
  2. 在“新同步共享向导”的“服务器和路径”步骤中选择“输入本地路径”,可通过浏览选中之前创建的目录“D:syncshare”。
    2
  3. 在“用户目录结构”这一步中可选择使用用户别名或包含用户所在域(user@domain)作为用户目录名称。
    3
  4. 如下图所示,键入同步共享名,便于用户识别。
    4
  5. 同步访问设置中添加隶属于此 Work Folders 服务器及同步共享目录的用户或用户组。
    5
  6. “设备策略”允许 IT 管理员强制为客户端启用安全措施,如:加密工作文件夹、自动锁定屏幕以及要求用户必须为设备设置一个密码。
    6
  7. 在确认页中复查之前的配置,如无问题便可点击“创建”按钮。
    7

配置客户端访问

  1. 客户端使用 Work Folders,目前的选择只有 Windows 8.1 客户端。我们可以在控制面板中找到客户端 Work Folders 的配置选项,如下图所示:8
  2. 键入用户邮件地址,向导会根据域名自动去链接 Work Folders 服务器标准地址,如:workfolders.contoso.com
    9
  3. 在完成上一步骤后,大家应该都会遇到连接故障,这是因为 Work Folders 目前还处于测试版阶段,整个功能并不完善。所以解决连接问题需要参考官方的文档,在客户端上执行一个注册表修改命令行,以允许客户端通过非 SSL 加密与服务器进行连接。脚本内容如下:
    Reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WorkFolders /v AllowUnsecureConnection /t REG_DWORD /d 1

    如果想略过之后手工填写用户所在的 Work Folders 服务器地址,可执行下面的命令行:
    Reg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\WorkFolders /v ServerUrl /t REG_SZ /d http://syncServer.contoso.com

    10
  4. 完成连接配置后,需要确认接受安全策略,最后完成整个配置过程。
    11
    12

        至此,服务器端和客户端的安装和配置过程即告结束,如果有多台客户端就可以实际体验一下数据的同步存储。感觉 Work Folders 目前还处于雏形阶段,很多问题还没有解决,而且功能和管理都存在缺陷和缺失,而现在距离 Windows Server 2012 R2 RTM越来越近,希望在 RTM 后还能看到 Work Folders。

参考:Work Folders Test Lab Deployment

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