GroupWise 8 Good and Bad Habits

From MicroFocusInternationalWiki
Jump to: navigation, search

GroupWise 8 Best Practices

GroupWise 8 Good and Bad Habits



This may well be where the rubber meets the road.

This section contains clever working examples, good advice, some warnings, and just plain criticisms. Tips of what to do, what not to do and tricks on extending your GroupWise services beyond the normal scopes are attempted. Hoping to help and preventing gotchas being the main theme .....

Global Good Habits

GroupWise System Configurations

  • Lock system administration to the primary domain
  • Do manage client settings at the domain level if possible
  • Do manage or limit wild card addressing
As of GroupWise 8 SP2, there can be restrictions on the numbers of recipients and attachment types
As of GroupWise 8 SP2, Distribution Lists can have restrictions on who can send to them.
  • Check agent queue directories from time to time for aged unprocessed files
For wpcsin and wpcsout subdirectories if a file is 24+ hours old it should be deleted (or looked into why, prior to deleting)
For the send, receive, and result directories used for the GWIA SMTP daemon if a file is 24+ hours old it should be deleted
MSLOCAL subdirectories for MTAs should be checked while all links are open and apply the same 24 hour rule, except for the \MSLOCAL\MSHOLD\xxxyyyy\ queues.

Internet Agent Configurations

  • Do configure or disable the SMTP relay settings
  • Do configure "Classes of Service" for any settings outside of the defaults for your system. Not only does it result in a modular implementation, but it presents a clear design picture for peer or juinor administrators
  • Do provide POP or IMAP services using dedicated agents
  • Do utilize the agent re-direction capabilities if multiple agents can or are used
  • Do Disable unused protocols (LDAP, POP3, IMAP)
  • Convert all Gateway Aliases to Internet Over-rides (Use Migration Tool provided in C1 GW Snapin)
  • If the Client (1677) communication has been set to use SSL, ensure that you change the Post Office link to "Use Current Post Office Access" (shown as Follow PO) or POP3 & IMAP4 will fail
  • Do ensure your attachment encoding method does not cause usability issues for clients. For instance a 20MB attachment will most likely be a 27MB file once it's MIME encoded. Subsequently it will be blocked by a 20 MB attachment limit. Don't make users do maths.
  • Do ensure that the GWIA is bound to only the specified IP Address/DNS Host name - Postfix requires the loop-back address so as to function correctly for system messages.

WebAccess Agent Configurations

  • Do patch the agent frequently to ensure viewer files are updated as they are updated by Novell
  • Do utilize the agent re-direction capabilities if multiple agents can or are used
  • Do Patch the host OS regularly as they will be attacked
  • Do try regular Penetration Testing to ensure security is maintained.
  • If the Client (1677) communication has been set to use SSL, ensure that you change the Post Office link to "Use Current Post Office Access" (shown as Follow PO) or WebAccess will fail
  • LDAP services should be disabled on system startup on Web Access Application servers
  • WebAccess Applications should be installed as 64 bit Linux instances to improve performance
  • Utilize restartable protected memory address spaces with meaningful names
  • Ensure "Memory Protection Fault Cleanup" is set to "On" to so successful Document Viewer address space restarts can actually occur (and they will)
  • Ensure "Memory Protection Restart Count" is set greater than "1" so multiple Document Viewer address space restarts actually can occur (and they will) without halting the agent or server

Message Transfer Configurations

  • Do configure additional inbound connection allowances for heavily loaded agents using the /tcpinbound switch in the agent startup file
  • Do configure domain links changes from the target domain

Post Office Agent Configurations

  • Never use direct access for post office connection.... really.... ever.....
  • Dedicate a POA(s) to document management services
  • Where you have to have multiple Agents on one server, stagger the maintenance tasks
  • Utilize the GroupWise High Availability feature in GW Monitor to manage the Linux agents to get restarted via gwha under xinetd
  • Do enable the Document Conversion Agent (DCA) and configure the quarantine settings
  • Utilize restartable protected memory address spaces with meaningful names
  • Disable the Document Conversion Agent (DCA) using the /nodca switch in the agent startup file
  • Place the LDAPSDK, LDAPSSL and LDAPX NLMs included with your agent software version in the same directory as the agent application files

Server platform considerations

Linux server configurations


  • OpenMotif libraries (openmotif-libs):Provides the environments required for the GroupWise text based installation
  • OpenMotif package (openmotif):Provides the environments required for the GroupWise GUI based installation

(The edit of the limits.conf below ONLY APPLIES to version 802HP2 or earlier. Version 802HP3 and later has resolved this where it automatically allocates the Open Files value for its process when it starts up.)

Configure open file limits on Linux servers by adding the following lines to the /etc/security/limits.conf file.

* soft nofile 8192
* hard nofile 65535

Configure the Postfix service to listen only on the local host interface by adding or modifying the following line to the /etc/postfix/ file.


(Applies to version 802HP2 or earlier only. Version 802HP3 and later has resolved this slow performance issue in code by making a TCP/IP "No Delay" call.) There is a slow performance situation in the MTP file transfer when two or more agents are running on the same Linux server (Novell TID 7007575). The data transfer between any two agents on the same server using MTP will slow down to around 200,000 bytes/sec. This problem does not exist if the file transfer occurs between different Linux servers. To resolve this issue, configure the loopback transfer to adopt the same data transfer size of 1500, same as using the Ethernet NIC, by adding or modifying the following line to the "/etc/sysconfig/network/ifcfg-lo" file.


Once modified run the following command to restart the network service and put the changed MTU into effect:

 sudo /etc/init.d/network restart

