Moving WebAccess – Linux

Previous Sections

In this chapter, we are moving WebAccess to a new Linux server. In our example, we will install and configure the WebAccess Application (the Web Server portion) and the WebAccess Agent (GWINTER) on the new Linux server.

Since we never run a WebAccess Agent on a server remote from its owning domain, that means we also must move our domain to the new Linux server. It’s also possible that this domain owns other gateways like a GWIA. If this is the case, and if you plan on moving the GWIA to the new Linux server as well, we can do this all at one time. However, if you only wanted to move the WebAccess Agent to the new Linux server, and leave the GWIA on your source server, you would essentially not be moving a domain to the new Linux server at all. Rather, you would be creating a new domain and WebAccess agent on the new server. If this is your situation, stop now and go to the chapter entitled “Creating a New Domain on Linux to Relocate a Gateway”.

In the “Preparing your New Linux Server” chapter, we installed the DBCopy utility that we use to move the data from the source server to the new Linux server. Additionally, during the setup of your server, you installed ncpfs, which allows us to attach to a NetWare server via NCP and/or smbfs which allows us to attach to a Windows server to copy the data. The steps we will take are as follows:

  • Create a mount point for the source server. Technically, we do not need to create a mount point if your are moving your WebAccess Agent from one Linux server to another. We will do the copy of the files with scp (Secure Copy) when we get to the section on copying the files.
  • Unload the existing Message Transfer Agent (MTA) for this domain. We will need exclusive access to the domain database, so we must also unload the WebAccess Agent and any other gateways that belong to this domain.
  • Rename the domain directory to avoid any accidental access while we are relocating the domain.
  • Ensure that all file and directory names for the domain are lowercase.
  • Copy the domain directory structure from it’s current location to the new Linux server using DBCopy or scp.
  • Load ConsoleOne and edit the domain location, agent address and link information if necessary.
  • Configure the MTA on the new Linux server.
  • Load the MTA with a GUI console for the relocated domain for testing
  • Verify that the MTA is communicating with any post offices it owns, and any other domains for which it has direct links.
  • Install the WebAccess Agent software and configure the WebAccess Agent.
  • Install the WebAccess Application software and configure the WebAccess Application.
  • Load the WebAccess Agent with a GUI console for testing.
  • Unload the MTA and WebAccess Agent, and reload them as daemons.

 

So, let’s see how this all works.

 

Create a Mount Point for the NetWare Server

If you are moving your domain from NetWare, you need to attach to the NetWare server from your new Linux server. To mount the NetWare volumes into your Linux file system, perform the following steps:

  1. On the Linux server, open up a terminal window.
  2. ”su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our NetWare server that is named gw1. It is suggested that you replace gw1 with the actual name of your NetWare server for ease of recognition later.
  4. We have chosen to connect to our NetWare server via ncpfs. To mount the NetWare server via ncpfs, issue the following command

 

ncpmount -S server -A 123.123.123.123 -U userid -P password /mnt/gw1

replacing your server name for “server” and your server’s IP address for 123.123.123.123. For example

ncpmount -S gw1 -A 192.168.100.200 -U danita.cnc -P password /mnt/gw1

 

NOTE: You might wonder about the “user.context” vs. “.user.context” in this example. While “.user.context” works on some versions of Linux, it fails on others. In my testing, “user.context” has always worked on all versions. You might keep this in mind if you experience any problems authenticating with ncpmount.

 

This will actually mount all volumes from the NetWare server to this location. So, if we cd to /mnt/gw1 will will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.

Create a Mount Point for the NetWare Server

If you are moving your domain from NetWare, you need to attach to the NetWare server from your new Linux server. To mount the NetWare volumes into your Linux file system, perform the following steps:

  1. On the new Linux server, open up a terminal window.
  2. “su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our NetWare server that is named gw1. It is suggested that you replace gw1 with the actual name of your NetWare server for ease of recognition later.
  4. We have chosen to connect to our NetWare server via ncpfs. To mount the NetWare server via ncpfs, issue the following command

 

ncpmount -S server -A 123.123.123.123 -U userid -P password /mnt/gw1

