List Archives

This forum is an archive of all posts to our mailing list over the past few years. The forum is set read only therefore to contribute you will need to join our list community. See more info about this here.

When subscribed to the list you should use your standard email client to send your posts to ActiveDir@mail.activedir.org.

List Archives

Unanswered Active Topics

Forums Search

Forums >ActiveDir Mail List Archive >List Archives

Subject: [ActiveDir] Attribute Replication Conflict

Prev Next

You are not authorized to post a reply.

Author

Messages

rmscheck

Posts:290

06/29/2012 2:19 AM
I'm having a problem figuring out what is the expected result when an SPN tied to a SQL cluster service account. I am finding that sometimes the attempted SPN write doesn't get replicated. What is happening, when the SQL cluster is failed over, the cluster owner unregisters the SPN, then the new owner reregisters the SPN when it starts up SQL. Sometimes the unregister/register process can occur on different DCs. I guess I'm trying to find out why sometimes I will have the SPN registered and sometimes it wont even though the SQL logs will always say SPN registered successfully. I am thinking this due to some conflict resolution on the attribute since the register/unregister process can be seconds apart. Here's what I think I know... Scenario DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. 1. the modification that has the higher versionID will win, OR if same 2. the modification with the later timestamp will win, OR if same 3. the modification from the DC with the lower GUID will win. However, I'm still puzzled as, in the scenario, above, I ended up with no SPN. I would have thought because the write to DC2 was later than DC1, it should have won, assuming the versionID was the same. Both should have started with the same number if no change to that attribute happened prior, right? Thus, the later timestamp rule should have given it to DC2's value, but it didnt. What do you think happened there? Replication on both DCs are fine so what should I expect? -Rand List info: http://www.activedir.org/List.aspx

Tony

Posts:172

06/29/2012 2:31 AM
Hi Rand You shouldn't have ended up with no SPN. I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. Tony ________________________________________ From: activedir-owner@xxxxxxxxxxxxxxxx [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar [rmscheck08@xxxxxxxxxxxxxxxx] Sent: Friday, 29 June 2012 1:16 p.m. To: ActiveDir@xxxxxxxxxxxxxxxx Subject: [ActiveDir] Attribute Replication Conflict I'm having a problem figuring out what is the expected result when an SPN tied to a SQL cluster service account. I am finding that sometimes the attempted SPN write doesn't get replicated. What is happening, when the SQL cluster is failed over, the cluster owner unregisters the SPN, then the new owner reregisters the SPN when it starts up SQL. Sometimes the unregister/register process can occur on different DCs. I guess I'm trying to find out why sometimes I will have the SPN registered and sometimes it wont even though the SQL logs will always say SPN registered successfully. I am thinking this due to some conflict resolution on the attribute since the register/unregister process can be seconds apart. Here's what I think I know... Scenario DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. 1. the modification that has the higher versionID will win, OR if same 2. the modification with the later timestamp will win, OR if same 3. the modification from the DC with the lower GUID will win. However, I'm still puzzled as, in the scenario, above, I ended up with no SPN. I would have thought because the write to DC2 was later than DC1, it should have won, assuming the versionID was the same. Both should have started with the same number if no change to that attribute happened prior, right? Thus, the later timestamp rule should have given it to DC2's value, but it didnt. What do you think happened there? Replication on both DCs are fine so what should I expect? -Rand List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

06/29/2012 3:41 AM
Yea, thats what I figured.. even with auditing (Quest) it logged the process properly, the unreg from node one on DC1 then 18 secs later the registration on DC2 from node 2, but for some reason, it didnt show on DC2 and thus the SPN is not there.. no errors on the supposed DC either. Very odd. I will have to pull some objmeta to see more, but something doesnt compute. On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: > Hi Rand > > You shouldn't have ended up with no SPN. > > I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. > > Tony > > ________________________________________ > From: activedir-owner@xxxxxxxxxxxxxxxx [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar [rmscheck08@xxxxxxxxxxxxxxxx] > Sent: Friday, 29 June 2012 1:16 p.m. > To: ActiveDir@xxxxxxxxxxxxxxxx > Subject: [ActiveDir] Attribute Replication Conflict > > I'm having a problem figuring out what is the expected result when an > SPN tied to a SQL cluster service account. I am finding that > sometimes the attempted SPN write doesn't get replicated. What is > happening, when the SQL cluster is failed over, the cluster owner > unregisters the SPN, then the new owner reregisters the SPN when it > starts up SQL. Sometimes the unregister/register process can occur > on different DCs. I guess I'm trying to find out why sometimes I > will have the SPN registered and sometimes it wont even though the SQL > logs will always say SPN registered successfully. I am thinking > this due to some conflict resolution on the attribute since the > register/unregister process can be seconds apart. > > Here's what I think I know... > > Scenario > DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. > > 1. the modification that has the higher versionID will win, OR if same > 2. the modification with the later timestamp will win, OR if same > 3. the modification from the DC with the lower GUID will win. > > However, I'm still puzzled as, in the scenario, above, I ended up with > no SPN. I would have thought because the write to DC2 was later than > DC1, it should have won, assuming the versionID was the same. Both > should have started with the same number if no change to that > attribute happened prior, right? Thus, the later timestamp rule > should have given it to DC2's value, but it didnt. > > What do you think happened there? Replication on both DCs are fine > so what should I expect? > > -Rand > > List info: http://www.activedir.org/List.aspx > List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

