MSFT_SolutionAccelerators

微软发布 Microsoft Deployment Toolkit 2012 Beta 1

        今天收到了 Microsoft Connect 的邮件,告知 MDT 2012 Beta 测试项目开始了,这意味着我们已经可以下载到 MDT 2012 的首个 Beta 版本!

        MDT 2012 Beta 1 提供了很多新的功能:

  • 对 SCCM 2012 Beta 2 的支持,包括 new application model and user device affinity (UDA) 的支持。
  • 改进了轻量级接触(Lite Touch)安装时的分区功能,支持 WAIK 首选分区设置。
  • 支持 UEFI 计算机的 64位 Windows 的轻量级接触部署。
  • 添加了新的 VHD Native Boot 任务模板,支持 Windows 7 或 Windows Server 2008 R2 的 VHD Native Boot 部署。
  • 增加了对 Windows ThinPC 和 Windows POSReady 7 的支持。
  • 改进了部分向导的外观界面。
  • 继续支持 SCCM 2007 SP2 以及 MDT 2010 所支持的所有操作系统。
  • 修复了很多已知的 Bug 并进行了其他小的改进。

        MDT 2012 Beta 1 支持从 MDT 2010 Update 1、MDT 2010、MDT 2008 Update 1 上直接升级。虽然如此,但还是强烈建议在升级前对当前数据进行备份!

        如果打算即可开始体验新版的 MDT 2012 Beta,可访问 Microsoft Connect 网站参与到 MDT 2012 Beta 项目中来。地址是:https://connect.microsoft.com/site14/Downloads/DownloadDetails.aspx?DownloadID=8689

        近期 gOxiA 重新搞起 Windows XP 的映像部署实践,虽然 Windows XP 正逐步被淘汰,但是面对一些老机器而言,有一个能够快速部署 Windows XP 的安装映像,能省掉不少时间和精力。此外,MDT 的新版本打包的 Windows XP 貌似能在不同的硬件上使用。所以 gOxiA 耗费了几天的时间制作了包含预装应用程序的 Windows XP Pro with SP3 Volume 和 Windows XP Pro with SP3 Dell OEM 的自定义映像,用于加速安装 Windows XP。

        加上早期制作的 Windows 7 HomePremium Custom Image,目前有三个自定义映像,下面便是三个自定义映像的相关信息截图。

WDS_Windows_Setup_Collection

W7HPCI

WXPProSP3DellOemCI

WXPProSP3VolCI

        大家已经留意到上面的第一张截图是 WDS 控制台的界面,是的!gOxiA 将 MDT 中捕获的 Windows XP 映像进行了修改,去除了与 MDT 相关的执行脚本,便于在 WDS 或通过 Windows Setup 来进行安装。

        但是在使用 WDS 部署 Windows XP Custom Image 时会出现如下图的蓝屏故障,即:STOP: 0x000000ED (0x823329E0, 0xC000014F, 0x00000000, 0x00000000)。系统在执行完毕 Mini Setup 阶段之后,重新启动便无法自举!

BOSD_0x000000ED

        随即启动 Windows PE 3.0,进入 Diskpart 环境,通过 Detail Disk 查看磁盘信息,发现了问题!虽然磁盘是联机状态,并且磁盘及分区都能够被识别,但是分区格式为 RAW。

detail_disk

        在命令行状态下进入 C: 失败,反馈信息为“此卷不包含可识别的文件系统。请确定所有请求的文件系统驱动程序已加载,且此卷未损坏。”查阅了微软知识库,找到了一篇 KB315403。KB 解释出现该故障的原因是由于 IDE 磁盘驱动器中的写模式优化导致的,为了将驱动器的写入速度保持在尽可能最快的水平上,缓存例程有时会根据数据在磁盘上的位置,打乱数据的写入顺序。一次写入没有完成时,将会在 NTFS 磁盘系统可能有关键表受损的位置开一个计时窗口……

        这么讲貌似应该与 WDS 没有关系,问题应该是出在映像系统本身上,但是实际的测试表明,当使用 Windows Setup 或 MDT 来部署 Windows XP Custom Image 时则不会发生这样的故障。之后,gOxiA 又在 WDS 上做了更深入的测试,在安装过程中,直接在现有分区上进行安装,而不再删除或格式化。之后发现 0x000000ED 故障不再出现,看来此故障应该与 WDS 中使用 Windows Setup 安装 Windows XP Custom Image 时建立的分区有关,而单独使用 Windows 7 安装源的架构和 Windows Setup 则不会出现故障,看来还是 WDS 在添加 Windows 7 的 Boot.wim 时,加入的某个 WDS 相关动态链接库文件(DLL)存在 Bug。

        目前在出现 0x000000ED 蓝屏故障后有效的解决办法就是参考 KB315403,在 Windows XP 故障恢复控制台或 Windows PE 中执行 chkdsk /r 执行扫描修复。之后再重新启动计算机 0x000000ED 故障消失!