Once all of the the above is done, the speed returns to around 26,000,000 bytes/sec. (GroupWise

GroupWise software updates

Its always a good idea to install and test available OES and SLES updates before installing GroupWise Support Pack or Hot Patch updates. It is possible that newer software has dependencies on updated core system files, libraries or applications. Minimally the documentation referencing the GroupWise software update should be evaluated for these requirements.

However, even these sources may not contain this information at times. So, when in doubt update and test core OS components prior to applying GroupWise software on OES and SLES hosts.

SSH service configuration

The SSH services running on POSIX systems offer a reasonable level of security in their default configurations. However, most organizations should implement some basic service configuration changes that will enhance the security SSH services.

The changes recommended here configure SSH to:

  • Prevent the ability of user “root” to login via SSH
  • Limits the use of service to SSH protocol version 2 only as version 1 has many documented security flaws
  • The incorrect user login count is decremented to 3 for usability reasons however your security model may not agree with this change

These changes can be implemented for SSH daemons on OES Linux servers by modifying the proper directives in the “/etc/ssh/sshd_config” file.


# Protocol 2,1
Protocol 2
# PermitRootLogin yes PermitRootLogin no
# MaxAuthTries 6 MaxAuthTries 2

Disable unnecessary services

Regardless of the role of the target server it should be deployed with the minimal running application environment possible. Disabling unnecessary services conserves computational resources and reduces management overhead. Additionally the server is more easily hardened as a result not allowing unneeded services to start.

Good candidates for disabling are:

alsasound - Sound hardware daemon
apache2 - The Apache 2 http daemon (If not used for WebAccess)
auditd - Linux file system auditing daemon
nfsserver - NFS server daemon
nfsboot - NFS service daemon
nmb -  netbios daemon
novell-tomcat5 - Novell implementation of the java application server
tomcat5 - Standard implementation of the java application server (If not used for WebAccess)
smb - Samba service daemon
portmap - NFS/NIS service daemon
splash - Splash screen setup
splash_early - Stops animations after the network starts

Additional Apache hardening

Disabling unnecessary Apache modules

The same logic for disabling and unloading unnecessary server applications and services can be applied to Apache modules as well. If the module is not running it does not need to be managed or secured.

With some degree of certainty there is a small subset of Apache server modules that can and should be disabled on most OES Linux and Suse Linux Enterprise servers. These primarily deal with file and database authentication and authorization services.

Modify the “APACHE_MODULES” directive in the “/etc/sysconfig/apache2” file to remove unnecessary modules from the server configuration and restart Apache.

For example remove the references for the following apache modules:


** However the required module set for any specific server implementation can vary so do not remove any modules your implementation may require.

There are many configuration changes that can be implemented to further harden Apache instances on OES Linux and SuSE Linux Enterprise servers. However the suggestions here are minimum baseline configurations that are determined to be a good fit for the network environment that hosts the servers and services.

A simple change could be used to prevent Apache from serving certain types of files as HTTP content or for download. Some of these file types may contain server and service configuration information or other information the organization may not intend to publish. A file named “security.conf” containing the required directives could be created and placed in the “/etc/apache2/conf.d” directory of the target server. Apache on OES and SuSE Linux distributions is pre-configured to process all files that end in a “.conf” extension in this directory on service startup. This is the preferred method to make modular changes to Apache instances instead of modifying the primary httpd.conf file. Apache should be restarted after placing the file in the referenced directory.

The contents of the “security.conf” file are displayed below:

<Files ~ "\.(bak|old|~|2|copy|tmp|swp)$">
Order allow,deny
Deny from all

Some additional security steps can be implemented to instruct Apache not to divulge unnecessary information just because a client asks for it. An example of this would be the vendor and version of the operating system hosting the Apache instance.

Instructing Apache to not declare the operating system provider used on its host is quite easy to do. Modify the “APACHE_SERVERTOKENS” directive in the in “/etc/sysconfig/apache2” file to be something other than "OS". It is recommended that you set it to “ProductOnly” so Apache only declares the Apache product and no version or OS info if interrogated by a client.

After making the change restart the Apache service.

Additional suggestions:

  • Disable logging for the “mod_rewrite” module if it is not being utilized beyond its default configuration
  • Modify the “/etc/apache2/listen.conf” file to configure the Apache service to listen on the primary server IP address instead of

Running agents in “User Space” is different

GroupWise agents running on the Linux platform run as a user recognized on the local system. As with any other application running in user space, as opposed to kernel space” file system rights to the target file system are required for the application to run successfully. By default the local user “root” is used as the GroupWise agent's run time identity. For this case file system rights do not need to be adjusted. However it is not recommended to run your GroupWise agents as user root.

Running GroupWise agents as non-root users Benefits:

  • Improves server and application security models (hackers love to interrupt applications running as root)
  • Improves service troubleshooting (If all applications are running as root.....)

All GroupWise agents with the exception of the WebAccess agent can run as non-root users. There are two platform specific options for providing the non-root user your agents will run as.


Use a locally configured user and group. Observations have indicated to use no more than eight lowercase characters for the names. Additionally, configure the users with a false shell and home directory (/bin/false, /home/false).


Use a locally known Linux User Management (LUM) enabled user. Observations have indicated to use no more than eight characters for the names. Additionally, configure the users with a false shell and home directory (/bin/false, /home/false).

You cannot use a LUM enabled user for the GWHA service. Currently this user must be local on each server participating in the GWHA implementation.

Once the non-root user is available to the system create a text file containing the non-root user name called “uid.conf” in the /etc/opt/novell/groupwise/agents directory. If the agent is already running shut it down and delete the existing “” file in the directory specified in it's “home” switch. Change the user and group ownership (setting the group ownership will not be possible for NSS volumes) of the files in the same directory to reflect the configured non-root user. Start or restart the target GroupWise agent.

If non-root users are used for GroupWise agents it is important that instances of ConsoleOne used against those agents are run as the same user. If ConsoleOne is run as any other user, such as root, administrative messages may be placed in agent queues that it cannot process due to ownership issues.

When non-root users are used be sure to set and monitor file and group ownerships on agent file systems. Be especially keen to observe for this issue post installation, following database rebuilds, or on the occasional agent restart.

Configuring Servers to use the GroupWise High Availability Service

The GroupWise High Availability Service (GWHA), and its configuration file, serves three purposes for a GroupWise agent.

  • It replaces the memory address space restart functionality used on the NetWare platform that promoted agent high availability.
    • When married with the GroupWise Monitor services GroupWise agents can be polled and restarted if the local GWHA services are properly configured.
  • It allows some additional control options for how the agent is started normally.
    • When the "show" argument is added to the gwha.conf file it can be enabled or disabled by the administrator to invoke the agent GUI for troubleshooting purposes

The gwha.conf file is located in the /etc/opt/novell/groupwise directory. A commented example is displayed below.

ssl      = no (no if not using SSL)
key      = filename.key (blank if not using SSL)
cert     = filename.crt (blank if not using SSL)
password = key file password (blank if not using SSL)

server    = /opt/novell/groupwise/agents/bin/gwmta
command   = /etc/init.d/grpwise
startup   = /opt/novell/groupwise/agents/share/domain_name.mta
delay     = 2
wait      = 10
;show	= yes (optional, yes starts agent with GUI and not as a daemon)

server    = /opt/novell/groupwise/agents/bin/gwpoa
command   = /etc/init.d/grpwise
startup   = /opt/novell/groupwise/agents/share/post_office_name.poa
delay     = 2
wait      = 10
;show	= yes (optional, yes starts agent with GUI and not as a daemon)

It is important that the case used for the GroupWise objects and their references in the gwha.conf file match.

The print argument for the /etc/init.d/grpwise script displays the the settings specified in the /etc/opt/novell/groupwise/gwha.conf file

/etc/init.d/grpwise print 

  • It serves as a set of configuration variables for the /etc/init.d/grpwise script.
    • In order to keep this init script as vanilla as possible. Imagine if each agent had its own script on a server in a large clustered environment. The gwha.conf file stores the name and configuration information specific to each agent installed on the server.

The "delay =" setting controls the length of time between when the script issues the command to start an agent and when the script displays a message indicating that the agent has started. The default delay time is 2 seconds. Under certain circumstances, an agent could encounter a problem and fail to start after 2 seconds. In this case, you would receive the success message but the agent would not be running. You need to increase the delay = setting to accommodate the length of time it typically takes for the agent to start successfully on your system.

The "wait =" setting controls the length of time between when the script issues the command to stop an agent and when the script kills the agent if the agent has not yet stopped. The default wait time is 10 seconds. Under certain circumstances, an agent could take longer than 10 seconds to perform a normal shutdown, and killing the agent under those circumstances would not be appropriate. You need to increase the wait = setting to accommodate the length of time it usually takes for the agent to shut down. A message notifies you if the script kills an agent because its shutdown exceeds the wait = setting.

Configuring a user account for GWHA services

Using a Linux User Management (LUM) enabled user will not work for GWHA services. However using a local Linux user on each server the GWHA service will benefit the robustness of the service by isolating it from external account store dependencies.

Configure a standard Linux user with a password and a primary group for GWHA to use. This user's credentials will be used by the GroupWise Monitor agent to interact with the GroupWise agent. No file system rights need be assigned. Ed Hanley's comment - I thought the xinetd credentials are used to interact with the GW Agent for restart and not the gwha account you create. Needs to be looked into.

Configure the gwha user with a false shell and home directory Use "/bin/false" and "/home/false" for the user's shell and home directory parameters.

Enable the High Availability service

In order for the Target GroupWise agent to be HA aware it must be loaded when the HA environment is active on the server.

  • In YaST, click Network Services > Network Services (inetd).
  • If necessary, select Enable to activate the list of services.
  • Scroll down to the gwha line, select it, then click Toggle Status (On or Off) to change the status to On.
  • Click Finish.
  • Stop/re-start the GroupWise agents(s)

To enable communication between the GroupWise Monitor Agent and the High Availability service, start the Monitor Agent with the the following switches minimally.

Configure the Monitor Agent to communicate with the GWHA service

Enable and modify the following section of the "/etc/init.d/grpwise-ma" script with the following switches and values.

MA_OPTIONS="--hauser <gwha_user> --hapassword <password> --hapoll 120"

Set to match the username and password of the Linux user you set up to represent the High Availability service on your Linux servers.


Also consider using the following switches

--httpagentuser <agent_http_mgmt_port_user>
--httpagentpassword <agent_http_mgmt_port_user_password>

The "--httpagentuser" and "--httpagentpassword" switches provide the user names and passwords for your monitored GroupWise agents HTTP management ports to the Monitor Agent for enhances monitoring, reporting, and alarm features.

Once the Monitor Agent is configured and restarted it will begin to poll the configured agents that are allowed through the service filter. The agents can also be manually polled through the agent interface to get status information between polling cycles or to restart a agent known to be stopped.

Add or remove GroupWise agents from the agent filter by using the "Preferences" --> "Filter" navigation link menus.

The GroupWise HA service and NCS

When a GroupWise agent is installed into a Novell Clustering Services environment there is a caveat to be aware of.

When an agent is failed or migrates to another node by the clustering software or a management action, the previous GWHA service is not aware of the agent's new good state on another node. We also have to disable the GWHA service during the NCS Unload process so the GW Monitor GWHA service does not try to start up the GW service that is being Stopped in the Unload script.

To ensure the HA environments are normalized, the GWHA services on the previous node should be restarted so it is unaware of the agents previous state transition. This is best accomplished by restarting the GWHA service using the GroupWise cluster resource Unload script.

Disable the gwha service at the beginning of the Unload script, unload the GroupWise agents, then re-enable the gwha service at the end of the Unload script.

#! /bin/bash
. /opt/novell/ncs/lib/ncsfunc

# Disable the gwha service under xinetd
ignore_error /sbin/chkconfig -s gwha off
ignore_error kill -HUP `pidof xinetd`

# Unload the GroupWise agents
/etc/init.d/grpwise stop POA.DOMAIN

# Unload other cluster stuff
NCP Services
IP addresses

# Re-Enable the gwha service under xinetd
ignore_error /sbin/chkconfig -s gwha on
ignore_error kill -HUP `pidof xinetd`

If you are using snmp (such as Cacti) to monitor disk free space clustered GroupWise volumes, you need to restart the snmpd daemon at the end of the cluster Load and Unload scripts so that when snmp queries the host the actual snmp object currently running will be reported. If a cluster volume is mounted on nodeA and is later migrated to nodeB without restarting the snmpd daemon, a snmp query to the server currently hosting the mount GroupWise resource will not know that a new snmp resouce is present and report erroneous numbers to the calling snmp application.

# If you are using snmp monitoring. Add at end of 
# the Load and Unload scripts
# Reload the snmpd daemon so the host recognizes
# a new resource has been added
/etc/init.d/xinetd restart

Additional GroupWise Monitor Agent Configuration

Configuring the GroupWise Monitor Agent can be a bit intimidating for some as it makes heavy use of startup switches. Fortunately, few are required to implement a very functional and useful service.

For more information about the GroupWise Monitor Service Please see GroupWise Monitor use and scope

In addition to the switches for the Monitor Agent startup script or file consider using the following switches as well.

--hapoll <desired_polling_time_in_seconds>
--monwork <path_to_monitor_work_directory>

The --hapoll startup switch to control how often the Monitor Agent contacts the High Availability service with agent status information in seconds. Consider the amount of time suitable for your environment. Understanding that loaded agents may take longer to shut down. 90 - 180 seconds works well for most environments.

The "--monwork" switch simply specifies where the the Monitor Agent places its application data to include maps and reports. By default it works from the "/temp" directory which is not desirable.

Again it is recommended that you implement a live domain for the GroupWise Monitor service. Using this configuration your Monitor Agent can perform reporting and performance analysis tasks against your system.

Do use the following switches if you incorporate a live domain as recommended into your Monitor service implementation:

--home <path_to_monitor_domain_directory_>
--ipa <ip_address_of_monitor_domain_mta>
--ipp <tcp_port_of_monitor_domain_mta>


It is better to have loved and lost than never to have loved at all...

NetWare has entered extended support (which ends in March 2012) Pretty much every TID and GroupWise admin knows NetWare and what to do, so this section is light.

NetWare 6.5 SP8 and Atime

There was a new NSS switch added to NetWare 6.5 Service Pack 8 that allows Atime to be disabled at a persistent volume level.

nss /noatime=gwdata


NTFS sucks - but we can improve it

NTFS File System

Ugly file system that it is, NTFS has managed to develop over time to quite a usable system. The inherent problems with fragmentation are designed deep into the code and therefore can never be resolved. For GroupWise on Windows this will require regular (every 6 Months?) de-fragmenting.

Optimizing the File system can be done however and items to consider for this are:

PagedPoolSize HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\ (REG_DWORD)

File cache space and paged pool space share a common area in system virtual address . Limiting the paged pool allows for a larger system cache, which causes more content to be cached and allows faster serving of files.

PagedPoolSize = 192000000

NtfsDisable8dot3NameCreation HKLM\System\CurrentControlSet\Control\FileSystem\ (REG_DWORD)

Default is 0. This parameter determines whether NTFS generates a short name in the 8.3 (DOS) naming convention for long file names and for file names that contain characters from the extended character set. If the value of this entry is 0, files can potentially have two names: the name that the user specifies and the short name that NTFS generates. If the name the user specifies conforms to the 8.3 naming convention, NTFS does not generate a short name.

NTFS File System Setting Under HKLM\System\CurrentControlSet\Control\FileSystem\ NtfsDisableLastAccessUpdate (REG_DWORD).

This system-global switch reduces disk I/O load and latencies by disabling the updating of the date and time stamp for the last file or directory access. This key needs to be added; it does not exist by default. Disabling the updates is effective when used with large data sets (or a large number of hosts) containing thousands of directories. It is recommended that you use IIS logging instead if you maintain this information for Web administration only.

Stripe unit size.

Software solution is fixed at 64 KB. Hardware solutions may range from 4 KB to 1MB. Ideal stripe unit size maximizes the disk activity without unnecessarily breaking up requests (so that multiple disks are required to service a single request). For example:

· One stream of sequential requests (large) on JBOD would keep only one disk busy at a time. To keep all disks busy, the stripe unit needs to be equal to 1/N where N is the request size.

· For N streams of small random requests, if N is greater than the number of disks, and if there are no hotspots, striping will not increase performance. However, if there are hotspots, the stripe unit size needs to maximize the chance that a request will not be split, while minimizing the chance of a hotspot falling entirely within one or two stripe units. You might pick a low multiple of the request size, like 5X or 10X, especially if the requests are on some boundary (for example, 4 KB or 8 KB).

· For fewer streams than disks, you need to split the streams so that all disks are kept busy. Interpolate from the previous two examples. For example, if you have 10 disks and 5 streams, split each request in half (use a stripe unit size equal to half the request size).

Whenever possible use separate volumes for each data type. For example, use one volume for the operating system and paging space, and one or more volumes for shared user data, applications, and log files.

Place different data types in separate volumes on different virtual disks. Using separate virtual disks is especially important for any data types that create heavy write loads, such as log files, so that a single set of disks (that compose the virtual disk) can be dedicated to handling the disk I/O created by the updates to the log files. Placing the paging file on a separate virtual disk can provide some minor improvements in performance, but typically not enough to make it worth the extra cost

Disablelastaccess HKLM\System\CurrentControlSet\Control\FileSystem\. (REG_DWORD)

By default, this registry key is not created.

If you have an NTFS volume with a high number of folders or files, and a program is running that briefly accesses each of these in turn, the I/O bandwidth used to generate the Last Access Time updates can be a significant percentage of the overall I/O bandwidth. To increase the speed of access to a folder or file, you can set disablelastaccess to disable updating the Last Access Time. After you use this command and restart the computer, the Last Access Time is no longer updated. If you create a new file, the Last Access Time remains the same as the File Creation Time.

CountOperations HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\I/O System\CountOperations.(REG_DWORD)

This parameter allows you to turn off system and process level I/O counters. This counter affects system and disk counting of disk and network I/O requests. Physical and logical disk counters—in addition to network interface, IP and TCP counters—are not affected by this parameter. It is useful to turn off the process and system counters by using this registry parameter on systems where there is a measurable cost associated with counting I/O at the process and system level but where I/O rates can still be analyzed at the physical, logical, network interface, IP and TCP levels. To turn off the process and system I/O counters, you need to create a registry value (and I/O System key if one doesn’t already exist) and set the value to 0 (REG_DWORD) in the following registry entry:

A reboot is required for this setting to take effect. Process and system counters can be turned on again either by setting CountOperations to 1 or by removing the CountOperations registry entry.

NumberOfRequests HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MINIPORT_ADAPTER\Parameters\DeviceN\NumberOfRequests (REG_DWORD)

This parameter allows you to specify the number of SRBs created for a given adapter. This improves performance and allows Windows to give more disk requests to a logical disk, which is most useful for HW RAID adapters that have concurrency capabilities since each logical disk consists of multiple physical disks. However, the default setting is often less than optimal for many high-speed HW RAID disk arrays. Overall disk array performance can be improved by setting NumberOfRequests to a value in the range of 32 to 96 (decimal).

Replace miniport_adapter with the specific adapter name. Make an entry for each device, and in each entry replace DeviceN with Device1, Device2, and so forth, depending on the number of devices you are adding. A reboot is required for this setting to take effect. For example, for two Emulex LP9000 miniport adapters whose miniport driver name is lp6nds35, you would create the following registry entries set to 96:



DontVerifyRandomDrivers HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\Memory Management\DontVerifyRandomDrivers.(REG_DWORD)

This parameter prevents the driver verifier from randomly verifying drivers for debugging. To disable the driver verifier set a value of 1 (REG_DWORD) for the following registry entry:

NumTcbTablePartitions HKLM\system\CurrentControlSet\Services\Tcpip\Parameters\. (REG_DWORD)

By default this key is not created.

This parameter controls the number of TCB table partitions. The TCB table can be partitioned to improve scalability on multiprocessor systems by reducing contention on the TCB table.

NumTcbTablePartitions = 8

TcpAckFrequency Note: TcpAckFrequency applies only to Windows 2003 and later and.XP Clients .

For Gigabit cards:

HKLM\system\CurrentControlSet\Services\Tcpip\Parameters\Interfaces (REG_DWORD)

For each Gigabit adapter, add:

TcpAckFrequency = 8 (decimal)

By default this entry is not in the registry.

If only acking data and not any control packets, ack once every 8 packets, instead of the default of 2. This helps reducing packet processing costs for the network stack in the case of large writes (uploads) from the server to client or client to server.

Configuration Tips and Tricks

Restricting your Internet Agent to talking to relay servers

Implementation Purpose:

To ensure the only machines that can transfer mail to your GWIA are your mail relay servers and your GroupWise MTA(s).


You use a mail relay model within your environment. Your GWIA(s) is not configured to discover mail servers to send mail to. You explicitly direct it to another SMTP service to send mail through.

You have open relay disabled on your GWIA(s).


You are able enforce which computers can connect to your Internet Agent to send mail.

Facilitates service load balancing implementations.

Doing so helps prevent your mail server(s) from being used to send mail from unauthorized internal systems or foreign systems. Some of this mail could even appear to come from your domain(s).

You can send mail to another SMTP service that may provide enhanced SMTP services, service aggregation, throughput, or metrics gathering.


  • Ensure you can disable the agents open relay option and do so. Select the "Prevent message relaying" option from the "Access Control" --> "SMTP Relay Settings" tab of the target Internet Agent object.

If you need to allow some servers to relay mail from your server be sure to configure relay exceptions for them now. Alternatively you could implement a GWIA explicitly for them to use and configure exceptions for them there.

  • Edit the "Default Class of Service" on the "Access Control" tab. Under the "SMTP Incoming" tab select the "Prevent Incoming Messages" option.
  • In the "Exceptions" section create the following entries in the "Allow messages from:" column:
    • *@*.*
    • Blank-Sender-User-ID

These entries are required for this configuration to work. Basically these records permit the agent to send outgoing messages and enable null sender message handling for incoming messages respectively. The latter messages include those used for listserv post notifications and other "do not reply" genre messages. We'll call it "querky" to be polite.

  • Also in the "Exceptions" section create entries in the "Allow messages from:" column for your relay server IP address(s) or DNS name(s).

Now the only machines that can transfer mail to your Internet Agent are the relay servers and its respective MTA.

Restricting your Internet Agents used for POP and IMAP to talking to load balancers

Implementation Purpose:

To ensure the only machines that can communicate with your GWIA using POP and IMAP protocols are your load balancers.


Load balancers are, or will be, used within your environment.

You have multiple GWIAs configured and dedicated to POP and IMAP clients installed on OES 2 or SLES 10 Linux instances


You are able enforce that which computers can connect to your Internet Agent to use POP and IMAP services.

Prevention of service use by unauthorized systems, and improvement of service security and performance by authorized systems.

Background Information:

The introduction of load balancing in the infrastructure can help improve the quality of many services. Ensuring service resource consumption is evenly distributed, and even re-directed in the event of a server fault or a designed service demarcation can be useful in large environments.

When the intention is to front end POP and IMAP services with load balancers you need to prevent clients from connecting to these agents directly. GroupWise provides no native tools that will allow you to restrict access to GWIA provided POP and IMAP services by network address.

Additionally, most load balancers will allow you to implement "SSL Off-loading". This can also be thought of as SSL certificate aggregation. Using this feature will allow you to use a single SSL certificate for a service provided by multiple GWIAs. The use of SSL off-loading can unify multiple agent identities to secure the communication between clients and services. Conversly, the communication between the service and the load balancer(s) can be optimised by turning off SSL security entirely if the back end components are within the secured network perimeter.


The only way to implement this model currently is to utilise the local Suse Linux Enterprise Server firewall. The SLES 10 firewall allows all outgoing communication by default. So, what is required is to configure the inbound ports required by a normal server participating in a networked environment to communicate successfully.

The chart below details the default protocols and ports that require configuration for OES 2 Linux servers. If the GroupWise Services are running on a SLES server a subset of the ports and protocols listed would be required.

OES 2 Linux and GroupWise Protocols and Ports

Service Protocol Ports Comments
Novell Jetstream TCP 6901 OES
iMonitor TCP 8028 OES
iMonitor TCP 8030 OES
wbem-https TCP 5989 OES

The easiest way to implement this configuration is to add the required ports to the appropiate sections of the /etc/sysconfig/SuSEfirewall2 file.

FW_SERVICES_EXT_TCP="123 1500 1501 1578 1579 1581 22 389 40193 427 524 5989 636 6901 7100 7102 7180 8008
8009 8028 8030 9850"
FW_SERVICES_EXT_UDP="123 427 524"

The best way to implement the connectivity for the load balancers and GroupWise Monitor is to add them as trusted hosts using the

appropiate section in the same file.

<LOAD_BALANCER_IP_1>/32,tcp,25 <LOAD_BALANCER_IP_2>/32,tcp,110 LOAD_BALANCER_IP_2/32,tcp,143
LOAD_BALANCER_IP_2/32,tcp,25 <GWMONITOR_IP>,tcp,8400"

Restart your local firewalls and verify your services are communicating as expected. If all is working well the result will be a server that can participate in the service provider role, service administration role, and network environment successfully.

Also remember to add any other third party software ports to your firewall configuration. Enterprise monitoring and backup services are the first that come to mind.

Configuring relay exceptions for your Internet Agent

Implementation Purpose:

To manage and authorize email relay operations for your GWIA(s)


GWIA email relay behavior is predictable, auditable and more secure

Background Information:

The best way to prevent abuse of your GroupWise Internet Agents from internal or external systems is to utilise public facing relay servers and access control tools. The previous section detailed how to manage the SMTP connections to your GWIA. This sections deals with the management of GWIA email relay behavior once a connection is allowed.

Understanding the behavior of your agents is key to implementing a predictable configuration. The best way to accomplish this is by knowing the variables, testing and finally documenting. Consider the truth tables below that were developed using the following information:

  • The public facing relay server will only accept mail from iDomains known to the GroupWise system
  • GroupWise Internet Agents will deliver mail to known iDomains without a relay exception configured

Relay Exception: "None"

From To GWIA Relays or Delivers Relay Server Delivers
<Any known iDomain> <Foreign Domain> NO N/A
<Foreign Domain> <Any known iDomain> YES N/A
<Any known iDomain> <Any known iDomain> YES N/A
<Foreign Domain> <Foreign Domain> NO N/A

(Used for internal delivery when no relay configuration is required)

Relay Exception: "<Any Known iDomain>"

From To GWIA Relays or Delivers Relay Server Delivers
<Any known iDomain> <Foreign Domain> NO N/A
<Foreign Domain> <Any known iDomain> YES N/A
<Any known iDomain> <Any known iDomain> YES N/A
<Foreign Domain> <Foreign Domain> NO N/A

(Used for internal delivery when a relay configuration is required)

Relay Exception: "*"

From To GWIA Relays or Delivers Relay Server Delivers
<Any known iDomain> <Foreign Domain> YES YES
<Foreign Domain> <Any known iDomain> YES N/A
<Any known iDomain> <Any known iDomain> YES N/A
<Foreign Domain> <Foreign Domain> YES NO

(Used for external delivery)

This example may differ from your environment but the concepts will be the same. Good planning leads to good results.

Configuring the WebAccess Agent for redirection and fault tolerance

Implementation Purpose:

To use two or more WebAccess Agents to redirect users to a specific agent and provide alternate ones in the event the preferred is not available.


There are multiple WebAccess Application instances and Agents already available and properly configured for normal operation within your environment.

Having multiple WebAccess Application instances on different network addresses, and possibly even load balanced using hardware or software would be a huge positive.


Users are directed to a preferred WebAccess Agent when they log in. If the primary is not available the alternate will assume the work.

If the primary fails whilst the user is logged in the user is migrated to the alternate agent. Since the session stuff is managed by the web application server this is transparent to the user. The best part is when the primary agent becomes available again the user migrates back. Awesome.


  • Ensure all target WebAccess agent encryption keys are identical. This is imperative as redirection will not work without completing this step. The field containing the encryption key used by the agent can be found on the "WebAccess" tab for the agent object in ConsoleOne.
  • For Linux servers modify the "/var/opt/novell/groupwise/webaccess/webacc.cfg" file manually to place the following entries in the "# Values added by install to update config file" section near the end of the file. Ensuring no other matching entries exist or conflict.
For NetWare and Windows the path to the webacc.cfg will be different will be different.
Manually modifying the webacc.cfg files disregards convention in respect to using the WebAccess Application Objects to perform this task.
Since the objects are simply a front end for the file changes administrators should use their best judgment for choosing a method to use for this change.
  • Using ConsoleOne add a primary WebAccess Agent override to the desired post offices.
  • Again using ConsoleOne add a second WebAccess agent override to the post office parent domain to serve as an alternate agent
  • The GroupWise Access Provider list specified in the webacc.cfg files for the application servers will ensure the tertiary agent is made available to users as it is the last configured component in the agent list hierarchy.
  • Restart the WebAccess Application services and agents to put the new configurations into effect and test.

Forcing WebAccess URL paths to use HTTPS

Implementation Purpose:

To force URLs that contain http:<web_server_address>/gw/<anything_else>/ on Linux GroupWise WebAccess Application servers to use an https:// form of the URL.


  • A configured Linux Apache web server with the GroupWise WebAccess Application installed
  • The mod_rewrite Apache module is installed on the Linux server instance (ussually this is the default configuration for OES and SLES servers)


Apache on OES and Suse Linux distributions is pre-configured to process all files that end in a “.conf” extension in "/etc/apache/conf.d" directory on service startup. This is the preferred method to make modular changes to Apache instances instead of modifying the primary httpd.conf file. Apache should be restarted after placing the file in the referenced directory.

  • A file named “gw-https.conf” containing the required directives could be created and placed in the “/etc/apache2/conf.d” directory of the target server.

The contents of the proposed “gw-https.conf” file are displayed below:

# HTTP_HOST is a variable that represents your web server address and shouldn't be changed.
# Turning the rewrite Engine on may not be required
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/gw
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]

