Hello Aaron,

i can confirm that this is a big trouble/problem, also by oes24.1. You are not alone with this.

I hear since month, that the developer are working intensiv on this and the recommandation from OT is to "must" have a second oes-server for replica.

This will be correct and more secure, but we begin all with the first oes-server and for this a flag "First OES-Server" will help to not veriry a replica server!!!

cg

Thanks for the confirmation.

I have now reverted to the previous snapshot of OES 2018.3 then created another OES VM with eDirectory (just a base install of OES 23.4).

eDirectory (in iManager) is now listing the replica and says it has synced. Woohoo. This is after I had to do # ndsrepair -P -Ad to remove an old server from the Replica Ring (this would be good to include in the help - I found a 16 year old post for this fix). 

I may be able to get past the eDirectory upgrade now (I hope)

What would be good is to be able to upgrade to 24.1 in one go but for that I need an activation code. Looks like OT needs to set up some redundancy.

UPDATE:
Installation went fine using the new replica.

Greiner Claude said:

I hear since month, that the developer are working intensiv on this and the recommandation from OT is to "must" have a second oes-server for replica.

Today, I just encountered this issue on a fresh install of OES 23.4 (latest ISO) into a new tree. With updates, I'm at 24.2.

I Googled for more information but the only result is this forum post.

I assume this hasn't been resolved? Is there a TID or any other documents from OpenText about this issue?

do you have use the new iso for oes23.4 (download it on your customer center, had the same name, but newer version=

cg

SHA256 hash is the real test,  though if that is a fresh download from SLD, you should be good, as the newer one was slid in on GoodFriday

old = bfb4c847484fa7df24205fe9b618bf11d089a61175b300f61cdbedf23bcdf78f  

new = 6eb493dfeb53036c26a57af8838abaf009da0e8c1953da80ee7f50d0fbfe630b

There is also a small size difference, but only of ~2MB  or 2,097,152 bytes less on the newer one.

Andy Konecny said:

SHA256 hash is the real test

SHA256 hash of OES23.4-DVD-x86_64-DVD1.iso:
6eb493dfeb53036c26a57af8838abaf009da0e8c1953da80ee7f50d0fbfe630b
CertUtil: -hashfile command completed successfully.

So I do have the latest version. Is it supposed to contain the fix for this issue?

I doubt, that it contains a fix for this issue.

This is really more than a small annoyance. If you let the eDir upgrade work freely, you afterwards need to check the /etc/nam.conf file, if there wasn't replaced the local server with the edirectory replica server. I once had this situation after an upgrade on all servers in the tree, and now always check that afterwards. In the last upgrade I did not see that, but this upgrade had much manual intervention necessary.

Kevin Boyle said:

So I do have the latest version. Is it supposed to contain the fix for this issue?

I didn't see anything about this being addressed in that little update.  This issue sounds like a much bigger thing to fix because they assumed that nobody has single tree/server OES systems.  The only work around that I know of is as mentioned, you need another eDir box in the tree as the master for the upgrade, even if you only have there temporarily.