Understanding the Administration System

The administration of the GroupWise system goes hand in hand with the GroupWise directory. The administration system of GroupWise consists of two separates sets of software components:

• GroupWise administrator snap-ins to ConsoleOne

• The admin threads of the MTA and the POA

The GroupWise Snap-Ins

The GroupWise administration snap-ins are often misunderstood. Administrators are quite often cognizant of the version of the GroupWise client, or the version of the GroupWise agents. There is often little emphasis placed on determining the version of GroupWise administration.

The version of administration is especially important when you have implemented a patch or a new version of GroupWise, and you really want to leverage the new fixes or features in that patch or new version. As discussed in Chapter 7, to determine the version of GroupWise administration you are using, do the following:

1.	Load ConsoleOne.
2.	Choose Help, About Snapins. You should see the screen shown in Figure 22.5. Figure 22.5. About Snapins in ConsoleOne
3.	Click a snap-in to see its version information.

Is this the version you want to be running? Is this version of the GroupWise snap-ins on every file server or workstation where ConsoleOne is running?

Many of Novell's customers have a huge GroupWise installation that is managed by several administrators. It is important that everyone who runs ConsoleOne is using the latest GroupWise snap-ins, or at least the latest ones that have been approved for your organization. If this is not the case, someone might be causing problems in the GroupWise systemproblems due to bugs that have been addressed in a later patch of the GroupWise administrator snap-ins.

Tip

GroupWise Administrator allows you to restrict which versions of snap-ins are allowed to connect to a GroupWise domain. This can be useful for preventing older snap-ins from accessing a WPDOMAIN.DB file and performing administration tasks. Define this setting from Tools, GroupWise System Operations, Admin Lockout Settings. From there, you can lock out older snap-ins.

Note

Only the 6.5 and later snap-ins will honor the lockout setting. GroupWise 6.x and older snap-ins do not honor this setting; they can access the domain database even when this setting is in effect through the 6.5.1 snap-ins.

Understanding the GroupWise Admin Thread

The admin thread is just a subprocess of the MTA and the POA. In the MTA and POA log files when the admin thread runs, it is logged as ADM. This chapter discussed this earlier, and this concept is also discussed in Chapter 8, "Configuring the Post Office Agent," and Chapter 9, "Configuring the Message Transfer Agent."

The admin thread on an MTA or a POA is responsible for updating its respective directory database. This admin thread has two input queues:

• The ADS directory queue: The first input queue for the admin thread is the WPCSOUT\ADS\2 directory off of a post office or domain. The admin thread comes to life every minute. For example, when a POA's admin thread discovers a file in the PO\WPCSOUT\ADS\2 directory, it makes a change in the WPHOST.DB file. If a domain MTA's admin thread discovers a file in the WPCSOUT\ADS\2 directory, it makes the appropriate change to the WPDOMAIN.DB file.

• The tickle queue: The admin thread will also come to life when it gets a tickle from the POA or MTA that owns the thread. In GroupWise 6.5 or higher, although the admin thread comes to life every minute, when an MTA or a POA gets an administration message via a TCP/IP connection, it queues the message up to the admin thread by a routine in memory. At the GroupWise domain/MTA level, quite often administration files do not go into the WPCSOUT\ADS\2 directory. They are instead handed off to the admin thread while they are in the MSLOCAL\GWINPROG directory.