That is a trifle scary... Rerun that and see if it has changed, also change your query to use objectcategory=person instead of objectclass=user unless you have indexed objectclass, you will find it runs faster that way.
If the counts are still off like that I would start looking for the specific objects that are off and see if I could figure out from that what might be happening. Also, when doing a count you don't need to -sort, you are submitting an unneeded control to AD. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Tuesday, May 16, 2006 6:39 PM To: [email protected] Subject: [ActiveDir] User Object Attribute mismatches on different DC's Evenin' All, Had the pleasure of jumping into warm waters at work today with a client where an authoritative restore was performed a few weeks ago following an OU being mistakenly deleted. Under this OU were a number of users whom have yet to be wholly migrated to AD but are still using their legacy NT4 accounts to access Exchange 2003 (i.e. disabled user in AD) before they are fully migrated to AD (Windows XP)... all DCs are running Win2K3SP1 ... I've discovered a number of mismatches between certain attributes of thes user objects according to the DC you query... <plug> For example, if I use the infamous ADFIND tool </plug> Using the following syntax I query the homeMDB attribute on each DC Syntax: for /f %%a in (mydclist.txt) do adfind -h %%a:389 -b "OU=RestoredOU,DC=MYAD,DC=ACME,DC=COM" -c -u ACME\admin -sort name "dn" -f "&(objectClass=user)(!(homeMDB=*))" The following information is returned (paraphrased) AdFind V01.30.01cpp Joe Richards ([EMAIL PROTECTED]) January 2006 Using server: gbsrv01.myad.acme.com:389 Directory: Windows Server 2003 1804 Objects returned Using server: gbsrv002.myad.acme.com:389 Directory: Windows Server 2003 1804 Objects returned Using server: ussrv001.myad.acme.com:389 Directory: Windows Server 2003 2669 Objects returned Using server: itsrv001.myad.acme.com:389 Directory: Windows Server 2003 1804 Objects returned Using server: nlbek31w3ls001.myad.acme.com:389 Directory: Windows Server 2003 4260 Objects returned Using server: ussrv002.myad.acme.com:389 Directory: Windows Server 2003 2670 Objects returned Using server: essrv001.myad.acme.com:389 Directory: Windows Server 2003 4146 Objects returned Using server: sesrv001.myad.acme.com:389 Directory: Windows Server 2003 1804 Objects returned Using server: frsrv001.myad.acme.com:389 Directory: Windows Server 2003 4090 Objects returned etc........... Interestingly, in certain cases, particular servers, not necessarily in the same site, return the same value of objects (not 1804) Given that the query is looking for user IDs with empty homeMDB, less is good.... and given that 1804 objects returned (seems) to indicate that these are the DCs with the correctly populated homeMDB attributes, my questions are thus: (1) Is a USN problem associated with the restore a possible cause here? (2) Given that a REPADMIN /showutdvec on all DC's reveals no USN inconsistencies as such, and that replication is working correctly, how was this situation likely to come about? (3) What's preventing successful update of these attributes (dumb question maybe but I want to be certain) (4) (Big If) but can I force replication from my suspected good entries to overcome this issue Granted, there's a paucity of information to go on... but I'll try and elaborate as the night goes along :-) Many thanks, Mylo List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