Your WebAccess URL on this server should now re-direct to HTTPS regardless of the URL address form used by user browsers.

Configuring a clustered NetWare WebAccess Agent to use SSL certificates

Implementation Purpose:

To successfully configure the HTTP management port for the GroupWise WebAccess agent to use SSL services when being accessed.


  • You have a functioning clustered WebAcess agent(s) running on the NetWare platform
  • You have properly configured SSL certificate files accessible to the agent
  • You receive 8209 "path not found" errors when you configure the SSL certificate for the agent

Oh ... and the agent won't load unless you disable the SSL configuration.


Obviously, using SSL when you communicate with, and authenticate to, the agent management port and secure inter-agent communications when configured.


The problem here is that for some reason the NetWare WebAccess agent won't use the NCP Virtual Server name in the certificate file path. Instead use the cluster volume format for the certificate path in the "SSL" configuration section for the WebAccess agent object.

For example:


Then configure complete the normal SSL configuration for the agent and restart it.

If the agent starts its a very good sign and most likely reflects a good result.

Using NFS to extend GroupWise SDD hosted on Linux

Implementation Purpose: To make a SDD on an OES Linux clustered Posix volume available to servers and clients outside of the cluster

Assumptions: The volume containing the SDDs are available to all required nodes within NCS cluster


  • A configured Posix file system cluster resource in a OES Linux NCS Cluster
  • A SDD or set of SDDs configured within that file system


