Configuring the WebAccess Agent Subcomponents

As already explained, there are three main components of WebAccess: the Agent, the Document Viewer, and the Application. To be technically correct, the WebAccess Application refers to several subcomponents that work together to make up the WebAccess Application. One of these components is referred to sometimes as the servlet component, and the others are referred to as the service provider components. These two sets of components work together in regard to the WebAccess Application.

You might have noticed that there was an option called the WebPublisher Application. Think of the WebPublisher Application as a mirror piece to the WebAccess Application with minor differences. They both perform the same functions, and they both talk to the same WebAccess Agent(s). The WebPublisher Application is used strictly for GroupWise Document Management access through a web interface. It does not retrieve users' mail, appointments, tasks, and so on.

Before discussing the next few components of the WebAccess gateway, let's take a look at what these additional objects are actually called:

• GroupWiseWebAccess object

• GroupWiseWebPublisher object

• NovellSpeller object

• GroupWiseDocumentProvider object

• GroupWiseProvider object

• LDAPProvider object

These six objects exist exclusively in the eDirectory tree and can therefore not be found in the GroupWise view. These objects are located in the context specified during the install of the WebAccess Application or WebPublisher Application. (Remember that this context might be under the GroupWise eDirectory domain object. They are not necessarily associated with a domain and do not exist in the WPDOMAIN.DB databases.) These objects are used to configure and administer the GroupWise Application pieces of WebAccess. Because GroupWise 7 offers many more features in WebAccess than previous versions, these objects are used as a better way to manage these functions. Also, because GroupWise WebAccess allows you to service multiple WebAccess Agents from a single WebAccess Application install, there has to be a way to manage just the WebAccess Application pieces of the picture. Having said that, the following discussion of the GroupWise WebAccess objects will help you understand how these all relate to the big picture of WebAccess.

GroupWise WebAccess Object

The GroupWise WebAccess object is the main component of the WebAccess Application. You can think of this object as being the WebAccess Application object that loads as a servlet on the web server. Through this object, you configure many of the settings that will affect the user's connection to WebAccess. This is the object that allows you to configure how a user interacts with the WebAccess gateway. Feel free to pull up the properties of your own GroupWise WebAccess object in your eDirectory tree and follow along.

To find the GroupWise WebAccess object, go into your eDirectory tree and highlight the GroupWise domain that you installed GroupWise WebAccess to. Figure 11.15 shows the location of the GroupWise WebAccess object in the wwwidgets system. The GroupWise WebAccess subcomponents discussed in this section are not available from the GroupWise view in ConsoleOne.

Figure 11.15. Locating the WebAccess Application objects

When you edit the GroupWise WebAccess object, you can configure the following options.

Application/Environment Property Page

From the Application/Environment property page it is possible to define some of the basic environment settings for the WebAccess Application object. These are the settings beneath this page are:

• Configuration File: This is the path to the WEBACC.CFG file. The WEBACC.CFG file contains all the configuration information regarding the GroupWise WebAccess object. This is a text file that can be viewed from any text editor. You can manually edit this file; however, it's kind of an all-or-nothing prospect. If you do edit the WEBACC.CFG manually, the changes you make are not written to eDirectory. But then when you try to edit the WebAccess Application from the ConsoleOne snap-ins, sometimes the snap-ins get confused and the WEBACC.CFG is configured incorrectly. On a NetWare server the WEBACC.CFG file is typically off of the SYS: volume in the Novell\WebAccess directory. On a Linux server it is typically at the path /opt/novell/groupwise/webaccess.

• File Upload Path: This is the path to which attachments are uploaded to the web server when a user attaches a file to a newly composed email from WebAccess. As soon as the user clicks OK to attach a file, WebAccess begins uploading it to this directory. This allows the upload to be taking place in the background so that the user can continue to compose the mail message. After the message is sent or cancelled, the uploaded file is deleted from this upload directory.

• Logout URL: Here you can enter an URL that a user will be sent to when logging out of the WebAccess client. You can enter any URL here, and the user's browser will be directed there upon logging out. This is very handy if you want to send the user to a particular website upon exiting.

Together, these three settings allow you to configure the paths employed by the WebAccess Application object.