replacing your server name for “server” and your server’s IP address for 123.123.123.123. For example

ncpmount -S gw1 -A 192.168.100.200 -U danita.cnc -P password /mnt/gw1

 

NOTE: You might wonder about the “user.context” vs. “.user.context” in this example. While “.user.context” works on some versions of Linux, it fails on others. In my testing, “user.context” has always worked on all versions. You might keep this in mind if you experience any problems authenticating with ncpmount.

 

This will actually mount all volumes from the NetWare server to this location. So, if we cd to /mnt/gw1 will will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.

Create a Mount Point for the Windows Server

If you are moving your domain from Windows, you need to attach to the Windows server from your new Linux server. To mount the Windows drives into your Linux file system, perform the following steps:

 

  1. On the new Linux server, open up a terminal window.
  2. ”su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our Windows server that is named gw1. It is suggested that you replace gw1 with the actual name of your Windows server for ease of recognition later.
  4. We have chosen to connect to our Windows server via cifs. To mount the Windows server via cifs, issue the following command:

 

mount -t cifs //server/d$ /mnt/name -o username=user,password=password, domain=domain or workgroup

 

This command is all one line, and there is no space between the comma following password and the word domain. You can use the entire drive (d$) or a specific share name. We like to use the drive (d$) when possible, but the share works as well. If for some reason you have difficulty mounting by by server name, you can substitute the IP address of the Windows server in the //server/d$ portion (i.e. //192.168.100.201/d$).

So, for example, our command would be

mount -t cifs //192.168.100.228/d$ /mnt/gw1 -o username=danita,password=pass,domain=caledonia

 

Unload the MTA

First of all, go to the server where your MTA is loaded for the domain that you are moving:

  • NetWare: press F7 at the agent console to unload the agent
  • Windows: if the agent is running as an Application, you can also press F7, or use the File Menu and Exit. If the agent is running as a Service, you must stop the agent from the services applet.
  • Linux: use rcgrpwise command. For example:

rcgrpwise stop DomainName

If you are not certain of the name that is defined for your domain in the rcgrpwise script, first run:

rcgrpwise status

This will show you all agents that the rcgrpwise script controls. Find the name for your MTA and then issue the stop command for your MTA.

Also make sure that no administrators are accessing the domain database through ConsoleOne.

Unload Your WebAccess Agent and Any Other Gateways

Like the MTA, your WebAccess Agent and any other gateways that are running under this domain must be unloaded. The instructions are the same as for the MTA. Press F7 where appropriate to unload the gateways, shut down the services on Windows, or stop the daemons on Linux. Make sure all gateways have been shut down before you proceed.

Copy the Files to New Linux Server

After the MTA is unloaded, we will prepare to copy the domain structure to the new Linux server. Let’s look at the current directory structure of our domain. Figure 6-1 shows the domain directory for our domain. Notice that on NetWare and Windows, most files and directories are in all uppercase (this is also dependent on your GroupWise version and more recent versions create everything lowercase to avoid problems down the road).

    1. FigureL-D5.tiffDomain Directory Structure

 

All files and directories for the domain and post office on Linux must be all lowercase, otherwise the agents will simply not see the “proper” file and will fail to load. Prior to loading the MTA on our new Linux server, we will need to change the case of all files and directories for the domain. We will use DBCopy for this purpose. If you are moving your domain from one Linux server to another, your file names are already all lowercase, and you will not need to concern yourself with this step.

Once we are ready to move the domain directory structure to our new Linux server, we will rename the domain directory to avoid any accidental access by administrators using ConsoleOne, NWADMIN, etc. DBCopy makes no changes to the original files in the domain directory. If needed, you could simply rename your domain directory back to its original name and load your MTA back up on the source server.

 

NOTE: Make sure that you prune out unneeded log files, files in the problem directories, etc. The gwprob directory under the GWIA is especially prone to a lot of unneeded files. We’ve seen YEARS worth of files in this directory during health checks. Clean out all of the junk, and the copy of your domain will fly!

 

From Linux

