The other day I had an IM conversation that went sort of like:
AD Engineer [12:37 PM]:
I’ve got a puzzler here… you around? I know it’s lunchtime
Richards, Joe (Active Directory) [12:37 PM]:
what up dog?
AD Engineer [12:38 PM]:
lol
k in ADUC, tool of champions, I see a count
Richards, Joe (Active Directory) [12:38 PM]:
What is this ADUC that you speak of?
AD Engineer [12:38 PM]:
COMPANY.COM\OU1\OU2 has contacts, sync’d from Lotus notes
so…
filter is set to 2000 objects by default
Richards, Joe (Active Directory) [12:39 PM]:
k
AD Engineer [12:39 PM]:
click the OU, and it shows 2000 of 15048
Richards, Joe (Active Directory) [12:39 PM]:
k
AD Engineer [12:39 PM]:
use adfind -b ou=OU2,ou=OU1,dc=company,dc=com -h dc01 -sc adobjcnt
and I get 8264
Raise your hand if you think AdFind has the right count.
Ok.
Raise your hand if you think ADUC has the right count.
Ok.
Anyone encounter this before?
Likely anyone who has more than 2000 objects in any container in their directory that they have looked at in ADUC has seen this situation whether they knew it or not.
Sometime after Windows 2000, Microsoft decided that there were containers with lots of objects in them and that GUIs likely needed to make decisions about how to best display the information based on the number of objects in the containers. For example, if you know a container has around 10 objects in it, there is no real performance hit to grab them all and display them. However, if the container has 10,000 objects in it, there could be a serious impact to performance and you could lock a GUI up waiting for the objects to get pulled across the network and populated. So Microsoft added a new attribute in Windows Server 2003 (and ADAM) to address this need.
The attribute is called msDS-Approx-Immed-Subordinates. The documentation on the attribute is here.The attribute is a constructed attribute built on the fly every time you ask for it. It is a rough order of magnitude hip shot SWAG for the number of child objects in a container. The value could be close or it could be pretty far off, the more objects, the more “off” it will likely be. The idea is to give you a rough order of magnitude so you can make some decisions on how you want to access and display the data.
Here are some examples:
[Wed 11/10/2010 22:38:43.00]
C:\>adfind -schema -s base msDS-Approx-Immed-Subordinates -list
2254[Wed 11/10/2010 22:40:35.23]
C:\>adfind -schema -s one -c -list3992 Objects returned
[Wed 11/10/2010 22:40:41.40]
C:\>adfind -default -s base msDS-Approx-Immed-Subordinates -list
186[Wed 11/10/2010 22:41:39.81]
C:\>adfind -default -s one -c -list39 Objects returned
[Wed 11/10/2010 22:41:49.01]
C:\>adfind -config -s base msDS-Approx-Immed-Subordinates -list
12[Wed 11/10/2010 22:44:23.68]
C:\>adfind -config -s one -c -list10 Objects returned
You will notice that the smaller the true number, the closer the SWAG is.
So now here is a nice side use of the attribute if you need to find any empty OU’s so you can clean up your environment (we all need a little bit of cleanup right?) quick and easy like…
adfind -default msDS-Approx-Immed-Subordinates -f objectcategory=organizationalunit -csv | findstr \"0\"
That will give you a listing of all OU’s that have no objects in them.
Cool?
joe