Create the cluster"able" NCP volume resource:

  • Configure a branch of the POSIX file system to hold your SDD(s) you want available over NCP. This means copying the platform appropriate software to directories within that file system as well.
  • Configure a NCP share on the POSIX cluster according to the following instructions:
    • Create a NCP share by issuing the following command on the server where the shared storage is currently mounted:
ncpcon create volume <NCP_VOLUME_NAME> <SHARE_POSIX_PATH>

Use case standards that match your institutional standards for the NCP volume objects and verify the volume object was created in the target server context using the <SERVER_NAME>_<NCP_VOLUME_NAME> format. Use the following command to verify the volume was created and mounted

ncpcon volumes
  • Edit the /etc/opt/novell/ncpserv.conf and remove the reference to the newly created NCP volume
  • Restart the eDirectory daemon after modifying the ncpserv.conf file using the following command:
/etc/init.d/ndsd stop && /etc/init.d/ndsd start
  • Restart the NCP/NSS IPC daemon after modifying the ncpserv.conf file using the following command:
/etc/init.d/ncp2nss stop && /etc/init.d/ncp2nss start
  • Create a virtual NCP server object for the new NCP volume using the following command:
  • Verify the virtual NCP server object was created successfully
  • Modify the new Virtual NCP server object using iManager and add the “NCS: Volumes” attribute to the object
    • Edit the "NCS: Volumes" attribute by adding the NCP volume object representing the NCP share as the value for the attribute
  • Modify the new NCP Volume object which is located in the same context as the server it was created on
    • Edit the "hostServer" attribute to match the name and context of the target NCP virtual server object
  • Rename the virtual NCP server and NCP volume object to match the institutional standards for your organization

