Validated for GroupWise versions 5 though 2018+.
Ensure that the PO and Domain objects have an appropriate GroupWise ID set as admin/postmaster to receive any system messages that the following routines will generate. After the first runs of these, do check the results and then make sure you at least check the end of the contents check there after to make sure there are few if any errors that repeat from check to check. The first time these are run there will be lots of "errors" as things get cleaned up, but withing a couple of weeks should be running fairly clear when you check the logs.
For GW 2014 and up, log into your GW Admin page such as https://gwserver:9710/gwadmin-console/login.jsp
If you are on an older GroupWise system, make sure that your NWAdmin(GW5.x) or ConsoleOne(GW6-12) is properly Snapped in with the relevant GroupWise hooks so that you can go to the Tools menu and see 'GroupWise View' as an available option. Make sure that you have run the manual maint routines before implementing these (unless this is a new system).
The following assumes the 'traditional' 9-5, M-F office type organization. Adjust times as appropriate for your situation so that the maintenance occurs in the lowest use times.
In GWAdmin, select Post Office Agents on the left, then select your POA you will start with.
In NWAdmin/ConsoleOne, go to the details/Properties of the Post Office Agent (POA) object
- select Scheduled Events tab or GroupWise/Scheduled Events tab.
-
Enable and edit the Default POA Disk Check Event.
- Unless you are running on a small system, put the space limit to 999
- Enable and edit the Default POA Disk Check Actions.
- Expire/Reduce Messages, select only the trash limit to 7 days, include all items.
Note: If you want, you can make several Expire and Reduce Events that get
progressively more aggressive in their clean-up as the space gets tighter.
Just keep in mind that when the event is running that it does use up a bit more
drive space so don't space those events too close to each other(i.e. start with
999MB, then at 900, 800, .. etc.). Also useful when you have a proper archiving tool and can remove old data from the live GW system.
- Logging Tab I, set to expr999.log, Results to the most appropriate admin
-
Create "Empty Trash 42 days old" Event.
- Set to a trigger of Weekday, late Sunday PM or early Monday AM.
- Create... event Empty the trash
- Expire/Reduce Messages, select only the trash limit to 42 days, include all items.
- Logging Tab I, set to expir42.log, Results to the most appropriate admin.
- Alternatively, select Reduce Only if you have the trash set to empty else wise such as locked client settings.
-
Enable and edit the Default POA Mailbox/Library Maintenance Event
- Set to Weekday, Saturday early AM, after the backup is complete and/or every weekday.
- Enable and Edit Default POA Mailbox/Library Maintenance Actions.
- Analyze/Fix Databases, select Structure, Index Check, and Fix Problems in both User & Message databases.
- Logging Tab I, set to Stuctr.log, Results to the most appropriate admin
-
Create "Weekly contents maint", type Mailbox/Library Maintenance
- Trigger of Weekday, Saturday AM, after your backup and the previous job are finished or Sunday 12:01AM
- Create... event Contents check
- Analyze/Fix Databases, Contents, & Fix problems, in both User & Message databases
- Logging Tab I, set to Contents.log, Results to the most appropriate admin
-
Create "Weekly contents maint#2", type Mailbox/Library Maintenance
- Trigger of Weekday, Sunday later afternoon
- Create... event Contents#2 check
- Analyze/Fix Databases, Contents, Collect Statistics & Fix problems, in both User & Message databases, Update user disk space totals.
- - - (A Caution on 'Update user disk space totals': If you have mailbox quotas set, you will be dealing with updating those quotas very quickly!)
- Logging Tab I, set to Contents.log, Results to the most appropriate admin.
- Notes: This run will have much fewer problems showing, making it easier to check if they require manual intervention. Make sure this job doesn't overlap with the previous contents, otherwise it will not run and you will get "DF2A Ignoring this request because it is a duplicate of one already in progress".
-
Create "Weekly stats for big attachments", type Mailbox/Library Maintenance
- Trigger of Weekday, Monday early AM, after your backup and the previous job are finished, and before the users come in.
- Create... event "List Big Items"
- "Mailbox Statistics", Expires statistics of only "Items larger than" 20000KB, to include Received, Sent, and Calendar items....
- Logging Tab I, set to Stats.log, Results to the most appropriate admin
-
Create "Weekly Audit and size update", type Mailbox/Library Maintenance
- Trigger of Weekday, Monday early AM, after your backup and the previous job are finished, and before the users come in.
- Create... event "Audit size updates"
- select "Audit Report"
- Logging Tab I, set to Audit.log, Results to the most appropriate admin
Note that this job updates User size totals and last logins as reported elsewhere, so even if you don't check for unused accounts, it is still very useful to run. I've seen even the developers forget about some of these updates when pointing people to those 'elsewhere' locations, so just run it.
- - - (A Caution on 'Size Update': If you have mailbox quotas set, you will be dealing with updating those quotas very quickly!)
You can now go to any/all other Post Office Agents and select all these created jobs or create new ones if needed for different times.
It is strongly suggested that these repair jobs be collected into a Shared folder that all applicable GW Team members be able to monitor the status of the system, check the logs periodically, and purge GWChecks older than about 2 months. Typically, the 'Admin' ID or its permanent equivalent GW account can be used for this, set with a rule to automatically move the GWCheck messages to the shared folder. This is also a good method for collecting GW Monitor alerts. For clients I am working with long term, I will often have an internal GW account that gets to share those folder(s).
Notes:
Assuming one POA per server, these events only have to be created once for the whole postal system and as such need to be done by a User with rights to the Primary Domain. They then only have to be activated on a PO basis. If you have multiple POA's per server, you'll need the multiple events to spread the times out.
GroupWise and its maintenance does multithreading nicely, so don't be shy about giving it cores to use. Even on small systems having at least two cores so that if one thread gets stuck for a bit, users aren't likely to notice, especially if all in on-line mode.
Do make sure you check the errors at the end of the Contents Check every once in a while to make sure there are no problems brewing. This is a task that can be readily outsourced to an organization such as Konecny Consulting Inc, so feel free to engage us.
Relevant TIDs + for reference:
10023861 - Secondary domain administrator cannot change or create scheduled events. Just in case you happen to run into this on an old system.
10021870 - Changing a Scheduled Event on one POA affects all POA's in the system. A good heads up that still applies
Top Down Rebuild tool for GW 14 and 18.
