hero_edge_sufandesktop

Surface Pro 4 批量部署系列 – Windows 10 激活

        回顾上一篇文章“Surface Pro 4 批量部署系列 - 驱动程序安装 ”我们掌握了 Surface Pro 4 批量部署时驱动程序的处理,并且可以参考“HOWTO: 在执行 Sysprep generalize 后保留预部署的硬件驱动 ”,在执行 Sysprep 时保留驱动,以加速部署速度,接下来我们就可以应用这个映像进行测试。

        Surface Pro 4 随机预装 Windows 10 Pro 版,并支持自动激活,本以为联网激活的时候会自动提取主板固件中的密钥,但实际测试并没有那么智能。所以要实现免序列号自动激活 Surface 必须先解包原厂系统执行 OOBE 联网激活系统一次,否则就需要单独输入有效密钥来激活。

        Windows 10 的激活技术是进行了改进,OEM 版每个主板都内置一个唯一的密钥,而不管是OEM还是零售版,这个密钥在首次激活后会绑定当前设备 GUID 或 LiveID,所以当以后再执行干净安装时就能在联网的时候自动识别,并激活系统。改进的激活技术确实很方便,但对于批量部署的用户来说,将是“噩梦”!单单解包原厂系统就要耗费掉不少时间,更别说后续还要部署定制版系统。

        gOxiA 就经历了这个过程,之前测试环境是一台已经激活的 Surface Pro 4,封装镜像测试激活正常后,开始分发!后续便遇到了新拆封从未激活的Surface设备,起初的报错信息是 0x2a 0x803F7001,中文提示 0x803F7001 在运行 Microsoft Windows 非核心版本的计算机上,按照提示执行 slui 查看具体的错误信息。

IMG_20161011_155900

        从错误信息上看并没有什么价值,难道是序列号对应的 SKU 不对,换了几个密钥均没有解决,随后联系微软技术支持,使用 WCF 的 Error 查看工具分析了代码得知是网络问题,果然在调整 HOSTS 后测试环境下的Surface能够激活了,但发现在分发给新设备后还是会报错误,导致无法激活。

snipaste20161031_135253

        几经折腾,最后才意识到是因为使用通用密钥是无法激活新拆封的设备的。期间也尝试提取原厂系统的文件,发现密钥部分是加密的,而且也证明激活程序不会自动提取主板固件中的 OEM 密钥,那么原厂系统的预置的密钥应该是一个真正意义上的黄金密钥,可惜被加密了,也只能放弃!除了恢复原厂系统,唯一的希望就是从主板固件提取密钥,还好微软为我们预留了 WMI 接口,我们只需要利用 WMI 把 OA3xOriginalProductKey 的值提取出来即可,拿到了唯一的密钥就可以使用 slmgr 来重新激活 Surface Pro 。

        注:OA3xOriginalProductKey 位于 SoftwareLicensingService 下。

Tags: , , , ,

Co3p9r4XYAAb_t8

为 Windows 10 强制启用暗黑主题

        自 Windows 10 年度更新发布后,gOxiA 就喜欢上了全黑色系的暗黑主题(Dark Theme),一股脑的将 Windows 和 Office 都设置为了全黑色,虽然是喜欢但实际使用中还是需要一个过程。默认情况下通过个性化设置众的颜色,便可开启深色主题,也就是我们常说的暗黑主题。但这个选项有时却很诡异的消失了。如下图所示,不知道是打了某个补丁的原因,还是因为更改了系统语言,而且提示貌似也并不搭边。这个时候恐怕只有手工修改注册表,才是最快速解决之道。

sp20161026_163527

        针对当前用户设置,我们只需要启动注册表编辑器,定位到以下路径,新建一个名为“AppUserLightTheme”的 DWORD32 值为“0”即可,这样便可禁用浅色主题模式,并自动开启暗黑主题。

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize 

snipaste20161030_192221

hero_edge_sufandesktop

