GroupWise 8 System Administration
GroupWise 8 System Administration
- 1 GroupWise 8 Best Practices
- 2 GroupWise 8 System Administration
This section contains information pertaining to administration concepts, tools, and advice for the administration of GroupWise systems and their components.
Please refer to the following GroupWise documentation:
There is also a Partner, Omni who offers a ZERO Rights web based solution
Please ensure that you only use the latest version of the ConsoleOne snapins with ConsoleOne version 1.36h. This is the only version of ConsoleOne that is supported with GroupWise 8.
To ensure that ConsoleOne 1.36h works correctly you will need to install it and not just copy the installation to your workstation as one did in days of old. This is to ensure that the updates required for C# are incorporated on the workstation.
Windows Vista, 7, and 2008 server:
Please see the ConsoleOne issues beyond XP section of this wiki for help with ConsoleOne issuse on the more recent platforms.
Please see the "How do I run ConsoleOne on Linux if I have a Windows Workstation" section the the FAQ section of this wiki for help with this.
NWAdmin should not be used to administer GroupWise version 6 or newer. However if you use the GroupWise API gateway you may require NWAdmin and the corresponding GW55 Snapins
Administrator Workstation Configuration
To ensure that the correct data is written to the WPDOMAIN.DB ensure that the following settings have been made for the Novell client:
1. Right-click on the red N in the right corner of the system tray and select "Novell Client properties..." 2. Click on Advanced settings. 3. Scroll down and find "File Caching" item -> set it to Off. 4. Scroll down and find "File Caching on Exclusively opened files" -> set it to Off. (XP Only) 5. Scroll down and find "File Commit" -> set it to On 6. If asked, reboot the workstation.
In addition to the workstation settings, the Cross Protocol Locks need to be enabled on the Linux server. In ncpcon, type "set CROSS_PROTOCOL_LOCKS=1" or add this line "CROSS_PROTOCOL_LOCKS 1" to the /etc/opt/novell/ncpserv.conf file. There is a limitation to this too, it only applies to Windows workstations. The Novell Client for Windows allows the NCP protocol to correctly enforce this. The Novell Client for Linux does not have this functionality yet.
The POA configuration, and the server configuration for the server the POA runs on, are the most important contributors to the satisfaction of your GroupWise users.
POAs Per Server
More then one GroupWise post office can reside on a server however as a general rule there should be but one Post Office per Server. Many customers have had success with more then one post office on a server, others have not.
The reason for the one Post Office per server rule is that the GroupWise POA will pummel the disk IO into submission and the POA will acquire all of the resources needed to maximise it's performance. When two POAs are loaded on the same server, they have no knowledge of each other, so whichever POA gets to the resource at any given moment can dictate that it's threads get more attention then the alternative POA. This can be problematic when one POA gets a hold of the processor first to do a bunch of message file processing when the other POA needs some client/server processing done. While a multi-core/cpu system will deal the processor threads, the disk IO contention will still remain.
Why is it then that some customers have success with multiple POAs and post offices on a server, whereas others have admittedly failed miserably with such configurations? Perhaps it has to do with the dynamics of how things are configured on the POAs, and dynamics of how E-mail is used in that organisation. For example, imagine that at ACME, E-mail is expired after 90 days, trash is purged each night, and the quickfinder indexing is set to happen early each morning at 2:00 A.M. Other fine tuning parameters have been made on the POA to see that it runs efficiently. The users at ACME are motivated to work hard because of a good compensation and clear corporate goals. The users rarely have time for sending movies to each other in E-mail, and they don't deal much in other big files. Users at ACME work in close-knit workgroups, and E-mails to large groups are only sent by corporate communications after-hours. Do you think ACME can get away with putting more then one post office on a server, without any visible problems. Sure they might! Things that exacerbate GroupWise post offices are poorly configured POAs, bloated message stores, poorly configured file servers etc.
There are other things that dictate the numbers of a POAs that can run on a server, and they don't have anything to do with correct configuration of GroupWise. It's just how people use GroupWise. Some organizations literally use GroupWise for 50% of their computing. 50% of the time people sit at a computer they are in GroupWise, their world is GroupWise, without GroupWise they do nothing... In these kind of computing environments one POA and Post Office to a server is generally going to be the rule of reality. The GroupWise product suite is just getting all the sweeter too, with document management and an increasing amount of third-party integration. This trend will more firmly dictate the one post office per server recommendation.
Message File Processing
Keep this feature enabled as ALL for your POA. It is possible to have multiple POAs per Post Office doing different tasks, but this is much less common than it was.
Message Handler Threads
Depending on the size and nature of the Post Office, the Message Handler Threads should be set to approximately half of the value of the Client/Server threads. When you look at the HTTP console for the POA, you can see how many items each Message Handler Thread has used. If all of the threads have handled roughly the same number of items (+/- 10%) then increase the thread count by 2. When you have one or 2 threads that show substantially less usage than the norm, you have adjusted to the correct limit.
Enable Client/Server (TCP/IP)
You will always want to enable TCP/IP on the POA.
- There used to be an argument that having Client/Server and Direct enabled the databases to be managed for backup and troubleshooting. When GroupWise introduced the â€œRestore Areaâ€ concept, the use of Client Server and Direct became redundant
Client/Server Handler Threads (TCP Threads)
The Client/Server Handler Threads are often referred to as the "TCP" threads. These are the threads that maintain the client/server connection and the client/server data processing. The performance of these threads determines the quality of service that end-users get. The Client/Server Handler Threads should be set to a value of roughly one thread for every 25 active connections. For example, if a post office has 500 users, but only an average expected concurrent connections of 300 users, we would calculate that the POA needs (300/25 = 12 ) 12 TCP Handler Threads.
Like with the Message Handler Threads, when you look at the HTTP console for the POA, you can see how many items each Client Server thread has used. If there are a number threads that have processed very few messages then you have too many C/S threads configured. If however you see that while you have 12 threads configured, the highest value thread is listed as 15, then you know that the POA has dynamically assigned additional threads to handle a peak in the workload.
Note: If the C/S hit 50 and remain there â€“ with clients timing out and overall slow performance, this is indicative of a slow or low performing Disk IO channel.
Both the TCP Handler and the Message Handler threads should not be greatly increased beyond the 20 to 30 users per thread. Perhaps you might think "well if 12 is good then 30 is better". This isn't true. Each thread is registered with the operating system. The operating system needs to poll all thirty threads to see if they have work to do. The majority of the threads will most likely never have work to do, and so the additional polling creates the in-efficiency
Max Physical Connections
The Physical Connections are when data is being passed between a POA and the client. The default value in GroupWise 8 is set to 1024. If your post office is large (over 500 concurrent connections) and your users really utilize GroupWise, then consider bumping this number up. For example, you could bump this value up to 2048.
Max App Connections
An average GroupWise user uses two to three app connections while logged into GroupWise. Every GroupWise Application chews up at least one app connection. The GroupWise Applications are GroupWise, the GroupWise Address Book, Notify, GroupWise Desktop, Proxying, Shared Folders, Shared Address Books, Multi-User Calendars etc. also chew up additional applications connections.
A post office with 500 concurrent users should generally get by with the default of 2048 App Connections. A post office with 1000 concurrent users will generally need more so a more appropriate number would be 4096 App Connections. The App Connections do not take a huge amount of memory to pre-allocate.
Enable this feature. This allows the POA to cache files that it has recently accessed. The POA caches files for 15 minutes after the last time the file was accessed. There is a RAM overhead but this is not large and the benefits well outweigh the usage.
CPU Utilization (NLM)
This value should be set at either 85 or 90%. This tells the POA not to spawn new threads if the utilization goes above 90%. Delay Time just below this setting is the number of milliseconds the POA should wait before checking if the CPU can handle another thread if the POA needs to spawn one. The default of 100 milliseconds is good. One hundred milliseconds is 1/10 of a second which is a long time on NetWare.
Max Thread Usage for Priming and Moves:
This works with the message handler threads for the provision of threads for User Moves, Remote users hit the road and caching. It is this last that causes problems with this setting due to the default GroupWise 8 setting of 30% If you have the default 6 Message Handler Threads and this set to 30% there is only one thread available for caching users. A better rule of thumb on a modern GroupWise system would be 50% with an all caching users Post Office set to 90%
Select this option to enable this POA to communicate with Internet Message Application Protocol (IMAP) clients.
Max IMAP Threads
Specify the maximum number of IMAP threads that this POA can create. By default, the POA starts 1 IMAP thread and automatically creates additional IMAP threads as needed until the specified maximum is reached. The default maximum is 40 threads and cannot be increased, but you can specify a lower maximum so that the POA allocates fewer threads to IMAP connections. Each IMAP thread can service multiple IMAP e-mail clients.
Select this option to enable this POA to communicate with Simple Object Access Protocol (SOAP) clients.
Max SOAP Threads
Specify the maximum number of SOAP threads that this POA can create. By default, the POA starts 4 SOAP threads and automatically creates additional SOAP threads as needed until the specified maximum is reached. The default maximum is 20 threads and cannot be increased, but you can specify a lower maximum so that the POA allocates fewer threads to SOAP connections. Each SOAP thread can service multiple SOAP clients.
Enable Calendar Publishing
Select this option to enable this POA to provide users' Calendar information to the Publishing Host so that the users' Calendars can be viewed on the Internet.
Max Calendar Publishing Threads
Specify the maximum number of calendar publishing threads that this POA can create. By default, the POA starts 2 calendar publishing threads and automatically creates additional threads as needed until the specified maximum is reached. The default maximum is 4 threads and cannot be increased, but you can specify a lower maximum so that the POA allocates fewer threads for calendar publishing.
Disable Administration Task Processing
Only select this option on a secondary POA. If you have only the one POA (Normal usage) then do not select this item! Select this option to disable the POA admin thread that updates the post office database (wphost.db)
If you aren't monitoring the POA via an SNMP console, turn this off. It makes the POA do work you don't need it to do. If you do have SNMP monitoring then you can enable this
SNMP Community "Get" String
Provide the "get" community string for the server where this POA runs. Community strings are case-sensitive. If access to POA information is unrestricted, the "get" community string is typically PUBLIC. This can be viewed as a security risk by security auditors. By providing the "get" community string, you enable this POA to receive SNMP requests. The community string information is stored in the domain database and can be discovered by network management and monitoring programs such as GroupWise Monitor.
Select this option to enable HTTP and the POA Web console, so that this POA can be monitored by GroupWise Monitor.
Always Specify a username and Password for the HTTP interface
Enable Quickfinder Indexing
This feature allows the POA to index all messages in a database. This feature should always be enabled.
Start QuickFinder Indexing
By default this is set to start at 20:00 (8PM) however this might not be optimal for your environment. If you set this to start early in the morning then all messages that were received while folk were asleep will be indexed when they arrive at their desks..
The QuickFinder Interval is usually be set to every 24 hours. By doing the QuickFinder indexing every 24 hours, we can tune the POA to do the QuickFinder indexing early each morning, which is when we generally want it done.
NOTE: By setting the QuickFinder Interval to 0 (zero) then you are actually telling the POA to run QuickFinder constantly.
Quarantine files that fail during conversion
Check this box. This will help you isolate what is not indexable and can be submitted to Novell to resolve such problems. Non Indexed items (failed items) can be found in /postoffice/oftemp/gwdca/problem directory
Enable Automatic Database Recovery
This feature allows the POA to fix a database when it determines that the database has structural damage. This feature should always be enabled.
Maintenance Handler Threads
By default this is set to 4. This setting only comes into play when checking Message or User Databases. Unless you have an extremely fast disk subsystem there is little point in changing this value. Those lucky enough to have (or disillusioned enough to think they have) a fast disk system can increase this to a maximum of 8 and check to see if there is any benefit in a shorter Gwcheck times.
Perform User Upkeep Definitely enable this feature. This feature advances user's Tasks to the next day in the calendar, and it deletes message items and trash items if the user has specified that they want this to happen. Probably the most important function of Perform User Upkeep is that it synchronizes the user's address book frequent contacts list with the system address book. This way if a user moves, then the frequent contacts will be updated with the moved user's new location. By doing the user upkeep in the middle of the night, the processing of these items happens at a non-peak time. This helps the morning GroupWise login process to go faster for end-users.
Start User Upkeep (hours after midnight)
Make sure to set this value for the early morning hours, not the late night hours. If you do it in the late night hours you aren't getting some of the effect that you want with user upkeep.
Generate Address Books For Remote
If you have remote users, by generating the address book in the early morning hours you create two benefits. Generating the remote address book in the morning assures that when a user requests the address book for GroupWise remote, the address book is already made and ready to ship to the user's remote mailbox. Another benefit is that the processing overhead that's generated, when creating the WPCSOUT\OFS\WPROF50.DB file, is offloaded to the night time.
Start Address Book Generation (hours after midnight):
This has to do with the generation of the WPROF50.DB file. It is best to do this address book generation in the early morning hours.
Set this value to every 5 minutes. It's a very quick check. This DiskCheck Interval value corresponds with the disk check scheduled event mentioned later in this document.
Set this value to every 2 hours.
Log File Path
On the Linux platform all of the log file have been nicely correlated in the one location /var/log/novell/groupwise/postoffice.poa and thus this path is of little consequence. In NetWare and Windows the correlation of the different log files is umm..â€œloseâ€... By creating a Log location in the GroupWise file structure it is possible to then set all of the GroupWise logging to the one location Example gwdata:\grpwise\log\poa By ensuring that all of the agents and gateways always log to the same location on every server, it become easy for any administrator to review the logs when necessary.
Unless you have a reason to diagnose ot troubleshoot and issue, set this to normal.
Max Log File Age
By default this is now set to 7 days. Do NOT set this to 0 or the logs will be kept forever!
Max Log Disk Space
The new Default in GroupWise 8 is 100MB or 102400KB Seems right.
These changed substantially with GroupWise 8. They are listed below and the non-legacy enents should be considered mandatory as a minimum for all systems.
Default Daily Maintenance Event
This event performs an Analyse/Fix Database action with the Structure and Fix Problems options selected, every day at 2:00 a.m.
Default Disk Check Event
This event performs an Expire/Reduce Messages action with the Reduce Only option selected, when only 500 MB of free disk space remains in the post office and stops all message processing when only 200MB of space remains.
These settings are probably too low - after all what would you prefer? 2 hours of a hot telephone or 2 days rebuilding the Post Office. A more real world setting is 2GB for the reduce and 1GB to stop all processing.
Default Weekly Maintenance Event
This event performs an Analyse/Fix Database action on user, message, and document databases, with the Structure, Contents, Collect Statistics, and Fix Problems options selected, every Saturday at 3:00 a.m. It also performs an Audit Report to show GroupWise accounts that have had no activity for the past 60 days.
Default POA Disk Check Event (on legacy systems)
This event performs an Expire/Reduce Messages action with the Reduce Only option selected, when only 100 MB of free disk space remains in the post office. This is comparable to the Default Disk Check event.
Default POA Mailbox/Library Maintenance Event (on legacy systems)
This event performs an Analyse/Fix Databases action on user, message, and document databases, with the Structure, Contents, and Fix Problems options selected, every day at 12:00 a.m. This is comparable to the Default Daily Maintenance event.
Default Weekly Maintenance Event (on legacy systems)
If you did not already have an event that was performing the Audit Report action, this event performs an Audit Report to show GroupWise accounts that have had no activity for the past 60 days.
See the section on SSL and Agents