search for: highwatermark

...STATUS_CONNECTION_RESET] >> [2017/10/12 08:38:57.969111,  0] >> ../source4/rpc_server/drsuapi/getncchanges.c:1961(dcesrv_drsuapi_DsGetNCChanges) >>   ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges >> 2nd replication on DN DC=samba,DC=company,DC=com older highwatermark >> (last_dn CN=Schema Admins,CN=Users,DC=samba,DC=company,DC=com) >> [2017/10/12 08:38:57.969762,  2] >> ../source4/rpc_server/drsuapi/getncchanges.c:1483(getncchanges_collect_objects) >>   ../source4/rpc_server/drsuapi/getncchanges.c:1483: getncchanges on >> DC=sam...

...52 PM, lingpanda101 via samba wrote: > You should be able to fix the 'replPropertyMetaData' errors with; > > samba-tool dbcheck --cross-ncs --fix --yes > 'fix_replmetadata_unsorted_attid' Yep, worked great! Fixed all of those replPropertyMetaData errors! :-) > The highwatermark doesn't necessarily reflect an issue. It's part of how > the destination DC keeps track of changes from the source DC. Can you > verify the time and date is correct on all DC's? Date & time matches. But the fact that the same identical message is logged multiple times per s...

...xt time this happens. > > But WHY is samba getting stuck in the first place? > > We are getting the following unusual in the logs on all three DCs: >> ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges 2nd >> replication on DN DC=samba,DC=company,DC=com older highwatermark >> (last_dn CN=a_username,CN=Users,DC=samba,DC=company,DC=com) >>   ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges >> 2nd replication on DN DC=samba,DC=company,DC=com older highwatermark >> (last_dn CN=Schema Admins,CN=Users,DC=samba,DC=company,DC=com)...

...nd samba funcion, until the next time this happens. But WHY is samba getting stuck in the first place? We are getting the following unusual in the logs on all three DCs: > ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges 2nd replication on DN DC=samba,DC=company,DC=com older highwatermark (last_dn CN=a_username,CN=Users,DC=samba,DC=company,DC=com) > ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges 2nd replication on DN DC=samba,DC=company,DC=com older highwatermark (last_dn CN=Schema Admins,CN=Users,DC=samba,DC=company,DC=com) > ../source4/rpc_server/drsua...

...m_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET] > [2017/10/12 08:38:57.969111, 0] ../source4/rpc_server/drsuapi/getncchanges.c:1961(dcesrv_drsuapi_DsGetNCChanges) > ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges 2nd replication on DN DC=samba,DC=company,DC=com older highwatermark (last_dn CN=Schema Admins,CN=Users,DC=samba,DC=company,DC=com) > [2017/10/12 08:38:57.969762, 2] ../source4/rpc_server/drsuapi/getncchanges.c:1483(getncchanges_collect_objects) > ../source4/rpc_server/drsuapi/getncchanges.c:1483: getncchanges on DC=samba,DC=company,DC=com using filter (uSN...

...ote: > >> You should be able to fix the 'replPropertyMetaData' errors with; >> >> samba-tool dbcheck --cross-ncs --fix --yes >> 'fix_replmetadata_unsorted_attid' > Yep, worked great! Fixed all of those replPropertyMetaData errors! :-) > >> The highwatermark doesn't necessarily reflect an issue. It's part of >> how the destination DC keeps track of changes from the source DC. Can >> you verify the time and date is correct on all DC's? > Date & time matches. But the fact that the same identical message is > logged mu...

On Thu, 2017-10-12 at 09:17 +0200, mj via samba wrote: > Hi all, James, > > After following James' suggestions fixing the several dbcheck errors, > and having observed things for a few days, I'd like to update this > issue, and hope for some new input again. :-) > > Summary: three DCs, all three running Version > 4.5.10-SerNet-Debian-16.wheezy, samba-tool

On Sat, 2017-10-14 at 12:52 +0200, mj wrote: > Hi Andrew, > > Thanks for chiming in! > > On 10/14/2017 12:16 PM, Andrew Bartlett via samba wrote: > > We are carefully following the reports here, but we do expect > > replication should be much more stable with Samba 4.7. > > OK, that's interesting, because I actually wanted to upgrade ASAP, but > (the

On Sat, October 14, 2017 14:33, Andrew Bartlett wrote: > > I remain ever thankful to those who are willing to test new Samba > versions, particularly Samba release candidates. > We have a FreeBSD-11 BHyve virtual machine spun up and awaiting a working SAMBA past v4.3+ to trial. So whenever this port gets to the point of requiring FreeBSD testers just drop me a note. -- ***

...CPU core fully utilized) - high BW utilization - replication issue messages: [2020/10/21 17:41:55.043563,? 0] ../../source4/rpc_server/drsuapi/getncchanges.c:2910(dcesrv_drsuapi_DsGetNCChanges) ? ../../source4/rpc_server/drsuapi/getncchanges.c:2910: DsGetNCChanges 2nd replication on DN DC= older highwatermark (last_dn CN=userXYZ,OU=Users,DC=) and this is happening only on one DC server in time - the one, to which this AD connector is connected for doing AD to AAD sync tasks. More details: CPU: mostly only one CPU core from all system-assigned cores is utilized at 100%: BW utilization: you can s...