Cluster NCP volume resource:

  • Modify the NCS cluster load script with the following italicised entries
. /opt/novell/ncs/lib/ncsfuncs
# define the IP address
# define the file system type
#define the container name
# define the device
# define the mount point
# define NCP volume
# define NCP server name
#activate the container
exit_on_error activate_evms_container $container_name $MOUNT_DEV
# mount the POSIX file system
ignore_error mkdir -p $MOUNT_POINT
exit_on_error mount -t $MOUNT_FS $MOUNT_DEV $MOUNT_POINT
# add the IP address
exit_on_error add_secondary_ipaddress $RESOURCE_IP
# mount the NCP volume
exit_on_error ncpcon mount $NCP_VOLUME=210,PATH=/media/posix/emailresources/ncp-share
# bind the NCP volume
exit_on_error ncpcon bind --ncpservername=$NCP_SERVER --ipaddress=$RESOURCE_IP
exit 0
Replace volume mgr container, network address, NCP server, volume names, and NCP_VOLUME values with your own
  • Modify the NCS cluster unload script with the following italicized entries
. /opt/novell/ncs/lib/ncsfuncs
# define the IP address
#define the container name
# define the mount point
# define NCP volume
# define NCP server name
# unbind the NCP volume
ignore_error ncpcon unbind --ncpservername=$NCP_SERVER --ipaddress=$RESOURCE_IP
# dismount the NCP volume
ignore_error ncpcon dismount $NCP_VOLUME
#dismount the POSIX volume
exit_on_error ncs_dismount $MOUNT_POINT
# del the IP address
ignore_error del_secondary_ipaddress $RESOURCE_IP
#deport the container
exit_on_error deport_evms_container $container_name
# return status
exit 0
Replace volume mgr container, network address, NCP server, volume names, and NCP_VOLUME values with your own
  • Test your clustered NCP share and move on when all is working as expected
  • Compose a script similar to the one below to export the desired SDD(s) over NFS