Surface Pro 4 批量部署系列 - 驱动程序安装

        Surface Pro 4 在企业环境中批量部署时需要考虑的问题和细节还是非常多的,目前 Surface Pro 4 出厂预装的系统为 Windows 10 Pro x64 1511 版本,在交付最终用户使用前通常需要对企业设备的系统进行定制,例如升级到最新版本,安装最新的系统补丁包、更新设备固件、常用工具、商用程序以及安全软件。由于 Windows 10 的周年更新(1607)已经发布,如果基于出厂预装系统进行定制,还需要进行夸版本的升级比较麻烦,为此会直接基于 1607 定制新的黄金镜像。在定制镜像时需要考虑的一个主要问题就是驱动。

        在进行标准化定制中,处理驱动程序的安装,通常会通过 MDT 加载驱动,并在安装过程中动态注入到系统中。但 gOxiA 在实践中发现默认的任务序列只会注入发现的设备驱动,这样就导致系统安装后一些设备并未完整的载入驱动,如下图所示:

mdtdrivers

        要解决这一问题,我们需要修改任务序列中的“Inject Drivers”部分,选择“Install all drivers from the selection profile”,这样在部署过程中就会将 Surface Pro 4 的所有设备驱动和固件强行注入到系统中,以完成后续的安装。

mdtdrivers1

        注意:如果当前部署解决方案框架包含多种设备,可以先创建一个 selection profile,包含 Surface Pro 4 的驱动,这样可避免将其他设备驱动也一同注入系统的问题。此外,在日后正式部署时 IT 人员应当确保 Surface Pro 4 在安装系统时的电量不低于 30%,因为 Surface Pro 4 的驱动包包含最新的固件程序,当电量低于 30% 时,系统策略会拦截固件的更新。

SDA

HOWTO: 解决 Surface Deployment Accelerator 的 Boot Drive was not found 错误

        在 Surface Deployment Accelerator 的道路上处处是坑,之前才出了因标点符号编码错误引发的脚本执行错误,这还没走几部就遇到了“FAILURE (5615): False: Boot Drive was not found, required?” 错误!

SDA-error-2

        SDA 的初始化其实就是自动创建一个适用于 Surface 设备部署的 MDT 部署点,所以在任务序列中会自动添加两个基本任务:1 – Deploy Microsoft Surface 和 2 – Create Windows Reference Image。gOxiA 在测试第一个任务时并未发现异常,知道开始测试第二个任务序列才遭遇到上面的错误,提示找不到引导驱动器。这个问题还是比较容易排错的,在测试客户端上使用 diskpart 检查磁盘,发现任务默认创建的分区有异常,随后在 MDT 中检查该任务序列,发现 Preinstall – New Computer only 组下只有一个分区格式化任务序列,真搞不懂这次是也是因为编码问题所致吗?怎么很明显的感觉是人为挖坑呢?!

        不管是人为还是什么原因,免费的解决方案还能过多要求什么呢?!自己动手改改就好,修正并创建两个分区格式化任务,一个针对 MBR,另一个则针对 UEFI。两个任务通过选项添加变量条件进行识别并执行。

MDT-Task1

        如上图所示,在 MBR 类型的任务选项中添加一条 Task Sequence Variable Condition,其中 Variable 为 IsUEFI,Condition 为 not equals,Value 为 True; UEFI 类型的条件则相反。最后修正分区格式化任务的卷设置,通常 MBR 类型是 499MB 为引导分区(FAT32),99%系统分区(NTFS),剩余 1%(实际创建时填写 100%) 为恢复分区(NTFS);而 UEFI 类型是 499MB 为引导分区,128MB 的 MSR 分区,99% 的系统分区和 1% 的恢复分区。

MDT-Task2

MDT-Task3

SDA

HOWTO: 解决中文环境 Surface Deployment Accelerator 初始化错误

        上一篇日志《Surface Deployment Accelerator - 安装》,gOxiA 介绍了 SDA 的安装和初始化,期间也是跳了不少坑,如果有开始体验的同学恐怕也会遇到一样问题,例如在中文系统环境下初始化配置时就会遇到莫名其妙的故障问题,如下图所示:

