I think the 6month period comes from the "tombstoneLifetime" attribute
present under this DN. The default is 180 days.
dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, BASEDN
Can this value be reduced and wait for samba to purge the old deleted
objects?
Modifying this value has other implications as per AD docs but I wonder if
it can be changed for a simple directory setup.
-Tushar
>
> ---------- Forwarded message ----------
> From: lp101 <lingpanda101 at gmail.com>
> To: Andrew Bartlett <abartlet at samba.org>
> Cc: samba at lists.samba.org
> Date: Sun, 22 Dec 2013 21:47:48 -0500
> Subject: Re: [Samba] DomainDnsZone Replication Shows 200,000 Objects
> Appreciate the response. You indicated the items will be retained for
> 6 months. Any possibilty of a parameter being introduced to modify this?
>
> -James
>
> On 12/22/2013 4:56 AM, Andrew Bartlett wrote:
>
>> On Fri, 2013-12-20 at 12:44 -0500, lp101 wrote:
>>
>>> During the samba domain join process I see over 200,000+
objects
>>> that need to be replicated. This takes several hours to complete if
at
>>> all. I don't believe this to be correct. I'm currently
running Samba
>>> 4.1.0 on several DC's across a couple sites. Tried to join a
new DC
>>> using Samba4.1.0 as well but it failed with an error code similar
to the
>>> one found here
>>>
>>> https://lists.samba.org/archive/samba/2013-October/176237.html.
>>>
>>> Reverted back to a 4.0.9 build and it completed the join process
>>> without this error. I would like to join another DC but it takes an
>>> excessive amount of time to replicate the DomainDnsZone partition.
I
>>> can't fathom this containing 200,000+ objects. My domain
consist of
>>> approximately 125 users and 150 machines. Thanks for any help.
>>>
>> A flawed fix was introduced and reviewed into our internal DNS server a
>> few months ago, purporting to fix issues with clients not being able to
>> update their DNS records.
>>
>> The fix caused the create of a new deleted record for every DNS
>> transaction, even one that should have had no impact on the database
>> (same IP).
>>
>> The only workaround to avoid creating more is to change from the
>> internal DNS server to the BIND9 DLZ module, but this won't fix the
>> issue with having a database that is drowning in deleted records. We
>> don't have a tool to purge these at this time, and by default they
will
>> be kept for 6 months.
>>
>> We do realise we are going to have to come up with a better fix, but
>> sadly nobody has yet proposed a patch to do this properly. (We should
>> probably at least revert the one that was put in).
>>
>> Sorry,
>>
>> Andrew Bartlett
>>
>>