06/30/2012 2:55 AM
I just dont get it... it continues to puzzle me. What should I be looking for in the objmeta? I've tracked the versionID and it stays the same.. What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC hasnt replicated within 20 secs.. Does it still attempt a write? On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > Yea, thats what I figured.. even with auditing (Quest) it logged the > process properly, the unreg from node one on DC1 then 18 secs later > the registration on DC2 from node 2, but for some reason, it didnt > show on DC2 and thus the SPN is not there.. no errors on the supposed > DC either. Very odd. I will have to pull some objmeta to see more, > but something doesnt compute. > > On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >> Hi Rand >> >> You shouldn't have ended up with no SPN. >> >> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >> >> Tony >> >> ________________________________________ >> From: activedir-owner@xxxxxxxxxxxxxxxx [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar [rmscheck08@xxxxxxxxxxxxxxxx] >> Sent: Friday, 29 June 2012 1:16 p.m. >> To: ActiveDir@xxxxxxxxxxxxxxxx >> Subject: [ActiveDir] Attribute Replication Conflict >> >> I'm having a problem figuring out what is the expected result when an >> SPN tied to a SQL cluster service account. I am finding that >> sometimes the attempted SPN write doesn't get replicated. What is >> happening, when the SQL cluster is failed over, the cluster owner >> unregisters the SPN, then the new owner reregisters the SPN when it >> starts up SQL. Sometimes the unregister/register process can occur >> on different DCs. I guess I'm trying to find out why sometimes I >> will have the SPN registered and sometimes it wont even though the SQL >> logs will always say SPN registered successfully. I am thinking >> this due to some conflict resolution on the attribute since the >> register/unregister process can be seconds apart. >> >> Here's what I think I know... >> >> Scenario >> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >> >> 1. the modification that has the higher versionID will win, OR if same >> 2. the modification with the later timestamp will win, OR if same >> 3. the modification from the DC with the lower GUID will win. >> >> However, I'm still puzzled as, in the scenario, above, I ended up with >> no SPN. I would have thought because the write to DC2 was later than >> DC1, it should have won, assuming the versionID was the same. Both >> should have started with the same number if no change to that >> attribute happened prior, right? Thus, the later timestamp rule >> should have given it to DC2's value, but it didnt. >> >> What do you think happened there? Replication on both DCs are fine >> so what should I expect? >> >> -Rand >> >> List info: http://www.activedir.org/List.aspx >> List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

bdesmond

Posts:1044

06/30/2012 3:29 AM
If there is zero change then I don't expect the version number to increment. Thanks, Brian Desmond brian@xxxxxxxxxxxxxxxx w - 312.625.1438 \| c - 312.731.3132 -----Original Message----- From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar Sent: Friday, June 29, 2012 8:55 PM To: activedir@xxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Attribute Replication Conflict I just dont get it... it continues to puzzle me. What should I be looking for in the objmeta? I've tracked the versionID and it stays the same.. What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC hasnt replicated within 20 secs.. Does it still attempt a write? On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > Yea, thats what I figured.. even with auditing (Quest) it logged the > process properly, the unreg from node one on DC1 then 18 secs later > the registration on DC2 from node 2, but for some reason, it didnt > show on DC2 and thus the SPN is not there.. no errors on the supposed > DC either. Very odd. I will have to pull some objmeta to see more, > but something doesnt compute. > > On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >> Hi Rand >> >> You shouldn't have ended up with no SPN. >> >> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >> >> Tony >> >> ________________________________________ >> From: activedir-owner@xxxxxxxxxxxxxxxx >> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >> [rmscheck08@xxxxxxxxxxxxxxxx] >> Sent: Friday, 29 June 2012 1:16 p.m. >> To: ActiveDir@xxxxxxxxxxxxxxxx >> Subject: [ActiveDir] Attribute Replication Conflict >> >> I'm having a problem figuring out what is the expected result when an >> SPN tied to a SQL cluster service account. I am finding that >> sometimes the attempted SPN write doesn't get replicated. What is >> happening, when the SQL cluster is failed over, the cluster owner >> unregisters the SPN, then the new owner reregisters the SPN when it >> starts up SQL. Sometimes the unregister/register process can occur >> on different DCs. I guess I'm trying to find out why sometimes I >> will have the SPN registered and sometimes it wont even though the >> SQL logs will always say SPN registered successfully. I am >> thinking this due to some conflict resolution on the attribute since >> the register/unregister process can be seconds apart. >> >> Here's what I think I know... >> >> Scenario >> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >> >> 1. the modification that has the higher versionID will win, OR if >> same 2. the modification with the later timestamp will win, OR if >> same 3. the modification from the DC with the lower GUID will win. >> >> However, I'm still puzzled as, in the scenario, above, I ended up >> with no SPN. I would have thought because the write to DC2 was >> later than DC1, it should have won, assuming the versionID was the >> same. Both should have started with the same number if no change to >> that attribute happened prior, right? Thus, the later timestamp rule >> should have given it to DC2's value, but it didnt. >> >> What do you think happened there? Replication on both DCs are fine >> so what should I expect? >> >> -Rand >> >> List info: http://www.activedir.org/List.aspx >> List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

06/30/2012 2:09 PM
If the SPN value is already present on the 2nd DC, since the change of unregister hasnt replicated to it yet, will it still write or will it do nothing? Then in 25 secs, the unregistration gets replicated to DC2, thus no SPN at the end of it all? On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx> wrote: > If there is zero change then I don't expect the version number to increment. > > Thanks, > Brian Desmond > brian@xxxxxxxxxxxxxxxx > > w - 312.625.1438 \| c - 312.731.3132 > > -----Original Message----- > From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar > Sent: Friday, June 29, 2012 8:55 PM > To: activedir@xxxxxxxxxxxxxxxx > Subject: Re: [ActiveDir] Attribute Replication Conflict > > I just dont get it... it continues to puzzle me. What should I be > looking for in the objmeta? I've tracked the versionID and it > stays the same.. > > What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC > hasnt replicated within 20 secs.. Does it still attempt a write? > > > > On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >> Yea, thats what I figured.. even with auditing (Quest) it logged the >> process properly, the unreg from node one on DC1 then 18 secs later >> the registration on DC2 from node 2, but for some reason, it didnt >> show on DC2 and thus the SPN is not there.. no errors on the supposed >> DC either. Very odd. I will have to pull some objmeta to see more, >> but something doesnt compute. >> >> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >>> Hi Rand >>> >>> You shouldn't have ended up with no SPN. >>> >>> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >>> >>> Tony >>> >>> ________________________________________ >>> From: activedir-owner@xxxxxxxxxxxxxxxx >>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>> [rmscheck08@xxxxxxxxxxxxxxxx] >>> Sent: Friday, 29 June 2012 1:16 p.m. >>> To: ActiveDir@xxxxxxxxxxxxxxxx >>> Subject: [ActiveDir] Attribute Replication Conflict >>> >>> I'm having a problem figuring out what is the expected result when an >>> SPN tied to a SQL cluster service account. I am finding that >>> sometimes the attempted SPN write doesn't get replicated. What is >>> happening, when the SQL cluster is failed over, the cluster owner >>> unregisters the SPN, then the new owner reregisters the SPN when it >>> starts up SQL. Sometimes the unregister/register process can occur >>> on different DCs. I guess I'm trying to find out why sometimes I >>> will have the SPN registered and sometimes it wont even though the >>> SQL logs will always say SPN registered successfully. I am >>> thinking this due to some conflict resolution on the attribute since >>> the register/unregister process can be seconds apart. >>> >>> Here's what I think I know... >>> >>> Scenario >>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >>> >>> 1. the modification that has the higher versionID will win, OR if >>> same 2. the modification with the later timestamp will win, OR if >>> same 3. the modification from the DC with the lower GUID will win. >>> >>> However, I'm still puzzled as, in the scenario, above, I ended up >>> with no SPN. I would have thought because the write to DC2 was >>> later than DC1, it should have won, assuming the versionID was the >>> same. Both should have started with the same number if no change to >>> that attribute happened prior, right? Thus, the later timestamp rule >>> should have given it to DC2's value, but it didnt. >>> >>> What do you think happened there? Replication on both DCs are fine >>> so what should I expect? >>> >>> -Rand >>> >>> List info: http://www.activedir.org/List.aspx >>> List info: http://www.activedir.org/List.aspx > > List info: http://www.activedir.org/List.aspx > > > > List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

06/30/2012 9:51 PM
More info... from what I've seen watching the unreg, reg process.. I would expect to see the version ID increment by two wouldnt I? +1 for the unreg on DC1, and +1 for the reg on DC2? Well I'm seeing the version only incrementing by 1. And the failover time has been as fast as 10 seconds, which means the spn unreg/registration is occurring in less than 10 seconds apart from 2 different DCs Any other ideas? On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > If the SPN value is already present on the 2nd DC, since the change of > unregister hasnt replicated to it yet, will it still write or will it > do nothing? Then in 25 secs, the unregistration gets replicated to > DC2, thus no SPN at the end of it all? > > On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx> wrote: >> If there is zero change then I don't expect the version number to increment. >> >> Thanks, >> Brian Desmond >> brian@xxxxxxxxxxxxxxxx >> >> w - 312.625.1438 \| c - 312.731.3132 >> >> -----Original Message----- >> From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >> Sent: Friday, June 29, 2012 8:55 PM >> To: activedir@xxxxxxxxxxxxxxxx >> Subject: Re: [ActiveDir] Attribute Replication Conflict >> >> I just dont get it... it continues to puzzle me. What should I be >> looking for in the objmeta? I've tracked the versionID and it >> stays the same.. >> >> What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC >> hasnt replicated within 20 secs.. Does it still attempt a write? >> >> >> >> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >>> Yea, thats what I figured.. even with auditing (Quest) it logged the >>> process properly, the unreg from node one on DC1 then 18 secs later >>> the registration on DC2 from node 2, but for some reason, it didnt >>> show on DC2 and thus the SPN is not there.. no errors on the supposed >>> DC either. Very odd. I will have to pull some objmeta to see more, >>> but something doesnt compute. >>> >>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >>>> Hi Rand >>>> >>>> You shouldn't have ended up with no SPN. >>>> >>>> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >>>> >>>> Tony >>>> >>>> ________________________________________ >>>> From: activedir-owner@xxxxxxxxxxxxxxxx >>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>>> [rmscheck08@xxxxxxxxxxxxxxxx] >>>> Sent: Friday, 29 June 2012 1:16 p.m. >>>> To: ActiveDir@xxxxxxxxxxxxxxxx >>>> Subject: [ActiveDir] Attribute Replication Conflict >>>> >>>> I'm having a problem figuring out what is the expected result when an >>>> SPN tied to a SQL cluster service account. I am finding that >>>> sometimes the attempted SPN write doesn't get replicated. What is >>>> happening, when the SQL cluster is failed over, the cluster owner >>>> unregisters the SPN, then the new owner reregisters the SPN when it >>>> starts up SQL. Sometimes the unregister/register process can occur >>>> on different DCs. I guess I'm trying to find out why sometimes I >>>> will have the SPN registered and sometimes it wont even though the >>>> SQL logs will always say SPN registered successfully. I am >>>> thinking this due to some conflict resolution on the attribute since >>>> the register/unregister process can be seconds apart. >>>> >>>> Here's what I think I know... >>>> >>>> Scenario >>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >>>> >>>> 1. the modification that has the higher versionID will win, OR if >>>> same 2. the modification with the later timestamp will win, OR if >>>> same 3. the modification from the DC with the lower GUID will win. >>>> >>>> However, I'm still puzzled as, in the scenario, above, I ended up >>>> with no SPN. I would have thought because the write to DC2 was >>>> later than DC1, it should have won, assuming the versionID was the >>>> same. Both should have started with the same number if no change to >>>> that attribute happened prior, right? Thus, the later timestamp rule >>>> should have given it to DC2's value, but it didnt. >>>> >>>> What do you think happened there? Replication on both DCs are fine >>>> so what should I expect? >>>> >>>> -Rand >>>> >>>> List info: http://www.activedir.org/List.aspx >>>> List info: http://www.activedir.org/List.aspx >> >> List info: http://www.activedir.org/List.aspx >> >> >> >> List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

07/08/2012 2:42 PM
Any other ideas? I guess I'll be calling MS to see what is the expected behavior of a DC in this scenario then. It's got me curious. On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > More info... from what I've seen watching the unreg, reg process.. > I would expect to see the version ID increment by two wouldnt I? > +1 for the unreg on DC1, and +1 for the reg on DC2? > > Well I'm seeing the version only incrementing by 1. And the failover > time has been as fast as 10 seconds, which means the spn > unreg/registration is occurring in less than 10 seconds apart from 2 > different DCs > > Any other ideas? > > > On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >> If the SPN value is already present on the 2nd DC, since the change of >> unregister hasnt replicated to it yet, will it still write or will it >> do nothing? Then in 25 secs, the unregistration gets replicated to >> DC2, thus no SPN at the end of it all? >> >> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx> wrote: >>> If there is zero change then I don't expect the version number to increment. >>> >>> Thanks, >>> Brian Desmond >>> brian@xxxxxxxxxxxxxxxx >>> >>> w - 312.625.1438 \| c - 312.731.3132 >>> >>> -----Original Message----- >>> From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>> Sent: Friday, June 29, 2012 8:55 PM >>> To: activedir@xxxxxxxxxxxxxxxx >>> Subject: Re: [ActiveDir] Attribute Replication Conflict >>> >>> I just dont get it... it continues to puzzle me. What should I be >>> looking for in the objmeta? I've tracked the versionID and it >>> stays the same.. >>> >>> What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC >>> hasnt replicated within 20 secs.. Does it still attempt a write? >>> >>> >>> >>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >>>> Yea, thats what I figured.. even with auditing (Quest) it logged the >>>> process properly, the unreg from node one on DC1 then 18 secs later >>>> the registration on DC2 from node 2, but for some reason, it didnt >>>> show on DC2 and thus the SPN is not there.. no errors on the supposed >>>> DC either. Very odd. I will have to pull some objmeta to see more, >>>> but something doesnt compute. >>>> >>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >>>>> Hi Rand >>>>> >>>>> You shouldn't have ended up with no SPN. >>>>> >>>>> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >>>>> >>>>> Tony >>>>> >>>>> ________________________________________ >>>>> From: activedir-owner@xxxxxxxxxxxxxxxx >>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>>>> [rmscheck08@xxxxxxxxxxxxxxxx] >>>>> Sent: Friday, 29 June 2012 1:16 p.m. >>>>> To: ActiveDir@xxxxxxxxxxxxxxxx >>>>> Subject: [ActiveDir] Attribute Replication Conflict >>>>> >>>>> I'm having a problem figuring out what is the expected result when an >>>>> SPN tied to a SQL cluster service account. I am finding that >>>>> sometimes the attempted SPN write doesn't get replicated. What is >>>>> happening, when the SQL cluster is failed over, the cluster owner >>>>> unregisters the SPN, then the new owner reregisters the SPN when it >>>>> starts up SQL. Sometimes the unregister/register process can occur >>>>> on different DCs. I guess I'm trying to find out why sometimes I >>>>> will have the SPN registered and sometimes it wont even though the >>>>> SQL logs will always say SPN registered successfully. I am >>>>> thinking this due to some conflict resolution on the attribute since >>>>> the register/unregister process can be seconds apart. >>>>> >>>>> Here's what I think I know... >>>>> >>>>> Scenario >>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >>>>> >>>>> 1. the modification that has the higher versionID will win, OR if >>>>> same 2. the modification with the later timestamp will win, OR if >>>>> same 3. the modification from the DC with the lower GUID will win. >>>>> >>>>> However, I'm still puzzled as, in the scenario, above, I ended up >>>>> with no SPN. I would have thought because the write to DC2 was >>>>> later than DC1, it should have won, assuming the versionID was the >>>>> same. Both should have started with the same number if no change to >>>>> that attribute happened prior, right? Thus, the later timestamp rule >>>>> should have given it to DC2's value, but it didnt. >>>>> >>>>> What do you think happened there? Replication on both DCs are fine >>>>> so what should I expect? >>>>> >>>>> -Rand >>>>> >>>>> List info: http://www.activedir.org/List.aspx >>>>> List info: http://www.activedir.org/List.aspx >>> >>> List info: http://www.activedir.org/List.aspx >>> >>> >>> >>> List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

07/14/2012 3:20 PM
Hmm, Gmail has totally wacked out my thread so I am lost of anyone has replied so I'll try again. Well it seems MS has been of no help.. I am not sure why this question is so hard.. it should be a case of typical conflict resolution, but I think its more than that.. What it boils down to is, will a DC write a value to the servicePrincinpalName attribute if its already there (as in it sees no difference between whats already contained in the attribute versus what its trying to write). The meat of it is, a second DC gets a request to write an SPN to a user account when that value is already present, and in about 10 seconds or less, it will be receiving a replicated write from another DC who just removed that value. All a result from a SQL failover that happens in less than 10 seconds. Any one got any other ideas? On Sun, Jul 8, 2012 at 8:39 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > Any other ideas? I guess I'll be calling MS to see what is the > expected behavior of a DC in this scenario then. It's got me > curious. > > > On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >> More info... from what I've seen watching the unreg, reg process.. >> I would expect to see the version ID increment by two wouldnt I? >> +1 for the unreg on DC1, and +1 for the reg on DC2? >> >> Well I'm seeing the version only incrementing by 1. And the failover >> time has been as fast as 10 seconds, which means the spn >> unreg/registration is occurring in less than 10 seconds apart from 2 >> different DCs >> >> Any other ideas? >> >> >> On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >>> If the SPN value is already present on the 2nd DC, since the change of >>> unregister hasnt replicated to it yet, will it still write or will it >>> do nothing? Then in 25 secs, the unregistration gets replicated to >>> DC2, thus no SPN at the end of it all? >>> >>> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx> wrote: >>>> If there is zero change then I don't expect the version number to increment. >>>> >>>> Thanks, >>>> Brian Desmond >>>> brian@xxxxxxxxxxxxxxxx >>>> >>>> w - 312.625.1438 \| c - 312.731.3132 >>>> >>>> -----Original Message----- >>>> From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>>> Sent: Friday, June 29, 2012 8:55 PM >>>> To: activedir@xxxxxxxxxxxxxxxx >>>> Subject: Re: [ActiveDir] Attribute Replication Conflict >>>> >>>> I just dont get it... it continues to puzzle me. What should I be >>>> looking for in the objmeta? I've tracked the versionID and it >>>> stays the same.. >>>> >>>> What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC >>>> hasnt replicated within 20 secs.. Does it still attempt a write? >>>> >>>> >>>> >>>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: >>>>> Yea, thats what I figured.. even with auditing (Quest) it logged the >>>>> process properly, the unreg from node one on DC1 then 18 secs later >>>>> the registration on DC2 from node 2, but for some reason, it didnt >>>>> show on DC2 and thus the SPN is not there.. no errors on the supposed >>>>> DC either. Very odd. I will have to pull some objmeta to see more, >>>>> but something doesnt compute. >>>>> >>>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> wrote: >>>>>> Hi Rand >>>>>> >>>>>> You shouldn't have ended up with no SPN. >>>>>> >>>>>> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >>>>>> >>>>>> Tony >>>>>> >>>>>> ________________________________________ >>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx >>>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>>>>> [rmscheck08@xxxxxxxxxxxxxxxx] >>>>>> Sent: Friday, 29 June 2012 1:16 p.m. >>>>>> To: ActiveDir@xxxxxxxxxxxxxxxx >>>>>> Subject: [ActiveDir] Attribute Replication Conflict >>>>>> >>>>>> I'm having a problem figuring out what is the expected result when an >>>>>> SPN tied to a SQL cluster service account. I am finding that >>>>>> sometimes the attempted SPN write doesn't get replicated. What is >>>>>> happening, when the SQL cluster is failed over, the cluster owner >>>>>> unregisters the SPN, then the new owner reregisters the SPN when it >>>>>> starts up SQL. Sometimes the unregister/register process can occur >>>>>> on different DCs. I guess I'm trying to find out why sometimes I >>>>>> will have the SPN registered and sometimes it wont even though the >>>>>> SQL logs will always say SPN registered successfully. I am >>>>>> thinking this due to some conflict resolution on the attribute since >>>>>> the register/unregister process can be seconds apart. >>>>>> >>>>>> Here's what I think I know... >>>>>> >>>>>> Scenario >>>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >>>>>> >>>>>> 1. the modification that has the higher versionID will win, OR if >>>>>> same 2. the modification with the later timestamp will win, OR if >>>>>> same 3. the modification from the DC with the lower GUID will win. >>>>>> >>>>>> However, I'm still puzzled as, in the scenario, above, I ended up >>>>>> with no SPN. I would have thought because the write to DC2 was >>>>>> later than DC1, it should have won, assuming the versionID was the >>>>>> same. Both should have started with the same number if no change to >>>>>> that attribute happened prior, right? Thus, the later timestamp rule >>>>>> should have given it to DC2's value, but it didnt. >>>>>> >>>>>> What do you think happened there? Replication on both DCs are fine >>>>>> so what should I expect? >>>>>> >>>>>> -Rand >>>>>> >>>>>> List info: http://www.activedir.org/List.aspx >>>>>> List info: http://www.activedir.org/List.aspx >>>> >>>> List info: http://www.activedir.org/List.aspx >>>> >>>> >>>> >>>> List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

bijubabuk

Posts:153

07/15/2012 1:58 AM
Not sure if SQL compares it with what is there in AD before it writes SPN - my guess is not. But I think u can test your theory if u can re-create the issue.. Failover the SQL then compare the object metadata from both the DCs (?) If the 15 sec interval for intra-site replication is not sufficient enough for u to gather the metadata, increase it for couple of min or so for this particular case. WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To change the delay between the change to the Active Directory and first replication partner notification, use Registry Editor to change the value data for the "Replicator notify pause after modify (secs)" DWORD value in the following registry key: Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters Key: Replicator notify pause after modify (secs) Value: REG_DWORD The default value data for the "Replicator notify pause after modify (secs)" DWORD value in Windows 2000 is 0x12c. This hexadecimal format is equal to a decimal value of 300 that is equal to 5 minutes. In Windows Server 2003 and in later versions, the default value data is 15 seconds Rgds My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) -----Original Message----- From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of rmscheck08@xxxxxxxxxxxxxxxx Sent: Saturday, July 14, 2012 7:50 PM To: activedir@xxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Attribute Replication Conflict Hmm, Gmail has totally wacked out my thread so I am lost of anyone has replied so I'll try again. Well it seems MS has been of no help.. I am not sure why this question is so hard.. it should be a case of typical conflict resolution, but I think its more than that.. What it boils down to is, will a DC write a value to the servicePrincinpalName attribute if its already there (as in it sees no difference between whats already contained in the attribute versus what its trying to write). The meat of it is, a second DC gets a request to write an SPN to a user account when that value is already present, and in about 10 seconds or less, it will be receiving a replicated write from another DC who just removed that value. All a result from a SQL failover that happens in less than 10 seconds. Any one got any other ideas? On Sun, Jul 8, 2012 at 8:39 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx <mailto:rmscheck08@xxxxxxxxxxxxxxxx> > wrote: > Any other ideas? I guess I'll be calling MS to see what is the > expected behavior of a DC in this scenario then. It's got me > curious. > > > On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx <mailto:rmscheck08@xxxxxxxxxxxxxxxx> > wrote: >> More info... from what I've seen watching the unreg, reg process.. >> I would expect to see the version ID increment by two wouldnt I? >> +1 for the unreg on DC1, and +1 for the reg on DC2? >> >> Well I'm seeing the version only incrementing by 1. And the failover >> time has been as fast as 10 seconds, which means the spn >> unreg/registration is occurring in less than 10 seconds apart from 2 >> different DCs >> >> Any other ideas? >> >> >> On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx <mailto:rmscheck08@xxxxxxxxxxxxxxxx> > wrote: >>> If the SPN value is already present on the 2nd DC, since the change >>> of unregister hasnt replicated to it yet, will it still write or will it >>> do nothing? Then in 25 secs, the unregistration gets replicated to >>> DC2, thus no SPN at the end of it all? >>> >>> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx <mailto:brian@xxxxxxxxxxxxxxxx> > wrote: >>>> If there is zero change then I don't expect the version number to increment. >>>> >>>> Thanks, >>>> Brian Desmond >>>> brian@xxxxxxxxxxxxxxxx <mailto:brian@xxxxxxxxxxxxxxxx> >>>> >>>> w - 312.625.1438 \| c - 312.731.3132 >>>> >>>> -----Original Message----- >>>> From: activedir-owner@xxxxxxxxxxxxxxxx <mailto:activedir-owner@xxxxxxxxxxxxxxxx> >>>> [mailto:activedir-owner@xxxxxxxxxxxxxxxx <mailto:activedir-owner@xxxxxxxxxxxxxxxx> ] On Behalf Of Rand >>>> Salazar >>>> Sent: Friday, June 29, 2012 8:55 PM >>>> To: activedir@xxxxxxxxxxxxxxxx <mailto:activedir@xxxxxxxxxxxxxxxx> >>>> Subject: Re: [ActiveDir] Attribute Replication Conflict >>>> >>>> I just dont get it... it continues to puzzle me. What should I be >>>> looking for in the objmeta? I've tracked the versionID and it >>>> stays the same.. >>>> >>>> What is supposed to happen when DC2 attempts to re-reg the SPN but in its DB the SPN is still there.. since the unreg from the other DC >>>> hasnt replicated within 20 secs.. Does it still attempt a write? >>>> >>>> >>>> >>>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx <mailto:rmscheck08@xxxxxxxxxxxxxxxx> > wrote: >>>>> Yea, thats what I figured.. even with auditing (Quest) it logged >>>>> the process properly, the unreg from node one on DC1 then 18 secs >>>>> later the registration on DC2 from node 2, but for some reason, it >>>>> didnt show on DC2 and thus the SPN is not there.. no errors on the supposed >>>>> DC either. Very odd. I will have to pull some objmeta to see more, >>>>> but something doesnt compute. >>>>> >>>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx <mailto:tony@xxxxxxxxxxxxxxxx> > wrote: >>>>>> Hi Rand >>>>>> >>>>>> You shouldn't have ended up with no SPN. >>>>>> >>>>>> I would enable directory access auditing and use that plus replication metadata (repadmin /showobjmeta) to try and figure it out. >>>>>> >>>>>> Tony >>>>>> >>>>>> ________________________________________ >>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx <mailto:activedir-owner@xxxxxxxxxxxxxxxx> >>>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >>>>>> [rmscheck08@xxxxxxxxxxxxxxxx] >>>>>> Sent: Friday, 29 June 2012 1:16 p.m. >>>>>> To: ActiveDir@xxxxxxxxxxxxxxxx <mailto:ActiveDir@xxxxxxxxxxxxxxxx> >>>>>> Subject: [ActiveDir] Attribute Replication Conflict >>>>>> >>>>>> I'm having a problem figuring out what is the expected result >>>>>> when an SPN tied to a SQL cluster service account. I am finding that >>>>>> sometimes the attempted SPN write doesn't get replicated. What is >>>>>> happening, when the SQL cluster is failed over, the cluster owner >>>>>> unregisters the SPN, then the new owner reregisters the SPN when it >>>>>> starts up SQL. Sometimes the unregister/register process can occur >>>>>> on different DCs. I guess I'm trying to find out why sometimes I >>>>>> will have the SPN registered and sometimes it wont even though the >>>>>> SQL logs will always say SPN registered successfully. I am >>>>>> thinking this due to some conflict resolution on the attribute >>>>>> since the register/unregister process can be seconds apart. >>>>>> >>>>>> Here's what I think I know... >>>>>> >>>>>> Scenario >>>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >>>>>> >>>>>> 1. the modification that has the higher versionID will win, OR >>>>>> if same 2. the modification with the later timestamp will win, >>>>>> OR if same 3. the modification from the DC with the lower GUID will win. >>>>>> >>>>>> However, I'm still puzzled as, in the scenario, above, I ended up >>>>>> with no SPN. I would have thought because the write to DC2 was >>>>>> later than DC1, it should have won, assuming the versionID was the >>>>>> same. Both should have started with the same number if no change to >>>>>> that attribute happened prior, right? Thus, the later timestamp >>>>>> rule should have given it to DC2's value, but it didnt. >>>>>> >>>>>> What do you think happened there? Replication on both DCs are fine >>>>>> so what should I expect? >>>>>> >>>>>> -Rand >>>>>> >>>>>> List info: http://www.activedir.org/List.aspx <http://www.activedir.org/List.aspx> >>>>>> List info: http://www.activedir.org/List.aspx <http://www.activedir.org/List.aspx> >>>> >>>> List info: http://www.activedir.org/List.aspx <http://www.activedir.org/List.aspx> >>>> >>>> >>>> >>>> List info: http://www.activedir.org/List.aspx <http://www.activedir.org/List.aspx> List info: http://www.activedir.org/List.aspx <http://www.activedir.org/List.aspx>

