Novell is now a part of Micro Focus

Implementing a High Availability Web Access Solution with GroupWise 6

Articles and Tips: article

Tay Kratzer
Premium Support Engineer
Novell, Inc.

01 Dec 2002


This AppNote describes a high availability Web Access solution that allows GroupWise 6 users to access their e-mail and other collaboration tools via the Web.


Topics

GroupWise WebAccess, GroupWise implementations, high availability, e-mail Web access

Products

GroupWise 6

Audience

network administrators, installers, designers

Level

intermediate

Prerequisite Skills

familiarity with e-mail and Web access concepts

Operating System

NetWare 5.1 and 6.x

Tools

none

Sample Code

no

Introduction

Accessing the many features of Novell GroupWise via the Web is becoming more and more important in many organizations. By using GroupWise WebAccess, many GroupWise sites are driving down their support costs for remote users, and using WebAccess in portals. With the fuller feature set of the GroupWise 6.x WebAccess clients, some customers-particularly the newest GroupWise customers-have opted to only use the GroupWise WebAccess client.

This new trend is not without some potential pitfalls though. By funneling users through a WebAccess solution, the WebAccess software becomes a single point of failure. Many seasoned GroupWise administrators have struggled to keep their WebAccess solution stable, largely due to abends on the WebAccess Agent, or over-utilization of the WebAccess Agents.

This AppNote is based upon my own experiences in working with customers to resolve these pitfalls. With the advent of the GroupWise 6 WebAccess software, Novell has made significant enhancements that, when used with good design, will eliminate the WebAccess pitfalls of the past. I recommend that you read this document in its entirety. It covers many helpful points about architecture, which you'll need to fully understand in order to adapt the solutions discussed in this document to your own GroupWise system.

WebAccess Problems at ACME

As the framework for this AppNote, I will use a fictitious company called ACME. GroupWise WebAccess is gaining popularity at ACME, particularly with the new features available in GroupWise 6 WebAccess. But unfortunately WebAccess has not been stable, and users complain that its performance has been sluggish at times. A couple of times a week, the GroupWise administrator gets calls that users can't view attachments. After further investigation, the administrator discovers the problem: the GroupWise WebAccess Agent (GWINTER.NLM) had abended while viewing an attachment, and now the WebAccess viewing engine is no longer working.

Until now, the only solution has been to bring down the server running the GroupWise WebAccess Agent. But bringing down the server after abends, or even for regular maintenance, is difficult because the WebAccess Agent is servicing users across several GroupWise post offices. Communicating downtime for WebAccess to users is virtually impossible, particularly when the WebAccess Agent server needs to be taken down and rebooted promptly to allow users to view attachments again.

Here are the features ACME wants in their WebAccess solution:

  • System available 99.99% of the time

  • Faster response to end-users

  • Allow for bringing down the server running the WebAccess Agent, and yet still maintain the 99.99% up-time

  • Allow users to be able to view attachments even when the GroupWise WebAccess Agent abends, without the need to bring down the WebAccess Agent and thus bump all users out of WebAccess

Overview of the Solution

Here's a quick synopsis of the solution implemented at ACME to create a GroupWise 6 WebAccess high availability system:

  • Multiple WebAccess Agents were configured.

  • The GroupWise WebAccess Application was configured to use multiple WebAccess Agents located in close proximity to GroupWise post offices.

  • The WebAccess Application is designed to failover to another WebAccess Agent seamlessly, if one becomes unavailable.

  • All WebAccess Agents are loaded into a protected memory space that restarts after an Abend.

The best part about these solutions is that they don't necessarily require more hardware beyond what you have already allocated to support GroupWise WebAccess.

In order to get to the high availability result at ACME, two solutions were employed. They are explained under the sections titled "Configuring Regional and Failover WebAccess Agents" and "Loading the GroupWise WebAccess Agent into Protected Memory" below. As I explain each of these, I will describe the architecture behind each of the solutions so that you can understand what's going on. This understanding will help you to adapt this high availability GroupWise 6 WebAccess solution to your own GroupWise system.

