MySphere Posts

When AdminP processes a password change in Lotus Notes/Lotus Domino, the old password is cached by the server for two days. What if this cache period is too long or too short ? Can the cache period ever be modified?

Yes, the cache period can be modified by setting the following parameter in the server’s notes.ini file:
HTTP_Pwd_Change_Cache_Hours.

Use the following format:

HTTP_Pwd_Change_Cache_Hours=x
(where x is the number of hours of caching time for the old password)

During the cache period, both old and new passwords are valid, assuming the change has replicated to the server being accessed.

In addition, the Security Settings Document –> Password Management –> “Allow users to change Internet password over HTTP” field must be set to Yes.

The information above is from TN1084395

There is no native failover support for scheduled agents in Domino. I know this issue i think since i start to work as a Domino Administrator 12 years ago.

From TN 109833034

This issue has been reported to Lotus Quality Engineering in the form of an enhancement request; however, there are currently no plans to address it.

Basically, scheduled agents run only on the server on which they are scheduled to run.  If Server A is clustered with Server B and Server A goes down, any scheduled agents on Server A are not going to run on Server B, even though they are clustered.

One way around this is to code the agents so that they poll the other server for availability.  If the server is available, they do not run; if it is not available, they do run.  It is important to note that this workaround is not supported by Lotus.

An optional workaround is:

1.  Create a single agent (AgentCore) with the core processing code you need and set the trigger to “Agent list selection”.
2.  Create a second agent (AgentTriggerPrimary) with code that calls the AgentCore agent.  Schedule this agent to run on the Primary Cluster Server.
3.  Create a third agent (AgentTriggerBackup) with code that checks to see if the Primary Cluster Server is available.  If it is not, it calls the AgentCore agent, otherwise it exits.  Schedule this agent to run on the Failover Cluster Server.

This kind of problem is old but you can use new tools to solve the problem.

Yesterday, in one of our applications a lot of old documents  reappear like ghosts.  According the TN 1098733 the problem is caused by:

1. The purge interval  is more frequent than the replication schedule.
If a document is deleted and the deletion stub is purged before replication, the other replica copy does not have the information that the document has been deleted and replicates the document just like a new document.

2. A document was modified on one database replica after it was deleted on another replica copy.
If a document gets modified on one replica copy of the database after it was deleted from another replica, the modified date on the existing document is newer and would overwrite the deletion stub (there is no replication conflict with deletion stubs, the document just reappears).

3. A document was modified more often than the deleted document
If a document gets modified more often on a replica copy than of the database with the deleted document, it will come back after replication even if it was deleted after the last modification. This is because the sequence number (number of modifications) takes precedence over the modified date – and since there can’t be a conflict with a deletion stub it reappears after next replication.

But in Domino Administrator you don’t have any   tool to help. Its where the ScanEZ, a powerful tool, can help to solve this kind of problem.

Go to this link and see a good article about the tool and how ScanEZ was used in this scenario.  

For more information about ScanEZ go to this link

Este tipo de problema é antigo mas existem ferramentas novas para ajudar a resolver o problema.

Ontem, uma de nossas aplicações, muitos documentos aqntigos reapareceram como “fantasmas”

Usei o ScanEz para achar quais documentos estavam com problemas e solulcioná-lo rápidamente, excluindo tais documentos.

Domino installer does not start and goes to command prompt immediately.

Domino requires the following packages to be installed. They can be located on the RHEL6 distribution disks or installed via RPM.

glibc-2.12-1.7.el6.i686
libgcc-4.4.4-13.el6.i686
libstdc++-4.4.4-13.el6.i686

The packages listed above are sufficient to install Domino in silent and console modes.
To run GUI Domino installer, you will need additional xWindows packages:

libXtst-1.0.99.2-3.el6.i686
libXmu-1.0.5-1.el6.i686
libXp-1.0.0-15.1.el6.i686

To run GUI setup you will need two more packages:
libXft-2.1.13-4.1.el6.i686.rpm
libXi-1.3-3.el6.i686.rpm

Installing the packages above plus any dependencies will allow the installer to run.

 The information above is from the TN 1455332

From TN 1228354. This is the last option

1. Ensure that the corrupt replica is not in use by any user or server.
   On the Domino server hosting the corrupted database, enter the following command: “dbcache flush” (command may require entering two or three time to release the database).