If you are moving your domain from one Linux server to another, there is very little reason to use DBCopy. Instead, you can simply use scp to copy the files over ssh. In order to use scp, you would issue a command like this:

scp -r /currentdomain user@newserver:/location

The -r switch tells scp to copy all subdirectories recursively from our current domain location to the requested location on the new server, and which user to log in as for the copy.

For example, if our current domain is at /grpwise/domains/cnc2.old (which we have now renamed to avoid accidental access), and it will go to server gw2 at /grpwise/domains/cnc2, our scp command would look like this:

scp -r /grpwise/domains/cnc2.old danita@gw2:/grpwise/domains/cnc2

If you ever have issues connecting to a source server from your Linux server by name, you can always replace the server name with the server’s IP address in the command. So, for example, danita@gw2 or danita@192.168.100.241 are both valid ways to use this command.

After you have copied your files over to the new server, skip down to “Edit Important information in ConsoleOne” and continue from there.

From NetWare or Windows

For those of you moving from NetWare or Windows, you will find that DBCopy on the Linux server does not run well from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location to run the utility. Run DBCopy to copy your files from the source server to the Linux location like this:

./dbcopy -m -d

so for our situation it would be

./dbcopy -m -d /mnt/gw1/GWDATA/domains/cnc2.old /grpwise/domains/cnc2

This will copy all needed data from the old domain directory into the directory structure that we’ve indicated for the destination. In our case, we have chosen to locate our domain in /grpwise/domains/cnc2.

The -m switch copies the files over in all lower case. The -d switch tells DBCopy that it is migrating a domain. Generally this will not take long at all to perform the copy. Unless you have many files in your existing MTA queues, there is not really much to copy!

 

Edit Important information in ConsoleOne

Now that your domain directory has been migrated to the new Linux server, we need to edit the location of the domain directory and fix some information in the agent’s network address configuration.

Since it’s a good exercise to learn to access ConsoleOne directly on your Linux server, we’ll do that for this task.

 

  • When we installed ConsoleOne earlier, the installation routine should have created a shortcut to the application on your desktop. If you cannot find this shortcut, we can load the application by hand simply by running /usr/ConsoleOne/bin/Consoleone.
    1. The first time you launch ConsoleOne for Linux with GroupWise snapins, you will be presented with a screen like Figure 6-2.
      1. Linux Mount DirectoryFigurel-d6.tiff

 

  • Assuming you wish to have your GroupWise server mount points in /mnt, leave the setting as it is and click okay. This mount point location for GroupWise is very important, and we discuss this in detail in the chapter entitled “Tips and Tricks for GroupWise on Linux”.
  • You should now be presented with a login prompt. If for some reason the login prompt does not appear, click on NDS under My World, and then click on the tree icon in the toolbar. Log into your tree as you normally would if this were a Windows workstation. Note, however, that if you cannot find the tree, putting the IP address of one of the eDirectory servers in the tree field should help you with that. On our systems, sometimes the login box seems to not allow us to click in the password field to enter a password. If that happens, simply attempt to login with no password. You will receive an error that the password is incorrect, but then the login box will refresh and correct itself.
  • Once you have logged into your tree, click on the “GroupWise System” next to the Globe.
  • Now, from the menu choose Tools|GroupWise System Operations|Select Domain.
  • Enter the Linux location for your domain. In our case, we put our domain in /grpwise/domains/cnc2. You can also browse for your domain directory if necessary.
  • Once GroupWise opens the domain database, you should see your GroupWise system under the globe. This is a really good time to point out that you will be required to open your domain every time you load ConsoleOne on Linux. Unlike on Windows, where ConsoleOne remembers where your domain last was and automatically connects you back to the last domain you accessed, ConsoleOne on Linux requires you to go through the Tools|GroupWise System Operations|Select Domain process each time. You will find this particularly frustrating once you see that this location is remembered for you and filled into the Select Domain field, but will not automatically connect until you perform these steps.
  • Right-click on the GroupWise domain you have moved to your new Linux server, and choose Properties.
  • For now, you will see that your domain says it is location somewhere like /mnt/gw1/GWDATA/domains/CNC2 (which is the source server location in your mount point). Change this to reference the actual Linux path in the UNC Path field – you can browse for this if necessary. In our case our path is /grpwise/domains/cnc2. Note that this really isn’t a UNC path, but we will change this later when we discuss mount points and UNC paths in the “Tips and Tricks for GroupWise on Linux” chapter. When you have your Linux path in this field, click OK.
  • Now, in the dropdown list that shows “Users”, change the setting to “Message Transfer Agents.”
  • Find the MTA for your domain, right-click and choose Properties.
  • On the first screen, change the Platform to Linux.
  • Now click on the triangle in the GroupWise tab and change to Network Address. Here you must change the IP address to that of the new Linux server.
  • Before you leave the Network Address tab, make special note of the HTTP port that is defined for this agent. By default, the HTTP port for the MTA is 7180. As we noted earlier in this book, since we will not have a GUI console for the MTA, you will want to ensure that you have the HTTP monitor configured properly so that you can access it for monitoring your MTA. If there is nothing in the HTTP port field, put 7180 (or another port of your choosing).
  • 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.
  • On the GroupWise tab, change to the log settings. If you have a custom path for the log settings, remove it. While it is technically okay to make a new custom path for your Linux agent logs, unless you have an overriding reason to have the logs somewhere other than the default, it’s best to just leave this field blank.
  • On the GroupWise tab, change to the Message Log Settings tab. As above, delete any custom location you may have defined there.
  • If you use SSL to communicate between agents, you will need to regenerate your GroupWise SSL Certificate for this server and make the changes on the SSL settings tab.

 