Configuring Regional and Failover WebAccess Agents

Before you can understand the notion of multiple GroupWise WebAccess Agents, you must understand a little about the system architecture. GroupWise WebAccess has two executables, referred to as the GroupWise WebAccess Application and the GroupWise WebAccess Agent.

Here are some pertinent aspects of the WebAccess Application:

  • Runs on the Web server as a servlet

  • Configured through ConsoleOne

  • Generally very stable

  • Can run on a variety of Web servers

Here are some pertinent aspects of the WebAccess Agent:

  • Runs on either a NetWare server or a Windows server

  • Configured through ConsoleOne

  • Is a GroupWise client, without an interface

The WebAccess Agent is the workhorse of the two executables. Of all the GroupWise Agents (including the Post Office Agent, Message Transfer Agent, and GroupWise Internet Agent), it is the most likely to cause an Abend in a NetWare server.

Understanding a User's WebAccess Session

Here's what happens when a user runs his/her browser and gets a session with GroupWise WebAccess.

  1. At a Web page, the user logs into WebAccess via a page provided by the WebAccess Application.

  2. The WebAccess Application passes the password and some security credentials back to the WebAccess Agent.

  3. The WebAccess Agent passes the user's password back to the user's GroupWise Post Office Agent (POA).

  4. The WebAccess Agent actually appears to the GroupWise POA as though it's a GroupWise Client. The WebAccess Agent effectively maintains a client connection with the GroupWise POA, retrieving data, manipulating it, and streamlining it for the WebAccess Application.

  5. The WebAccess Application plugs the data it gets from the WebAccess Agent into templates on the Web server, and feeds it to the user's Web browser.

Concepts for Configuring Multiple WebAccess Agents

You can install more than one GroupWise WebAccess Agent in your system. A WebAccess Agent needs to be configured under a GroupWise domain, and must have access to the WPDOMAIN.DB file of that domain. It is recommended that a WebAccess Agent executable (either GWINTER.NLM or GWINTER.EXE) be running on the same server that houses the WPDOMAIN.DB file. Many customers create a special-purpose GroupWise secondary domain just for containing the GroupWise WebAccess Agent--this is a good practice.

The GroupWise WebAccess Agent (GWINTER) requires a chatty conversation with the GroupWise POA, which is indicative of a standard GroupWise Client/Server connection. The WebAccess Agent then sends small amounts of data back to the WebAccess Application. Because the conversation between the WebAccess Agent and the POA takes a lot of communication, it is best to have the WebAccess Agent in close network proximity to the POA that is servicing the Client/Server connection. In fact, end-user performance is increased by up to 50% when GWINTER is on the same network switch as the POA servicing the Client/Server connection to GWINTER.

Bearing in mind what you know now about placement of WebAccess Agents, imagine that ACME has three major facilities: one in New York, one in Missouri, and one in California. Each of these facilities might have a few post offices. Using the best design, you would place a WebAccess Agent in New York, Missouri, and in California.

With GroupWise 6, there is a way to indicate that "the Default WebAccess Agent for this GroupWise post office or domain is . . ." and you can select a WebAccess Agent that you know has a good network link speed to the POA servicing that particular post office. The WebAccess Application uses the Default WebAccess Gateway setting to determine which WebAccess Agent it should use to create its session for the user. If all is configured correctly, it will use the WebAccess Agent that has the best link speed to the POA.

In the next section you will learn that, by having multiple WebAccess Agents, your WebAccess Application will look for the best WebAccess Agent to communicate with. If the "best" WebAccess Agent is down, there's no problem. The Application just reads its Provider List and finds the next available WebAccess Agent. Furthermore, if one WebAccess Agent goes down while users are using it, the Application fails-over the users' sessions to the next WebAccess Agent in the provider list. This transition is seamless to the users.

