Usually I would move a secondary domain. But in your case it is even faster to create a new secondary domain if your old domain does not have any data or additional function.

Do you have to take care of any data or settings around your Messenger? Archives, groups, ...

Thanks much. Messenger has no archives or groups to worry about.

Then a new installation will cause less effort. Maybe it depends a little bit on the detail how your users connect to Messenger. Via Groupwise, directly? If directly then use dns names instead of ip addresses. Makes life in future easier.

However, be aware of this TID:

portal.microfocus.com/.../KM000028441

I can only verify that based upon the TID I have decided not to waste time trying to do an install since to make it work would require engaging someone to modify the database.

You will very likely need to do that step, as seen in other customers' cases. Other than that, just keep using the same server where the Messenger was installed, as it does not require any heavy HW. Then, move only the GW domain to a new server.

As a final post, I decided to permit tech support to modify the database file per the TID. Doing so caused no disruption. The bad news is that the Messenger App (MA) was difficult to configure. I installed it on a fresh SLES 15.6 VM with all the features required in the 24.3 online documentation preinstalled.  The pre-config install went fine. All DNS features worked fine on the MA and Admin Service (AS) machines. Nslookup worked well, and the hostname reports were correct, etc. However, the AS machine did not like the SSL certificate tendered to it by the MA. [Error communicating with resource … hostname wrong … should be ____.] I was pointed to an old TID about how to resolve the issue. It did not help, but it recommended restarting the adminservice between connecting attempts. I followed the recommendation. || Since I was using a self-signed cert on the MA, I created one with the hostname FQDN and another hostname as the IP ADDR of the MA. I tried configuring the MA with FQDN and cert with FQDN. No luck; the same error was issued at the AS. [I tried allowing weak DB certs and not allowing, and allowing weak is what I settled on using.] The only configuration that worked was configuring the MA to use the IP as the hostname, coupled with the cert configured the same. The AS liked that combo, and the errors disappeared. The good news is that the new VM MA machine is very fast now that everything is configured, and the tasks needed to import GroupWise users through the admin console worked extremely well. Since there is no intent to use the MA outside the local network, I will not substitute commercial certs. I set the certs I created to live for 10 years, so hopefully, I will not have to configure for quite some time. Thanks to all who assisted on this project.

DH2 said:

I set the certs I created to live for 10 years, so hopefully, I will not have to configure for quite some time.

fingers crossed tight. There is a drive to reduce cert life spans to very short terms, and gradually that will impact the upstream code that Messenger and the servers in general use. We already hit that sort of thing with SHA1 signed CAs as far as ZCM interacted with. I had to rebuild all the eDir tree certs of a couple clients last Xmas break that had SHA-1 signed CA going out to as far as they could be done (2036)
Just a heads-up about that.