Moving your GroupWise PostOffice to a new server
07/09/07 17:45 Filed in: Novell
So
for one reason or another you need to move your
GroupWise post-office to a new server. I have used
the following process with GW7 but there should be no
reason you can't use it with version 5.x and 6.x. The
key is to do it in a test environment first, in case
things turn pear-shaped. If your GroupWise system is
using UNC paths for access links between the agents,
I recommend you change this now to TCP links. The
GroupWise documentation
covers
this.
You're going to need to bring down the MTA and POA to do this so pick a time when people aren't needing the system urgently.
We work in I.T. We're used to doing the late shift... aren't we?
First things first. Know a little about your GW system. Are your POA's, MTA's etc configured for TCP links or UNC paths? Also know where your log files are currently going and where to change this information.
1. Shutdown the MTA and POA. If you have more than 1 post office in your domain, shut the others down also.
2. Copy the PO data to the new location.
You can use whatever you like. I'm lucky, my PO resides on a SAN LUN so it can be easily pointed at any server with a HBA. But you can use XCOPY, DBCOPY, even the Server Migration Utility. While the copy is occurring carry on with the next steps.
3. Edit the post-office object in ConsoleOne and change the UNC path to reflect the new location.
4. Edit the post-office agent in ConsoleOne and change the network address to reflect the new server. You can also change the port if required. Check the log file UNC path to ensure it's still valid and change if necessary. I like to keep logs local to the post-office so I change this to reflect a path on the local server.
5. Select the Domain MTA and edit the Link configuration of the post-office in ConsoleOne to reflect the network address and port of the new server. Save this.
6. Edit the links for your Web Access Gateway if you use it, to reflect the new server network address. Save this.
7. Edit the links for your GWIA to reflect the new server network address. Save this.
8. If your NGWNameserver DNS entry points to the old server, make sure you update this information if required.
9. Load the MTA for the domain if the data copy has completed.
10. Rename and rebuild all post-offices in the domain and reload the agents on their respective servers. (I have two post-offices in the domain and until I had rebuilt the second post-office it wouldn't redirect clients to the moved post-office)
11. From the MTA Agent screen press F10 and view the configuration information. Ensure it reflects the changed network address/port of the new server for the PO in question.
12. Test.
As mentioned previously I assume the use of TCP links rather than UNC between the different agents. If you use UNC paths the process is the same except you will need to ensure the /USER-userid has the required filesystem rights to the new post-office location.
LINUX. If you're running your GW system on Linux the process is the same. But rather than use the MTA agent screens that appear on NetWare, you will need to use the web consoles for your agents.
I highly recommend you run up a test environment and test your proposed course of action.
You're going to need to bring down the MTA and POA to do this so pick a time when people aren't needing the system urgently.
We work in I.T. We're used to doing the late shift... aren't we?
First things first. Know a little about your GW system. Are your POA's, MTA's etc configured for TCP links or UNC paths? Also know where your log files are currently going and where to change this information.
1. Shutdown the MTA and POA. If you have more than 1 post office in your domain, shut the others down also.
2. Copy the PO data to the new location.
You can use whatever you like. I'm lucky, my PO resides on a SAN LUN so it can be easily pointed at any server with a HBA. But you can use XCOPY, DBCOPY, even the Server Migration Utility. While the copy is occurring carry on with the next steps.
3. Edit the post-office object in ConsoleOne and change the UNC path to reflect the new location.
4. Edit the post-office agent in ConsoleOne and change the network address to reflect the new server. You can also change the port if required. Check the log file UNC path to ensure it's still valid and change if necessary. I like to keep logs local to the post-office so I change this to reflect a path on the local server.
5. Select the Domain MTA and edit the Link configuration of the post-office in ConsoleOne to reflect the network address and port of the new server. Save this.
6. Edit the links for your Web Access Gateway if you use it, to reflect the new server network address. Save this.
7. Edit the links for your GWIA to reflect the new server network address. Save this.
8. If your NGWNameserver DNS entry points to the old server, make sure you update this information if required.
9. Load the MTA for the domain if the data copy has completed.
10. Rename and rebuild all post-offices in the domain and reload the agents on their respective servers. (I have two post-offices in the domain and until I had rebuilt the second post-office it wouldn't redirect clients to the moved post-office)
11. From the MTA Agent screen press F10 and view the configuration information. Ensure it reflects the changed network address/port of the new server for the PO in question.
12. Test.
As mentioned previously I assume the use of TCP links rather than UNC between the different agents. If you use UNC paths the process is the same except you will need to ensure the /USER-userid has the required filesystem rights to the new post-office location.
LINUX. If you're running your GW system on Linux the process is the same. But rather than use the MTA agent screens that appear on NetWare, you will need to use the web consoles for your agents.
I highly recommend you run up a test environment and test your proposed course of action.