GroupWise 8 Design System
GroupWise 8 Design System
- 1 GroupWise 8 Best Practices
- 2 GroupWise 8 Design
- 3 GroupWise 8 Design System
- 3.1 Introduction
- 3.2 System Design
- 3.2.1 System component relationships
- 3.2.2 System naming standards
- 3.2.3 Agent configuration standards
- 3.2.4 System policy standards
- 3.2.5 ConsoleOne use and scope
- 3.2.6 Legacy or Incorrect Snapin versions
- 3.2.7 GroupWise Monitor use and scope
- 3.2.8 File systems
- 3.2.9 Volumes, Drives and Mount Points
- 3.3 Hardware
- 3.4 Post Office Configuration Best Practices
- 3.5 Library Placement and Configuration
- 3.6 Internet Addressing
- 3.7 GroupWise Client
Any GroupWise deployment should be planned prior to implementation. Sometimes the application of this concept by the administrators of smaller systems is done so too casually. Often small systems grow into larger systems for a plethora of reasons. It is often difficult, sometimes very difficult, to implement best practices in an expanding system with legacy design hurdles in the way.
Whereas in the Architecture section we emphasised the importance of the structure, in this section it is the relationship between the design and the physical system (world/environment) that is important.
System component relationships
Service driven requirements
Consider the focus of the service to be consumed. This could mean load, availability, and end user experience expectations. Planning a service and seriously considering these items could significantly impact your design considerations.
Domains, gateways, service and user post offices, etc
Even in single domain systems it is best to implement a secondary domain if only for redundancy. Having a second copy of the GroupWise information store can only benefit a system. Another consideration is placing users who are most likely to communicate with each other on the same domain. However this becomes important on large, or potentially large, systems.
Other considerations are placing gateways on their own secondary domains instead of those used by post offices. Since gateways tend to be the most volatile components within a system placing them on domains that don't have a direct impact on the end user experience is desirable.
Consider aligning post office memberships with users who are most likely communicate with each other. Implementing dedicated post offices for applications, trusted or external, or automated services that consume email resources is often in the best interest of any system. Especially as it grows.
The importance of designing post office access with end user, and subsequently end user support staff, usability in mind cannot be understated. Consider planning and implementing your Post Office Agent (POA) network address naming scheme so that end users never have to place a call to determine what â€œIP addressâ€ they need to configure their GroupWise client with.
System naming standards
Agents' directory objects
Do implement naming standards for all GroupWise system objects. Not only does this result in a organized and professional appearance but it also assists in system growth and troubleshooting scenarios. It would be easy to assume that we will always have the graphical view of our system using the ConsoleOne or iManager applications. However within larger systems that use third party tools, such as those common to bulk operations, to perform maintenance or assessment tasks being able to identify an object type by its name could be extremely useful.
File system, mount points, directory, and configuration files
Since dealing with these components claims a respectable percentage of an administrator's time, increasing usability in this area has obvious benefits. Mount point names, drive letter assignments, or volume names for storage used for GroupWise information stores should be standardized. Additionally the names and locations for the parent directories for those information stores, including gateway directories, should be standardized as well.
Often administrators will have to interact with GroupWise agents using command line interfaces. Standardizing agent startup and configuration files certainly helps here. Often troubleshooting email issues, or loading a failed service on the fly, is an extremely time sensitive affair and application configuration file names can be a nuance or a caveat.
Agent configuration standards
Agent startup files should be standardized unless an agent requires a specialized configuration. A minimalist approach is best with the information contained in the agent startup files. Ideally it should only contain the agent's â€œhomeâ€ switch and its respective value.
The ability to store an agent's configuration in the domain or post office database should be leveraged as much as possible. Troubleshooting or configuration change efforts can be hampered by having unnecessary agent configuration options in the agent startup file. Remember that GroupWise agents pull configuration information from the command line, the startup file, and then the agent configuration database in that order. Adjusting agent startup files or using the command line to troubleshoot agents is a very common and valuable practice. Just be sure to return the agent configuration back to your organizational standards if applicable.
System policy standards
Message retention policies
This type of policy is extremely difficult to implement in an existing system. Ironically it's also the best one that can benefit a system's health pro-actively. It is also the most complicated system component to plan for. Issues range across end user usability, support infrastructure, and even legal boundaries. Limiting the amount of on line storage an account can consume will vary greatly from organization to organization and may be the simplest end of the equation for the administrator. Do plan for this aspect of your GroupWise systems health as early as possible.
Whether you utilize GroupWise restore areas for day to day operations or for emergency recovery objects they require a system level configuration change to implement. The internal system names and storage locations should be standardized to align with the post office that owns it.
Client Options settings
These settings again will vary from organization to organization, but should align with providing predictable end user experiences in your environment.
Automated maintenance services
All GroupWise post offices should experience scheduled â€œContentâ€, â€œStructureâ€, â€œExpire/Reduceâ€, â€œAuditâ€, and â€œDisk Checkâ€ maintenance events.
The MTA for the Primary domain should perform the scheduled eDirectory synchronization event for a GroupWise system.
ConsoleOne use and scope
Since there is no management tool, whether it be iManager or stand alone web based, on the immediate horizon we'll limit our discussions to ConsoleOne.
Platform does matter.
Having a GroupWise agent's file systems on NCP accessible storage gives several advantages. Most importantly it allows administrators with management applications running on the Windows platform to manage GroupWise system components and user accounts without regard to the server platform hosting the service.
There are without a doubt many GroupWise systems, or a subset of their components, still being managed by utilities on Windows workstations. The fact that Novell has patched the most recent version of ConsoleOne to make it more compatible with Windows 7 speaks to this. The majority of environments are likely mixed platform systems. Placing as many GroupWise agents on NCP accessible file systems allows for the most uniform management models that require very little change for staff.
All of these system component instances can be managed by remote instances of ConsoleOne running on Windows or Linux based computers that are also running the Novell client software.
However whereas it is technically possible to manage GroupWise information stores that are mapped to Linux systems running the Novell NCP client it should not be your first choice.
There may be times when you cannot place GroupWise system components on NCP accessible file systems. This assertion will vary across organizations but could likely be limited to GroupWise web applications, monitoring services, and some gateways. All of these system component instances are managed by local instances of ConsoleOne running on the OES Linux servers hosting the service.
These instances will require the ConsoleOne application and GroupWise snapins be installed on the target server. However you can still run your ConsoleOne management sessions from your Windows systems (or Linux if you have a ponytail) remotely utilizing an SSH client. Put simply, you can configure SSH to forward the ConsoleOne application to your workstation so it appears to be running on your desktop the same as any local application.
You can of course still run it from the server console as well.
Please see the Running ConsoleOne on a remote Linux box section of this wiki for instruction on running C1 via an SSH "X11 Forwarding session".
Legacy or Incorrect Snapin versions
Allowing administrators to administer GroupWise systems with legacy components can lead to very bad results. 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.
GroupWise Monitor use and scope
All GroupWise systems benefit from agent and service level monitoring. Knowing when an agent fails is key to resolving service outages quickly. However GroupWise Monitor understands GroupWise services and processes natively and can trained to alert you to subtle issues that can become large issues if left unattended.
GroupWise Monitor Services, resulting from the marriage of the GroupWise Monitor Application and the Monitor Agent, allow you to be very granular with your system monitoring model. In a nutshell the GroupWise Monitor Application, which requires the standard Apache and Tomcat web application components, monitors agent states, generates alarms, and sends notifications.
Conversely the GroupWise Monitor Agent provides additional system performance testing, trending, and reporting in addition to the Monitor Application features. Most importantly it is utilized for the GroupWise High Availability Service (GWHA) to make your GroupWise agents running in the Linux platform highly available. When the Monitor Agent detects an agent has failed it will connect to the target server and restart the agent.
Additional server configuration info for GWHA services can be found here Configuring Servers to use the GroupWise High Availability Service
Additional Monitor service configuration info for GWHA services can be found here Configure the Monitor Agent to communicate with the GWHA service
However most of the features delivered by the Monitor Agent require it to have access to a domain participating in your system. Since it is considered best practice to dedicate domains to specialized services GroupWise Monitor should be no exception. Consider implementing a domain and MTA on the same server as your Monitor service. It could even be a great virtualised server candidate.
Running the GroupWise Monitor Application and Agent on the same Linux server works well and conserves resources.
Thresholds, alarms, and notifications
Firstly, if your system is large there are lots of things to monitor. Additionally if you plan on configuring thresholds and possibly notifications there may be a lot of email to manage. Consider using a dedicated email account for these messages.
Secondly, Consider using a lightly utilized SMTP server that is not prone to failure, one that is outside of the monitoring scope, or not even in the same system that GroupWise Monitor service is to send alert notifications. This way you are not dependent on a monitored service that may have failed for delivering failure notifications..... doh!
In order for thresholds to be useful they must be meaningful. You don't need to be notified every time an agent goes to an unknown state or when your SMTP server reaches its normal peak activity window. Meaningful thresholds for GroupWise systems seem to evolve best over time and come from experience of the system involved. Configure common sense thresholds, agents down and queue depth for example, during the initial deployment. As you observe trends in your system allow your threshold and notification model to evolve until you reach that proactive state that benefits your organisation.
GroupWise Monitor services should be implemented regardless of your system size simply due to the visibility of system internals it provides administrators.
File systems for use with GroupWise is a subject visited with some frequency: There has been much debate and many differences of opinion.
The following is considered as a base line for administrators to make a decision from, it is not all encompassing but contains the latest data on each of the file systems that is currently available where it concerns GroupWise.
- Linux File Systems
- The ext3 or third extended filesystem is a journalled file system that is commonly used by the Linux kernel.
- Advantages - Stable, efficient and resilient, the EXT3 file system is a good choice as a generalised file system for all services. Good data recovery from a file system corruption.
- Disadvantages - Directories with large numbers of files can slow file access. With SLES 10 this performance increased considerably.
- GroupWise Suitability - Good choice for Domains, Gateways and smaller Post Offices. Some users report reasonable performance up to 100GB volumes.
- Formerly the standard file system for SuSE distributions, with the reduction in support and development due the effective loss of the project leader, this has now been superseded on SuSE by EXT3.
- Advantages - File access speed and the ability to handle large numbers of small files.
- Disadvantages - Fragile; many users have reported that their Reiser file system has destroyed itself for no apparent reason. There are many reported cases of this behaviour available on the net. Poor data recovery after a file system crash.
- GroupWise Suitability - Whilst very fast, the lack of good recovery of data from a crash, combined with the innate apparent instability of the file system make this a poor choice.
- EXT3 + DirIndex (H-Tree)
- An HTree is a specialized version of a B-tree. They are constant depth of either one or two levels, have a high fan-out factor, use a hash of the filename, and do not require balancing. Htree indices are used in the ext3 and ext4 Linux filesystems, and were incorporated into the Linux kernel around 2.5.40.
- Advantages - Stable, efficient and resilient, the EXT3 file system is a good choice as a generalised file system for all services.
- Disadvantages - Directories with large numbers of files can slow file access. With SLES 10 this performance increased considerably.
- GroupWise Suitability - With H-Tree, ext3 becomes a very strong performer. However, there is a price to pay for the increased performance. GroupWise uses telldir(), seekdir(), and readdir(), in the calling of files, all of which return a cookie that is nominally the position in the file. It's unfortunately based an assumption that was true when the API interface was designed but is not currently true. The assumption is that directories will always be laid out linearly, so a file offset will be enough to identify the directory entry. Unfortunately, this offset is a signed int, where only positive values are valid. This translates to a cookie size of 31 bits in which to uniquely identify the position. The problem arises with ext3 hashed directories, because they use a 64-bit hash that consists of a 32-bit major and a 32-bit minor hash. Ext3 returns the major hash, which is additionally truncated by one bit. This not only eliminates the collision handling that the kernel handles internally, but also creates even more collisions for telldir(). (Note: The official Linux answer to this is - Stop using those APIs) Discounted
- XFS is a high-performance journalling file system created by Silicon Graphics, originally for their IRIX operating system and later ported to the Linux kernel. XFS is particularly proficient at handling large files and at offering smooth data transfers.
- Advantages - Stable, efficient and resilient, the XFS file system is a good choice as a generalised file system for all services.
- GroupWise Suitability - XFS is extremely fast, and it uses some very aggressive caching to achieve the throughput (CPU intensive). It's also questionable in its management to do with fragmentation etc. In addition there is a major problem to do with flushing inodes on umount and the ability to corrupt the file system see SGI OSS Forum The fix for this has only been included in SLES11 SP1 - Discounted on all other platforms.
- NSS (with OES2)
- The NSS file system is only available on the Linux platform when used as part of Novell Open Enterprise Server.
- Advantages - Stable, efficient and resilient, able to handle millions of files and folders. Good data recovery from a file system corruption. When not used in conjunction with NCP, performance is good.
- Disadvantages - Only available with OES2. Proprietary. Performance decreases markedly if the atime directive is enabled with large file systems.
- GroupWise Suitability - Good choice for GroupWise. With the NetWare platform having used NSS for many years, GroupWise programmers have been making use of many optimisations in the background. With atime disabled the performance is linear and better than with ext3.
In addition to the points raised above, consider some other options around NSS. Remember that NSS is powerful and flexible because it offers such features as compression, encryption, data shredding, modified file lists etc, but in a GroupWise context, such features are not required. As such, when creating an NSS volume (on Linux or NetWare for that matter), switch off all NSS features you know you don't need. How do I know if I need it? Well if you aren't sure, you don't need it. GroupWise content is already compressed and encrypted, so why do the same job twice?
Every NSS option you switch on has an overhead, and every overhead adds latency. It sounds obvious, but it's more common than not that an NSS volume with a post office or domain on it has all NSS bells and whistles turned on. For example, what use is salvage on a mail volume?
Remember also that mail volumes will write, modify and delete many small files over their lifetime. As such, mail volume performance may suffer if there is a build up of purgeable files on the volume that can be removed. Don't automatically assume that setting the Immediate Purge flag in Windows Explorer is all you have to do to switch this on, have a look at the OES2 documentation page for full instructions on how to configure the Purge Immediate flag for NSS.
Finally, we once visited a customer who had severe performance issues with a large post office. When we looked at the NSS volume hosting the post office, we discovered that the "Flush Files Immediately" flag had been set. Have a look at TID 10065215 to find out why that's a bad idea.
- Linux File Systems In conclusion there are two options for GroupWise: EXT3 or NSS
- There is a File System Primer on the OES wiki.
- There is only one choice of file system on the legacy NetWare platform, NSS
- There are configuration optimisations for NSS that will improve performance. GWTune.ncf is file designed to do just that.
- There is only one choice of file system on the Windows platform, NTFS.
- There are configuration optimisations for NTFS that will improve performance below in the NTFS File System section.
Volumes, Drives and Mount Points
GroupWise mount point configuration:
For Linux there is room for argument....
There are three possible locations for the creation of a mount point for GroupWise on the Linux platform. /srv/gwdata, /mnt/gwdata, or in the root as a dedicated /gwdata
- /mnt - As the /mnt is location for the temporary mounting of local or remote file systems. This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run. This directory must not be used by installation programs: a suitable temporary directory not in use by the system must be used instead.Â
- As the GroupWise daemons are services running on the server, there are not a temporary items and thus this is not a good choice of location.
- /gwdata (root mount point) - The creation of additional root mount point is considered very poor practice. There are several reasons why creating a new subdirectory of the root filesystem is prohibited the most obvious 2 are:
- 1)It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons.
- 2) It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes.
- Distributions are extremely careful about the creation new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.
- Thus it would imply that /gwdata would also not be a good choice of location.
- /srv - This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for read-only data, writeable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory.
- As can be seen this is the most logical target for a GroupWise mount point so /srv/gwdata wins
NetWare: Use a Volume dedicated to GroupWise and optimise for best performance.
Windows: Use a dedicated Drive for GroupWise and configure the Registry for optimal performance
This is always required
The GroupWise documentation has a section on the System Requirements that should be read before proceeding further.
All Post Office servers cache file information (for up to 15 mins) for maximum efficiency - writing the data back to disk but avoiding having to re-fetch the data the next time it is requested. The more memory that is available for this caching, the better the overall performance. On a 32 bit OS system the maximum memory that the OS and GroupWise combined is 32 bit (or roughly 3.6GB) which is sufficient for all but the very busiest of Post Offices. One a Windows platform the maximum allowed memory for any one Application on the 32 bit Platform is 2GB. From that we can deduce that most NetWare and Linux Post Offices on 32 bit platforms should have 4GB of RAM installed.
On a 64 bit machine, each 32 bit process can access the full 3.6GB (without the OS taking its share) - This allows the 64 bit version of Linux and Windows to provide better GroupWise performance.
Thinking through the storage system is important - what is there between the server and the data on the disk that can cause bottlenecks, slowdowns, contention or just pain?! There is an oldie but goody appnote on disk layout that is still relevant.
A GroupWise system is a Database system so the rules of thumb that apply to say a SQL server apply to GroupWise. When thinking of a Big Database server would you use a cheap embedded RAID card to host the data? The RAID function of embedded HP, DELL and IBM systems are really only good for RAID1 (Mirroring) and asking them to do fast calculations for RAID 5 and 6 is rather optimistic.
In some modern shared storage systems, the data can be migrated at a block level from fast expensive disk to slow cheaper storage and this can play hell with performance.
Rule of thumb for a new GroupWise Post Office is use SAS, SSD or FC disks only (Never SATA) and avoid contention with other Post Offices.
If you have, or think you have slow disk issues have a look at this TID
Many Factors Affect Disk I/O Performance, there are myriad best practices & considerations for optimal disk I/O subsystem performance.
Be mindful of all such factors:
â€“ RAID level â€“ File allocation unit size â€“ Number, size, & speed of disks â€“ Configuration of HBAs & fabric switches â€“ Network bandwidth â€“ Cache on disk, controllers, & SAN â€“ Whether disks are dedicated, shared, or virtualised â€“ Bus speed â€“ Number of paths from disk I/O subsystem to server â€“ Driver versions for all components â€“ Stripe size â€“ Stripe unit size â€“ Workload
Why the SAN guys hate youâ€¦
- Drives only got bigger, not faster
- You leave tons of empty space around
- You ruin their TCO story.
â€“ You need 10x72G 15Krpm disk drives (0+1) for a 100G transaction log. â€“ Thatâ€™s 620G of wasted space!!! * 720G space â€“ 100G t-log = 620G wasted * They canâ€™t â€œleverageâ€ that BIG investment they have. *â€“ Leverage = Sharing *â€“ We donâ€™t like to share
Note: - the above is a SQL statement! It applies to GroupWise just as much...
Look at backups and GWCheck
A long running backup, or GWCheck contents check jobs taking days to complete are indicative of larger architecture issues in your database.
When to and when not to virtualise
There are times when Virtualisation should and should not be used, this section provides thoughts and real world experience on what works and what doesn't. There is most definitely a place for virtualisation within a GroupWise system, the question is where; it is safe? If you are in a hurry, look at the end of this section...
With no more ado, let us start by reviewing VMware's recommended limits on VMFS
Max Recommended VMFS LUN size 512GB Max VMs per VMFS LUN 16
So your first thought here is what???
These are taken from the VSphere best practices and administration courses, combined with the internal documentation available to partners, so there has to be a reason for this! Let us examine this further.
The largest of the downsides is the hard drive configuration. For the most part when you set up virtual servers, you'll use the native virtual storage technique that comes with the virtual server software. This means that the hard drive that the virtual machine sees is in reality actually a single file stored somewhere on the shared storage. Combine this with the OS caching and driver model, combined with the virtualisation OS having caching in its driver layer and who knows what going on at the firmware level and what wrote out first, the log or the data? The design is great for a read only, low IO scenario: Something that GroupWise is not.
VMFS uses large file blocks, the minimum default is 1MB, but that restricts VMFS volumes to 256GB so that is rarely used. The largest size that a VMFS partition can be is 2TB (less 512bytes) which requires a block size of 8MB. Compare that with NSS or EXT3 or NTFS using a 64k block size or smaller... Great when the IO is mostly read based, but if there are files that regularly require updating or changing this architecture can cause problems (ofmsg anyone?)
The whole area of virtualised data sizes throws up a load of silly information, so rather than work through all of the issues, FUD and hype let us keep things simple.
Working through all of the internal data on VMware's web site leads to a number of conclusions:
Maximum safe size of a "pure" VMDK is 50GB Relational Databases (VMware stress MS SQL) should only be hosted on RDM Drives (Raw Disk Mapping) Maximum safe size for a heavily used RDM is 100GB Recommendation for a maximum RDM (with Low IO) is ~200GB
I know of lots of deployed systems that break these boundaries - but I have also seen a lot of scar tissue out there too...
Putting the boot in:
Youâ€™re adding an operating system: This aspect of virtualisation is easy to forget, because most virtual servers act like real servers, running a Microsoft Windows or other platform. But in fact, the virtualisation application itself (VMware, Microsoft Hyper-V, Xen, etc.) becomes the operating system on the server where it resides, with the operating systems of the virtual servers running as applications hosted on that system. Like any other operating system, virtualisation software needs to be patched and updated regularly, to ward off security threats, in addition to the patch management you still need to maintain whatever operating system the virtual server or servers are running. So now you have two operating systems to monitor and patch, instead of one!
On the other hand...
Having upset lots of folk with the above, now let us look at the positives: Where and what can you virtualise?
Any GroupWise gateway and its parent Domain make an excellent candidate for virtualisation.
Got a small Post Office? Virtualise using a RAW LUN for the data target
Routing Domain? Administrative Domain? IDM Domain? Virtualise - Maybe not the Primary though...
Rules of Thumb for GroupWise and Virtualisation
- If it's a large Post Office Don't
- If it is a small Post Office Use a RDM
- Anything else Go ahead, what are you waiting for?
Post Office Configuration Best Practices
Only allow Client/Server access to the POA
Configure every post office for Client/Server Only access mode. The GroupWise Information Store is reliable only if users have no file system rights to it. In Direct Access mode, users must have file system rights, and a GPF or cold-reboot can result in incomplete transactions and damage to the message store. Some Windows systems allow for write-behind caching to enhance responsiveness of the Windows interface. This feature will always introduce some level of corruption into the GroupWise message store if users run in Direct Access mode.
Use caching mode
Whenever possible, configure clients in Caching mode.
The Caching mode provides increased client performance due to the local storage of a mirror image of the user's live mailbox: folders, address book, calendar information, and all other information. Only changes are synchronized in the background.
The initial priming of this caching will be a heavy load for the POA; it is recommended to monitor this for load and to perform it during off-peak hours if possible. The priming is handled via client/server threads. A limit can be set on the POA of the percentage of the processor utilization for priming the caching. The default limit is 30% of the available client/server threads, not nearly enough.
Once the client is operating in Caching mode, the POA only has to provide new information to the client, run the rules, and monitor the state of the live databases and other activities. The GroupWise client has an option to "Repair Mailbox" in Caching and Remote mode, executing a local copy of GWCheck installed in the GroupWise client directory.
One situation where caching mode may not be desirable is for heavy document management users. Another is the fact that a copy, albeit encrypted, of the data exists on the users machine - unacceptable to some organisations.
Set your DNS up to redirect ngwnameserver to at least one Post Office on port 1677, ideally the one that will have the fewest online users attached to it.
On large systems, create a dedicated POA for ngwnameserver redirection. If you have more than 2,000 users, it is likely that at least a hundred of them will need to use redirection to find their post office in the morning. Dedicating a lightweight or virtual server to the task of ngwnameserver redirection prevents another post office from suffering a performance hit every morning as users log on.
The benefits of this configuration increase on larger systems (i.e. 10,000+ users). Note that for organizations using a local DNS for each site, the DNS ngwnameserver entry should point to a local POA and not to one across a WAN link.
Library Placement and Configuration
Establish libraries on the same post offices as the users who will be using them. Performance will be better if users do not need to search for or retrieve documents across the network. In most organizations, there are only a few users actively creating documents. The additional disk space required for a library on each post office should not cause problems.
Documents may be stored either under the post office library directory or in a separate location known as a document storage area. Carefully plan out the location of your document storage areas. Do not store documents from different libraries in the same document storage area.
After you begin using GroupWise libraries, ensure that you are performing regular backups of your library and document storage areas. It is also important that you back up the NGWGUARD.DB. You never want to recreate the NGWGUARD.DB if you have libraries under that post office.
QuickFinder Library Indexing
The indexing process is CPU-intensive and may impact Client/Server performance on post offices of even moderate size. Dedicate a server for Libraries with a Post Office dedicated to this function is the Linraries are large.
The majority of information in this section has been taken from TID 10066601 - GroupWise QuickFinder Indexing.
Due to age of this TID it focussed on the CPU load caused by the index process and the impact that this can have on the overall performance of the server. With the improvements with processor performance over the last 5 years and the ability of GroupWise to use the mult-processor environments provided by Windows and Linux the bottleneck has moved more to the I/O caused by the QuickFinder process. Currently the index files are held within the Post Office directory structure and so all I/O has historically taken place to the same disks that hold the Post Office, which for large systems has resulted in a trade off between the index system and servicing client requests. With the ability of GroupWise to operate on a Linux platform it is now possible to map the index directory to a different disk set by the use of Linux's ability to mount additional file systems within the overall file tree.
This better info
Novell recommends enabling Internet Addressing. Enable Internet Addressing on your GroupWise system after considering all points below. For more information about Internet Addressing, read the Internet-Style Addressing Guide in the On-line Documentation.
Preferred Address Format
Novell recommends never removing the address format "userID@IDomain" as this is key to a properly functioning Internet Addressing system. This format is the easiest way to ensure unique addressed and to match a common Internet e-mail address format used in different organizations.
The User.PO.Domain and User.PO addressing format options will prove to be somewhat problematic for moved users, and confusing to the outside world.
If you select the First.Last and Last.First options, then you will need to make sure the resultant Internet Address is unique; if not users are not unique use the Internet Override option ensure uniqueness.
Upgrading From GroupWise 7
A common issue when upgrading from GroupWise 7 is that the client executables are moved from their traditional home of C:\Novell\GroupWise into C:\Program Files\Novell\GroupWise. Although the GroupWise 8 client installer has got much better in detecting and removing old GW7 clients, scope exists still for DLLs and registry inconsistencies to remain.
One tool that has been a massive help to many GroupWise customers in the move from 7 to 8 has been the free CleanIt tool from Messaging Architects (download CleanIt here). It's especially handy because as well as being totally free, there are command line switches to allow the program to be run silently etc., meaning it's easy to run from a login script, or better yet, a ZENworks application object or ZCM bundle.
Remember that the client upgrade phase is the most visible part of the upgrade to your end users, and that suitable testing and planning should be performed against existing test systems/production images.
ZENworks Application Virtualization (ZAV)
For GroupWise customers who also use ZENworks Configuration Management, it's also possible to remove the old GroupWise 7 client and use ZAV to push down a pre-packaged version of the GroupWise 8 client that runs in a sandbox. ZAV8 provides a pre-built and tested GroupWise 8 client package from Novell, making it nice and easy to configure and deploy. Best of all, it leaves nothing behind on the workstation and can be run in conjunction with GroupWise 7 and/or Outlook, without treading on their toes.
Some customers even provide their users with a pre-packaged copy of the GroupWise client to run straight from a USB stick, for use in public access areas/cyber cafes etc. All messages are stored on the stick, nothing is installed on the workstation and no administrator rights are required.
Another benefit is that when a new support pack or hot patch version of the client is released, you simply withdraw the old ZAV application and deploy the new one, without having to worry about the uninstall process on the workstation breaking something! If you haven't seen ZAV yet, download an evaluation copy and see what it can do.