chkdsk_rchkdsk_r_1

Tags: , , , , , , ,

MSFT_SolutionAccelerators 轻量级接触部署的配置文件参考

CustomSettings.ini 部分:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipDomainMembership=YES
SkipCapture=YES
DoCapture=NO
SkipComputerBackup=YES
ComputerBackupLocation=NETWORK
BackupShare=\\ServerName\SystemWIM
BackupDir=%OSDComputerName%
SkipAdminPassword=YES
AdminPassword=password
SkipProductKey=YES
SkipDeploymentType=YES
DeploymentType=REFRESH
SkipTimeZone=YES
TimeZone=210
TimeZoneName=China Standard Time
SkipLocaleSelection=YES
UILanguage=zh-cn
UserLocale=zh-cn
KeyboardLocale=zh-cn;0804:00000804
SkipUserData=YES
ScanStateArgs=/v:5 /o /c
LoadStateArgs=/v:5 /c /lac
UserDataLocation=AUTO
UDShare= \\ServerName\USMT
UDDir=%OSDComputerName%

Bootstrap.ini 部分:

[Settings]
Priority=Default

[Default]
DeployRoot=\\ServerName\DeployPoint$
UserID=deployadmin
UserDomain=contoso
UserPassword=password
SkipBDDWelcome=Yes

MSFT_SolutionAccelerators 禁用 ZTIBackup 以加快 Refresh 方式的部署速度

        当我们使用 MDT 的 Refresh 方式部署客户端系统时会发现,在进入 LiteTouch PE 环境后会执行一个 Backup(ZTIBackup.wsf)任务序列,将当前系统捕获为一个 WIM 映像文件,如果之前我们在 CS.ini 里指定了 ComputerBackupLocation=NETWORK,即使是指定存储在本地,那么也将会严重影响整体的部署速度。

MDT_Refresh_ZTIBackup

        作为 ITPro 如果在评估当前环境后,认为在为客户端执行 Refresh 方式部署时无需备份当前系统和用户数据,那么可以在 Task Sequences 中禁用任务中的 Backup(ZTIBackup.wsf)任务序列。如下图所示:

MDT_Refresh_ZTIBackup1

        这样一来,在以 Refresh 方式部署时就可以略过当前系统的备份过程,从而加快了部署的速度。MDT 真的是非常灵活并强大,Task Sequence 的应用和配置是深入学习 MDT 的重点!

        最近一位老网友一直在与我分享他使用 WDS、MDT 使所遭遇的问题,在协助他解决问题的同时我不仅“快乐”着,也同时有机会接触到更多的“问题”,今天的这个话题也源自这位老网友。

        在 WDS 中我们可以添加多个不同应用的启动映像,来满足我们实际工作中的需求。当计算机通过 PXE 引导后我们能看到如下图的引导菜单,在引导菜单中我们可以手动按上下键来选择要启动的映像,默认的启动选择为菜单列表中的第一项。

PXEBootList

        如果我们需要设置默认的启动映像,可以通过 WDS 控制器进行操作,首先打开 Windows 部署服务 控制器,选中当前 WDS 服务器,然后点击鼠标右键进入 属性,并切换到 启动 选项卡,在 默认启动映像(可选) 中为 各个体系结构指定默认的启动映像即可。配合 PXE 引导策略 还可以选择 PXE 的引导方式根据需要实现自动化的 PXE 引导。

SetWDSBoot

        但是,网友也提出了一个疑问,就是如何修改 PXE 引导菜单中启动映像的顺序,而非指定默认的启动映像。其实这个问题的解决方法很简单,思考一下 WDS 的 PXE 启动原理,不难看出 PXE 引导菜单是基于 BCD BootMgr 的,那么我们只需要修改启动配置数据(BCD)信息即可实现我们的目标。修改 BCD 我们需要用到 BCDEdit 工具,修改启动顺序则需要用到 BCDEdit 的“/displayorder”及其子参数“/addfirst”和“/addlast”。

        接下来就是要找到 PXE 使用的 BCD,这其实才是关键。OK,PXE 所使用的 BCD 存储在“RemoteInstall”的“Tmp”子目录下,在该目录中有存储着各个体系结构的 BCD 文件,我们只需要使用 BCDEdit 进行修改即可!友情提示:别忘记使用“/store”参数来指定你要编辑的 BCD 哦!