Configuring the WebAccess Application

The GroupWise WebAccess Application is configured through ConsoleOne, via an object called the "GroupWiseProvider". This object is new to GroupWise 6 and is stored in eDirectory/NDS, not in the GroupWise WPDOMAIN.DB file. Configuration changes made to the GroupWiseProvider object are held in eDirectory and also in two *.CFG files. The WebAccess Application reads these *.CFG files in order to know how to function. The *.CFG files are located on the server running your Web server software, in the Novell\WebAccess directory. They are as follows:

  • WEBACC.CFG - An ASCII text file that's pretty easy to read and understand.

  • COMMGR.CFG - A binary file which holds an encryption key and information about the first WebAccess Agent that the WebAccess Application should attempt to contact. Besides being found in the Novell\WebAccess directory on the Web server, a copy is also found in <domain>\WPGATE\<WebAccess Gateway Directory>. When ConsoleOne modifies the COMMGR.CFG file on the Web server, it also makes a copy of it in the WebAccess Gateway Directory.

The GroupWise 6 WebAccess Application can be configured with a list of one or more WebAccess Agents by editing the GroupWiseProvider object and linking the WebAccess Application to any of the WebAccess Agents that are currently configured in the system.

ACME's System Configuration

Now that you've gotten a whole lot of theory, let's look at ACME's GroupWise system configuration both before and after implementing the high availability solution.

Before the Solution. Here's a simple breakdown of the ACME system before the GroupWise 6 WebAccess high availability solution.

Link speeds between regions are slow, while link speeds within a region are fast. So link speeds from New York to California are slow, but link speeds from Los Altos, California to Palo Alto, California are fast.

The following table shows other configuration details.


Primary Domain

ACME_PRIMARY

Secondary Domain with 10 Post Offices in 3 major regions and WebAccess Agent "HQ_WEB_AGENT" running as an NLM (GWINTER.NLM) on the same server as the domain. The regions are New York, Missouri, and California. This domain is located in New York.

ACME_HQ

Secondary Domain with GWIA

ACME_GWIA

WebAccess Application on a Web server in the DMZ (you don't see this server in the GroupWise View because Web servers aren't in a GroupWise View)

WEBMAIL.ACME.COM

Figure 1 shows the ACME system in its original state.

ACME GroupWise system view before the WebAccess high availability solution.

Here are the drawbacks to this configuration:

  • If GWINTER.NLM Abends or if the server needs to rebooted or serviced, all users lose their WebAccess session.

  • Users in New York have acceptable performance, while users in Missouri and California have much poorer performance because there are only slow network links from New York to Missouri or California.

  • Many times users contact the administrator to tell him that they cannot view attachments.

After the Solution. Here's a quick look at the ACME system after the GroupWise 6 WebAccess high availability project.

The following table shows the configuration details.


Primary Domain

ACME_PRIMARY

Secondary Domain with 10 Post Offices in three major regions and WebAccess Agent "HQ_WEB_AGENT" running as an NLM GWINTER.NLM) on the same server as the domain. The regions are New York, Missouri, and California. This domain is located in New York.

ACME_HQ

Secondary Domain with GWIA

ACME_GWIA

WebAccess Application on a Web server in the DMZ

WEBMAIL.ACME.COM

Secondary Domain with a WebAccess Agent GWINTER.NLM) running on the same server as ne of the Post Offices in New York

ACME_NY_WEBDOM

Secondary Domain with a WebAccess Agent GWINTER.NLM) running on the same server as ne of the Post Offices in Missouri

ACME_MO_WEBDOM

Secondary Domain with a WebAccess Agent GWINTER.NLM) running on the same server as ne of the Post Offices in California

ACME_CA_WEBDOM

Figure 2 shows the ACME system in its reconfigured state.

ACME GroupWise system view after the WebAccess high availability solution.