SDA-Error-0

        从错误提示上来看并无太明显的线索,ParserError 也没有给出具体的所以然,就是一堆乱码!以为是网络问题,还专门检查了网络也没有实质进展,看来还是只能从错误提示上找原因。报错的三个文件分别是:Install-WindowsADK.ps1、INSTALL-MDT.ps1、Config-DeploymentShare.ps1。除了开头乱码外,末尾 CLSID 值也包含乱码而且三个文件均在 CB00C0 位置。

        使用 PS 编辑器查看还像没什么问题,搜索 CB00C0 发现三个文件都存在这个 CLSID,而且单引号看起来像全角符号,联想到错误中的乱码问题,恐怕就是编码问题,果然当使用 Emeditor 编辑时提示要使用什么编码打开,问题算是找到了。接下来解决起来就容易很多,先新建一个 PS 扩展名的文本文件,并使用 UTF-8 格式 保存,然后在 PS 编辑器中修正编码错误的单引号,然后复制所有内容到 Emeditor 中,保存并进行覆盖即可。

SDA-error-1

        重新执行 Surface Deployment Accelerator 初始化向导,便可完成配置。

Suface Deployment Accelerator - 安装

[ 2016/09/17 11:13 | by gOxiA ]

SDA

Surface Deployment Accelerator - 安装

        Surface Deployment Accelerator(以下简称:SDA)是微软针对 Surface 商业用户发布的一个系统部署加速器,它是一款免费的部署工具,可自动创建和配置将 Windows 部署到 Surface 系列电脑所需的一切内容。旨在帮助 IT 人员快速将 Surface 系列电脑部署到企业环境中。

        作为一款针对 Surface 设备的软件工具,SDA 支持目前主流的 Surface 系列电脑,包括的型号有:

  • Surface Book
  • Surface Pro 4
  • Surface Pro 3
  • Surface 3
  • Surface 3 LTE 系列版本

        支持部署的操作系统版本:Windows 8.1、Windows 10

        Surface Deployment Accelerator 的安装环境有特定的需求,必须满足以下的先决条件:

  • SDA 应当安装在 Windows Server 2012 R2 或更高版本上
  • PowerShell 脚本执行策略必须设置为“不受限制”
  • Windows Server 2012 R2 环境下的网络上启用 DHCP 和 DNS
  • Windows Server 2012 R2 应当能够访问 Internet,并且 IE 增强的安全配置应处于禁用状态
  • Windows Server 2012 R2 应当安装 Windows 部署服务,以提供 PXE 请求
  • SDA 部署时需要 Windows 8.1 或 Windows 10 的安装源

        Surface Deployment Accelerator 按这样非常简单,首先从 Surface Tools for IT 下载页面下载 Surface Deployment Accelerator 安装包,然后在准备好的环境下执行安装。

        安装完毕后在程序列表中找到“Surface Deployment Accelerator”程序项并执行它,之后便会开始运行配置脚本。熟悉 MDT 的朋友应该一眼就能看出来 SDA 其实就是基于 MDT 打造的。在欢迎页面 SDA 给出了环境要求。其实在实践中直接安装在 Windows 10 上也是可以使用的,只是无法 PXE 网络引导。

2016-09-16 (1)

        第二步是验证系统,主要是三个部分:Powershell 执行策略、Windows ADK、MDT 2013 Update2,如果当前系统没有安装 ADK 和 MDT 接下来的步骤会先从 Internet 下载这两个软件,建议用户事先就安装好他们,避免因网络问题影响安装进度。

2016-09-16 (2)

        前面讲过,SDA 支持 Windows 8.1 和 Windows 10 的部署,如果接下来的实践中不涉及 Windows 8.1,可以选择略过直接在 Windows 10 支持选项页面进行选择。注意:两者必选其一否则无法继续!

