ADS | WDS | BDD2007 | MDT 2008 | MDT 2010

WindowsUpdateLogo

HOWTO: 获取已安装的 Windows Update 列表

        在进行桌面标准化的系统更新补丁阶段,需要对客户端从 Windows Update 或内部 WSUS 安装补丁的相关数据进行整理汇总,便于后续的测试和评估,以确保生成适用于当前企业IT环境的系统版本,打造出卓越的黄金映像。既然要进行整理汇总,就需要将更新的补丁列表导出至文件,但是在“查看更新历史记录”和“已安装更新”中都没有提供导出视图列表的功能。

windowsupdatelist

windowsupdatelist_1

        还好通过 Windows 命令行能够实现,在 PowerShell 下提供了 Get-Hotfix 能够列出当前系统已经安装的更新补丁,如果列表的数据并非我们所需要的那样,可以通过参数自己指定要收集的信息。

get-hotfix

        例如,gOxiA 需要收集更新补丁的安装时间、当前计算机名、更新补丁KB号、更新补丁类型,以及更新补丁的说明网址,那么可以使用 PowerShell 命令行“Get-Hotfix |select-object installedon,csname,hotfixid,description,caption”,之后在利用管道通过 Export-csv 输出为 CSV 格式文档。

get-hotfix1

        此外,我们也可以使用 WMIC 提供的 qfe 命令参数进行处理,命令行非常简单"wmic qfe list /format:csv > c:\WAU_List.csv",相比较起来 Get-Hotfix 更灵活,但是 WMIC 便捷性更强些。

wmic_qfe_list_format_csv

        导出后的 CSV 可以利用 Excel 2016 内置的 PowerBI 功能通过查询方式从 CSV 中提取数据进行分析和列表的完善。

SearchCSV

Windows KMS Client Setup Keys

[ 2017/11/28 14:10 | by gOxiA ]

MSFT_logo_rgb_C-Gray_D

备忘专用,以后没有大的变更,将仅更新这篇日志。

Windows Server, version 1709

Operating system editionKMS Client Setup Key
Windows Server Datacenter6Y6KB-N82V8-D8CQV-23MJW-BWTG6
Windows Server StandardDPCNP-XQFKJ-BJF7R-FRC8D-GF6G4

Windows Server 2016

Operating system editionKMS Client Setup Key
Windows Server 2016 DatacenterCB7KF-BWN84-R7R2Y-793K2-8XDDG
Windows Server 2016 StandardWC2BQ-8NRM3-FDDYY-2BFGV-KHKQY
Windows Server 2016 EssentialsJCKRF-N37P4-C2D82-9YXRT-4M63B

Windows 10, version 1709

Operating system editionKMS Client Setup Key
Windows 10 Professional WorkstationNRG8B-VKK3Q-CXVCJ-9G2XF-6Q84J
Windows 10 Professional Workstation N9FNHH-K3HBT-3W4TD-6383H-6XYWF

Windows 10

Operating system editionKMS Client Setup Key
Windows 10 ProfessionalW269N-WFGWX-YVC9B-4J6C9-T83GX
Windows 10 Professional NMH37W-N47XK-V7XM9-C7227-GCQG9
Windows 10 EnterpriseNPPR9-FWDCX-D2C8J-H872K-2YT43
Windows 10 Enterprise NDPH2V-TTNVB-4X9Q3-TJR4H-KHJW4
Windows 10 EducationNW6C2-QMPVW-D7KKK-3GKT6-VCFB2
Windows 10 Education N2WH4N-8QGBV-H22JP-CT43Q-MDWWJ
Windows 10 Enterprise 2015 LTSBWNMTR-4C88C-JK8YV-HQ7T2-76DF9
Windows 10 Enterprise 2015 LTSB N2F77B-TNFGY-69QQF-B8YKP-D69TJ
Windows 10 Enterprise 2016 LTSBDCPHK-NFMTC-H88MJ-PFHPY-QJ4BJ
Windows 10 Enterprise 2016 LTSB NQFFDN-GRT3P-VKWWX-X7T3R-8B639

Windows Server 2012 R2 and Windows 8.1

