samba - Apr 2016 - Samba 4.4.2 AD DC demote fails

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=11882
Ok, 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)