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

Project Honolulu Technical Preview 1711 Build 01003

        忍了好久终于可以发布这篇日志,微软在公布 Windows Server Insider Preview Build 17035 的同时,还公布了 Project Honolulu Technical Preview 1711 Build 01003,如果你还不了解什么是“Project Honolulu”,建议先复习一下 gOxiA 之前发布的文章“Project Honolulu Technical Preview 概览”和“Project Honolulu Technical Preview 部署 ”。

        在新版的 Project Honolulu 中又带来了一些改进:

  • 远程桌面
    1711 Build 01003 中加入了远程桌面的支持,现在我们可以在 Honolulu 中通过 RDP 来远程登录计算机,对远程计算机进行操作和管理。目前 RDP 控制台的功能还比较简单,如果你实在无法忍受这么小的可视界面,建议还是单独启动 MSTC 更为合适,对于 Honolulu 这套服务器管理方案来说,提供 RDP 只是为了便于 IT人员能够执行那些 Honolulu 还未提供的管理功能。
    Snipaste_2017-11-20_09-09-27
  • Windows 10 客户端管理
    在 TAP 中看到 Honolulu 1711 的内部测试公告时,超兴奋!可惜当时处于 NDA 只能压抑心中的喜悦。在 1711 中已经能够添加 Windows 10 客户端进行管理,点击“Add Cpnnections”能够看到“Add Windows PC Cnnection”选项。
    add_connections
    对 Windows 10 客户端的管理支持与服务器并无太大区别,除了常规的指标监控,计算机基本信息外,也可对证书、设备、日志、防火墙、当前进程、服务、存储,进行管理和操作,如果被管理的 Windows 10 客户端启用了 Hyper-V,还可通过 Honolulu 操控这些虚拟机,并对虚拟交换机进行管理和配置。
    ManagerPC
  • Switch Embedded Teaming(SET)
    Switch Embedded Teaming(PS:貌似是交换机嵌入式分组),应该是 SCVMM 的一个功能,看介绍之前没有提供 GUI 界面来配置,而现在作为 Windows Server 2016 的内置功能,已经可以通过 Honolulu 进行管理和配置,其位于“Virtual Switch”下。(PS:但是在实际使用中并未找到这个功能选项,可能是由于被管理的服务器系统版本不是 1709 所致。)
  • 数据网格性能改进
    针对证书和日志管理工具做了网络数据方面的性能改进。能够在处理大型数据集时,确保不会出现性能问题。这项改进将会持续进行,以确保 Honolulu 的所有管理功能都会获得最佳的性能。从目前的测试看,事件日志的加载过程确实缩短了不少。
  • 从 In Service 模式中移除 LAPS
    LAPSLocal Administrator Password Solution)已经从服务器安装场景中移除,但是在 Windows 10 下安装之后 LAPS 依然能够使用。


Project Honolulu Technical Preview 下载地址:http://aka.ms/honoluludownload

Honolulu_logo

Project Honolulu Technical Preview 部署

        上一篇日志“Project Honolulu Tecnical Preview 概览”向大家介绍了 Project Honolulu 的用途和主要的功能,而今天开始 gOxiA 将分享 Project Honolulu 的部署和安装。整体来说 Honolulu 的部署和安装非常的简单,没有复杂的限制和繁琐的需求,显得非常灵活和开放。所以无需有太多的顾虑,也不用特意搭建环境。

        在官方文档中 Project Honolulu  目前推荐了三种部署模式:

  • 本地模式,安装在 Windows 10 系统上,可满足快速开始、测试、临时或小规模的环境。
  • 网关模式,部署独立的 Honolulu 服务器,用于管理托管的服务器。
  • 混合模式,适用于群集,可部署在群集中的某个节点上,管理托管的服务器

deployment

        Project Honolulu 目前支持管理最新的 Windows Server v1709,Windows Server 2016,Windows Server 2012 及其 R2 版服务器,但是仅支持部署在 Windows 10、Windows Server v1709 和 2016 系统上,其中 Windows 10 仅支持本地模式,即安装后 Project Honolulu 不会以服务形式驻留,在使用前需要启动 Project Honolulu,会在系统栏保留程序图标。

        下面的截图是在 Windows Server 2016 上安装 Project Honolulu 的步骤,需要注意的是在授权协议界面中需要复选“Allow Project Honolulu to modify this machine's trusted hosts settings.”以允许安装程序修改信赖主机设置,根据需要复选“Create a desktop shortcut to launch Project Honolulu”。另外在服务器系统上安装时会提示指定一个用于 Project Honolulu 的 Web 服务端口,为了保护 Web 登录过程的安全,还可利用安装程序生成一个自签名证书,需要注意的是该证书有效期只有60天;当然也可以指定已经安装证书的指纹,分配其使用。

1

2

3

4

        安装完毕后便可通过 “现代” 浏览器访问 Project Honolulu 的管理站点,去添加要管理的服务器。

5

        如果当前下的设备未加入到域(AD - 活动目录),需要在 PowerShell 下使用 Set-Item 指令手动配置 TrustedHosts,才能完成账户验证以管理远程服务器,命令行参考如下:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value '*'

Set_WSMan_TrustedHosts

        最后确保 Windows 防火墙已放行 Windows 远程管理(WinRM)以允许通过端口 5985 进站访问。

