本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m转载文章,请务必保留出处与作者信息。否则,切勿全文照抄!未经许可严禁用于商业用途!
HOWTO:解决 WinRM 服务无法创建以下 SPN... 的 WinRM ID10154 警告
HOWTO:解决 WinRM 服务无法创建以下SPN… 的 WinRM ID10154 警告
当在 Windows Server 2008 R2 上安装 Active Directory 服务后,重新启动服务器会收到类似“WinRM 服务无法创建以下 SPN: /WSMAN/DC.contoso.com; WSMAN/DC。”的警告!来自于系统日志,事件来源:Windows Remote Management,事件ID:10154。具体的错误信息如下图所示。
根据事件属性中的提示使用 setspn.exe 创建了相关的 SPN 未果,又在网上使用中文关键词进行了查询仍没有任何收获,而使用英文时能找到几篇相关的帖子,根据提示进行了排错也都未能解决问题(让使用 Adsiedit 修改 CN=AdminSDHolder 的安全属性)。最后没辙,通过微软中文技术论坛向 Partner Support 寻求帮助,得到的解答与网上搜索到使用 Adsiedit 修改相关安全属性的方法一致,但是唯一不同的是要修改 CN=ServerName 的安全属性,赋予 Network Service 账号对该对象有”已验证的到服务主体名称的写入(Validated Write to service principal name)”的权限。由于解答中权限部分使用的是英文,害得 gOxiA 理解了半天,不过还好最终算是解决了!赋予了账号权限后,重新启动 WinRM 服务,会发现“WinRM ID10154”警告消失(出现的“WinRM ID10149”警告可以忽略)。
![]()
最后补充一下出现该警告的原因是:Network Service 在这个 Object 上没有相关的 ACE,所以 WinRM 没能建立日志中提到的 SPNs。
HOWTO:解决 DFS 命名空间服务无法初始化该域控制器上的跨林信任信息
HOWTO:解决 DFS 命名空间服务无法初始化该域控制器上的跨林信任信息
网友反馈,在 Windows Server 2008 R2 上安装 Active Directory 服务之后,重新服务器可能会收到“DFS命名空间服务无法初始化该域控制器上的跨林信任信息……”的错误警告。但是根据实际的测试,该问题的出现几率很低,但是确实也有发生。
出现该错误警告的原因是由于 DFS 服务在 Active Directory 初始化完毕前就进行访问,所以要解决该问题只需要将“DFS Namespace”服务改为“自动(延迟启动)”即可。如果重新启动服务器后还会有该错误警告日志,可以尝试修改注册表,为 DFS Namespace 服务配置依存关系,为其添加依赖“NTDS”服务。为此执行下面的步骤:
运行注册表编辑器,定位到下面的注册路径:
修改 DependOnService 的键值,重起一行并添加“NTDS”。
在 Windows Virtual PC 上使用 Windows Server 2008 Core
在 Windows Virtual PC 上使用 Windows Server 2008 Core
Virtual PC Guy's Blog 发布了一篇日志与大家分享如何在 Windows Virtual PC 上使用 Windows Server 2008 Core,gOxiA 看完感觉还是有一定价值的,特总结一下在本 Blog 与大家分享。在 Windows 7 上我们目前主要使用 Windows Virtual PC 作为虚拟机平台,虽然相比 Microsoft Virtual PC 2007 有了诸多的改进和增强,但是显然也存在一些不足,缺乏虚拟机平台的通用性,可能是跟 Windows 7 集成度太高而给人的一种错觉!不过也不难理解,毕竟叫 Windows Virtual PC 嘛!回到正题,在 Windows Virtual PC 上创建一个虚拟机,然后安装 Windows Server 2008 Core 版本,为了能够轻松地在窗体之间切换和使用增强功能,我们需要为虚拟机安装 Integration Components,但是你会发现安装会失败并提示下图中显示的警告!
出现该故障的主要原因就是因为 Windows Virtual PC 创建的虚拟机中包含声卡设备,所以根据《Using Windows Server 2008 Core on Windows Virtual PC》文中的提示,我们只需要修改虚拟机的配置文件 – VirtualMachineName.vmc,找到 Sound 段落,将其 “enable type=”boolean””的设置由 True 改为 False ,最后重新打开虚拟机安装 Integration Components 即可!
虽然大家都已经开始在学习 Windows Server 2008 R2,而 Windows Virtual PC 不支持 64bit guest OS,所以该文的价值并没有想象中那么大,可是起码能够引导我们重视这些配置文件,也许在深入发掘之后有其他更大的收获!
[MDT] 使用 Sysprep and Capture 任务序列创建系统映像
继之前两篇日志《解决 A connection to the deployment share could not be made. The deployment will not proceed.》和《解决 Capture 时出现的 Unable to validation connection because a blank UNC was specified. 错误》,我们对 MDT 的 Sysprep and Capture 任务序列已经有了非常深入的了解和认识,但是 gOxiA 在测试一台位于工作组级别的计算机执行 Sysprep and Capture 任务序列时仍旧提示 the deployment will not proceed 错误,几经波折发现在访问和执行 MDT 共享目录下的脚本时是需要技巧的。测试成功之后不敢独享,特撰文出来与大家探讨!
按照常规的操作我们通常会打开网络邻居键入 MDT 的共享路径,而该共享路径默认配置为 ShareName$,当工作组级别的计算机在访问时又需要进行身份验证,故几次测试 Sysprep and Capture 任务序列都失败告终(PS:当计算机加入到 AD 后无此问题,很纳闷!),最后发现当把 MDT 的 ShareName$ 映射到本地 Z: 后故障消失!看来 MDT 脚本存在一定的问题,不管怎样问题得到了解决,要正确执行 Sysprep and Capture 任务序列,则强烈建议通过命令行执行脚本,大致步骤如下:
之后提示键入验证用户的密码,随后执行:
之后在 cmd 环境会出现脚本执行的详细细节,之后直接探出任务序列选择列表,这点与之前的执行过程略有不同,无需再次验证身份。在任务序列选择列表中,选择执行 Sysprep and Capture,跟随向导确定完成,最后就出现于下图所示的任务执行截图。
虽然问题都已经得到了解决,但是 gOxiA 总感觉之前的 《解决 A connection to the deployment share could not be made. The deployment will not proceed.》 失去了意义,迫于精力有限无法继续证实,还望有条件的朋友能继续测试给于不同的见解和意见!
[MDT]解决 Capture 时出现的 Unable to validation connection because a blank UNC was specified. 错误
在 MDT2010 中微软设计添加了一个新的任务序列,即:Sysprep and Capture。利用该任务序列,管理员可以轻松地对已经安装好的系统执行系统准备和捕获,以便于以后做批量部署之用。
Sysprep and Capture 任务序列将从 MDT2010 服务器复制一份包含 Capture 功能的 Windows PE,并在当前系统上创建一个一次性引导信息,使当前系统在自动执行了 Sysprep 后,启动计算机时能自动引导进入 Windows PE 中执行 Capture。MDT2010 默认配置下,我们执行该任务序列时会指定 Capture WIM 的存储路径,但是如果之前在 Rules 中添加过自动化参数 SkipCapture=Yes,那么我们将遇到下面图中的错误警告信息,即:“WARNING – Unable to validation connection because a blank UNC was specified.”导致任务序列执行失败。
要解决这个问题,我们可以将 Rules 中配置的 SkipCapture=YES 删除,之后在执行任务序列时手工输入 Capture WIM 的存储路径。或者继续完善自动化任务所需的参数数据,使之能够自动执行 Capture WIM 任务序列。为了减少管理员干预次数,我们将预先配置 Capture WIM 时所需的参数数据,此例主要包含3个参数:ComputerBackupLocation、BackupShare 和 BackupDir。
其中 ComputerBackupLocation 即备份位置,可以是 Network - 网络、Specific Path - 特定路径、Auto - 自动 以及 NONE。这里我们选择使用 Network,将 WIM 存储在网络中。
之后我们要指定这个网络共享路径,即:BackupShare,如:“\\MDTSRV\DeployShare$\Captures”。
由于 Sysprep and Capture 任务序列会被复用,为了避免与其他已经 Capture 机器的 WIM 冲突,我们可以使用 BackupDir 参数,并赋予其一个 MDT 变量值 - %OSDComputerName%,这样就会在 \\MDTSRV\DeployShare$\Captures 目录下创建一个以计算机名为名称的目录。
当了解了各个参数的作用后,我们就可以将这些参数写入到 Rules 中,格式如下:
如果当前已经为 MDT2010 配置了数据库,那么我们可以在 Database – Locations 中创建一个位置,并为其 Details 选项卡中的 User Data 部分配置这些参数数据,如下图所示!
之后再行测试,“WARNING – Unable to validation connection because a blank UNC was specified.”故障问题消失!至此,我们也对 Sysprep and Capture 有了比较深入的了解和认识。
[Hyper-V] 增加 VMBus 缓冲区大小来提升虚拟机网络吞吐量
增加 VMBus 缓冲区大小来提升虚拟机网络吞吐量
今天在 Windows Server Performance Team Blog 看到一篇非常有价值的文章《Increase VMBus buffer sizes to increase network throughput to guest VMs》,主要介绍了如何通过增加 VMBus 的缓冲区来提升虚拟机网络的吞吐量。由于原文的介绍已经相当详细,小弟我也就不班门弄斧!简单来讲,Hyper-V 提供的 VMBus 架构是非常优越的,由于虚拟网络的数据交换是通过 VMBus 到物理网卡的,所以 Virtual Switch 能够提供充足的缓冲,我们可以利用该特性有效的改善传统网络中出现的因吞吐量导致的数据包丢失问题。在 Windows Server 2008 R2 上默认的缓冲区大小为 1mb,它能提供 655 个数据包缓冲(每个缓冲区 1600 个字节)。根据原文的建议可以将其缓冲增加到 2mb(最大有效值是 4mb),能够满足大多数的情况。除非你有足够大的内存,否则不建议设置到 4mb。
要增加 VMBus 缓冲区的大小只需要修改虚拟机的网卡(Microsoft 虚拟机总线网络适配器)注册表相关项增加两个 DWORD 值即可。执行此操作前我们需要先确认虚拟机网卡的“驱动程序关键字”便于在注册表中定位,为此在虚拟机中打开硬件管理找到网卡适配器进入其属性下的详细信息选项卡页面,在属性列表中选取“驱动程序关键字”,将该值记录下来。
接下来打开注册表编辑器,根据之前记录下来的值定位到类似下面的注册表位置上,并添加名为:ReceiveBufferSize 和 SendBufferSize 的 DWORD 键,设置其值为:800
最后重新启动虚拟机即可。由于本人英语水平有限,无法完全正确地翻译原文介绍,以及表达我个人的理解意思,文中有错误的解释欢迎大家指正。
硬件虚拟化技术检测工具 - Microsoft Hardware-Assisted Virtualization Detection Tool
Microsoft Hardware-Assisted Virtualization Detection Tool
除了微软最新的虚拟化平台,目前几乎所有的虚拟化平台都要求 CPU 支持 Hardware-Assisted Virtualization ,如:AMD-V、Intel VT 以及 VIA VT。为了检测我们的 CPU 是否支持该项技术,我们经常要在不同硬件厂商的主页里寻找检测工具,而且检测结果的标识结果让用户难以理解!
现在我们可以使用微软官方发布的工具对我们的 CPU 进行检测,以检查是否满足 Windows Virtual PC 的硬件需求,该工具的用途主要是检测 CPU 是否支持硬件虚拟化技术,所以检测结果并不能用于鉴定当前硬件是否也满足 Hyper-V 的需求。
Microsoft Hardware-Assisted Virtualization Detection Tool 的官方下载地址是:http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ee2a17f-8538-4619-8d1c-05d27e11adb2






