rmscheck

Posts:290

07/15/2012 5:24 AM
I've actually tested it and wire capped it.. and yes SQL doesnt check, if the service account its running under has permissions to change it will send the request without and checking. In the capture, I saw exactly what I described.. SQL1 fails over, sends DC1 the unregister request.. DC1 receives the request and successfully unregisters the SPN.. DC1 logs show the change and objmeta shows +1 versionID. SQL2 then receives the cluster resources and tells DC2 to register the SPN. DC2 gets the request and event logs show the update but does nothing.. no objmeta change. DC2 then gets the replicated update from DC1 to remove the SPN. Objmeta shows DC1 last writer.. All of this happens in less than 10 secs. What is supposed to happen in a situation like this? On Sat, Jul 14, 2012 at 7:55 PM, <Biju_babu@xxxxxxxxxxxxxxxx> wrote: > Not sure if SQL compares it with what is there in AD before it writes SPN - > my guess is not. But I think u can test your theory if u can re-create the > issue.. > > > > Failover the SQL then compare the object metadata from both the DCs (?) If > the 15 sec interval for intra-site replication is not sufficient enough for > u to gather the metadata, increase it for couple of min or so for this > particular case. > > > > > > WARNING: If you use Registry Editor incorrectly, you may cause serious > problems that may require you to reinstall your operating system. Microsoft > cannot guarantee that you can solve problems that result from using Registry > Editor incorrectly. Use Registry Editor at your own risk. > > To change the delay between the change to the Active Directory and first > replication partner notification, use Registry Editor to change the value > data for the "Replicator notify pause after modify (secs)" DWORD value in > the following registry key: > > > > Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters > > Key: Replicator notify pause after modify (secs) > > Value: REG_DWORD > > > > The default value data for the "Replicator notify pause after modify (secs)" > DWORD value in Windows 2000 is 0x12c. This hexadecimal format is equal to a > decimal value of 300 that is equal to 5 minutes. In Windows Server 2003 and > in later versions, the default value data is 15 seconds > > > > Rgds > > > > My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) > > > > > > -----Original Message----- > From: activedir-owner@xxxxxxxxxxxxxxxx > [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of > rmscheck08@xxxxxxxxxxxxxxxx > Sent: Saturday, July 14, 2012 7:50 PM > To: activedir@xxxxxxxxxxxxxxxx > Subject: Re: [ActiveDir] Attribute Replication Conflict > > > > Hmm, Gmail has totally wacked out my thread so I am lost of anyone has > replied so I'll try again. > > > > Well it seems MS has been of no help.. I am not sure why this > > question is so hard.. it should be a case of typical conflict > > resolution, but I think its more than that.. > > > > What it boils down to is, will a DC write a value to the > servicePrincinpalName attribute if its already there (as in it sees no > difference between whats already contained in the attribute versus > > what its trying to write). The meat of it is, a second DC gets a > > request to write an SPN to a user account when that value is already > present, and in about 10 seconds or less, it will be receiving a > > replicated write from another DC who just removed that value. All a > > result from a SQL failover that happens in less than 10 seconds. > > > > Any one got any other ideas? > > > > > > On Sun, Jul 8, 2012 at 8:39 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > >> Any other ideas? I guess I'll be calling MS to see what is the > >> expected behavior of a DC in this scenario then. It's got me > >> curious. > >> > >> > >> On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >> wrote: > >>> More info... from what I've seen watching the unreg, reg process.. > >>> I would expect to see the version ID increment by two wouldnt I? > >>> +1 for the unreg on DC1, and +1 for the reg on DC2? > >>> > >>> Well I'm seeing the version only incrementing by 1. And the failover > >>> time has been as fast as 10 seconds, which means the spn > >>> unreg/registration is occurring in less than 10 seconds apart from 2 > >>> different DCs > >>> > >>> Any other ideas? > >>> > >>> > >>> On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >>> wrote: > >>>> If the SPN value is already present on the 2nd DC, since the change > >>>> of unregister hasnt replicated to it yet, will it still write or will it > >>>> do nothing? Then in 25 secs, the unregistration gets replicated to > >>>> DC2, thus no SPN at the end of it all? > >>>> > >>>> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond <brian@xxxxxxxxxxxxxxxx> >>>> wrote: > >>>>> If there is zero change then I don't expect the version number to >>>>> increment. > >>>>> > >>>>> Thanks, > >>>>> Brian Desmond > >>>>> brian@xxxxxxxxxxxxxxxx > >>>>> > >>>>> w - 312.625.1438 \| c - 312.731.3132 > >>>>> > >>>>> -----Original Message----- > >>>>> From: activedir-owner@xxxxxxxxxxxxxxxx > >>>>> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand > >>>>> Salazar > >>>>> Sent: Friday, June 29, 2012 8:55 PM > >>>>> To: activedir@xxxxxxxxxxxxxxxx > >>>>> Subject: Re: [ActiveDir] Attribute Replication Conflict > >>>>> > >>>>> I just dont get it... it continues to puzzle me. What should I be > >>>>> looking for in the objmeta? I've tracked the versionID and it > >>>>> stays the same.. > >>>>> > >>>>> What is supposed to happen when DC2 attempts to re-reg the SPN but in >>>>> its DB the SPN is still there.. since the unreg from the other DC > >>>>> hasnt replicated within 20 secs.. Does it still attempt a write? > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >>>>> wrote: > >>>>>> Yea, thats what I figured.. even with auditing (Quest) it logged > >>>>>> the process properly, the unreg from node one on DC1 then 18 secs > >>>>>> later the registration on DC2 from node 2, but for some reason, it > >>>>>> didnt show on DC2 and thus the SPN is not there.. no errors on the >>>>>> supposed > >>>>>> DC either. Very odd. I will have to pull some objmeta to see more, > >>>>>> but something doesnt compute. > >>>>>> > >>>>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> >>>>>> wrote: > >>>>>>> Hi Rand > >>>>>>> > >>>>>>> You shouldn't have ended up with no SPN. > >>>>>>> > >>>>>>> I would enable directory access auditing and use that plus >>>>>>> replication metadata (repadmin /showobjmeta) to try and figure it out. > >>>>>>> > >>>>>>> Tony > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx > >>>>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar > >>>>>>> [rmscheck08@xxxxxxxxxxxxxxxx] > >>>>>>> Sent: Friday, 29 June 2012 1:16 p.m. > >>>>>>> To: ActiveDir@xxxxxxxxxxxxxxxx > >>>>>>> Subject: [ActiveDir] Attribute Replication Conflict > >>>>>>> > >>>>>>> I'm having a problem figuring out what is the expected result > >>>>>>> when an SPN tied to a SQL cluster service account. I am finding that > >>>>>>> sometimes the attempted SPN write doesn't get replicated. What is > >>>>>>> happening, when the SQL cluster is failed over, the cluster owner > >>>>>>> unregisters the SPN, then the new owner reregisters the SPN when it > >>>>>>> starts up SQL. Sometimes the unregister/register process can occur > >>>>>>> on different DCs. I guess I'm trying to find out why sometimes I > >>>>>>> will have the SPN registered and sometimes it wont even though the > >>>>>>> SQL logs will always say SPN registered successfully. I am > >>>>>>> thinking this due to some conflict resolution on the attribute > >>>>>>> since the register/unregister process can be seconds apart. > >>>>>>> > >>>>>>> Here's what I think I know... > >>>>>>> > >>>>>>> Scenario > >>>>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. > >>>>>>> > >>>>>>> 1. the modification that has the higher versionID will win, OR > >>>>>>> if same 2. the modification with the later timestamp will win, > >>>>>>> OR if same 3. the modification from the DC with the lower GUID will >>>>>>> win. > >>>>>>> > >>>>>>> However, I'm still puzzled as, in the scenario, above, I ended up > >>>>>>> with no SPN. I would have thought because the write to DC2 was > >>>>>>> later than DC1, it should have won, assuming the versionID was the > >>>>>>> same. Both should have started with the same number if no change to > >>>>>>> that attribute happened prior, right? Thus, the later timestamp > >>>>>>> rule should have given it to DC2's value, but it didnt. > >>>>>>> > >>>>>>> What do you think happened there? Replication on both DCs are fine > >>>>>>> so what should I expect? > >>>>>>> > >>>>>>> -Rand > >>>>>>> > >>>>>>> List info: http://www.activedir.org/List.aspx > >>>>>>> List info: http://www.activedir.org/List.aspx > >>>>> > >>>>> List info: http://www.activedir.org/List.aspx > >>>>> > >>>>> > >>>>> > >>>>> List info: http://www.activedir.org/List.aspx > > > > List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