#! /bin/bash
# Enable NFS Shares
/etc/init.d/portmap start
/etc/init.d/nfsserver start

# Load NFS Shares
/usr/sbin/exportfs -o ro,no_root_squash
/usr/sbin/exportfs -o ro,no_root_squash

Exports the desired file systems via NFS.

  • Compose scripts similar to the one below to un-export the SDD(s)
#! /bin/bash
# Unload NFS Shares
/usr/sbin/exportfs -uaf

# Disable NFS Shares
/etc/init.d/nfsserver stop
/etc/init.d/portmap stop

Removes all active NFS exports on the server

These scripts assume that the portmap and NFS Server services are disabled on the server. Adapt the scripts for your server ans services environment.

  • Name these scripts something like...

... and place then on the storage accessible to the cluster resource and modify the cluster load and unload scripts to call them.

  • Now compose scripts similar to the following to mount and unmount the exported NFS shares to any non-clustered servers for software installation
if [ -d $directory ]; then
  echo GroupWise SDD mount point exists, proceeding to NFS mount
  /etc/init.d/portmap start
  mount -t nfs -o rsize=8192,tcp emailresources:/media/posix/emailresources/linux-share/software  /gw8/
software.sp2 /media/software
  echo The GroupWise 8 SP2 software is available at /media/software
  echo Please use the script when complete to deactivate NFS share
  echo GroupWise SDD mount point does not exist
  echo Creating mount point...
  mkdir /media/software
  echo Proceeding to NFS mount
  /etc/init.d/portmap start
  mount -t nfs -o rsize=8192,tcp emailresources:/media/posix/emailresources/linux-share/software