PXEBCDStoragePath

MSFT_SolutionAccelerators

如何为 Windows XP 的自定义映像配置默认的本地用户配置文件

        在 Windows 7 日趋兴盛的阶段中,确实还有不少 ITPro 坚守着 Windows XP 阵地,尤其是 Microsoft Deployment Toolkit(MDT)的广泛使用,使 Windows XP 的大批量部署更为轻松。而今天这个主题的由来,源自一位老网友的咨询,涉及的问题大致是这样的,使用 MDT 部署 Windows XP,在任务序列的系统属性下配置了 Sysprep.inf,添加了“UpdateServerProfileDirectory=1”,希望自定义默认的本地用户配置文件。但是,在实际测试中发现并未产生效果。

        其实道理非常简单,在部署 Windows XP 时,因为是标准化安装所以并未涉及到 Sysprep,而只用到了 Unattend。而任务序列中的 Sysprep.inf 可以协助我们在标准化安装之后执行 Sysprep 和 Capture 操作时作为应答文件来使用。此外自定义的默认用户配置文件肯定也是在系统完成安装后才能开始对系统进行个性化配置,之后再执行包含“UpdateServerProfileDirectory=1”参数的Sysprep 操作,才能将当前用户配置文件指定为默认的本地用户配置文件。看似很绕,其实不难理解!

        而此事对于 gOxiA 的价值,关键在于一个“UpdateServerProfileDirectory=1”,gOxiA 确实对该参数非常陌生,因为很少使用自定义映像来进行部署(PS:Windows XP 的 HAL 以及驱动问题确实很令我头疼),过去也都是手工方式配置默认的本地用户配置文件,不管怎样这里还是非常感谢这位老网友!

        有关各版本操作系统如何自定义默认的本地用户配置文件,可参考微软官方 KB959753,其中涉及到了 Windows XP 的 UpdateServerProfileDirectory。对于 Windows 7 环境,我想不用再仔细介绍了,在 Microsoft Windows Shell Setup 下启用 CopyProfile 即可。

MSFT_SolutionAccelerators

如何避开 Performing a Refresh from a newer OS Version to an older OS Version is not supported.

        在 Microsoft Deployment Toolkit(MDT)中 ZTIValidate.wsf 是用来进行有效性验证的脚本,其作用就是协助 ITPro 在使用 MDT 部署时能够根据特定的要求,来验证客户端是否能够正常执行 MDT 的任务序列。如 gOxiA 之前的一篇 Blog《[MDT] HOWTO:解决 Virtual PC 下因 CPU Speed 导致的 MDT LTI 错误》。除此之外,ZTIValidate.wsf 还包含了微软的一些策略要求,比如不支持从新版本系统以刷新或升级的方式来安装旧版本系统。而 gOxiA 最近在实践学习中就遇到了此类问题,有一台 Windows 7 的虚拟机需要重新安装 Windows XP 系统,为此在当前系统下执行了 LiteTouch.vbs,之后选择任务序列执行安装,随后提示如下的错误:

无命名

        FAILURE (9808): Error – Performing a Refresh from a newer OS Version to an older OS Version is not support. 是的,当我们将一个新版本操作系统以 Refresh 方式安装一个旧版操作系统是不被支持的,需要以 NewComputer 进行部署。这是因为当执行 Refresh 模式时,会涉及到用户数据的迁移,其中会引发兼容性问题,当然这只是 gOxiA 的看法!

        但这是一个测试环境,gOxiA 又懒得不希望重新启动虚拟机到 LiteTouch PE 下执行全新安装,最终 gOxiA 选择了避开 MDT 任务序列的验证步骤,正如前面提到的那篇 Blog,我们只需要将“Validate”禁用即可!如下图所示:

DisableValidate

        此法方便快捷,无需对 ZTIValidate.wsf 脚本进行修改,顺利完成系统的 Refresh 安装!但是,需要注意的是,虽然我们可以通过禁用 Validate 来实现新版系统 Refresh 旧版系统,但是强烈不推荐在生产环境中使用,由此引发的数据丢失 gOxiA 不负任何责任哦!