2016-09-16 (3)

        在Windows 10 支持选项页面上,用户需要指定部署点本地路径,本例中 gOxiA 在 E 盘创建了一个名为“SDAWin10”的目录,Windows 10 的安装源位于 G 盘。

2016-09-16 (4)

        接下来的体验配置选项页面选择要支持的 Surface 系列型号,可以进行多选,并选择附加的工具“Surface Firmware Tool”、“Surface Asset Tag CLI Utility” 以及“Office 365 Pro Plus”,注意如果使用预先下载好的 Surface 驱动和工具进行离线安装,那么将不支持 Office 365 Pro Plus 的复选。离线安装可以节省大量的时间,并确保安装进度不会因网络问题出现中断,要使用离线安装只需要将手工下载的工具和驱动保存在一个单独的目录即可,zip 压缩包方式的驱动无需进行解压。

2016-09-17

2016-09-16 (5)

        虽然 gOxiA 是离线安装,但在接下来的安装过程里也好去了近10分钟的时间,因为过程涉及部署点的准备以及拷贝 Windows 安装源文件。

2016-09-16 (9)

2016-09-16 (10)

        当安装结束后用户可以在 Summer 页面看到结果,点击“Finish” 完成安装。至此 SDA 安装完毕,要开始使用只需运行 MDT 的 Deployment Workbench,你会发现 SDA 已经对 MDT 部署点进行了预先的设置。所以用户如果要使用 SDA 加速部署 Surface,是需要对 MDT 有一定了解的。

HOWTO: 重置 Windows 更新组件

[ 2016/09/16 23:07 | by gOxiA ]

windows-10-508x192-logo

HOWTO: 重置 Windows 更新组件

        这几天一直被 KB3189866 这个更新困扰着,两台设备都是卡在45%不再继续。像以往一样停止 Windows Update 服务去删除“SoftwareDistribution”目录发现有几个文件提示正在被使用无法删除,禁用 WU 服务重启再试无果。看来从 14393 开始 Windows Update 的运行机制发生了比较大的改变,貌似与“更新来自多个位置”有关,这个功能允许该电脑将以前下载的 Windows 更新和应用发送到本地网络上的电脑或 Internet 上的电脑,从而起到加快下载速度的目标。

        那么现在该如何正确的重置Windows更新组件呢?!首先要停止与更新相关联的所有服务,不再单单只是 Windows Update,需要停止的服务如下:

  • net stop bits
  • net stop wuauserv
  • net stop appidsvc
  • net stop cryptsvc

        然后删除更新相关目录和文件:

  • Del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat"
  • Del “%systemroot%\SoftwareDistribution”
  • Del “%systemroot%\system32\catroot2”

        最后重新启动电脑,再次执行更新应该就能解决常见的更新故障,如果依旧有问题可以常识重置 BITS 和 WU 的安全描述符,为此执行如下命令行:

  • sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
  • sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

        也可以常识重新注册相关服务的动态链接库:

regsvr32.exe atl.dll
regsvr32.exe urlmon.dll
regsvr32.exe mshtml.dll
regsvr32.exe shdocvw.dll
regsvr32.exe browseui.dll
regsvr32.exe jscript.dll
regsvr32.exe vbscript.dll
regsvr32.exe scrrun.dll
regsvr32.exe msxml.dll
regsvr32.exe msxml3.dll
regsvr32.exe msxml6.dll
regsvr32.exe actxprxy.dll
regsvr32.exe softpub.dll
regsvr32.exe wintrust.dll
regsvr32.exe dssenh.dll
regsvr32.exe rsaenh.dll
regsvr32.exe gpkcsp.dll
regsvr32.exe sccbase.dll
regsvr32.exe slbcsp.dll
regsvr32.exe cryptdlg.dll
regsvr32.exe oleaut32.dll
regsvr32.exe ole32.dll
regsvr32.exe shell32.dll
regsvr32.exe initpki.dll
regsvr32.exe wuapi.dll
regsvr32.exe wuaueng.dll
regsvr32.exe wuaueng1.dll
regsvr32.exe wucltui.dll
regsvr32.exe wups.dll
regsvr32.exe wups2.dll
regsvr32.exe wuweb.dll
regsvr32.exe qmgr.dll
regsvr32.exe qmgrprxy.dll
regsvr32.exe wucltux.dll
regsvr32.exe muweb.dll
regsvr32.exe wuwebv.dll

        不要忘记重置 Winsock 可以解决大部分网络访问异常的问题:

