Upgrading to GroupWise 2018 from 2014 R2

We have a relatively small installation of GroupWise at our agency (around 200 active users) and I am preparing to perform an in place upgrade of SuSE 11.4 to 12, then an in place upgrade of GW2014 to 2018. I am testing and so far everything is working out as I figure out and document the little bugs/caveats I run into. We want to use Mobility for our external users to sync their devices to the post office and integrate the new Messenger as well. My question is this, can I install the Mobility portion on the Webaccess server and the Messenger portion on the GroupWise email server so my foot print stays at one server?

Thanks!
  • In article <smkornegay.8wypyo@no-mx.forums.microfocus.com>, Smkornegay
    wrote:
    > I am preparing to perform an in place
    > upgrade of SuSE 11.4 to 12, then an in place upgrade of GW2014 to 2018.

    I'm assuming you mean SLES as to differentiate from SLED and anyother SLE
    (SUSE Linux Enterprise) or OpenSUSE.
    A) Is that GW 2014 or GW 2014R2? The later supports SLES12, the former
    didn't quite make it, in which case you will want to do the GW upgrade
    first.
    B) Is this direct on hardware or is this virtualized? If virtualized, it
    is generally not recommended to make such major version upgrades of the
    guest OS but to migrate the resources to a new vm.

    > We want to use Mobility
    > for our external users to sync their devices to the post office and
    > integrate the new Messenger as well. My question is this, can I install
    > the Mobility portion on the Webaccess server and the Messenger portion
    > on the GroupWise email server so my foot print stays at one server?

    At the very least you run into port contention as Mobility MUST BE on port
    443, and Webaccess really wants to be on port 443 or you have to do some
    juggling to get your end users to it.
    If you have a virtualized environment, you'd easily be able to spin them
    up on their own boxes that makes them so much easier to manage and
    troubleshoot.



    Andy of
    http://KonecnyConsulting.ca/gw in Toronto
    Knowledge Partner
    https://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!

  • konecnya;2496893 wrote:
    In article <smkornegay.8wypyo@no-mx.forums.microfocus.com>, Smkornegay
    wrote:
    > I am preparing to perform an in place
    > upgrade of SuSE 11.4 to 12, then an in place upgrade of GW2014 to 2018.

    I'm assuming you mean SLES as to differentiate from SLED and anyother SLE
    (SUSE Linux Enterprise) or OpenSUSE.
    A) Is that GW 2014 or GW 2014R2? The later supports SLES12, the former
    didn't quite make it, in which case you will want to do the GW upgrade
    first.
    B) Is this direct on hardware or is this virtualized? If virtualized, it
    is generally not recommended to make such major version upgrades of the
    guest OS but to migrate the resources to a new vm.

    > We want to use Mobility
    > for our external users to sync their devices to the post office and
    > integrate the new Messenger as well. My question is this, can I install
    > the Mobility portion on the Webaccess server and the Messenger portion
    > on the GroupWise email server so my foot print stays at one server?

    At the very least you run into port contention as Mobility MUST BE on port
    443, and Webaccess really wants to be on port 443 or you have to do some
    juggling to get your end users to it.
    If you have a virtualized environment, you'd easily be able to spin them
    up on their own boxes that makes them so much easier to manage and
    troubleshoot.



    Andy of
    http://KonecnyConsulting.ca/gw in Toronto
    Knowledge Partner
    https://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!


    Thanks Andy! I've tested the upgrade and had to remove a legacy file to get gui to work properly. How is virtual so different from hardware as to warrant creating a new VM and migrating GW over? How would one even do that?

    Great advice about port 443. I will spin up a small vm for the mobility addition.
  • It's an unsupported operation from the VM Host provider (VMware). They don't support in place OS upgrades. I have done it in the past (by accident) and not had issues, but the VM vendor doesn't support it if it blows up. From the SLES OS point of view they have a supported OS upgrade path from SLES11 to SLES12, but it depends when the OS is running on.

    Mark
  • smkornegay;2496871 wrote:
    We have a relatively small installation of GroupWise at our agency (around 200 active users) and I am preparing to perform an in place upgrade of SuSE 11.4 to 12, then an in place upgrade of GW2014 to 2018. I am testing and so far everything is working out as I figure out and document the little bugs/caveats I run into. We want to use Mobility for our external users to sync their devices to the post office and integrate the new Messenger as well. My question is this, can I install the Mobility portion on the Webaccess server and the Messenger portion on the GroupWise email server so my foot print stays at one server?

    Thanks!


    We are using Hyper-V. Maybe that is the difference. I believe SuSE and Microsoft have a very good relationship with virtualizing SLES 10 and up. The only issue I have seen with the upgrade is the gui goes away, but I found the fix (remove an obsoleted file:

    zypper remove --clean-deps libcroco

    I'm positive there is more cleanup, but in place upgrades are more convenient than moving the post office to a new server (IMHO).
  • smkornegay wrote:

    > but in place upgrades are more
    > convenient than moving the post office to a new server (IMHO).


    Hi,

    Here are a few other things to consider when creating a new VM or
    updating an existing one - regardless which hypervisor is used:


    When you create a new VM the default hardware (nic, storage adapter,
    etc.) are chosen to provide optimal performance based on the OS you
    specify. When you *upgrade* to a new "Major Release", very often you
    don't get the benefits of all the new OS capabilities as the upgrade
    process may try to maintain compatibility with existing filesystems and
    devices even though the OS supports newer, better performing, ones.

    GroupWise migrations from one physical device to another using dbcopy
    certainly were time consuming but in a virtual environment you have
    other options. If you store your domain(s) and post office(s) on their
    own device/LUN migrations are a snap. Just attach the device to your
    new VM and install the GroupWise software. If they are not on their own
    device, shutdown the source VM, temporarily attach the device
    containing the domain(s) and post office(s) to the new VM and copy the
    directories to their new location.

    Of course, the choice is yours. I just wanted to offer you some
    additional options.

    --
    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.
  • KBOYLE;2497033 wrote:
    smkornegay wrote:

    > but in place upgrades are more
    > convenient than moving the post office to a new server (IMHO).


    Hi,

    Here are a few other things to consider when creating a new VM or
    updating an existing one - regardless which hypervisor is used:


    When you create a new VM the default hardware (nic, storage adapter,
    etc.) are chosen to provide optimal performance based on the OS you
    specify. When you *upgrade* to a new "Major Release", very often you
    don't get the benefits of all the new OS capabilities as the upgrade
    process may try to maintain compatibility with existing filesystems and
    devices even though the OS supports newer, better performing, ones.

    GroupWise migrations from one physical device to another using dbcopy
    certainly were time consuming but in a virtual environment you have
    other options. If you store your domain(s) and post office(s) on their
    own device/LUN migrations are a snap. Just attach the device to your
    new VM and install the GroupWise software. If they are not on their own
    device, shutdown the source VM, temporarily attach the device
    containing the domain(s) and post office(s) to the new VM and copy the
    directories to their new location.

    Of course, the choice is yours. I just wanted to offer you some
    additional options.

    --
    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.



    This sounds really good and I will take this under advisement.

    The current configuration of the virtual machine is one large drive with partitions. One partition (grpwise/2TB (910GB free)) holds the following directories:

    domain
    lost found
    po

    Are these all I would need to copy to the new grpwise partition on the new server?
  • smkornegay;2497034 wrote:
    This sounds really good and I will take this under advisement.

    The current configuration of the virtual machine is one large drive with partitions. One partition (grpwise/2TB (910GB free)) holds the following directories:

    domain
    lost found
    po

    Are these all I would need to copy to the new grpwise partition on the new server?


    The short answer is: yes.

    I would suggest you use a dedicated drive for your GroupWise data. That way you can attach it to its own controller to reduce IO contention and make it easier to assign to a new VM. If you choose, you could even do this on your existing server to make your migration easier.

    I have written a Cool Solution that discuss various migration options you may find helpful:
    GroupWise Migrations – A Better Way
  • KBOYLE;2497037 wrote:
    The short answer is: yes.

    I would suggest you use a dedicated drive for your GroupWise data. That way you can attach it to its own controller to reduce IO contention and make it easier to assign to a new VM. If you choose, you could even do this on your existing server to make your migration easier.

    I have written a Cool Solution that discuss various migration options you may find helpful:
    GroupWise Migrations – A Better Way


    I am going to try creating another virtual drive, mounting it in the vm, and then copying the domain and post office to the new drive (after updating to GW 2018, right?). Then attach it to a new SLES 12 clean virtual machine and installing GW 2018. Thanks!
  • smkornegay;2497038 wrote:
    I am going to try creating another virtual drive, mounting it in the vm, and then copying the domain and post office to the new drive (after updating to GW 2018, right?). Then attach it to a new SLES 12 clean virtual machine and installing GW 2018. Thanks!


    I would suggest a slightly different sequence:


    1. Create a new virtual drive.
    2. Mount it.
    3. Shutdown GroupWise.
    4. Don't upgrade Groupwise.
    5. Copy over your domain and post office to the new drive. No need to use dbcopy. Any copy utility will do.
    6. Optional: You can use this virtual drive on the existing server. Just point GroupWise to the new location for the domain and post office or mount the new virtual drive to the same location where the existing domain and post office reside.


      When you are ready to upgrade:


      1. Shutdown your current server. You don't want it accessible while you are upgrading GroupWise on the new server.
      2. You don't want the GroupWise virtual drive attached to two running servers at the same time so disconnect the drive from the current server's virtual machine, just to be safe in case the VM is accidently started.
      3. Mount the GroupWise virtual drive to the location you want on the new SUSE Linux Enterprise Server 12 SP4 server.
      4. Install Groupwise 18 on the new server if you haven't done so already.
      5. Follow the steps to upgrade an existing GroupWise system as described in the GroupWise 18 documentation.


        Remember, migrating is separate from upgrading. Both steps are needed. Since you have to go through the configuration steps on the new server anyway (because it's a new installation), there is no point doing the GroupWise 18 upgrade on the current server beforehand.

        Make sure you have a backup. You can clone the GroupWise virtual drive and make sure the clone is not mounted anywhere while doing the migration and upgrade.
    7. KBOYLE;2497059 wrote:
      I would suggest a slightly different sequence:


      1. Create a new virtual drive.
      2. Mount it.
      3. Shutdown GroupWise.
      4. Don't upgrade Groupwise.
      5. Copy over your domain and post office to the new drive. No need to use dbcopy. Any copy utility will do.
      6. Optional: You can use this virtual drive on the existing server. Just point GroupWise to the new location for the domain and post office or mount the new virtual drive to the same location where the existing domain and post office reside.


        When you are ready to upgrade:


        1. Shutdown your current server. You don't want it accessible while you are upgrading GroupWise on the new server.
        2. You don't want the GroupWise virtual drive attached to two running servers at the same time so disconnect the drive from the current server's virtual machine, just to be safe in case the VM is accidently started.
        3. Mount the GroupWise virtual drive to the location you want on the new SUSE Linux Enterprise Server 12 SP4 server.
        4. Install Groupwise 18 on the new server if you haven't done so already.
        5. Follow the steps to upgrade an existing GroupWise system as described in the GroupWise 18 documentation.


          Remember, migrating is separate from upgrading. Both steps are needed. Since you have to go through the configuration steps on the new server anyway (because it's a new installation), there is no point doing the GroupWise 18 upgrade on the current server beforehand.

          Make sure you have a backup. You can clone the GroupWise virtual drive and make sure the clone is not mounted anywhere while doing the migration and upgrade.


        That looks like my plan moving forward. Thanks for all your help!

        I will reply back when it is completed.