Here are the advantages gained from implementing the high availability solution:

  • GroupWise WebAccess is virtually never down, and bringing down a server that is running a WebAccess Agent is no longer a concern. If a WebAccess Agent goes down, the Application automatically switches the users over to one of the four WebAccess Agents available to it. Users don't even need to re-login.

  • WebAccess for users in Missouri and California is just as fast as it is for New York users.

  • Users no longer complain that they cannot view attachments.

GroupWise 6 WebAccess High Availability Configuration Steps

The first three steps are not explained in any detail, because they have to do with creating domains and installing GroupWise WebAccess. There are wizards for all three of these steps and adequate documentation is provided in the Novell's GroupWise 6 Administrator's Guide.

  1. Install the GroupWise 6 WebAccess Application on the Web server. When you run the install for GroupWise 6 WebAccess, you have the option to install just the WebAccess Application. That is what you need to do in this first step. It doesn't matter what platform you choose; however, configuration is a little easier on a NetWare server. (This AppNote was written with the WebAccess Application installed on a NetWare 6 server running the Apache Web Server.)

  2. Install new special-purpose GroupWise secondary domains that will house the three new WebAccess Agents. These domains will be called ACME_ NY_WEBDOM, ACME_MO_WEBDOM, and ACME_CA_WEBDOM. Make sure these domains are functioning, with MTAs loaded to service the domain.

  3. Install a GroupWise WebAccess Agent associated with each of the new special purpose domains. When you run the install for GroupWise 6 WebAccess you have the option to just install the WebAccess Agent, that is what you need to do in this step, and ACME will run through this install three different times.

    Now that the special purpose domains and the additional WebAccess Agents have been installed, the WebAccess Application needs to be configured to work with the WebAccess Agents.

  4. Locate the GroupWiseProvider object, as shown in Figure 3. You will not be able to find the GroupWiseProvider object in the GroupWise View. These objects are only available to you in the eDirectory/NDS browser view in ConsoleOne.

    GroupWiseProvider object.

    Note: The GroupWise 6 Support Pack 2 snap-ins to ConsoleOne had a defect which will not allow you to edit the GroupWiseProvider object. Until GroupWise 6 Support Pack 3, you will need to use the Field Test File for GroupWise 6 Support Pack 3 ConsoleOne snap-ins. This code is located at the following location: http://support.novell.com/cgi-bin/search/searchtid.cgi?/2963587.htm

  5. Select to view the GroupWiseProvider object's properties. When the properties window comes up, there is generally one WebAccess Agent listed (see Figure 4). In the case of ACME, the only listed WebAccess Agent is called HQ_WEB_AGENT.

    Properties page of the GroupWiseProvider object.

    The WebAccess Agent listed first does the following:

    • Answers the "Get Best Agent" call that the WebAccess Application submits when a user first logs in. This call is used to help the WebAccess Application determine if a Default WebAccess Agent has been defined for the post office of the user that is logging in.

    • Handles sessions created when a user proxies to another mailbox.

    • Becomes the first WebAccess Agent for the WebAccess Application to failover to if it cannot contact, or has lost contact with, a WebAccess Agent designated as the Default WebAccess Agent for a post office.

  6. Click the Add button to add the other three WebAccess Agents to the provider list. In the browse dialog that comes up, you will need to browse your tree to find the GroupWise domains that contain the WebAccess Agents created earlier. Select the WebAccess Agents one by one. After adding all the WebAccess Agents, click the Apply button to apply the changes to the WEBACC.CFG file.

    After adding the three agents to the GroupWiseProvider's list of agents, the GroupWiseProvider's property page is populated with all four WebAccess Agents as shown in Figure 5.

    GroupWise Provider list with all WebAccess Agents listed.

    At this point the WebAccess Application is configured so it knows about the agents available to it.

