Object count disparity over DCs

[aceonbass]

Hi all,

 

We've just introduced a new 2012R2 Domain Controller into our student domain. Everything was fine with the setup, all SYSVOL and NETLOGON appears to be working etc. I've found a problem in that each of our domain controllers is reporting different numbers for differents things. Here's some examples:

 

 

Site1-DC1(2K8) - Alumni OU = 59,245 total items

Site1-DC2(2K8) - Alumni OU = 25,157 total items

Site2-DC1(2k12R2) - Alumni OU = 63,575 total items

 

Site1-DC1(2K8) - Departments OU = 9,378 total items

Site1-DC2(2K8) - Departments OU = 9,378 total items

Site2-DC1(2k12R2) - Departments OU = 1,476 total items

 

It's a little worrying as the Departments OU is the main holder for active students. Running both dcdiag and repadmin /showrepl on the new DC passes all tests/shows all as succesful yet we're getting this strange disparity. Has anyone encountered this before, or have any tips to check?

 

 

Thanks,

[pete]

What does repadmin /queue * show?

[aceonbass]

Empty queues for all DCs

[pete]

Was this issue present before the mass accidental deletion and restore of the tombstoned users?

 

How are you counting the objects? Try (adjust for your domain):

 

Get-ADObject -Filter {name -like '*'} -SearchBase 'DC=internal,DC=SchoolName,DC=localauthorityname,DC=sch,DC=uk' -ResultSetSize $null | Measure-Object

[aceonbass]

I can only do this for the 20012R2 server, the other two are only 2008.

 

I couldn't say for certain if this was present before the authoritative restore, but this new 2012R2 server was only introduced a couple of weeks after the AR. It must be something to do with it, as we restored roughly 14,000 accounts and I'm ~8,000 down in 'Departments', and ~6,000 down in 'Users' when comparing the 2008 to 2012R2 servers.

 

Both 2008 servers match numbers in an empty search the Departments OU and Users CN in ADUC, but doing the same search on the new 2012R2 server yields a total of 14,000 less.

[MatthewL]

Give them chance to replicate mine took 24 hours when I did this a few years ago.

[aceonbass]

Turns out all the objects are there, but here's the perplexing thing: the "isRecycled" is set to TRUE. Yes, that explains why they don't come back on an ADUC search on the 2012R2 box, but we only have a Domain & Forest Functional Level of 2008, not 2008 R2! This means we can't have the AD Recycle Bin feature enabled, yet here all our objects are with the isRecycled is true.

[aceonbass]

So it seems we're in a strange limbo situation here. The users have "isRecycled:TRUE" set against them, yet no value for "isDeleted". Accoring the MS documentation this shouldn't really be possible. Additionally, those accounts with isRecycled:True will be set to delete by the 2012R2 server. Luckily, all attributes (such as employeeID) are still present on these objects.

 

These accounts show up in 2008 because they don't recognise/honour the 'isRecycled' attribute. The issue here is that it is a system-only value so cannot be changed in ADSI edit. We found we can clear the flag using LDP.exe after tricking AD into thinking a schema update is happening, but this is on a one-by-one basis, and as we're missing 14,000 accounts, we can't do this manually. We're trying to script using the "System.DirectoryServices.Protocols" but keep running into errors.

 

If anyone has any tips on this, it would be much appreciated!

[minimoo]

ADDS: Deploying the 1st W2K8 R2 or later DC in an existing forest may temporarily halt AD replication to strict mode destination DCs for up to 12 hours seems to imply that isREcycled is set on deleted objects to 1 when the first windows 2008 r2 dc is promoted - which would imply that you can have isRecycled set to true even if before setting the functional level of the domain/forest. Doesn't really help you though.

[aceonbass]

Thanks for the link. The replication wasn't actually an issue because the objects were there on the new 2012R2 DC, and we'd already had a 2008R2 DC in for a while (which went mega fubar - we think it must be related; this is why we replaced it with a 2012R2 box). We ended up just scripting an .ldf file that modified that value, tricked AD into thinking we were starting a schema update and played the LDF file. This fixed it for us and we've had no issues after this.