標題: Managed Replicas Explained
網址: http://www-10.lotus.com/ldd/dominowiki.nsf/dx/Managed_Replicas_
內容:
Managed Replicas Explained
Introduction & Overview
Notes 8.5.2 introduces the managed replica, which is a variation of a standard local replica of the user's mail file. The managed replica has the special characteristic of being used "automatically" when the user is connected on a server-based location. It also has the capability of containing full documents for a section (based on time/date) of the mail file and truncated content for the rest (older data). The concept of a local replica of a user's mail file and the use of a local outgoing mailbox to send mail has been with Notes almost since its inception. Previously these features were utilized by configuring a location to use a local mail file, causing the client to use a local outgoing mailbox automatically. In addition, the replication schedule has to be configured so that the local replica will replicate with the server-based mail file.
At a fundamental level, the managed replica extends the capabilities of a local mail replica and a local outgoing mailbox to those locations where the user remains connected to a Domino server. In this configuration, (connected location with managed replica) when the user opens the mail file the client code will detect that a managed replica for the file exists, open that managed replica (locally), and present the user with the view of the mail from the local file. Updates, sending of mail, and receipt of new mail will happen as when the Notes user uses a standard local replica with a local outgoing mailbox. Synchronization occurs just as always, in the client replicator between the server-based files (mailbox, mail file) and local mail. The client will be configured to perform this synchronization in as timely a manner as possible (details in a later section). The target user for this feature is a user who is connected to a Domino server for mail but on a network or line that can have high latency issues (for example, LLN2). By moving all network I/O between local and server files to the background client replicator, the user's interface will never be blocked waiting for an I/O to complete. All the user's operations will occur on the local files.
Configuring Managed Replicas
There are two methods for creating a managed replica (or standard local replica) of the user's mail file.
1. Setting the appropriate value(s) in the NOTES.INI file.
2. Having the Domino Administrator set the appropriate fields in the Desktop Settings policy document. This method requires the release 8.5.2 Domino Directory NAMES.NSF.
In either method, the information is sampled by the Notes Dynamic Client configuration tool (DynConfig), and the local replica (managed or not) is created and added to the user's desktop and to the replicator. An initial replication (build) of the file is then triggered.
The following settings are recommended for the initial creation of a managed replica. Default settings can be used for the remaining parameters, which are detailed in the following table.
- CacheMail=3 (Create the managed replica if a local replica does not already exist.)
- OutgoingMailSendThreshold=1 (Set the mail threshold to 1. This means every time a new message is deposited in the local mailbox it will immediately be sent to the server.)
- ReplicateOnNewMail=1 (Replicate new mail from the server every time we detect new mail has been delivered. This is crucial in keeping the cache "up to date")
These settings can be configured explicitly in the NOTES.INI file by the end user or they can be pushed down by the administrator, using the Notes Desktop settings policy:
| Notes.ini Parameter/Policy Field | Type | Description |
| CacheMail (INI)
LocalReplica (Policy) | Bit mask | Controls the initial creation of the local replica. This parameter can have the following values:
1 - Create a local replica of the user's mail file. If a local managed replica exists, convert it to a standard local replica.
3 - Create a local managed replica of the user's mail file. If a local replica already exists, do nothing.
7 - Create a local managed replica of the user's mail file. If a local replica already exists, convert it to a managed replica.
8 - Delete the local replica of the user's mail file (managed or not). |
| CacheDBInitialFullDoc | Number | Applies to initial managed replica creation only. If set (to n) the most recent n days worth of data will be replicated with full content (attachments and rich text). (Default is 30 days). Documents older (not modified) than this will be truncated. (Default is summary data only). |
| CacheDBRemoveDocsAfter | Number | Applies to initial creation of the local replica. If set (to n) documents not modified in the last n days will not be retrieved from the server and will be removed as the replica ages. (This is the same setting as seen on the Space Savers panel of the replication options dialog box). Default is none (all documents will be retrieved). |
| DocAutoRetrieve | Number | This setting controls the auto-retrieval of truncated documents in any local replica. :
0 - No auto-retrieve of truncated documents. Entire documents may be retrieved the same as in selective replicas.
1- Rich text (content) is automatically retrieved when a document is opened. Attachments are retrieved on demand (when accessed).
2- All truncated content (rich text and attachments) is automatically retrieved from the server when the document is opened.
Default value if not specified is 1 (auto-retrieve of rich content). |
| CacheDbTruncatedRTF | Number | Amount of rich text (in KB) to retrieve in docs older than CacheDbInitialFullDoc days during cache creation. Default 0 (summary only) |
| CacheDbTruncatedAtt | Number | Amount of attachments (in KB) to retrieve in docs older than CacheDbInitialFullDoc days during cache creation. Default 0 (summary only) |
| CacheDbFreeSpaceNeededInMB | Number | Amount of free disk space required on the user's drive where Notes data resides in order to create the managed replica. Default is zero. (the client will always try to create the managed replica) |
| OutgoingMailSendThreshold | Number | If set, the client will use a local outgoing mail box for sending mail from the user interface. The client replicator will transfer the sent messages from the local mailbox to the server's mailbox. The value of this parameter will indicate how many messages need to be queued in the local mailbox before triggering the replicator to transfer them to the server. The default is zero (transfer directly to the server's mailbox).
Note: It is recommended for all users of LLN2 that this value be set to 1 (transfer on each message deposited to the local mailbox). |
| ReplicateOnNewMail | Number | If non-zero and a local replica (managed or not) exists. The client replicator will be triggered to pull down new mail from the server upon detection of that mail being deposited in the user's server-based mail file (asynchronous notification from the server to client). |
| FailoverSilent | Number | If non-zero the client will silently fail over to a different server if the current server is no longer operational (no prompts). Default is 0 (prompt). Best practices suggest this should be set to 1 for all server based mail users in the LLN2 environment. |
| ($PrefReplDefFullText) | Number | If set to non-zero full text indices will be created for all local replicas (including managed replica). Default is 0 (no full text indices) |
| ($PrefReplDefEncrypt) | Number | If set to non-zero local replicas (including managed replica) will be created with encryption turned on (default). |
| ($PrefReplDefEncryptType) | Number | Specifies the strength of the encryption for the local replicas |
Desktop Settings policy document > Mail tab > Mail Settings & Managed Replica Settings
Desktop Settings policy document > Mail tab > Client Settings
Creating & Using Managed Replicas
After the client is started, with the above values set in the NOTES.INI file, the managed replica will be created. The processing of these values and the initial replica creation is handled by the Dynamic Client Configuration tool (DynConfig). If a policy is received, that contains a setting for the LocalReplica, the setting will be interpreted and the other fields (in the table above) will be pulled from the policy and copied to the NOTES.INI file. If the CacheMail setting is in the NOTES.INI, that setting is interpreted and the other values (if set) are assumed to be also set in the NOTES.INI. In this way, the same code can process the settings regardless of whether they were pushed down through a policy or explicitly set in the NOTES.INI file.
The trigger is the value of CacheMail (NOTES.INI file) or LocalReplica (policy). In the case of a policy being pushed down all the other values are extracted from the policy and copied into the Notes.INI and the code from that point forward will interrogate the INI variables to determine what to do. If specified, the local managed replica is created (in the same relative path as on the server), and the desktop entry is created and added to the workspace. A replication entry is also created and added to the replication page; then a replication is initiated.
The managed replica is initially marked out of service, using the database option (DBOption) bit, until the initial replication pass is complete. In addition, a new database option bit (DBOPTBIT_LOCAL_CACHE) that identifies the local replica as a managed replica is set in the database. This is essentially the only on-disk difference between a standard local replica and a managed local replica. A managed replica is initially set to retrieve summary data only from the server. As the replicator makes its first pass, it checks to see, for each note to be replicated, whether the last modified time is more recent than (CacheDBInitialFullDoc) days. If so, the replica is signaled, on the fly, to retrieve the entire note from the server. Once the first replication pass is complete, the replica is updated always to retrieve entire documents from then on. In addition, the replicator will build the most accessed views (Inbox, Sent, Calendar...) before marking the replica back in service. After the replica is marked in service, it will be used as the user's mail file.
Using mail during the creation of the managed replica
All the processing in the preceding paragraphs takes place in background processes (Task Loader, DynConfig) on the Notes client. The end user will continue to access mail and calendar directly on the server. If a value for the OutgoingMailSendThreshold (recommended value is 1 for use with a managed mail replica), the local outgoing mail box (mail.box) will be created immediately. Any mail sent by the end user from then on will be deposited in the local mail box and then immediately replicated to the server via the background replicator. Once the managed mail replica is completely replicated and is marked in service, it is ready for use.
Using the managed replica as the mail file
The managed mail replica is essentially intended to be used as an abstraction of the user's server based mail file. Even though the location will still indicate that the user's mail file is on the Domino server, user gestures which access the mail file will transparently access the local managed replica rather than the server-based file. The following gestures will all access the local replica rather than the server replica:
1. Open->Mail from the bookmark list.
2. Create->Mail-> Message...
3. File->New->Message...
4. Actions->Forward
5. Sending mail from a third-party application (for example, Adobe Reader).
6. Double-clicking a workspace icon of the mail file.
The user can still directly access the server based copy by explicitly opening it. There are two methods by which the end user can explicitly open a specific server-based replica of the mail file:
1. Select File -> Open -> Lotus Notes Application, then browse to the desired server and replica.
2. From the Workspace Entry or from the Open List, select Open Replica-> and then select a specific server-based replica.
Synchronizing the managed replica
As already mentioned, a managed replica is essentially a local replica with a couple of special attributes. It will use the same background replicator as other local replicas to sync changes between the local file and the server-based replica. Because the managed replica is an abstraction of the server-based file, it should receive updates to the local file as soon as possible. For that reason, the managed replica should always be used in conjunction with the ReplicateOnNewMail setting. Updates in 8.5.2 always leave a network session open to the user's home mail server. In this way, an asynchronous notification is always received at the client, when new mail is deposited in the server mail file. If the ReplicateOnNewMail setting is enabled, this configuration will trigger a replication of the mail file to the local managed replica and the new mail will become available at the client.
Because the goal is for the end user always to work in the local file, updates made locally are not as time-critical to send to the server. If the user already had replication enabled, when the managed replica was created, the settings are not changed. For all server based locations, for which replication is not enabled, the client will create a default schedule (once an hour, seven days a week) for the replicator. Updates made to the local replica will be pushed out to the server on this schedule.
One of the goals of the managed replica is to never block the user interface due to network latency/connection issues. This is especially important in the cloud environment. For this reason, a managed replica should always be used with the SendOutgoingMailThreshold parameter set to one. When the user sends an e-mail, it will be dropped locally in the mail.box file and the user can continue on to the next operation without waiting for the transfer to the server to complete. If the threshold is set correctly (to one) the background replicator will immediately transfer the message to the server's mailbox. Because this happens in a background process, the user interface is not blocked or delayed.
Full text index searching
When the local managed replica is created, a full text index will also be created if either of the following is true:
1. The server based replica has a full text index.
2. The setting ($PrefReplDefFullText) is set, indicating a full text index should be created.
The managed replica is created and replication is performed in the same manner , whether a full-text index is created or not. That is to say, the CacheDBInitialFullDoc setting controls how many days of full content (default 30) is replicated down to the client. All remaining data is summary only (by default). Once this initial replication pass is complete, the indexer is kicked off and the content that has been retrieved from the server is indexed. The end user can now perform full text searches against the local, managed replica. Because the data is incomplete the index will be as well.
The first time the user searches the mail file, this will signal the background replicator to begin to pull down the rest of the data (the notes that were truncated) from the server. This happens invisibly to the user and will be interrupted if the client exits before it is done. The "trickle down" of the truncated data will continue on client restart. The data is indexed as it is retrieved. The user can continue to search the local managed replica while this process is occurring. The user will receive an indication with the search results, that the hits may be incomplete as the index is not fully built. Once all of the truncated documents are retrieved and indexed this indication is removed and the user can search with impunity. The screen shot below illustrates a typical result said with the (Incomplete...) added to the header line. Hovering over this line will indicate that the reason the results may be incomplete is that the index is still being built.
NOTE: The managed replica's index uses document data plus any attachment data already retrieved, if the "Index attached files" option was set on the server replica.
Falling back to the server-based replica
The goal of the managed replica is that the user constantly works on the local file, the data is synchronized in the background, the user is never blocked due to network latency and never has to explicitly connect to the server based replica of the mail file. One of the issues with the Notes client and local files has to do with an abnormal client exit. Any local NSFs that were open are now in a potentially inconsistent state and need to be fixed up. The end user will typically see this when, upon restarting the client they go to access a local database (e.g. their local mail file) and receive a status message to the effect that the code is performing a consistency check on the file. The user is prevented from being able to access the file until the consistency check has completed. Unfortunately, depending on the state of the NSF when Notes terminated, and particularly for large files, this can be a lengthy delay. For managed replicas, on access, the code will check if the file is an inconsistent state and if it is, will automatically redirect the user to the server based replica. The consistency check, or fixup will occur in a background thread. Once this check is complete, a replication with the server based file is triggered. Subsequent accesses of the mail file will then go back to using the local managed replica.
If managed replica got badly corrupted or deleted or somehow got in a state where the code is unable to complete the consistency check, the existing managed replica will be deleted. The code will then recreate the file from scratch, honoring the settings as outlined in the previous sections. Again, after the replication completes and the views are built, the managed replica is ready for use and will be transparently switched to, on subsequent mail file accesses.
Architectural Change: Multi-threaded Background Replicator
The creating and the initializing of the managed replica simply leverages the long standing replication technology in Notes. No architectural changes were required here either. The notion of switching between various replicas of the user's mail file depending on availability is also a longstanding capability of Notes utilized by fail over. The transparent switching to and from the local managed replica based on its state leverages and extends this capability. The one major area where architectural changes were introduced in support of the managed mail replicas is in the Notes client's background replicator.
Prior to Notes 8.5.2, entries on the client's replicator page were processed in sequence, by the background replicator process, in a single thread of execution. The main goal of the managed mail replica is to shield the user from any network latency issues by performing all mail operations in this background process. However, the user expectations is that these operations occur in real time (when they hit send, the message is sent immediately, when new mail arrives in their mail file, they see it immediately...).
In the single threaded model, mail operations can be blocked for a significant amount of type. Imagine the end user has other local replicas. If a large number of documents, say from a specs database, are being replicated down to the client machine, all other replicator operations are blocked until the first replication is complete. Even if the end user utilizes the background replicator solely for mail operations scenarios are encountered where a large amount of data is being replicated in one direction (incoming or outgoing) and pending operations in the other direction are blocked until the current operation is complete.
The solution for this problem in Notes 8.5.2 is to re-architect the background replicator to be multi-threaded so that more than one operation can be executed simultaneously. In particular, higher priority is given to operations involving the end user's mail than other replicator operations. To that end, two threads of execution are reserved for mail operations, essentially sending and receiving of mail. In general, just one thread will be utilized, but if that thread is busy for longer than 15 seconds, the second thread will be utilized to perform the other mail operation.
All other replicator functions are performed on a pool of worker threads. Operations against the same server (e.g. replicating 3 databases, all against the same remote server) are grouped together, in a single thread and performed sequentially. Failover will occur exactly as in earlier versions of Notes.
Because multiple operations can be concurrently executing the user interface for the client to reflect that. The major change is that rather than have a single status area at the bottom of the page to reflect the current operation, each entry in the replicator page has its own status area and an individual button to control (cancel) its operation. The major button at the top allows the user to start or stop all enabled operations. The various menu commands and capabilities (Send/Receive Mail, replicate with a specific server, etc..) remain the same.
The screenshot below illustrates a typical scenario during a scheduled replication, on the Notes client:
Note that the mail operations have already completed, on the mail thread. Two databases are concurrently replicating with the respective servers. Each database has its own stop button and one can be cancelled independently of the other. A third database is pending, which means it is waiting for another operation to complete. There are two reasons for an operation to be pending:
1. All the threads are busy executing replication requests.
2. There is an active replication request processing against the server that the pending operation wishes to utilize.
In the example shown above, the database that is pending (V85 Fixes) is waiting to replicate against the same server that the entry above it (Clearcase) is currently replicating with. Once the replication of the first NSF completes, the second NSF will be processed, on the same thread of execution.
Intended audience for Managed Replicas
The sweet spot for managed replica usage is end users who work exclusively connected to a Domino server but are frustrated by delays in processing mail operations, waiting for network operations to complete. Users in a remote location and cloud users are two good examples. Anyone who experiences network latency issues would benefit from having a managed replica. In addition, because the Notes replicator streams notes from the server to the local machine in a single NRPC transaction, usage of managed replicas can reduce load on the Domino server. The managed replica has to be created and completely replicated and have its view indices built before it can be utilized. Newly provisioned users or users with small mail files are excellent candidates for managed replica usage as they can enjoy the benefits of the local replica almost immediately.
Users with large mail files can also utilize managed replicas. One potential consideration for these users is to configure the setting CacheDBRemoveDocsAfter to create a managed replica that is also a selective replica. For example setting CacheDBRemoveDocsAfter to 365, the end user will have a managed replica containing documents for the most recent year, and full content for the most recent 30 days. This will allow such users to get online and use the managed replica for new mail in a more timely fashion. The caveat here is that in order to see documents older than one year the end user must explicitly open the server replica.
As noted in an earlier section, the managed replica can be configured by the Domino Administrator via the Desktop settings policy. (eg. Open->Mail->Open Replica-> <Home server replica> or go to the File->Open->Lotus Notes application dialog and explicitly browse to the server based replica).
Users of local mail replicas can continue to use these replicas as they always have. The behavior of standard local mail replicas do not change with the addition of managed replicas. In general users who are comfortable with local mail replicas and understand the functionality and limitations should continue to use them in the manner they are accustomed to. Notes 8.5.2 will support the ability to convert a standard local replica to a managed replica. In local locations, the managed replica will behave much the same as a regular local replica. The benefits of conversion will add the capability to use the managed replica even in a server based location, as outlined in the functional section of this document. In addition, if the local replica needs fix up, the code will automatically switch back to using the server based replica. Converting a standard replica to managed or vice versa does not change any of the data parameters but simply toggles the database option bit that identifies the file as a managed replica. What ever the truncation and selective replication parameters are for the existing file, they will not be altered when converting between a standard and a local replica.
Configuring Managed Replicas for large number of users
Users can have managed replicas setup for them by the Domino Administrator via the Desktop Settings policy document. One thing to consider is that the potential for a large number of users to have the same policy pushed down to their clients at roughly the same time. This could result in a large number of managed replicas being created and replicating with the Domino mail server simultaneously, causing significant load on the server. To reduce the likelihood of this, the Administrator may want to consider a phased approach. Notes 8.5.2 has built-in functionality to mitigate this risk.
For hosted users whose Domino mail server is in the cloud, the server load when creating a managed replica is modulated based on the current server load. This modulation occurs as a cooperative exchange between the Notes client and the Domino SAAS (LLN2) server. When establishing a session to the LLN2 server for initially replicating the managed replica, the Notes client will indicate that this is a background session. The LLN2 server has built in controls to award higher priority to foreground sessions. If the server becomes heavily loaded it may send asynchronous notifications back to the client, on this session to indicate that it should modulate the streaming of the data (notes) from server to the client. Based on the data in the asynchronous notification the client code will delay before asking for the next piece of data in the replication stream. If the server becomes too heavily loaded, it may, without warning terminate the session to the client. For this reason, the client periodically stores away checkpoint results during the replication operation. If the replication is interrupted (either by the end user or by the server terminating the session), the client code will, upon the next replication, pick up the latest checkpoint results. The replication operation will pick up from there, rather than starting over again to stream the data down to the local machine.
A different mechanism needs to be managed replica users whose mail servers are on premise. For Notes 8.5.2, the managed replica creation code will leverage the same throttling mechanism that exists for the Notes Smart Upgrade on the server. The administrator will have to enable the Smart Upgrade Governor in the mail server's configuration document:
The maximum concurrent downloads setting indicates how many client machines can be replicating with the mail server for the purpose of building the managed mail replica at any given time.
In addition to allowing a maximum number of clients to connect to the server for the purposes of managed replica creation and initial replication, the replication code in the end user's client will receive an indication of how many concurrent managed replica operations are being performed on the server. Based on this number the replicator will delay between operations that occur during the initial replication of the managed replica. The delay behavior will conform to the following algorithm:
1. If the number of concurrent replications that are active is less than twenty percent of the maximum number (maximum concurrent downloads) no delay is enforced between operations.
2. If the number of concurrent replications is between twenty percent and ninety percent of the maximum number the client replicator will delay between operations. The operation will be delayed in proportion to this percentage. For example suppose the maximum concurrent downloads is set to 100 in the Smart Upgrade Governor:
a. For less than 20 concurrent replications there will be no delay .
b. For over 90 concurrent replications the server connection will be refused.
3. If the number of concurrent replications reaches ninety percent of the maximum number, any further attempts to connect to the mail server to build a managed replica will be refused. If this maximum count is reached any subsequent server connections to build a managed replica will be refused. The end user will see the following error displayed on the replicator page: "Access to this server has been restricted due to excessive load."
Examples for setting maximum number of users
- The limit can be set at what ever the administrator would like to set it at, and the client handles it in the following way.
- If the default of 100 is used, the first 20 users (20%) can replicate at the highest performance level at the same time, users 21 through 90 are still allowed to replicate, except at a lower level, and (at 90% usage) users 91 to 100 (and above) are limited until less users are currently replicating (Access to this server has been restricted due to excessive load).
- If 1000 user limit is used, the first 200 users (20%) can replicate at the highest performance level at the same time, users 201 through 900 are still allowed to replicate, except at a lower level, and (at 90% usage) users 901 to 1000 (and above) are limited until less users are currently replicating (Access to this server has been restricted due to excessive load). 90% was chosen so Smart Upgrade has at least 10% of the user limit to use for Smart Upgrade purposes.
- So 90% of the user limit setting, can replicate at the same time. The first 20% of the user limit will replicate at the highest performance level, users from 21% to 90% of the limit will replicate at a lower performance level.
- Setting the maximum users to a large number will essentially disable the governing/limiting for replication and rely on the standard server performance to handle its maximum number of users that can replicate at the same time.
If a client is refused a connection, it will attempt again, according to the above algorithm on the next replication (scheduled or explicit, via user gesture).
Enabling full text searching for Managed Replicas
As already mentioned, if the server based replica of the user's mail file has a full text index, the local managed mail replica will be created and a local full text index will be created so that the user will have the same search capabilities as on the server. However, a number of current customers do not have full text enabled on their servers for performance reasons. For end users who have sufficient free disk space, the administrator has an alternate method to be able to provide full text capabilities for managed replicas. On the desktop settings policy document, the Preferences->Replication Tab has a setting to create full-text indices for local replicas (Create a full-text index for faster searching):
Note: Enabling this setting will create a full-text index for all local replicas, not just the managed mail replica. It should also be noted that the data will be retrieved for building the full text index in a background session, much the same as the data that is retrieved when the managed replica is initially built.
Screencasts
You may also watch the video in full size and in HD on You Tube
How to Identify Truncated Documents
Error when Archiving Truncated Documents
Related Content
Technote #1448134: Understanding Managed Mail Replicas (Q&A, Troubleshooting, and Known Issues)
Technote #1437957 - Configuring managed replicas using the Desktop Settings document
Technote #1505469 - Recommendations to achieve the best results with Notes/Domino Failover functionality
Help topic: What's New in Lotus Notes 8.5, 8.5.1, and 8.5.2?
About the Author
This article was written by Mike Kudla, a Sr. Software Engineer on the IBM Lotus Notes Client Adoption Team.
標題: Q&A: Understanding Managed Mail Replicas
網址: http://www-01.ibm.com/support/docview.wss?uid=swg21448134
內容:
Q&A: Understanding Managed Mail Replicas
Abstract
This technote provides answers to common questions about the Managed Mail Replica feature introduced in Notes/Domino 8.5.2.
Content
Tip: Review this Q&A in conjunction with the wiki article titled Managed Mail Replicas Explained
How can you determine if you are using a Managed Replica?
-- The easiest way is to go to the Open List and select Open > Mail. The mail file should indicate that it is on Local, even if the current location is a server based mail file location.
-- You could also go to File> Application > Properties. The Type drop-down list should indicate"Managed Replica".
How do you know whether a managed replica is working correctly?
The managed replica is working correctly if the following are all occurring:
1. Access to the mail file brings the user to the local replica.
2. The user is never blocked doing mail/calendar operations.
3. New mail is received, sent mail is transferred to the mail server and the managed replica stays in sync with the server based replica.
Can users still access your home server-based mail file replica even though you have a local managed replica?
In general, the managed replica is intended to replace the server based replica as the user's mail file. However, there may be instances where users still want to directly access the server based mail file. This can be accomplished by explicitly accessing the server based file in one of two ways:
-- Open -> Mail(right-click) -> Open Replica -> Choose the home server>
-- File->Open->Lotus Notes Application, then Choose the home server and browse to the user's mail file on that server.
What should you check if new mail is not being delivered to a managed replica?
-- Check for the following line in the notes.ini: ReplicateOnNewMail=1?
-- From the Open list, select Replication and Sync. Is the local managed replica entry visible and enabled? When was the last time it replicated?
-- From either the Replicator page or the managed replica's Inbox, select the Send and Receive Mail button. Does new mail appear? Send a test message and see if it is received in the Inbox.
-- Does the new mail notification appear in the Notes Status bar? Do you hear the new mail sound when new mail is delivered on the server?
What if a managed replica does not seem to stay synchronized with the server-based copy?
It is important to note that changes made on the managed replica (drafts, filing into folders, unread marks) are not replicated to the server until the next scheduled replication. New mail should be received within a few seconds after it is delivered on the server copy. Also, sent mail should be received by the intended recipients immediately (see subsequent problem).
For synchronization issues in general, all that needs to be checked is that scheduled replication is enabled and the managed replica is checked. (Note: this is done automatically when the managed mail replica is created, however, the user can change these settings and essentially disable the replication. )
What should you do if sent mail is not being received by intended recipents?
Check the following items:
-- Is the following line in the user's notes.ini -- OutgoingMailSendThreshold=1
-- Do you see messages pending in the outgoing mail.box? Select File > Open > Lotus Notes Application, then while on My Computer type mail.box and select Open.
-- On the Replicator page, is there an entry for Outgoing Mail on the Replicator Page? Is the entry enabled/checked? Are there any pending messages? When was the last time it replicated?
-- If pending messages and/or messages were seen in the mail.box file, hitting the Send/Receive Mail button in the Inbox or on the replicator page should send the messages.
Does the setting "Amount of free space required before cache is created" compare the amount of free space on the client with the size of the mail file?
No, it is just looking at free space available on the drive with the Data directory. The managed mail replica tends to be smaller based on initial truncation and truncation of attachments older than 30 days.
For example: Say you have the setting set to 2GB and the mail file is actually 5GB. If you have only 3GB left on your local drive it will meet the criteria for the size but you still will not have enough for the actual replica (assuming you are not truncating any docs). In this case, the replica will be created, and will replicate what it can. And then, when enough space becomes available, replication will complete.
If the replica fails due to not enough space is the partial replica removed? If not removed, does it keep the content that replicated before space ran out or just a replica stub of a smaller size?
The initial local replica stub would succeed, but replication may not complete. The Notes Client will continue to use the server copy, until at least the initial replication completes. Replication is optimized to not resend the same documents once replicated. In addition, there is an additional optimization the stores the initial replication search to avoid repeating a search if replication does not initially complete, for whatever reason.
If the replica fails due to not enough space, will it continuously try at each client startup because the policy indicates there should be a managed mail replica but one is not present?
If the space check fails, yes it will retry, but the checks for space are computationally cheap and done infrequently. If the space check succeeded, but the replication did not complete, it will retry on the replication schedule.
How can you prevent it from continuously trying to create the replica if not enough space?Raise the free space check to a higher value.
Does a managed mail replica's full text index include attachments?
The managed replica's index uses document data plus any attachment data already retrieved, if the "Index attached files" option was set on the server replica. See below for more details.
The default full text index, created automatically with managed mail replica (MMR), is document data only (with caveats):
First MMR replicates the last N (30) days of full documents (data and attachments) leaving the rest of the database with truncated documents (minimal data and no attachments). When the first search is performed on the MMR, the document data for those truncated documents (without the attachments) is retrieved from the server, using background replication. The attachment data for those truncated documents can be auto downloaded when a user accesses them manually. The full text index is created locally with the same options as the server FTI. The attachment data is not in most of the truncated documents, unless the user has accessed them, or they were in the first N days of fully replicated documents.
The user can delete the full text index created for MMR and recreate it with "Index attached files" option set, using the document properties dialog, but the attachments will still need to be retrieved before they can be included in the full text index. You can not index what is not there.
Known Issues & Troubleshooting
Configuring managed replicas using the Desktop Settings document (Technote #1437957)
Local replica converted to managed replica does not get upgraded to ODS 51 (Technote #1444556)
Notes clients are still throttled when creating managed replicas, even after disabling Smart Upgrade Governor on the server (Technote #1444563)
A database that is marked "out of service" does not replicate on startup (Technote #1444558)
Related information
Managed Mail Replicas Explained
Recommendations to achieve the best results with Notes/ |
|