/gw8/software.sp2 /media/software
  echo The GroupWise 8 SP2 software is available at /media/software
  echo Please use the script when complete to deactivate NFS share

The above script checks for the /media/software mount point and creates it if it doesn't exist. It then mounts the specified SDD over NFS to that directory.

This is also why it's useful to put an "ID" file in the SDD to identify the software version using the text interfaces :) .

umount /media/software
/etc/init.d/portmap stop
echo The GroupWise Software Distribution Directory
echo       has been successfully unmounted

The above script unmounts the imported NFS share. Understand that these are very simple scripts with almost no error control or management.

  • Name these scripts something like...

... and place them "/usr/sbin" and have it's permissions changed directory of the target GroupWise server and configured so only the root user can run them.

  • Create as many scripts as needed for software versions and distribute them to the necessary servers

Setting up a GroupWise micro-SDD

It's important that the GroupWise POA have access to its configured SDD in order to retrieve the SOFTWARE.INF file for the GroupWise client.

When a GroupWise client detects that the bump number for the user's post office is different then the bump number in the Windows Registry, it tries to access the software.inf file, and a setup executable such as the setup.exe in the <SDD>\CLIENT\WIN32 folder.

If the GroupWise client determines that it does not have the access or a drive letter mapping to the SDD assigned to the post office, it asks the POA to help the client retrieve the software.inf file so it can determine the software version in the SDD.

When the POA delivers the software.inf file to the client:

  • It looks at the "BuildNumber=" value in the file and compares it to the BuildNumber key value within the Windows registry. If the BuildNumber in the file is greater than the BuildNumber in the registry, the GroupWise client requests that the POA retrieve the setup.cfg from the <SDD>\CLIENT\WIN32 directory.
  • The setup.cfg file is read and if the IP based update is enabled it transfers the gwipupdt.dll, gwupdten.dll (for English), setupip.exe, and setup.ini files to the GroupWise client over port 1677. The successful delivery of these files to the client allows the client update to initiate.

This dictates the minimum files to implement a valid SDD for client updates. If there are additional language library files required they should be added as well. If the SetupIP.exe application is configured to pull the actual client installation files from other sources over HTTP these files do not need to be present within the SDD.

File system layout:


  • ../client
    • /win32
      • setup.cfg
      • setup.ini
      • setupip.exe
    • software.inf
    • gwipupdt.dll
    • gwupdten.dll

Web Server Directory

  • ../gwclient
    • /win32
      • setup.cfg
    • setupip.fil
    • setupip.en

With this minimum file footprint the SDD can be configured within the system and fully participate in GroupWise client auto-update for Windows clients.

Creating a Domain

There are times when you need to create a secondary Domain and it can be difficult to talk to the server at the final destination. This might be because the final destination is yet to exist, the WAN link is poor, it is still being built, whatever. In the Linux world a more common problem is that you have created a pure SLES server in the DMZ and there is no way that ConsoleOne can talk to that server - no NCP, no Samba or to use the vernacular - No Nuthin. The way to resolve this is to make use an old IT quote - "If at first you don't succeed, Cheat!"

When you create a new Domain, you have to specify a path to where that Domain will reside. What the creation wizard doesn't say is that the path specified has to be the final resting place...

Open ConsoleOne and connect to the Primary

Create the new Domain and follow through the Wizard. Use a local path
 (C:\temp  or /mnt/temp)
Remain connected to the primary and change the new Domains properties to the correct final path
 (UNC or Linux)
Rebuild the new Secondary Domain - When prompted for the path, change to C:\temp

Copy the Domain, DC files etc. to the final resting place (File copy, USB stick)

On the SLES server in the DMZ you can start the MTA and then create what ever gateways you require, the communication between the secondary domains will deal with any later updates, changes or synchronisation.

Rebuilding Databases

When rebuilding a Domain or a Post Office you are prompted with a dialogue box for the destination path - never use that path, always rebuild to a local path. (See Top Down Rebuild below for more details)

How to do a Top Down Rebuild

This procedure is usually recommended whenever a GroupWise system is experiencing domain or post office database issues or a GroupWise system server is experiencing frequent abends or some other system critical failure in which there is a potential of compromising the integrity of your GW data.

The GroupWise system Top Down Rebuild is also recommended for periodical maintenance and before any upgrades, i.e. version or major patching implementation.

NOTE: Before proceeding, make sure that you have a current backup of the entire GroupWise system.

The Top Down Rebuild process requires the use of ConsoleOne with the GroupWise 8 snapins installed. Always use the latest version of the snapins for the version of GroupWise installed

The Stand-alone version of GWCheck for GW may also be needed to complete this procedure. For most GroupWise 8 systems, GWCheck is located in your patched Software Distribution Directory under the ..\ADMIN\UTILITY\GWCHECK folder.

When performing a top down rebuild, do it in the following manner, all steps below are done under GroupWise System in ConsoleOne...

1. Stop the Primary Domain. Copy the existing WPDomain.db to a safe location.

2. Restart the Primary Domain

3. Open ConsoleOne and Connect to your Primary Domain

  • Leaving all agents up and running, right mouse click each Secondary Domain under GroupWise System view
Select GroupWise Utilities
System Maintenance
Sync Primary with Secondary
OK to the path given in the Database Path dialogue.  

  • Do this on each Secondary Domain before rebuilding the Primary Domain.

