Building an Outlook Add-in: completing work on the Active Directory query

ToDo’s (from last post):

  • Implement the GC (domain-less) query, rather than orient to the current implicit binding to the user’s current domain
    • Big question to answer: are all the fields of interest being replicated in the AD GC?
  • Implement a reasonable collection that will be useful to the calling code, and return the user info in the return value
    • After 15 minutes in MSDN Library and some wide-swath google searches, it sounds like the NameValueCollection class is fairly suitable: hashtable-based, strings-only, and allows multiple values for a single key (which may come in handy later for multi-value directory data, of which AD allows a few)
  • Start testing this beast against the company AD

Y’see, this is one of the problems with doing code development in your spare time – I’m facing a major uphill climb, trying to remember (1) where I was going next, (2) where the next layer of function calls was supposed to get plugged into, and (3) which article I was reading that headed me down this design path.  Arrgh.

So I’m starting over with the first “article” (actually MSDN video demo) that caught my fancy, and downloaded the sample code.  I have an idea of (1) – to plug the utility class that scrapes AD for user data into the code that calls the Winforms-wrapping-WPF control, and display the user data in that blank context menu window I’ve already sketched out.  By wandering around the sample code, I’m hoping to figure out (2) without having to review every line of code and compare to my own design “pattern”.  Presumably by retracing the steps outlined in my blogs, I’ll be able to quickly stumble across (3) – again, without having to review every word I’ve written.

God I hope this works.

Acquiring the user’s Email Address

Fortunately, by looking in the sample code’s ThisAddIn.vb class, I’ve already discovered a helpful Function that I knew I needed somewhere.  A quick trip to a VB-to-C# converter and I’ll drop this into my own ThisAddIn.cs class.

However, there’s no direct property of an IMsoContactCard object that corresponds to the contact’s email address – for that I had to find this sample code that does a conversion.

D’oh! Nope, even that just ends up returning the X.500 version of the Exchange mail address.  Instead, I ended up back at this article that I’d read before, which provides a great GetSmtpAddress() function in VB.  Oh, *right* – which I’d already implemented in my project’s code a few weeks ago.  See what I mean about this “once a week coding” nonsense?

Here’s my completed OnClick() method for the Contact context menu item, that calls into my ActiveDirectoryUser class:

public void onGetUserDetailsClick(Office.IRibbonControl control)
        Office.IMsoContactCard card = control.Context as Office.IMsoContactCard;

        if (card != null)
            // Here's where we need to instantiate the UserDetailsPopup() object
            UserDetailsPopup UserDetailsInfoForm = new UserDetailsPopup();

            string emailAddress = GetSmtpAddress(card);
            ActiveDirectoryUser user = new ActiveDirectoryUser();
            NameValueCollection coll = user.getGcUserData(emailAddress);
            // Here's where we handle this edge case
    catch (Exception ex)
        // Handle the exceptions
        Console.WriteLine("Error spat out" + ex.Message);

Much later, after a couple of hours of debugging this slapped-together code, I’ve finally arrived at a method that’s finally deriving the output of live queries against AD.  And I have an answer to the big question: no, not all of the really useful attributes are being replicated to the GC.  The most obvious one that’s missing would be the job description-oriented attribute.  Of all the User object custom attributes *not* to replicate, why did they pick on this one?  Is it really so hard to believe that someone would want to query this value in a global directory?  Looks like I’m going to have to implement some referral chasing and see if that doesn’t tank the performance of the add-in.

Completed GC-querying Method

Here’s my GC-querying method call to derive the GC-replicated attributes (using “department” as substitute for the the custom attributes internal to the organization that I’m going after):

public NameValueCollection getGcUserData(string emailAddress)
    NameValueCollection returnValue = new NameValueCollection();
    DirectoryEntry gc = new DirectoryEntry("GC: ");
    DirectoryEntry _root = null;
    using (gc)
        //there is only 1 child under "GC: "
        foreach (DirectoryEntry root in gc.Children)
            _root = root;

    //Note: the filter must be searching for a GC replicated attribute!
    string filter = String.Format(
        "(mail={0}) ",

    DirectorySearcher ds = new DirectorySearcher(

    using (SearchResultCollection src = ds.FindAll())
        foreach (SearchResult sr in src)
            returnValue.Add("department", sr.Properties["department"].ToString());
    return returnValue;

Next Steps

Need to figure out how to bind the NameValueCollection to the XAML for my WPF-based add-in.  Then I need to find my ass with two hands and a map.  And after that, perhaps I’ll look into the complexity of referral chasing to get the non-GC-replicated user attributes.

Acknowledged: the two simple articles that saved my ass twice now

Extending the User Interface in Outlook 2010

Customizing the Context Menu of a Contact Card in Outlook 2010

One thought on “Building an Outlook Add-in: completing work on the Active Directory query

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s