ADS | WDS | BDD2007 | MDT 2008 | MDT 2010

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: , , , ,

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

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