Hello –
A few things:
Steve is correct. On the BES server, you need to run the maintenance tasks on all items in the BES\ sub folder of the Domino Server’s Data directory. On the Mail server, you’ll want to run the maintenance tasks on the BlackBerry user’s mail files and server-based replicas of any personal Address Books or person Journals that BES uses. And yes, you can totally do these as on-line tasks. RIM just recommends off-line tasks since it’s the simplest way for RIM to walk neophyte Domino Administrators through while on the phone. They just assume you’ll run them as on-line tasks if you already know how.
I schedule mine to run once a week on both my BES servers and my Mail servers. You’ll want to schedule the program documents with enough of a time window so hopefully the next task doesn’t start before the prior task completes. I don’t know how much Domino Administration you are familiar with? So please excuse me if some of the following is rudimentary for you. You’ll want to schedule the tasks with the Administration client and not the Notes client (IBM’s recommendation).
Against the BES:
You just run the tasks against everything under \BES so we’ll hardcode this path in the Command Line field of the program documents. Then use the Administration client to schedule the maintenance tasks referenced in RIM KB02207.
Task 1:
Program Name: nfixup
Command Line: -F –L –O BES
Server to run on: BES01/OU
Schedule: Enabled
Run at times: (some time between Midnight and 2AM depending on your window)
Repeat interval of: 0
Days of week: (probably Sun or Sat)
Comments: BES program to run periodic maintenance to fix possible corruption in databases used by the BES. See RIM KB02207
Task 2:
Program Name: nupdall
Command Line: -R BES
Run at Times: (sufficient time after task 1)
Task 3:
Program Name: ncompact
Command Line: -c BES
Run at Times: (sufficient time after task 2)
Against the Mail servers:
Inside the data directory, create a text file called BES_Periodic_Maintenance.IND .
Within that text file, type the relative path of each BES User’s mail file or server-based replica of the Address book or Journal with each entry on its own line. that is, unless you want to also run these program documents against
all mail files or
all databases (etc) on these mail servers. (I don’t).
Quote:
(start contents of example BES_Periodic_Maintenance.IND file: )
Mail\aroc.nsf
Mail\adam.nsf
Mail\larry.nsf
Names\aroc.nsf
Names\adam.nsf
Names\larry.nsf
Memos\aroc.nsf
Memos\adam.nsf
Memos\larry.nsf
(end contents)
|
In my example, I have the mail in the Mail folder, server copies of the BES user’s Personal Address Books in the Names folder, and the Journals in the Memos folder.
Then use the Administration client to schedule the maintenance tasks referenced in RIM KB02207.
Task 1:
Program Name: nfixup
Command Line: -F –L –O BES_Periodic_Maintenance.IND
Server to Run: Mail01/OU
Schedule: Enabled
Run at Times: (some time between Midnight and 2AM depending on your window)
Repeat Interval of: 0
Days of Week: (probably Sun or Sat)
Comments: BES program to run periodic maintenance to fix possible corruption in databases used by the BES. See RIM KB02207
Task 2:
Program Name: nupdall
Command Line: -R BES_Periodic_Maintenance.IND
Run at Times: (sufficient time after Task 1)
Task 3:
Program Name: ncompact
Command Line: -c BES_Periodic_Maintenance.IND
Run at Times: (sufficient time after Task 2)
Task 4:
Program Name: nupdall
Command Line: -X BES_Periodic_Maintenance.IND
Run at Times: (sufficient time after Task 3)
Other noteworthy items: - RIM recommends that any personal address books (synchronized with a BlackBerry) should have at minimum these three fields populated: FirstName, LastName, CompanyName. Populating these three fields helps the Synchronization Service better do its job, since it has an easier time identifying the records. We find this to be somewhat true in practice. It does seem to help.
- I tend to delete users then manually delete their State Databases (under BES\State\xxxxxxxx.nsf) once every 2 years or so. I noticed some of the older state databases from users that were originally activated under BES 2.x were having problems reconciling changes (read/unread status, deletes – from E-mail). Continuing with that trend, I now do the same maintenance for everyone. Where I work high-profile people get a new handheld every 9-12 months and everyone gets a new one every 2 years. So this maintenance seems to best coincide when a user is issued a new handheld.
- On occasion an address book will stop synchronizing wirelessly with a handheld. We delete the Desktop SYNC address book from the handheld (Home, Options, Service Book) then from the console of the BES, we right-click on the user in question and select “resend service books.”
- The same can also happen with the Calendar. In the case of the Calendar, I just delete ALL of the Desktop* service books (including Desktop ICAL) and re-push new Service Books from the server.
- RIM suggests keeping mail files maintained with the Inbox view holding less than 1000 documents (document count in other views are not counted against this) and also keeping the folders/views within a mail file to less than 500 folders/views overall. Most people don’t create anything near 500 folders, so this isn’t often exceeded. However many people are know to keep more than 1000 or even more than 10,000 documents in their Inbox views. While exceeding this limit doesn’t always start to cause problems, it seems that the ones that do have problems are the ones with more than 1000 documents in their Inbox views (as high as 40,000 in some cases). If you can set up some type of archiving (that either you as the administrator maintain, or something the user can do) this can help.
- I keep Full-Text indexes (using the default FT index settings) of the BES users’ mail files and any address book or journal replicas that exist on the server. Keeping the FT indexes seems to help speed up the reconciliation times (read/unread status, deletions) as the BES seems better able to discern “what” has “recently changed.” Keeping the FT indexes was RIM T-Support’s suggesting, an so far we are pleased with the results so we continue to keep the FT indexes for BES users. Prior to implementing the FT Indexes, the media reconcile time was 40 minutes. It would not be uncommon for changes to take 24 hours or more to reconcile (part of this was the BES server was underpowered). After the implementing the FT Indexes, the median reconcile time (server to handheld) was less than 5 minutes though it is my understanding that this value is coded at the server to be 20 minutes or so.
IBM technote article on the architecture of Unread Marks in Lotus Notes - (link) IBM - The Architecture of Unread Marks in Lotus Notes (27002920) . This link may be useful if you have not already seen this information.
The Unread ID Table
Each database stores the list of unread documents in an
Unread ID Table within the NSF file. To save space, this table stores a list of Note IDs instead of the longer UNIDs. Because of this, the table is
specific to the replica that stores it.
This table is
user-specific and is stored within the .NSF file in a special structure named with the
hierarchical user name to which it applies.