netsh winsock reset

        同时微软也为我们提供了故障诊断程序,可以自动诊断并修复问题。

windows-10-508x192-logo

HOWTO: 解决资源管理有两个 OneDrive

        上周 gOxiA 一个不小心把两个数据盘给误格了,数据损失近 2TB,整整耗费了1周的时间才将数据恢复,由于是主力机所以系统也只能重新安装,Windows 10 1607版,没想到刚安装完就发现一个问题,OneDrive 初始化设置完毕后在资源管理器中竟然看到两个图标目录,位于桌面下,十分诡异!既然是同名同路径,而且图标显示 OneDrive 的状态和右键功能都正常,说明这两个图标应该是通过注册表加载的标识符。

sp160908_160323

        标识符在系统中是具有唯一性的,否则也不可能出现两个同名图标,搜索 MSDN 了解到在注册表中 CLSID 分支存储着系统中所有 COM 类对象的数据,路径位于 “HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID}”,启动注册表编辑器定位到这个路径开始搜索关键词 OneDrive,看看会有什么收获!如下截图搜索到了很多 OneDrive 相关的标识符,其中有些 CLSID 下包含 ShellFolder 看起来挺有关联。

2016-09-10 (2)

        为了继续验证,启动了 Sysinternals 套件的 Process Monitor 工具对资源管理进行监测,因为重点怀疑的是注册表,并且问题在资源管理器中可以重现,所以进行了过滤,果然收集到了有价值的数据。从截图可以看到当 gOxiA 访问资源管理器的这两个 OneDrive 后,Process Monitor记录下了这两个图标的 CLSID,分别是:

{018D5C66-4533-4307-9B53-224DE2ED1FE6}

{D227B6E2-5C41-4EB2-BD76-51940CFD391F}

2016-09-10 (24)

2016-09-10 (26)

        既然找到了两个图标的 CLSID 那么就可以在注册表中缩小搜索范围了。继续搜索注册表锁定了问题范围,从下面截图可以看到在下面两个路径下存在 CLSID 记录,从注册表项的名称看确有关联。

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel

2016-09-10 (1)

        下来尝试修改“HideDesktopIcons”-“NewStartPanel” 下相关的 CLSID 值改为为 0,不隐藏图标进行测试。(注意:在进行注册表操作前一定要进行备份!!!)刷新桌面,可以看到出现了两个 OneDrive 图标,OK 问题可以锁定了!但奇怪的是当删除其中一个 OneDrive 的 CLSID 后,桌面仍有两个图标,而且资源管理其中也仍旧显示两个图标。尝试删除“Desktop”-“NameSpace” 下的项进行测试,发现两个图标的问题解决了!

2016-09-10 (23)

        虽然问题得到解决了,但是应该删除哪个 CLSID 呢?如何确定这两个 CLSID 哪个才是当前 OneDrive 所使用的呢?翻出之前 Process Monitor 监测的结果,可以看到 OneDrive 的配置项所在的位置。

HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive

        顺藤摸瓜再接再厉,找吧!

2016-09-10 (25)

        功夫不负有心人,HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive\Accounts\Personal,下面“NamespaceRootId”记录的 CLSID 值就是当前所使用的,至此可以收官了!

2016-09-09 (1)

        结束前做了一个小测试,删除了当前正在使用的 CLSID 项,发现从系统栏打开 OneDrive 时会报错。此外还有一个问题!虽然删除了资源管理器和桌面中的图标(注册表对应的项和值),但是监测发现,打开资源管理时还是会去读取已经删除的 CLSID,说明仍有残留,可是注册表中已经搜索不到这个 CLSID,检查 OneDrive 的配置文件仍一无所获,也许是一个 Bug 已经提交微软反馈中心,期待后续会彻底解决。(考虑重新做一遍系统,同步数据这事还是靠谱点好!!!)

 

image

HOWTO: 在执行 Sysprep generalize 后保留预部署的硬件驱动

        在 IT 设备部署中我们都会使用 Sysprep 对黄金映像进行初始化,默认情况下执行 Sysprep 后会删除当前系统中的所有设备驱动数据,使其在后续能应用在其他不同的硬件设备上。但是也有一些特例,例如 IT 人员针对一款笔记本设备做了软件的预定义,并测试这些软件在特定的硬件驱动版本上能够正常工作,那么就要确保在对当前实例执行 Sysprep 后,驱动能够被保留下来,同时也通过驱动的预部署加速后续的部署过程。

        一些传统的做法肯定是将驱动集成到部署过程中进行实时安装,其实无需那么麻烦!如果是针对性的系统映像,我们完全可以单独维护一份映像。在审核模式下就将所需的设备驱动安装完毕,然后启用 Windows 应答文件中提供的硬件驱动保留选项,实现我们的需求。

        为此,添加 Microsoft-Windows-PnpSysprep_neutral 中的 PersistAllDeviceIns 选项,将其设置为 true 即可。需要注意的是,因为该选项处于 generalize 阶段,所以在执行 sysprep 时就要进行加载。

image

参考文档: https://technet.microsoft.com/zh-cn/library/dd744391(v=ws.10).aspx

Co3p9r4XYAAb_t8

这个工具很好 - 微软快速助手

        在 Windows 10 首个年度更新(Build 10.1.14393)中包含了一个非常有价值的工具 - 微软快速助手,可以方便的让两个用户通过远程连接共享计算机,以便于帮助用户解决计算机上的问题。微软快速助手的使用界面非常直观,需要获取帮助的一方点击“获取协助”,填写提供帮助方的代码就可进行连接,之后点击允许共享屏幕即可让对方远程操作自己的桌面。

123

        这个工具非常的有价值,因为我们不必再购买第三方软件,就能够帮助到自己的亲友解决计算机相关的问题。对于提供协助的一方要启动一次远程协助也是非常方便,在快速助手的开始页面选择“提供协助”,会提示使用Microsoft Account(即LiveID)登录,登录成功后会生成一个6位的共享安全代码,如果在10分钟内未使用这个安全代码将会过期失效。

4

        下面来看看快速助手在连接到对方计算机后的操作界面,界面非常简洁。受助方可以通过顶部的工具条来暂停或停止桌面共享;而帮助方除了可以实时操控对方计算机系统外,还可以利用工具栏提供的功能对当前界面添加批注,也可以快速启动任务管理器。虽然目前的功能很简洁,但是足以满足使用需要。

5

6

        需要注意的是,你不能使用同一个 Microsoft Account 桌面登录进行远程共享连接,此外微软快速助手的界面看起来很现代,但他仍是一个 EXE 程序,进程名称为“quickassist.exe”,通过对该进程的实时监控发现,微软快速助手的连接机制并未采用点对点方式,而是通过微软站点进行两点的通讯数据中转,在监控窗口可以看到它使用443端口接到微软站点上,就是是443端口应该是加密通讯,除了拥有更好的网络穿透力,还提供了安全的通讯方式,因为需要使用 Microsoft Account 发起共享连接,而且必须通过微软通道中转,从而避免了被乱用的可能,降低了安全风险。

8

        从目前实际的使用状况来看,通讯稳定性和流程性还有待提高,而这一问题的主要根源还是国内用户访问微软的速度,但整体来说还是相当不错了。

        最后的温馨提示:要启动微软快速助手可以通过Cortana键入“快速助手”启动,也可以在“Windows 附件”程序组中找到。

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