[Samba] updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)

[garming at catalyst.net.nz]

I have also managed to spot a hard-coded 2 hour fallback period in our 
code (which may or may not be configurable in Windows). So this period 
of time seems to generally be the default expectation of how long you 
might expect to be able to take the DC offline without interfering with 
the topologies (which is probably what you might want in the case of 
brief service interruption and not suddenly triggering replication to 
other partners). We may want to add a configuration option to Samba 
possibly, but this requires some more thought and from some the feedback 
I already have, some are surprised we were this fault tolerant to begin 
with.

Cheers,

Garming

On 2016-09-27 22:25, garming at catalyst.net.nz wrote:
>> 
>> Wasn't aware of this. Thank you for the info. If I was to delete the
>> incorrect respsFrom/repsTo attributes, wouldn't the KCC just
>> regenerate them over time once the KCC check and ISTG check kicked in?
> 
> As long as the topology doesn't change or DCs which are not
> bridgeheads do not go offline, there should be basically zero
> additional reps over time. How often they build up over time is an
> open question (when DCs do go offline), I can't test every setup and
> I'm sure there are edge cases. However if there are these additional
> links for when you have spuriously unreliable DCs, they work just as
> well as a fallback.
> 
> The interSiteTopologyFailover attribute seems to be on the
> NTDS-Site-Settings class. By default it probably isn't defined, but
> the internal default value in both Samba and Windows is 2 hours.
> 
> The ITSG is not the same as the bridgehead server. The ITSG is a
> single DC in the site which coordinates all the DCs and picks
> bridgehead servers in the site to talk to other sites (at some DC
> bridgehead arbitrarily chosen on the other end). The reason I ask who
> the ITSG was is because if the ITSG is dead, it is reasonable to
> expect that there is no current coordinator who is site-aware, and so
> no fallback has occurred yet.
> 
> Cheers,
> 
> Garming