很多人在测试通过Intel SCS来Provision和管理Intel AMT机器时，为了认证的方便性和适应企业应用环境，一般都会将Intel SCS与Microsoft Windows AD Server进行整合，由Windows AD Server来提供对Intel AMT设备访问的统一认证，这种认证方式是基于Kerberos的。在实践过程中，不少用户碰到了这样的一个问题：通过USB Key或手动的方式设置了iAMT机器的PID/PPS以后，通过SCS Console查看相应的iAMT机器是否被配置，在LOG中一直出现这样的一个错误："Can not create AD AMT Object"。用户觉得很是奇怪，在Windows AD Server端查看了一下日志，也没看到什么特别的异常，会是什么错误呢？
根据我的经验，直觉告诉我用户的Windows AD Server中有些关于iAMT的配置不对，看来很大可能性是用户没有将Intel ME Engine这个object加入到AD Server中，所以造成AD Server无法识别SCS发送过来的请求增加相应iAMT Object的请求。找到SCS Server的安装目录，进入到AdminScripts目录，在命令行方式下执行“cscript CheckSchemaExists.VBS”，果然，提示信息告诉你在AD Server中找不到相应的Intel ME Engine的Object。真相大白了，那么解决起来也很容易了：首先执行 " cscript BuildSchema.VBS", 这是系统会出现一个消息框警告你，点击确定按钮就ok。然后再执行上面CheckSchemaExists的脚本，你就可以看到Successfully 的提示，恭喜你，"Intel ME Engine" 的Object成功加入到AD Server中了。
接下来继续Provision你的Intel AMT机器，成功完成配置！看来其根本原因还是因为用户没有仔细研究Intel SCS的manual，不过话说回来，SCS Manual有些地方也确认是条理不够清楚的，比如执行上述脚本这块，就没有说得很明确。
如果你在做配置参数时候，选择了采用TLS，尤其是采用Mutual Authentication的TLS，SCS还会到CA上面去自动请求证书，也可能会有异常，这个方面的问题我可以在以后文章中继续分享。
本文转自Intel_ISN 51CTO博客，原文链接：http://blog.51cto.com/intelisn/130764，如需转载请自行联系原作者