Hi Andrew, Thanks for chiming in! On 10/14/2017 12:16 PM, Andrew Bartlett via samba wrote: > We are carefully following the reports here, but we do expect > replication should be much more stable with Samba 4.7. OK, that's interesting, because I actually wanted to upgrade ASAP, but (the few) 4.7-upgrade experiences that have been posted, are mostly about replication issues after

...been digging, digging, digging, and I found this in the log file of the DC the 2008R2 box is attempting to replicate from - Feb 1 16:52:42 larkin28 samba[18650]: ../source4/rpc_server/drsuapi/getncchanges.c:1961: DsGetNCChanges 2nd replication on DN CN=Configuration,DC=micore,DC=us older highwatermark (last_dn CN=414,CN=DisplaySpecifiers,CN=Configuration,DC=micore,DC=us) Feb 1 16:52:44 larkin28 samba[18650]: [2017/02/01 16:52:44.553389, 0] ../source4/rpc_server/drsuapi/getncchanges.c:1961(dcesrv_drsuapi_DsGetNCChanges) Feb 1 16:52:44 larkin28 samba[18650]: ../source4/rpc_server/drsu...

...We also see the high CPU usage on the DC that the Azure AD Connect server connected to. Between 70 - 100 percent in our case. We are not seeing any replication issues after azure AD Connect, and I have a script that automatically checks replication every few minutes. I was the one reporting the highwatermark back in 2017, but we're not getting those now. Between 2017 and now, we stopped testing azure, and I took it up again only last week. On the samba DC side, we observe that samba is very buzy talking to the Azure AD Connect machine, even though we filter sync using one group containing only...

...ure AD Connect >> server connected to. Between 70 - 100 percent in our case. >> >> We are not seeing any replication issues after azure AD Connect, and >> I have a script that automatically checks replication every few minutes. >> >> I was the one reporting the highwatermark back in 2017, but we're not >> getting those now. Between 2017 and now, we stopped testing azure, >> and I took it up again only last week. >> >> On the samba DC side, we observe that samba is very buzy talking to >> the Azure AD Connect machine, even though we...

...ge on the DC that the Azure AD Connect > server connected to. Between 70 - 100 percent in our case. > > We are not seeing any replication issues after azure AD Connect, and I > have a script that automatically checks replication every few minutes. > > I was the one reporting the highwatermark back in 2017, but we're not > getting those now. Between 2017 and now, we stopped testing azure, and > I took it up again only last week. > > On the samba DC side, we observe that samba is very buzy talking to > the Azure AD Connect machine, even though we filter sync using on...

...- high BW utilization > - replication issue messages: > [2020/10/21 17:41:55.043563,? 0] > ../../source4/rpc_server/drsuapi/getncchanges.c:2910(dcesrv_drsuapi_DsGetNCChanges) > ? ../../source4/rpc_server/drsuapi/getncchanges.c:2910: DsGetNCChanges > 2nd replication on DN DC= older highwatermark (last_dn > CN=userXYZ,OU=Users,DC=) > > > and this is happening only on one DC server in time - the one, to > which this AD connector is connected for doing AD to AAD sync tasks. > > More details: > > CPU: mostly only one CPU core from all system-assigned cores is >...

...nnected to. Between 70 - 100 percent in our case. >>> >>> We are not seeing any replication issues after azure AD Connect, and >>> I have a script that automatically checks replication every few >>> minutes. >>> >>> I was the one reporting the highwatermark back in 2017, but we're >>> not getting those now. Between 2017 and now, we stopped testing >>> azure, and I took it up again only last week. >>> >>> On the samba DC side, we observe that samba is very buzy talking to >>> the Azure AD Connect mach...

On 10/16/2017 08:56 PM, Andrew Bartlett wrote: > Are they breaking anything? Not sure. But in another thread I reported some issues on replication, highwatermark notifications, high COU load, etc. My idea was do try several things to fix this. SO I created a virtualised isolated environment, in which I can try out all kinds of things: - upgrading the DCs to 4.7 (as suggested by you) or - add a fresh 4.7 dc, see how that works out - try the clone-dc-data...

...opertyMetaData, nor copy it between DCs. > OR > > samba-tool drs replicate dc-damaged dc-blank DC=DOMAIN,DC=com > > should have flags to skip unknown parts, not to exit on first error This would not be safe, because when we safe the 'up to dateness vector' and the 'highwatermark' we promise that we have obtained and stored each object. We are already battling other errors ('missing objectclass') where objects are skipped unintentionally, and so I wont add such functionality intentionally. > > > > How to recreate this attribute properly? How to r...

On Tue, 2017-10-17 at 11:04 +0200, mj via samba wrote: > > On 10/16/2017 08:56 PM, Andrew Bartlett wrote: > > Are they breaking anything? > > Not sure. But in another thread I reported some issues on replication, > highwatermark notifications, high COU load, etc. > > My idea was do try several things to fix this. SO I created a > virtualised isolated environment, in which I can try out all kinds of > things: > > - upgrading the DCs to 4.7 (as suggested by you) > or > - add a fresh 4.7 dc, see ho...