lingpanda101 at gmail.com
2016-Sep-23 18:53 UTC
[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0
On 9/22/2016 6:31 PM, Garming Sam wrote:> On 23/09/16 00:59, lingpanda101 at gmail.com wrote: >> For clarification I'll add a few things. >> >> I initially deleted all the NTDS site links for each site and allowed >> the new KCC to create them. However it did not create them I believe >> correctly. By that I mean it defined what appeared to be a bridgehead >> server at each site. So I disabled the new KCC >> 'kccsrv:samba_kcc=false' in my smb.conf and allowed the full mesh to >> be used again. After all site links were recreated. I then switched >> the 'kccsrv:samba_kcc=true' in my smb.conf and that's what prompted >> the following errors above. >> >> To further expand on my Topology, I have 3 sites. I'll call them A,B >> and C. Each site contains 2 DC's. Sites use different subnets and are >> connected via. fiber. Sites B and C should not be replication >> partners. They should only replicate with Site >> A(Default-First-Site-Name). With the new KCC after deleting all the >> NTDS links, Sites B and C Domain Controller #1 becomes the bridgehead >> server for that site. Domain Controller #2 at sites B and C only >> replicates with Domain Controller #1 at it's respective site. So if >> the bridgehead server goes down, Domain Controller #2 at sites B and C >> will no longer receive changes. >> >> The new KCC does prevent sites B and C from replicating with each >> other. That is correct. This isn't a huge issue for me. I can continue >> using the old KCC for now. The full mesh isn't detrimental to my >> network. Don't want to take up too much of your time. Thanks >> >> > The KCC has been my pet project for the last little bit, so I am very > interested in how it functions in general. But as far as I can tell, the > KCC is doing what is expected of it. What should happen, and I say > should, is that if the bridgehead server dies, the bridgehead server > role will transfer to the other DC. There might be a brief period of > time before the KCC re-runs where the sites are disconnected, but in > general, the failovers should be relatively stable. With only a small > number of sites (and DCs), this might be more trouble than it's worth, > like you say. In either case, I appreciate your input. > > > Thanks, > > GarmingI went ahead and enabled the new KCC. I deleted all the automatically generated NTDS links and let Samba create them. I did this through the Microsoft Active Directory Sites and Services tool. I didn't see the option to delete with 'samba-tool drs options --help'. I did run 'samba-tool drs kcc' to force the check and not wait. I see all the automatically generated site links are created as you say they should. I shutdown one of the bridgehead servers in a site (killall samba). In my case it's SOLDC1 in Site B. I ran 'samba-tool drs kcc' on all DC's to see if a new KCC connection would be created on SOLDC2 in site B. It never was. So I restarted SOLDC2 in site B and no connection was ever created. This is all with SOLDC1 in site B still down. This tells me SOLDC2 becomes an island without anyway to replicate. One strange thing is 'samba-tool drs showrepl' begs to differ. root at soldc2:~# samba-tool drs showrepl site-b\SOLDC2 DSA Options: 0x00000001 DSA object GUID: 25055641-49e7-4b3f-a7e3-9d206375306c DSA invocationId: d11890e8-6b90-4e94-aca4-6d7a940f47b5 ==== INBOUND NEIGHBORS === CN=Configuration,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ Fri Sep 23 14:40:18 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:40:18 2016 EDT DC=DomainDnsZones,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ Fri Sep 23 14:42:24 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:42:24 2016 EDT DC=DomainDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ Fri Sep 23 14:42:34 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:42:34 2016 EDT DC=DomainDnsZones,DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ Fri Sep 23 14:42:32 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:42:32 2016 EDT DC=DomainDnsZones,DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ Fri Sep 23 14:41:00 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:41:00 2016 EDT DC=DomainDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ Fri Sep 23 14:40:58 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:40:58 2016 EDT CN=Schema,CN=Configuration,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ Fri Sep 23 14:40:19 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:40:19 2016 EDT DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ Fri Sep 23 14:40:20 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:40:20 2016 EDT DC=ForestDnsZones,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ Fri Sep 23 14:40:18 2016 EDT was successful 0 consecutive failure(s). Last success @ Fri Sep 23 14:40:18 2016 EDT ==== OUTBOUND NEIGHBORS === CN=Configuration,DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Configuration,DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Configuration,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Configuration,DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Configuration,DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=DomainDnsZones,DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Schema,CN=Configuration,DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Schema,CN=Configuration,DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Schema,CN=Configuration,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Schema,CN=Configuration,DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) CN=Schema,CN=Configuration,DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=domain,DC=local site-c\DUNDC2 via RPC DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC1 via RPC DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=domain,DC=local site-b\SOLDC1 via RPC DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=domain,DC=local Default-First-Site-Name\PFDC2 via RPC DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) DC=ForestDnsZones,DC=domain,DC=local site-c\DUNDC1 via RPC DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) ==== KCC CONNECTION OBJECTS === Connection -- Connection name: 7b7ddab7-4377-44f4-9831-8fe7feb55115 Enabled : TRUE Server DNS name : SOLDC1.domain.local Server DN name : CN=NTDS Settings,CN=SOLDC1,CN=Servers,CN=site-b,CN=Sites,CN=Configuration,DC=domain,DC=local TransportType: RPC options: 0x00000001 Warning: No NC replicated for Connection! 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. -- -James
garming at catalyst.net.nz
2016-Sep-24 00:08 UTC
[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0
On 2016-09-24 06:53, lingpanda101 at gmail.com wrote:> On 9/22/2016 6:31 PM, Garming Sam wrote: >> On 23/09/16 00:59, lingpanda101 at gmail.com wrote: >>> For clarification I'll add a few things. >>> >>> I initially deleted all the NTDS site links for each site and allowed >>> the new KCC to create them. However it did not create them I believe >>> correctly. By that I mean it defined what appeared to be a bridgehead >>> server at each site. So I disabled the new KCC >>> 'kccsrv:samba_kcc=false' in my smb.conf and allowed the full mesh to >>> be used again. After all site links were recreated. I then switched >>> the 'kccsrv:samba_kcc=true' in my smb.conf and that's what prompted >>> the following errors above. >>> >>> To further expand on my Topology, I have 3 sites. I'll call them A,B >>> and C. Each site contains 2 DC's. Sites use different subnets and are >>> connected via. fiber. Sites B and C should not be replication >>> partners. They should only replicate with Site >>> A(Default-First-Site-Name). With the new KCC after deleting all the >>> NTDS links, Sites B and C Domain Controller #1 becomes the bridgehead >>> server for that site. Domain Controller #2 at sites B and C only >>> replicates with Domain Controller #1 at it's respective site. So if >>> the bridgehead server goes down, Domain Controller #2 at sites B and >>> C >>> will no longer receive changes. >>> >>> The new KCC does prevent sites B and C from replicating with each >>> other. That is correct. This isn't a huge issue for me. I can >>> continue >>> using the old KCC for now. The full mesh isn't detrimental to my >>> network. Don't want to take up too much of your time. Thanks >>> >>> >> The KCC has been my pet project for the last little bit, so I am very >> interested in how it functions in general. But as far as I can tell, >> the >> KCC is doing what is expected of it. What should happen, and I say >> should, is that if the bridgehead server dies, the bridgehead server >> role will transfer to the other DC. There might be a brief period of >> time before the KCC re-runs where the sites are disconnected, but in >> general, the failovers should be relatively stable. With only a small >> number of sites (and DCs), this might be more trouble than it's worth, >> like you say. In either case, I appreciate your input. >> >> >> Thanks, >> >> Garming > > I went ahead and enabled the new KCC. I deleted all the automatically > generated NTDS links and let Samba create them. I did this through the > Microsoft Active Directory Sites and Services tool. I didn't see the > option to delete with 'samba-tool drs options --help'. I did run > 'samba-tool drs kcc' to force the check and not wait. I see all the > automatically generated site links are created as you say they should. > > I shutdown one of the bridgehead servers in a site (killall samba). In > my case it's SOLDC1 in Site B. I ran 'samba-tool drs kcc' on all DC's > to see if a new KCC connection would be created on SOLDC2 in site B. > It never was. So I restarted SOLDC2 in site B and no connection was > ever created. This is all with SOLDC1 in site B still down. This tells > me SOLDC2 becomes an island without anyway to replicate. > > One strange thing is 'samba-tool drs showrepl' begs to differ. > > root at soldc2:~# samba-tool drs showrepl > site-b\SOLDC2 > DSA Options: 0x00000001 > DSA object GUID: 25055641-49e7-4b3f-a7e3-9d206375306c > DSA invocationId: d11890e8-6b90-4e94-aca4-6d7a940f47b5 > > ==== INBOUND NEIGHBORS ===> > CN=Configuration,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ Fri Sep 23 14:40:18 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:40:18 2016 EDT > > DC=DomainDnsZones,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ Fri Sep 23 14:42:24 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:42:24 2016 EDT > > DC=DomainDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ Fri Sep 23 14:42:34 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:42:34 2016 EDT > > DC=DomainDnsZones,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ Fri Sep 23 14:42:32 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:42:32 2016 EDT > > DC=DomainDnsZones,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ Fri Sep 23 14:41:00 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:41:00 2016 EDT > > DC=DomainDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ Fri Sep 23 14:40:58 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:40:58 2016 EDT > > CN=Schema,CN=Configuration,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ Fri Sep 23 14:40:19 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:40:19 2016 EDT > > DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ Fri Sep 23 14:40:20 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:40:20 2016 EDT > > DC=ForestDnsZones,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ Fri Sep 23 14:40:18 2016 EDT was > successful > 0 consecutive failure(s). > Last success @ Fri Sep 23 14:40:18 2016 EDT > > ==== OUTBOUND NEIGHBORS ===> > CN=Configuration,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Configuration,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Configuration,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Configuration,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Configuration,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=DomainDnsZones,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=DomainDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=DomainDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=DomainDnsZones,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=DomainDnsZones,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Schema,CN=Configuration,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Schema,CN=Configuration,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Schema,CN=Configuration,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Schema,CN=Configuration,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > CN=Schema,CN=Configuration,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > ==== KCC CONNECTION OBJECTS ===> > Connection -- > Connection name: 7b7ddab7-4377-44f4-9831-8fe7feb55115 > Enabled : TRUE > Server DNS name : SOLDC1.domain.local > Server DN name : CN=NTDS > Settings,CN=SOLDC1,CN=Servers,CN=site-b,CN=Sites,CN=Configuration,DC=domain,DC=local > TransportType: RPC > options: 0x00000001 > Warning: No NC replicated for Connection! > > 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. 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
Denis Cardon
2016-Sep-24 11:32 UTC
[Samba] updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)
Hi LingPanda101, ....> > DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-c\DUNDC2 via RPC > DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC1 via RPC > DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-b\SOLDC1 via RPC > DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > Default-First-Site-Name\PFDC2 via RPC > DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > DC=ForestDnsZones,DC=domain,DC=local > site-c\DUNDC1 via RPC > DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 > Last attempt @ NTTIME(0) was successful > 0 consecutive failure(s). > Last success @ NTTIME(0) > > ==== KCC CONNECTION OBJECTS ===> > Connection -- > Connection name: 7b7ddab7-4377-44f4-9831-8fe7feb55115 > Enabled : TRUE > Server DNS name : SOLDC1.domain.local > Server DN name : CN=NTDS > Settings,CN=SOLDC1,CN=Servers,CN=site-b,CN=Sites,CN=Configuration,DC=domain,DC=local > > TransportType: RPC > options: 0x00000001 > Warning: No NC replicated for Connection! > > 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.the job of the samba_kcc script is to create the ntdsConnection objects. Afterward the repsFrom/repsTo attribute are created in accordance with the ntdsConnection objects (you can force the creation using samba-tool drs replicate although). You can check that the process is asynchronous when you join a new DC, the INBOUND and OUTBOUND entries are coming later on after the ntdsConnection object has been created. You can find repsFrom/repsTo attributes at on the root ldap entries of each of the five AD partitions. Those entries correspond to the INBOUND and OUTBOUND display in the samba-tool drs showrepl command. However there is currently no standard way to delete the leftover of repsfrom/repsto, others than deleting the repsFrom/repsTo attribute manually or through scripting (python-ldb is your friend here). I had a discussion with Garming a while ago about this issue, and it was not clear what process was responsible to remove spurious/leftover repsfrom/repsto attribute. With the old kcc, it was not such an issue because it was full meshed, however with the new KCC, it would indeed be good to have some more tooling for drs maintenance and monitoring. By the way, KCC computation algorithm specifications from Microsoft are kind of mind boggling, so there might need some more tweaking, but thanks to Garming it is has done the job for us since 4.3.0 for almost one year. Cheers, Denis> >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr
Denis Cardon
2016-Sep-25 22:26 UTC
[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0
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 >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr
lingpanda101 at gmail.com
2016-Sep-26 14:34 UTC
[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0
On 9/23/2016 8:08 PM, garming at catalyst.net.nz wrote:> >> >> 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. > > 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, > > GarmingGarming, What is the command and syntax to query Samba for the interSiteTopologyFailover variable? If I use ADSI edit to view the variable it displays as '<not set>'. What's also odd is the interSiteTopologyGenerator variable. My understanding is the ISTG should only be defined on one DC in each site. Which it is but it's the DC that is defined that's odd. In my case for 'Site-B', it's SOLDC2. That would explain why shutting SOLDC1 didn't prompt the KCC to create new NTDS connections. SOLDC1 is the DC that has automatically generated connections to the 'Default-First-Site-Name'. SOLDC2 only has KCC connections to SOLDC1. Isn't Samba defining the incorrect server as being the ISTG bridgehead server? This is the case for my other two sites as well. Thanks. -- -James
lingpanda101 at gmail.com
2016-Sep-26 14:54 UTC
[Samba] replPropertyMetaData & KCC issues after updating to Samba 4.5.0
On 9/23/2016 8:08 PM, garming at catalyst.net.nz wrote:> On 2016-09-24 06:53, lingpanda101 at gmail.com wrote: >> On 9/22/2016 6:31 PM, Garming Sam wrote: >>> On 23/09/16 00:59, lingpanda101 at gmail.com wrote: >>>> For clarification I'll add a few things. >>>> >>>> I initially deleted all the NTDS site links for each site and allowed >>>> the new KCC to create them. However it did not create them I believe >>>> correctly. By that I mean it defined what appeared to be a bridgehead >>>> server at each site. So I disabled the new KCC >>>> 'kccsrv:samba_kcc=false' in my smb.conf and allowed the full mesh to >>>> be used again. After all site links were recreated. I then switched >>>> the 'kccsrv:samba_kcc=true' in my smb.conf and that's what prompted >>>> the following errors above. >>>> >>>> To further expand on my Topology, I have 3 sites. I'll call them A,B >>>> and C. Each site contains 2 DC's. Sites use different subnets and are >>>> connected via. fiber. Sites B and C should not be replication >>>> partners. They should only replicate with Site >>>> A(Default-First-Site-Name). With the new KCC after deleting all the >>>> NTDS links, Sites B and C Domain Controller #1 becomes the bridgehead >>>> server for that site. Domain Controller #2 at sites B and C only >>>> replicates with Domain Controller #1 at it's respective site. So if >>>> the bridgehead server goes down, Domain Controller #2 at sites B and C >>>> will no longer receive changes. >>>> >>>> The new KCC does prevent sites B and C from replicating with each >>>> other. That is correct. This isn't a huge issue for me. I can continue >>>> using the old KCC for now. The full mesh isn't detrimental to my >>>> network. Don't want to take up too much of your time. Thanks >>>> >>>> >>> The KCC has been my pet project for the last little bit, so I am very >>> interested in how it functions in general. But as far as I can tell, >>> the >>> KCC is doing what is expected of it. What should happen, and I say >>> should, is that if the bridgehead server dies, the bridgehead server >>> role will transfer to the other DC. There might be a brief period of >>> time before the KCC re-runs where the sites are disconnected, but in >>> general, the failovers should be relatively stable. With only a small >>> number of sites (and DCs), this might be more trouble than it's worth, >>> like you say. In either case, I appreciate your input. >>> >>> >>> Thanks, >>> >>> Garming >> >> I went ahead and enabled the new KCC. I deleted all the automatically >> generated NTDS links and let Samba create them. I did this through the >> Microsoft Active Directory Sites and Services tool. I didn't see the >> option to delete with 'samba-tool drs options --help'. I did run >> 'samba-tool drs kcc' to force the check and not wait. I see all the >> automatically generated site links are created as you say they should. >> >> I shutdown one of the bridgehead servers in a site (killall samba). In >> my case it's SOLDC1 in Site B. I ran 'samba-tool drs kcc' on all DC's >> to see if a new KCC connection would be created on SOLDC2 in site B. >> It never was. So I restarted SOLDC2 in site B and no connection was >> ever created. This is all with SOLDC1 in site B still down. This tells >> me SOLDC2 becomes an island without anyway to replicate. >> >> One strange thing is 'samba-tool drs showrepl' begs to differ. >> >> root at soldc2:~# samba-tool drs showrepl >> site-b\SOLDC2 >> DSA Options: 0x00000001 >> DSA object GUID: 25055641-49e7-4b3f-a7e3-9d206375306c >> DSA invocationId: d11890e8-6b90-4e94-aca4-6d7a940f47b5 >> >> ==== INBOUND NEIGHBORS ===>> >> CN=Configuration,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ Fri Sep 23 14:40:18 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:40:18 2016 EDT >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ Fri Sep 23 14:42:24 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:42:24 2016 EDT >> >> DC=DomainDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ Fri Sep 23 14:42:34 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:42:34 2016 EDT >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ Fri Sep 23 14:42:32 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:42:32 2016 EDT >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ Fri Sep 23 14:41:00 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:41:00 2016 EDT >> >> DC=DomainDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ Fri Sep 23 14:40:58 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:40:58 2016 EDT >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ Fri Sep 23 14:40:19 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:40:19 2016 EDT >> >> DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ Fri Sep 23 14:40:20 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:40:20 2016 EDT >> >> DC=ForestDnsZones,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ Fri Sep 23 14:40:18 2016 EDT was >> successful >> 0 consecutive failure(s). >> Last success @ Fri Sep 23 14:40:18 2016 EDT >> >> ==== OUTBOUND NEIGHBORS ===>> >> CN=Configuration,DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Configuration,DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Configuration,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Configuration,DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Configuration,DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=DomainDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=DomainDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=DomainDnsZones,DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> CN=Schema,CN=Configuration,DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=ForestDnsZones,DC=domain,DC=local >> site-c\DUNDC2 via RPC >> DSA object GUID: 3c08db42-9416-40df-99ad-6d0c0ec554a6 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=ForestDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC1 via RPC >> DSA object GUID: acc2392f-9567-450f-bcb3-4fb1034b8753 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=ForestDnsZones,DC=domain,DC=local >> site-b\SOLDC1 via RPC >> DSA object GUID: 55e069f5-4f47-415b-8fa4-a398948235aa >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=ForestDnsZones,DC=domain,DC=local >> Default-First-Site-Name\PFDC2 via RPC >> DSA object GUID: e6284e90-f964-4643-b6a6-5baafdd7ba36 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> DC=ForestDnsZones,DC=domain,DC=local >> site-c\DUNDC1 via RPC >> DSA object GUID: a216e718-488f-4821-8d9c-a399e6789222 >> Last attempt @ NTTIME(0) was successful >> 0 consecutive failure(s). >> Last success @ NTTIME(0) >> >> ==== KCC CONNECTION OBJECTS ===>> >> Connection -- >> Connection name: 7b7ddab7-4377-44f4-9831-8fe7feb55115 >> Enabled : TRUE >> Server DNS name : SOLDC1.domain.local >> Server DN name : CN=NTDS >> Settings,CN=SOLDC1,CN=Servers,CN=site-b,CN=Sites,CN=Configuration,DC=domain,DC=local >> >> TransportType: RPC >> options: 0x00000001 >> Warning: No NC replicated for Connection! >> >> 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. > > 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, > > GarmingI should point out for reference how I was trying to query the interSiteTopologyFailover variable. ldbsearch -H usr/local/samba/private/sam.ldb '(&(objectclass=person)(name=Guest))' name intersiteTopologyFailover # record 1 dn: CN=Guest,CN=Users,DC=domain,DC=local name: Guest # Referral ref: ldap://domain.local/CN=Configuration,DC=domain,DC=local # Referral ref: ldap://domain.local/DC=DomainDnsZones,DC=domain,DC=local # Referral ref: ldap://domain.local/DC=ForestDnsZones,DC=domain,DC=local # returned 4 records # 1 entries # 3 referrals Is this correct? -- -James
lingpanda101 at gmail.com
2016-Sep-26 14:57 UTC
[Samba] updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)
On 9/24/2016 7:32 AM, Denis Cardon wrote:> > the job of the samba_kcc script is to create the ntdsConnection > objects. Afterward the repsFrom/repsTo attribute are created in > accordance with the ntdsConnection objects (you can force the creation > using samba-tool drs replicate although). You can check that the > process is asynchronous when you join a new DC, the INBOUND and > OUTBOUND entries are coming later on after the ntdsConnection object > has been created. > > You can find repsFrom/repsTo attributes at on the root ldap entries of > each of the five AD partitions. Those entries correspond to the > INBOUND and OUTBOUND display in the samba-tool drs showrepl command. > > However there is currently no standard way to delete the leftover of > repsfrom/repsto, others than deleting the repsFrom/repsTo attribute > manually or through scripting (python-ldb is your friend here). > > I had a discussion with Garming a while ago about this issue, and it > was not clear what process was responsible to remove spurious/leftover > repsfrom/repsto attribute. With the old kcc, it was not such an issue > because it was full meshed, however with the new KCC, it would indeed > be good to have some more tooling for drs maintenance and monitoring. > > By the way, KCC computation algorithm specifications from Microsoft > are kind of mind boggling, so there might need some more tweaking, but > thanks to Garming it is has done the job for us since 4.3.0 for almost > one year. > > Cheers, > > Denis > > >> >> >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? -- -James
Seemingly Similar Threads
- replPropertyMetaData & KCC issues after updating to Samba 4.5.0
- replPropertyMetaData & KCC issues after updating to Samba 4.5.0
- updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)
- replPropertyMetaData & KCC issues after updating to Samba 4.5.0
- updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)