bijubabuk

Posts:153

07/15/2012 8:48 AM
Perhaps it's that DC 2 somehow fails to actually write the attribute rather than a replication conflict ? Is that DC2 always the Server2 which it contacts ? can u take DC2 out of the equation or force to use a single DC for both nodes ? May be doing it doesn't make much sense or resolve the issue, but it can give u better understanding of the problem.. Rgds My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) -----Original Message----- From: activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of rmscheck08@xxxxxxxxxxxxxxxx Sent: Sunday, July 15, 2012 9:54 AM To: activedir@xxxxxxxxxxxxxxxx Subject: Re: [ActiveDir] Attribute Replication Conflict I've actually tested it and wire capped it.. and yes SQL doesnt check, if the service account its running under has permissions to change it will send the request without and checking. In the capture, I saw exactly what I described.. SQL1 fails over, sends DC1 the unregister request.. DC1 receives the request and successfully unregisters the SPN.. DC1 logs show the change and objmeta shows +1 versionID. SQL2 then receives the cluster resources and tells DC2 to register the SPN. DC2 gets the request and event logs show the update but does nothing.. no objmeta change. DC2 then gets the replicated update from DC1 to remove the SPN. Objmeta shows DC1 last writer.. All of this happens in less than 10 secs. What is supposed to happen in a situation like this? On Sat, Jul 14, 2012 at 7:55 PM, <Biju_babu@xxxxxxxxxxxxxxxx> wrote: > Not sure if SQL compares it with what is there in AD before it writes > SPN - my guess is not. But I think u can test your theory if u can > re-create the issue.. > > > > Failover the SQL then compare the object metadata from both the DCs > (?) If the 15 sec interval for intra-site replication is not > sufficient enough for u to gather the metadata, increase it for couple > of min or so for this particular case. > > > > > > WARNING: If you use Registry Editor incorrectly, you may cause serious > problems that may require you to reinstall your operating system. > Microsoft cannot guarantee that you can solve problems that result > from using Registry Editor incorrectly. Use Registry Editor at your own risk. > > To change the delay between the change to the Active Directory and > first replication partner notification, use Registry Editor to change > the value data for the "Replicator notify pause after modify (secs)" > DWORD value in the following registry key: > > > > Path: > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters > > Key: Replicator notify pause after modify (secs) > > Value: REG_DWORD > > > > The default value data for the "Replicator notify pause after modify (secs)" > DWORD value in Windows 2000 is 0x12c. This hexadecimal format is equal > to a decimal value of 300 that is equal to 5 minutes. In Windows > Server 2003 and in later versions, the default value data is 15 > seconds > > > > Rgds > > > > My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) > > > > > > -----Original Message----- > From: activedir-owner@xxxxxxxxxxxxxxxx > [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of > rmscheck08@xxxxxxxxxxxxxxxx > Sent: Saturday, July 14, 2012 7:50 PM > To: activedir@xxxxxxxxxxxxxxxx > Subject: Re: [ActiveDir] Attribute Replication Conflict > > > > Hmm, Gmail has totally wacked out my thread so I am lost of anyone has > replied so I'll try again. > > > > Well it seems MS has been of no help.. I am not sure why this > > question is so hard.. it should be a case of typical conflict > > resolution, but I think its more than that.. > > > > What it boils down to is, will a DC write a value to the > servicePrincinpalName attribute if its already there (as in it sees no > difference between whats already contained in the attribute versus > > what its trying to write). The meat of it is, a second DC gets a > > request to write an SPN to a user account when that value is already > present, and in about 10 seconds or less, it will be receiving a > > replicated write from another DC who just removed that value. All a > > result from a SQL failover that happens in less than 10 seconds. > > > > Any one got any other ideas? > > > > > > On Sun, Jul 8, 2012 at 8:39 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> wrote: > >> Any other ideas? I guess I'll be calling MS to see what is the > >> expected behavior of a DC in this scenario then. It's got me > >> curious. > >> > >> > >> On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >> wrote: > >>> More info... from what I've seen watching the unreg, reg process.. > >>> I would expect to see the version ID increment by two wouldnt I? > >>> +1 for the unreg on DC1, and +1 for the reg on DC2? > >>> > >>> Well I'm seeing the version only incrementing by 1. And the failover > >>> time has been as fast as 10 seconds, which means the spn > >>> unreg/registration is occurring in less than 10 seconds apart from 2 > >>> different DCs > >>> > >>> Any other ideas? > >>> > >>> > >>> On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >>> wrote: > >>>> If the SPN value is already present on the 2nd DC, since the change > >>>> of unregister hasnt replicated to it yet, will it still write or >>>> will it > >>>> do nothing? Then in 25 secs, the unregistration gets replicated to > >>>> DC2, thus no SPN at the end of it all? > >>>> > >>>> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond >>>> <brian@xxxxxxxxxxxxxxxx> >>>> wrote: > >>>>> If there is zero change then I don't expect the version number to >>>>> increment. > >>>>> > >>>>> Thanks, > >>>>> Brian Desmond > >>>>> brian@xxxxxxxxxxxxxxxx > >>>>> > >>>>> w - 312.625.1438 \| c - 312.731.3132 > >>>>> > >>>>> -----Original Message----- > >>>>> From: activedir-owner@xxxxxxxxxxxxxxxx > >>>>> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand > >>>>> Salazar > >>>>> Sent: Friday, June 29, 2012 8:55 PM > >>>>> To: activedir@xxxxxxxxxxxxxxxx > >>>>> Subject: Re: [ActiveDir] Attribute Replication Conflict > >>>>> > >>>>> I just dont get it... it continues to puzzle me. What should I be > >>>>> looking for in the objmeta? I've tracked the versionID and it > >>>>> stays the same.. > >>>>> > >>>>> What is supposed to happen when DC2 attempts to re-reg the SPN but >>>>> in its DB the SPN is still there.. since the unreg from the other >>>>> DC > >>>>> hasnt replicated within 20 secs.. Does it still attempt a write? > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar >>>>> <rmscheck08@xxxxxxxxxxxxxxxx> >>>>> wrote: > >>>>>> Yea, thats what I figured.. even with auditing (Quest) it logged > >>>>>> the process properly, the unreg from node one on DC1 then 18 secs > >>>>>> later the registration on DC2 from node 2, but for some reason, >>>>>> it > >>>>>> didnt show on DC2 and thus the SPN is not there.. no errors on >>>>>> the supposed > >>>>>> DC either. Very odd. I will have to pull some objmeta to see more, > >>>>>> but something doesnt compute. > >>>>>> > >>>>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> >>>>>> wrote: > >>>>>>> Hi Rand > >>>>>>> > >>>>>>> You shouldn't have ended up with no SPN. > >>>>>>> > >>>>>>> I would enable directory access auditing and use that plus >>>>>>> replication metadata (repadmin /showobjmeta) to try and figure it out. > >>>>>>> > >>>>>>> Tony > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx > >>>>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar > >>>>>>> [rmscheck08@xxxxxxxxxxxxxxxx] > >>>>>>> Sent: Friday, 29 June 2012 1:16 p.m. > >>>>>>> To: ActiveDir@xxxxxxxxxxxxxxxx > >>>>>>> Subject: [ActiveDir] Attribute Replication Conflict > >>>>>>> > >>>>>>> I'm having a problem figuring out what is the expected result > >>>>>>> when an SPN tied to a SQL cluster service account. I am finding >>>>>>> that > >>>>>>> sometimes the attempted SPN write doesn't get replicated. What is > >>>>>>> happening, when the SQL cluster is failed over, the cluster >>>>>>> owner > >>>>>>> unregisters the SPN, then the new owner reregisters the SPN when >>>>>>> it > >>>>>>> starts up SQL. Sometimes the unregister/register process can occur > >>>>>>> on different DCs. I guess I'm trying to find out why sometimes I > >>>>>>> will have the SPN registered and sometimes it wont even though >>>>>>> the > >>>>>>> SQL logs will always say SPN registered successfully. I am > >>>>>>> thinking this due to some conflict resolution on the attribute > >>>>>>> since the register/unregister process can be seconds apart. > >>>>>>> > >>>>>>> Here's what I think I know... > >>>>>>> > >>>>>>> Scenario > >>>>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. > >>>>>>> > >>>>>>> 1. the modification that has the higher versionID will win, OR > >>>>>>> if same 2. the modification with the later timestamp will win, > >>>>>>> OR if same 3. the modification from the DC with the lower GUID >>>>>>> will win. > >>>>>>> > >>>>>>> However, I'm still puzzled as, in the scenario, above, I ended >>>>>>> up > >>>>>>> with no SPN. I would have thought because the write to DC2 was > >>>>>>> later than DC1, it should have won, assuming the versionID was >>>>>>> the > >>>>>>> same. Both should have started with the same number if no change to > >>>>>>> that attribute happened prior, right? Thus, the later timestamp > >>>>>>> rule should have given it to DC2's value, but it didnt. > >>>>>>> > >>>>>>> What do you think happened there? Replication on both DCs are fine > >>>>>>> so what should I expect? > >>>>>>> > >>>>>>> -Rand > >>>>>>> > >>>>>>> List info: http://www.activedir.org/List.aspx > >>>>>>> List info: http://www.activedir.org/List.aspx > >>>>> > >>>>> List info: http://www.activedir.org/List.aspx > >>>>> > >>>>> > >>>>> > >>>>> List info: http://www.activedir.org/List.aspx > > > > List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

