我们在使用 MDT 部署 Windows 7 或 Windows Server 2008 R2 时可以在任务序列的 State Restore 阶段中添加“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 目录中，具体路径不再复述。上述操作完毕后，我们可以运行一个部署测试，在向导过程中会提示我们选择要安装的角色和功能。

        如果要在安装过程中略过角色或功能的安装，只需要在  CustomSettings.ini 添加 SkipRoles 或 SkipFeatures 参数即可。此外，我们也可以直接调用角色和功能安装脚本来进行独立的测试，只需运行“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 类型进行隐藏保护等操作。下图是整体的流程：

        不难看出，要实现包含恢复功能的安装，最简单的实现办法就是在新计算机上通过命令脚本的方式来安装。而恢复功能则是用的 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 安装源，并提供了只有品牌机才有的恢复功能。

        加速部署映像 - 也就是我们通常说的系统模板，通常我们为了提高 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 的加速部署映像。

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

Tags - microsoft , windows , 7 , waik , imagex , unattend ]]> http://goxia.maytide.net/read.php/1385.htm gOxiA <goxia@live.cn> Wed, 02 Jun 2010 03:05:50 +0000 http://goxia.maytide.net/read.php/1385.htm         使用集成 imagex 等小工具的 WinPE v3.0 工具盘可以说为很多朋友解决了不少的问题。gOxiA 一直以来也都擅长喜好使用 imagex 来执行系统备份，诸如此类的优势说明在过去的日志中也经常提到，这里就不再复述。而今天要与大家分享的经验是最近 gOxiA 遇到一个问题，而过去也曾经历过只不过未有留意，而这次遭遇同类问题在解决之后认为有必要大家分享，帮助大家避免发生同类的问题。

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

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

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

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

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

        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”功能开始创建单机部署源。

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

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

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

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

        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 有一定认识的朋友，能很容易看懂！并能够灵活应用到实际环境中。

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

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

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

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

        Sysprep and Capture 任务序列将从 MDT2010 服务器复制一份包含 Capture 功能的 Windows PE，并在当前系统上创建一个一次性引导信息，使当前系统在自动执行了 Sysprep 后，启动计算机时能自动引导进入 Windows PE 中执行 Capture。MDT2010 默认配置下，我们执行该任务序列时会指定 Capture WIM 的存储路径，但是如果之前在 Rules 中添加过自动化参数 SkipCapture=Yes，那么我们将遇到下面图中的错误警告信息，即：“WARNING – Unable to validation connection because a blank UNC was specified.”导致任务序列执行失败。

        要解决这个问题，我们可以将 Rules 中配置的 SkipCapture=YES 删除，之后在执行任务序列时手工输入 Capture WIM 的存储路径。或者继续完善自动化任务所需的参数数据，使之能够自动执行 Capture WIM 任务序列。为了减少管理员干预次数，我们将预先配置 Capture WIM 时所需的参数数据，此例主要包含3个参数：ComputerBackupLocation、BackupShare 和 BackupDir。

        其中 ComputerBackupLocation 即备份位置，可以是 Network - 网络、Specific Path - 特定路径、Auto - 自动 以及 NONE。这里我们选择使用 Network，将 WIM 存储在网络中。

        之后我们要指定这个网络共享路径，即：BackupShare，如：“＼＼MDTSRV＼DeployShare$＼Captures”。

        由于 Sysprep and Capture 任务序列会被复用，为了避免与其他已经 Capture 机器的 WIM 冲突，我们可以使用 BackupDir 参数，并赋予其一个 MDT 变量值 - %OSDComputerName%，这样就会在 ＼＼MDTSRV＼DeployShare$＼Captures 目录下创建一个以计算机名为名称的目录。

        当了解了各个参数的作用后，我们就可以将这些参数写入到 Rules 中，格式如下：

        如果当前已经为 MDT2010 配置了数据库，那么我们可以在 Database – Locations 中创建一个位置，并为其 Details 选项卡中的 User Data 部分配置这些参数数据，如下图所示！

        之后再行测试，“WARNING – Unable to validation connection because a blank UNC was specified.”故障问题消失！至此，我们也对 Sysprep and Capture 有了比较深入的了解和认识。

        在 MDT 官方 Blog 看到了解决办法需要修改 ZTIUtility.vbs，找到下面的字段范围：

        然后使用下面的字段进行替换：

        此外提供一篇官方的 KB 供大家参考：http://support.microsoft.com/kb/977566/zh-cn，本博也提供一个修改好的 ZTIUtility.vbs 供大家替换。

        下面就让 gOxiA 引领大家开始这一体验之旅，在开始前有必要提示一下准备工作，首先要准备一个完整的 WDS 环境，需要注意的是 WDS 必须是基于 Windows Server 2008 R2 的，因为部署 VHD 这一功能只有 WS08R2 支持。系统 SKU 的选择，目前 Client 只有 Windows 7 的 Enterprise 以及 Ultimate 支持 VHD Native Boot，而 Server 则 Windows Server 2008 R2 SKUs 都支持。接下来我们需要准备一份用于部署的 VHD 文件，可以参考之前的文章使用 imagex 工具释放 Install.wim 中的对应版本到 VHD 中，也可以使用 WIM2VHD 工具进行转换，或者使用 Disk2VHD 抓取现有的系统 VHD 映像，但是需要考虑硬件驱动及 SID 等问题，建议执行 Sysprep，或者在虚拟机中直接安装系统，并进行必要的配置及常用软件的安装，之后执行 Sysprep。最后将这些 VHD 拷贝到 WDS 以备后用。另外，将 Windows 7 或 Windows Server 2008 R2 的安装光盘中 Sources 目录下的 Boot.wim 添加到 WDS 的启用映像中，用于后面的引导和安装，这一步骤不再复述，非常简单！

