Demotion of a AD DC fails with the following errors:
If I explicitly select a partner server with the "--server=" option
the
error is:
Deactivating inbound replication
Asking partner server [selectedDC] to synchronize from us
Error while demoting, re-enabling inbound replication
ERROR(<type 'exceptions.UnboundLocalError'>): uncaught exception -
local
variable 'e' referenced before assignment
File
"/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/__init__.py",
line 175, in _run
return self.run(*args, **kwargs)
File
"/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/domain.py",
line 797, in run
raise CommandError("Error while sending a DsReplicaSync for partion
%s" % str(part), e)
If I don't explicitly select a partner server, the error is:
Deactivating inbound replication
Asking partner server [someDC] to synchronize from us
Error while demoting, re-enabling inbound replication
ERROR(<type 'exceptions.RuntimeError'>): Error while sending a
DsReplicaSync for partion DC=lan,DC=cimbal,DC=pt - (8440,
'WERR_DS_DRA_BAD_NC')
File
"/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/domain.py",
line 786, in run
drsuapiBind.DsReplicaSync(drsuapi_handle, 1, req1)
I have two other DCs which seem to be working correctly. Replication and
name resolution are working. All 7 FSMO roles have been successfully
transferred to one of the other DCs prior to the demotion attempt.
Can anyone here point me to the right direction? I would like to avoid
brute force removal of the DC by "--remove-other-dead-server".
As a consequence of the demotion attempts, the other DCs have this on their samba logs: [2016/04/29 20:46:47.344355, 0] ../source4/dsdb/repl/drepl_service.c:260(drepl_replica_sync) ../source4/dsdb/repl/drepl_service.c:260: Failure - Failed to find requested Naming Context. werr = WERR_DS_DRA_BAD_NC
On Fri, 2016-04-29 at 20:50 +0100, Miguel Medalha wrote:> Demotion of a AD DC fails with the following errors: > > If I explicitly select a partner server with the "--server=" option > the > error is: > > Deactivating inbound replication > Asking partner server [selectedDC] to synchronize from us > Error while demoting, re-enabling inbound replication > ERROR(<type 'exceptions.UnboundLocalError'>): uncaught exception - > local > variable 'e' referenced before assignment > File > "/usr/local/samba/lib64/python2.7/site > -packages/samba/netcmd/__init__.py", > line 175, in _run > return self.run(*args, **kwargs) > File > "/usr/local/samba/lib64/python2.7/site > -packages/samba/netcmd/domain.py", > line 797, in run > raise CommandError("Error while sending a DsReplicaSync for > partion > %s" % str(part), e) > > > If I don't explicitly select a partner server, the error is: > > Deactivating inbound replication > Asking partner server [someDC] to synchronize from us > Error while demoting, re-enabling inbound replication > ERROR(<type 'exceptions.RuntimeError'>): Error while sending a > DsReplicaSync for partion DC=lan,DC=cimbal,DC=pt - (8440, > 'WERR_DS_DRA_BAD_NC') > File > "/usr/local/samba/lib64/python2.7/site > -packages/samba/netcmd/domain.py", > line 786, in run > drsuapiBind.DsReplicaSync(drsuapi_handle, 1, req1) > > > I have two other DCs which seem to be working correctly. Replication > and > name resolution are working. All 7 FSMO roles have been successfully > transferred to one of the other DCs prior to the demotion attempt. > > Can anyone here point me to the right direction? I would like to > avoid > brute force removal of the DC by "--remove-other-dead-server".The brute force removal really isn't as bad as it seems, if you have got all the data off the DC first and turned it off. Indeed, it is actually more correct and more tested, cleaning up more of the right things. In any case, I found and fixed the issue you hit last week, the patch is at https://bugzilla.samba.org/show_bug.cgi?id=11882 The syntax error should then go away (bug I have a patch for that as well, it is on samba-technical if you are curious). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
> The brute force removal really isn't as bad as it seems, if you have > got all the data off the DC first and turned it off. Indeed, it is > actually more correct and more tested, cleaning up more of the right > things.What raises my doubts here is that I need to use the demoted server as a member server, and I would need to keep its name because it hosts the users' profiles and some other resources that have lots of GPOs pointing to. The editing needed to accommodate a change of name would be extensive and prone to error. Also, I don't have much time to do it, the resources are scarse and the system needs to be in production again. The Samba Wiki contains dire warnings about never ever connect to the network again a DC removed by brute force. Will it be ok if it is joined again as a member server with the same name? I fear that the cleaning done by "--remove-other-dead-server" may leave some residue that will later wreak havoc on the working of the AD.> In any case, I found and fixed the issue you hit last week, the patch > is at https://bugzilla.samba.org/show_bug.cgi?id=11882Ok, thank you! I will surelly give it a try.> The syntax error should then go away (bug I have a patch for that as > well, it is on samba-technical if you are curious).Of course I am, more than curious! I can search for it, unless you give a pointer. Thank you for your reply. This is robbing me much needed sleep time.
> In any case, I found and fixed the issue you hit last week, the patch > is at https://bugzilla.samba.org/show_bug.cgi?id=11882 The syntax > error should then go away (bug I have a patch for that as well, it is > on samba-technical if you are curious).I found this on a post by Rowland penny (https://lists.samba.org/archive/samba/2016-March/198662.html): HI, it would seem you have found a bug, line 943 in 'domain.py' sends this: remove_dc.remove_sysvol_references(remote_samdb, dc_name) to 'remove_dc.py' , which expects to receive this: def remove_sysvol_references(samdb, logger, dc_name): Definitely a bug, logger is set earlier in the 'cmd_domain_demote' class. Would this still apply after the patches you did? (By the way, I already found the one on samba.technical)