活动目录常见问题

一、导出用户和组信息

可以使用CSVDE使用以逗号分隔 (CSV) 格式存储数据的文件从 Active Directory 导入和导出数据。CSVDE的语法

csvde [-i] [-f FileName] [-s ServerName] [-c String1 String2] [-v] [-j Path] [-t PortNumber] [-d BaseDN] [-r LDAPFilter] [-p Scope] [-l LDAPAttributeList] [-o LDAPAttributeList] [-g] [-m] [-n] [-k] [-a UserDistinguishedName Password] [-b UserName Domain Password]

导出ad用户和组的具体设置如下：

1.开始－>运行”并输入“CMD”

2.csvde -f c:filename.csv ?-r objectclass=user

3.csvde -f c:filename.csv ?-r objectclass=group

二、系统ghost恢复后不能连接域控制器

client一旦加入域之后，如果要使用ghost来恢复系统，那么需要这么做：

1、安装好client系统，安装完最新的补丁，也可以考虑安装一些基本软件。

2、针对现有系统开始执行sysprep ，关于操作步骤，请参考

http://support.microsoft.com/default.aspx?scid=kb%3bzh-cn%3b298491

http://support.microsoft.com/default.aspx?scid=kb;zh-cn;302577

做这一步的目的，就是抽取硬件信息。做完之后，系统就会关机了。

3、对这台机器的引导区作ghost，以后恢复就用这个母盘恢复了。

Note：您会注意到上面的动作，并不是将client加入域之后再ghost，为什么呢？ok，下面我说一下您之所以遇到这个问题的原因：

ad在设计的时候，为了保证client与dc之间安全的通信，要求client在加入域后，client的计算机账户需要定期与dc的计算机账户保持同步（这个期限默认是30天），也就是说，当client与dc发生验证动作的时候，其实是先用计算机账户去验证，然后才是用户账户验证（也就是您输入用户名和密码）。那么，为什么要这么做呢？因为，用户名和密码是比较容易伪造的，如果在任何验证发生之前，先校验计算机账户的安全性，校验通过之后，再校验用户账户，那么整体验证的安全性就得到了保证，相对于用户帐户，计算机账户就比较难以伪造。

微软通过如下两个方法来保障计算机账户验证的安全：

其一、ad不允许任何用户模式下的程序或者用户模式下的交互动作，去干预或者设置计算机账户的同步（由这个同步动作建立的通道，微软称之为 security   channel），

其二、计算机账户将会关联计算机硬件信息，然后用形成计算机sid（sysprep的动作就是抽取了这部分信息）。

ok，那么我们重现一下您遇到的问题。您可能在将client加入域后，没有作sysprep，然后直接ghost。然后这台计算机启动登录到域，于是dc验证当前client，通过验证，随后与client计算机账户进行同步（这个动作对用户是透明的），好，这些都没有问题。

过了一段时间，这段时间可能超过了30天，您使用之前的ghost进行恢复，然后再次尝试登录到域，dc验证当前计算机账户的时候，与ad中的那个计算机账户对比，发现已经超过了30天，那么出于安全考虑，认为该计算机账户是不可信任的（怕是伪造的），于是就给出一个错误信息“windows 无法与此域连接，原因是域控制器存在故障或不可用，或者没有找到计算机帐户，请稍后再试。如果此消息持续再现。请与系统管理员联系以得到帮助”，在这种情况下，不是说dc有问题，而是说client的计算机账户有问题，请管理员出面解决。管理员该如何做呢？把ad中原来的计算机账户删除，然后将客户端重新加入域就可以了。

三、常见问题解决步骤

比如，用户会经常说 “策略应用不到，策略无法应用”等等，那么作为管理员或者面对问题的人，首先要搞清楚这些问题：

1、用户的操作环境是怎样的。比如域的架构，ad的版本，client的os等等。

2、用户作了什么操作，目的是什么。了解用户的操作，往往能够更快的确定问题发生的原因，从而找到问题的解决方法；了解了用户的需求，即便通过后面的步骤无法解决问题，也可以尝试通过变通的方法来解决。但用户的语言描述往往不能准确表达他的意愿，这就要靠后面的步骤来判断。

3、系统有什么现象或者提示？这里一定要确定系统给出的错误信息原文。用户经常会根据自己的感觉来描述问题，这可能会将问题导向歧途。

4、eventvwr.msc中有什么相关的日志？这里一定要确认日志的source and id，进一步需要确定日志给出的log全文。大家都知道，不同的日志会有不同的source and id。由于不同语言版本的词汇不同，source and id是能够精准定义log的方法；另一方面，即便是相同的source and id，错误描述不同，就会存在不同的错误。

5、使用一些工具。还有一些错误，日志中是不会记录的，那么我们如何来debug它们呢？MS使用一些命令行的工具来弥补日志的不足。比如，大家经常在连接网络资源时，遇到的事物处理问题，我们就可以用 net use 尝试建立连接，根据返回的error code，来判断问题所在。再比如，netdom dcdiag nltest 等等。返回的错误信息为中文，不是英文，不利于查找，怎么办呢？我们可以用chcp 437，将当前cmd console language code page转换为英文，这样就可以看到英文的提示信息了。

6、同时，尽量获得错误的英文提示信息或者关键字，这样比较容易通过搜索引擎，搜索国外的专业站点乃至support.microsoft.com。

7、最后，大家可以通过winmag这样的专业社区来交流所遇到的问题。当然如果您具有MS的产品售后，或者同意有偿服务，您还可以咨询MS技术支持。大家在提问的时候，可以尽量清楚详细的描述问题，管理员或者有兴趣的朋友在回复问题时，可能需要更多的数据以确认问题所在，并给出解决方案。

一般来说，故障现场的信息收集包括如下方面：

1）您所使用的操作系统以及所发生错误的软件版本信息

2）您当前所使用的计算机是否处于网域环境，如果需要寻求帮助，当前计算器的IP地址、用户名和密码是否可以获得

3）您当前所要进行的操作及目的

4）您的操作过程、时间、地点及系统或者软件所给出的错误信息原文（合适的情况下可截取错误画面）

5）您所进行的其它尝试以及获得的结果

6）您通过查看windows的在线帮助文档以及support.microsoft.com在线支持，是否能够找到解决方案。或者您也可以参考这个文章来进行debug http://gnaw0725.blogbus.com/logs/4888525.html

7）尽可能保留故障现场，或者能够重现故障现象详尽的描述能够帮助您更快的解决问题。