Configuring the Encryption Key. There is another detail involving the WebAccess Application to WebAccess Agent communication. It's the "encryption key". You must make sure that the WebAccess Application and all the WebAccess Agents in your GroupWise system are using the same encryption key. The WebAccess Application defaults to using the same encryption key used by the first WebAccess Agent listed in the GroupWiseProvider object's list of WebAccess Agents. So the goal is this: you need to copy the encryption key from the first WebAccess Agent in the provider list to each of the other WebAccess Agents in the provider list. This is a simple copy and paste project.

  1. On the GroupWiseProvider object's Properties page, highlight the first WebAccess Agent in the provider list. In the case of ACME, this is "HQ_WEB_AGENT.ACME_ HQ.NY.AMERICAS". Click the Edit button. The encryption key will be displayed on the next page, as shown in Figure 6.

    The encryption key of the Default WebAccess Agent.

  2. Copy the string of characters in the Encryption Key field to the Windows clipboard (block the characters and press <Ctrl>-<C> to copy). Click the Cancel button to dismiss this window.

  3. Edit each of the WebAccess Agents by removing the string of characters in the Encryption Key field, and pasting in the Encryption Key that you copied to your Windows clipboard earlier. (Use the <Ctrl>-<V> keystroke to paste from the Windows clipboard.)

  4. Since you have reconfigured the WebAccess Agents to use a new Encryption Key, you must stop and restart your WebAccess Agents.

Now your WebAccess Application is completely configured to enable it to use all the GroupWise WebAccess Agents in the provider list. However, there are still some things that need to be done in ConsoleOne to configure the WebAccess Agents.

Designating the Default WebAccess Agent. Now at each post office, the Default WebAccess Agent needs to be designated. Each post office will need to be individually edited in order to designate the Default WebAccess Agent. If you know that you want all the post offices on a particular domain to use the same WebAccess Agent, you could just designate the Default WebAccess Agent at the domain level, without having to designate it individually at the post offices. At ACME, this will not work because different post offices in the same domain will use different Default WebAccess Agents.

  1. Highlight each post office, and edit the properties of the post office.

  2. Go to the "Default WebAccess" property page. Click the override checkbox, and then browse to and select the appropriate WebAccess Agent to service that post office.

    Figure 7 shows that the Los Altos, California post office in the ACME system is using the CA_WEB_AGENT WebAccess Agent as its Default WebAccess Agent.

    Defining the Default WebAccess Agent for the Los Altos post office.

At this point in the project, ACME has accomplished the following:

  • Creation of regionalized WebAccess Agents for better performance

  • A failover solution such that, if a WebAccess Agent is not available, the WebAccess Application will failover to another Agent.

The following potential pitfalls still exist at this point:

  • If GWINTER.NLM Abends on an attachment, WebAccess remains running, but users cannot view attachments.

  • If GWINTER.NLM Abends for any other reason, the Abend affects the rest of the server. The server will need to be taken down at some time.

Loading the GroupWise WebAccess Agent into Protected Memory

Now ACME is going to configure the GroupWise WebAccess Agent to run in protected memory. This will eliminate the two remaining pitfalls mentioned in the prior paragraph. First, though, let's review some architecture and theory.

Architecture and Theory

Beginning with NetWare 5, NetWare has had a handy feature called protected memory. By loading an NLM into protected memory, if the module abends it only abends in that protected memory space, having no affect on the rest of the server's processes. Loading NLMs into protected memory is a popular practice in environments in which customers are using Novell's Clustering Services, but it has broader application than just with clustering.