（Windows 启动流程示意图）

（VHD Native Boot 架构）

        准备工作结束后，就开始进入正题。因为 WDS 目前还不支持 UI 方式，即通过 WDS 管理器添加 VHD 的操作，所以我们需要借助 WDS 命令行工具 – wdsutil.exe 来完成工作。为了便于管理，我们可以单独为 VHD 类型的安装映像建立一个安装组，该操作可以使用 WDS 管理器进行添加，或使用下列命令行：

        安装组创建完毕之后就可以开始添加 VHD 映像，为此请执行下列命令：

        命令行中的 verbose 和 progress 参数可以省略，用来显示详细信息和处理进度。其他参数都很容易理解，或是用“/?”获取相关的帮助，这里不再单独说明。到这里 VHD 的添加就完成了，非常之简单！如果是差异磁盘，那么只需要直接添加差异磁盘即可，父盘会自动添加到 WDS 存储 images 的目录中，出于安全原因原父盘名称会被自动修改为 Base-1.vhd 并被赋予隐藏属性。此外，打开 WDS 管理器我们能看到 VHDs 安装组中会存在两个刚添加好的映像，其中被禁用的便是 Base-1.vhd。因为添加的 VHD 都使用内部版本名+版本号作为映像名称，所以存在多个 VHD 时容易混淆，我们可以直接修改这些映像名称！

        OK，现在就来感受一下成果，启动一台客户端计算机（物理机或虚拟机均可）通过 PXE 引导进入 WDS 的安装向导界面，选择之前添加的 VHD 执行安装，接下来的时间可以休息一下！

        下图可以看到 VHD 被部署到客户端后的存储方式，默认 WDS 会在客户端计算机目标分区建立名为 WindowsImages 的根目录，其中会依序创建000、001 这样的子目录存储部署的 VHD 文件。此外，差异磁盘的父盘也会一同部署到客户端计算机上。至于网上有网友提到的使用差异磁盘来做客户端的还原和快速恢复应用，是一个很不错的想法，但是 gOxiA 认为 VHD Native Boot 更多考虑的应该是应用中会遇到的阻碍等问题。要细心设计如何更好的应用，而不是功能本身的操作。

        在欣喜之余对 VHD Native Boot 做一下总结，虽然 VHD Native Boot 有很大的发展潜力和优势，但是大家还是需要了解一些他的注意事项：

• 强烈建议将 VHD 单独部署到一个独立分区中，并且不要在该分区内存储其他数据；
• 不论 VHD 是固定磁盘还是动态扩展磁盘格式，存储 VHD 的分区一定要大于 VHD 的总容量；
• VHD Native Boot 最大支持 512 个实例；
• 不支持休眠；
• 无法使用 BitLocker；
• VHD 所在父分区不支持 Volume Snapshot；
• 不支持 RAID。

         最后，WDS 部署 VHD 支持无人值守脚本，从而实现自动化部署。差异磁盘的创建则在 diskpart 命令环境中执行如：“create vdisk file=child.vhd parent=name.vhd”的命令行即可，其中 parent 即指定父硬盘。

        至此，本篇即告结束！欢迎感兴趣的网友与 gOxiA 联系共同学习探讨！

• 如果从原 MDT 2008 上进行升级，那么 MDT 2010 会自动升级你的 MDT 数据库，即使数据库版本是 SQL Server 2000；
• 同上，如果之前已经存在一个 MDT 2008 数据库，那么只需要在 MDT 2010 数据库配置中直接选中之前已经存在的数据库即可；
• 
• 同理，验证 MDT 2010 的数据库是可以基于 SQL Server 2000 的（并不存在无法连接这一说法），那么我们可以在 SQL Server 2000 上的用于 MDT 的数据库上执行 MDT 2008 带的数据库查询脚本，创建对应的表。之后再通过前面的步骤进行升级；
• 如果需要将基于 SQL Server 2000 上的 MDT 数据库迁移到 SQL Server 2005 或 2008 版本上，那么可以使用 SQL Server Management Studio 附加原数据库，或通过导入和导出数据功能将原数据库中的表导入到新版本的数据库中。
• 最后，如果是全新安装的 MDT 2010，并且不存在上一版本的 MDT 数据库，那么要创建和使用 MDT 数据库，则 SQL Server 版本必须高于 SQL Server 2000，否则就会出现之前日志中出现的数据库错误。