We as Domino Administrators may not be involved in the configuration and management of the operating system software and hardware upon which we run Domino. And as you know, the more people involved with managing a server, the more chance something is going to go awry.
To avoid a disaster waiting to happen, take a look at these settings in your server Notes.ini:
What are these settings and why are these “must haves”? As you know Domino by default relies on the operating system (and associated hardware time). Imagine that the following happens in your environment:
Your eager OS system administrator changes the date and time on a server to 7/3/2010. And because he is in a timezone that uses a dd/mm/yyyy format he merrily goes along his way. But let’s take this one step further – the servers he’s managing are in a timezone that uses mm/dd/yyyy. Domino periodically checks the OS time every 5 minutes to synch the Domino system time with the OS time. If your eager OS admin had changed the date/time, the next time it synchs — Domino would change its clock to July 3rd rather than March 7th. Are you with me so far? Hopefully you’re beginning to sense the global impact of this change.
How do you avoid this? Step one – include Reset_Time_Interval in your Notes.ini or your Server configuration document. Reset_Time_Interval setting is the maximum time difference allowed between “Domino time” and the “OS time”. The setting is in seconds with the default being 5 minutes. So let’s say you add Reset_Time_Interval=600 (or 10 minutes). And Domino time is 8:15 AM and the OS time is 8:42 AM, Domino would not reset itself to 8:42 AM. And issuing a Set System Time would not reset the Domino time to match the OS time either.
Step two – include Restart_Time_Action=1 in your Notes ini. This setting is a little more complicated. If this setting is set to 1, the server will not restart if the Domino time does not match the OS time and the server has been down longer than the Restart_Time_Interval, the server will not start. This is like an emergency brake. The server is not going to start with an OS time of 3 days in advance if this setting is in place if the time doesn’t match your Domino time. This is especially useful if you know your system administrator is doing hardware maintenance. Additionally, when Domino is shut down it adds Last_Domino_Time setting to the Notes.ini. You may not have noticed this Notes.ini parameter, but it includes the previous Domino time and uses this time value when calculating the time Domino should use – especially in conjunction with the values of Reset_Time_Interval and Restart_Time_Action.
If none of these settings exist in your Notes.ini, then the OS time will be used upon server restart.
I would recommend working with these options on your test server (which does not replicate with your production environment), until you feel comfortable in your understanding of how they work and how best to set them for your environment. Consider the impact of not including them. Do you want to have modify what could possibly be thousands of documents to adjust for time correction? Remember what this was like for the US Daylight Saving Time issue? Not something anyone of us wants to tackle any time soon!!!
Here are a few tidbits of “wisdom” gleaned from our current Notes 8.5 upgrade:
- databases that have been around migrated from previous versions (prior to 7.0.3), with private folders, or complex folder structures – may take longer on a convert – especially if you are converting the designs up from dwa7.ntf to mail85.ntf versus upgrading from mail8.ntf. Check your resource utilization while the convert process is running to see if the process is affecting overall server availability.
- remember to change the mail85.ntf template to enable the compression features that are available beginning with 8.0.2.
- for Notes 8.5 installs on Vista workstations — make sure that UAC has been turned off. There are PMRs open for Vista/Notes 8.5 – especially with regards to the 8.5 client NSDing on first start after the client install. The client will start in safe mode without networking, but with networking it will not load. Support has relayed that there may be some Windows files at play that are either missing or not at the version expected.
- for those workstations that continue to prompt for a software upgrade or a design refresh after the refresh has been confirmed on the server (smart upgrade tracking database) or in design properties of the database – a nonsupported workaround to make the messages go away involves editing the notes.ini and removing any of the SmartUpgrade related parms (begin with SU). As always make a backup of the notes.ini before attempting this.
- users do miss the red unread marks, and will find the workaround for editing the jar file – so be prepared for questions or issues if that fails.
- if a user is prompted with the message – no matching smart upgrade kit found – most likely the user is attempt to install a client kit versus an all client kit. a nonsupported work around for this is to change the installtype in the notes.ini from installtype=2 (for all clients) to installtype=6; and then have the user attempt to run the smart upgrade again.
- Sametime preferences have changed significantly in the Notes 8.5 client, so review those settings before deploying.
So far training issues have been minimal, but we have not yet upgraded those power calendar users yet, and I expect questions may arise with some of those folks. All and all the project is moving along!
Join Marie Scott, Franziska Tanner, and Gabriella Davis on May 27, 2010 at 11:00 AM EDT as they present their Lotusphere session:
“Top Chefs” Share Recipes for Avoiding Everyday Server Disasters
LotusphereComesToYou Oneline 2010 is brought to you by LotusUserGroup.Org.
Be sure to register online to attend!
Instructions in the hotfix indicate that you should install the following dwabl.jar in the following directories
Solaris/Linux/AIX : \jvm\lib\ext
Well the first problem we discovered was that the fixpack did not include that jar. It included dlt.jar
Secondly, there is no dlt.jar in the \jvm\lib\ext directory.
Upon contacting Lotus Support they told us that a new DWA Hotfix set had just become available but was not on Fix Central yet! (Imagine my surprise.) When we explained that the jar file was not found in the directory, they recommended reinstalling 8.5.1. Given that these are productions servers, that option was certainly out of the question. We then did some digging around and found that the dlt.jar along with the dwabl.jar are located in the \ndext directory.
We have subsequently sent this information on to Lotus Support. So if you are in the process of installing patches, it’s good to read the readme files thoroughly and know that you might need to do some file searches to locate a file rather than rely on the directory information included with the fix.
Postscript: There appears that there may be an issue with the location of the jar files as placed by the 8.5.1 install. We’re currently working with Lotus Support to identify this.