The benefits my customers have enjoyed by using protected memory in conjunction with the WebAccess Agent are the following:

  • Protected memory causes the WebAccess Agent to automatically unload and reload on an abend.

  • When the WebAccess Agent unloads and reloads on an abend, it does so very quickly (the longest it's been unavailable is 10 seconds).

  • When the WebAccess Agent abends, it does not cause the rest of the server to be unstable, giving my customers confidence in putting the WebAccess Agent on servers that also house GroupWise post offices.

My customers and I have configured WebAccess Agents in protected memory on dozens of servers without any problems, although we do find that it takes some fine tuning on some servers. I would not recommend using this solution on any server running less than NetWare 5.1 SP2 or NetWare 6 SP1. I have not tested protected memory on NetWare 5.0; I just hear it got a lot better in NetWare 5.1.

Some customers have complained that if a NetWare server has several abends, it will stop initiating the protected memory space and abend one more time. None of my customers have experienced this problem, so I have not personally seen the problem.

As of this writing, Novell's OS engineering group is aware of this problem and has created a patch to resolve the problem. The name of the patch is "NetWare 5.1 and 6.0 Memory Protection Update". Currently the patch can be found on Novell's support Web site at the following location:

http://support.novell.com/cgi-bin/search/searchtid.cgi?/2964068.htm

Configuration Steps

Follow these steps to configure each server running a GroupWise WebAccess Agent. The WebAccess Agents are the executables that are problematic, not the WebAccess Application. This AppNote focuses only on running the WebAccess Agent in protected memory.

This solution is a simple one. It consists of changes to the NetWare server's STARTUP.NCF and AUTOEXEC.NCF files, and the creation of three new files:

  • GWINTER.CFG, which is the configuration file for GWINTER.NLM

  • STARTGWA.NCF, which is used to load GWINTER.NLM (the executable for the WebAccess Agent)

  • STOPGWA.NCF, which is used to unload GWINTER.NLM if you ever need to do so

Change to STARTUP.NCF. Add the following command in the server's STARTUP.NCF file:

SET MEMORY PROTECTION NO RESTART INTERVAL = 0

Note: You do not have to reboot the server to have this setting take effect. This is a setting that goes immediately into effect if you enter the above command at the system console prompt.

Creating the GWINTER.CFG File. Make a text file called GWINTER.CFG and place it in the SYS:SYSTEM directory. This file should contain the following options:

/ph=<path to the domain>\wpgate\<webaccess directory>

/user=<anything> (it doesn't matter if this is a valid user or not)

/password=<anything> (it doesn't matter if this is a valid password or not)

/LOGDISKON

For example, your SWINTER.CFG file might look like this:

/ph=FS1\VOL1:WEBDOM\WPGATE\WEBACC6user=MICKEYpassword=MINNIELOGDISKON

You can add other switches in this file as needed. To discover the other switches available to GWINTER, load GWINTER.NLM with the "/?" switch.

Creating the STARTGWA.NCF File. Create an NCF file called START- GWA.NCF and save it in the SYS:SYSTEM directory. It should contain two lines exactly as shown below (in other words, this is not a typo-do not use an equals sign in the "Protection restart . . ." command):

LOAD ADDRESS SPACE =GW1 GWINTER @GWINTER.CFGROTECTION RESTART GW1

Creating the STOPGWA.NCF File. Create an NCF file called STOPGWA.NCF and save it in the SYS:SYSTEM directory. It should contain the following lines:

UNLOAD ADDRESS SPACE =GW1 GWINTERNLOAD KILL ADDRESS SPACE=GW1

Changes to the AUTOEXEC.NCF File. In the file server's AUTOEXEC.NCF file, remove any prior references to the GroupWise WebAccess Agent and reference the STARTGWA.NCF file. Load the GroupWise WebAccess Agent first, then the GroupWise MTA (or vice versa-I have seen it work either way).

One tip I can pass along from experience is that you need to delay the loading of the STARTGWA.NCF file from the loading of the GroupWise MTA by about 20 seconds. To do this, you can use the "?CLS" command twice, since this command by default makes the server pause 10 seconds and then clears the screen.

Note: You can load the STARGWA.NCF and the GRPWISE.NCF batch commands manually one right after the other after the server is booted, without having to space them out. It is only when the commands are both loaded in the AUTOEXEC.NCF file that you need to space them out by 20 seconds.

I have found that if the STARTGWA.NCF and the loading of the GroupWise MTA are not spaced out from each other by about 20 seconds when loaded during a server's boot-up, GWINTER.NLM will not automatically reload if it abends. You can test to see if this potential problem exists during the testing phase described next.

Testing Phase.  Perform the following steps to test for potential problems with GWINTER.NLM not reloading automatically after an abend.

  1. Reboot the server to make sure that when the WebAccess Agent is loaded in protected memory from an *.NCF referenced in the AUTOEXEC.NCF, and the MTA is loaded from an *.NCF also referenced from the AUTOEXEC.NCF file, that the WebAccess Agent will actually restart when it abends. After rebooting the server, proceed to Step 2.

  2. To test the WebAccess GWINTER abending, try to identify a bad document that is likely to abend WebAccess. Generally, you can file bad documents in the WPGATE\WEBACC directory. These files have a *.CMC extension, but they are in their native file format. Attach one of these files to an e-mail message, and then try to view it in GroupWise WebAccess. Confirm that GWINTER unloads and reloads as expected.

  3. If GWINTER does not reload into protected memory, try this. Remove references in the AUTOEXEC.NCF to the STARTGWA.NCF and the GRPWISE.NCF (or whatever command you use to load the MTA), and then reboot the server. Run the STARTGWA.NCF and the GRPWISE.NCF file, and see if GWINTER will reload automatically on an abend. If this does work (and it didn't work when loading the *.NCF files from the AUTOEXEC.NCF), then you must space out the loading of the STARTGWA.NCF batch file and the GRPWISE.NCF batch file by 20 seconds.

Important Tips

  • Do not attempt load the GroupWise MTA into the same protected memory space as the GroupWise WebAccess Agent. Just load it normally, and not in a protected memory space. Or you can try loading the MTA into a different memory space if you have a need to do so.

  • The WebAccess agent should be configured to speak to all post offices via Client/Server connections to the POA, even if the post office is on the same server as the WebAccess Agent.

  • Be sure to remove any other references to loading the GroupWise WebAccess Agent from the AUTOEXEC.NCF file.

  • If you need to bring down GWINTER, do not use the <F7> function key. Use the STOPGWA.NCF batch command file to unload GWINTER from protected memory.

What Happens When the Agent Loads in Protected Memory

Let me help you envision what happens when you have the WebAccess Agent loaded in protected memory. I will explain it from the viewpoint of what happens in the ACME system.

  1. A user, Jeff Griffin, on the Los Altos post office logs into GroupWise WebAccess. The default WebAccess Agent defined at the post office level is used, and so the WebAccess Agent named "CA_WEB_AGENT" is being used for Jeff's session.

  2. Jeff attempts to view an MS-Word document that abends the WebAccess Agent "CA_WEB_AGENT".

  3. The NetWare operating system unloads the GWINTER.NLM from the protected memory space GW1, and then re-loads it in a matter of 5 seconds.

  4. Jeff is not knocked out of GroupWise WebAccess. He just gets a blank page in his browser where it was trying to view the document that abended the server.

Now suppose one more thing. Let's imagine during that 5-second downtime, someone else on a California post office in the ACME system is trying to interact with WebAccess. When the WebAccess Application cannot contact the WebAccess Agent within second, it just fails over to the top WebAccess Agent on the provider list, seamlessly logging the user into that Agent and allowing it to complete the action the user took in his/her WebAccess session. The user is now using the HQ_WEB_AGENT for the balance of their session. After the 5 seconds have gone by and the CA_WEB_AGENT is reloaded, all other users just maintain their session with the CA_WEB_AGENT as long as they did not try to open something or take an action that required the WebAccess Agent during that 5-second period.

Fine Tuning Details

This section describes some of the fine tuning parameters on both your WebAccess Agent and your WebAccess Application that you will want to consider. You will also want to make sure that you have fine tuned your Web server; however, instructions for doing so are beyond the scope of this document.

Fine Tuning the WebAccess Application

  1. Edit the GroupWiseWebAccess object, shown in Figure 8.

    GroupWiseWebAccess object.

  2. Go to the Applications > Templates Property Page. Enable Template Caching and change the size to 4096 KB.

Fine Tuning the WebAccess Agent

Follow these steps to edit the properties of each WebAccess Agent you have:

  1. On the WebAccess Settings property page, change the maximum threads to a number that you feel is adequate. For most of my customers, I change this value to 50 threads.

  2. Go to the Post Office Links Settings property page and make sure the links to your post offices are correct. Also make sure they are only using Client/ Server connections to the POA.

  3. Go to the GroupWise Log Settings property page and set the logging to Verbose.

Miscellaneous Tips

Here are some miscellaneous tips and things to be aware of when implementing a high availability GroupWise WebAccess solution. Most of these are based on questions from customers.

Maximum Number of WebAccess Agents

Many customers have asked me how many WebAccess Agents they can create in their GroupWise system. I don't know for sure, but one of my customer's systems has 30 WebAccess Agents.

Compatibility with GroupWise 5.5 EP WebAccess

The solution outlined in this AppNote is specifically for use with GroupWise 6 WebAccess, as the WebAccess Application is required in order for it to work. However, I have successfully used it in conjunction with the 5.5 EP WebAccess Agent. Here are some important guidelines for making this work:

  • Do not allow the GroupWise 5.5 EP WebAccess Agent to be the first in your provider list. This will break the proxying capabilities available to GroupWise 6 users.

  • Configure the WebAccess Agents using all the same techniques explained in this document: change the encryption key, load it into protected memory in the same manner, and so on.

The July 2002 issue of Novell Connection magazine talks further about mixing GroupWise 5.5 EP WebAccess with GroupWise 6 WebAccess. You can access this content on the Web at http://www.ncmag.com.

WebAccess Agents: Provider List vs. Default Agent

All WebAccess Agents must be listed in the Provider list of the GroupWise- Provider object. When you create a new WebAccess Agent, put it in the provider list. Don't just designate it as a Default WebAccess Agent.

Changing the Default WebAccess Agent

If you change the Default WebAccess Agent for a particular domain or post office, you do not need to bring down either the WebAccess Application or the WebAccess Agent.

Adding a WebAccess Agent to the Provider List

When you add a WebAccess Agent to the provider list, you do not need to bring down the WebAccess Application (unload and reload the web server). The WebAccess Application will reread the WEBACC.CFG file dynamically.

WebAccess Agent on the Windows Platform

In this AppNote we didn't talk about using a GroupWise WebAccess Agent on the Windows platform. You can use a Windows-based GroupWise WebAccess Agent in the mix among the WebAccess Agents on the NetWare platform. The only disadvantage the WebAccess Agent has when running on the Windows platform is that the protected memory schemes explained in this AppNote are not available to you. That said, my experience with the WebAccess Agent on the Windows platform is that it is very stable.

WebAccess Application on a Windows-Based Web Server

Configuring the WebAccess Application on a Windows-based Web server may require you to run ConsoleOne from that Windows server. The reason for this is that there are configuration files that must go on the hard drive of the Windows server.

Multi-Processor Performance

In my testing I have found that SMP (Symmetric MultiProcessing) does enhance the performance of the GroupWise WebAccess Agent, even on the NetWare 5.1 platform.

Conclusion

This AppNote has outlined the implementation of a high availability GroupWise 6 WebAccess solution. It has provided architectural concepts and configuration details that you can adapt for your own GroupWise WebAccess system.

For additional information, refer to the author's Novell's GroupWise 6 Administrator's Guide and other GroupWise 6 guides available at http://www.caledonia.net.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates