Upgrading Your Post Offices

Revision for “Upgrading Your Post Offices” created on December 9, 2013 @ 23:53:44

TitleContentExcerpt
Upgrading Your Post Offices
<div>

Upgrading your post offices is very similar to upgrading domains. There are just a few things to keep in mind about your upgrade:
<ul>
<li>Your post office cannot be upgraded until the domain that owns the post office is at GroupWise 2012.</li>
<li>You should use the version of GWCheck that is designed for your version of GroupWise. Thus, if you have multiple post offices and will not upgrade them all at the same time, make sure you have not only your GroupWise 2012 GWCheck available, but also that you keep the older standalone versions of GWCheck on hand until you have upgraded those older post offices.</li>
<li>The GWIA, while an SMTP server, also serves as a client when it is used for IMAP4 and POP3. Once you upgrade your GWIA to GroupWise 2012, you will only be able to use POP3 and IMAP4 to GroupWise 2012 post offices.</li>
<li>If you upgrade a post office to GroupWise 2012 and that post office owns users who typically proxy to other users on older GroupWise post offices, you will not be able to upgrade those users’ clients until all post offices are upgraded.</li>
<li>If you have multiple post offices, you will need to wait on upgrading WebAccess until all of the post offices have been upgraded, or use two separate WebAccess servers to handle both versions of GroupWise.</li>
</ul>
&nbsp;

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.

&nbsp;

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:
<ul>
<li>The domain that owns the post office in question must already be upgraded to GroupWise 2012.</li>
<li>The Post Office Agent software must be at GroupWise version 12</li>
<li>The dc (dictionary files) in the post office directory must be at version 12</li>
</ul>
&nbsp;

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!

&nbsp;

Enabling SOAP

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:
<ol>
<li>In the dropdown list that shows “Users”, change the setting to “Post Office Agents.”</li>
<li>Find the POA for your post office, right-click and choose Properties.</li>
<li>Now click on the triangle in the GroupWise tab and change to Network Address.</li>
<li>Make sure that there is a port listed for SOAP for your Post Office Agent. The default SOAP port is 7191.</li>
<li>Now, on the GroupWise tab, change to the Agent Settings screen. Verify that SOAP is enabled for the POA.</li>
<li>Save your changes.</li>
</ol>
&nbsp;

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:
<ol>
<li>In the dropdown list that shows “Users”, change the setting to “Post Office Agents.”</li>
<li>Find the POA for your post office, right-click and choose Properties.</li>
<li>Now click on the triangle in the GroupWise tab and change to Network Address.</li>
<li>Make special note of the HTTP port that is defined for this agent. By default, the HTTP port for the POA is 7181.</li>
<li>If there is nothing in the HTTP port field, put 7181 (or another port of your choosing).</li>
<li>Now, on the GroupWise tab, change to the Agent Settings screen. Notice the HTTP Monitor settings. If you have never enabled the HTTP monitors for your agents, you will need to decide on a good userid and password for the HTTP monitors. Please note that this is neither an eDirectory user nor a GroupWise user. This is an entirely made up user and password solely for the use of the HTTP monitors. If all administrators in your organization will have rights to use the HTTP monitors, then it is a good idea to have the same userid and password for all agents. If you need to limit rights to some agents to various groups, set up a userid and password for each group of agents that will be monitored. Enter the userid and password that you have decided on here in this screen.</li>
<li>Save your changes.</li>
</ol>
&nbsp;

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.

&nbsp;

Linux

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:

&nbsp;

/etc/init.d/grpwise stop

/etc/init.d/grpwise-wa stop

/etc/init.d/grpwise-ma stop

&nbsp;

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:

&nbsp;

ps -A | grep gw

&nbsp;

If at this point you still see GroupWise components loaded you can kill them individually, either by pid or name – for example:

&nbsp;

kill 9860

(if you show a GroupWise component with the pid 9860 running)

&nbsp;

or

killall gwpoa

&nbsp;

Windows

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.

&nbsp;
<ol>
<ol>
<li><a id="Anchor-13"></a><img alt="services1.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/services1_opt.jpeg" width="636" height="448" />Stopping a Windows service</li>
</ol>
</ol>
&nbsp;

&nbsp;

After your post office agent is shut down, leave the agent down until you are instructed to reload it below.

&nbsp;

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.

&nbsp;

Windows

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

&nbsp;
<ol>
<ol>
<li><a id="Anchor-17"></a><img alt="install1.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/install1_opt.jpeg" width="693" height="518" /><a id="Anchor-17"></a>The main installation screen</li>
</ol>
</ol>
&nbsp;

&nbsp;

