我正在尝试从Outlook COM-addin内部查询MAPI收件人的Active Directory属性。这是我第一次处理广告查询，到目前为止我发现的唯一方法似乎并不完全理想，所以如果有更多经验的人能在我继续实施这种方法之前插话，那就太好了。
所以，这是我想到的:
- 读取接收方的
PR_EMAIL_ADDRESS_WMAPI属性值。 - 使用
IDirectorySearch查找legacyExchangeDN属性匹配的ldap表项。
这看起来很简单，概念验证也很有效，但是:
- 我已经有一个唯一的ID -为什么我要做一个实际的搜索?是否应该有一些直接访问AD用户对象的方法，例如，通过某种方式使用我所拥有的关于收件人的信息来构建一个ldap路径，我可以简单地传递给
ADsGetObject()?属性名称中的术语"legacy"暗示这可能不是一个好的长期策略。 - 上面的列表中实际上缺少一个步骤:在我可以使用
IDirectorySearch之前，我需要确定要搜索的根容器。现在我正在查询"LDAP://rootDSE"，然后要求"defaultNamingContext"属性来制定一个新的查询。这是普遍安全的吗?例如，当我的插件的Outlook 2010主机连接到多个不同的Exchange服务器，并且我需要查询的收件人不是来自默认服务器时，这是否也有效?
顺便说一下，我正在使用优秀的Redemption库来访问扩展的MAPI层，所以我实际上不是在使用IMailUser，而是使用IAddressEntry。所以，如果有更好的方法来做我在库中尝试做的事情请随时提出建议
里面有很多问题，但还是继续。
总的来说，你的概念和流程是正确的。您必须记住的是Active Directory和Exchange是两个不同的系统。他们紧密结合，但你仍然需要搜索广告找到他们的帐户。MAPI早于Active Directory，而且在这个托管框架的世界里还没有很好地老化，这并没有什么帮助，所以除非在Redemption中内置了一些东西来为你获得AD用户，否则你只能靠自己了。
啊,legacyExchangeDN。听起来有更好的东西要来了，对吧?没有。自Windows 2000首次发布Active Directory以来，该属性一直是AD帐户和Exchange邮箱之间的主要链接。这是在Active Directory中查找邮箱用户的最佳方法。使用是安全的。
你的最后一个项目足够复杂，可以作为它自己的问题。对于95%的Exchange和Active Directory安装，假设您的外接程序是在现场或通过VPN使用的，那么您的方法是可以的。但剩下的5%非常复杂。您可以使用Exchange进行一些疯狂的设置，范围从不同的域到不同的森林以及托管的Exchange环境。老实说，如果你需要能够查询AD从任何配置，我会问，作为它自己的问题。
最后，对于大多数公司局域网情况，您可能会很好。托管Exchange将导致问题，因为您通常无法访问后备Active Directory。