AD(活动目录)有一个非常基础，非常重要的功能，就是形成企业的组织架构。由于AD里面的数据是基础数据，所以全球所有主流应用都会使用AD里面的组织架构数据。

 最常见的就是Outlook，当你打开在Outlook里面打开或者写一封邮件的时候，你双击某个人，就会出现联系人卡片，然后卡片里面有组织架构，你可以看到那个人的老板，他的平级同事，他的下级同事，他老板的老板等等，这些数据都来自于AD。

Lync也是一样，点击Lync里面的联系人，同样会出现联系人卡片，同样会看到那个人相关的组织机构。

实际上，你用这个方法可以查看公司里面任何一个人的组织信息，当然，也可以看到这个公司的组织架构树。

很多的工作流或者BPM工具也大量使用AD里面的组织架构数据做流程走向的判断。

但我们帮很多企业构建，升级，优化，整理他们AD的时候，发现非常多企业的AD在构造企业组织架构的时候，使用的方法是不对的。

我们看到很多企业使用OU构造组织架构，他们用OU的容器建立一个部门，如何在这个部门下面加入员工账号，以及建立子部门，以此类推，这样当全部完成之后，在AD管理工具里面看OU的时候，就可以看到组织架构了。

单当他们使用Outlook的时候，他们会发现他们无法看到组织架构，这个时候客户就会很迷茫的问我们，为什么会这样？其实很简单，这种做法不对。

正确的做法是，AD里面每个账号的属性对话框里面都有一个选卡叫Orgnazition，这个选卡里面有个属性，叫Manager，就是经理，这个属性至关重要，决定一切，通过给每个账号设置正确的Manager，你企业的组织架构才会在AD里面正确的形成，所以组织架构和OU无关的，和各种组也无关的，只和Manager这个属性相关。

这样做了之后，全球所有主流应用程序就都可以正确读出你企业的组织架构了。

但可惜的是微软并没有在AD里面做一个可以看到整个组织架构的界面，同时给每个人设置Manager的工作也很大，也不大方便，所以这个时候，我们光合信息一个倍受欢迎的产品“AD管理平台”就派上用场了，我们的这个产品是基于Web的，可以一目了然的浏览，管理和编辑企业的组织架构。

转载：光合信息http://www.guanghe.it/wblog/ADzuzhijiagou.html