You can find information on generating your SSL certificates for GroupWise at http://www.novell.com/documentation/gw8/gw8_admin/data/adqul6f.html. This information is for GroupWise 8.Similar information can be found for all versions of GroupWise, but the instructions for GroupWise 8 are the same as prior versions.

 

  1. After you have made all of the above changes, click OK to save the settings.

Configuring the MTA on Your New Linux Server

Now we will go back and configure the agent for your new Linux server. The configuration process will create a new startup file for the MTA, and configure the agent to launch upon startup.

In a terminal window, go back to the location where you extracted your GroupWise distribution above in “Preparing your New Linux Server”. Run the install script as root. For example:

gwlinux:/grpwise # ./install

 

  • Choose Install Products.
  • Choose GroupWise Agents.
  • Choose Configure Agents.
  • At the License Agreement screen, accept the license.
  1. The next screen will look very familiar to GroupWise administrators (see Figure 6-3). This is where we list the agents that will run on this server to create startup files and the startup script for Linux.

 

    1. Figurel-d7.tiffGroupWise Agents Configuration

 

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.

First, this screen is a template for creating new agent startup files (for example the cnc2.mta file), and for configuring your gwha.conf file. Let’s take the example of our groupwise system. Our domain is called CNC. If we want to create a new startup file for the CNC file, and place it in our gwha.conf (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 2-3 and enter the information for our domain.

    1. Enter the information for your domain, using the local Linux path (see Figure 6-4)
      1. Figurel-d8.tiffDomain Information

 

By entering this information, we are instructing the installation routine to create us a startup file called cnc2.mta with a –home switch of “/grpwisedomains/cnc2, place it in the /opt/novell/groupwise/agents/share directory and include the information in the gwha.conf file.

  1. After your domain information is entered, click next to move on to the startup screen.
  2. You will be asked if you wish for your agent to load on startup. This box is already checked, but really just looks like a red box. You will notice that if you click on the box, it becomes white (unchecked) and clicking again will recheck the box. It is advisable to have your agents load on startup.
  3. Click Exit to leave this setup, and then click the Exit icon (at the bottom right of the screen) to leave the GroupWise installation program.

 

When you perform these tasks, a startup file is created for the domain’s MTA, and if you chose to launch on startup, symbolic links were created in the proper run level directories to start the agent automatically. Looking at the /opt/novell/groupwise/agents directory you will see directories named bin, lib and share. Under bin you will see the agent executables, as well as default startup templates. Under the share directory are a couple of directories, and the cnc2.mta startup file that was created by our installation. Let’s run this agent now and see what it looks like.

Starting the GroupWise MTA with the GUI for Testing

The first time we start a new agent on a Linux server, we like to start it with a GUI console to test that everything is working properly. It’s important to know that you will not run your agents with the GUI console as standard practice. We will load our MTA up for the first time with the GUI console solely to verify that there are no problems with our installation.

The easiest way to start the GUI agent is as follows:

From a terminal window, change to the /opt/novell/groupwise/agents/bin directory. From here, type the following:

./gwmta –show @cnc2.mta &

This should bring up the agent screen as shown in Figure 6-5.

    1. Figurel-d9.tiffThe Linux MTA

 

If this domain owns any post offices, and you had them configured as “mapped” or “UNC” locations, the post offices will be closed, as you can see in this figure. If we choose Configuration|Status, we see that these post offices had their link configuration as “mapped” before. Now that we are on a different server, we need to fix this. Of course, if your MTA and POA were talking IP prior to the domain move, your post offices should come up and be just fine. This example is merely to show what might happen if you have direct links.

 

  1. Figurel-d10.tiffConfiguration Status showing Post Office Closed

 

  • Back in ConsoleOne (/usr/ConsoleOne/bin/ConsoleOne if you’ve closed it down), right-click on the domain and choose GroupWise Utilities|Link Configuration.
  • From the menu choose View|Post Office Links.
    1. Double-click on the Post Office that cannot be accessed, and fix the link. It should, of course, be a TCP/IP connection, pointing to the IP address and port on the old NetWare server. See Figure 6-7
      1. Figurel-d11.tiffChange the Link Configuration

 

If all goes according to plan, your MTA will now show your POA open. Verify all of the links for this MTA (other post offices and domains). We will leave the MTA loaded with the GUI Console now while we install and configure the GWIA.

Install the WebAccess software and configure the WebAccess Agent

Now that the MTA for this domain is up and running in testing mode, we will continue to install the WebAccess Agent software and configure the WebAccess Agent on this server.

In a terminal window, go back to the location where you extracted your GroupWise distribution above in Preparing Your Server. Run the install script as root. For example:

 

gwlinux:/grpwise # ./install

 

  • Choose Install Products.
  • Choose GroupWise WebAccess.
  • Choose Install WebAccess Agent. The software will install and you will be presented with an “OK” screen when the installation has finished.
  • Now choose Configure WebAccess Agent.
  • When prompted, accept the License agreement
  1. At the server information enter the information for your WebAccess Agent (See Figure 6-8).

 

    1. WebAccess Agent Server InformationFigurel-d16.tiff

 

 

  1. At the Domain Directory screen, put in the local Linux path location for your domain. Also verify the directory name for your WebAccess Agent.
  2. Next you must authenticate to your eDirectory tree via LDAP. This is necessary even if you are already logged into eDirectory in ConsoleOne. It is easier if your LDAP server allows for clear-text passwords. Otherwise you must check the “Use SSL” box and have your certificate available to this server.

 

TIP: If you need to temporarily allow access to your LDAP server without SSL, edit the LDAP Group for the LDAP server in ConsoleOne and uncheck the box that says “Require TLS for simply binds with password”. You can turn it back on afterwards. Of course, if you have easy access to the SSL Certificate on your Linux server, you will not need to bother with this.

 

  1. At the Gateway screen, you will see the name of your WebAccess, and you will be asked to enter the LDAP context for your GroupWise domain. You can browse for this if you like.
  2. It is likely that you will receive a notification that you already have a WebAccess Agent in this context. Clicking okay at this screen will allow you to use the existing configuration for your WebAccess Agent.
  3. Now, indicate that you want the WebAccess Agent to load at startup, and click Exit, and then exit from the GroupWise installation application.
  4. If you have special Access Control Rules defined, these are located in the gwac.db file. If you have moved your WebAccess Agent to this server, then these rules will have moved with you. If you are returning to this section from the Chapter on “Creating a New Domain on Linux to Relocate a Gateway”, then you need to copy this gwac.db file from the original gateway directory to the WebAccess Agent’s gateway directory on the new Linux server.

 

Starting the WebAccess Agent with the GUI for Testing

As with the MTA, the first time we start a new WebAccess Agent on a Linux server, we like to start it with a GUI console to test that everything is working properly. It’s important to know that you will not run your agents with the GUI console as standard practice. We will load our WebAccess Agent up for the first time with the GUI console solely to verify that there are no problems with our installation. That said, one can hardly call the WebAccess console a “GUI” – it is text based, but gets the job done.

The easiest way to start the GUI agent is as follows:

From a terminal window, change to the /opt/novell/groupwise/agents/bin directory. From here, type the following:

./gwinter –show @webac80a.waa &

This assumes that the startup file that was created is called webac80a.waa

This should bring up the agent screen as shown in Figure 6-9.

    1. WebAccess Agent Text ConsoleFigurel-d17.tiff

 

As long as the WebAccess Agent looks okay, we can unload both the GWINTER and the MTA (which is still loaded in GUI mode above), and reload them as daemons. To unload the GWINTER, press Control-C in the text console window. To unload the MTA, press F7 in the GUI Console.

 

Starting Your MTA and WebAccess Agent as Daemons

When you configured your MTA above, a couple of scripts were created for GroupWise. One is in the /etc/init.d directory named, and can only be called from that directory. The other is rcgrpwise, which is essentially in your “search path” and can be called from any location. If you go to a terminal window and type

rcgrpwise start

your MTA and WebAccess Agent will be launched. The options for this script are:

  • rcgrpwise start (starts the agents)
  • rcgrpwise stop (stops the agents)
  • rcgrpwise status (shows the status of the agents).

 

The rcgrpwise script handles MTAs, POAs, GWIAs and WebAccess Agents. We will see more on how the rcgrpwise script works in the “Tips and Tricks for GroupWise on Linux” chapter.

Your domain is moved and your MTA and WebAccess Agent are up and running. If the WebAccess Application will be on this server (and Linux is a fine place for the WebAccess Application, we’ll install and configure that now.

Loading the HTTP Monitor

Now, since we have enabled out HTTP Monitor, we can verify that both the MTA and the GWIA are loaded by going to the monitor screens in a browser. For the MTA, go to http://server:7180. For the GWIA, go to http://server:7211.

 

Install and Configure the WebAccess Application Software

In a terminal window, go back to the location where you extracted your GroupWise distribution above in Preparing Your Server. Run the install script as root. For example:

 

gwlinux:/grpwise # ./install

 

  1. Choose Install Products.
  2. Choose GroupWise WebAccess.
  3. Choose Install WebAccess Application. The software will install and you will be presented with an “OK” screen when the installation has finished.
  4. Now choose Configure WebAccess Application.
  5. When prompted, accept the License agreement
  6. At the Gateway Directory screen, enter the location of the WebAccess Agent that you installed above.
  7. As long as you have standard installations of Apache and Tomcat, the information in the Web Server Information screen should be correct. Otherwise, enter the appropriate information for your instances of Apache and Tomcat. Click Next.
  8. Next you must authenticate to your eDirectory tree via LDAP. This is necessary even if you are already logged into eDirectory in ConsoleOne. It is easier if your LDAP server allows for clear-text passwords. Otherwise you must check the “Use SSL” box and have your certificate available to this server.

 

TIP: If you need to temporarily allow access to your LDAP server without SSL, edit the LDAP Group for the LDAP server in ConsoleOne and uncheck the box that says “Require TLS for simply binds with password”. You can turn it back on afterwards. Of course, if you have easy access to the SSL Certificate on your Linux server, you will not need to bother with this.

 

It is likely that you will receive a notification that you already have a WebAccess Objects in this context. Clicking okay at this screen will allow you to use the existing configuration for your WebAccess Objects.

Restart Apache and Tomcat and your WebAccess server should be operational.

 

You can test your WebAccess by going to https://yourserver/gw/webacc (or https://yourserver/servlet/webacc on GroupWise 6.5).

Next Sections