rmscheck

Posts:290

07/15/2012 10:47 PM
No, DC2 is one of many.. other DCs do the same. If the nodes end up contacts the DCs in reverse, same result. And here's what opposite of it all.. If we start without the SPN at all, on all DCs.. after the failover cycle, we end up with the SPN on the service account. On Sun, Jul 15, 2012 at 2:46 AM, <Biju_babu@xxxxxxxxxxxxxxxx> wrote: > Perhaps it's that DC 2 somehow fails to actually write the attribute > rather than a replication conflict ? > > Is that DC2 always the Server2 which it contacts ? can u take DC2 out of > the equation or force to use a single DC for both nodes ? > > May be doing it doesn't make much sense or resolve the issue, but it can > give u better understanding of the problem.. > > Rgds > > My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) > > > -----Original Message----- > From: activedir-owner@xxxxxxxxxxxxxxxx > [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of > rmscheck08@xxxxxxxxxxxxxxxx > Sent: Sunday, July 15, 2012 9:54 AM > To: activedir@xxxxxxxxxxxxxxxx > Subject: Re: [ActiveDir] Attribute Replication Conflict > > I've actually tested it and wire capped it.. and yes SQL doesnt check, > if the service account its running under has permissions to change it > will send the request without and checking. > > In the capture, I saw exactly what I described.. SQL1 fails over, > sends DC1 the unregister request.. DC1 receives the request and > successfully unregisters the SPN.. DC1 logs show the change and objmeta > shows +1 versionID. SQL2 then receives the cluster resources and tells > DC2 to register the SPN. DC2 gets the request and event logs show the > update but does nothing.. no objmeta change. DC2 then > gets the replicated update from DC1 to remove the SPN. Objmeta shows > DC1 last writer.. > > All of this happens in less than 10 secs. > > What is supposed to happen in a situation like this? > > > > On Sat, Jul 14, 2012 at 7:55 PM, <Biju_babu@xxxxxxxxxxxxxxxx> wrote: >> Not sure if SQL compares it with what is there in AD before it writes >> SPN - my guess is not. But I think u can test your theory if u can >> re-create the issue.. >> >> >> >> Failover the SQL then compare the object metadata from both the DCs >> (?) If the 15 sec interval for intra-site replication is not >> sufficient enough for u to gather the metadata, increase it for couple > >> of min or so for this particular case. >> >> >> >> >> >> WARNING: If you use Registry Editor incorrectly, you may cause serious > >> problems that may require you to reinstall your operating system. >> Microsoft cannot guarantee that you can solve problems that result >> from using Registry Editor incorrectly. Use Registry Editor at your > own risk. >> >> To change the delay between the change to the Active Directory and >> first replication partner notification, use Registry Editor to change >> the value data for the "Replicator notify pause after modify (secs)" >> DWORD value in the following registry key: >> >> >> >> Path: >> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters >> >> Key: Replicator notify pause after modify (secs) >> >> Value: REG_DWORD >> >> >> >> The default value data for the "Replicator notify pause after modify > (secs)" >> DWORD value in Windows 2000 is 0x12c. This hexadecimal format is equal > >> to a decimal value of 300 that is equal to 5 minutes. In Windows >> Server 2003 and in later versions, the default value data is 15 >> seconds >> >> >> >> Rgds >> >> >> >> My working hours are from 11:00 to 19:30 IST (00:30 to 09:00 CST) >> >> >> >> >> >> -----Original Message----- >> From: activedir-owner@xxxxxxxxxxxxxxxx >> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of >> rmscheck08@xxxxxxxxxxxxxxxx >> Sent: Saturday, July 14, 2012 7:50 PM >> To: activedir@xxxxxxxxxxxxxxxx >> Subject: Re: [ActiveDir] Attribute Replication Conflict >> >> >> >> Hmm, Gmail has totally wacked out my thread so I am lost of anyone has > >> replied so I'll try again. >> >> >> >> Well it seems MS has been of no help.. I am not sure why this >> >> question is so hard.. it should be a case of typical conflict >> >> resolution, but I think its more than that.. >> >> >> >> What it boils down to is, will a DC write a value to the >> servicePrincinpalName attribute if its already there (as in it sees no > >> difference between whats already contained in the attribute versus >> >> what its trying to write). The meat of it is, a second DC gets a >> >> request to write an SPN to a user account when that value is already >> present, and in about 10 seconds or less, it will be receiving a >> >> replicated write from another DC who just removed that value. All a >> >> result from a SQL failover that happens in less than 10 seconds. >> >> >> >> Any one got any other ideas? >> >> >> >> >> >> On Sun, Jul 8, 2012 at 8:39 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> > wrote: >> >>> Any other ideas? I guess I'll be calling MS to see what is the >> >>> expected behavior of a DC in this scenario then. It's got me >> >>> curious. >> >>> >> >>> >> >>> On Sat, Jun 30, 2012 at 3:48 PM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >>> wrote: >> >>>> More info... from what I've seen watching the unreg, reg process.. >> >>>> I would expect to see the version ID increment by two wouldnt I? >> >>>> +1 for the unreg on DC1, and +1 for the reg on DC2? >> >>>> >> >>>> Well I'm seeing the version only incrementing by 1. And the > failover >> >>>> time has been as fast as 10 seconds, which means the spn >> >>>> unreg/registration is occurring in less than 10 seconds apart from 2 >> >>>> different DCs >> >>>> >> >>>> Any other ideas? >> >>>> >> >>>> >> >>>> On Sat, Jun 30, 2012 at 8:04 AM, Rand Salazar <rmscheck08@xxxxxxxxxxxxxxxx> >>>> wrote: >> >>>>> If the SPN value is already present on the 2nd DC, since the change >> >>>>> of unregister hasnt replicated to it yet, will it still write or >>>>> will it >> >>>>> do nothing? Then in 25 secs, the unregistration gets replicated > to >> >>>>> DC2, thus no SPN at the end of it all? >> >>>>> >> >>>>> On Fri, Jun 29, 2012 at 9:28 PM, Brian Desmond >>>>> <brian@xxxxxxxxxxxxxxxx> >>>>> wrote: >> >>>>>> If there is zero change then I don't expect the version number to >>>>>> increment. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Brian Desmond >> >>>>>> brian@xxxxxxxxxxxxxxxx >> >>>>>> >> >>>>>> w - 312.625.1438 \| c - 312.731.3132 >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx >> >>>>>> [mailto:activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand >> >>>>>> Salazar >> >>>>>> Sent: Friday, June 29, 2012 8:55 PM >> >>>>>> To: activedir@xxxxxxxxxxxxxxxx >> >>>>>> Subject: Re: [ActiveDir] Attribute Replication Conflict >> >>>>>> >> >>>>>> I just dont get it... it continues to puzzle me. What should I > be >> >>>>>> looking for in the objmeta? I've tracked the versionID and it >> >>>>>> stays the same.. >> >>>>>> >> >>>>>> What is supposed to happen when DC2 attempts to re-reg the SPN but > >>>>>> in its DB the SPN is still there.. since the unreg from the other > >>>>>> DC >> >>>>>> hasnt replicated within 20 secs.. Does it still attempt a write? >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Jun 28, 2012 at 9:39 PM, Rand Salazar >>>>>> <rmscheck08@xxxxxxxxxxxxxxxx> >>>>>> wrote: >> >>>>>>> Yea, thats what I figured.. even with auditing (Quest) it logged >> >>>>>>> the process properly, the unreg from node one on DC1 then 18 secs >> >>>>>>> later the registration on DC2 from node 2, but for some reason, >>>>>>> it >> >>>>>>> didnt show on DC2 and thus the SPN is not there.. no errors on >>>>>>> the supposed >> >>>>>>> DC either. Very odd. I will have to pull some objmeta to see > more, >> >>>>>>> but something doesnt compute. >> >>>>>>> >> >>>>>>> On Thu, Jun 28, 2012 at 8:27 PM, Tony Murray <tony@xxxxxxxxxxxxxxxx> >>>>>>> wrote: >> >>>>>>>> Hi Rand >> >>>>>>>> >> >>>>>>>> You shouldn't have ended up with no SPN. >> >>>>>>>> >> >>>>>>>> I would enable directory access auditing and use that plus >>>>>>>> replication metadata (repadmin /showobjmeta) to try and figure > it out. >> >>>>>>>> >> >>>>>>>> Tony >> >>>>>>>> >> >>>>>>>> ________________________________________ >> >>>>>>>> From: activedir-owner@xxxxxxxxxxxxxxxx >> >>>>>>>> [activedir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Rand Salazar >> >>>>>>>> [rmscheck08@xxxxxxxxxxxxxxxx] >> >>>>>>>> Sent: Friday, 29 June 2012 1:16 p.m. >> >>>>>>>> To: ActiveDir@xxxxxxxxxxxxxxxx >> >>>>>>>> Subject: [ActiveDir] Attribute Replication Conflict >> >>>>>>>> >> >>>>>>>> I'm having a problem figuring out what is the expected result >> >>>>>>>> when an SPN tied to a SQL cluster service account. I am finding > >>>>>>>> that >> >>>>>>>> sometimes the attempted SPN write doesn't get replicated. What > is >> >>>>>>>> happening, when the SQL cluster is failed over, the cluster >>>>>>>> owner >> >>>>>>>> unregisters the SPN, then the new owner reregisters the SPN when > >>>>>>>> it >> >>>>>>>> starts up SQL. Sometimes the unregister/register process can > occur >> >>>>>>>> on different DCs. I guess I'm trying to find out why sometimes > I >> >>>>>>>> will have the SPN registered and sometimes it wont even though >>>>>>>> the >> >>>>>>>> SQL logs will always say SPN registered successfully. I am >> >>>>>>>> thinking this due to some conflict resolution on the attribute >> >>>>>>>> since the register/unregister process can be seconds apart. >> >>>>>>>> >> >>>>>>>> Here's what I think I know... >> >>>>>>>> >> >>>>>>>> Scenario >> >>>>>>>> DC1 unregisters at 10:05:13, DC2 registers at 10:05:31. >> >>>>>>>> >> >>>>>>>> 1. the modification that has the higher versionID will win, OR >> >>>>>>>> if same 2. the modification with the later timestamp will win, >> >>>>>>>> OR if same 3. the modification from the DC with the lower GUID >>>>>>>> will win. >> >>>>>>>> >> >>>>>>>> However, I'm still puzzled as, in the scenario, above, I ended >>>>>>>> up >> >>>>>>>> with no SPN. I would have thought because the write to DC2 was >> >>>>>>>> later than DC1, it should have won, assuming the versionID was >>>>>>>> the >> >>>>>>>> same. Both should have started with the same number if no > change to >> >>>>>>>> that attribute happened prior, right? Thus, the later timestamp >> >>>>>>>> rule should have given it to DC2's value, but it didnt. >> >>>>>>>> >> >>>>>>>> What do you think happened there? Replication on both DCs are > fine >> >>>>>>>> so what should I expect? >> >>>>>>>> >> >>>>>>>> -Rand >> >>>>>>>> >> >>>>>>>> List info: http://www.activedir.org/List.aspx >> >>>>>>>> List info: http://www.activedir.org/List.aspx >> >>>>>> >> >>>>>> List info: http://www.activedir.org/List.aspx >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> List info: http://www.activedir.org/List.aspx >> >> >> >> List info: http://www.activedir.org/List.aspx > > List info: http://www.activedir.org/List.aspx > > List info: http://www.activedir.org/List.aspx List info: http://www.activedir.org/List.aspx

skradel

Posts:354

rmscheck

Posts:290

skradel

Posts:354

rmscheck

Posts:290

mcasey

Posts:82

skradel

Posts:354

You are not authorized to post a reply.

Forums >ActiveDir Mail List Archive >List Archives > [ActiveDir] Attribute Replication Conflict

ActiveForums 3.7

Syndicate

Friends

List Archives

List Archives

Friends

Members

Articles

Related Links

Ads