gOxiA 很长一段时间都没有在 Virtual PC 下测试 MDT,全面转到 Hyper-V 环境中,这几天协助 Yinjie 老大的 Project 遇到了一个故障问题,截图如下:

未命名 

        提示中 ERROR – Processor speed of 5MHz is  insufficient. At least a 790MHz processor is required. 这段错误提示是重点。导致此例中 LTI 失败的原因是因为 CPU Speed 无法满足需求!

        幸好这几天貌似看到过有关解决该问题的 Blog,于是赶紧翻出来看看!该文源自 ITECN 网站,原文地址是:MDT 2010的一点点经验总结,其中提到了该问题,但是给出的解决办法是需要修改脚本文件!gOxiA 个人感觉这并不是一个最佳的解决办法,于是继续在网上搜索相关的资料。用关键词搜索到的可用信息很贫乏!还好发现了 MDT 2010 Update1 的 Release Notes 中也提到了这个问题,并且属于 Konw Issues!原文如下:

· The Validate Task Sequence step returns an “insufficient processor speed” error in Microsoft Virtual PC running on Windows 7, as WMI returns incorrect processor speed. To work around this issue, clear the Ensure minimum processor speed check box in the Validate task sequence step.

        OK!现在问题很清晰了,并且官方也给出了解决办法,只需要清除“Ensure minimum processor speed”复选即可!参考下图,编辑 Task Sequence,展开 Validation 定位至 Validate 选项,将右边选项列表中的“Ensure minimum processor speed”复选清除,最后单击确定完成。

Ensure_mini_CPU_Speed

        现在此故障问题得到了解决!官方文档还是有必要认真阅读的,以后要养成良好的习惯!  

MSFT_SolutionAccelerators

P2V Migration for Software Assurance Beta 安装篇

        上一节 gOxiA 通过 P2V Migration for Software Assurance Beta 介绍篇 向大家介绍了其用途,本篇则着重介绍 P2V Migration for Software Assurance Beta(简称:P2V Migration for SA) 的安装。其实 P2V Migration for SA 的安装还是相当简单的,我们只需要注意一些细节上的需求即可,首先针对 MDT 2010 Update 1 的轻量级接触安装与配合 SCCM2007 实现的零接触安装,P2V Migration for SA 都需要一个已经配置好的部署点,并且 MDT 服务器与 Internet 连接并能够下载软件包。注意:如果 MDT 服务器无法连接 Internet,那么需要手动将必须的软件拷贝到“Assurance\Tools”目录中,这些必须的软件包是:

        此外,针对 VHD 转换的客户端计算机必须满足以下要求:

  • 32位版本的 Windows 7 Professional 或 Enterprise,Windows Vista Business 或 Windows Vista Enterprise 的 SP1 或 SP2 版本,以及 Windows XP Professional 的 SP3 版本。
  • 客户端必须是使用批量授权或完整零售版的产品安装媒体来安装和激活的。注意:OEM 版本是无效的安装。此外,虽然完整零售版提供了转移到另一台计算机的安装授权,但它需要重新激活。
  • 被执行 P2V Migration for SA 的计算机硬盘容量必须小于 127GB。假如一个 160GB 硬盘,即使只使用了 20GB 的容量,又或者配置了小于 127GB 的分区都将导致 P2V Migration for SA 失败。

        将安装新的操作系统的客户端计算机必须满足以下要求:

  • 32位 或 64位 的 Windows 7 Professional 或 Enterprise 版本(PS:实际测试中 Windows 7 Ultimate 也受支持)。
  • 支持 Microsoft Software Assurance ,并提供高达四个虚拟机安装权利的授权。
  • 硬件必须符合 Windows Virtual PC(建议 2GB 内存)与 Windows 7 的最低需求。

        在了解 P2V Migration for SA 的需求之后,我们便可以开始安装,首先我们需要先前往 DownloadDetails.aspx-DownloadID=30989 登记注册并下载 P2V Migration for SA,之后在 MDT 服务器上进行安装。以下是安装过程的截图,供大家参考:

1

2

3

4

5

6

7

8

9

        在安装完成之后,我们便能够在 MDT 控制器部署节点的“Task Sequences”中创建 P2V Migration for SA 的任务序列。

P2V_Migration_TaskSequence

        在下一节 gOxiA 将继续与大家分享 P2V Migraiton for SA 的使用经验,并介绍如何使用 P2V Migration for SA 迁移计算机。敬请期待!

MSFT_SolutionAccelerators

解决 Unable to find USMT30_x86.cab file so it is not possible to install USMT 3.0… 故障

        在使用 MDT(Microsoft Deployment Toolkit)2010 为客户端执行部署任务时,我们需要考虑备份当前系统的用户状态及数据,特别是在迁移系统时,这一环节将显得更为重要,微软为此提供了 USMT(Windows User State Migration Tool) 工具。 它与 MDT 配合使用能为用户提供自动化的数据备份及迁移功能,大大提高了部署效率。

        我们可以通过 MDT 管理器来下载 USMT 组件,默认提供的是 USMT v3.0.1。

image

        MDT 虽然提供了 USMT 组件下载功能,但这并不代表下载后它就能够直接使用,如果你也计划在 MDT 中使用 USMT,相信也会遇到如下图所示的错误:

USMT3_Error

        上图中,ERROR: Unable to find USMT30_X86.cab file so it is not possible to install USMT 3.0, Aborting USMT is not installed, searching for scanstate.exe. 便是主要的故障信息。这个问题早先查阅资料解决过,但是一直没有做备忘,为了便于今后的工作更加顺利,决定补上解决该故障问题的日志!(PS:最近搞 P2V Migration for Software Assurance Beta 这个问题又在新部署的 MDT 服务器上出现!)

        要解决这个问题就要找到 USMT30_X86.cab,而这个文件其实是找不到的,必须手工创建。而 MDT 也为我们提供了创建 USMT30_X86.cab 的关键文件 - USMT30_x86.ddf,但是我们需要对其进行一下修改,因为默认路径与实际 USMT 的安装路径不符,从而会导致制作失败。为此,我们需要编辑 USMT30_X86.ddf,将其中的“.Set SourceDir=C:\Program Files\USMT30”改为实际的文件路径。

image

        修改完毕之后将该文件拷贝到 USMT 的安装目录下,使用 makecab.exe 命令加参数“/F”来创建 USMT30_X86.cab,为此打开 cmdshell 运行如下命令:

makecab /F USMT30_X86.ddf

        最后将创建好的 USMT30_X86.cab 拷贝到部署点 Tools 目录下的 x86 子目录中,为了便于日后其他新建的部署点使用,也可以将该文件再拷贝到 MDT 安装目录下“Templates\Distribution\Tools\x86”子目录中。

        再次进行测试,该故障消失问题得到了解决!

MSFT_SolutionAccelerators

P2V Migration for Software Assurance Beta 解决 Failure 1603 和 –2147024893 故障

        最近在鼓捣 P2V Migration for Software Assurance Beta,困难重重,问题一个接着一个,归根结底还是英文水平有限导致的。目前已经暂时停手,等待更多的资料出现再继续。今天主要来说说 P2V Migration for Software Assurance Beta 常见的一个故障问题,即 Failure:1603 和 –2147024893 故障问题。如下图所示:

KB961742_error

        当我们执行一个“Standard Client Task Sequence with P2V Migration”任务时,便会出现如上图的故障。通过故障代码也并未找到什么线索,所以开始进行排错。首先手动执行 KB961742-v3.exe 的安装,发现了问题!提示语言版本不同无法安装,这才恍然大悟,看来 P2V Migration for Software Assurance Beta 目前还主要针对英语版本,所以默认下载的补丁也是英文的。之后,重新下载简体中文版的 KB961742-v3.exe 进行覆盖即可。

        而下面的“-2147024893”故障应该也跟语言版本有关,注意观察“Internet Explorer 6.lnk”的路径,其中“Programs”在中文环境下的名称应为“程序”,所以要解决这个问题就必须修改其脚本文件。为此,我们需要编辑“ZTIRetro.wsf”文件,找到“With oShell.CreateShortcut(oShell.SpecialFolders("AllUsersStartMenu")”这段,将后面的“Programs”修改为“程序”即可。

        至此,FAILURE:1603 和 –2147024893 故障排除!

使用 MDT 向导窗体手工选择要安装的角色和功能

        我们在使用 MDT 部署 Windows 7 或 Windows Server 2008 R2 时可以在任务序列的 State Restore 阶段中添加“Install Roles and Features”任务来为系统安装角色和功能。

Install_Roles_and_Features

        但是我们可能遇到一种情况,即用户端希望手工分开选择要安装的角色和功能,那么利用前面所讲的任务即无法实现。现在 The Deployment Guys 为我们提供了一个解决方案 – MDT Deployment Wizard Panes for Installing OS Roles and Features,对现有的 MDT 稍加修改即可实现这一需求。

        首先下载 Roles_Features.zip,除了 readme.txt 以外的文件都复制到已经创建的 MDT 部署节点下的 Scripts 目录中,压缩包中包含了我已经修改好的 DeployWiz_Definition_ENU.xml 文件,如果之前你对该文件进行过修改,建议参考 Readme.txt 进行修改。如果打算在日后创建的新部署点上使用该功能,建议将提供的脚本文件拷贝到 MDT 安装目录下 Template 目录中对应的 Scripts 目录中,具体路径不再复述。上述操作完毕后,我们可以运行一个部署测试,在向导过程中会提示我们选择要安装的角色和功能。

Install_Roles  Install_Features

        如果要在安装过程中略过角色或功能的安装,只需要在  CustomSettings.ini 添加 SkipOSRoles 或 SkipOSFeatures 参数即可。此外,我们也可以直接调用角色和功能安装脚本来进行独立的测试,只需运行“cscript roles_features.wsf”,注意要执行此步骤请务必将 Roles_Features_Definition_ENU.xml 文件也拷贝到 Scripts 目录中,否则会提示错误。

        最后,再给大家一个友情提示,在实际测试中,发现该脚本无法识别要部署的目标操作系统版本,也就是说如果你选择要部署的操作系统是 Windows XP,但是在安装向导过程中还是会出现这个角色和功能安装的任务。

进一步优化加速部署映像的安装

        为了让大家更清晰的明白 gOxiA 这篇日志要讲的内容,先让我们回顾一下 gOxiA 之前写的两篇日志:制作 Windows 7 加速部署映像利用 REAgentc 实现快速的系统恢复。否则你将无法真正了解 gOxiA 撰写此篇日志的意图。

        创建自定义映像(加速部署映像)就是为了能提高系统的安装速度,并简化安装过程。而部署这一映像有很多种方法,比如:通过网络、UFD、DVD等方式。这里将不讨论网络的安装方式,而后两者都是通过存储载体进行安装,那么我们要么使用标准的 Windows 7 Setup 进行安装,或者使用自定义的 PE 环境来调用命令(Imagex.exe)安装。两者各有优势,Windows 7 Setup 提供了友好的交互界面,而命令方式虽然看似复杂,但能实现更多的需求,并减少人工的干预,最关键的是实现安装后的系统已经包含恢复功能及恢复映像。所以我们需要根据实际的需求对加速部署映像的安装做进一步的优化,以实现我们的需求或目标。

        为了更清楚的描述,gOxiA 拿自己的设计需求为例向大家讲解。首先 gOxiA 已经制作好了一份自定义的 Windows 7 映像,该映像包含应答配置,最终将通过 UFD 为载体进行安装,并提供原始映像用于系统恢复。由于旧计算机已经包含分区和数据,所以配置系统恢复功能只能通过手工的方式,在 Windows 7 Setup 标准安装全部完成之后进行。如果是新计算机则就好办的多,直接执行事先写好的命令行脚本,即可完成创建系统分区和恢复分区、释放系统映像、拷贝加速部署映像到计算机恢复分区、配置 REAgentC、配置恢复分区为 OEM 类型进行隐藏保护等操作。下图是整体的流程:

image

        不难看出,要实现包含恢复功能的安装,最简单的实现办法就是在新计算机上通过命令脚本的方式来安装。而恢复功能则是用的 Windows 7 自带的 REAgentC 来实现。在旧计算机上的安装和后续恢复功能的配置操作这里就不再阐述,可以参考前面提到的“利用 REAgentc 实现快速的系统恢复”。下面将主要讲解如何通过命令脚本在新计算机上进行安装。

        为了进一步的优化安装,上图中的子流程包含了6个步骤,其中包括了为恢复映像单独创建一个分区,并对其进行了隐藏保护。首先我们要准备两个 diskpart 脚本文件,以实现创建分区(ConfigHD.txt)和保护分区(ConfigOEMID.txt)的操作。

        ConfigHD.txt 的内容如下:

sel disk 0
clean
create partition primary size=100
format fs=ntfs quick
active
assign letter=s
create partition primary size=61444
format fs=ntfs quick label=OS
assign letter=c
create partition primary size=10245
format fs=ntfs quick label=Recovery
assign letter=r
exit

        ConfigOEMID.txt 的内容如下:

sel disk 0
sel partition 3
set id=27
exit

        将上面两个文件保存当 UFD 安装盘根目录下。之后创建一个名为 CleanDeployWindows7.cmd 的文件,同样保存在 UFD 根目录下,内容如下:

diskpart /s confighd.txt
imagex apply .\sorucesinstall.wim 6 c:
c:\windows\system32\bcdboot c:\windows /s s: /l zh-cn
md r:\recovery
copy .\sources\install.wim r:\recovery
copy c:\windows\system32\recovery\winre.wim r:\recovery
c:\windows\system32\reagentc /setreimage /path r:\recovery /target c:\windows
c:\windows\system32\reagentc /setosimage /path r:\recovery /rarget c:\windows
diskpart /s configoemid.txt
x:\windows\systrem32\wpeutil reboot

        至此,准备工作完成,接下来使用该 UFD 引导,如果是在新计算机上则调用 CMD,执行 CleanDeployWindows7.cmd,由于要释放和拷贝 WIM,所耗时间会有所增加,但是一劳永逸!当操作完成后会自动重新启动。如果是在旧计算机上,则使用 Windows 7 Setup 进行安装,再之后手工拷贝 WIM 文件,执行 REAgentC 进行恢复功能的配置。

        以上内容参考了 Microsoft OPK 提供的资料并进行了适当的修改。现在我们有了一份属于自己的 Windows 7 安装源,并提供了只有品牌机才有的恢复功能。

HOWTO:制作 Windows 7 加速部署映像

        加速部署映像 - 也就是我们通常说的系统模板,通常我们为了提高 Windows 的安装速度,会事先制作一套包含驱动、应用软件、补丁程序以及自定义设置的标准化系统。这样我们在使用该加速部署映像完成安装后,就可以让用户直接使用,不仅在安装方面大大缩短了时间,也提高了用户的体验。

        在 Windows XP 时代,我们在定制完毕系统后为了能够让该加速部署映像用于不同 HAL 的电脑,还需要人工执行很多复杂繁琐的操作,最后再使用 Sysprep 执行系统封装准备,完成后对系统打包。如果要实现自动安装,事先还需要使用 setupmgr 制作一份用于 Sysprep 的应答文件。

        自 Windows Vista 开始,Windows 的安装和部署发生了质的变化,到了 Windows 7 更是得到了完善和加强。现在我们使用 Sysprep 的 generalize 参数即可制作出一套不受 HAL 限制的通用映像。而自动应答文件富含更多地功能和设置,我们现在需要借助 WAIK(Windows Automated Installation Kit)这个新的 Windows 自动安装工具包来制作 Windows 的应答文件。由于 Windows 安装方式的改进,过去零散的安装文件都被打包在以扩展名为 WIM 的文件中,此外由于采用了文件方式的存储,WIM 不受磁盘大小的约束,能够很轻易的部署到不同容量的分区卷上,并且在释放 WIM 后文件都将紧密排列存储。这样我们维护或部署映像也将更将方便快捷。

        由于 Windows 7 的一些新特性,如:系统 oobe 阶段必须创建一个新用户;经过定制后将当前用户配置文件应用于默认用户配置,则需要借助  WAIK 在 specialize 阶段通过 CopyProfile=true 来实现。导致我们不能像以往 Windows XP 那样制作定制的加速部署映像。在 WAIK 的帮助文档中提供了多种安装部署方式的标准流程,鉴于一些环境因素的约束,gOxiA 采用如下的流程来制作 Windows 7 的加速部署映像。

image

        本次测试环境是在 Hyper-V 中创建了一个 Windows 7 的虚拟机,标准安装时直接 Mount 的 Windows 7 Pro ISO,使用虚拟化来创建加速部署映像是非常方便的。如果打算在物理机上实施则可以使用安装光盘、移动U盘或网络安装等方式执行标准化安装。

        使用集成 imagex 等小工具的 WinPE v3.0 工具盘可以说为很多朋友解决了不少的问题。gOxiA 一直以来也都擅长喜好使用 imagex 来执行系统备份,诸如此类的优势说明在过去的日志中也经常提到,这里就不再复述。而今天要与大家分享的经验是最近 gOxiA 遇到一个问题,而过去也曾经历过只不过未有留意,而这次遭遇同类问题在解决之后认为有必要大家分享,帮助大家避免发生同类的问题。

        起因是这样,gOxiA 的 Blog 服务器前段时间曾出现不稳定的状况,在对系统执行优化后决定对磁盘执行一次碎片整理,毕竟这个基于 Windows Server 2008 Web 的虚拟服务器已经运行了近17个月。随即在夜间进行了磁盘整理工作,第二天一早发现悲剧降临了,在执行碎片操作前,gOxiA 忽略了这台虚拟服务器使用的是动态类型的磁盘,而虚拟磁盘文件所在的分区卷容量还小于这个动态类型磁盘的容量,结果可想而知。系统启动后无法登录,提示磁盘已满,而存储卷显示剩余0字节。之前决定使用 VMWare 的压缩工具进行压缩,但都以失败告终。现在唯一的可行办法就是使用 WinPE 引导系统,挂载一个空的虚拟磁盘并使用 imagex 将原系统映像备份出来,因为 imagex 是以文件方式来执行数据拷贝的,所以新生成的映像恢复到新的虚拟磁盘上将不会有任何问题,初次之外还起到了磁盘整理的效果,因为 imagex 恢复后的文件时顺序排列的。经过一番折腾,总算把备份的映像释放到了新的虚拟磁盘上,然后挂载到虚拟机上启动系统,但是出现了 winload.exe 0xC000000E 故障。

winload_0xc000000e

        该故障引发的原因很简单,因为 bcdboot 中的引导信息是与硬盘所关联的,因为映像释放到了新的虚拟磁盘上,就相当于更换了硬盘,那么势必导致硬盘唯一标识变更,最终导致该故障的发生。而早先 gOxiA 使用 imagex 用于部署系统,不是将备份恢复到原硬盘就是使用 sysprep 后部署到其他硬盘上。此外,在部署 Windows 7 和 Windows Server 2008 R2 时因为系统设计的变化,默认安装系统时会自动生成一个 100M 大小的分区存储引导信息,而通常我们只备份系统盘,而在使用 imagex 恢复映像后都需要使用 bcdboot 命令创建引导信息。OK,到这里我们已经改如何解决这个故障信息了,除了使用 Windows 安装光盘引导进行修复以外,我们还可以使用手头现有的 WinPE 光盘进行命令行方式的修复。为此,我们使用 WinPE 引导盘引导系统,执行如下命令:

bcdboot c:\windows /s c:

        执行完这条命令之后我们就可以进行正常的启动了,但是问题还并未真正解决完。因为你会发现启动过程会显示 boot manager 菜单,而其中包含了两个名称相同的系统引导项,此外还会发现当前的引导菜单无法正确显示出中文字符。所以我们在前面使用 bcdboot 命令创建完引导信息之后还需要再执行如下命令,使 boot manager 采用中文版本。

bcdboot c:\windows /l zh-cn

        执行完上面两行命令后再退出 WinPE 重新引导计算机,最后使用 bcdedit 命令删除之前失败的系统引导项,整个恢复过程才算正式结束。

        保持清醒的头脑,认真分析之后再进行操作才能万无一失!

Tags: ,

        MDT 2010 中加入了一个新的高级功能 - Media,通过该功能我们可以实现客户端部署时脱离网络的限制,即无需 PXE 引导和 WDS 以及 MDT 节点服务器。部署涉及的脚本控制、任务序列、应用软件、操作系统、驱动等等数据都可以打包到一起生成 ISO 文件,刻录成DVD光盘使用。或者,将其直接拷贝到 U 盘,通过 U 盘进行安装(注意:该方法必须在 Windows Vista 或 Windows 7 系统上对 U 盘执行分区、格式化、激活才能实现引导)。对于单机部署来说,十分方便快捷!并且能实现最小化的接触安装。

        gOxiA 最近实施一个小项目,为5台 Dell 服务器进行系统安装,由于环境和时间约束无法部署 WDS+MDT2010,那么为了节省时间并减少人为干预,通过传统载体实现自动化安装是最佳的方式。最终,gOxiA 选择了 MDT 2010 的 Media 高级功能,该方案非常适合此项目的实施!整个设置步骤和操作过程其实都非常简单,gOxiA 认为重点主要还是在设计规划上,首先要尽可能的实现少量接触,此外还要保证其相对的通用性。这5台 Dell 服务器除了型号不同以外,有些还应用了 RAID5。因为操作系统是 Retail 的 Windows Server 2003 R2 Standard Edition,所以自动化步骤中的产品密钥部分就要单独考虑。此外,因为必须要在设备抵达前就准备好系统安装所需,那么通过设备序号或 MAC 来标识安装的办法亦不可取,最后的设计是产品密钥使用通用密钥,之后单独输入各自的产品密钥手工激活;计算机名也是用自动命名方式,之后再单独进行更改;系统分区没有特别要求,故分配40G。

        完成了计划便可以进入准备工作,为了减少数据占用的容量建议单独创建一个 Point,添加 Windows Server 2003 R2 安装源文件,添加磁盘控制器、显卡、网卡等驱动,具体的步骤就不再复述,需要注意是任务序列创建过程中序列号应当输入一个通用密钥,以便后续部署过程中能够自动输入序列号。当准备工作完成后,便可以使用“Advanced Configuration”下的“Media”功能开始创建单机部署源。

image

        创建过程也非常简单,可以参考下面的截图。

image

image

image

        下面开始重点部分,因为要部署的 Windows Server 2003 R2 是 32-bit 版本,所以在 General 选向卡下去除 Generate x64 boot image 的复选。因为考虑到还要通过光盘来部署系统,所以 Generate a Lite Touch bootable ISO image 选向也是必须的。

image

        我们知道默认的 Rules 和 Bootstrap.ini 配置非常简单,无法满足我们所需的自动化安装步骤,所以要完成前面所讲到的目标,我们需要对这两个配置文件进行修改。

image

        如下图所示,这是 gOxiA 做好的配置,其中 Bootstrap.ini 里 [Default] 部分添加的“SkipBDDWelcome=YES”是略去部署环境开始时的欢迎界面。

image

        Rules 配置文件中 [Default] 部分的详细数据如下:

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipSummary=YES(忽略部署环境中最后的摘要)
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES(忽略产品密钥的输入)
SkipLocaleSelection=YES
SkipDomainMembership=YES(忽略加入域的步骤,即默认为工作组)
KeyboardLocale=0804:00000409(指定键盘区域为中文简体)
InputLocale=0804:00000409(指定输入法为中文简体)
UserLocale=0804:00000409(指定用户默认语言为中文简体)
SkipTimeZone=YES(忽略时区设置)
TimeZone=210(指定时区代码)
TimeZoneName=China Standard Time(指定时区的名称)
DoCapture=NO
SkipUserData=YES
UserDataLocation=NONE
SkipFinalSummary=YES(忽略部署的最后结果摘要,可根据需要选择,如果之前已经进行过完整的测试,那么可以忽略该摘要。)
SkipTaskSequence=YES(忽略任务序列的选择)
BuildID=001(指定任务序列ID,这个变量同样是定义 Task Sequence ID 的,但是由于该变量沿用BDD2007中的变量,并且是内置变量,无法通过 MDT 控制台进行编辑,我们可以将其看作为一个索引值。在实际应用中,BuildID和TaskSquenceID必须一同使用。否则单一指定TaskSquenceID无效。)
TaskSquenceID=001(指定任务序列的ID)
SkipComputerName=YES(忽略计算机名)

        看了上面提供的配置数据,我相信对 MDT2010 有一定认识的朋友,能很容易看懂!并能够灵活应用到实际环境中。

Tags: , , ,

        继之前两篇日志《解决 A connection to the deployment share could not be made. The deployment will not proceed.》和《解决 Capture 时出现的 Unable to validation connection because a blank UNC was specified. 错误》,我们对 MDT 的 Sysprep and Capture 任务序列已经有了非常深入的了解和认识,但是 gOxiA 在测试一台位于工作组级别的计算机执行 Sysprep and Capture 任务序列时仍旧提示 the deployment will not proceed 错误,几经波折发现在访问和执行 MDT 共享目录下的脚本时是需要技巧的。测试成功之后不敢独享,特撰文出来与大家探讨!

        按照常规的操作我们通常会打开网络邻居键入 MDT 的共享路径,而该共享路径默认配置为 ShareName$,当工作组级别的计算机在访问时又需要进行身份验证,故几次测试 Sysprep and Capture 任务序列都失败告终(PS:当计算机加入到 AD 后无此问题,很纳闷!),最后发现当把 MDT 的 ShareName$ 映射到本地 Z: 后故障消失!看来 MDT 脚本存在一定的问题,不管怎样问题得到了解决,要正确执行 Sysprep and Capture 任务序列,则强烈建议通过命令行执行脚本,大致步骤如下:

net use * \\wds-srv\mdtdeployshare$ /user:domain\username

        之后提示键入验证用户的密码,随后执行:

cscript \\mdtdeployshare$\scripts\litetouch.wsf

        之后在 cmd 环境会出现脚本执行的详细细节,之后直接探出任务序列选择列表,这点与之前的执行过程略有不同,无需再次验证身份。在任务序列选择列表中,选择执行 Sysprep and Capture,跟随向导确定完成,最后就出现于下图所示的任务执行截图。

image

        虽然问题都已经得到了解决,但是 gOxiA 总感觉之前的 《解决 A connection to the deployment share could not be made. The deployment will not proceed.》 失去了意义,迫于精力有限无法继续证实,还望有条件的朋友能继续测试给于不同的见解和意见!

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