ho verificato... e il link funzia ;) cmq ecco l\'estratto
How to resolve Free Time inaccuracies in Notes/Domino Calendar and Scheduling
Technote (FAQ)
Problem
What can an Administrator do to resolve inaccuracies with free time lookups/schedules that may occur in the Calendaring & Scheduling feature of Lotus Notes/Domino®? Should the Domino Administrator rebuild the Busytime.nsf on a periodic basis?
Solution
Index:
I. Start here
II. What to do next
III. Prepare data for submitting to IBM Lotus Support
Note: The Free Time database (Busytime.nsf) does not need to be rebuilt on a regular basis. If the Free Time database is corrupt, the Schedule Manager will abort and log a failure, and free time lookups will return no data or inaccurate data.
I. Start Here
To troubleshoot inaccurate Free Time start by doing the following:
1. Compare the $BusyName value in the Calendar document against the $Name value in the Resource/Room document or the busytime document for the affected user in the Busytime.nsf or Clubusy.nsf (for clustered environments) database.
These entries should be the same, and in canonical format (that is, CN=First Name Last Name/O=Organization Name). They may not match in rare cases when a user (or room or resource) was renamed and the rename did not complete without problems. Check the Administration database (Admin4.nsf) for any errors that may have occurred during a rename.
2. Make sure the StartDate Time and the EndDateTime fields of the Calendar document match up with what displays in the Calendar or the CalendarDateTime field.
2a. The $BusyPriority item value on the Calendar document is used to convey "pencilled-in" versus "busy". A $BusyPriority value of "1" (or missing) is an Appointment and should appear as occupied time in the graphical user interface (GUI). A $BusyPriority value of "2" is a pencilled-in entry and should not appear in the GUI (the GUI does weighting but it has no means of rendering "pencilled-in" versus "busy", so it does not render them).
3. Check the user\'s Person document for misspellings/typos in the User Name, Mail Server, Mail File, and Domain fields.
4. Check the user\'s Notes Client preferences to make sure the user name in the field, "This Mail File Belongs To" is correct. While in the mail file, select Actions > Tools > Preferences and switch to the Mail tab, Basics sub-tab.
II. What to Do Next
If you have checked all items above and they have their correct values then follow the steps below.
Note: Before executing the console commands below, please enable console logging. To enable Console logging type the following command:
start consolelog
From the Domino Console of the Home server of the Mail file or Resource Reservations database type the following commands:
1. Tell Sched Show HIERARCHICALUSERNAME or roomname/sitename
This command will look at the Free Time database and display the entries for this person (sorted chronologically), and the data will be placed in the Log.nsf as well as display on the console. There will be 1 line per entry except for the case of repeating meetings which are listed as 2 lines per entry. Schedule Manager will also tell you some information about each entry such as whether it is pencilled in, repeating, etc. You can use this information to match up against entries in the user\'s actual Calendar.
2. Tell Sched List HIERARCHICALUSERNAME or roomname/site name
Issuing this command will display the user\'s profile information, list when the user is available, and write the data to the log.nsf as well as display it on the console. If the HIERARCHICALUSERNAME is not in the busytime database or not typed correctly then Schedule Manager will log the error "User HIERARCHICALNAME not found in schedule database" instead of any data.
3. Tell Sched Check HIERARCHICALUSERNAME or roomname/sitename
This command causes Schedule Manager to check the user\'s busytime data against their actual Calendar documents. If there are any existing busytime entries that are different than the actual entry in the user\'s Calendar, the user\'s busytime will be updated to match the version in the mail file. If the entry does not exist in the mail file then it is removed from the user\'s busytime record. Entries that do not already exist in the busytime database are not found and added; this command simply makes the current busytime data match the data in the user\'s mail file. If after running this command the busytime is still not accurate, open the Calendar entry in Edit mode and modify it by either making a fake change to it (for example, press the space bar in the description field) or marking it "pencil in". Run this command again. If you marked the entry as "Pencil In", deselect the "Pencil In" checkbox and run the command again.
4. Tell Sched Validate HIERARCHICALUSERNAME or roomname/sitename
This causes Schedule Manager to check if a user is "valid" or not on that server. If the user is valid, Schedule Manager will pick up any Calendar related changes that occur in the user\'s mail file after the command is run. It will NOT pick up any missing updates up to that point. If Schedule Manger is already monitoring for Calendar entries then the command has no effect. This command is primarily intended to be used in cases where new users, rooms or resources get added to the Domino server but are not immediately reflected in busytime.
If a new user is added and they immediately begin using Calendaring & Scheduling (or a new room or resource is created and you need it to be available immediately), you can use this console command after they have been added to the Domino Directory (Name & Address Book, or NAB) and Schedule Manager will begin to monitor their mail file and create a busytime record for them. Schedule Manager repeats its startup scans and database validation at 2AM local time; therefore, any new user, room or resource will automatically be found and added to Busytime.nsf at that point.
If after all of the above procedures have been executed and the Free Time system still is not providing accurate results, the Free Time database may need to be re-created.
Note: Re-creation of the Free Time database should be conducted during off hours.
If the Free Time database needs to be re-created, follow these steps:
1. If possible, map a drive or FTP to the Domino Server\'s \Data directory.
2. From the Domino Administrator open the live console.
3. Issue the following commands:
Note: These commands are not case sensitive.
tell sched q
tell CalConn q
tell RnRMgr q <---- Note: This command is for the Domino 7.x server only
dbcache flush
Note: Several "dbcache flush" commands may be required, depending on the OS and the server\'s load.
4. On the Domino Server\'s \Data directory locate Busytime.nsf and rename it to something else, such as Busytime.old. Then move Busytime.old out of the \Data directory and from any references to a database or directory link.
Note: DO NOT leave the renamed copy in the Domino server\'s \Data directory hierarchy or you may encounter unexpected results.
5. Issue the following commands:
Note: These commands are not case sensitive.
load sched
load CalConn
load RnRMgr <---- Note: This command is for the Domino 7.x server only
How To Re-create Clubusy.nsf File (applies to Domino 5.x, 6.x and 7.x Servers only):
The Clubusy.nsf file is the Free Time database on a clustered server. To re-create (or restore) the Clubusy.nsf file do the following:
Note: This process must be done to all servers in the cluster to avoid the replication of Clubusy.
1. If possible, map a drive or FTP to the Domino Server\'s \Data directory.
2. From the Domino Administrator client open the live console.
3. Shut down the Sched and Calconn tasks on all clusters and flush the database cache.
tell sched q
tell CalConn q
tell RnRMgr q <---- Note: This command should be run on Domino 7.x Servers only
dbcache flush
Note: Several "dbcache flush" commands may be required, depending on the OS and the server\'s load.
4. On the Domino Server\'s \Data directory locate Clubusy.nsf and rename it to something else, such as Clubusy.old. Then move Clubusy.old out of the \Data directory and from any references to a database or directory link.
Note: DO NOT leave the renamed copy in the Domino server\'s \Data directory hierarchy or you may encounter unexpected results.
Important Note: Steps 3 and 4 MUST be done on ALL clustermates BEFORE Step 5 is performed on ANY server. Otherwise, old data may be added back into the Clubusy database invalidating what you are trying to do. If you do not do this correctly, you will have to restart the recreation process for Clubusy.nsf (steps 1 - 4) all over again.
5. Issue the following commands on all clustermates:
Note: These commands are not case sensitive.
load sched
load CalConn
load RnRMgr <---- Note: This command should be run on Domino 7.x Servers only
III. Prepare Data for Submitting to IBM Lotus Support
If the steps above do not resolve the issue, please prepare the following data to be submitted to IBM Lotus Technical Support:
Enable debugging for the Schedule Manager
Debug_schedule=1
A Note about debugs:
1.. DEBUG_SCHED_ALL is used by the Server / NSF to provide debug information about busytime lookups, etc. This option can be turned on/off via the console and takes immediate effect for Client -> Server command tracing of commands/lookups. This setting is NOT useful for tracking down any Schedule Manager related problems. A server restart is NOT required when you change the value of the Debug_schedule. It will take effect without a restart.
2.. DEBUG_SCHEDULE is used just by the Schedule Manager to provide debugging information about what it is doing (or not doing). In releases prior to Domino 6.0, it was either On or Off (a value of 1 or 0). As of Notes/Domino 6.0 it was changed into "levels" to keep the unnecessary information in the logs at a minimum. The levels are:
Debug_Schedule=1 /* Basic debugging messages */
Debug_Schedule=2 /* Busytime cache debugging */
Debug_Schedule=4 /* Admin Caveats, if they want \'em */
Debug_Schedule=8 /* Trace routine entry/exits */
Debug_Schedule=16 /* Scanning dBs for docs to process */
Debug_Schedule=32 /* Detail harvesting/processing related */
Debug_Schedule=32768 /* MSB = "All" or "R5 behavior", verbose */
You can combine the levels together to obtain combinations as desired. For example, you can use DEBUG_SCHEDULE=3 to obtain both "Basic" and "Busytime cache" messages.
This option is for tracing busytime information gathering by Schedule Manager only. This setting is NOT useful for tracking down any busytime lookup related problems. Changes to this setting DO require a restart of Schedule Manager in order to take effect.
Note: In Domino 7.0 the Rooms and Resources manager also responds to similar debug parameters as the Schedule task. The values are the same, but the INI parameter to enable them is as follows:
DEBUG_RNRMGR
This debug information should be included for situations on Domino 7.0 Server.
Gather the Following Data
1. An operating system (OS) copy of the Busytime.nsf/Clubusy.nsf database. Note that for clustered servers the database is called Clubusy.nsf.
2. An OS copy of the mail file or Resource Reservations database.
3. An OS copy of the Domino Directory.
4. Any logged output that relates to the problem (missing entries, entries that do not belong, etc.).
- Debug results
- Console log results from the Tell Sched commands in section II. above.
|