Note: If the following error is displayed: "Error: Access denied. Caller is not allowed access to a file", unload any GroupWise Gateways that are accessing the secondary domain database file (GWIA, WebAccess, API, etc.). and ensure that there are no Administrators with ConsoleOne locking the databases.

Note: If the remote path is unavailable - Cheat! Copy the remote secondary Domain's wpdomain.db file to a local directory, add the DC files. Then re-run the Sync Primary with Secondary but change the path to this local copy when prompted for the path.

4. Rebuild the Primary Domain

Right click the Primary Domain object and select GroupWise Utilities
System Maintenance
Rebuild Database
  • Then on the Database Path dialogue in the Path to Database field, change the path to C:\temp, and click OK (Note: This path must exist). This will create a new domain database in [file:///C:/temp C:\temp].

Note: do not use the path as presented as this will not allow for a backup (un-rebuilt) copy of the Domain

  • When the rebuild has completed, close out of ConsoleOne and shut down all the GW agents, i.e. MTA and POA for this domain, as well as any gateways you may have running within the primary domain <shudder>.

Note: Closing ConsoleOne is only necessary after rebuilding the Primary Domain because you are connected to that domain and that connection holds the wpdomain.db open, preventing the renaming of the file.

  • In the domain dir. rename wpdomain.db to wpdomain.db.xx-xx-xx where xx-xx-xx is day, month and year
  • "MOVE" not "COPY" up the new wpdomain.db from your c;\temp, this will remove the new wpdomain.db from your hard drive so you do not accidentally copy it up to another domain location.
  • Then rename the queue directories, wpcsin to wpcsin.old, wpcsout to wpcsout.old and mslocal to mslocal.old. In the event that there have been a significant number of admin messages that have failed to process in the past, clearing these queues will ensure that there is nothing that will be applied “after the fact”
  • Bring up just the MTA and reload ConsoleOne. (To ensure that only the domain is running until the rebuild is complete)

5. Stay connected to the Primary Domain and we then start rebuilding all Secondary Domains. Repeat the steps above for for any Secondary Domains in your system.

Rebuild Secondary Domain to [file:///C:/Temp C:\Temp]
Stop Secondary Domain
Rename existing WPDomain.db to wpdomain.db.xx-xx-xx
Move new  WPDomain.db to server
Rename wpcsin, wpcsout and mslocal
Start Secondary Domain

6. After each secondary domain has been rebuilt, it is then possible to rebuild the dependant post offices.

  • The rebuild steps are much the same as for Post Offices as they were for your Domains, except you will need to be connected to the owning domain when rebuilding a Post Office database (As opposed to the Primary). You may also wish to rebuild any PO's in your Primary Domain before continuing on to rebuild all Secondary Domains. It is possible to rebuild a post office to C:\temp while the Post Office is running, however no other admin changes should happen at this point in time, and the Post Office will need to be stopped to replace the WPHost.db

7. Rebuild Post-Office while connected to the owning domain

Right click the Post-Office object and choose GroupWise Utilities
System Maintenance
Rebuild Database
  • Then on the Database Path dialogue in the Path to Database field, change the path to C:\temp, and click OK.
Stop the POA
  • When complete go to your PO dir. and rename wphost.db to wphost.old and "MOVE" not "COPY" the new one from your "C" drive, this will remove the new wphost.db off your hard drive so you won't accidentally copy it up to another post-office.
  • Rename the queue directories, wpcsin to wpcsin.old, wpcsout to wpcsout.old. This is to be 100% certain that there are no administrative messages in the queues that will be processed when the Post Office restarts.
  • Bring up your POA agents check that there are no error messages.

8. After a TDR is is advisable to run a contents check on the data and to review the necessity of Quickfinder Index Rebuild. If these jobs are scheduled as “Scheduled Events” then these will complete in the usual time frame.

Bad Habits

Never, Ever, under any circumstances ermm forget to check your references  :-)

Single Domain Systems

It is quite possible to set up a complete (small) GroupWise system using just a single GroupWise Domain. Don't... You lose your one and only Domain you are up the creek, sans paddle! Like eDirectory and AD, GroupWise Domains are replicas, thus if you have a secondary Domain you can rebuild. You have been Warned!

Moving users when connected to the source domain

Simply put don't do this as it is just plain incorrect. Always initiate user moves from the destination domain after connecting to it.

If you do initiate a move while connected to any other Domain, including the primary, you add an additional layer to the complexity and increase the likelihood of failure .... really.

Domain link configuration malpractice

When adding a new domain do not forget to configure its links. The default link configuration for new domains is an indirect link to all other domains via the primary. If this was not your intention then .....

Always connect to the primary domain when modifying a domain's link configuration. After all it does know how to connect, and therefore direct admin traffic, to all other domains. Once connected to the primary modify the links from the target domain's perspective. This way all changes can be made in one screen.

Additionally, only change and save either incoming or outgoing links at a time. Changing and saving them both simultaneously could lead to issues with your inter-domain traffic. You could lose some hair, nails, and skin getting it all sorted.


DBcopy is a great tool for migration there are a couple of bad habits to avoid and a couple of others that would qualify as Good...

BAD - If you run DBcopy with the /s and /o (-s -o on Linux) then you will NOT copy any blobs over - shame really as this is a second pass

BAD - Running any DBCopy with the /l switch (-l on Linux) where you have a source and destination specified - This will do a MOVE and not a copy and thus it will ensure that you will have a bad day

POOR - When migrating from NetWare to a SLES or OES2 server, there is the option to use NCPMOUNT to mount the original NetWare volume on the SLES/OES2 server and then run DBCopy on the new server. You can grow old waiting for this to complete.

UPDATE: The above statement is true IF you do not specify to use tcp on the ncpmount command. Do this with -o tcp and watch the blobs fly.

BETTER - Far better (if you can) to use a Windows Workstation to do the DBCopy with mapped drives for the source and destination - far, far faster! NCPMOUNT is notoriously slow...

NOTE: With OES2 SP2, you have the benefit of using the embedded Novell Client (ncl)- this will simplify operations and improve the speed immeasurably!

Using legacy or incorrect snapin versions

Allowing administrators to administer GroupWise systems with legacy components can lead to a very bad result. Minimally the result may be not being able to make a configuration change because the legacy snapins do not understand updated agent or system features. At worst the creation of incorrect agent databases respective of version or even the corruption of existing databases could occur.

All domains within your system should utilize the lockout feature for administrative snapins to prevent the use of legacy or unwanted management snapins against your system.

Not Disabling QuickFinder during scheduled maintenance

Ever started a top down rebuild during the evening just to have QuickFinder maintenance kick in for the entire system in the middle of the effort? It's an annoyance best avoided so remember to turn it, and other automated maintenance, off during large scheduled maintenance windows.

Just remember to turn it back on when done :)