Move GW8 from Netware to Windows Server 2022

Hi,

after digging through the documentation and this forum from my understanding the best way is installing the GW18- or GW24-server-software on the Windows Server to have the new DBCOPY.EXE at hand, then use this DBCOPY.EXE to copy domain, post-office and storage-area from the Netware-server to the Windows-server. Then - maybe, not sure about this step - run the new GWCHECK.EXE against the copied  system and finally use the GWADMIN on the Windows-server to do the upgrade of the copied system including installation of the MTA and POA. After this point I would start correcting the settings like IP-address, platform (Windows instead of Netware) etc. with GWADMIN on the Windows-server. I will not correct the settings with ConsoleOne due to the - from my view - lesser integration of the new GW with eDir.

Or is it neccessary to first throw the GW8-server-software on the Windows-server, have this running and then do an in-place-upgrade?

Regards

Karl

  • 0  
    Or is it neccessary to first throw the GW8-server-software on the Windows-server, have this running and then do an in-place-upgrade?

    Please refer to the GroupWise Server Migration Guide

    The documentation states that migration and upgrade are two separate and distinct processes.

    Andy, I'm sure will have more to say. :-)

    __________
    Kevin Boyle, SuperUser

    Calgary, Alberta, Canada

  • 0  

    Going direct to the newest (GW24.2 at this point) is your best bet (GW18 is just running out of support). GW8 software on Win2022 is pushing things rather far, for little gain. That path also gives you the cleanest fallback if there are issues along the way, where you've done nothing to the old system, while working on the new, and if it kabooms on you, you just fire the old system back up.  

    Make sure you are running the full set of GWChecks on the existing system, having set them as scheduled maintenance, and make sure those logs aren't showing any problems that need attention up front.  Those settings will carry forward with the migration, though checking them after isn't a bad thing.  If you haven't had much running in regular GWChecks, then running some manually up front is a good thing.  Start with Structural only Analyze fixes until they are clean (i.e. deal with issues found) before moving on to the full Context GWChecks.

    Kevin's comments came in about here as I was typing this ;)  and are good additional things to read.

    The newer GroupWise is rather picky about certificate details. We have to make sure the host name of the GW service/agents is FQDN, in both the local hosts file AND in DNS for on the new system.  It does make future moves easier if GroupWise agents are running on their own IP as separate from the server they are running on. Then you just shift that secondary IP to the new host, that simplifies so many things, oh, I just wrote about that.  This might be a point where making that split on the source box might make life easier moving forward, or just using the old host's IP as the new secondary IP that you only activate at that point you run the upgrade process.

    I'm sure you will have more questions as you dive in reading all of this, and we are here to help.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    This "picky about certificate details" is why I tended to give GW18.5 a shot in my test-lab. The last tests with GW24.2 caused some grieve when it comes to get things connected together with LDAP and certificates. GW18.5 failed as GW24.2 before, the POA did not start at all, no matter what I tried (removing library, deleting and setting POA up again). No chance. So I will rebuild my test-lab for GW24.2 and be back here again. I miss this rock-stable tight integration of Netware/eDirectory/GroupWise.

    Regards

    Karl

  • 0   in reply to 

    Picky GW certificates started with GW18.4 I think - so try GW18.3 Innocent


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to 

    The pickiness with certs came in on 18.4, and is pretty much stable on that front since.  Basically, our path from not really caring much about those certs to demanding it be done correctly was at the switch to 18.4. We have all had to learn about all the things needed to get certs correct.  So there really isn't a point in not going straight to the newest.   

    Was your test with a new system or a copied system?   If copied, make sure you do a dbcopy run with the source agents down to be 100%   it is possible you have some issues on the source that needs the appropriate GWChecks done on them first. 

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    Andy,

    so I will not bother with the older versions and go for GW24.2.

    I am testing this on a mirrored/copied test-system all the time, what gives time for trial and error.

    All the GW8-agents are shut down when the DBCOPY-job gets started.

    Would you advice doing the GWCHECK with the old version in the old system before DBCOPY? Or should this be done after DBCOPY on the new system with the new GWCHECK?

    Regards

    Karl

    Would you advice doing the GWCHECK with the old tool on the old system after shutting down all the agents

  • 0   in reply to 

    GWchecks are smarter before activities.

    I prefer a two step approach because if you fail you do not know why. Did you fail because of copying data or because of using the newer version ...


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to 
    Would you advice doing the GWCHECK with the old tool on the old system after shutting down all the agents

    Let the GW8 POA do the work overnight. You can schedule the jobs as per the link I gave earlier, and also kick them off manually from within ConsoleOne.  Making sure they send the results to an appropriate account you have access to.

    The standalone GWCheck we tend to leave for when it is really needed.

    You should have the regular scheduled maintenance running to keep your system healthy, so checking those logs is a very good start. Of course, finding them may be your first challenge, you get hints from looking at what is already scheduled.  They may just be going to the system defined admin, and their subjects aren't the most.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    And going from GW 8 to GW 24.2 directly does work, as the settings have to be moved from Edirectory (GW 8.0) to the Groupwise database (GW24.2)?

    My last netware server with GW agents was shutdown permanently on August 1st 2011, so no experience on later moves.

  • 0 in reply to   

    Did the shutdown, ran standalone-GW8-GWCHECK with no real errors, did the GW24.2-DBCOPY, then standalone-GW24.2-GWCHECK. That gave quite some correctable errors regarding "access" and "proxy" on the first run. Got it corrected with follow-up-runs and after this the install-/upgrade-routine of GW24.2 resulted in MTA and POA up and running. Starting a GW8-client against the migrated system worked, so I wiped the test-system to start from scratch again.