Hello everyone,

I have this stupid issue...

So, I have security global group which has arround 3000 computer objects and through ADUC when I look at the group and go to Members tab all computers have user's icon.

We manage group membership with the powershell script. Everything is populated correctly, I have checked backlinks on computer objects and repl metadata for a group. So membership is fine, no issue.

And that would be the end for me, but not for the customer. So if you stumbled on something like this let me know. The only thing I had found is KB281923 but that doesn't apply - not the same issue.

Same issue in all environments regardles of DFL, FFL or OS version. Have just checked 2008 R2 FFL.

Thanks

• Edited by Natty976 Thursday, January 24, 2013 8:45 AM

If the objects were created using a script, perhaps some attribute value is incorrect. I would create a test computer object in ADUC and make it a member of any group. Assuming this object shows up in the member list with the correct icon, I would then compare the following attributes of this object with one that displays with the user icon: sAMAccountType (should be 805306369), sAMAccountName (should have trailing "$" character), objectCategory, objectClass, userAccountControl (should be 0x1000).

I've seen computer objects where sAMAccountName does not have the trailing "$" and they still have the correct icon. Note that objectClass should be top, person, organizationalPerson, user, computer.

I assume the icon is correct for these objects in their parent OU/container.

Are those objects cross-domain or even cross-forest referenced e.g the group in one domain/forest and the computer objects in another?

hi Richard,

No, computer objects are created by the action of clasicall domain join. However, this is definitely the same for all huge groups in several different forests. I have checked Domain Computers group which have around 40k members and all are represented as users.

This is the case only while looking at the list of members on the members tab.

Hi Christoffer,

The objects and the group are all in one domain.

N.

Then this is most likely something internal to ADUC (Active Directory Users and Computers) it will be very hard to figure out why this is happening without low level debugging of ADUC.

I agree this sounds like a problem with ADUC and how it displays icons. I would suspect a problem with displaySpecifiers, but you say the icon is correct elsewhere in ADUC. It's only wrong on the "Members" tab for groups in ADUC. It would be very difficult for us to troubleshoot this.

yes, that is correct. And I have noticed that it happens just for the groups with a lot of members (several thousand users).

If I empty the group and add several computers all is good. When I add several thousands of computers - all look like users on Members tab.

I believe it is very easy to reproduce. In the lab environment create few thousands computer accounts and just have a look at Domain Computers group. You should see the same...

I can confirm what you observe. I created 2000 computer objects and they all appear on the "Members" tab of the group "Domain Computers" with the user icon, but with the computer icon in the OU. I would call this a bug in ADUC.

Further testing in my domain shows that 501 is the critical number. 500 computers (or any objects) in a group is fine, but more members results in all computers showing the user icon.

Actually, once a group has 501 or more members, all classes of members (user, computer, contact, or group) are shown with the user

Finally found documentation on this problem:

http://support.microsoft.com/kb/281923

Retrieving the membership of a group just requires enumerating the member attribute of the group (ignoring for now "primary" group membership). This collection of member DN's is parsed for the RDN (name) and canonical name of the parent OU/container, which involves no further communication with AD. However, determining the class of each member requires connecting to each member object in turn, to retrieve the objectCategory. This can be a lot of extra work for large groups, so the system limits this extra step to groups with 500 or fewer members (by default). Above that number and ADUC does not retrieve the class of any members. It uses the same user icon (but with grey hair if you look closely) for all objects. You can modify a registry setting to overcome this limit if desired, as explained in the article I linked. For me, the explanation is enough.

I hope your hair didn't turn grey as you worked on this problem, Richard! ;-)

Richard,

many thanks for confirming the issue. I have mentioned the same KB in my opening post. You explanation is also fantastic and it makes sense. However, the KB referrs to 2003 version and I can confirm it doesn't work on 2008. I've tried it.

It doesn't bugs me and it is much more important to me that members are listed quickly then with the right icon.

As an interesting point, under Windows XP this generic grey haired icon was very easily distinguishable from the standard black haired user objects icon. You immediatley knew it was a generic icon.

It seems that during the graphical improvements in more recent OS releases the icons have been upgraded. The difference between the person icon and generic icon is now almost totally indistinguisable.

Another impact of this can be found when trying to identify Disabled Objects. As the member object has not been queried, it won't show the relevant disabled icon when viewing inside a group.