【IT168 资讯】 ADS发布已经有一段时间，早先曾做过ADS1.0的实验，但因技术参考资料贫乏，而且了解的人不多无法共同学习讨论。那段时间几乎都在看技术资料，MVP文章，Webcast课程，反复实验但都总因为不知名的错误而停滞不前，最后几乎走火入魔(英文阅读能力差，机器配置低，反复实验经常要等待，而且要重复很多步骤)，实在无法继续下去，决定暂停!待有更加全面的资料公布或新版本发布后再作实验。
1个多月过去了，偶然发现微软在其网站发布了ADS1.1，于是兴奋的下载下来准备再次准备实验。在经过前期准备后开始了此次利用 ADS来部署WinSrv2003的实验。中间也遇到了很多问题，反复查资料看KB最终换来了成功。而这篇文章实际意义主要是为了给自己的实验作备忘，汇总每个资料中的关键信息，并通过每个实验细节的介绍使那些希望学习ADS的朋友们不必再因为参考资料的某些问题而走弯路。
希望大家能从此篇文章中获得有价值的东西。因本人并不是微软的技术专家，所以篇中用词可能并不规范并且不免有遗漏或错误，还请大家谅解指正。
ADS 简要概述
Automated Deployment Services，自动化部署服务，简称ADS.
在Windows Server 2003中，Microsoft对平台进行了扩展，管理员可以通过它容易地构建和管理超大型的可伸缩Windows服务器部署。自动部署服务(Automated Deployment Services，ADS)包括一组Microsoft开发的新映像工具，以及一个可以用来在裸机服务器上快速部署Windows 2000 Server和Windows Server 2003的、更安全且具有远程操作能力的基础结构。此外，ADS提供了一个更加安全、可靠的脚本执行，允许管理员像管理一台服务器那样简单地在1000台服务器上执行基于脚本的管理工作。
ADS 产品特性
在ADS中，计算机被称之为设备(Device)，所有被管理的设备都需要安装ADS中的Administration Agent(简称：代理程序)。ADS服务器需要由三部分组成，它们是：Controller Service(用来集中管理设备)、Network Boot Services(简称NBS，用来客户端的远程计算机启动)、Image Distribution Services(负责映像创建和部署)。这三个部分可以被分散在多台计算机，也可以集中安装在一台计算机。
ADS使用数据库来存储信息，在ADS安装源中包含有他的本地MSDE，或者使用一个本地或远程的SQL Server 2000服务器。
ADS需要一台DHCP服务器来为客户端作引导服务，同时ADS服务器本身也支持动态IP分配，因此ADS服务器静态IP配置不是必须的。另外建议不要在ADS服务器上部署DHCP服务。
ADS客户端需要支持PXE引导，或被利用RIS工具创建PXE引导盘，前提是你的网卡在RIS所支持的清单中。
ADS不依赖微软的活动目录，一个简单的LAN环境就可以实现ADS.它的任务脚本强大，可以实现对客户端更加细微的管理能力(如：为客户端分区)。
ADS的设计目标前面提过了，主要是用来大规模部署服务器。但是在微软讲师和MVP的技术资料中提及ADS同样可以用来部署Win2000Pro或XPPro，不过我想可能会有很多需要修改的地方，这也是我以后的实验目标。
以下是ADS的关键属性表，大家可以参考：
ADS关键属性表
典型场景 数据中心，计算机中心，大规模部署
部署的操作系统 Windows Server 2003：所有32位版本
Windows 2000：所有服务器版本(SP3以上)
可用性 可以运行在Windows Server 2003企业版和数据中心版
部署方式 基于映像
部署初始化 部署控制服务，推模式
支持多播部署 是
每服务器部署的并发数量 最大128(多播)，部署速度不受服务器并发部署数量影响
每计算机多个卷的部署 是
部署映像文件格式 NTFS，FAT16，FAT32
映像编辑工具 是
根据硬件抽象层(HAL)自动映像过滤 否
DHCP服务器类型 任意
活动目录需求 否
配置信息存储源 Microsoft SQL Server
编程可扩展性 是
为了方便在有防火墙的环境下实验，以下列出ADS所涉及到的端口：
Communication ports used by ADS
Device to the DHCP server
Protocol Direction Port Notes DHCP Device (PXE firmware) to DHCP service UDP 67 DHCP DHCP service to Device UDP 68 Device to Network Boot Services Protocol Direction Port Notes PXE Device (PXE firmware) to the ADS PXE service UDP 67 and/or UDP 4011 Required to support a device's boot to the Deployment Agent (using PXE)。 You can configure the use of port 4011 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\ADSPXE\Parameters\PxeUseDhcpPort registry entry. PXE ADS PXE service to the device UDP 68 TFTP Device (PXE firmware) to the TFTPD service UDP 69 Required to download Startnbs into RAM. DHCP Device running Startnbs to the Deployment Agent Builder service UDP 4012 You can configure the use of port 4012 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\ADSBUILDER\parameters\ServerPort registry entry. DHCP Device (Ntldr) to the Deployment Agent Builder service UDP random port TFTP Device (Ntldr) to the TFTPD service UDP 69 Required to download the Deployment Agent image into RAM. Device to the Image Distribution service Protocol Direction Port Notes Image download (multicast) Device to the Image Distribution service UDP 30877 or 30878 Required for image capture and deployment. Requires DHCP multicast address allocation. IP addresses are not the device's， but allocated multicast address. Image download (unicast) Device to the Image Distribution service TCP 30877 Image transfer Image Distribution service to the device UDP 30877 through 31878 Device to the Controller Protocol Direction Port Notes BMDP Device to the Controller UDP 8197 Required for remote execution of jobs on the device (both in Deployment Agent and in Administration Agent)。 You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\BmdpIpPort registry entry. BMDP Controller to the device TCP 8198 You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\BmcpIpPort registry entry. BmFileXfer file transfer Controller to the device TCP 19778 Controller to Network Boot Services Protocol Direction Port Notes BMDP UDP 8197 Required to support NBS. You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\bmdpIpPort registry entry. BMDP TCP 8198 You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\BmcpIpPort registry entry. Controller to the Image Distribution service Protocol Direction Port Notes BMDP UDP 8197 Required to support the Image Distribution service. You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\bmdpIpPort registry entry. BMDP TCP 8198 You can configure the use of port 8197 using the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetControl\BMSS\BmcpIpPort registry entry.
实验环境介绍
因为我没有实际的测试环境所以需要依靠虚拟系统来搭建实验环境，为了提高虚拟机的运算性能，我在VMwareGSX下部署ADS服务器，在Virtual PC部署客户端。每台虚拟机都会分配128M内存，并为ADS服务器和原型机部署Windows Server 2003企业版。DHCP则使用实际环境下的服务器。因为服务器和客户端都使用动态IP分配，所以在这里就不再只能每台设备的IP地址。当然大家也可以根据自己的习惯选择虚拟机软件。
呵呵，忘记介绍我做实验用的宿主机配置。PIV2.4G/512M/80G，跑两个虚拟机是没有问题的，就这样的配置曾经还跑过三台虚拟机作群集实验，不过我想磁盘寿命估计已经大大减少。
部署 ADS 服务器
微软为我们提供了ADS的免费下载，你可以从本文相关链接中获取它的下载地址。下载得到的文件是一个自解压文件包，我将其解压缩在系统所在磁盘并将目录命名为ADS_Setup.当解压缩完毕后ADS的安装主界面会自动载入。
ADS的配置信息都保存在数据库中，为此要先安装MSDE.当然也可以安装SQL Server 2000，这个我们在之前已经提醒过。
点击ADS主安装界面中的“Install Automated Deployment Services”开始安装。
在此次实验中，我将会把ADS的三个组件都安装在这台服务器上，为此在安装类型选择中选择“Full Inetallation”。这里要注意的是请使用默认的安装路径，否则在下来的部署中可能会遇到意外错误。(这是微软专家们提到的，我想还是照办为好!毕竟ADS才刚刚发布没多久，免不了有Bug.)
在点击下一步后会弹出一个警告，因为安装了NBS服务，它包含ADS PXE服务，所以要求在此网络环境中应该禁止存在RIS服务器。点击“OK”继续下一步。
选择数据库，如果没有使用SQL Server那么请保持默认选择。并选择创建一个新的ADS数据库。
这里请在光盘驱动器中放入Windows Server 2003的安装光盘，ADS需要从中拷贝文件来创建客户端引导代理环境所需要的虚拟启动磁盘(RAM Disk)，在磁盘上对应的目录是%Program Files%\Microsoft ADS\WindowsCD.
这一步是创建WinPE预部署环境，我放入WinPE光盘发现并不能安装，可能是因为我的安装光盘不符合要求，或者有其他安装方法，这里我选择不创建WinPE.
注意，请使用默认的安装路径，原因嘛我就不再重复，这个文件夹是用来保存捕获的映像文件的。
在完成ADS的安装后，我们首先要作的是将ADS附带的任务执行脚本模板导入ADS管理器中。有了这些任务模板，我们的工作可是事半功倍，就不需要再去自己编写任务脚本了。为此，需要运行%Program Files%\Microsoft ADS\Samples\Sequence目录中的Create-template.bat文件。
文件执行完成后，在Windows程序项中找到Microsoft ADS菜单项，点击运行“ADS Management”，就打开了ADS的MMC管理界面。展开Job Templates查看是否显示出导入的模板。
为了能够管理客户端执行部署任务，我们需要将计算机添加到ADS中，为此我们在Devices中添加一个设备。
之前我已经创建了一台原型机，获取该原型机的名称及网卡MAC地址并填写在这里。
至此客户端的添加就完成了，但是该客户端端还无法执行任务，为此需要右键单击并选择Take control.
客户端设备默认通过PXE引导，为了能正确进入代理程序，我们需要修改该设备属性中General下的Default job Template选项为boot-to-da.
准备原型机
上面我们已经安装好了ADS服务器，并将原型机添加至设备中。但是如果要成功捕获原型机的系统映像，则必须在原型机上安装ADS代理程序，之后还要再作其他设置。
首先我们将ADS安装包下的ADSAgentSetup.msi拷贝到原型机上并运行它。
ADS和设备之间的安全认证方式与RIS不同，RIS使用活动目录来做验证，而ADS并不需要活动目录环境，所以只能依靠证书来做认证。ADS安装后在其目录下有证书目录，里面有个名字为adsroot.cer的证书，我将其拷贝到我的原型机下，并在这里填写正确的路径。当然，除了使用ADS自带的证书外，也可以使用自己的企业CA.
登录方式选择中，我指定使用系统权限来运行服务。
还是那句话不要修改安装位置。
创建原型机系统映像
在安装完代理程序后，可以回到ADS服务器上，这时你会发现设备中的计算机上的红叉消失了，如果还没有请刷新或者进入此设备属性中填写原型机的IP地址，确认后你的原型机GUID值和正确的计算机名称将被传递过来。在此实验中我是先添加的设备后安装的代理程序，你可以反向操作，这样可以直接成功，ADS也支持自动查找，只要安装有ADS代理程序都能被ADS服务器查找到。另外需要注明的是：如果你要为一台设备部署操作系统，那么只要添加设备时直接填写MAC和名称就可以。
要完成客户端的自动化部署，需要使用sysprep工具在原型机上重新生成唯一的SID，因为执行sysprep后系统会进入最小化安装状态，所以我们还要创建sysprep方式的应答文件。在以前的权威资料中指出的操作是将%Program Files%\Microsoft ADS\Samples\Sysprep下对应的应答文件拷贝到原型机的C：\sysprep\i386下并更名为sysprep.inf，其实我实际测试中此举并不能完成最小化的自动安装。也就是因为这个sysprep，让我反复复位系统了n次。想起来我都头大，郁闷!就这个问题难道资料中就不能指出来么?经过我的反复测试，最终是这样顺利完成实验的。
首先，在C盘下建立名为sysprep的目录，将系统安装盘下deploy.cab文件中的setupcl.exe、sysprep.exe、setupmgr.exe提取拷贝至C：\sysprep目录下。
然后，使用setupmgr.exe制作sysprep方式的全自动应答文件，保存在C：\sysprep目录下，并命名为sysprep.inf.对比ADS自带的应答文件你会发现有所不同，ADS自带的应答文件中没有包含OemSkipEula的值，这样将直接导致在客户端设备进入最小化安装后，会提示你确认协议。另外关键的地方在产品安装钥匙、计算机名、超级用户密码、工作组名这四处。(其中最关键的是前三项，不过我实验过程中发现如果在原型机上已经设置了超级用户的密码，那么你只需要关注前两项就可以了，因为就算你在应答文件中重新输入新的密码仍然不会更该之前的密码。)他们是类似^ADS_Computer_Name^这样的字符串，这就是ADS变量。而我做的自动应答文件是不会被ADS所识别的，必须修改其中关键的那四项字符串。为此请对照两个文件修改!
最后，一定要在C：\sysprep目录下建立一个名为i386的目录并在其下建立名为$oem$的子目录，否则你的自动应答文件写的再好，sysprep后进入最小化安装模式也不会被应用。就这个问题，我实在不知道该怎么泄愤了，也许官方的资料并没有错，而是我哪里疏忽了，但实际中却必须要这样做。具体可以参考我的一篇Blog：http://goxia.maytide.net/p/sysprep.php
因为没有按照权威资料来做实验，所以我们需要修改任务模板，启动ADS程序组中的Sequence Editor，打开捕获映像的模板capture-image.xml，修改sysprep的路径为你原型机中sysprep的实际路径。
我们要为捕获的映像包起一个便于记忆识别的名字，为此在Capture Image中填入自己需要的映像包名称，为了快速顺利的完成实验，我没有选择Compress这个选项来压缩我的映像包。
要捕获原型机的系统镜像，需要为原型机指定任务。为此，在设备上右键选择Run Job…
因为之前我已经导入任务模板，所以这里选择Use an existing job template
在列表中选择我之前修改过的任务模板：capture-image
此时原型机开始执行所分配的任务，在执行Sysprep后系统重新启动进入PXE引导。
此时载入RAM Disk，为进入代理模式作准备。记得第一次实验ADS1.0时就在这里被卡了，反复测试都无法通过这里，也不知道因为什么，看capture-image中的命令没有什么不对，后来也就是因为这个问题才结束了实验。后来在ADS1.1的首次测试中，一次就过去了。估计不是因为我当时的实验环境不稳定就是因为ADS1.0有Bug.关于ADS1.1的首次测试记录可以访问我的blog：http://goxia.maytide.net/p/ads.php
兴奋的时刻到来了，设备成功进入代理环境，并开始执行捕获系统镜像的任务。现在可以休息一下了!休息一下!秋天到了，天气比较干燥，我建议大家多吃些洋葱，喝些菊花茶。菊花茶，嘿嘿!我去接水喝，一会见!
系统映像捕获完毕后，就可以关闭这台原型机。这里不能提到ADS的一个功能，或者应该说是命令。ADS捕获的镜像被打成包保存在C：\Image下，此包的扩展名是。img，ADS中imgmount.exe命令可以将这个映像包映射为本地磁盘以便我们查看其中的内容甚至修改里面的内容。在命令行环境下键入imgmount /m /w filesname.img，其中/m参数就是加载映像也可以/mount./w参数能够实现映像文件映射为本地磁盘后对其的写操作。
如果要卸载这个磁盘则运行：imgmount /u filesname.img，更多的命令可以使用/?来查看。
为客户端部署映像
完成了系统映像的捕获实验，大家是不是心里很开心。映像得到了，我们就该完成此次ADS实验的最后一个环节。这样心里才舒坦，您说是不!俏皮话就不多说了，我只是为了缓解一下我写此文时的疲劳感!
我用Virtual PC创建了一台虚拟机使用client命名计算机，分配了16G的硬盘空间，内存还是128M，首次开机引导之后将其关闭，然后打开。vmc文件，也就是虚拟机的配置文件。记录下MAC地址以备之用。(不这样做，你新创建好的虚拟机配置文件中是不会产生MAC地址的。)
客户端的部署仍然需要在ADS将其添加到设备中。
同样将其默认任务配置为boot-to-da，因为只有这样客户端在PXE引导后才能进入代理模式接受ADS服务器的管理。
还记得前面提到的sysprep的应答文件么?因为在应答文件中使用了ADS的变量，所以我们要为这个设备指定对应的变量值，以便自动完成客户端系统的部署。为此，在User Variables下创建三个必要的值：“productkey、adminpassword、machinename”，同时我们也可以加密这些值使之无法被查看，为此请钩选“Encrypt value”，其中产品安装钥匙的格式应该为xxxxx-xxxxx-xxxxx-xxxxx-xxxxx，同时我们还可以创建更多的变量值来满足我们的部署需要。如指定客户端的IP、DNS等等。此外ADS在群集系统的部署中能够帮助我们减少很多宝贵时间。
现在，我们需要使这个设备处于被管理状态，为此请执行Take control
在ADS服务器端的准备已经完成，我们可以重新开启客户端计算机了。这时客户端通过PXE引导载入RAM Disk进入代理环境，等待服务器发布执行任务。
要执行部署，需要指定部署所需要的任务，所以使用模板编辑器打开da-deploy-image-wg.xml，这个文件是ADS自带的部署模板，如果没有它们可以想象我们要费多少精力。
自带的这个模板默认是5G的分区，如果你的原型机分区与之不符就会导致部署失败，所以在此修改容量值。
之前捕获的映像名还记得么?所以我们需要在Download image中指定正确的映像名称。
由于我更该了sysprep.exe的默认位置，所以需要在Set sysprep custom info in the sysprep.inf file中修改正确的路径。
回忆一下是否正确的完成上述步骤，OK!检查完毕，让我们我们开始完成此次实验的最后一步，为客户端指派部署任务。注意：使用Virtual PC+PXE虚拟磁盘的朋友请将这个任务模板中最后两个boot-to-hd删除。否则你会失败!
选择da-deploy-image-wg为部署任务。
这时客户端开始执行部署任务，你会发现客户端此时已经开始获取映像。兴奋!!!吸根烟，闭目养神休息会，嘿嘿!别告诉你办公室不能抽烟，那叫惨!注意：使用Virtual PC创建客户端的朋友们注意，此时最好把你载入的虚拟PXE引导盘out出去，否则接下来的启动你会失败。
忘记告诉大家，ADS还为我们提供了一个任务监视功能，请在ADS控制器中的Running Jobs下双击当前正在执行的任务，这时你就能够监视到每个任务的执行情况。
在映像获取成功后，客户端重新启动计算机进入最小化安装，此过程将一路闪过，就因为我们使用了正确的应答文件及配置方式。
完成最小化安装后，系统再次重新启动。这时系统将完成最后的任务，将ADS设备属性中的默认任务改为boot-to-hd(从磁盘引导)。在实际环境中因为默认是网卡引导，所以可能会导致设备重新启动后进入PXE引导环境进入代理环境。看看人家微软在设计的时候考虑的多么周到啊!：-P
至此使用ADS部署WinSrv2003的实验就成功完成了。大家心里怎么想的?希望能来五月时节社区参与讨论，网址是：http://forum.maytide.net
实录感想
从第一次开始ADS实验到最终成功完成实验到完成这篇文章，历时近2个月，实际中试验用就去了了1个多星期的时间。其间真是波折起伏，总想放弃但又实在狠不下心，就这样跌跌撞撞中完成了实验。不过好赖总算给自己了一个完美的交代，心里也畅快了很多。
机器配置差，中文资料不丰富，英文资料读不全照实让我吃了一次亏。我想大部分的朋友也跟我差不多少。该反思一下了，反思之后发现做这行对我真没什么前途，具体的心思保密啦，个人隐私!
回到主题，让我们回忆一下之前的操作步骤，其实并不十分繁琐。相反利用微软的ADS完全可以实现我们的自动化部署任务。怪不得微软谈到利用ADS使管理员可以轻松的完成1000台服务器的部署。我很希望能尽快完成客户端的部署实验，大家可能更加关注的也是这个话题。假设，在一个200台客户端的企业环境中，如果使用的是相同的硬件并支持PXE引导，那么管理员对系统的部署将会多么轻松。一切都是在服务器端控制下完成，客户端只需要完成PXE的引导设置就可以。而且利用ADS还可以搭建一个管理平台，利用ADS强大的脚本功能来控制管理客户端，这些都等待着大家去发掘，不要去考虑ADS能干什么，完全看你利用ADS都做了什么，这才是最关键的。如何有效利用工具才是真理。
从这次实验中再次证明!!!
只有敢于攀登顶峰的人，才能将顶峰踩在脚下。
不怕失败，超越自我
文章到此也该结束，实在太累了!本人文学功底不强，技术能力也是在学习中得以提高。斗胆写此文章，希望没有浪费大家的宝贵时间，反而更希望能帮助到大家，这才能激励我、鼓舞我。
