日期时间引发的客户端进入ADS代理而无法完成就绪
今天为一台破机安装系统，安装上CPU和硬盘挂上软驱准备通过ADS来部署系统。发现客户端能够正常地执行PXE引导，并且能够引导RAMDisk，并进入ADS代理环境，可是发现无法进入就绪阶段，屏幕状态最终停止在断开状态，并且键盘挂起无法操作除非复位！
查看了ADS服务器的事件日志发现了一个警告日志，内容如下：
ID：532
描述：
Failed to connect to the device (device name: MAC4C00101F39F5, IP address: 192.168.0.12): Most common causes of ADS connection failures are:
1) The public root certificate is missing. Ensure a public certificate is installed for the ADS Builder service and each device.
2) The public root certificate is rejected because a BIOS date is set incorrectly. Confirm that the date and time on the Controller and the BIOS date and time on the device are the same.
Refer to the ADS troubleshooting guide for more information about connection failures and possible solutions.
刚开始怀疑是主板的问题，因为在开始引导磁盘时BIOS会显示“Unkonw Flash Type”，难道跟BIOS有关导致无法获取证书？但是他们之间不存在直接的关系啊，仔细看了第二种可能的情况重新启动了客户端并进入BIOS设置发现果然是日期造成的。原来主板之前维修过日期恢复为出厂状态！修改为正确的日期时间后，ADS代理正常了，并能够顺利完整部署！
解决因硬件不被DeploymentAgent（ADS代理）支持的问题
因前面写了不少关于ADS的文章受到了大家的关注，很多朋友慕名而来向我咨询关于ADS的问题，今天这篇Blog主要是讲如何解决硬件不被ADS代理支持而导致客户端无法进入ADS代理环境。
ADS执行部署的最关键一步取决于客户端是否能够进入ADS代理环境，只有在进入ADS代理环境后客户端才能够接受ADS服务器的指令。DeploymentAgent（ADS代理，以下简称DA），从开机进行PXE引导后，客户端通过TFTP下载DA，如果在出现DA引导时缓慢或最终中断提示RAMDisk错误，那么通常出现此故障的原因就是因为客户端计算机上的设备不被DA支持，通过ADS的日志和日志查看器中应用程序日志下我们可以看到警告日志，内容大致是提示DA中出现IRQ等错误不被DA识别，经过分析你会看到其实该故障的来源是网卡，那么我们如果让DA识别客户端的网卡呢？并不是像大家所想把网卡的驱动拷贝到System32目录或其他系统目录下，我们只需要将第三方网卡驱动拷贝到“C:\Program Files\Microsoft ADS\nbs\repository\User\PreSystem”目录下即可，之后重新启动“adsbuilder”服务即可。至此问题已经顺利解决！
ADS实际环境部署XP经验总结
经历了漫长而艰难的历程，总算深入的了解了ADS。
经过多次的实验，积累不少经验。早期都是在虚拟环境下测试，虚拟机的配置特别低（PIV2.4G/128M内存），后来决定亲自找个实际环境测试一下。
经过2天的调试测试，总算拿到了一些实际的数据并且收获不小，因为在实际中又遇到很多实际的问题。首先就是硬件兼容性问题，其次是网络架构稳定性问题，最后是数据量问题。
在准备实际环境测试前，已经在虚拟环境中作了多次实验，以避免实际中遇到的问题，感觉都考虑进去了，没想到时却出了问题，先介绍一下实际的环境：
100M交换网络，对等网，190台机器，交换机为主干+多个级联下一级交换，服务器和客户机都是AMD2800+/512M/80G~160G。
部署ADS服务器很顺利，制作好命令脚本后开始部署一台原型机，原型机C盘5G数据占2.5G，D盘5G数据占2G，E盘65G数据占60G，总共的数据量大概在65G。没能仔细统计这个数据比较遗憾，总之数据量不会低于61G。此原型机在主干交换机上，ADS服务器在下一级交换。
为了避免出现不必要的麻烦，我首先测试原型机是否能够正常通过PXE引导进入ADS代理环境，这时问题出现了，几次尝试都失败告终。这一天算是过去了，没想到用别人的环境就是麻烦，一天里干不了什么事情。
晚上回去跟伙计讨论了一会决定明天将原型机和ADS服务器放在一个交换上，因为之前测试发现RAMDISK载入速度很慢，但是我考虑到不排除硬件不兼容的问题，因为原型机的网卡是8169千兆的，而且2003和XP系统都不支持PnP。
早上10点左右过来，此时网络状况相对好些，先测试是否因为网络拥挤造成，启动原型机RAMDISK载入明显加快，但是还是没能进入代理环境，无奈在服务器分析日志最终将故障锁定在驱动程序上，果然在ADS的驱动目录中添加了8169的驱动后，代理环境正常进入，真兴奋！
开始捕获系统映像，顺利完成。之后继续执行我单独编写的脚本，执行D盘捕获时问题又出现了，过程中出现意外I/O错误导致中断，此原型机网卡本身就不是很稳定，难道我就这么点背，直接将其硬盘挂接在ADS同交换的主机上（硬件完全相同），修改脚本去掉C盘捕获继续执行，这次顺利的完成了D盘捕获，接下来就是E盘，数据量超大，足足用了2个小时，天呐！那叫痛苦。不过比起Ghost网播感觉不错了。
因为时间的问题，此次的实际环境测试其实很不是很理想，不过从得到的数据来看，ADS在对客户端部署时对内存的要求并不严格，而对网络速度及稳定性要求很高。因为实际发现512M内存和128M内存作部署的速度相差不大，而传输速度却非常影响，通过监视数据的传输也就在每秒3M~6M间，如果网络环境好，每秒稳定在9M决对可以缩短很长时间，看来网络环境占ADS性能部署的首要因素。
此次实测，C盘的捕获耗时10分18秒（ADS纪录为11点06分54秒开始，11点22分44秒结束），压缩需要6分16秒左右，看来选择压缩时就需要硬件本身的性能。D盘捕获耗时8分14秒（ADS纪录为11点51分31秒开始，12点00分05秒结束），E盘的捕获耗时2小时10分53秒（ADS纪录为12点00分05秒开始，14点02分52秒结束），这是一个单机的捕获！时间之漫长，不过我想按照微软的资料声称在30台-50台下，这个时间应该还是能够在4小时内完成的，伙计曾经在40台Ghost网播下耗时近4小时。如果网络状况非常好，我想时间可以大大缩减，况且也不会有那么多人像我一样进行这么大的数据量部署。
ADS在此次实际环境下部署XP，还是很令我满意得。这时实话，我没有接触过Ghost网播，但是对于ADS这样的部署方式我绝对接受，也认为很简单。GHOST网播也有优势，但是不足之处也是显而易见的。
回来之后就试验把PXE引导的ADS环境提取出来手工安装在XP上，发现服务倒是运行了，可在ADS服务器上却始终抱错，提示ADS代理在一个无效的客户端上，估计还是程序本身对系统版本要求的问题。看来只能再等ADS2.0的发布了。不过此次实践充分证明ADS自动化部署XP绝对是可行的，而且优势于RIS，偶决定放弃RIS改用ADS来做以后的部署，哈哈！
ADS算是告一段落，期待新的版本给我新的惊喜！（今天温度突然下降，变得好冷！提醒大家多穿衣服，别忘记喝羊肉汤、牛肉汤、驴肉汤！:-p）