Application/Log Settings Property Page

The Application/Log Settings property page is where you can configure the log settings for the WebAccess Application. Rarely will you need to access the Application's log files. It's the WebAccess Agent's log files that are generally of interest.

Application/Services Property Page

The Application/Services property page is where you can define which services are available through the WebAccess Application by listing what are called GroupWise providers. These providers are discussed in just a bit. For now, think of this tab as providing the ability to configure whether the WebAccess Application can access either a WebAccess Agent or an LDAP server. The reason for the LDAP server portion is that, from the WebAccess address book, you can query other LDAP servers to look up names and addresses in their directories. Without the LDAP provider defined as an active service on the GroupWise WebAccess object, LDAP lookups from the WebAccess client address book would fail. Similarly, if you did not have the GroupWise provider listed here as an active service, the application could not physically talk to a GroupWise agent.

Note

You cannot have multiple instances of the same provider listed here. If you choose to edit a listed provider, it takes you to the properties of that particular provider, which you will read about shortly. Deleting a listed provider does not actually delete the provider from the system, but simply deletes it from the GroupWise WebAccess object so that this service is not active from the GroupWise WebAccess object's point of view.

Application/Templates Property Page

The Application/Templates property page is where you can define the type of interface users see when accessing WebAccess. It might be helpful for you to understand what templates are first. Figure 11.16 shows the Application/Templates Property Page.

Figure 11.16. The Application/Templates property page

You can think of templates as being containers that hold or display the data retrieved from a user's mailbox located at the post office. Templates are associated with the type of browser or device being used to access WebAccess. For example, if you were to access your GroupWise mailbox from a standard PC-based web browser such as Internet Explorer or Netscape, you would be using the standard HTML templates to view the contents of your mailbox. If you were to access your mailbox from a Pocket PC device running a browser, you would probably want to use a different set of templates, called simple HTML templates. Or if you were to access your mailbox from a wireless cellular phone, you would need to view your mail by using a different set of templates called WML (wireless markup language) templates. Templates are explained much more in Chapter 24, "Configuring GroupWise Wireless." Just remember that templates are the key to how flexible the GroupWise WebAccess system is as far as supporting and displaying the contents of a user's mailbox across many types of devices. For now, this chapter discusses some of the basic configuration options available for the WebAccess Application:

• Template Path: This defines where all the template directories exist. If you were to look in the directory defined here, you would see several subdirectories under these, one representing each set of templates that WebAccess supports.

• Java Package: A Java package name is a directory path that uses a period (.) instead of a slash (\) to separate components of the path. This path identifies the location of the template string tables. Unless you are an HTML developer and are creating your own custom templates, you will not need to modify this path.

• Images URL: This is the path under the web server's document root directory where the images that you see from the WebAccess client are located. These images are *.GIF files; they make up the icons and buttons you see from the browser.

• Applets URL: This identifies the path to the WebAccess applets. This should be blank unless you have moved the applets to a different server. You would then enter the path to another root directory. The default location of applets is under the web server's document root directory.

• Help URL: This is the path under the web server's document root directory where the help HTML files are located. If WebAccess users want t o pull up the online help, they are directed to the INDEX.HTM file.

Tip

Under this help directory, there is a subdirectory that represents the language that the user is using. For example, if the language is English, you will see an EN directory under the HELP directory, which would contain the INDEX.HTM. You could then create your own help files, if desired.

• Enable Template Caching: This option allows the WebAccess Application to cache the templates in RAM the first time they are used. This increases performance. Keep these settings intact.

• Cache Size: This value determines how much RAM the web server will use to cache the templates. You can increase the template caching to 4000KB, which is our preference. Setting the cache beyond that is probably just a waste of memory.

• Default Language: This identifies the default language that will be presented to users when they reach your web server's home page and you have selected to use the default WebAccess home page.

• Define User Interfaces: Clicking this button allows you to set up custom user interfaces. This is useful when your users are using different types of devices to access their mailboxes. You can learn more about this in Chapter 24.

Application/Security Property Page

Some of the basic configuration options available beneath the Application/Security property page are discussed here:

• Timeout for Inactive Sessions: This setting allows you to configure how many minutes of inactivity must pass before a user becomes disconnected from the application. The WebAccess Application does not tie up too many resources maintaining a WebAccess client session. We suggest changing the timeout to 60 minutes.

• Path for Inactive Sessions: Imagine that you are in the middle of composing an email from the WebAccess client and are interrupted for several minutes. The inactive session timeout value kicks in, and you get disconnected. The WebAccess Application saves your session before disconnecting. When you come back and reauthenticate to WebAccess, you can resume your email.

• Use Client IP in Securing Sessions: If this option is checked, the WebAccess Application uses the client's IP address to help construct the hash value used to identify the user's browser session within the WebAccess Application. Be aware, however, that if a user's browser is configured to use a proxy server, there is a chance that the proxy server can use different IP addresses during the same session. This would cause invalid hash errors to appear on the WebAccess Application. If you see this type of problem, you will want to disable this option. The GroupWise WebAccess Application handles session security through the use of cookies. The only reason you would need to check this option is if users access GroupWise WebAccess through a browser that does not accept cookies.

Warning

AOL users usually have difficulties using GroupWise WebAccess if you enabled Use Client IP in Securing Sessions. The AOL client relies heavily on proxy servers, so a user's session with the WebAccess Application can change often as the proxy server's IP address changes.

Application/Settings Property Page

The Application/Settings property page, shown in Figure 11.17, is where you enable or disable options that users will see from the WebAccess client. If you disable an option, that particular option's interface will be missing for all WebAccess users accessing this particular WebAccess Application.

Figure 11.17. The Application/Settings property page, where options such as the LDAP directory search has been disabled

The available settings on this page are listed here:

• Spell Check Items: Here you can either enable or disable the user's ability to spell-check newly composed email messages before sending them.

