ActiveDirectory error 0x8000500c when traversing properties

Question

I got the following snippet (SomeName/SomeDomain contains real values in my code)

var entry = new DirectoryEntry("LDAP://CN=SomeName,OU=All Groups,dc=SomeDomain,dc=com");
foreach (object property in entry.Properties)
{
    Console.WriteLine(property);
}

It prints OK for the first 21 properties, but then fail with:

COMException {"Unknown error (0x8000500c)"}
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Entry()
   at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Current()
   at ActiveDirectory.Tests.IntegrationTests.ObjectFactoryTests.TestMethod1() in MyTests.cs:line 22

Why? How can I prevent it?

Update

It's a custom attribute that fails.

I've tried to use entry.RefreshCache() and entry.RefreshCache(new[]{"theAttributeName"}) before enumerating the properties (which didn't help).

Update2

entry.InvokeGet("theAttributeName") works (and without RefreshCache).

Can someone explain why?

Update3

It works if I supply the FQDN to the item: LDAP://srv00014.ssab.com/CN=SomeName,xxxx

Bounty

I'm looking for an answer which addresses the following:

Why entry.Properties["customAttributeName"] fails with the mentioned exception
Why entry.InvokeGet("customAttributeName") works
The cause of the exception
How to get both working

My first guess at _why_ would be permissions. What context are you running under? — Grant Thomas, Mar 16 '12 at 12:55
@Mr.Disappointment: Just tried with an account that should have enough privileges. No difference :( — jgauffin, Mar 16 '12 at 13:02
Can you try specifying 'God' credentials explicitly via the constructor? Just as a sanity check. — Grant Thomas, Mar 16 '12 at 13:04
@Mr.Disappointment: We got a custom attribute which is the one that I can't access. — jgauffin, Mar 16 '12 at 13:15

score 4 · Answer 1 · answered Jul 02 '14 at 14:18

I have the same failure. I´m read and saw a lot of questions about the error 0x8000500c by listing attribute from a DirectoryEntry. I could see, with the Process Monitor (Sysinternals), that my process has read a schema file. This schema file is saved under C:\Users\xxxx\AppData\Local\Microsoft\Windows\SchCache\xyz.sch.

Remove this file and the program works fine :)

score 4 · Accepted Answer · answered Mar 24 '12 at 22:20

If one wants to access a custom attribute from a machine that is not part of the domain where the custom attribute resides (the credentials of the logged in user don't matter) one needs to pass the fully qualified name of the object is trying to access otherwise the schema cache on the client machine is not properly refreshed, nevermind all the schema.refresh() calls you make

Found here. This sounds like your problem, given the updates made to the question.

score 3 · Answer 3 · answered Mar 21 '12 at 03:04

3

Using the Err.exe tool here

http://www.microsoft.com/download/en/details.aspx?id=985

It spits out:
for hex 0x8000500c / decimal -2147463156 :
E_ADS_CANT_CONVERT_DATATYPE adserr.h
The directory datatype cannot be converted to/from a native
DS datatype
1 matches found for "0x8000500c"

Googled "The directory datatype cannot be converted to/from a native" and found this KB: http://support.microsoft.com/kb/907462

answered Mar 21 '12 at 03:04

Jeremy Thompson

61,933
36
195
321

@jgauffin can you let us know what OS version & SP level? also what is this 22nd property? can you see it using ADSIEDIT.MSC? does that cause an exception/crash when you view this 22nd property? what about the MMC AD Snap-in what does that do when you view this property? – Jeremy Thompson Mar 23 '12 at 04:55
woops custom attribute forget the MMC bit, look this might be a red herring but its not a Not Set property is it? http://stackoverflow.com/questions/7990505/net-code-to-set-an-active-directory-attribute-to-not-set – Jeremy Thompson Mar 23 '12 at 05:05

score 1 · Answer 4 · edited Jul 04 '16 at 04:33

I just encountered the issue and mine was with a web application. I had this bit of code which pulls the user out of windows authentication in IIS and pulls their info from AD.

using (var context = new PrincipalContext(ContextType.Domain))
{
    var name = UserPrincipal.Current.DisplayName;
    var principal = UserPrincipal.FindByIdentity(context, this.user.Identity.Name);
    if (principal != null)
    {
        this.fullName = principal.GivenName + " " + principal.Surname;
    }
    else
    {
        this.fullName = string.Empty;
    }
}

This worked fine in my tests, but when I published the website it would come up with this error on FindByIdentity call.

I fixed the issue by using correct user for the app-pool of the website. As soon as I fixed that, this started working.

score 0 · Answer 5 · answered Apr 18 '18 at 19:26

I had the same problem with a custom attribute of a weird data type. I had a utility program that would extract the value, but some more structured code in a service that would not.

The utility was working directly with a SearchResult object, while the service was using a DirectoryEntry.

It distilled out to this.

SearchResult result;

result.Properties[customProp];     // might work for you
result.Properties[customProp][0];  // works for me. see below

using (DirectoryEntry entry = result.GetDirectoryEntry())
{
    entry.Properties[customProp]; // fails
    entry.InvokeGet(customProp);  // fails as well for the weird data
}

My gut feel is that the SearchResult is a little less of an enforcer and returns back whatever it has.

When this is converted to a DirectoryEntry, this code munges the weird data type so that even InvokeGet fails.

My actual extraction code with the extra [0] looks like:

byte[] bytes = (byte[])((result.Properties[customProp][0]));
String customValue = System.Text.Encoding.UTF8.GetString(bytes);

I picked up the second line from another posting on the site.

ActiveDirectory error 0x8000500c when traversing properties

5 Answers5

Linked