1. Upgrade the Notes clients that administrators will use to edit and operate on the Domino Directory.
2. Upgrade the Domino Directory first (this is done by upgrading the Domino server that is the Administration Server of the Domino Directory to Domino 8.0 first).
3. Replicate the Domino Directory to the other servers.
4. Upgrade the Hub servers.
5. Upgrade the Mail servers.
6. Upgrade the SMTP servers.
7. Upgrade the Web servers.
8. Upgrade the Application servers.
9. Any third-party/companion product server (check for Notes/Domino Release 8.0 readiness).
10. Upgrade the general population of clients to Notes 8.0.
11. Replace the design of any databases/mail files with any new Notes/Domino Release 8.0 design changes last. For mail files, the Convert task should be used on the server to change the design of the mail file.
Friday, October 19, 2007
What is Lotus' recommended Upgrade Path for lotus 8?
Monday, October 15, 2007
Incomplete NSD after a Domino server crash
| Question |
| Your Domino® server crashes and the NSD file is incomplete. The NSD will stop after running some time without any error message. When run manually. NSD does run to completion successfully. |
| Cause |
| In the Server document -> Basics tab -> Cleanup Script / NSD Maximum Execution Time field is set to 600.
Even though the faulty recovery is not enabled, the Cleanup Script /NSD Maximum Execution Time does apply to automatic NSD. In this case, nsd ran for 600 seconds and is being terminated, resulting in NSD terminating prematurely. In Domino server 6.5.5, the auto nsd did finish in about 1 minute, even with the Cleanup Script/NSD Maximum Execution Time set to 30. (Faulty recovery not enabled) This feature is to prevent nsd from running for too long to hinder Domino server restart. However, for some busy servers, it takes more than the default 5 minutes to finish. NSD needs to complete in order to troubleshoot the issue. |
| Answer |
| Increase Cleanup Script /NSD Maximum Execution Time from 600 to 1800. This field range is from 30 to 1800. This will increase the time the Domino server is down from 600 seconds to 1800 seconds. In most cases, a complete nsd is required to determine the root cause of the issue. |
Wednesday, October 10, 2007
Notes/Domino Best Practices: Domino Domain Monitoring (DDM)
Domino Domain Monitoring (DDM) is the new interface and tool to view server health information across your entire Domino domain. The feature provides Domino administrators with correlated Event report documents that help find existing configuration or performance problems and ward off potential problems in the future. Collection hierarchies are available to roll up DDM.nsf data into one or more collection servers and Filter documents can be used to ensure only the event types that are important in your domain are being reported. Corrective actions allow for a high degree of customization and automation and the DDM interface provides the framework for problem management workflow.
| Best practices |
- To ensure DDM.nsf data on a collection server is available during a server outage or down time, it is highly recommended to provide redundancy of your collection server DDM.nsf databases. To accomplish this, add that collection server to another server collection hierarchy.
- The majority of the new DDM probes will only monitor Domino 7 servers, but there are three DDM probes that can monitor pre-Domino 7 servers: the Security, Web and Replication probes.
- DDM will report on more events and potential problems than most Domino administrators are normally used to seeing provided with other monitoring tools. It is highly recommended to control the volume of data into DDM with Event filters, by lowering the severity of certain Event Message documents or by permanently closing Event Report documents in DDM.
- Collect baselines for all servers and tailor probes according to the baseline.
- Disable probes during maintenance windows to avoid phantom events.
- Use fully qualified host names to monitor servers outside of the domain.
- During the upgrade from Domino 6 to Domino 7, prohibit design changes from R6 to R7 Events4.nsf.
- DDM will increase the load to some extent due to the behind-the-scenes replication. While this should be negligible, do not choose a heavily loaded server for a collection server.
Copy Lotus Notes databases from the Domino Server console command line
The Domino Server console commands are turned off by default, so you need to first enable them. Set this server notes.ini variable, like so:
No need to restart the Domino server, it becomes active immediately. This enables this new command: CL COPY sourcedb targetdb.
Below, I have listed some examples for the CL COPY command:
This creates a regular non-replica copy of db1.nsf on serverA as db2.nsf on ServerB
This creates a replica copy of db1.nsf on serverA as db2.nsf on ServerB
This creates a template copy (only design, no data) of db1.nsf on serverA as db2.nsf on ServerB
This creates a regular non-replica copy of db1.nsf as db2.nsf on the same local server
Notes/Domino Best Practices: Administration Process
The Administration Process is a program that automates many routine administrative tasks such as renaming groups and people and mail file and replica management. The Domino Administration Guide provides a more thorough description of the Administration Process.
It is vital for administrators to understand the Administration Process in order to maintain a healthy Domino environment. To that end, this document contains a list of Technotes, developerWorks articles, Redbooks and Redpapers that encompass existing Best Practices materials for Notes/Domino 6 and 7.
General rules There are some general rules that apply to a well maintained Administration Process:
- Only replicate from the administration server. Never replicate from another replica copy on a spoke server.
- Always use pull-push when replicating the administration database (admin.nsf). Pull replication is important as AdminP is expecting responses back, such as acknowledgements, status or errors.
- IBM recommends the cut-off interval be 7 to 14 days and should never be set to more than 21 days to help reduce the size of the administration database.
- All replica copies of admin4.nsf should have identical cut-off intervals that are equal to or less than the source on the administration server. Cutoff intervals that are out of sync sometimes lead to old data reappearing.
- If a server has been down for a long period of time, or if replication of the admin4.nsf has not occurred for several days, do not attempt to replicate, as deletion stubs may have expired. Instead, delete or rename the database and create a new replica copy from the source on the administration server. This action will prevent deleted or changed documents from being reinstated. This is good practice for all Domino applications.