Based on the description i Bug #1391204, I removed the cn=userRoot database and tried running remove-ds.pl and migrate-ds.pl scripts to check if its running fine. Is that all required to verify? Request you to add additional steps to verify, if required.

Sankar,

The bug appears when none of the backends are named 'userRoot', so you may test with both environments (with and without 'userRoot' backend).
The commands to test are the ones you tested but you may also test *-admin.pl scripts (register-ds-admin.pl, setup-ds-admin.pl if possible to create an instance without 'userRoot' but I doubt it is possible).

Hi Thierry, thanks for clarification.

1. Installed 389-ds-base, 389-admin, 389-ds-console and idm-console-framework packages.
2. Created two instances, one with admin console and other one without.

[0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1389 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix
nsBackendSuffix: userRoot:dc=lab,dc=eng,dc=rdu2,dc=redhat,dc=com

[0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix 
nsBackendSuffix: userRoot:dc=lab,dc=eng,dc=rdu2,dc=redhat,dc=com
nsBackendSuffix: NetscapeRoot:o=netscaperoot
nsBackendSuffix: example1489:dc=example,dc=com
nsBackendSuffix: example11489:dc=example1,dc=com
nsBackendSuffix: example21489:dc=example2,dc=com

3. Then, registered the instance to admin server using register-ds-admin.pl. The registration completed successfully.

4. Removed userRoot db from the instance where admin server is registered.
[0 root@qeos-84 389ds-replica]# ldapdelete -rx -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 "cn=userRoot,cn=ldbm database,cn=plugins,cn=config"

[0 root@qeos-84 389ds-replica]# ldapsearch -x -p 1489 -h localhost -D "cn=Directory Manager" -w Secret123 -b "" -s base + |grep -i nsBackendSuffix
nsBackendSuffix: NetscapeRoot:o=netscaperoot
nsBackendSuffix: example1489:dc=example,dc=com
nsBackendSuffix: example11489:dc=example1,dc=com
nsBackendSuffix: example21489:dc=example2,dc=com

5. Created new instance with setup-ds-admin.pl to create as well as register with the existing admin server. Creation and registration of instance completed successfully.

6. Created a new instance with setup-ds.pl script and then registered using register-ds-admin.pl script. Creation and registration of instance completed successfully.

Creation and registration of instances successfully completed with setup-ds-admin.pl and register-ds-admin.pl scripts. Also tested remove-ds.pl and remove-ds-admin.pl scripts. No issues encountered. Hence, marking the bug as Verified.

Tested environment:

[0 root@qeos-84 389ds-replica]# rpm -qa |egrep '389-|redhat-ds'
389-console-1.1.18-2.el7dsrv.noarch
389-ds-base-1.3.5.10-17.el7_3.x86_64
389-ds-base-libs-1.3.5.10-17.el7_3.x86_64
389-ds-console-1.2.16-1.el7dsrv.noarch
redhat-ds-admin-10.1.0-2.el7dsrv.x86_64
redhat-ds-10.1.0-2.el7dsrv.x86_64
389-admin-1.1.46-1.el7dsrv.x86_64
redhat-ds-base-10.1.0-2.el7dsrv.x86_64
redhat-ds-console-doc-10.1.0-2.el7dsrv.noarch
389-adminutil-1.1.23-2.el7dsrv.x86_64
redhat-ds-console-10.1.0-2.el7dsrv.noarch
389-ds-console-doc-1.2.16-1.el7dsrv.noarch
389-admin-console-1.1.12-2.el7dsrv.noarch
389-admin-console-doc-1.1.12-2.el7dsrv.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0385.html