NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.
A few months ago, I was working on a project to query for specific AD properties of a user-object programmatically. I knew the properties I wanted to return and I had worked with returning properties in ExBPA/HRC. I hadn’t, however, found the joys of receiving a System.__COM object in any of my returns until now.
To explain this, you should familiarize yourself with ADSI (Active Directory Service Interfaces), if you’ve never been exposed to it, before. As the previous link points out, ADSI is a COM (Component Object Model), and – as such – we will get a return of ‘System.__COM’, if we fail to pull the data in the expected format.
So, how was I to return the data from the COM? Well, as it turns out, there’s ‘deprecated’ documentation which helped me farther than any blog, technical bulletin, or reference did. You can find it, here. (Apologies, apparently all of the English versions have been pulled because it was deprecated.)
Using some ingenuity and a little luck, I found the answer to my problem: return the value I’m querying for as ‘ActiveDs.IADsLargeInteger’.
So, armed with this knowledge, I could now pull the properties I wanted to return in usable context, like the following:
ActiveDs.IADsLargeInteger recipientTypeDetails = (ActiveDs.IADsLargeInteger)userResult.Properties[“msExchRecipientTypeDetails”].Value as ActiveDs.IADsLargeInteger;
Once I had the data ‘out’, as it were, I could try to manipulate it:
long recipTypeDetails = recipientTypeDetails.LowPart;
I realize this doesn’t mean much to some people (maybe a lot) but I figured if I could save one person the hours it took me to find the answer, then it was well worth the time in writing this.