&nbsp;
<ul>
<li>Click on Install GroupWise System.</li>
<li>Click Yes on the next screen to accept the license agreement.</li>
</ul>
<ol>
<ol>
<li><a id="Anchor-17"></a>Click Next on the next screen to do a standard install. You will see the window in <a>Figure 9-3</a>.
<ol>
<li><img alt="installagents.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/installagents_opt.jpeg" width="693" height="519" /><a id="Anchor-30"></a>Install Wizard – GroupWise Components</li>
</ol>
</li>
</ol>
</ol>
&nbsp;
<ul>
<li>You will notice on this screen that we have many options. Novell has created an entirely new upgrade routine. However, we still feel like it is best to manage the upgrade manually. Thus, we will choose “Install Individual Components”.</li>
<li>Do not check any options other than the GroupWise Agents on this screen.</li>
<li>The next screen seems to be a holdover from the combined Windows and NetWare installation routines of the past, and has a single radio button for Windows. Just click next.</li>
<li>The next screen will give you the option of where to install your files on your Windows server, and options for the installation.</li>
</ul>
&nbsp;
<ol>
<li>If you have SNMP installed on your GroupWise server, you can configure SNMP for the agents on this server.</li>
<li>Here you also have a check box for installing the agents as windows services. It is highly recommended that you install your GroupWise agents as services on your Windows server. If you do not, you must log into the Windows server and launch the agents on startup. Otherwise the agents cannot launch and users will not be able to access GroupWise until the login takes place.</li>
</ol>
<a id="Anchor-30"></a>After you choose the options on this screen you will click next and be presented with the window in <a>Figure 9-4</a>.
<ol>
<ol>
<li><a id="Anchor-25"></a><img alt="install5.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/install5_opt.jpeg" width="693" height="519" />Configuring the GroupWise Agents</li>
</ol>
</ol>
&nbsp;

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.
<ol>
<ol>
<li><a id="Anchor-26"></a><img alt="agentconfig2.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/agentconfig2_opt.jpeg" width="394" height="205" />Adding a post office for configuration</li>
</ol>
</ol>
&nbsp;

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.
<ol>
<li>You will now be asked how you wish to run the agents. If this post office agent has no need to log into any other servers, choose local system account. If you need to log into other servers, supply a user who has rights to this server as well as the other server in question. Leave the startup type as Automatic.</li>
<li>Next you will be presented with a summary screen showing your choices for the install, and the installation will proceed.</li>
<li>When the installation has completed, leave both boxes (Save settings for a future installation” and “Launch Agents Now”) unchecked (we do not want to start up our agents yet!), and click “Finish” to close the installation program.</li>
</ol>
<a id="Anchor-26"></a>Now that your Windows agent software has been updated, we need to move on to the actual process of upgrading the post office to GroupWise 2012. See <a>“Upgrading Your Post Office”</a> below.

&nbsp;

Linux

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.

&nbsp;

In your Master Linux SDD (in our case /grpwise/gw12soft), run the install script. For example:

&nbsp;

gwlinux:/grpwise # ./install

&nbsp;

After choosing your installation language, you will see the screen in <a>Figure 9-6</a>.
<ol>
<ol>
<li><a id="Anchor"></a><img alt="lnxinstall1.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/lnxinstall1_opt.jpeg" width="802" height="623" />The Linux Install Screen.</li>
</ol>
</ol>
&nbsp;

&nbsp;

&nbsp;
<ul>
<li>Choose install products.</li>
<li>Choose GroupWise Agents. We will take this opportunity to point out that in the Linux installation routine there are separate “install” and “configure” steps for each agent. Since we’re doing an upgrade, and typically do NOT need to configure the agents, we’ll only look at these as we need them.
<ol>
<li><img alt="lnxinstall2.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/lnxinstall2_opt.jpeg" width="802" height="623" />Install and Configure Screen</li>
</ol>
</li>
</ul>
<ol>
<ol>
<li><a id="Anchor"></a>Choose Install Agents. You should see a screen similar to <a>Figure 9-8</a>. This screen will show all components on this particular Linux server that must be upgraded.
<ol>
<li><a id="Anchor-12"></a><img alt="update.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/update_opt.jpeg" width="479" height="331" /><a id="Anchor-12"></a>Components to Upgrade on Linux</li>
</ol>
</li>
</ol>
</ol>
&nbsp;