• Search LDAP Directories: If this option is disabled, users will not be able to search the admin-defined LDAP servers for email addresses. If you do not have an LDAP address book for your users to search (most people don't), there's really no reason to have the LDAP address book capability show up in the WebAccess client address book. In the example shown in Figure 11.17, the LDAP directory search has been disabled. You can find more about setting up LDAP servers later, in the section "Configuring an LDAP Address Book for WebAccess."

• Change Passwords: This option allows users to change their GroupWise master mailbox password from WebAccess. Be aware that if LDAP is enabled and you are using Novell's eDirectory as your LDAP server, when users change their password here, they are changing their eDirectory password also. This is really slick when you think of it. Conceivably, your users can change their eDirectory authentication from their WAP-enabled cell phones.

• Access Document Management: This option controls user access to documents from within GroupWise libraries. Some organizations want users to access document management only from a GroupWise 32-bit client. This is the case at WorldWide Widgets. In the sample Settings page shown in Figure 11.17, the capability to view documents from WebAccess is disabled.

• Open Attachments in Native Format: This setting governs whether users can open attachments from their browsers. Their web browser needs to be able to determine the file type, and then launch the document into the associated application. Some browsers do a better job of this than other browsers. We recommend checking this option.

• Open Documents in Native Format: This option has to do with GroupWise document management. Most customers, even those using document management, will want to disable this check box. Opening a document from document management in the WebAccess client can cause version-control issues.

• Include Only Files with These Extensions: By filling in this field, you can specify just what kinds of files users have an option to open. The users can always save the file to their own computer and try to open it there.

• View Attachments in HTML Format: This option is useful if you do not want to give users the ability to view attachments from within WebAccess. It removes the view option from mail with attachments when they read them. You can allow users to open the attachments in their native applications, though. Personally we think it is a good thing to allow users to view attachments in HTML format, but not all attachment types.

  Fortunately, there's a place where you can exclude certain document types; read on.

• View Documents in HTML Format: This option performs the same functionality as the preceding function. If you disable this option yet document management is enabled, users can view the document in HTML format.

• Exclude Files with These Extensions: This setting allows you to exclude files such as *.PDF files (which are better viewed from Acrobat reader) from HTML viewing.

• Customize Settings in XML: This button launches an XML editor that can be used to modify the settings on the WebAccess Application. There are several settings you can enable or disable through this interface. For example, if you want to disable the calendar functions from a WebAccess Application, you can do so from this interface. Or you might want to set a limit on the size of attachments that are viewable through the WebAccess Application. You can do this by changing the Document.View.maxSize setting. The default value is 1MB. We like this setting; however, if you want to increase this setting beyond 1MB, you can. If a file exceeds the Document.View.maxSize setting, the users cannot view the document, but they can save the file and then launch it in the native application.

NovellSpeller Object

The NovellSpeller object basically represents the GroupWise speller servlet object. It is created when you install the WebAccess Application object. The speller servlet object automatically starts when the web server loads the WebAccess Application.

Application/Log Settings Property Page

From the Application/Log Settings property page, you can configure the log settings for the speller. Rarely will you need to look at the speller's log files.

Application/Environment Property Page

The settings here are really the only thing you can configure on the speller object, other than the logging. The settings available are listed here:

• Configuration File: This is the path to the spell checker's configuration file. It is a text file that contains all the configuration information regarding the spell checker.

• Dictionary Path: This is the path to the dictionary files that contain the word lists and suggestions used during spell checking.

• Maximum Suggestions: Here you can enter the maximum number of suggestions to give when a misspelled word is encountered during a spell check.

• Customize Settings in XML: Here you can also modify these settings from the included XML configuration editor.

Those are all the settings available for the speller object. Most customers will not need to make any changes to the speller object.

GroupWiseProvider Object

The GroupWiseProvider object works in conjunction with the GroupWise WebAccess object or the WebAccess Application. Think of it as the actual transport provider that is responsible for carrying the data between the WebAccess Agent and the WebAccess Application. This might sound a bit confusing because the entire chapter notes that the GroupWise WebAccess Application talks directly to the WebAccess Agent. Basically it does, but for administration purposes and future support for additional features in WebAccess, it has been broken into providers.

A user's web browser talks to a servlet running on the web server. This servlet functions as the default WebAccess Application. The Application then looks up which providers it has access to and hands the request over to the appropriate provider. This all happens on the same server. There is not an actual separate program that acts as the provider; it is all bundled into the WebAccess Application, but it acts as a separate, configurable subprocess of the WebAccess Application. The provider then communicates directly to the agent. If you think of it this way, it will be much easier to understand how the provider objects relate to the WebAccess Application or servlets.

Configuring the GroupWiseProvider object is really quite simple and straightforward. The following properties of the GroupWiseProvider object can be configured:

• Timeout for Busy Search: This value sets the number of minutes the provider waits when performing a busy search to the WebAccess Agent. This allows the administrator to control how soon busy searches are cancelled through the WebAccess client.

Note

A busy search is a feature that allows you to check when other GroupWise users are available so that you can schedule an appointment with them through the GroupWise calendar.

• Configuration File: This simply points to the COMMGR.CFG file that the provider uses to determine where the WebAccess Agent is (the IP address and port) and how to encrypt the data in transit using the encryption key embedded in the COMMGR.CFG file.

• GroupWise WebAccess Agents: This is where you list all the WebAccess Agents that the provider will be able to communicate with. You must have at least one agent defined here, but you can have multiple agents. This gives you a level of fault tolerance in regard to the WebAccess Agent.

The GroupWiseProvider object is most useful when used for the fault-tolerance capabilities of WebAccess.

LDAPProvider Object

The LDAPProvider object basically serves the same function as the GroupWiseProvider object; the WebAccess Application sends requests for LDAP lookups to it, and then the LDAP provider looks up and hands the results back to the GroupWise WebAccess object. The LDAPProvider object does not communicate with the WebAccess Agent like the GroupWiseProvider object does. Instead, it queries whatever LDAP servers have been configured for lookups directly.

Following is an explanation of the settings you can configure on the LDAPProvider object:

• Configuration File: This setting points to the path of the LDAP configuration file. This is a text file that contains all the configuration information for the LDAP provider. This file contains the settings for the LDAP servers, for example.

• LDAP Servers: This setting lists the configured LDAP servers that would be available to search from the WebAccess client. In the upcoming section "Configuring an LDAP Address Book for WebAccess," you learn how to set up additional LDAP services.

• Customize Settings in XML: Once again, you can configure these settings from the XML configuration editor, if desired.