Operating system editionKMS Client Setup Key
Windows 8.1 ProfessionalGCRJD-8NW9H-F2CDX-CCM8D-9D6T9
Windows 8.1 Professional NHMCNV-VVBFX-7HMBH-CTY9B-B4FXY
Windows 8.1 EnterpriseMHF9N-XY6XB-WVXMC-BTDCT-MKKG7
Windows 8.1 Enterprise NTT4HM-HN7YT-62K67-RGRQJ-JFFXW
Windows Server 2012 R2 Server StandardD2N9P-3P6X9-2R39C-7RTCD-MDVJX
Windows Server 2012 R2 DatacenterW3GGN-FT8W3-Y4M27-J84CP-Q3VJ9
Windows Server 2012 R2 EssentialsKNC87-3J2TX-XB4WP-VCPJV-M4FWM

Windows Server 2012 and Windows 8

Operating system editionKMS Client Setup Key
Windows 8 ProfessionalNG4HW-VH26C-733KW-K6F98-J8CK4
Windows 8 Professional NXCVCF-2NXM9-723PB-MHCB7-2RYQQ
Windows 8 Enterprise32JNW-9KQ84-P47T8-D8GGY-CWCK7
Windows 8 Enterprise NJMNMF-RHW7P-DMY6X-RF3DR-X2BQT
Windows Server 2012BN3D2-R7TKB-3YPBD-8DRP2-27GG4
Windows Server 2012 N8N2M2-HWPGY-7PGT9-HGDD8-GVGGY
Windows Server 2012 Single Language2WN2H-YGCQR-KFX6K-CD6TF-84YXQ
Windows Server 2012 Country Specific4K36P-JN4VD-GDC6V-KDT89-DYFKP
Windows Server 2012 Server StandardXC9B7-NBPP2-83J2H-RHMBY-92BT4
Windows Server 2012 MultiPoint StandardHM7DN-YVMH3-46JC3-XYTG7-CYQJJ
Windows Server 2012 MultiPoint PremiumXNH6W-2V9GX-RGJ4K-Y8X6F-QGJ2G
Windows Server 2012 Datacenter48HP8-DN98B-MYWDG-T2DCC-8W83P

Windows 7 and Windows Server 2008 R2

Operating system editionKMS Client Setup Key
Windows 7 ProfessionalFJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
Windows 7 Professional NMRPKT-YTG23-K7D7T-X2JMM-QY7MG
Windows 7 Professional EW82YF-2Q76Y-63HXB-FGJG9-GF7QX
Windows 7 Enterprise33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
Windows 7 Enterprise NYDRBP-3D83W-TY26F-D46B2-XCKRJ
Windows 7 Enterprise EC29WB-22CC8-VJ326-GHFJW-H9DH4
Windows Server 2008 R2 Web6TPJF-RBVHG-WBW2R-86QPH-6RTM4
Windows Server 2008 R2 HPC editionTT8MH-CG224-D3D7Q-498W2-9QCTX
Windows Server 2008 R2 StandardYC6KT-GKW9T-YTKYR-T4X34-R7VHC
Windows Server 2008 R2 Enterprise489J6-VHDMP-X63PK-3K798-CPX3Y
Windows Server 2008 R2 Datacenter74YFP-3QFB3-KQT8W-PMXWJ-7M648
Windows Server 2008 R2 for Itanium-based SystemsGT63C-RJFQ3-4GMB6-BRFB9-CB83V

Windows Vista and Windows Server 2008

Operating system editionKMS Client Setup Key
Windows Vista BusinessYFKBB-PQJJV-G996G-VWGXY-2V3X8
Windows Vista Business NHMBQG-8H2RH-C77VX-27R82-VMQBT
Windows Vista EnterpriseVKK3X-68KWM-X2YGT-QR4M6-4BWMV
Windows Vista Enterprise NVTC42-BM838-43QHV-84HX6-XJXKV
Windows Web Server 2008WYR28-R7TFJ-3X2YQ-YCY4H-M249D
Windows Server 2008 StandardTM24T-X9RMF-VWXK6-X8JC9-BFGM2
Windows Server 2008 Standard without Hyper-VW7VD6-7JFBR-RX26B-YKQ3Y-6FFFJ
Windows Server 2008 EnterpriseYQGMW-MPWTJ-34KDK-48M3W-X4Q6V
Windows Server 2008 Enterprise without Hyper-V39BXF-X8Q23-P2WWT-38T2F-G3FPG
Windows Server 2008 HPCRCTX3-KWVHP-BR6TB-RB6DM-6X7HP
Windows Server 2008 Datacenter7M67G-PC374-GR742-YH8V4-TCBY3
Windows Server 2008 Datacenter without Hyper-V22XQ2-VRXRG-P8D42-K34TD-G3QQC
Windows Server 2008 for Itanium-Based Systems4DWFP-JF3DJ-B7DTH-78FJB-PDRHK
Tags: , ,

win10creatorsupdate1703

HOWTO: 快速在 UEFI 启动的 Windows 10 中添加 Native VHD Boot

        今天又要与大家分享关于 Native VHD Boot 的小技巧了,搜索本站 gOxiA 已经写了不少关于 Native VHD Boot 的文章,虽然之前也有撰写“Windows 10 Native VHD Boot 案例分享”,但本文将向大家介绍如何在基于 UEFI 启动的 Windows 10 中添加一个 Native VHD Boot 实例,整个操作过程期间并不需要重启进入PE环境,完全就地解决。

        准备一个准备添加 Native VHD Boot 的安装源,可以是 ISO 也可以是 WIM,前者需要先 Mount ISO 到当前系统,以便于访问其中的 WIM;之后在当前卷新建一个目录用于存放 Native VHD Boot 的 VHD 文件,例如“C:\VHDBoot\”;接下来使用磁盘管理器创建一个 VHD 文件WS2012R2.vhd,存储在前面的目录中,建议使用固定大小,注意请务必转换为GPT磁盘,根据需要进行分区,格式化为NTFS。固定大小的 VHD 虽然占用了不少空间容量,但可避免不必要的麻烦;然后再释放 WIM 映像到这个 VHD 中,方法相信大家已经轻车熟路,使用内置的 DISM 命令即可完成,命令行可参考“dism /apply-image /imagefile:G:\sources\install.wim /index:1 /applydir:V:\”,映像应用完毕即可unmount VHD,现在就差创建启动信息。

        由于是系统在线环境,且引导卷处于隐藏状态,所以最为方便的添加 Native VHD Boot 启动信息的方案就是使用 BCDEdit 工具,基于默认启动项新建一个新的 Native VHD Boot 启动信息,修改 Device 和 OSDevice 选项指定到前面创建的 VHD 路径上,即可完成。为此参考如下命令行执行!

1. bcdedit /copy {default} /d "WS2012R2 Native VHD Boot"

2. bcdedit /set {GUID} device vhd=[c:]\VHDBoot\WS2012R2.vhd

3. bcdedit /set {GUID} osdevice vhd=[c:]\VHDBoot\WS2012R2.vhd

        现在重新启动便可以出现多启动菜单,可选择 Native VHD Boot 来启动系统,UEFI 比较不人性化的是当选择另一个启动项后会再次重启计算机,这个没办法 UEFI 的设计使然。是不是非常简单,只要理解了相关的概念,命令能够做到得心应手,就能针对不同场景制定实现方案!

image

HOWTO: 为 MDT Media LiteTouch 启用 WIM Split

        现在的系统映像容量是越来越庞大,像 Windows Server 2016 的 ISO 要想通过 UFD 以 UEFI 方式来安装,可真是要提前准备一番,2个 UFD 一个是 FAT32 格式的用来做 UEFI 引导,另一个 NTFS 格式的用来存储安装源,没办法WIM 超过了4GB,相信这个场景不少 ITPro 都曾遭遇过!尤其通过 MDT 的 Media LiteTouch 安装系统时,问题尤为突出!虽然前段时间 gOxiA 与大家分享了 Widnows 10 v1703 支持 UFD 创建多分区 的文章,在 MDT 实践中可以通过创建对应目录结构实现 Media LiteTouch 部署大容量自定义系统映像的需求,但之后的维护工作却非常繁琐。其实在 MDT 中已经提供了 WIM 的分卷功能,只是官方很少提及!截止到今日,官方与网上都没有一个明确的说明该如何为 MDT Media LiteTouch 启用 WIM Split。(PS:明显的坑,大坑!)

        gOxiA 抽出时间做了一下功课,对 MDT WIM Split 做个总结。WIMSplit 确实受 MDT 支持,但是官方并没有提供图形化的设置界面,我们需要修改配置文件中对应的选项参数来启用它。这个选项为“ <SkipWimSplit>False</SkipWimSplit>”,位于“settings.xml”中。也就是说只要在 Settings.xml 中将 SkipWimSplit 配置为 False 那么在对 Media 执行刷新时就会自动将大于 4GB 的 WIM 映像进行分拆。而网上普遍存在修改 SkipWimSplit 后并未生效的主要原因是选错了 settings.xml,问题就是这么简单!还没理解?!搜搜 settings.xml 都位于哪几个目录下?去修改主 settings.xml 就会作用到 Media LiteTouch。

        这个问题的起因完全是用户和开发者概念逻辑不统一所致!大家都认为应该修改 Media 下的 Settings,但实际上需要修改部署点的,在刷新 Media 时脚本会将系统映像分拆然后拷贝到 Media 下,完毕后会删除原始位置的 SWM文件。

SkipWimSplit

Co3p9r4XYAAb_t8

HOWTO: 解决 Windows DISM error ID3 0x80070003 故障

        DISM error ID3 的故障描述,自定义的 Windows 7 标准化系统映像测试正常,封装后在测试环境中部署时发现在 offline mode 下使用 DISM 对系统进行管理时操作失败,如下图所示 DISM 未能找到有效的 Windows 目录,但是当前系统路径确实是有效的,本以为是封装前的系统出现了异常,也反复进行了原始映像的测试,并对当前系统进行了检查并未发现有什么可疑的地方,无奈只能重点排查 DISM 日志!

snipaste20170116_111632

        在对 dism.log 文件进行了分析后,发现了详细的报错信息,DISM 在对脱机映像执行操作时发生了错误,“DISM OS Provider: PID=1420 Failed to mount the remote registry...(hr:0x80070003)”!复查系统映像创建中的配置修改以及后续部署时无人应答文件的设置,可算找到了线索在应答文件中对用户配置文件进行了重定向,该设置会将 Users 目录移动到其他分区,这就导致“All Users” 和“Default”目录也被移动,而 Default 目录包含默认的注册表数据文件(NTUSER.DAT),当 DISM 对脱机映像管理时会去 Mount 这个注册表数据文件,所以最终导致操作失败。

dism_error_cbs_log

        而要解决这个问题的办法还是相当简单的,就是在系统所在分区创建一个相同的目录结构(C:\Users\Default\), 并将 Windows 安装源(Install.wim)中的 NTUSER.DAT 文件拷贝过去即可。在微软官方的知识库(KB2293874)中确认了这是一个已知的问题。

        随后 gOxiA 在 Windows 10 上也重现了这个故障问题,dism.log 中记录的错误提示稍有区别,但意思完全相同,所以解决方法一致。为什么时隔7年这个问题仍旧没有解决,恐怕也只有产品组的人员知道!不过也完全可以理解,在企业环境中要重定向用户配置文件目录通常会使用组策略进行设置,此法不会移动系统级的目录;而直接通过应答文件的做法恐怕也是极为罕见的场景需求。

UserProfileError

snipaste20170118_164951

Co3p9r4XYAAb_t8

