为什么在使用 KMS 方式激活系统时会出现 0xC004F035 问题
为什么在使用 KMS 方式激活系统时会出现 0xC004F035 问题
故障环境是 WDS 部署企业定制的标准化映像，映像为 Windows 7 Pro X64，部署到一台 HP 设备上后出现 KMS 无法激活的故障问题，提示 “错误：0xC004F035 软件授权服务报告无法使用批量许可证产品密钥激活该计算机。……"，如下图所示：
其实这是一个不是技术问题的“技术问题”，因为获得批量授权许可的先觉条件是企业用户采购的设备是预装了 Windows 系统的，才能购买批量授权许可使用专业版或者企业版 Windows。
很明显这台 HP 设备的 BIOS 是清除过 SLIC 的，被标注为无预装系统的计算机，所以被 Windows 软件授权服务检测到未满足使用 KMS 激活的条件，那么比较简单的解决方法即使用 MAK 密钥激活该计算机即可。
Project Honolulu 正式版发布为 Windows Admin Center
Project Honolulu 正式版发布为 Windows Admin Center
微软今天正式发布了 Project Honolulu 的正式版，其正式的名称为 Windows Admin Center，gOxiA 之前一直在这个 TAP 中，从 1711 到 1804 可以看出微软现在的开发速度之快，从测试情况看 WAC 质量非常高。
正如之前日志说讲 Windows Admin Center 设计初衷并不是要替代现有的 Windows 管理工具，Windows Admin Center 在现代化、简化、集成和安全的远程管理体验中汇集了许多以往管理工具的特性，可供大家有更多的选择。Windows Admin Center 通过以下特性帮助IT管理员：
- 简单和现代管理经验：Windows Admin Center是一个轻量级的，基于浏览器的GUI平台和工具集，供IT管理员远程管理Windows服务器和Windows 10 计算机。
- 混合功能：Windows Admin Center可以在任何地方管理Windows Server 和 Windows 10实例，其中包括物理系统、任何管理程序上的虚拟机或在任何云中运行。使用可选的增值功能（如与Azure站点恢复的集成）连接到云以保护虚拟机，并支持Azure活动目录以使用多因素身份验证来控制访问。
- 集成工具集：与其在几个不同的工具和上下文之间切换，不如通过Windows Admin Center管理中心对IT资源进行全面概述，并能够深入了解详细信息。除了服务器和客户端计算机外，还允许管理故障转移群集和超聚合基础结构（HCI）部署。
- 可扩展设计：微软一直在与早期使用者、合作伙伴协作，在SDK的私有预览中改进扩展开发体验。这意味着用户很快就可以将Windows Admin Center的功能扩展到第三方解决方案。例如：用户将开始看到第三方硬件供应商使用Windows Admin Center 提供自己的硬件管理。
Windows Admin Center 下载：http://aka.ms/WACDownload
Windows Admin Center 文档：https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center
[WDS] 通过 WDS 为 Windows 10 部署提供驱动安装支持
WDS（Windows Desployment Services）即 Windows 部署服务，其架构需求简单，配置灵活，使用起来轻松直观，所以深受企业 IT 服务台的青睐，常用于简单需求的 Windows 桌面系统安装场景。在一些管理级别不高的企业，为了简化管理和部署过程，WDS 中的系统安装映像通常使用的是集成了万能驱动的版本，但是对于复杂多样的企业 IT 环境，此法反而弄巧成拙，导致交付到用户手里的 Windows 设备经常会出现蓝屏、性能低下等异常的故障。
其实 WDS 本身也提供驱动部署的支持，只是基于数据库结构管理，所以刚上手的用户可能对其操作流程并不适应，时常会因操作出错，而需删除已有的配置重新来过。今天 gOxiA 将与大家分享 WDS 驱动管理方面的知识和经验，为了方便说明专门整理了一张图希望能够让更清晰明了的让大家了解。
WDS驱动管理是基于数据库结构管理的，对于驱动文件本身的管理其实非常简陋，并不是很智能。其完全依赖筛选器来进行管理和部署驱动，而筛选器可提供的选项又并非满足大家的需要，所以在使用WDS进行驱动管理时应该遵循如下的流程规范：
1、先创建驱动组，驱动组基于设备机型及系统架构来创建，例如我们要通过 WDS 为 ThinkPad X270 部署 Windows 10 Pro x64，那么我们可以先创建名为“Lenovo-X270-Win10x64”的驱动组。为了确保该组下所有的驱动都能被正确安装，所以建议选择“安装此组中的所有驱动程序包”。
2、导入驱动包，将厂商发布的 Drivers Pack解压缩，并添加到WDS中，因为是要批量导入驱动，所以选择“从文件夹中选择所有驱动程序”，这样向导将遍历目标路径下的所有子目录添加驱动。如果企业驱动库位于一个UNC路径，可先通过资源管理器访问并复制路径填写到位置栏。
可用的驱动程序包界面可看到搜索到可添加到WDS驱动库的驱动程序，大家会注意到体系结构包含x64、x86，甚至有些还会包含IA64，如果要导入的驱动数量较少，或者你不嫌麻烦，可以在如下图步骤中去除那些不适用于X64架构的驱动，因为大家应该记得，前面的驱动组添加过程中我们配置为“安装此组中的所有驱动程序包”，如果导入的驱动不适用于X64架构，如包含了X86或IA64驱动，将导致WDS部署客户端操作系统时，在“特殊化”阶段报错，导致安装失败。
导入驱动后，可能会提示部分驱动无法导入到WDS驱动库中，这是因为部分驱动未包含签名，可能会导致设备出现意外故障。通常我们可以忽略，如果在WDS部署客户端设备后发现有未知设置未能成功安装驱动，可单独联系厂家获取驱动。
添加到驱动组这一步非常重要，WDS的运维人员在这一步的操作一定要谨慎，不要出错，因为WDS的驱动管理完全依赖筛选器，如果这一步出现错误，可能会导致我们要推翻之前所有的驱动操作，重新来过一遍。
3、修改驱动组筛选器，前面的步骤我们已经完成了对应设备机型的驱动组及其对应驱动的添加，那么如何确保创建的驱动组能正确匹配到要部署系统的客户端设备上呢？！为此，我们需要为驱动组添加一些筛选器，确保其与设备和映像匹配。为了确保设备机型与驱动组匹配，需要为驱动组添加“制造商”和“型号”筛选器。
制造商即设备的品牌，如本例中 Thinkpad X270 的制造商为 LENOVO，而其型号却为 20K6A00DCD，那么我们该如何确认一个设备的制造商和型号信息呢？！有两个办法，从包装盒获取，不同时期发布的产品或批次，这些名称可能都不会相同；另一个办法是使用 WMIC 指令，如：“wmic csproduct get …”其中 … 为 vendor 时是提取设备制造商名称，而为 name 时是提取设备型号。
在制造商和型号通过筛选器匹配后，我们还需要确保驱动组与映像进行匹配，所以我们继续添加如下筛选器：“OS版本”和“映像ID”，其中 OS版本 可在安装映像属性中查看到，但是需要注意筛选器中的OS版本包含两个信息，一个是映像版本，还需要加上 Service Pack 级别，以本案中的 Windows 10 为例，那么其最终的 OS版本号应为 10.0.16299.0。
而映像ID 获取相对来说就较为繁琐了，在 WDS 管理器中是无法查看映像ID的，需要通过命令行进行操作，参考如下：
借助 WDS 的命令行获取映像ID，“wdsutil /get-image /image:”Windows 10 Pro” /imagetype:install /imagegroup:”Windows 10 x64”，gOxiA 建议获取到的映像ID单独存储在一个文本文件中，便于日后查看。此外，映像ID是添加映像文件（WIM）到WDS时产生的唯一值，如果你删除重新添加了映像那么其ID便会变更，但是如果你使用替换映像的操作方式，则不会影响到映像ID。
4、删除驱动，前面的三个步骤完成后驱动的导入即告结束，但请不要忘记因为我们导入的驱动包含X86和IA64，所以我们需要使用WDS的删除驱动功能来帮我们从驱动组剔除掉无用的驱动程序。过程很简单。打开删除驱动对话框，添加搜索筛选器，选择要从哪个驱动组删除驱动，并指定要删除的驱动架构版本，搜索到后便可批量删除。这里需要注意的是，虽然我们能够通过筛选器来删除特定组中的驱动，但是如果其他组有相同的驱动时，执行删除的操作也会从在其他组中生效。
对于WDS的驱动管理，基本就是导入和剔除驱动，不要想着可以利用筛选器去满足更多的需求，因为稍有不慎就会导致整个WDS驱动库推翻重来。
