Lotus Domino Administration 8.5.3 Training

Click the Below link for Lotus Domino Admin video Training

lotus-domino-administration-853 Training

Lotus Sametime users with different 'home' servers cannot see each other online

I am new to Notes/Domino and Lotus Sametime. I noticed that users with different "home" Sametime servers cannot see each other online. I was trying to perhaps develop a plug-in that would provide this functionality. Is there a way to achieve this?

Lotus Sametime users within the same Lotus Domino domain (and even across different domains) can see one another, as long as their "home" servers are aware of the existence of other Lotus Sametime servers through a "Community."

To ensure that your servers are aware of one another, create Sametime connection documents in both directions (i.e. Server A -> Server B and Server B -> Server A) using the Domino administrator client.

To check whether your Lotus Sametime servers can see other members of the community:

1. Open a Web browser, go to the Sametime Web Administration Utility (http://yourserver/stcentre.nsf and choose the "Administer the server" link).
2. Expand the "Configuration" heading and then choose the "Connectivity" option.
3. When the "Configuration - Connectivity" page opens, click the "servers in the Community" tab.
4. If you see both Server A and Server B under the "Meeting Servers that are connected" section, your servers should be able to communicate with one another.

To create the Lotus Sametime connections:

1. Start your Domino administrator client.
2. Go to the Configurations Tab.
3. Expand the server's Twistie and choose Connections.
4. On the Action Bar, choose "Add Connection," make the connection type "SameTime," complete the Source (Server A) and Destination (Server B) server fields, and add an optional network address for the destination server.
5. Now add another connection document going in the other direction.

Sametime connect list disappeared

Using a 6.5.1 client, and logging into Sametime, the connect list has "disappeared." It will not show up on the client. However, if you use the Sametime connect client, the connect list will show up there. We are operating on XP.

I have seen this occurring when the Sametime server utilizes LDAP authentication, rather than Domino authentication to log-in.

If you are using this configuration, change the connection settings in your location document from "Automatically" to "Manual," disconnect from the Sametime session and try to log in again. In the username and password window, try either your short name (as specified in the Domino Directory) or your e-mail address, in conjunction with your Internet password.

As an example, rather than logging onto Sametime through Notes as "Mathew Newman/iteam," try either "mnewman" or "mnewman@iteam.com."

How to enable communication between multiple Lotus Sametime servers

In our Notes/Domino organization, we have set up a primary and secondary Lotus Sametime server. The primary server is a Notes/Domino server and is set as a standalone machine. The second server is on a separate Notes/Domino server, and was set as a member of the primary server at the time of installation.

Clients of the primary Lotus Sametime server are only able to communicate with members of the primary server. Clients of the secondary server are only able to communicate with members of the secondary server.

We would like to enable communication between multiple Lotus Sametime servers. For instance, we'd like a member of the primary server to be able to send messages to a member of the secondary server. We were not able to add users from the primary server to the secondary server or vice versa.

How can we add members of the secondary server into the contact list of members of the primary server?

The easiest way to confirm that your Lotus Sametime servers are members of the same community is to check the "Community" settings in the Lotus Sametime Web administration client.

1. Open a Web browser, go to the Sametime Web Administration Utility (http://yourserver/stcenter.nsf and choose the "Administer the server" link), expand the "Configuration" heading and then choose the "Connectivity" option.
2. When the "Configuration - Connectivity" page opens, click the "servers in this community" tab.
3. If you see both the primary server and secondary server under the "Meeting Servers that are connected" section, your Lotus Sametime servers should be able to communicate with one another.

I'm going to go out on a limb here, and suggest that you will not see both servers in this section. From the description of your setup, I'm guessing that your infrastructure is that your primary server is on one machine and your secondary server is on a separate machine.

But from what you have indicated, both servers are members of the same Lotus Domino domain ("member of the primary Sametime server at the time of installation"). This means that the servers already "trust" one another -- being members of the same organization. They are therefore able to see all servers and users within the domain, because the Sametime servers share the same Domino directory.

Side Note:

A Domino domain is a collection of servers and users who share the SAME Domino directory (names.nsf/ Public Address Book, etc). An organization is a security mechanism for creating and identifying entities (servers/users) within the Lotus Domino domain.

If both servers are members of the same Domino domain, then you simply need to create a Sametime connection document in your Domino directory, similar in the way to creating a replication connection document.

1. In your Domino Administrator client, go to the configurations tab, expand the Server's Twistie and then choose "Connections."
2. On the Action Bar, choose "Add Connection", make the connection type "Sametime", complete the Source (Primary server) and Destination (Secondary server) server fields and add an optional network address for the destination server.
3. Add another connection document going in the other direction.

Give your system a little while to detect the new configuration, and you should see both Lotus Sametime servers listed as "Connected."

If your servers are not part of the same Lotus Domino domain, then you will need to do a little more work:

1. Cross certify the two servers , so that the servers trust one another.
2. Configure Directory Assistance on both Lotus Sametime servers, so the servers can access one another's directories.
3. Create the Lotus Sametime connection documents described above, so the Lotus Sametime servers can communicate.

Enabling a Domino server to host Sametime applications

From "The ABCs of enabling Notes and Domino applications with Sametime," by John Fiola, consultant, Lotus, which originally appeared in the Sept./Oct. edition of The View.

If you choose to host Sametime-enabled Notes applications from a Sametime server, no special server setup is required. The Sametime server can be installed on Windows NT.

If you want to serve Sametime-enabled applications from a Domino server, you will have to do the following:

1. Install the Sametime server. When you install the Sametime server, three databases are created that are used for deploying Sametime applications: the Secrets database (StAuthS.nsf), the Tokens database (StAuthT.nsf) and the VPUserInfo database (VPUserInfo.nsf).

The Tokens and Secrets databases handle authentication and log in to the Sametime servers for the users of a Sametime-enabled application.

The VPUserInfo database stores information used to restrict whom a user can see or who can see the user. This information is configured with the Connect client. Restrictions apply to both the Connect client and to applications through which the user may connect.

2. Replicate databases to the Domino application server. The Secrets database and the Tokens database must be replicated from the Sametime server onto the data directory of the Domino server, maintaining the same file names as on the Sametime server.

Unlike the Secrets database, the Tokens database doesn't have to be regularly replicated to the application server, but it is recommended that you replicate it at least once. The file names must be maintained because the Sametime agents have these file names hard-coded into them.

The VPUserInfo database does not need to be replicated onto the Domino application server. Access restrictions will be checked when the user logs in to the Sametime server.

Once a Domino application server is Sametime-enabled with the Tokens and Secrets databases, it can host multiple Sametime-enabled databases. You do not need to put new replicas of the Tokens and Secrets databases onto the application server each time you create a new database.

No one can see Lotus Sametime user is online

When one of my users logs onto Lotus Sametime instant messenger, it shows her as online to herself -- but she sees no one else online and no one can see her. She is not set up to block any other users. We tried rebooting the Lotus Sametime server with no luck. Do you have any suggestions?

1. Open the "VPUserinfo.nsf" database located on your Lotus Sametime server and locate the record for your user.
2. Check to see that there is only one instance of this user in the Sametime VPUserInfo database.
   I have seen instances where even though the records should be stored in canonical format, a user has had multiple Lotus Sametime records that confuse who is actually logging in, and what their individual settings are.
3. Delete the record(s) for this user. I should warn you though that, there is a side effect -- the user will lose the buddy list they have created.
4. Log the user into your Lotus Sametime server through the Sametime Connect client or Browser Connect client. The user should have a new (blank) buddy list.
5. Check the user's Lotus Sametime configuration by choosing the "Options" menu, and then "Who can see if I am online."
6. Make sure the setting is "Everybody can see if I am online." Add a new person or group to the Sametime buddy list, and then check to make sure the user can chat normally.

Find out the number of users who have logged onto the server using a Web browser

 have the following query regarding Lotus Domino :- Situation : - Users access a Lotus Domino Server using HTTP ( Browser Based Access) for accessing mails and workflow applications developed in Lotus. Requirement :- To find out the number of users who have logged onto the server using a Web Browser) Note:- The SHOW USER Command Gives only the number of users who are accessing the server using LOTUS CLIENT and does not show the number of users logged in using the WEB BROWSER. 

You must have session authentication (single or multi-server) enabled on the server. Then issue the command ?tell http show users? with a live console running. I would also turn on logging for HTTP. I prefer the text log files as opposed to domlog.nsf. You can use any free/shareware log analyzer to break down the numbers with the text logs. 

Bulk replication and commands

Create a text file that saves you typing multiple commands. A text file with console commands written one after the other on separate lines can be saved to the Domino directory. From the console simply type < textfile.txt. That is Less Than a space then the file name. Domino then enters the commands in that order. Great for forcing replication of the names.nsf and Admin4.nsf.

Redirecting Web Users to Any Database

This technique will allow you to "point" Web site users at any database on your server without having to type in any of the subdirectory names that you would normally have to use to get to your Domino Web pages by simply creating a text file using whatever editor that creates system compatible text files (such as NotePad if you are using a Windows-based server). In this text file you enter in the full file-system path of the database you want to point to and then save this file in your Domino/Data directory and give it a file name which includes a file suffix of .NSF. (Yes, that's right. You are creating a text file and using the exact same file suffix as if it were a Domino database. I know it sounds weird, but it works).

So, you have a Domino database on your server and the fully qualified file name is: D:\R5\DATA\ACCOUNTING\TOP\THISWEB.NSF

You can create a text file called SITEA.NSF, enter the above fully qualified file name into the file, and DO NOT ADD a carriage return at the end of that line. Save that text file into your D:\R5\DATA directory.

Now, Open your browser and enter a url that includes that new file you just created:

HTTP://EREHNKE/SITEA.NSF

If you got it right, you will be launched into the THISWEB.NSF database and you URL line won't even give it away.

Is that cool, or what? According to the Domino.Doc Administration manual, this "trick" has another benefit.

You only need to authenticate with the server ONCE. Not several times as it sometimes requires.

How to move Notes databases off Domino 8 servers and save disk space

There is an easy way to free up disk space on Domino 8 servers without losing data or references from your Lotus Notes Workspace or Bookmarks. Suppose that your Notes databases (.nsf files) are growing too large and you're running out of space on a Domino 8 server, but you cannot delete old documents.

One solution is to move these databases to file servers or a SAN device. However, if you move your Notes databases off the server, how will your users access these files? By default, they can't. Use this workaround to enable users to access files stored off your Domino 8 server.

Using Domino Directory Link (Dirlinks) -- Folder Links -- in the Administration client can solve this issue. In older versions of Domino, you could create a text file with a .dir extension and place your full path to the data. Then, all you would have to do is create this within the Administration client and Domino does all the work. Users still have access and you can store data on an inexpensive storage medium.

Once you've moved your data from your Domino server, follow these steps:

1. Open the Lotus Notes Administration client.
2. Go to the Files tab and select Domino\data directory.

3. On the right side of your window, expand Tools and then Folder.

4. Choose Create New Link.
The link name will be the name as the folder in which your data exists. This is also the name of the folder you want to see when you click onFile\Application(Database)\Open.

Note: F:\archive data is a drive that I've setup at the OS level that takes me to my storage location. Be sure that the ID the Domino Service is running under has rights to this storage location.
5. Click OK .
6. To view your data, click on File \Application(Database)\Open, then switch to your Domino server and click on the folder you have just created.

Notice a radio button for Database in Step 4. This option allows you to create a Database link and move one individual database from a Domino\data location to another Domino\data location or to a non-Domino device.

What is Notes 8.5's DAOS (Domino Attachment and Object Storage) feature?

The release of Lotus Notes 8.5 introduces a new administrative feature called Domino Attachment and Object Storage (DAOS). In this article, contributor Mike Kinder explains what DAOS is, its different components, some requirements and caveats and why DAOS is important to your Notes 8.5 environment.

---

At Lotusphere, Paul Mooney and Gabriella Davis, led a session that covered three new administrative features in Lotus Notes 8.5: ID vault, DAOS, and roaming.

Paul Mooney presented on DAOS and let me use his presentation as a guide to summarize this new feature in Notes 8.5. To view the full presentation, visit Paul's website.

What is DAOS?

DAOS -- Domino Attachment and Object Storage -- is a process that is separate from Lotus Domino, but works with it, to remove attachments from documents. The process replaces the attachments with a "ticket" in the document. The ticket references the attachments that were originally contained in the documents; the attachments are then stored in Domino server's file system.

Note: The documents can be from any type of database, not just the mail database.

DAOS consists of four different components:

• DAOSManager -- DAOS Manager is the focal point of the DAOS feature; it runs under and separate from the Domino server.
• NLO -- NLO is the new file extension of any attachment the DAOSManager handles from a database. For security reasons, Lotus didn't copy the attachment and use its own extension. It's also important to note that it is an encrypted version of the attachment. The server's ID file encrypts the attachment. This does, however, create some of the following caveats.
• DAOS Catalog -- This is a Lotus Notes database that contains a list of the NLO files and their references. The DAOSManager process reads this database for information related to attachments it's managing.
Note: This database cannot be accessed by anyone directly. You will receive an error if you try.
• Tickets: These are the references that remain in the rich-text fields of Lotus Notes documents where DAOS removed attachments. They are used to reference the appropriate NLO files for that document.

Why should I care about DAOS?

The most obvious reason to run DAOS is the disk savings, especially in a mail environment where many attachments are exchanged. This has a domino effect where backups are smaller and backup times are shortened. Less resources are also required for backups.

What is required to use DAOS?

• Lotus Domino 8.5 server
• DAOS only works against attachments, not embedded objects.
• Space on a server where the attachments can be stored.
• Any database that DAOS manages must use the new ODS 5.1.
• Any database that DAOS manages must be transactionally logged.
• Any database that DAOS manages must have the new database property for DAOS enabled and then compacted.
• Any database DAOS is manages must be an NSF, as it does not support NSFDB2 databases.

Does DAOS have any special configuration options?

Fortunately, DAOS is not something that you turn on and then have no control over. DAOS lets you control how big an attachment must be before it removes it from a document and moves it to an NLO file. It also lets control other things such as how long an NLO file stays around after all tickets have been removed.

There are also new server console commands related to the DAOSManager process (called DAOSMGR), and new features of other server commands. For example, compact has new arguments related to enabling DAOS, namely "load compact mail\mailfile.nsf –c DAOS on."

Caveats to be aware of before implementing DAOS

There are also some things that must be aware of before implementing DAOS:

• Your backup process must change. When attachments are initially stored in the OS, the directory of NLO files needs to be backed up, in addition to the databases on the Domino server that you were backing up before. When performing the backup, it's a good idea to back up your databases first, then the NLO files.
  If you back up the NLO files first, but a new message comes in with an attachment later, it is possible that the email would be backed up, but the related NLO would not.
• If copying/replicating a DAOS-managed database from one server to another (or to a client) where DAOS is not enabled, the attachments are re-added to the NSF, so it will be much larger. Make sure that the new destination has the necessary disk space to handle the database with all of the attachments added in.
• NLO files should not be copied (at the OS level) from one server to another. The files are encrypted by the Domino server ID. If they are moved to another server where a different server ID file is used, the NLO files are useless.

What do you do if you need to move a DAOS-enabled database from one server to another server to make it DAOS ready? You don't need to do anything, just use the Admin client to create a copy/replica. DAOS and Domino will do the rest. They add the attachments back onto one server and remove them from the other server.

Lotus Domino 9 Server Installation and Configuration

Please contact at Lotusnotes.kiran@gmail.com for Complete set of Course Videos

Setting up authentications on your Lotus Domino server

For Domino organizations to be capable of exchanging data, they must share a common certificate. This is accomplished by using an organization certifier ID file. Cross certifying a user or server ID with an organizational certifier guarantees that both IDs have a common certificate. Domino uses two types of certifier IDs related to organizations:

• Organization certifier ID: The default name for this ID file is CERT.ID. This ID file is created when the server is deployed. This ID typically includes the company name and is the highest point on the hierarchy tree.
• Organization unit certifier IDs: This level of organizational certifier is typically used to delineate the next level on the hierarchy tree, usually identifying county or department names.

Creating a new organization certifier ID

To create a new organization certifier ID, follow these steps:

1. Using the Administrator client, select the Configuration tab and open the Tools pane. Select Registration, and then click Organization from the menu; the Register Organization Certifier dialog box appears.
2. Enter the organization name and choose a country code (the latter is optional).
3. In the Certifier Password field, enter a new password that will be required when certifying IDs for the new organization.
4. Use the Password Quality slider to determine the quality of password security to assign to the ID file. The default location of the slider is to the extreme left, which is no password and a value of 0. Sliding the bar to the extreme right forces a very strong password and a value of 16. Although it is true that this is optimal for servers, each time the server is loaded, a password will be required at the console before the server will start.
5. In the Security Type field, choose North American or International.
6. In the Mail Certification Requests To field, choose Administrator.
7. Optionally, add a location and comments.
8. Click Register to create the new certifier ID.

Creating a new organizational unit ID

To create a new Organizational Unit ID, complete these steps:

1. Using the Administrator client, select the Configuration tab and select the Server document for the server to be recertified.
2. Open the Certification menu selection under the Tools pane and select Organization Unit; the Register Organization Certifier dialog box appears.
3. Click the Server button to select the Registration server and click OK. You are then presented with two options:
   • Supply Certifier ID and Password: A file navigation box appears when this option is selected. Navigate to the required certifier ID and select OK. If you choose this option, go to step 4.
   • Use the CA Process: This option allows the administrator to recertify the ID without having access to the certifier ID or the certifier password. A drop-down box is provided to allow the administrator to select a CA-configured certifier from the ones available on the server.
4. If you chose Supply Certifier ID And Password in step 3, a dialog box appears requiring the certifier password. Enter the password and select OK; the Register Organizational Unit Certifier dialog box appears.
5. Select the registration server, and then select the certifier ID.
6. Select Set ID file to define the location for the new certifier ID being created.
7. Complete the Organizational field by entering a name for the new Organizational Unit.
8. Complete the Certifier password field by entering a new password.
9. Use the Password Quality slider to determine the quality of password security to assign to the ID file. The default location of the slider is to the extreme left, which is No Password and a value of 0. Sliding the bar to the extreme right forces a very strong password and a value of 16. Although it is true that this is optimal for servers, each time the server is loaded a password will be required at the console before the server will start.
10. In the Security Type field, choose North American or International.
11. In the Mail Certification Requests To field, choose Administrator.
12. Optionally, enter a location and/or comments.
13. Click Register to create the new ID file.

Using the Domain Search tool on your Lotus Domino server

Domino provides the ability to search for files across multiple servers using a tool called Domain Search. Database information that is searchable includes documents, files, and file attachments.

Setting up Domain Search requires a server to be designated as the indexing server. This server creates a master index that contains all of the results from search queries run in the domain. The database that is used by Domain Search is Domain Catalog. The databases in the domain are then searched by the indexing server using a search spider. Based on the size of the domain, this task could take a few hours, a few days, or a few weeks.

Indexing is an intensive task and proper consideration should be taken to make sure that the indexing server is adequately configured to handle the work. Multiple processors, disk arrays with high-speed access, and large amounts of RAM are recommended for the indexing server. Lotus recommends a dedicated indexing server if more than six servers in the domain will be participating in the Domain Search, but use this as a "rule of thumb" only based on the configuration of the domain. When a user's search is performed, the indexing server accesses the Domain Catalog and returns search results that are valid based on the user's access restrictions.

When setting up the Domain Search program, set the search spider to run at a time when server use is low, typically at night.

Follow these steps to set up the Domain Search:

1. Create the Domain Catalog on the indexing server. Create a new database using the CATALOG.NTF as the database template.
2. Using the Domino Administrator, open the Configuration tab and select the server to be used as the indexing server. Click Edit Server to open the Server document.
3. Navigate to the Server Tasks tab, choose the Domain Indexer tab, and select enabled for the Domain Catalog field. In the Limit Domain Wide Indexing to the Following Servers field, select the servers to add to the search.
4. Click Save & Close to save the document.
5. This task requires a server restart before it starts. Restart the server when possible and then verify that the Directory Indexer task has started by issuing a show tasks command at the server prompt.

Recertifying a Lotus Domino server ID

Periodically, certificates associated with a server ID expire. When this occurs, the ID needs to be recertified. To recertify a server ID, the administrator must have either Author access to the Domino directory and the ServerModifier role assigned or Editor access to the directory. In addition, the administrator must have Author access or greater to the certification log. The following steps allow a server ID to be recertified:

1. Using the Administrator client, select the Configuration tab and select the Server document for the server to be recertified.
2. Open the Certification tab under the Tools pane and select Certify; the Choose a Certifier dialog box appears.
3. Click the Server button to select the Registration server and click OK.
4. In the Registration Server dialog box, choose an option to determine how you will register the server. The options include
   • Supply Certifier ID and Password: If you choose this option, a file navigation box appears. This option is used if a certifier ID is used to authorize access to the domain. Navigate to the required certifier id and select OK.
   • Use the CA Process: This option allows the administrator to recertify the ID without having access to the certifier ID or the certifier password, by using a Certificate Authority (CA), instead. If you choose this option, use the drop-down box it provides to select a CA-configured certifier from the ones available on the server.
5. After you've selected one of the two options, click OK. If Supply Certifier ID and Password is chosen, a dialog box appears requiring the certifier password. Enter the password and click OK to continue.
6. A file navigation box appears prompting for the ID to be certified. Select the server's ID file and click OK; the Certify ID dialog box appears.
7. In the Expiration Date field, choose a setting to determine when the server will need to be recertified. The default time is two years, but can be changed as needed.
8. In the Subject Name List field, type a common name for the ID if desired (this field is optional). This is used to identify the user in the Directory.
9. In the Password Quality field, use the slide bar to determine the quality of password security to assign to the ID file. The default location of the slider is to the extreme left, which is No Password and a value of 0. Sliding the bar to the extreme right forces a very strong password and a value of 16. Although it is true that this is optimal for servers, each time the server is loaded, a password will be required at the console before the server will start.
10. Select Certify to continue and recertify the ID; a dialog box appears asking if the administrator wants to certify another ID.
11. Select Yes to certify more IDs or No to exit the certification process.

Implementing directories on your Lotus Domino server

Domino provides multiple options when presenting directories in the domain. The key point to remember is that the Domino Directory is accessed by all users as well as servers, so care should be taken to ensure that user and server access is optimized for the best throughput. Three ways to provide directory access are:

• Distributed: This method assumes that each server has a replica copy of the directory on each server in the domain. This method is optimal when many users are on the network or the communications infrastructure may have many points of congestion.
• Centralized: This method uses the administration server as the central point for the directory and configuration directories. Configuration directories host Server, Connection, and Configuration Setting documents. Typically, a second server also has these directories for disaster recovery purposes in the event that the registration server fails.
• Hybrid: This method uses a combination of distributed and centralized. Local users may use the centralized directory, whereas remote users would have a local copy of the directory on their server so that bandwidth would not be an issue.

Identifying a registration server on your Lotus Domino server

Domino uses a Registration server to define changes made to the Directory and then replicates the changes to all Lotus Domino servers in the domain. By using a single instance of the Directory for all changes, consistency is maintained throughout the domain.

A registration server is defined using the Administrator client. To do so, follow these steps:

1. Click the File menu and select Preferences.
2. Select Administration Preferences from the submenu.
3. From the available selections, click Registration. This tab allows an administrator to select a registration server.
4. Select the Registration Server button.
5. Select the server to be used as the registration server and click OK. Click OK again to close the Administration Preferences dialog box. The registration server is now set.

Enabling transaction logging on your Lotus Domino server

Transaction logging is available for Lotus Domino servers running release 5 or later and databases using release version 5 or later On Disk Structure (ODS). Database changes are sent to a transaction log database and then written later to the target database. Transaction logging offers benefits for the following system activities:

• Backup throughput is increased because transaction logs back up quicker than normal databases.
• Disaster recovery is more complete in that data that was stored in the transaction log can be supplemented to the full system recovery so data is not lost. Data that is stored in the transaction log file is written to the database when the log file is recovered from tape.
• Database views are stored in the log file so database views may not need to be rebuilt.

Transactional logging also creates a unique database instance ID (DBIID) for each database. When transactions are added to the log, the DBIID is assigned so that the source database can be recorded. DBIID tags are assigned at the following times:

• The first time transaction logging occurs.
• In some instances when the Compact task is executed, such as reducing file size.
• When fixup is used to correct a corrupted database.
• When a database is moved to a server using transaction logging.

Transaction logging versions

You can choose from three different versions of transaction logging, including Circular, Linear, and Archived. Here are descriptions of each of these transaction logging versions:

• Circular: This version of logging uses up to 4GB of disk space and then begins writing over the oldest log information in the database. The transaction log database should be backed up daily using this deployment version.
• Linear: This version of logging is similar to circular logging, but can use more than 4GB of disk space.
• Archived: This version of logging creates transaction logs as needed. Log files are not overwritten; they are archived. Ensure that the logs are being backed up regularly or the server might run out of disk space.

Implementing transaction logging

Transaction logging needs to be properly planned before it can be implemented. Steps to complete before implementing transaction logging include:

• Make sure the server hardware is properly configured. Use a disk array with at least RAID 1 support and a dedicated disk controller.
• Define a backup plan and use software that supports Domino servers running transaction logging.
• Plan to use logging on all available databases, but remember that only databases using the R5 ODS or later will be able to use transaction logging.
• Decide which version of logging to use (Circular, Linear, or Archived).

To set up transaction logging on the server, follow these steps:

1. Using the Domino Administrator, select the Configuration tab, select the Server document, and then click Edit Server Document.
2. Select the Transactional Logging tab.
3. In the Transactional Logging field, select either Enabled or Disabled.
4. In the Log Path field, enter the explicit path to the transaction log database.
5. In the Logging Style field, select either Circular, Linear, or Archived.
6. The default selection for the Use All Available Space On Log Device is No. If you use the default selection, in the Maximum Log Space field, enter the amount of space in megabytes to be used for the transaction log database.
   If you select Yes in the Use All Available Space On Log Device field, the next option, Maximum Log Space, is removed as a valid selection.
7. Choose Enabled or Disabled in the Automatic Fixup Of Corrupt Databases field. If Automatic Fixup is not enabled, administrators will need to manually perform database maintenance when errors occur.
8. In the Runtime/Restart Performance field, choose from the valid options in the drop down menu: Favor Runtime, Standard, and Favor Restart Recovery Time.
9. In the Quota Enforcement field, choose from these valid options:
   • Check Space Used in File when Adding a Note
   • Check Filesize when Extending the File
   • Check Filesize when Adding a Note
10. Select Save & Close to start transaction logging.

Enabling protocols on your Lotus Domino server

Your Lotus Domino server supports various protocols that are enabled on the Ports tab of the server document. The following protocols can be enabled:

HTTP: Used for Web access.

• IIOP: Used to allow Java code to run on the server.
• LDAP: Used for addressing services.
• POP3: Used to access Internet mail, typically used by clients such as Netscape Navigator.
• IMAP: Used to access Internet mail, typically used by clients such as Microsoft Outlook.
• SSL: Used to provide data encryption and security.

Select a protocol based on the intended use when changing the Server document settings.