How Dave Does It: GroupWise Consolidation - Moving GroupWise over the WAN
Novell Cool Solutions: Trench
By Dave Muldoon
Digg This -
Posted: 5 Mar 2003
This is the fifth article in this series regarding consolidating your GroupWise system. The first four articles reviewed consolidation project guidelines, potential impact to the end users and monitoring user moves for potential problems. This article will give you an alternative process for moving massive amounts of users over WAN links all at the same time.
Removing the WAN from the GroupWise Move Process
This process requires the use of a server that I refer to as a "staging server". The server is basically an extra server that is configured specifically to run GroupWise Post Offices/Domains and has no other application or uses. This entire process revolves around swapping Post Offices from one server to another. To use this server and method, you follow a process similar to this (but more detailed - and I'll give the details of course):
- Stage the server in your centralized location with backup device connected.
- Backup the remote location locally.
- Restore the data to the server at the centralized location - locally (that's the key).
- Then if the need is still there to move the users off of the moved Post Office to a different one at the central location, the traffic is all local - and fast.
Sounds easy enough right? Well, I'll provide more details in case you want to use this method?
Staging ServerThis server should be adequately sized to accommodate the remote Post Office that is being moved to this server. Make sure you have enough disk space (and then some). Also note the following:
- Staging Server's IP Address. This will be used before the backups are taken at the remote location.
- Also make sure that the Staging Server's anti-virus configuration is configured so that the volume that will be used to service GroupWise data is not scanned during the restore. I also recommend that this volume is not scanned at all unless using a product specifically designed for GroupWise. Even if using a product specifically designed for GroupWise - turn it off during the restore, so that the server has the resources for the backup application.
- Also, keep handy the obvious stuff like server name, volume and intended directory path/structure for the GroupWise agents being moved.
Prep and backup the remote location
Before going through this procedure, take note from the Post Office Agent's IP Address tab if the address is a DNS name or IP Address. NOTE: If the users access the Post Office via a DNS name (i.e. POST1), the end users should not even be aware of this move if things go as planned.
Using the information that was gathered for the Staging Server, run through the following process. It's really rather simple, but it saves a lot of time and headaches once you're ready to activate the GroupWise Agents on the Staging Server.
I like to follow this process without deviating from it. I actually go so far as to make check marks after completing a step, because if a step is skipped or done out of order, it will cause a lot of work later - when you'll be much less awake. This process is simply modifying the POA Object that is going to be relocated. NOTE: This procedure is for moving ONLY a Post Office. If you're moving a Domain at the same time, I'll add a couple notes at the end of this section with some additional items to supplement this process.
- Connect to the Primary GroupWise Domain.
- Change the path statement on the Remote Post Office Agent to the Staging Server name and directory structure (based on the information gathered from the Staging Server).
- Synchronize the Post Office Object.
- Change the IP Address field on the Remote Post Office Agent to that of the Staging Server.
- Synchronize the POA. (Wait 5 minutes after this before continuing to the next step).
- Synchronize the Domain object.
- Wait 5 minutes before continuing on to the next step.
- READ CAREFULLY: Remotely connect to the server that contains the GroupWise Domain that owns the Remote Post Office that was just modified. Look at the Message Transfer Agent screen to verify that the Remote Post Office is showing as closed (it should be closed at this point). You can also verify this through the F10 menu and Configuration Statistics menu option, and seeing the Remote Post Office is accessible at the Staging Server's IP address.
- After the above step is verified, reconnect to the Remote Post Office server. From the server console (of the Remote Post Office Agent's server) shut down the POA (F7 and say yes - you'll have to disconnect all the users if they haven't already been disconnected).
- NOTE: At this point a LOCAL backup job can be started. Just to be clear, this a backup job that is run against the remote Post Office data structure, from a backup server in the remote location.
In recap, the process above has made changes to the GroupWise POA, telling the POA and the Domain that owns the POA that the POA is located on the staging server and is communicated to on the Staging Server's IP address. Of course, at this point, it's all a "lie" and the system says the agent is closed - that's the intention. After the restore is finished on the Staging Server, the Post Office will load without any problems and the system will immediately recognize that it's up and treat it normally.
If there is a Domain that is on the remote server and it is to be moved, you must add these steps to the above process. NOTE: This should only be done while connected to the Primary Domain (and this process is different if moving the primary domain, the two MTA items are reversed in that situation).
- After changing the POA IP address, verify the remote domain sees the POA as closed, then move on to the following:
- Change the MTA directory path to that of the Staging Server and directory structure that you will use for the Domain.
- Synchronize (wait 5 minutes).
- After waiting 5 minutes, change the MTA's IP address, synchronize and wait 5 minutes.
- Instead of connecting the owning domain, connect to a different secondary, assuming that you have one and verify that it sees the remote domain as closed. Connect back to the remote server that contains the agents that have been modified. Then shut all agents down on the remote server and begin the backup process.
What to do during the backup
Sorry, it's not naptime. During the backup, it's usually best to grab copies of the GroupWise startup files off of the remote server and do a little cleanup.
Go into the server's SYS:system directory and check the autoexec.ncf. See how GroupWise is called (most likely "startgw"). You should comment this line out so that the server doesn't try to load against the old data set. But grab a copy of the startgw.ncf so that it can be dropped on the Staging Server.
Edit the startgw.ncf (if that's what you found was calling GroupWise) and see what this file calls (most likely grpwise.ncf). I like to comment out the line in the stargtw.ncf too. I usually comment out the line and put a note about the location being moved/consolidated. Grab an unedited copy of the grpwise.ncf too, so that it can be used on the Staging Server.
Edit the grpwise.ncf and see what files it calls. I'm guessing this portion is going to be customized, but will reflect something like load GWPOA @POST1.POA. Grab a copy of POST1.POA (or whatever the file is called). Take a copy of this file too, but this file will need to be edited to make it useable on the Staging Server. Things you should edit are the "home switch" (/home-VOLUME:\directory_path), and any specified IP addresses or ports that are active in the file. Use those of the staging server. NOTE: If a domain is involved, gather the domain files too and follow the editing suggestions for the POA file.
Now all of these files can be moved to the Staging Server's SYS:system directory. But, you're still not done?
If you were lucky enough to have the users connect to this Post Office with a DNS name, you will need to change this name to reflect the Staging Server's IP address. After that, start watching the backup job - make sure nothing has stopped it and that the speed it's running at is adequate for your change window. You may also wish to double-check that the Post Office is still unloaded (I've seen cases where other support areas see the outage and re-load the agents before the files can be edited/deactivated).
The backup is done? now what?
This portion involves some pre-planning. You need to work out the logistics of getting the tape(s) from the remote location to the centralized location - in a hurry (don't get caught speeding - I'm guessing your employer won't pay for the ticket). There are options here; if the location is actually close enough to drive, go get it. It can be couriered through a local delivery service. Maybe it can even be shipped overnight or next morning, etc. if it fits your timeframe. Whatever you do, keep this window as short as, possible, as the rest of the system is still storing communication to this Domain/Post Office and it's users. And no matter what, don't launch GroupWise at the remote location unless you're aborting the change. Once the remote system comes up again on the remote server, the entire process has to be started over. But this is the good part of the whole process, if something goes wrong, you just need to revert the changes to Agent paths and IP addresses and rebuild the databases (along with fixing the startup files).
Okay, however you got the tapes to your central location, you can start the restore process. Not much goes on at this point, other than the restore process. You still should monitor the process with your eyes open. There's nothing worse than waking up with Post-It Notes stuck to your face and seeing the restore job failed at 35% and it now needs to be restarted.
The restore is done
This is the big test; launch GroupWise on the Staging Server. If you followed everything here and the data was backed up and restored without corruption, the agent(s) should load and the rest of the system should pickup the fact that this agent came back online within a few minutes. You'll see the items that were queued up come in and get processed, and that's a good sign too.
Before leaving the office, do yourself a favor, connect to a few other GroupWise Agents and make sure that they see that the agent you just brought back up is open. Don't rely solely on one agent. Check a few. You may have to check some Link Configuration settings if you see problems. Don't forget about the GWIAs and the other gateways like Web Access. Make sure that those agents are seeing the proper connection address for the agent that was moved.
Lastly, update any monitoring agents. I know that this seems like something that can wait, but if you receive alerts for problems, this would be a really good time to have the system monitored. There really should be any problems, if the agents came up, but there's no reason to take chances.
That's it - at this point in the procedures a larger number of users have been moved over the WAN in a short amount of time, without much risk at all.
Some other options and brief items worth noting
There are few things that I think you should consider with regard to this process. Some of them may be things that you would consider doing if you don't have an "extra" server to use as a Staging Server. For example, the entire server could be moved. Of course there would be server specific items such as changing the server's IP Address configuration to one that can be used in the central location. And possibly pulling the server out of DNS due to NDS replica issues, then putting it back in at the central location, in the appropriate replica. Of course, I can't provide all of this information, these are just some thoughts that you may want to research or review.
Now, if the Staging Server is a possibility for your organization, you are possibly in a position after this change that leaves the remote server unused. This is based on the possibility, that the server at the remote location was only used for GroupWise. If that was the case, the remote server that can be de-installed from the network and the hardware used as a Staging Server at the centralized location to be used to bring another Post Office (and possibly Domain) back to the central location. There is also the possibility that the server can be upgraded, adding things like RAM, disk, faster controller, etc.
And finally, I don't want to overlook the idea of using a pilot group. It's always a good idea to pilot a few users to make sure the access methods across a WAN are capable in providing acceptable performance and response times. Move a few users over the WAN to an existing central Post Office and get some feedback. This is also a very important pre-planning step in all projects.
This article is a different method of performing the process that was outlined in my last article. This process is not always something that can be done. It seems that there is always a need to move user accounts for one reason or another. At a minimum, this process can get your remote Post Offices and users closer to the location that you wish to use as the consolidated system (hopefully the same LAN), so that moves are more efficient.
My next article will cover server configuration items that I've come across during research and development that I've found to be very useful when dealing with GroupWise and server performance. Especially when servers are dedicated to GroupWise.
Watch for more articles by Dave Muldoon, every couple of weeks, under the resources link on GroupWise Cool Solutions - http://www.novell.com/coolsolutions/gwmag/features/trenches/tr_how_dave_does_it_gw.html.