[Samba] samba-tool domain schemaupgrade fails on DC member

[Garming Sam]

Hi,

While I think we have most of the 2012 schema problems under control
now, there's still quite a bit of work to get the functional level
things working. In order to actually raise the level, we still need to
implement a number of features (mostly security). We're able to do some
prep steps (so that things like Windows server 2012 R2 appear to join us
but still use 2008 R2 FL) but it's still quite experimental and I don't
think I would recommend it unless you had a pressing need for Windows
2012 joins.

Cheers,

Garming

On 17/04/19 2:47 PM, Elias Pereira via samba wrote:
> Thanks Rowland and Garming for your help!!
>
> How about "another DC", or 'a second DC' ?
>
>
> Ok. Got it! :D
>
> Alternatively, re-joining the domain controller (or joining a new DC and
>> demoting the old one) probably works because I believe there is code to
>> handle this case.
>
> I re-joined (remove secrets.tdb and .lbd, copy idmap from existing DC...)
> and now works properly!
>
> Raise the level for 2012_R2 already working?
>
> On Tue, Apr 16, 2019 at 9:28 PM Garming Sam <garming at catalyst.net.nz> wrote:
>
>> Hi,
>>
>> This is a known issue:
>>
>> https://bugzilla.samba.org/show_bug.cgi?id=12204
>> https://bugzilla.samba.org/show_bug.cgi?id=13713
>>
>> There are currently patches in master to fix this issue. We could
>> probably backport a patch to 4.10, but you'd have to rebuild Samba.
>>
>> Alternatively, re-joining the domain controller (or joining a new DC and
>> demoting the old one) probably works because I believe there is code to
>> handle this case.
>>
>> There's not really any rollback of this code besides keeping a backup.
>> Schema updates build on top of each other and once you're at a certain
>> level you can't undo them, neither on Windows.
>>
>> Cheers,
>>
>> Garming
>>
>> On 17/04/19 6:58 AM, Elias Pereira via samba wrote:
>>> Hello,
>>>
>>> I upgrade the schema for our main ADDC and everything works properly, but
>>> the member DC (DC to an Existing AD) fails.
>>>
>>> Both servers are in version 4.10.2
>>> Distro: Debian 9.8
>>>
>>> *Main ADDC:*
>>>
>>> [2019/04/16 15:43:03.814846,  0]
>>>
>> ../../source4/rpc_server/drsuapi/getncchanges.c:2919(dcesrv_drsuapi_DsGetNCChanges)
>>>   ../../source4/rpc_server/drsuapi/getncchanges.c:2919: DsGetNCChanges
>> 2nd
>>> replication on different DN DC=campus,DC=sertao,DC=ifrs,DC=edu,DC=br
>>> CN=Schema,CN=Configuration,DC=campus,DC=sertao,DC=ifrs,DC=edu,DC=br
>>> (last_dn
>>>
>> CN=ms-DS-cloudExtensionAttribute14,CN=Schema,CN=Configuration,DC=campus,DC=sertao,DC=ifrs,DC=edu,DC=br)
>>> *Member DC:*
>>>
>>> [2019/04/16 15:42:55.703281,  0]
>>>
>> ../../source4/dsdb/repl/replicated_objects.c:248(dsdb_repl_resolve_working_schema)
>>>   Can't continue Schema load: didn't manage to convert any objects: all 1
>>> remaining of 133 objects failed to convert
>>> [2019/04/16 15:42:55.703619,  0]
>>>
>> ../../source4/dsdb/repl/replicated_objects.c:361(dsdb_repl_make_working_schema)
>>>   ../../source4/dsdb/repl/replicated_objects.c:361:
>>> dsdb_repl_resolve_working_schema() failed: WERR_INTERNAL_ERRORFailed to
>>> create working schema: WERR_INTERNAL_ERROR
>>>
>>> Is there any way to fix this problem?
>>>
>>> dumb question: Can I roolback the schemaupgrade? :D
>>>
>