扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
经过几天的反复测试,终于完成了ADS部署XP的试验。看来不经过反复的失败、试验是无法从胜利中得到技术和知识积累的。
ADS原则上是不支持桌面操作系统的,因为ADS控制客户端必须依靠ADS代理,而进入ADS代理环境有两种方式,第一种是在Windows 2000服务器版和Windows Server 2003上安装代理程序,而此程序只支持有限的系统版本;另一种是使用PXE引导至ADS的代理环境。从以上所述可以看出要想真正的实现全自动化部署,ADS代理占着至关重要的地位。
经过多次的试验,XP的全自动化部署还是可行的。重点在于选择正确的部署顺序,并修改执行任务脚本。在这次的试验中,我的方法如下:
1、安装XP原型机,做系统准备工作,生成全自动化mini安装应答文件,并修改相应的变量,最后手工执行sysprep及其必须的参数;
2、在ADS服务器中添加此设备,修改默认任务为boot-to-da,添加此设备对应的变量并授予控制;
3、开启原型机,检查其是否顺利进入代理环境并进入预备状态;
4、创建新的Capture-Image任务脚本,其任务顺序是:捕获系统映像(或其他分区映像)—> 修改原型机的sysprep.inf(因为原型机上的sysprep.inf包含ADS变量,当重新启动后会无法正确执行自动化mini安装,所以要将变量修改为实际值)—> 将原型机默认任务修改为boot-to-hd —> reboot ;
注:此步骤虽然按照自动化理念执行,但是当原型机重新进入系统后,ADS的控制便会出现错误,首先表现在任务执行最后一步reboot无反馈,导致任务一直在执行状态,这时候你需要手工停止任务。原因很简单原型机上未安装ADS代理,曾经尝试在任务脚本最后添加adsdevice /rc ,但是发现在代理环境下不允许执行此命令,所以最终还是要手工将其释放控制。不过,我感觉最后的reboot可以更换为shutdown,这样原型机关闭电源后,ADS设备中就可以正常释放控制,否则你会发现原型机重新启动后,ADS设备管理中你无法释放控制。
5、在ADS设备中添加要部署的客户端设备,修改默认任务为boot-to-da,添加此设备对应的变量并授予控制;
6、开启此客户端,检查其是否顺利进入代理环境并进入预备状态;
7、创建新的Deploy-Image任务脚本,其任务顺序是:对客户分区(如果存在多个分区,你可以添加多条分区指令)—> 部署映像(如果要部署多分区映像,可添加多条指令) —> 修改目标客户端上的sysprep.inf —> 将原型机默认任务修改为boot-to-hd —> reboot ;
至此ADS部署XP就算完成,如果客户端支持网卡远程启动,那么就实现了真正意义上的全自动化。多么希望ADS代理支持XP或者 2000PRO,曾试着解包代理程序去掉系统版本验证,可惜对这些确实不精通无奈放弃,希望其他朋友能有能力修改代理程序使其支持桌面版系统。
在此次的试验中我大概算了一下时间,捕获和部署映像的耗时差不多,在PIV2.4G/128M的虚拟机中,各需10多分钟,而这个时间还只是捕获纯系统映像,如果系统安装有应用软件,或包含其他分区映像捕获需要的时候可能更长。而ghost单机克隆时,只需要3分多钟,但是ADS的优势还是显而易见的。
接下来我将找一个实际的环境进行大规模部署测试,希望能拿到一个实际数据来对比ghost网播。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者