HOWTO:  通过预先配置 TrustedImageIdentifier 以加速 Windows 10 黄金映像

       Windows 10 应答选项中包含一个参数 - "TrustedImageIdentifier",位于 "amd64_Security-Malware-Windows-Defender_neutral"下,利用这个参数设置可以加速 Windows 10 黄金映像的运行速度,即在应答文件中的初始化阶段添加一个 GUID 值,告知 Windows Defender 该系统映像是安全的,这样 Windows Defender 便不会对系统进行扫描。

        使用和维护 Windows Defender 的 IT 人员应该了解,因为 Windows Defender 在初始化的系统上会对系统主要文件进行扫描,以确保文件安全,如果没有单独执行一次完整的扫描,便会在后台进行调度,这样一来便会影响系统的运行速度,所以这就是为什么全新安装的系统在期初运行时会感觉慢的原因。

        要预先配置“TrustedImageIdentifier”需要进行两个步骤,在应答文件中添加 TrustedImageIdentifier 对应的 GUID 值,并为当前参考映像环境的注册表指定位置添加对应的 GUID 值。为此我们执行如下步骤:

        第一步,使用 Windows System Image Manager(该工具位于 WindowsADK 中)先创建或修改 Windows 安装应答文件,在 Windows 编录下的 Components 中找到“amd64_Security-Malware-Windows-Defender_10.0.14393.0_neutral”,将其添加到应答文件的“4 specialize” 阶段,然后为 TrustedImageIdentifier 填入系统的 GUID 值。

TrustedImageIdentifier_GUID

        第二步,在参考映像(即黄金映像)系统中打开注册表编辑器,定位至“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender”,并添加一个新的字符串,命名为“TrustedImageIdentifier”,其值为之前在应答文件中设置的 GUID。

TrustedImageIdentifier_regedit

        完成上面的两个步骤就可以对黄金映像进行打包(Sysprep)以便于分发给最终用户。值得注意的是在修改注册表时管理员是没有修改权限的,所以需要先拿到所有权再进行修改;另外,如果很不幸你在分发部署黄金映像后发现该映像存在安全问题,那么可联系 Windows Ecosystem Engagement team 并提供映像的 GUID 值,这样微软会将这个不安全的 GUID 更新到 Windows Update 中,Windows Defender 在更新后会对当前系统执行完全扫描。

        最后提供两篇微软官方的参考资料:

TrustedImageIdentifier:

https://technet.microsoft.com/en-us/library/hh825450.aspx

Configure a Trusted Image Identifier for Windows Defender:

https://technet.microsoft.com/en-us/library/hh825233.aspx

hero_edge_sufandesktop

Surface Pro 4 批量部署系统 - 应答文件优化

        Surface Pro 4 的批量部署工作已经结束,也算有时间能够继续完善这个系列的经验总结。在开始前先回顾一下之前已经发布的两篇文章“Surface Pro 4 批量部署系列 - 驱动程序安装”、“Surface Pro 4 批量部署系列 - Windows 10 激活”。Surface Pro 4 与常规设备系统部署基本一致,主要考虑的问题就是驱动的注入和新系统的激活。驱动的注入主要是考虑提前在映像中安装驱动,以加速部署速度,并可脱离 MDT 进行独立安装;Windows激活主要是考虑新系统只是应用自定义映像,授权方式并不修改,而新 Surface 设备直接重装自定义系统后会导致预激活信息丢失,必须手工提取OA3密钥进行激活。

        剩余的主要考虑事项恐怕就是应答文件的优化,虽然我们会对系统映像进行预先定制和设置,但是为了确保这些修改在后续生效,或者做个双保险,又或者一些设置必须通过应答文件设置,所以我们还是需要针对部署用的应答文件进行修改和完善。

  1. SkipRearm = 1,因为系统映像会阶段性的进行修改、完善,所以会多次进行 Sysprep 操作,为了确保系统保留有效次数的Rearm,建议在 Generalize 阶段跳过 Rearm。  
  2. InputLocale = 0804:00000804
    SystemLocale = zh-cn
    UILanguage = zh-cn
    UserLocale = zh-cn
    由于 MDT 是一种部署加速解决方案,所以它并不会像应用程序那样智能,能够通过当前系统环境来自动配置应答文件中涉及的语言设置,所以默认情况下 MDT 的默认应答文件均以英文环境来进行设置。而我们通常会为客户端部署中文版系统,所以需要对应答文件的几个阶段进行配置修改,它们是:
    1 windowsPE
    3 generalize
    4 specialize
    7 oobesystem  
  3. TimeZone = China Standard Time,原因同上所以我们需要针对  specialize 和 oobesystem 阶段的时区配置进行修正。  
  4. 由于批量部署应用在企业环境下,为了使预定制映像中的系统桌面环境能够应用到每个登录到系统上的用户账号,需要配置 specialize 阶段的 CopyProfile = True,以启用默认用户配置文件拷贝。  
  5. 在 specialize 阶段添加 DisableSR = 1,以禁用系统还原。  
  6. 在 specialize 阶段添加 fDenyTSConnections = false,以启用远程桌面。  
  7. 通常在企业环境中会采用第三方的防病毒软件,那么禁用系统自带的 Windows Defender 是非常必要的,所以在 specialize 阶段添加 DisableAntiSpyware = true。  
  8. 如果你正在使用 SDA,那么需要检查 oobesystem 阶段下的 Display 设置,确认添加如下配置,因为在 SDA 环境下该默认该配置数据缺失,而 Surface Pro 4 的默认分辨率为 2376*1824。
    ColorDepth = 32
    HorizonralResolution = 2376
    RefreshRate = 60
    VerticalResolution = 1824  
  9. 根据需要配置 OEM信息,为此可在 oobesystem 阶段为 OEMInformation 指定相关配置。
    Logo = %windir%OOBEinfoSurface.bmp
    Manufacturer = Microsoft Corporation
    Model = Surface Pro 4
    以及 SupportHours、SupportPhone 和 SupportURL 时间。  
  10. 为了加快 OOBE 的速度减少人为干预,可隐藏 oobesystem 阶段 OOBE 下的相关配置。
    HideEULAPage = True
    HideLocalAccountScreen = True
    HideOEMRegistrationScreen = True
    HideOnlineAccountScreens = True
    HideWirelessSetupInOOBE = True  
  11. 如果要脱离MDT单独部署映像,只需要删除 oobesystem 下的 FirstLogonCommands 项。