MSFT_SolutionAccelerators

解决 MDT Update Deployment Share 无法创建多播 的故障问题

        在一台新服务器上安装了 MDT 进行了相关的配置,在执行 Update Deployment Share 时出现如下图的故障,并且该问题实实在在烦了我几天。今天下午总算是解决了,又是因为疏忽导致的,惭愧……!

mdt_multicast_error

        先来看看图中的错误:

An error occurred while trying to execute the command.
Error Code: 0xC1250100
Error Description: The configuration string was invalid or empty.
䔊楸⁴潣敤㴠ⴠ〱㐵㌵㔹〲
Unable to create multicast namespace "DeployPoint$", rc = -1054539520.

        遇到故障问题,如果 gOxiA 无法自己解决首先会想到的是强大的搜索引擎,可惜最近RPWT,总是搜索不到任何有价值的资料!所有资料都未正确提及或引导出该问题的错误根源!这也是 gOxiA 多天没能解决的主要原因。

        乍一看,Unable to create multicast namespace “DeployPoint$”都很清楚的描述了错误,而这个 namespace 又确实存在, 并且 MDT 部署也未有任何异常,当然除了无法执行多播。早先又因为搜索网上的资料被误导进入到了一个死胡同,直到今天下午来到办公室,利用闲暇时间决定使用 wdsutil.exe 来探个究竟。

        MDT 的脚本执行遭遇错误得到的反馈信息可能不便于 troubleshooting,毕竟文档资料太少,但是如果直接使用 wdsutile.exe 自己手工创建多播应该更加直观。于是:

wdsutil /new-namespace /friendlyname:”MDT Share DeployPoint$ Multicast” /namespace:”deploypoint$” /contentprovider:wds /configstring:”D:\DeployPoint” /namespacetype:autocast

wdsutil_namespace

        晕!竟然没有反馈任何错误,成功的执行了!但是 gOxiA 也非常肯定 MDT 的脚本肯定是没有问题的,因为同样的环境其他 MDT Server 就不会出现这个问题。重新思考……再思考!

        当前的 MDT Server 使用的 Deployment Point 是从 gOxiA 笔记本上现成拷贝过来了,难道是哪个路径忘记改写了!迅速打开 Deployment Point 属性查看 General 选项卡终于发现了问题,再导入现有节点后我虽然修改了 UNC path,但是忽略了 Local path。也正是这个原因导致在执行 Update Deployment Share 时无法创建多播。但是,MDT 在错误反馈方面也确实有些疏漏,本是“Configstring”的问题,现实的错误反馈结果却是“Namespace”。

mdt_general_localpath

        不论怎样,问题今天总算是得到了解决!再次得到一个教训和经验!
        参考资料:http://technet.microsoft.com/zh-cn/library/cc794731(WS.10).aspx

MSFT_SolutionAccelerators

P2V Migration for Software Assurance 应用篇

        距离之前发布的几篇有关 P2V Migration for Software Assurance(以下简称:P2V Migration for SA)的文章已过去2个月左右的时间,gOxiA 说太忙没时间写也都是托词,其实更多时候感觉是精力有限!就在最近,P2V Migration for SA 正式版发布了!而面对更多用户开始部署 Windows 7 的大好局面,P2V Migration for SA 正式版的出现,能够帮助到更多用户轻松的部署到 Windows 7。

        P2V Migration for SA 的功能及实现的最终目标并不难理解,利用 P2V Migration for SA 我们能够在部署到 Windows 7 时将之前的旧系统转换为 Windows Virtual PC 下的虚拟机,这样一来即使我们已经被部署到 Windows 7 环境,但是利用 XP Mode 特性仍能够轻松、便捷地使用我们旧系统环境中的应用软件和设置。P2V Migration for SA 的整个执行过程看似都是那么简单便捷,这一切都要感谢 Microsoft Deployment Toolkit Team,而他们为广大用户所带来的一整套部署解决方案还是免费的!

image

        正如我前面所讲的 P2V Migration for SA 在使用起来非常简单,与常规的安装工作序列并无太大区别,唯一加入的就是将现有的系统捕获为虚拟机,在安装完 Windows 7 系统后自动执行 Windows Virtual PC 的安装,并将虚拟机配置到当前环境中。在开始介绍 P2V Migration for SA 的应用前,大家先回顾一下 gOxiA 之前的文章:

        当我们安装好 P2V Migration for SA 后,在 Task Sequences 新建任务序列中看到新添加的三个任务序列,分别是:Standard Client Task Sequence with P2V Migration、Standard Client Replace Task Sequence with P2V Migration 以及 Custom Task Sequence with P2V Migration。

