During the webinar me and Heather ran out of time so we did not have time to talk about all the points that are highlighted in the slides.
Here are some details on those point that we did not cover
Program Documents provide a method for scheduling server tasks to run at a scheduled time/day. A common usage is for proactive database maintenance. Prior to release 9, program documents would typically be created to run the fixup and compact tasks against databases. Release 9 includes the Database Management Task, DBMT, which does the following.
- runs copy-style compact operations
- purges deletion stubs
- expires soft deleted entries
- updates views
- reorganizes folders
- merges full-text indexes
- updates unread lists
- ensures that critical views are created for failover
- System databases are not compacted
- -compactThreads 8 -updallThreads 8 -range 2:00AM 7:00AM -compactNdays 5 -force 1
- Remove ServerTasksAt2=Updall
To run DBMT via a program document, create a new one to run DBMT at server startup. For the command line enter information that includes the number of compact threads, updall threads, time range for running updall and compact, number of days to wait unil running compact and day of the week to run fixup against databases that cannot be compacted. For example, the following loads 8 compact and updall threads, runs the tasks between the hours of 2 – 7 AM , waits 5 days to run compact and runs fixup on Sundays.
-compactThreads 8 -updallThreads 8 -range 2:00AM 7:00AM -compactNdays 5 -force 1
Additionally, you will want to remove ServerTasksAt2=Updall from the server’s notes.ini. Also, because the compact is a copy style compact set the ini parameter MailFileDisableCompactAbort=1. This will cause the router to be compact aware, holding emails until compact finishes running against a mail database.
It is important to note that the DBMT tool does not run compact against the following databases.
Hence, it is recommended that the administrator creates a program document to run compact -B once a week to compact these databases.
Domino Certificate Authority
In many Domino environments the certifier ID that is used to register, rename and recertify users is stored in the Notes\Data folder of the administrator’s computer. However, this approach has risks for the ID could potentially be stolen if someone gains access to the device or lost if the device is impaired. Further, if the administrator decides to delegate these tasks to another entity, such as the help desk, then the certifier and its password have to be shared.
Hence, it is recommended that a Domino Certificate Authority be created. From the administrator client’s configuration tab select Tools – Certificate – Migrate Certifier and follow the on screen prompts. As a result, an ICL database will be created. Now, the people you specify can perform user registrations, renames and recertifications without having physical access to the certifier ID nor do they need to know the password.
In addition, the CA task should be added to the ServerTasks lin of the server’s notes.ini.
Introduced with 8.5, the ID Vault provides a method for securely storing Notes IDs. Further, as ID passwords are changed and as users are renamed and recertified, the ID in the Vault is updated. The ID Vault is a core component of the Domino security model, is required for Verse on Premises and in Domino 12 will be automatically configured if one does not already exist. Hence, if you do not have an ID Vault today then create one.
To create an ID Vault go to the Configuration tab of the administration client, select Tools – ID Vaults – Create and follow the on screen prompts. An ID Vault will be created in the IBM_ID_Vault folder and a Vault ID will be generated. It is important that you backup the Vault ID and its password. Additionally, the ID Vault should be replicated to other servers using Tools – ID Vaults – Manage.
Now, users you assign to the vault and new users created will have their Notes ID added to the Vault. From here the ID can be accessed for web authentication, downloaded as part of the Notes client set up and recovered when a password or ID is lost.
Policies and Settings Documents
Policies and settings documents provide several configuration options for managing the Notes and Domino infrastructure. Hence, it is important that the administrator create policies and subsequent settings document. To better understand policy types, hierarchy and settings documents reference the HCL Domino documentation.
Domino Server Monitoring
Like any system, Domino servers require monitoring in order to ensure they are optimally performing and hopefully detect problems before they cause service interruptions. Natively included, Domino Domain Monitoring allows an administrator to view and manage server events. In the events4.nsf database DDM probes and event handlers are created and managed. These drive what is monitored on the Domino server. When thresholds are met, a document is created in the DDM.nsf database. The administrator should regularly review the DDM database to be aware of new events and take corrective action.
Domino Server Maintenance
While gone are the days when scheduled system reboots were necessary to avoid memory problems, it is still necessary to have a server maintenance plan. As discussed earlier, program documents are used to perform database maintenance. Further, for the system databases log.nsf, domlog.nsf and mail.box a recommended practice when Domino is not running is to rename these files and allow the server to create new ones at start up. Note: change the extension to a different value so that Domino does not attempt to manage the file, i.e. log.old.
As with any server, it is important to stay current with software offerings and operating system patches in order to avoid security problems that hackers may exploit and repair known issues. Hence, install Domino fix packs as they become available, plan to upgrade following new releases and apply OS patches on a regular basis. Finally, keep supporting software, such as anti virus software, up to date.