image

HOWTO: 解决 Microsoft Deployment Toolkit 8443 出现的 Invalid DeploymentType value 问题

        几天前 gOxiA 与大家分享了“Microsoft Deployment Toolkit (8443) 发布”这篇文章,8443 的升级过程还是非常顺利的,但没想到在后续的实施部署中遇到了问题。具体的故障现象是不论执行哪个任务序列都会提示“Invalid DeploymentType value “” specified. The deployment will not proceed.”最终导致任务失败。

InvalidDeploymentType2

        因为 MDT 在升级部署点后是不能够降级的,所以即使卸载 8443 并重新安装老版本也是无济于事,目前折中的办法是在 CustomSettings 中添加“SkipProductKey=YES”,或者替换 DeployWiz_ProductKeyVista 文件,虽然在微软技术支持论坛中有用户提到替换文件后并未发现什么不良反应,但 gOxiA 认为还是跳过密钥更稳妥!

参考资料:https://social.technet.microsoft.com/Forums/en-US/5bba8ffb-227d-40f6-b074-5817fafe3ae8/mdt2013-update-2-invalid-deploymenttype?forum=mdt

image

Microsoft Deployment Toolkit (8443) 发布

        微软近期发布了 Microsoft Deployment Toolkit (MDT)Build 8443 版本,与以往不同的是 MDT 新版不再附加年份版本号,官方解释是为了更好的配合 Windows 10 和 SCCM 的当前分支版本,以简化品牌和发布过程。这一版带来的改进主要如下:

支持 Windows ADK for Windows 10 的 1607 版

支持 Windows 10 1607 版

支持 Windows Server 2016

支持 SCCM 1606 版

        其他改进方面,终于支持高 DPI 设备,Surface Pro 4 部署时向导界面得到改善;针对 Windows 10 就地升级的一些问题修复;ADDS 配置步骤的问题修复;移除 imagex/ocsetup,全面使用 DISM;最新的 SCCM 任务序列支持。

        MDT 8443 下载地址:https://www.microsoft.com/en-us/download/details.aspx?id=54259

        MDT 8443 可直接从当前版本升级,在升级安装完毕后需要对部署点进行升级,并重新生成 Lite Touch PE,根据需要替换 WDS 对应的 WIM。

1

2

3

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: , , , ,
分页: 1/12 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]