ActiveDirectory error 0x8000500c when traversing properties

Question

ActiveDirectory error 0x8000500c when traversing properties

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

c#

active-directory

directoryservices

asked on Stack Overflow Mar 16, 2012 by

jgauffin • edited Mar 20, 2012 by

jgauffin

5 Answers

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.

answered on Stack Overflow Mar 24, 2012 by

Chris Gessler

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 on Stack Overflow Mar 21, 2012 by

Jeremy Thompson

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 :)

answered on Stack Overflow Jul 2, 2014 by

Nerospeed

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.

answered on Stack Overflow Jun 9, 2016 by

Alok • edited Jul 4, 2016 by

David Gardiner

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.

answered on Stack Overflow Apr 18, 2018 by

englebart

User contributions licensed under CC BY-SA 3.0