一旦了解些AD了，你可能在考虑赋予应用程序目录功能的时候，被引至过度使用所有关于AD的新功能。实际上，大多数程序员都会经历一个把目录看做是另外用途的数据库的阶段。为了避免这个独特错误所导致的代码重写，应该始终记住AD和绝大多数其它基于LDAP的目录实质上是一个“关系用户”信息的仓库。
虽然，你可以在AD中存储具体应用程序的数据，但不要期待由此获得许多的好处。例如，许多开发者希望有通用的自动化的治理，但不可能得到。你可以从“Active Directory用户和计算机”治理器的“高级功能”（在“查看”菜单中）的设置中理解到这一点。请看下图：
你看DNS在AD中存储的信息，注重，虽然AD的治理功能可以用统一的格式显示这些数据，但是不知道如何解释它们，同时只有极少的数据答应在这里修改。当然，DNS治理器插件知道如何作解释和修改，但是这些功能的代码是为此而专门编写的。你不得不提供类似的功能来治理你决定存储到目录中的任何数据，你不得不以同样的方式在AD之外进行操作而不管它的数据存储结构。
最后：请继续使用你原有的方法保存应用程序和配置的有关数据。除非象微软的DNS服务一样，你需要可靠的治理和配置在多台机器间的数据复制，这种需求在这个规则中是个例外。在绝大多数应用程序中，不管是数据库还是注册表，AD都不能作为它们的替代品。
同时应该避免一开始就依靠特定目录的架构或者层次关系。虽然目录中的对象和它们的属性在AD中作了很好的定义，但是对象的层次并没有，每个系统治理员都可以对之作任何改变，也可以用怪异的或奇妙的办法进行目录连接。注重，在这里的“可以改变”有“将会改变”的意思：开发者在目录中存储不正确数据的倾向的地方，系统治理员经常会在这些地方因为不明显的原因乱调对象的层次，或者做一些象在域控制器容器中创建用户对象一类的事情。
不作对象所在位置的假设，意味着你的目录查询代码可能最终看起来复杂而没有必要。但记住，这是使应用程序可扩展的唯一办法。