Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Powershell CmdLet Get-ADObject fails with "The given key was not present in the dictionary."


Symptoms

You are using the Active Directory CMDLets coming with Windows Server 2008 R2 and Windows 7 Remote Administration tools to interrogate Active Directory Objects. When you print results of the Get-ADObjects CMDLets you get the output:

The given key was not present in the dictionary.

When launching Active Directory Administrative Center the Domain Controller chosen appears to be down. When you click on the domain controller you receive the error message “Failed to access the object. Check data availability or access permissions”:

When selecting “Change Domain Controller”  you receive the error Message  “Failed to retrieve Domain Controller information”:

↑ Back to the top


Cause

The Powersehll CmdLet wants to format the attributes for output and it has a special handling for a number of attributes. This for example includes linked attributes. To track this correctly, the Powershell CmdLet retrieves a list of interesting attributes from the Active Directory.

It then checks this list against the list of attributes retrieved for the Aggregate Schema. The problem occurs when the query returns an attribute that is not in the Aggregate schema.

This can happen for Defunct Attributes that are still returned by the Powerhell query, which are not present in the Aggregate Schema.

When you create a Log of the AD Web Service, you see the schema query as:

ParseEnumerate: [timestamp] [b] filter=(&(objectClass=attributeSchema)(|(attributeSyntax=2.5.5.17)(linkID=*)(systemFlags:1.2.840.113556.1.4.803:=4))), scope=Subtree, baseObject=CN=Schema,CN=Configuration,DC=<forestroot>

↑ Back to the top


Resolution

Retrieve the List of attributes the powershell CmdLet asks for, execute on a DC:

Ldifde /s %computername% /d CN=Schema,CN=Configuration,DC=<forestroot> /r "(&(objectClass=attributeSchema)(|(attributeSyntax=2.5.5.17)(linkID=*)(systemFlags:1.2.840.113556.1.4.803:=4)))" /f powershell-query.txt

Then export the same list, this time without the attributes that are defunct:

Ldifde /s %computername% /d CN=Schema,CN=Configuration,DC=<forestroot>/r "(&((!(isdefunct=TRUE))(objectClass=attributeSchema))(|(attributeSyntax=2.5.5.17)(linkID=*)(systemFlags:1.2.840.113556.1.4.803:=4)))" /f powershell-query-without-defunct.txt

Compare powershell-query.txt with powershell-query-without-defunct.txt using a tool like WinDiff from from the Platform SDK. It would show the extra attributes quite nicely.

The schema attribute should have a property that makes it match the original filter, like it's storing a Sid, is a constructed attribute (would be unusual), but the most common cause should be that a defunct attribute still has a linkID set.

To resolve the problem, you should delete the linkID attribute from the defunct attribute.

↑ Back to the top


More Information

The Active Directory Modules for Powershell need to provide assistance rendering the attribute data for output. So they need to know the attributesyntax and other details so it's displayed correctly. The problem with this query prevents proper matching of attributes.

↑ Back to the top


Keywords: vkball, kb

↑ Back to the top

Article Info
Article ID : 2670098
Revision : 1
Created on : 1/8/2017
Published on : 6/5/2012
Exists online : False
Views : 135