WinRM_5985

        对于受管理的 Windows Server 2012 服务器,可能需要额外安装 Windows 管理服务框架,请移步微软下载中心获取“Windows Management Framework 5.1”。

HOWTO: 修复 WINS 解析信息没有更新 记录格式已损坏 问题

        前段时间为一个 AD 做了个 FSMO 的转移,之后对新 DNS 服务器进行了记录的手工清理工作,在对 DNS 中原有的 WINS 信息进行更新时发现报错,也无法执行删除操作,具体错误提示为 “WINS 解析信息没有更新。记录格式已损坏。

WINS_Error

        使用 DNS 管理器已是无济于事,只能借助强大的 PowerShell 命令。咨询微软技术支持了解到可以使用 Remove-DNSServerResourceRecord 命令清理域相关的记录,具体的指令如下:

Remove-DNSServerResourceRecord -ZoneName contoso.com -Force -RRType "WINS" -Name "@"

        之前 gOxiA 分享了一篇日志“HOWTO: 基于 Windows Server iSCSI 服务创建 RAM Disk ”,由于该方法会导致服务器管理无法正常访问 iSCSI 目标服务器,可能会影响管理员日常操作。

        如果您体验完毕可以使用以下 PowerShell 步骤去删除 RAM Disk,否则对 iSCSI 目标服务的管理都要基于 PowerShell 进行。删除 iSCSI RAM Disk 的方法很简单,就是倒着执行一遍之前的命令,只不过将新建改为移除。

        首先,移除已经为 iSCSI 目标移除分配的 RAM Disk,为此执行如下命令:

Remove-IscsiVirtualDiskTargetMapping -targetName targetRAMDisk -Path "ramdisk:WIM-RAMDisk.vhdx"

remove-iscsivirtualdisktargetmapping

        然后,移除 iSCSI 目标,为此执行如下命令:

Remove-IscsiServerTarget -TargetName targetRAMDisk

remove-iscsiservertarget

        我们还能使用 Get-IscsiServerTarget 查看当前所有的 iSCSI 目标。

        最后,移除 RAM Disk,为此执行如下命令:

Remove-IscsiVirtualDisk -Path "ramdisk:WIM-RAMDisk.vhdx"

remove-iscsivirtualdisk

        上个月看到 Windows Team 的工程师 Mounia Rachidi 发布的 Blog,提到了在 Windows Server 上利用 iSCSI 创建 RAM Disk 的方法,于是动手实践了一下,感觉还不错!决定分享一下实践经验。

        实践环境是一台运行 Windows Server 2016,且拥有 32GB 内存的工作站。计划在内存中创建 28GB 的 RAM Disk,用于系统映像(WIM)的处理。将 WIM 放在 RAM Disk 里进行读写操作的优势显而易见,降低磁盘IO瓶颈。当然,也许您还能想到更多 RAM Disk 的应用场景,不妨利用 Windows Server  iSCSI 服务来体验一下。

        首先,我们需要为 Windows Server 2016 安装 iSCSI 目标服务器(iSCSI Target Server)角色,可启动服务器管理工具添加角色和功能。iSCSI目标服务器角色位于”文件和存储服务“角色下,具体参考下图:

iscsi_role

        然后,在 Windows 防火墙(Windows Firewall)中允许”iSCSI 服务“例外,即允许通过防火墙。

iscsi_service_mpssvc

        为了确保 iSCSI 目标服务能够为本机提供 iSCSI 服务,需要修改 Windows Server 2016 的注册表以允许回环模式,为此执行 Regedit 定位至如下路径,修改 AllowLoopBack(REG_DWORD) 值为:1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\iSCSI Target

iscsi_reg_allowloopback

        完成上述操作后,便可开始创建 RAM Disk,首先创建容量为 28GB 的 RAM Disk:

New-IscsiVirtualDisk -Path "ramdisk:WIM-RAMDisk.vhdx -Size 28GB

new-iscsivirtualdisk

        之后创建 iSCSI 目标:

New-IscsiServerTarget -TargetName targetRAMDisk -Initiatorlds @("IPAddress:X.X.X.X")

new-iscsiservertarget

        接下来将 RAM Disk 分配给 iSCSI 目标:

Add-IscsiVirtualDiskTargetMapping -TargetName targetRAMDisk -DevicePath "ramdisk:WIM-RAMDisk.vhdx"

add-iscsivirtualdisktargetmapping

        现在启动 Windows Server 2016 上的 iSCSI Initiator(iSCSI 发起程序,该程序位于管理工具组下) 来连接这个 iSCSI 目标。

iscsi_initator

        连接成功后,便可在通过磁盘管理器初始化这个 RAM Disk,默认配置下这个 RAM Disk 是动态扩展类型的 VHDX,所以分配并格式化后,不会马上占用内存容量,会随着 RAM Disk 数据量的增长,而发生变化,但不会因删除数据而逆转。也就是说拷贝了一个10GB的数据,删除后会发现内存占用还是10GB,必须重新启动服务器才会得到空间的释放。

diskview

        最后需要注意的是,在 iSCSI 目标服务上启用 RAM Disk 后,会导致无法正常访问 服务器管理器 下的 iSCSI 目标服务器角色。

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

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