<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.
<ol>
<li>You must choose Yes for this option, otherwise the installation will simply close. Choosing Yes starts the update of all agents required on this server. If there are a number of agents, this can take awhile.</li>
<li>Once the agents are installed, choose Configure Agents.</li>
<li>Click next on the introduction screen and accept the license agreement. You will be presented with a window similar to <a>Figure 9-4</a> (just a bit more “Linux-like”). This screen is a template for creating new agent startup files (for example the post1.poa file), and for configuring your gwha.conf file to start the agents on Linux. 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 the grpwise script (provided that we checked the option above to “Launch the GroupWise agents on system startup), we would click the Add button as shown in Figure 5-8 and enter the information for our post office.
<ol>
<li><img alt="posetup.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/posetup_opt.jpeg" width="409" height="201" />Adding a post office for configuration on Linux</li>
</ol>
</li>
</ol>
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 “/grpwise/pos/cal-po”, place it in the /opt/novell/groupwise/agents/bin directory, and add the information into the gwha.conf file that will be loaded by the grpwise script on startup.

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:

&nbsp;
<ol>
<li>In your Master SDD, there is a directory called po. Copy all of the dc files from the po directory directly into the root of your post office directory (i.e., the directory where the wphost.db file resides). Overwrite the existing files if asked.</li>
<li>Next in your Master SDD under the client/win32 directory there is there is a directory called ofviews. Copy everything in the ofviews directory into the ofviews directory that is in your post office directory. It’s really not necessary to make a backup copy of this ofviews directory, but some sites like to do that just in case. Overwrite the existing files if asked, even if prompted that some existing files are newer. Now we will launch the POA so that your post office can upgrade.</li>
</ol>
Windows: Even if your agents normally launch as services, it is useful to launch the POA to the GUI console the first time, just to see that everything launches correctly. At the command prompt (note we’re using c:\grpwise – you may have reinstalled your agents into c:\program files\novell\groupwise server\agents):

c:\grpwise\gwpoa @po.poa

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 &amp;

&nbsp;

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.

&nbsp;

&nbsp;

Troubleshooting

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:
<ul>
<li>Verify that you have GroupWise 2012 snapins installed. You can get odd results in the version field of a post office if you are looking at a GroupWise 2012 post office with older GroupWise snapins.</li>
<li>Double-check that you got the dc files copied into the post office directory. Open the gwpo.dc and ngwguard.dc files with a text editor to verify that they are indeed the GroupWise 2012 files.</li>
<li>Double-check that the domain owning this post office is actually a GroupWise 2012 domain (i.e., it shows as version 12 in ConsoleOne).</li>
<li>Unload and reload the POA to see if this solves the problem.</li>
<li>It is possible that communications issues have prevented the post office database from receiving the news that its parent domain is a GroupWise 2012 domain and thus is allowed to upgrade. Remember that just loading the GroupWise 2012 agent software is not enough. If all else fails, rebuild the post office database in ConsoleOne (Tools|GroupWise Utilities|System Maintenance|Rebuild Database).</li>
</ul>
&nbsp;

&nbsp;

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:
<ol>
<li><img alt="Figurel-p5.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/Figurel-p5_opt.jpeg" width="667" height="540" />The POA HTTP Monitor</li>
</ol>
*** Need New Graphic

At this point we want to click on the link for MTP Status, and we will see this screen:
<ol>
<li>The POA MTP Status Screen<img alt="Figurel-p6.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/POChpt-web-images/Figurel-p6_opt.jpeg" width="667" height="540" /></li>
</ol>
&nbsp;

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
<ul>
<li>Send a message to yourself. This should pop into your mailbox almost immediately.</li>
<li>Send a message to a user on the same post office, and verify that it is received.</li>
<li>Send a message to a user on another post office if applicable and verify that it was received</li>
<li>Send a message to an external recipient through your GWIA and verify that it was received.</li>
<li>Send a message from an external sender to your user through the GWIA and verify that it was received.</li>
<li>If you use GroupWise Document Management and your documents are all stored under the Post Office directory structure, open an existing document and verify that you are able to access it properly.</li>
<li>Create a new document in GroupWise DMS and verify that it creates and saves properly.</li>
</ul>
&nbsp;

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.

&nbsp;

&nbsp;

New Options to Explore

There are a few new functions of the Post Office Agent that you should take a look at. They are:

&nbsp;
<ul>
<li>Calendar publishing: Combined with the new Calendar Publisher Host, the POA will provide access to calendar publishing and free/busy searching features in the Windows and WebAccess clients for all calendars, including the main GroupWise calendar for a user.</li>
<li>Beginning with GroupWise 8, the new Document Conversion Agent that is launched by the POA provides indexing of additional document formats such as PDF, OpenOffice, and newer versions of Microsoft Office. This is available for indexing documents in the GroupWise library, and attachments in the GroupWise mailbox.</li>
</ul>
&nbsp;

Once you are ready to continue, just turn to the next chapter in your upgrade plan.

</div>



Old New Date Created Author Actions
December 9, 2013 @ 23:53:44 Danita
December 9, 2013 @ 23:12:33 Danita