3) Build a new SLES12 VM, install the binaries, down the old box, detach the VMDK holding GW data from the old box, attach it to the new box, move the secondary IP over to the the new box (or add the / replace with the primary, whatever your agents currently listen on), create the / place copies of the config files, run the upgrade. (assuming we're talking of plain SLES as opposed to OES)

Basically all approaches wil do it. With 2) you'll have a pretty short downtime (assuming the dbcopy way) and keep the old system intact. Handy if little purple monsters rush into the building. With 3) you'll have even less downtime, but you'll have to (i.e. you should) prepare another sort of fallback plan.

In article <bkesting.8fbqsn@no-mx.forums.microfocus.com>, Bkesting
wrote:
> 1) Upgrade inside existing VM?
>
> 2) Build brand new SLES 12 VM and then copy over postoffice and domain
> data and build GW2018 from scratch?

What is your Hypervisor?
The vmware vote appears to be for #2
https://kb.vmware.com/s/article/2018695
check out the OES Installation forum for more of the fun on this topic

In the process of figuring out the same set of upgrades, I think I'll be
working a few of the long weekends this year.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

mathiasbraun wrote:

> With 3) you'll have
> even less downtime, but you'll have to (i.e. you should) prepare
> another sort of fallback plan.

It's always a good idea to keep your domain and post office on its own
virtual disk. That way, you can assign a separate disk controller for
slightly better performance. In some cases it cam be a higher
performance disk controller than is used on the disk that hosts your
OS. If necessary, you can even use higher performance storage to host
the virtual disk. Perhaps all this is unnecessary but you would have
the ability to do it.

With your GroupWise data on its own virtual disk you can quickly down
your system and clone the virtual disk to create a full backup much
more quickly than copying files. It's always a good idea to have a
couple of good backups before attempting anything out of the ordinary
and that includes attaching a virtual disk to a new VM. By using a
copy, your original system remains intact for a quick fallback should
it become necessary.

Attaching the virtual disk to the new VM is the quickest way to get the
data there. If your existing system doesn't currently have your
GroupWise files on its own virtual disk then I suggest shutting down
the current server running GroupWise and attach its virtual disk to
your new server in order to copy over the files. Copying files between
two disks on the same server is considerably faster than copying them
across the wire. It isn't necessary to use dbcopy in this situation.
You can use whatever copy utility is available. And, of course, you'll
want to copy them to their own virtual disk which you can then mount
anywhere you need it.

If you are using VMware, their official position is that they don't
support upgrading the OS in a VM from one major release to another and
suggest that you create a new VM to accomplish the upgrade. Upgrading
from SLES11 to SLES12 is considered a major upgrade from VMware's
perspective.

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.

konecnya;2478762 wrote:
In article <bkesting.8fbqsn@no-mx.forums.microfocus.com>, Bkesting
wrote:
> 1) Upgrade inside existing VM?
>
> 2) Build brand new SLES 12 VM and then copy over postoffice and domain
> data and build GW2018 from scratch?

What is your Hypervisor?
The vmware vote appears to be for #2
https://kb.vmware.com/s/article/2018695
check out the OES Installation forum for more of the fun on this topic

In the process of figuring out the same set of upgrades, I think I'll be
working a few of the long weekends this year.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

I am using Hyper-V as my hypervisor.

In this case i'd vote for option 2b) which is basically option 2) along with the fresh VM running on another hypervisor.

In article <bkesting.8ffenb@no-mx.forums.microfocus.com>, Bkesting
wrote:
> I am using Hyper-V as my hypervisor.

While I can't find the same recommendation as vmware did, I believe the
same logic still applies with any hypervisor as the guests are built
with a set of assumptions that are different enough between major
versions that it is just safer to do the migration.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

What's the best way to upgrade Mobility?

In article <bkesting.8fgy7b@no-mx.forums.microfocus.com>, Bkesting
wrote:
> What's the best way to upgrade Mobility?

Thats easy, especially if you have a purchased cert. Build the new box
with the newest versions. Set it all up so that it can do its sync of
the users. Once that is all happy, move the cert over from your
previous box and flip the DNS/NAT to the new box. Then the users
devices will connect to the new box as if nothing has changed and away
they go.

If you don't have a purchased cert, this is a good time to play with
LetsEncrypt to escape any of those issues that really want a public
root CA tied cert. I've used this as part of migrations to SLES12 very
successfully.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

So in conclusion as I'm about to do a test GW 2018 install..............I can just install the GW 2018 software on my test SLES 12 box, don't "configure it" just yet, copy over postoffice/domains from old system, and then upgrade those using the GW2018 installation tool?

bkesting wrote:

>
> So in conclusion as I'm about to do a test GW 2018
> install..............I can just install the GW 2018 software on my
> test SLES 12 box, don't "configure it" just yet, copy over
> postoffice/domains from old system, and then upgrade those using the
> GW2018 installation tool?

More or less...

You have the general idea but your domain and post office contain
configuration information that refers to your existing (live?)
GroupWise system. You want to make sure GroupWise 2018 doesn't try to
use that information to interact with your GroupWise 2014 system.

The best way to do that is to make sure your SLES 12 box can't talk to
your SLES 11 box by either shutting down your SLES 11 box or by
disconnecting your SLES 12 box from the network.

--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.