Last week someone ran a 'declare a new epoch' on one of our servers for
multiple partitions, not knowing that the master server was triggered to
switch all replica's to the new state.
Because we had multiple bordermanager servers running in the same tree,
guess what happened:

YES, the bordermanager master server failed to connect to all of our branch
offices and ofcourse it did not start anymore, because the r/w replica was
set to new state.
Because of this no more communication was possible and some sites could not
So there we were: middle in the night with an edirectory with multiple
partitions and allmost all replica's set to a new-state. After a few days,
transfering some hardware from branchoffices to our mainoffice and creating
a whole new vpn to get the synchronization back to work, we finally got
edirectory ok.

This is more then a reason to get rid of the bordermanager's dependancy of
the scmserverobject in edirectory. It could save us a lot of trouble/money.
Was there by the way (probably not, because no one at Novell TechSupport
could tell us), for the master vpn server to contact the server with the
master replica ? It was on the same site in the same tree and in the same
It refused to check there, but only checked it's own r/w replica.
We upgraded from sp3 to sp4 and ir3, but unfortunately bordermanager still
did not want to start.

Anyone any thought on this?