ShowTable of Contents
Introduction
Lotus Notes and Domino provide the benefit of working “locally,” using local replicas of Notes applications/databases. The main benefit---and the original idea behind the local-replica mode---is to allow users to work while offline or when connected via slow networks (dialup, reduced bandwidth, etc.). Users can do their work, reply to mail messages, access applications, etc., and then connect and replicate, simply and painlessly.
However, most Lotus Notes users today can connect via the Internet, Wireless Cards, etc., and most of these ISPs provide excellent speeds, which begs the question: Is it still a good idea to deploy local mail file replicas, and what are the benefits, considerations, and best practices for doing so?
Over the years, it's been common for companies to debate whether to deploy local replicas vs. server replicas for their employees, even if they are working on site when the servers and users are all on the same LAN.
Most organizations have based their decision on technical needs, security, user training, and the level of support they can provide (since they now have an additional configuration to support); however, the debate continues for some others.
So, the purpose of this article is to clarify why---or if---local replicas are a good option for your environment and how you can deploy this option.
NOTE: For more information on how local replicas work, refer to the Lotus Notes and Domino Administration Help database that ships with every Admin & Server licensed software (help\adminxx.nsf, where xx stands for the release number of Lotus Domino software) and to the developerWorks® Lotus article, “
Understanding and implementing local mail replicas for IBM Lotus Notes.”
Also, you may want to review the Lotus Notes 8.5 Product Documentation topic, “
Using Notes Offline.”
Server replica versus local replicas and what's best for your organization
Aside from the performance benefits, deploying local replicas should represent no changes to how your users interact with their email. However, as with making any change in a production environment, local replicas should be fully evaluated and understood, to make sure there no surprises down the road.
There are multiple advantages and considerations that must be evaluated before making a decision. To understand more about these factors, let's start with the main purpose of email, that is, to send and receive messages.
Looking at this scenario from the user's perspective, it should be as simple as “I click Send and the messages goes out. If I receive messages, they show up in my Inbox”. Properly configured scenarios work as follows:
Server replica
- When a user sends a message, it goes out immediately
- When a user receives a new message, it shows up in the Inbox immediately
Local replica
- When a user sends a message, it goes out immediately
- When a user receives a message, the message shows up in the Inbox approximately 60 seconds after it's received on the server
So, the only difference is that, for the local-replica setup, there's a 60-second delay when receiving new messages. As we demonstrate below, however, this delay is a small price to pay when compared with all the performance gains, the savings in resources' usage, and the high-availability benefits that the organization and users can realize by switching to local replicas.
After many years of working with multiple Lotus Notes and Domino environments, we have found that organizations should always base their evaluation on these key factors, which represent the vital points of any IT Infrastructure.
Table 1 shows how these factors, and many others are affected, and serves as a handy “cheat sheet“ to help organizations to decide which option to deploy.
Table 1. Effects of using local replicas on your IT environment
Parameter | Advantage | Consideration |
Infrastructure |
Server workload | Will be reduced | - |
Network utilization | Will be reduced | - |
High availability | Users will not notice if servers are down, especially in a clustered environment. | - |
Server consolidation | If less resources are needed, server consolidation could be considered. | - |
Security | - | Corporate Policies might prohibit having confidential data on users' machines. |
Initial replication / Plan and deploy | - | Extra considerations when creating the replica for the first time for remote users. |
Users |
Performance | All mail operations will be faster since they are performed locally. | - |
Inbox and folder load times | Inboxes and folders with large number of documents will load faster. | - |
Offline access | Full access to the mail file, even if there's no access to the server. | - |
Full text index and searches | Databases can be fully indexed. Searches will be performed locally and will be faster. | - |
Local Mail.box control | If Message Recall is not deployed and users are working offline, users can open the Mail.box and delete messages that haven't been sent to the server. | - |
Receipt time for new messages | - | By having the parameter ReplicateOnNewMail=1, users will see new messages up to 60 seconds after messages was received by the server. |
Support |
Troubleshooting | - | IT Support needs to be trained to handle and configure replication issues. |
Maintenance tasks | - | Database maintenance should be performed on users' machines. |
User machine resources | - | Users' machines might need more disk space. |
Let's now discuss these advantages and considerations in more detail.
Advantages of the local replica
The following are the advantages of using a local replica:
- Server workload. The server requires less resources since all user operations are performed on the client.
- Server consolidations. If all or a majority of users access their mail files via local replicas, server workload will be reduced so that more users can share the same server, meaning less administration and less costs.
- Inbox's load time. A major benefit applies to all users who like to have all messages in the Inbox. Opening the Inbox is the most “expensive” operation for the mail client so, if you move the operation to the client, load time will improve greatly since there's no need to use the server or network.
Although the user will notice a difference when opening the Inbox, keep in mind that the server must still process the large Inbox on the server replica.
- High availability and clustering. Having a local replica means you don’t care what server with which you are replicating; if one server goes down or is busy, the Notes client will replicate against the next-most-available server. You'll neither know about it nor need to be redirected to the replica on the other server.
- Offline access. Access to local replicas means 24x7 availability; if the server goes down, or you're on an airplane, or the network/Internet is down, you can still access your local replica.
Also, by deploying Directory Catalog to users' machines, you'll have a reduced version of the Company Directory, which can be used while offline. Moreover, for large companies, users won’t need to wait until the Address Book Dialog containing thousand of names loads.
- Performance/speed. Working via the local replica means that all transactions are performed locally (except for replication), requiring only minimum access to the server. This provides a huge benefit to environments that have heavy network usage, heavily loaded servers, or may be experiencing network issues.
- Network improvements. Having users work on local replicas improves not only their Notes mail experience but also may help other applications that relay on a healthy network or that require a lot of bandwidth.
- Local Mail.box control. With local replicas, users have full control of their local Mail.box. For example, if they send a message by mistake, they're able to recall it by navigating to their local Mail.box and deleting the message before it is replicated to the Domino server.
This can have the similar advantage of having the Message Recall functionality. Note, however, that Message Recall works only when both the sender and recipient are Domino mail users, and the message was sent using NRPC.
- Full text index. Some organizations don’t allow full text indexes (exact searches) due to performance or space issues. However, if you have a local replica, you can create your own full text index (and the Notes Administrator may thank you for not having to worry about those anymore).
Considerations for the local replica
The considerations and their solutions are as follows:
- Additional support/configuration. Additional Help Desk / Deskside Support may be required to handle local-replica issues such as replication delays, corruption issues, or bad configurations. Also, configuring the Notes client to work with a local replica requires some extra steps.
Solution: Policies not only let you control multiple clients’ settings, such as those for mail and security, but also allow you to control the use of local replicas. (See Section 4, “Controlling local replicas using policies,” below for more information.)
- Security. Security is always a concern when data is stored on PCs or laptops, especially if they leave the company facilities on a regular basis. When users have local replicas of their mail file or their company’s directory on their machines, all data being protected on the server (physically and digitally) is likewise stored on a user’s laptop that can be lost or stolen.
Solution: Lotus Notes provides three levels of encryption for local replicas. This encryption is based on the password-protected Notes ID file. Encryption for local replicas can be forced via policies, which can also be used to increase the complexity of passwords and even to force users to change password on a regular basis.
- Less likely to have scheduled maintenance. Since mail files are stored on users’ machines, this sometimes means---especially for users working remotely---they'll have no access to their computers if the database is corrupted, needs to be compacted, etc.
Solution: When the Compact, Updall, or Fixup task needs to be performed on a local replica, some companies have developed batch files to send to users that, when executed, will perform these tasks on all or specific databases on the Notes client.
Other companies use Microsoft® Windows® Scheduled Tasks to call specific programs on a regular basis. Since these models require the user (or the program) to enter the Notes ID password, we prefer to use Program documents in the Local Address Book (see Section 5, “Running scheduled maintenance tasks on the Notes client,” below.)
- Delay. Some users and organizations might think that they need to replicate manually every minute in order to receive the newest messages.
Solution: Local replicas can be configured to send messages immediately after the user clicks Send. They can also be configured to receive new messages every 60 seconds. Refer to Section 3, “Real-time” synchronization when using local replicas,” below for more information.
- Additional resources provided to users' machines. Because users' laptops and desktops require a few extra local databases, such as extended Directory Catalog to do name lookups in the offline mode, their machines require higher disk space and memory compared with those who use server-based mail files.
Solution: There is always a bit of confusion around this topic since most people think that, now that they have a local replica, they need more resources. However, technically, it's sufficient to have the
Detailed system requirements for Lotus Notes recommended by IBM.
NOTE: Since a local replica database can be several gigabytes, just make sure there is enough space to store it. Also–and very important–make sure the local disk is healthy and fast enough to support the extra I/O.
- Initial replication / Plan and deploy. When planning a local replica deployment, you must take extra considerations for remote users. Mail files can be multiple gigabytes in size, and the creation of the replica must be carefully studied so as not to affect network resources.
Solution: There are two common approaches you can use when deploying local replicas to remote users:
a) Send an automated CD/DVD: Your IT department can create a CD/DVD with the mail file to be replicated (and additional databases, if desired and if space is available). You can instruct users to execute a batch file (let's say, MakeNotesFaster.bat) that will move the mail file from the CD/DVD to the Notes Data folder. (This method is also used when upgrading Notes Clients or installing Fix Packs.)
b) Two-phased deployment: The most important factor to consider when deploying local replicas to remote users is bandwidth. Obviously, organizations don't want to replicate big files during business hours and affect other applications using the same connection to the main office or data centers.
As a workaround, you can create two Desktop Policies, Local Replica Phase1 and Local Replica Phase2. The Phase1 policy only asks the Lotus Notes Client to create the local replica and will replicate only after business hours, but all settings still map to the server as the place to go for mail. After users confirm that the full replica of their mail file has been received, they move to the Phase 2 Policy, which changes all settings to use the local replica for mail.
In Notes 8.5.2, when your Domino administrator sets the creation of managed replica for you via a Policy, the Notes Client creates a local mail replica and marks it as a managed replica. For more information, refer to the Notes wiki article, “
Managed replicas explained.”
Real-time synchronization when using local replicas
When some organizations think about local replicas, they think about delays or no real-time access to their mail messages. However, by using the following features you can guarantee that new messages will be received roughly 60 seconds after the server replica gets the messages, and that messages sent to other users or to the Internet will be sent immediately.
Asynchronous mail replication
Asynchronous replication is one of the most important configuration settings when deploying local replicas. When this feature is enabled, it checks for new messages every 60 seconds (by default), and if there is at least one new message on the server, it triggers a replication task for the mail file (other applications in the Replicator Page are replicated on the next scheduled replication).
To enable asynchronous replication:
1. Add POLL_REMOTE_MAILFILE=1 to the client's Notes.ini file.
2. In the Notes Mail Preferences settings, enable and set “Check for new mail” to 1 minute (see figure 1).
Figure 1. Sending and Receiving Preferences window
3. In the Notes client, select File > Preferences > Locations > Edit, and select the Mail tab (see figure 2). In the Edit Location window, set the:
- Mail file location field to “Local”
- Mail Addressing field to “Local then Server” or “Server then Local”
Figure 2. Mail tab of the Edit Location window
Note that all these settings can be deployed and controlled via Policies. Refer to Section 4 below to understand how to achieve this configuration. Also, an active session is required with the user's Home mail server.
Controlling when messages leave the local Mailbox databbase
Another big concern for users is having to wait until the next replication to make sure a message is sent when they click Send. This may be hard to understand for some, or simply not desirable; however, by using Desktop policies, you can control when messages are sent when using local replicas.
Desktop policies let you modify additional settings on the Location document that are not included as options in the Desktop Settings document.
To do this, within your Notes client, again select File > Preferences > Locations > Edit, and select the Mail tab (recall figure 2). At the bottom of the window, use the “Transfer outgoing mail if:” field to set the maximum number of messages that must be in the local Mail.box before being sent to the server.
For Notes and Domino versions 8.0.2 and later, refer to the
Domino Policies Demystified blog for more information about updating specific Location document fields.
To update this value in the Location document in Notes and Domino 8.0.1 or earlier, follow the instructions in IBM Support Technote #1196837, “
Using a Desktop Policy to set notes.ini and Location parameters.“
Setting mail files to use high-priority replication
Scheduled replication is still recommended to maintain synchronization between both replicas (local and server), and when users move messages to folders, read email messages (that is, update unread marks), create folders, etc.
To maintain a minimum amount of data to be replicated, you can set high-priority replication for the mail file. This configuration mainly applies when users have multiple local replicas of different applications.
Currently, Policies can be used to create mail files’ local replicas but
not to set them to use the replication schedule for high-priority databases. However, with a little bit of coding you can change this. The example code in listing 1 shows how to set a database to use high-priority replication. You can adapt the code as needed.
Listing 1. Code to set high-priority replication
Dim db As NotesDatabase
Dim replication As NotesReplication
‘... your code here
Set db = ‘<set the NotesDatabase Object>
Set replication = db.ReplicationInfo
replication.priority = DB_REPLICATION_PRIORITY_HIGH
Call replication.Save()
‘... your code here
Also, as a best practice, instead of running this code every time you create new mail files, you can just change the setting on the Mail Template(s), so that all databases created from that template will inherit the setting.
To do this, open the mail file, select File > Replication > Options for this Application, select Other, and then change the “Set scheduled replication priority for this replica” field to High (see figure 3).
Figure 3. Replication Options window
