hello Anders, why updgrade to OES2018 when the actual OES is 24.3, i can you give name of OES-Specialist that will help you to assist you by your migration for older systems as oes, gw, gms and other.

if you are interrest, send me a private message, i am now retired after more then 46 years in IT and i have a good network that is able to assist you!

Good luck! 100% winners have take there chance!

In addition to the trustee and data (+home directory), depending on the services deployed, you may have to consider moving them as well (replica, ca, driver store, print manager, etc). To replace cluster nodes:

https://www.microfocus.com/documentation/open-enterprise-server/23.4/clus_admin_lx/t486spmgv9j5.html

https://www.microfocus.com/documentation/open-enterprise-server/23.4/clus_admin_lx/ncs_multiple_node_addback.html 

No clusters. But let me elaborate:

1. Make sure the server to-be-replaced is not the master of any replica

2. Make a copy of the VM

3. Backup trustees

3. Remove the replica

4. Unistall ds

5. Shut down server

6. Clean up DS, ie remove all server-specific objects pertaining to this server, ie certs, iprint etc

7. Install new server with same name

8. Move over data volume image(s) from old server to new, make them visible in NSSMU, import to DS or if that fails create the volume objects manually.

9. Restore trustrees.

Hi Anders,

I need to do the same with my servers. My plan is to add a new 24.3 server to the existing tree, make it the master replica, transfer services from the old server, then decommission the old server. Yes, the server will have a new name and a new IP address but they are all private addresses and I can add the hostname and IP address into my DNS before I deploy the new server.

If the new server is in the same tree, you don't have to worry about trustees. If your NSS files are on their own device, just attach a copy of the virtual disk to your new VM. The other thing you can do is a pool move where everything is transferred over intact.

There may be other things to do. Depending on the age of your existing servers, you may want to recreate your CA and generate new certs. DNS and DHCP are pretty easy. If you use iPrint, there are some tricks to move it pretty much transparently.

The User Hoe Dir attribute is an important thing to consider. Another question is the tree CA and the topic Master on NDS Tree, SLP and other funny things from the OES area. For iPrint recovery, or also recovery from OES DNS or DCHP, there is KM from OT.

Another thing to test in the lab is what happens if you follow the instruction "remove a crashed server from the NDS" and deliberately leave the NSS objects in the tree, install new server, mount nss and so on.

Another possibility is the Migration Wizzard from OES. However, this has a problem at the end that still exists today. He simply forgets the rename of the nss admins

I don't want to get ahead of myself here, you have to do it yourself in the lab to learn. My method is a very hard one, but it requires experience. I recreate an OES server in the lab with the same IP and name. I then copy the NDS of the source system and copy the NSS volumes in such a way that the target system has access. Than back in die org. NDS and NDS Healt ChecksAfter the reboot, the system is actually the carrier of the NDS of the target system and, ideally, has mounted the NSS volumes. But here, too, it only works with practice.

A solution that has been best practice in my field for years works with nbackup into a pipe and out of the pipe into a target system. With Nbackup there are really many possibilities, even today it is still possible to go from Novell Netware to OES 24.3 without having to pull up. Once the backup is complete, the name and ip of the two servers can be swapped. The keyword here is e.g. ndsd.conf. For me this is a finger exercise because I have been doing this for years, my largest cluster systems I have moved had half a petabyte of NSS data. Whereby the migration of clusters is less critical than some people think. Of course, everything I have presented here requires fine-tuning.

BTW, it is part of an emergency manual and part of NIS2 to have such cases as described here and as a task to master
I apologize for writing in a casual way, but to be very specific I need to have access to the systems  


George

Yes. The actual procedure will depend a lot on what services that server hosts and yes, been there, done that. If you do not clean up old DS objects you will NOT be able to install a new server with the same name. 

Yes. That is my path. I already have done that on a replica server that hosted nothing but Apache. It is now running 23.4 and is the master. I kept the old name and basically removed it cleanly and then removed the server-specific DS objects, which is a royal pain in iManager, was so much easier in NWAdmin :) There is an install gotcha where NSS (if used) will not load if you have secure boot selected, there is a TID about that.

Therefore, the new server with the same IP and name is set up in a remote quarantine network and patched so that both the source and the server in the remote network have the same status. There is an article from NetIQ that discusses the recorvery of servers that hold a DS replica and what to do to move the DS data from a to b. For me this is a normal thing to do. In my environment it is even the case that I go other ways here, in necessary situations I even run several instances of replicating different OES servers on one OES server in order to be able to carry out repairs or other work. Running multiple instances on one system is described in the NetIQ documentation for eDir. Disaster recovery instructions are also available for the other services.

Sometimes I had the situation in the field that an OES starts in emergency mode for whatever reason. In such a case, I mount the faulty OES on an emergency system and copy out the necessary configuration files and also the DS data. Afterwards, I correct the errors or sometimes also move data from a functioning OES to the system, move the config data of the system back again and start the system.
From field experience, I really recommend practicing such situations in the lab. Even if there are only 3 servers in an NDS or a GW system consists of a single server.

Anders Gustafsson said:

There is an install gotcha where NSS (if used) will not load if you have secure boot selected, there is a TID about that.

I heard about that but then forgot about it. There are just too many gotchas to remember!

You are correct. The trustees remained when I checked after the upgrade.