Revision for “Upgrading Your Post Offices” created on December 9, 2013 @ 23:53:44
Upgrading Your Post Offices
Upgrading your post offices is very similar to upgrading domains. There are just a few things to keep in mind about your upgrade:
So, as you can see, it’s a good idea to get your post offices upgraded to GroupWise 2012 on a scheduled roll-out so that you are not surprised by any of the possible issues with mixed post offices. That said, may sites operate in a “mixed” system quite nicely for an extended period of time. You must simply make sure that your plans take the above caveats into account.
How Does the Upgrade Work?
At the post office level, a GroupWise upgrade is really just a database conversion from one version to another. The former GroupWise post office database, is RECOVERED by the MTA’s administrative thread and CONVERTED to the new version. This requires three simple components:
We realize that this sounds simplistic, but it really is quite simple. When you upgrade your post office, you are simply recreating your post office database to be a GroupWise 2012 database. If you are moving from GroupWise 7 or GroupWise 8 to GroupWise 2012, there are no structural changes outside of the post office database to be concerned with. However, if you are upgrading from GroupWise 6.5 or earlier, you will notice an interesting new feature. Prior to GroupWise 7, GroupWise had 25 message databases in the ofmsg directory structure. These are shared databases that are randomly divided amongst your users, no matter how many users are on a post office. Upon creation, a user is assigned to a message database, and all mail “sent” from that user goes into this database number. In GroupWise 6.5 and earlier, a post office with 50 users ends up with the same number of message databases as a post office with 5000 users!
This was not a huge issue for many years. However, as the usage of e-mail increased over time, these databases grew larger and larger. While GroupWise seemed to handle the bloat of the databases just fine itself, it started to cause issues for backup software, the time it took to perform a GWCHECK, etc., etc. Additionally, FLAIM databases (which all GroupWise user and message databases are) have a limit of 2 GB per database. Thus, it has become more important over time to distribute the data over a larger number of databases to prevent database files from reaching the FLAIM limit.
With GroupWise 7, Novell increased the number of message databases to 255. This allows for better load balancing of the message store. There are some interesting side effects of this change though that are important to know about. If you are upgrading to GroupWise 2012 from GroupWise 6.5 or earlier, users will be reassigned to these new database numbers immediately. For example, Danita’s database went from being number 21 under GroupWise 6.5 to number 91 under GroupWise 7. And as we say, this is an immediate change. As soon as a user logs into the GroupWise 2012 post office (regardless of the client version) and sends a message, that message will be saved into the new database. All previous messages will remain in the former message database. So, in the case of Danita, she now has messages linked in her sent items to both msg21.db and msg91.db.
While this is mostly a technical discussion, and doesn’t really impact your users in any noticeable way, you should know what happens if you have post offices at a version older than GroupWise 7 that you do not upgrade right away. You will start to see these newer, higher numbered databases appearing even in GroupWise 6.5 or earlier post offices. This is due to how the GroupWise system works. If Danita sends a message to a user on a different post office, the message is placed in msg91.db on Danita’s post office. That message is then sent through the MTAs to the second post office, and when it is saved, it is placed in msg91.db on THAT post office. This poses no problems. The older post office agents will look into any database that is referenced in a message header. The important thing to remember is that this is normal and you should not be concerned when you see these “oddly” numbered databases in the older post office directories. And be careful not to assume that these files are not needed and get too tidy and delete them!
In the past, SOAP only needed to be enabled if you were running the GroupWise Mobile Server, the DataSynchronizer Mobility Server, or another third party product that requires SOAP access. With GroupWise 2012, it will be a very rare occurrence to not need SOAP enabled for your post offices. Not only do the aforementioned processes require SOAP access, but WebAccess itself will require SOAP to be enabled at the POA in order for WebAccess to function. Thus, it will be important for almost all Post Office Agents to support SOAP. Follow these steps to enable SOAP for all post offices that will have users who access GroupWise via WebAccess:
In ConsoleOne, click on the GroupWise System Globe, and perform the following steps:
Enabling the HTTP Monitor for Your Agent
We have found that there are many GroupWise sites where the HTTP (Web) Monitor is not in use. Especially since GroupWise 8, these HTTP Monitors have become more and more important. If you define a userid and password for the HTTP Monitors, you can perform all of the functions that you used to perform at the GUI Consoles for your agents, as well as new functions that were not available on the GUI Consoles. If you do not have your HTTP Monitor enabled, now is a good time to do so.
In ConsoleOne, click on the GroupWise System Globe, and perform the following steps:
Preparing the Post Office Database
When you are ready to continue your upgrade, we will first check the post office database to make sure that it is ready to upgrade. First, in ConsoleOne, select the post office object and choose Tools|GroupWise Utilities|System Maintenance|Validate Database. If your database shows as valid, you can proceed. If for some reason the database does NOT validate, you should rebuild it. In order to rebuild the database you must first shut down the POA and make sure that no users can attach to the post office directly. At this point, we are going to shut down the post office agent for the upgrade anyway, so if you need to rebuild your database, first follow the instructions immediately below on shutting down your post office agent. Once the post office agent is shut down, return to ConsoleOne and choose Tools|GroupWise Utilities|System Maintenance, and this time choose Rebuild Database.
On Linux, you must upgrade all GroupWise components at the same time, so you need to stop all processes that are GroupWise related. This includes GroupWise agents and gateways and GroupWise Monitor. We are assuming that you are running your agents as daemons. If, however, you are running them with their GUI consoles, unload all of the agents by shutting down the GUI consoles. Close the GroupWise client if it is running on the server. Finally, to be certain that all agents and gateways are closed, type the following commands at a terminal prompt:
You may receive errors if you are not using the grpwise-ma or grpwise-wa scripts, but it does not hurt to attempt to stop them even if you do not have these scripts installed.
After all GroupWise components have been shut down, type the following into the terminal prompt to verify that no GroupWise components are running:
ps -A | grep gw
If at this point you still see GroupWise components loaded you can kill them individually, either by pid or name – for example:
(if you show a GroupWise component with the pid 9860 running)
For Windows, you must also shut down your post office agent. If you are running the agents as services, go into the services console from the Control Panel, right click on the GroupWise post office agent, and choose stop (see <a>Figure 9-1</a>). If you are not running the post office agent as a service, go to the post office agent console and exit via F7 or from the agent menu.
After your post office agent is shut down, leave the agent down until you are instructed to reload it below.
Installing your Agent Software
In the sections above, we shut down the POA on your server. It is important that you have not reloaded the POA since then, or if you did that you go back through the steps to unload your post office agents again. Once the POA is unloaded, look in the root of the Master SDD we created during the upgrade of the domain.
If you are running your Post Office Agent on Windows, you must run this installation directly on the Windows server, rather than from a workstation attached to the Windows server.
<a id="Anchor-13"></a>In the root of the Master SDD, you will see the setup.exe program that will be used for this upgrade. When you run this program, you see the Window in <a>Figure 9-2</a>.
While we are looking at this screen, we should explain its usage so that it’s more easily understood the next time you encounter it. There are a few misconceptions about what is done here, and what you need to put in this location, so we will try to clear those up.
<a id="Anchor-25"></a>First, this screen is a template for creating new agent startup files (for example the post1.poa file), and for configuring your Windows services or Windows shortcuts. Let’s take the example of our groupwise system. Our post office is called Caledonia. If we want to create a new startup file for the Caledonia post office, and configure Windows services or shortcuts, we would click the Add button as shown in <a>Figure 9-5</a> and enter the information for our post office.
By entering this information, we are instructing the installation routine to create us a startup file called Cal-PO.POA with a /home switch of “W:\pos\cal-po”, place it in the location of our startup files that we indicated above, and optionally configure a Windows service for the POA or create a Windows shortcut.
This screen will validate the location you specify and warn you if you are putting in an invalid location (for example, if you put in m:\pos\cal-po and that location does not contain a post office database it will complain). Interestingly enough though, if you “cancel” at this point, it will still put m:\pos\cal-po in the setup and will complain that the path is invalid when you click “Next” to continue the setup. You will be required to fix this to point to a valid post office location before you can complete the setup. The installation does not validate the “name” you put here and indeed, you can name things here anything you like. For example, rather than naming my startup file “Cal-PO.POA” as shown above, I could just as easily type “Post1” in the name field, and the name of the file would instead be Post1.POA. If you put in a name that has more than eight characters (for example Caledonia), the file name will be truncated to eight characters. So, if indeed I were to put “Caledonia” in the name of my post office field, I would have a startup file called “Caledoni.POA”. If a “Caledoni.POA” file already exists, I will now have a “Caledoni.PO1” file in that directory.
Running the Linux installation routine is a bit different, in that you are not allowed to pick and choose what you install when running this installation script. The script will detect what GroupWise components are already installed on this server, and it will insist that they all be updated at the same time.
In your Master Linux SDD (in our case /grpwise/gw12soft), run the install script. For example:
gwlinux:/grpwise # ./install
After choosing your installation language, you will see the screen in <a>Figure 9-6</a>.
<a id="Anchor-12"></a>NOTE: <a>Figure 9-8</a> shows a number of agents installed on this server. If you have a simple, single server system, you may see all of these. If you have multiple servers, you will only see the agents required for the particular server being upgraded. With the changes to WebAccess, not only do you not see the WebAccess Agent listed (as it is now obsolete), but you do not see the WebAccess Application either. You will be required to do a separate installation for WebAccess if it is on the same server.
This screen will validate the location you specify and warn you if you are putting in an invalid location (for example, if you put in /groupwise/pos/cal-po and that location does not contain a domain database it will complain). The installation does not validate the “name” you put here and indeed, you can name things here anything you like. For example, rather than naming my startup file “cal-po.poa” as shown above, I could just as easily type “post1” in the name field, and the name of the file would instead be post1.poa.
If you put in a name that has more than eight characters (for example Caledonia), the file name will be truncated to eight characters. So, if indeed I were to put “Caledonia” in the name of my post office field, I would have a startup file called “Caledoni.POA”. If a “Caledoni.POA” file already exists, I will now have a “Caledoni.PO1” file in that directory.
<a id="Anchor-29"></a>Upgrading Your Post Office
At this point, you have installed the software required to take your post office to GroupWise 2012, but your post office has not actually upgraded. This will not happen until you load the new software, under the proper conditions. Earlier in this chapter we saw an option on the Novell installation routine that said “Update an Existing System” and we chose to skip that. Novell’s installation routine has improved quite a bit with GroupWise 2012, but it still expects certain aspects of every GroupWise system to be uniform, and we find that more times than not, GroupWise systems simply are not! This causes inconsistencies in the upgrade process, and it is easier for us (and you) to do these steps manually to ensure that they are done correctly in every single upgrade. This makes just a one or two fewer things to have to troubleshoot if there are problems. In order to continue our upgrade, do the following:
Linux: For all Linux installations, the agents are installed to run as daemons. You can launch them under X-Windows to the GUI console during the upgrade just to see that everything loads okay. From a terminal prompt:
/opt/novell/groupwise/agents/bin/gwpoa –show @po.poa &
Your POA should load up on your server. If you receive any errors during loading, check what the error is and see what can be done to resolve it.
When the GroupWise 2012 POA loads, it looks for the dc file that says it is okay to upgrade. The dc file is essentially a text file that contains the database schema for creating a GroupWise 2012 database. The gwpo.dc shows the version number at the very top line as #VERSION=1200. This version number at the top of the file verifies that you have the GroupWise 2012 dc file in your post office directory. Once the POA sees the GroupWise 2012 dc file and sees the flag from it’s domain that the post office is allowed to upgrade, the POA will launch a recovery of the database, effectively converting the post office to GroupWise 2012. If you are quick (on a small post office – not so quick on a larger one), you will be able to see the Admin Status of the post office change to “Recovering” to show that the post office is being converted. Once the status returns to “Normal” you should be able to look at the properties of the post office in ConsoleOne and see that the version is GroupWise 2012. Once the post office has been converted to GroupWise 2012 you should log in to the post office as a GroupWise user to ensure that everything looks okay. Try logging in with a GroupWise 2012 client. This will confirm that the post office is indeed version 12. If you attempt to log in to the post office with a GroupWise 2012 client and receive a message that says “The Version of GroupWise you are using cannot access this post office” then your post office has not upgraded properly, and you should see the troubleshooting steps below.
There are very few things that can go wrong during a post office upgrade. If you find that your post office refuses to show as a GroupWise 2012 post office in ConsoleOne, do a couple of things:
Checking the MTP Link
Frequently when moving a post office, the message transfer link between the MTA and the POA is broken. For those of you who have never used the HTTP monitors for the agents before, this will be a really good example of “learning to love the HTTP monitor”. Because even though it’s something you have to get used to doing since we are not loading the GUI Consoles for our agents (except in testing situations), the solution that we will show now is not available in any of the GUI Consoles! So the HTTP monitor wins our love and devotion in one simple command.
<a id="Anchor-29"></a>The first thing we are going to do is log into our POA’s HTTP monitor. Using your favorite browser (we prefer Firefox, but Internet Explorer works as well), go to the IP address and port of your POA’s HTTP monitor. Our location is <a href="http://192.168.100.169:7181/">http://192.168.100.169:7181</a> – and unless you changed the default port for your POA, you will also go to 7181. When we enter this address, we are first asked for a userid and password. This is the userid and password we assigned to the HTTP monitor in “Edit the Details of the Post Office in ConsoleOne” above.
After authenticating, we are presented with the following screen:
At this point we want to click on the link for MTP Status, and we will see this screen:
You will notice that the Receive Status shows as Closed, and that the Inbound TCP/IP address shows our old IP address. This is due to the simple fact that our POA doesn’t know that it has moved! This is easily rectified. Simply click on the Closed link under the word Received, change the IP address to the current IP address of the POA on Linux, click the Start MTP Receive radio button, and click Submit. Now click the MTP Status link again and you will see that the Receive thread shows Open. Your MTA and POA are talking to each other again, and mail can begin flowing.
Log into the POA on the New Server
It’s now time to log into your new POA and verify that everything is working as desired. If you use the ngwnameserver listing as described above, your GroupWise client will initially try to go to the old server, timeout and then ask for the new entry in DNS. If you do not use ngwnameserver, you will likely need to enter the new IP address manually when the login times out.
Once you have logged into your mailbox, there are a few tasks that you should perform to ensure that everything is working properly
Once all of these tasks are performed successfully, you are DONE. Unless of course you need to move an External Storage Area. In that case, continue on with the next section.
New Options to Explore
There are a few new functions of the Post Office Agent that you should take a look at. They are:
Once you are ready to continue, just turn to the next chapter in your upgrade plan.