[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0

[garming at catalyst.net.nz]

Hi Dennis,

There are some improvements made in 4.5.0 for the KCC in regards to 
removing repsFrom/To. RepsTo should no longer push updates to dead DCs 
(as well as repsFrom) and there was some changes to fix some issues with 
DomainDns and ForestDns partitions (where the NCReplicaLocations 
attribute was not set).

Cheers,

Garming

On 2016-09-25 15:26, Denis Cardon wrote:
> Hi Garming,
> 
> ...
> 
>>> I have what appears to still be a full mesh replication. Shouldn't 
>>> the
>>> outbound and inbound neighbors be reflective of the KCC connection
>>> objects? I would expect to find only inbound and outbound connections
>>> for SOLDC1. Maybe I'm completely misinterpreting the intended
>>> behavior.
>> 
>> There's likely at least some stale entries (repsFrom). The KCC builds
>> the inbound connections for each DC. Then as a separate step 
>> translates
>> the connections to replication links. The outbound links are mostly 
>> the
>> other DCs problem (likely an old repsFrom pulling from SOLDC1). I've
>> taken quite a few steps to rid the DCs of as many old repsFrom entries
>> as possible from within the KCC, but based on time delays and use of 
>> the
>> old KCC, this may not be enough in its current state to be equivalent 
>> to
>> a fresh domain.
> 
> About the cleanup of repsFrom/repsTo, is the cleanup code included in
> 4.4.5 or only in 4.5? I have not yet found time to test that new
> version, but at least in 4.4.5, I still have the behavior where
> leftover repsFrom/repsTo are not automatically deleted. I hope to find
> time to test 4.5 next week.
> 
> Cheers,
> 
> Denis
> 
> PS : sorry for my parallel response to that thread, I didn't see your
> mail before hitting the send button.
> 
>> 
>> I've taken another look and it's plausible that the failover for 
>> inbound
>> connections won't occur for 2 hours thanks to the default of the
>> interSiteTopologyFailover variable on the site objects. I would be
>> interested as to result if you set the variable (which I think is in
>> minutes) to something much lower.
>> 
>> This area is definitely not simple. And has a lot of room to improve
>> (One bug I see here is 'Last attempt @ NTTIME(0) was successful' which
>> has an unmerged fix to get the right time I believe). But it is a vast
>> improvement on the old code, especially at scale.
>> 
>> 
>> Cheers,
>> 
>> Garming
>>