2. Using operating system commands, delete the corrupt replica file.
3. Using the Lotus Notes client, open the “good” replica located on the other clustered server.
4. Create a new replica on the server where the “bad” replica was deleted.
   Select File -> Replication -> New Replica.
5. Complete the replication.
6. Stop the Cluster Directory task on the server where the new replica was created by running the console command “tell CLDBDIR quit”
7. Restart Cluster Directory task by running the command “load CLDBDIR”
8. Verify database replica is on clustered server: Open Cluster Directory database and select the view, Databases by Replica ID
9. Verify that each replica copy of the same NSF file has the same Replica ID value.

Today  i an agent stop to working . The cause was the wrong signature but in this case was not access rights

The TN 1099178 explain the problem:

In order for “After new mail has arrived” triggered agents to run on Notes/Domino Servers, the following must be true:

1.        The signer of the agent (the last person to save or enable the agent) must have their mail file located on the same server as where the agent will run.  The server determines this by taking the name of the last person to save the agent, performing a person lookup into the Domino Directory and retrieving the Mail Server from that user’s Person document.  If the Mail Server in the Person document is different than the current server, the agent will not run.  If the person is not found in the directory, the agent will not run.  This person lookup is performed every time the agent loads to run.  Remember, if the User ID is hierarchical, the user name in the Person document must also be hierarchical.  This is stored in the field “FullName” in the Person document.

2.        Historical Detail: In Notes R4, if the agent is a Formula agent (as opposed to a Simple Action or Script agent), then there is an additional requirement that the agent be saved as a R4 type agent, rather than an R3/R4 Compatible agent (which is the default).  An agent will save as a R4 agent when a feature that is exclusive to R4 is used within the agent.

Note:   This limitation no longer applies to formula agents created or saved in R5.  R5 does not save agents in the R3/R4 compatible format.  Existing agents that are still in the R3/R4 compatible agent format will still not run under R5 until they are resaved using an R5 client.

Workarounds for the Mail Server Lookup caveat in Requirement #1 above

In Notes 4.5x and later:

You can add a parameter to the NOTES.INI file that disables this mail lookup check.  The NOTES.INI parameter must be set on the server where the agent is to be run.  The parameter is:  

AMgr_DisableMailLookup=1

Historical Detail: In 4.5x releases prior to 4.5.3 and in release 4.6, if the above INI parameter is set to 0, then it still acts as if it is set to 1.  So, in those Notes releases if you want to re-enable the mail lookup, the INI parameter must be removed entirely.

Note:  This parameter does not prevent the following warning when saving the agent; however, the agent still runs:

“Unable to determine the execution access privileges for this agent on ; agent may not run.”

Thetechnote  1447614 outlines the steps to install Multi-user 8.5.1 or later releases, on Citrix XenApp with a customized data directory for new and existing Notes Installs.  These instructions do not include steps to store the data directory on a remote file share, because this configuration is not supported.

I search for information about upgrading ODS to a new version to support a Domino migration  and justify the upgrade of the ODS.

The summary is bellow.

On-Disk Structure (ODS)

Every major release of Notes/Domino (e.g., versions 2, 3, 4, 5, 6/7 ,8 and 8.5 ) has included significant architectural changes to the database structure, also known as the On-Disk Structure (ODS). These architectural changes enables the Notes and Domino development team to improve performance and scalability in each release. Upgrading the databases provides a lot of benefits, with very low risk, so this has always been an important early step in any Notes and Domino upgrade plan.

The ODS version for each major release of Notes and Domino is as follows:

• v2 — ODS 16/16.3
• v3 — ODS 17/17.3
• v4 — ODS 20
• v5 — ODS 41
• v6/v7 — ODS 43
• v8 — ODS 48
• v8.5 — ODS 51

The impersonation feature lets you access another user’s system as though you are that user. This is a new feature of WebSphere Portal 7.
The impersonation feature lets you view new pages, portlets, and other portal components. Users such as support specialists can use the impersonation feature to find issues and errors.

But pay attention on this two things:

Client side aggregation does not support user impersonation. For this reason, ensure you do not activate client side aggregation on any portal pages where the impersonation portlet is deployed.

User impersonation and people awareness: When a user who is enabled for impersonation impersonates other users, the people awareness feature is disabled for the entire session for which that user is authenticated.