P2V_Migration_Seq_1

        其中 Standard Client Task Sequence with P2V Migration 便是我们常用的任务序列。gOxiA 事先准备了一个测试环境,在 MDT 中导入了 Windows 7 的安装源,并跟随向导创建了一个基于 Standard Client Task Sequence with P2V Migration 类型的任务序列,之后在一台虚拟机上开始进行实验,此台虚拟机已经安装了 Windows 7 Ultimate 中文版(PS:虽然不是 Windows XP,但不影响整体的测试效果!)整个过程中初期部分与常规的 MDT 部署客户端没有太大区别,除了在过程中捕获当前系统会消耗一段时间。在当先系统环境中执行 Litetouch.vbs,选择之前创建的 P2V Migration for SA 任务序列,跟随向导完成操作后,剩下的就交给 MDT 和 P2V Migration for SA 了!我们可以稍作休息,在系统完成安装之后,我们会看到后续执行的任务发生了变化。

P2V_Migration_1

        如上图所示,P2V Migtation for SA 开始将之前捕获的系统虚拟磁盘文件恢复到当前的系统之上。而在这一过程前面,会自动为当前系统安装 Windows Virtual PC 以及 without VT 的补丁。

        最后整个任务序列完成之后我们便能够在 Windows 7 开始菜单的所有程序中看到 Windows Virtual PC 以及类似名为“Old OS – Administrator”的旧系统的虚拟机,并且其状态为运行中。我们可以即刻访问这个虚拟机来使用我们的旧系统环境!

P2V_Migration_2

        P2V Migration for SA 无疑为我们部署 Windows 7 并保留旧系统提供了便捷的解决方案,如果你正考虑将现有客户端计算机部署到 Windows 7,并希望用户能够继续使用旧系统环境,P2V Migration for SA 将满足你的需要!

MSFT_SolutionAccelerators

解决 Non-zero return code from Scanstate RC=27 故障

        Windows 7 正如我们之前所预料大规模的部署已经开始,特别从 10月份开始更多的企业用户着手于 Windows 7 的部署。最近 gOxiA 也正忙于通过 MDT 2010 来部署 Windows 7,早先只是测试环境及小规模的应用,而通常都是新装 Windows 7。如果为现有 Windows 7 操作系统执行 Refresh 操作,那么可能会出现如下图所示的错误:

MDT_W7_Scanstate_rc27error

        主要的错误为“Non-zero return code from Scanstate, RC = 27”,应该是 USMT 执行失败。检查 cs.ini 配置,其中我预先定义了用户数据的相关配置“SkipUserData=YES”、“UserDataLocation=NONE”,即表示略过用户数据保存步骤,并预设存储路径为“None”,并且之后 gOxiA 也对 cs.ini 重新修改,删除 SkipUserData 和 UserDataLocation 的配置,进行了常规测试,手动操作这些步骤,结果并未出现错误。很诡异……

UserData_test

        之后查阅了大量的资料也没有什么头绪,难道在对现有 Windows 7 执行 Refresh 时必须在 cs.ini 中提供详细的 USMT 配置信息?! 不亲自实践不会有结果,耗些时间去测试才会有收获!

        打开 Deployment Workbench,进入部署点的属性设置,切换到 Rules 选项卡修改 cs.ini,添加了 USMT 相关的配置信息最后确定退出!

MDT_Rules_USMT

        添加的 USMT 配置信息如下:

LoadStateArgs=/lac  /v:13
USMTMigFiles1=MigApp.xml
USMTMigFiles2=MigUser.xml
USMTMigFiles3=YourCustomMigFile1.xml
USMTMigFiles4=YourCustomMigFile2.xml
USMTMigFiles5=YourCustomMigFile3.xml
USMTMigFiles6=YourCustomMigFile4.xml
USMTConfigFile=Config.xml
UserDataLocation=AUTO
UDShare= \\MyServer\MyShare\
UDDir=%OSDComputerName%

        重新进行了测试故障解除!至于最终导致的原因由于缺乏资料,gOxiA 目前也真道不明白!关于 USMT 在 MDT 中的应用和设置看来需要抽时间专门研究研究。

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