Get started Bring yourself up to speed with our introductory content.

What are settings documents?

Learn and understand everything about settings documents including setup, registration, and primary usage as well as how to inherit and enforce settings documents.

What are setting documents? There are five primary types of settings documents:

  • Setup

  • Registration

  • Archive

  • Desktop

  • Security

Each type of document serves a unique purpose and is utilized at different points in time by the Lotus Notes client. In some cases, the settings are applied one time, such as during the installation of the Notes client, whereas others are dynamically applied. Using dynamic settings, the configuration settings are "refreshed," so to speak, each time the user accesses his Notes client. As you consider the configuration settings, you'll need to organize them in accordance with the various types. These policy documents consist of the types shown in Table 1.

Document Type Document Description Primary Use
Setup Controls the settings as new users are registered as well as general preferences for the Notes client. Settings are applied only one time during the installation of the Notes client.

Changes to the Setup document do not affect clients that have already been installed.

Most of the configuration options in the settings document are also included in the Desktop settings document.

Location documents

Browser default


Proxy settings

Registration Controls the registration settings of users.

Settings are applied only one time during the registration of the Notes client.

Changes to this document do not affect clients that are already connected and currently using the Notes client.

Mail template default

Certificate expiration

Internet mail address format

Archive Controls the archive settings for the user's mail database.

This policy document allows you to enable or disable archive and to control settings from a server or user perspective.

Notes client-based archive of folders

Server-to-local-based archive

Server-to-server-local-based archive

Desktop Controls the user's Notes client desktop and environment settings.

These settings are dynamic and are applied to the Notes client each time the user starts the client.

Default bookmarks


Welcome page

Security Controls the password settings; that is, length, expiration, and creation requirements.

This settings document also manages execution control list (ECL) settings and the synchronization of Internet and Notes passwords.


Security settings

Table 1. Types of Settings Documents

As you research and identify the settings to be implemented, you will need to organize them into one of these policy documents. One method is to start by determining the various user groups and then decide on the settings that should be applied to each group. Once you know the groups and settings, you can create a policy with one or more settings.

Note: Policy documents were introduced in Lotus Notes version 6. Prior to the presentation of policy documents, Lotus Notes 5 utilized "setup profiles." As a best practice, eliminate the use of setup profiles and convert them to policy documents as you migrate to version 6 or later of the Notes client.

If you are running a mixed environment consisting of version 5 and higher-level clients, the policy document will only apply to those users running version 6 or higher of the Notes client. Until all version 5 clients are upgraded, you will need to maintain both setup profiles and policy documents.

Understanding each type of settings document is fundamental to implementing a policy-based system for administration of client settings. Let's take a deeper look at the relationship between the policy and settings documents as it's important to understand the configuration options for both of these documents (see Figure 1).

Figure 1. A policy document contains a number of settings that you can apply to the client environment to ensure consistent implementation across the company.

Setting relationships: As previously stated, each policy document includes a number of settings. These settings are hierarchical in nature and can be implemented in a parent-child-like relationship. In this type of relationship, there is a parent or primary document that has one or more subordinate documents. The parent document setting always takes precedence and overrules a child setting. These policy documents can then be assigned to users or groups. Using this approach you can apply top-level settings across the organization and unique settings based on the group.

Inherited/Enforced settings In addition to the parent-child relationship you can also Inherit and Enforce settings within the policy hierarchy.

An Inherited Setting is one in which the setting is automatically obtained based on another policy document. This keeps settings consistent from policy to policy.

An Enforced Setting is one where the parent document always overrules the child setting. Enforced settings are typically implemented when you want to implement a consistent setting across the organization. That said, here's how they are applied:

  • An inherited setting can only be used or implemented in a child settings document. When the Inherit option is selected, the child policy document takes the setting from the parent policy document.
  • If a child settings document contains a value and the Inherit setting option is selected, then the child setting is ignored and the parent policy setting takes precedence.
  • An enforced setting can only be used or applied at the parent policy level. When selected, the parent policy setting is enforced and the child setting is ignored (if one has been specified).
  • If a parent policy document has one or more child policy documents and neither the Inherit nor Enforce option has been selected, then the child setting takes precedence over the parent setting in the event of a conflict between settings.
  • When multiple child-level policies are associated with a parent policy, the top-level (or first) child policy document has precedence over sibling policy documents in sequential order.

Table 2 shows how these rules are applied. It illustrates the parent-child relationship and the setting that will be implemented based on the Inherit and Enforce setting. The first column shows the parent document value. The second column shows the child document value. The third column represents how Domino manages these settings, based on the Inherit and Enforce setting, and the value to be implemented.

Parent Document Setting Child Document Setting The Implemented Setting
Setting A (No setting specified) Setting A (Parent Value)
Setting A Setting B, Inherit Setting A (Parent Value)
Setting A, Enforce Setting B Setting A (Parent Value)
(No setting specified) Setting B Setting B (ChildValue)
Setting A Setting B Setting B (ChildValue)

Table 2. Inherit and enforce value precedence

Note: Lotus has issued a technical bulletin regarding the implementation of policy settings when using the Inherit and Enforce options. This bulletin, entitled "Policy settings not being applied correctly," provides additional information on how policies are applied when the Inherit and/or Enforce options are selected and a child document exists. To review this technical note, visit the IBM Lotus website

Now let's review each of the policy documents. After reviewing the documents, you'll learn how to set up and configure these documents.

Archive Policy Document: The Archive document, as the name implies, is used to manage mail archive settings for the organization. Implementation tends to vary from company to company. Some choose to set up an archive policy whereas other companies rely on third-party software or the employee to archive mail to another medium (such as compact disc, shared network drive, or flash drive). Regardless of the method, you'll probably want to implement some method or process to manage archiving. Conversely, if you're working with sensitive information you might also want to disable the ability to archive information. When working with the Archive document, you'll want to have a clear understanding of and be able to answer the following questions:

  • Should documents be archived?
  • Which documents should be archived?
  • When should documents be archived?
  • What happens to the documents after being archived?
  • Using the Archive policy document you can fine-tune the archive process. The numerous settings allow you to:

    • Enable or disable archiving
    • Specify the location of the archive - server or local.
    • Determine the archive selection criteria.
    • Record or log archive history.
    • Schedule the frequency in which archiving will occur.
    • Define what action to take after the document has been archived.

    The combination of these options offers great flexibility in the setup and administration of the archive process. Archiving works by removing mail files that meet certain criteria, such as date or age of the document, into a separate database. This subsequently frees up storage space and data management costs on both the server and the user's workstation.

    The Basics Tab: Let's start with the Basics tab where you specify a name and provide a brief description of the Archive document. From here you can enable or disable the archive process and define the source and destination settings for archived documents. Table 3 describes the various fields of the Archive Policy.

    Field Name Description
    Prohibit archiving A universal setting to completely prohibit all archiving.
    Prohibit private archiving criteria Disables the ability for users to define separate or private archive criteria.
    Archiving source database The source location of the database to be archived. Archiving can occur at the server level or at the user (or local database) level.
    Destination database The destination location for where to store all archived documents. Here you can elect to archive documents to a local workstation, Domino server, or mail server.

    Table 3. Basics tab field descriptions

    The Selection Criteria Tab: On the Selection Criteria tab, you must specify one or more rules to govern what documents are archived. Multiple rules can be established. This allows you to create multiple archive settings documents to manage how and which documents are archived. For example, you might have a rule to manage the server-based archives and another for client-based archives. When taking this approach, you will need to create new selection criteria and then add them to the archive settings document. Table 4 outlines the fields associated with an archive rule.

    Field Name Tab Description
    How should documents be archived Basics Administrators have the choice to "copy old documents into the archive database and then clean up the database" or to simply "clean up the database."
    How should documents be cleaned up Basics When cleaning the database you can either "delete the document from the database" or "reduce the size of the document" to around 40k in size. If you decide to implement the "40k" size restriction, the email will be trimmed to 40k. Any character that exceeds this threshold will be removed from the user's mail database. In other words, a partial message will be displayed. However, users will be able to view the entire message in the archive database.
    Which documents should be cleaned up Basics Allows users to define which documents are archived based on the age or expiration date of the document.
    Archive Directory Destination The destination tab allows you to set the default archive database filename and directory. The default directory path and name is "Archive."
    Archive Prefix Destination A prefix can be appended to the filename to signify the database is an archive.

    Best practices recommend using "a_" as the prefix for all archive databases.

    Archive Suffix Destination The suffix indicates the file type extension for the archive database.

    You will most likely want to keep the default value ".nsf" to allowaccess from the Notes client.

    Number of characters from the original filename Destination The number of characters that will be taken from the original database and included in the archive database filename.

    For example, if the user's mail filename is "harryjones.nsf" and the value is set to six characters, then the archive filename would be "a_harryj.nsf" when using the default values.

    Table 4. Selection criteria tab field descriptions

    The Logging Tab: The Logging tab in the "Archive settings" document allows you to record the history or log file information associated with the archive process (see Figure 2). This tab enables you to define whether logging is enabled and the name of the log file database.

    logging tab

    Figure 2: The Logging tab allows you to define if and where to record archiving activities.

    The Schedule Tab: The Schedule tab allows you to schedule when archiving will occur for client-based archives (Figure 3). With this option enabled, you can set the frequency, start time, and day of the week to run.

    client based archives
    Figure 3: The Schedule tab allows administrators to set if and when client-based archives willoccur.

    The remaining three tabs;Advanced, Comments and Administration are self-explanatory and only contain one or two fields. For example, the Advanced tab allows you to set the retention period in terms of years. The Comments tab is a free-form field and is blank by default. The Administration tab allows you to specify the owners and administrators for the document. These are, for the most part, standard tabs.

    Tip: You can find additional information on how to create and manage archive policy settings on the IBM Web site. Manage archive policy settings includes step-by-step instructions and a free video presentation regarding the archive settings. It also includes links to the other settings documents.

    Note: You should consider the performance impact to the Domino server and/or client when establishing an Archive Settings policy. To learn more about the potential impacts, read the IBM technical bulletin.

    Registration Policy Document: The Registration policy document contains settings that are applied as new Lotus Notes users are created. These settings are applied when new users are registered in the Domino Directory and do not apply to existing users who have already been registered. Using this document you can manage the settings for:

    • Home mail server
    • Internet address format
    • Mail database quota size
    • Mail template
    • Password options and settings

    If your company utilizes both the Lotus Notes client and iNotes, you can create a separate registration document for each type of user -- one containing settings for those using the Notes client and another for those who access iNotes through a browser. However, where possible, best practices recommend a single registration document that contains all the settings in a single location. This will simplify management and administration of settings across the organization.

    Having a registration document will also reduce the time and effort needed for setting up new users. Instead of having to add similar information and settings during the "registration" process, these settings will automatically be applied to the new user based on the registration policy document. The policies will be applied in a consistent manner, but will be based on the current settings document. So, changes made to the registration document will not be applied to users that were previously registered.

    There are several ways to create a registration document by navigating to the Settings view located on the People & Groups tab in the Administrator client or by choosing Policies -> By Settings in the Domino Directory.

    Basics Tab: Let's take a closer look at the registration settings document and some of the associated options, starting with the Basics tab (Figure 4). When creating a registration document you first need to provide a name and general description of the policy. You'll also need to specify the Domino server that's used for user registration and the password strength. Optionally, you can also specify to set the Internet password if users will access Notes from the browser.

    registration settings
    Figure 4. The Basics tab of the Registration Settings document.

    Mail Tab: Next, the Mail tab contains three primary sections: Mail user registration options (Figure 5), Internet address options, and Advance Mail options. Start by selecting the mail system type. This option governs what subsequent options are displayed.

    In most cases, you'll want to select "Lotus Notes" as the primary mail system along with the designated mail server. There's also an option to designate a default mail template file. As users are registered, this template will be used as the basis to create their mail database.

    If your company uses consultants who have their mail hosted on another system, it might be beneficial to create a setting that has Other Internet as the mail system. This option can be very useful in organizations with large numbers of consultants.

    archiving tab
    Figure 5. In the first section of the Mail tab you select the mail system, mail server, and default mail template for user registration.

    Note: The Registration Settings document allows you to specify how new mail files will be generated: either "Create Mail File Now" or "Create Mail File in the Background." The default option is to immediately create the mail file. It's important to understand how these options will impact your Domino Administrator client.

    Using the default option, "Create Mail File Now," your Domino Administrator client will be locked (that is, waiting on the hourglass) as the new mail file is generated. If you find the time required to generate the new mail file is longer than desired, you can select the "Create Mail File in the Background" option. This selection will free up your Administrator client and generate the mail file in the background. This setting is especially important for administrators who access the system from a dialup (or non-broadband) connection.

    Tip: You can find additional information on how to create a Mail Settings policy document on the DeveloperWorks Web site. The article, entitled "Creating Mail policies in Lotus Notes/ Domino 7" was written by Timothy Speed and Terry Fouchey. This document focuses specifically on how to for users. Visit manage calendar and mail settings to view this document.

    The Internet Address Options section allows you to apply a consistent format to the Internet address (Figure 6). There are multiple format options. You should give careful consideration to the format so that a consistent format is established from the onset of the user registration process. You can also specify the delimiter that will be used to separate values, such as the "dot" or "underscore." For example, the Internet addresses could be [email protected] or [email protected]

    archiving tab
    Figure 6. The Internet Address Options section enables you to apply a common address format to all newly registered users.

    The last section of the "Mail tab" contains the Advanced Mail options (Figure 7). This section enables you to set the default access level of the user for the mail database, establish a full text index, set a database size quota, and set the warning threshold as users approach the size quota. At a minimum, you should consider which users will have the Manager, Designer, or Editor authority to the mail database.

    mail options
    Figure 7. The Advanced Mail Options section of the Mail tab allows you to set the default access, index, quota, and threshold value pertaining to the user's mail database.

    By default, users will be granted Editor access to their mail database. Alternatively, you can select Designer or Manager access. Users who have Editor access will be able to create, modify, or delete any document created in the mail database. Users with Designer authority will have the ability to perform the same actions as Editors plus the ability to modify the design of the mail database, but they cannot modify the ACL permissions.

    Finally, users with Manager access can perform all the same transactions available to lower access levels, plus they have the ability to modify the ACL, encrypt the database design, modify replication settings, and compact and/or delete the mail file database.

    The ID/Certifier Tab: The ID/Certifier tab of the Registration Settings document enables you to specify several key aspects of the users' ID and Certifier, both of which pertain to user ID security (see Figure 8). Start by determining whether an ID file will be created. In general, companies running Lotus Notes clients will want to create and store the ID file. By default this file will be stored in the Domino Directory.

    ID/certifier tab
    Figure 8. The ID/Certifier tab contains security settings associated with the users' Notes ID.

    From an administrative perspective, you'll want to determine the storage location that is most appropriate for your company. Finally, you can set the security type and the certificate expiration date. Using a static date means the ID will expire on a specific date. The default is two years from the date of registration. Alternatively, you can state an arbitrary duration in terms of months for when the ID will expire. These values can affect the employees' ability to access their Notes client. Be sure to review the Domino Administrator online help for supplemental information.

    The Miscellaneous Tab: The Miscellaneous tab contains miscellaneous settings pertaining to groups (Figure 9). Here you can automatically assign users to groups that have been defined in the Domino Directory as part of the registration process. In many cases, no action will be needed here.

    client based archives
    Figure 9. The Miscellaneous tab allows you to add the user to one or more groups as part of the registration.

    The Comments and Administration Tabs: The remaining tabs, Comments and Administration, are straightforward. The Comments tab contains a freeform text field where you can add any personal notes or other information regarding the Registration document. The Administration tab allows you to specify all persons who have the authority to modify the document. Specifically, you can specify the owner and administrators associated with the registration settings.

    Note: You might notice after reviewing the Registration Settings document that some Notes settings cannot be managed from a policy document. Some of these settings include the Unique Organization Unit, Location, Comment, Preferred Language, and Alternate Name Language, just to name a few.

    Dynamic Desktop Setting: The Dynamic Desktop setting (previously called the Desktop policy document) manages various aspects of the Notes Desktop for users. The settings affect all users in the Notes community which is different from the Registration settings document. If you recall, Registration settings only affect users at the time of registration and do not affect existing (already registered) users. However, with the Dynamic Desktop document, these settings are dynamic. Changes to these settings will migrate down to all Notes clients.

    When you open this document you'll notice a rather significant number of options. Some of these options extend beyond the general settings associated with the client desktop.

    The Basics Tab The Basics tab contains general settings associated with the Notes client (Figure 10). As with all policy and settings documents, start by specifying a document name and description in the Basics tab. Next you can optionally specify a default welcome page.

    basics tab
    Figure 10. The Basics tab for the Dynamic Desktop document.

    The Location Options section enables you to control whether users have the ability to create Location documents on their workstation where the Notes client resides. This option, along with countless other options within the document, enables you to control whether users have the ability to modify, create, or change settings from their client application. For example, you can control whether users have the ability to manage "plug-ins," the default Domino server directory, Instant Message server, default browser to launch, and so forth.

    Many readers will find the "Create Local Mail File Replica" option of particular interest. This option allows a local instance of the mail file to be created on a user's workstation. Generally speaking, most administrators will want to enable this option to permit replication.

    In the Mail Template Information section (Figure 11), you choose how to communicate with the user and how mail templates are managed during client upgrades. You can prompt users before upgrading their mail file. This option works in conjunction with the Smart Upgrade. You can also elect to automatically upgrade the design of their custom folders.

    mail template information setting
    Figure 11. Using the Mail Template Information settings you can control how upgrades are applied to users' mail database design.

    The Databases Tab: If you have a common set of databases that all employees should have access to, you can add them in the "Database Links" section of the Databases tab. Drag and drop the database into the "Default Databases Added to Bookmarks" field. All database links will then appear in the user's bookmarks database.

    The Preferences Tab: The "Preferences" tab is another section that you should review when creating a Dynamic Desktop settings document (see Figure 12). By default, users will have the ability to modify some of their settings from the Notes client. By going to the appropriate section in the client preferences, users can modify certain values associated with the Notes client. On the Preferences tab you can define certain default values and settings, or if you do not want users to be able to modify settings, you can disable the ability for users to modify their client settings.

    Tip: A technical bulletin has been issued that describes how to set values in the notes.ini file and Location document using the Dynamic Desktop settings policy. To learn more about how this works, read the technical note.

    preference settings tab
    Figure 12. You can fine-tune the preference settings for the user's client in the "Preferences"tab.

    Initial Desktop Setup: The Initial Desktop Setup (previously called a Setup policy document) is used to control the initial setup settings. These settings are applied as part of the installation process and are applied only one time. You'll also notice that many of the settings found in the Initial Desktop Setup document are also found in the Dynamic Desktop document.

    In fact, the Initial Desktop Setup document is a subset of the Registration document. You can apply the settings once during the initial setup and then manage them long term using the Registration document. Just remember the Initial Desktop Setup policies only apply once during the installation process.

    If you modify the Initial Desktop Setup settings document, the settings will only apply to new software installations that are performed subsequent to the modification. No changes will be applied to existing Notes clients.

    From an implementation perspective, you'll probably want to keep the Initial Desktop Setup document and Registration document synchronized. Or, alternatively, primarily use the Registration document as the primary method for managing client settings.

    The settings specified in the Initial Desktop Setup document will be applied after the client has been installed and connects to the Domino server for the first time. This is the last step in the install process. Once the settings are applied to the client, a pop-up message will appear stating the "Notes Setup Is Complete."

    Tip: You can use the Initial Desktop Setup document to implement mail replicas. If you are considering implementing a standard for mail replicas across the company, you can use the Initial Desktop Setup policy to manage a consistent implementation. You can learn more about how to implement such an approach in the article "Understanding and Implementing Local Mail Replicas for IBM Lotus Notes," by Joseph Anderson and Peter Burkhardt. You can find it at the following DeveloperWorks site.

    Security Policy Document: The primary focus of the Security policy document is password management. You can find the majority of the settings on the "Password Management" tab (Figure 13). Here you can define the settings for three areas -- Password Management, Password Expiration, and Password Quality.

    password management
    Figure 13. Password management should be a key consideration when creating policy settings for the Notes client.

    The first section, Password Management, allows you to determine how passwords are implemented for the Lotus application. Table 5 describes each of the fields along with the default and recommended settings.

    Field Name Description Default Recommend
    Use Custom Password Policy for Notes Clients Uses custom password requirements for Notes password checking. Using custom password parameters enables you to enhance security to ensure they are not predictable.

    An additional configuration tab appears after you change the default value to "Yes."
    This secondary tab allows you to define all the rules a user must follow when generating a password. Some of the settings include:

    • Minimum password length

    • Minimum number of alphabetic characters

    • Minimum number of numeric characters

    • Number of unique characters

    • Allow common name

    • Number of uppercase characters

    • Number of lowercase characters

    No Yes
    Check password on Notes ID file Requires all copies of the user ID to have the same password No No
    Allow Users to Change Internet Password over HTTP Allows users to use the browser to change their Internet passwords. If you do not use the Internet to access Notes, you can set this value to "No." Yes Yes, if iNotes is used. No, if not used.
    Update Internet Password When Notes Client Password Changes Synchronizes the users' Internet password with their Notes client password. No No
    Enable Notes Single Logon with Workplace Rich Client: Allows workplace users to use the same password for Notes and Workplace™ Rich client. Setting this value to "Yes" enables a single logon between the Notes client and the IBM Workplace Rich client. No No

    Table 5. Password management field descriptions

    The "Password Expiration Settings" section allows you to control how long a password can be used and the frequency in which the password must be changed. The default values are set rather loosely and many administrators will want to change the values to enforce a tighter level of security. Table 6 describes the Password Expiration Settings options.

    Field Name Description Default Recommend
    Enforce password expiration Requires password expiration.The default is set to Disabled. As a general best practice, users should be required to change their password on a regular basis.

    WARNING: Do not enable password expiration if smart cards are used to log in.

    Disabled Notes only, Internet only, or Notes & Internet (based on your setup).
    Required change interval The interval in which users must change their password.

    The default setting is one year. Many administrators will want to change the interval to a more frequent basis, such as Quarterly.

    Be careful not to set the interval too low as changing the password on a weekly basis could frustrate users and impede work.

    365 120
    Allowed grace period The number of days the user is allowed to continue using the Notes client after the expiration date has been reached.

    Setting this value to 0 will force users to change their password once their password has expired.

    0 0
    Password history (Notes only) The number of expired passwords to be tracked. The user can only reuse a password after the specified number has been reached. This prevents the user from reusing the same password over and over.

    The higher the number the less frequently a user can reuse the password.

    50 50
    Warning Period The number of days before a password expires to notify the user.

    Notes will automatically calculate when to send a notification if this value is set to a value less than 30.

    Password expiration must be enabled in order to use this field.

    0 0
    Custom warning message If you desire, you can specify a custom warning message to be sent to the users when their password is about to expire.

    This field only applies to the Notes client password.

    Blank This is an optional field setting

    Table 6. Password expiration settings field descriptions

    The final section in the Password Management tab allows you to manage the quality settings. The higher the password quality, the less likely an intruder will be able to gain access via a password.

    When looking at this section, you'll notice there are two fields and approaches to managing password quality, as shown at the bottom of Figure 13. The default approach allows you to select a quality level based on a scale of values. It is called the "Required Password Quality" and is set to "Require Password That Is Difficult to Guess, But May Be Vulnerable to Automated Attack (8)." You can select the password quality that is implemented by clicking on the dropdown and selecting a new value, as shown in Figure 14.

    password quality settings
    Figure 14. The Password Quality Settings area enables administrators to choose the password strength to be implemented across the organization.

    An alternative approach that you can use to set the password quality is based on the length of the password. From an implementation perspective, the password is accepted or rejected entirely based on the length of the password as opposed to the quality of the password. To use this approach, simply select YES in the "Use Length Instead" field and specify a numeric value.

    The Execution Control List tab, starting with release 6, allows you to specify how updates to the Execution Control List (ECL) are distributed to the user. The default values allow Notes to automatically manage the user's ECL. These settings are sufficient for most companies. You can find additional information on ECL administration in the Domino online help database.

    Note: IBM has issued a technical bulletin regarding ECL alerts and custom mail templates. In certain circumstances, users may receive alert messages for the person who signed the Mail template. The Bulletin provides additional information on how to resolve the issue.

    Tip: You might be interested to know there is an IBM Redbook called the "Lotus Security Handbook." This free publication is available online. It provides detailed information on all aspects of Domino security, including Execution Control Lists (ECL).

    Survival guide for Lotus Notes and Domino Administrators

     Home: Introduction
     Part 1: What are policies?
     Part 2: How are policies implemented?
     Part 3: What are settings documents?
     Part 4: What is a policy architecture?
     Part 5: Creating settings and policy documents
     Part 6: Creating policy documents
     Part 7: Registering a new user using an explicit policy
     Part 8: Assigning an explicit policy to an existing user
     Part 9: Using exception policies
     Part 10: Viewing your policy settings

    Survival Guide for Lotus Notes/Domino Administrators This chapter is an excerpt from the book, Survival Guide for Lotus Notes and Domino Administrators, authored by Mark Elliott, published by IBM Press, March 2009, ISBN 0137153317, Copyright 2009 by International Business Machines Corporation. All rights reserved. For more info, please visit the publisher site. Safari Books Online subscribers can also access the book at

    Click here for the chapter download.

    Dig Deeper on Lotus Notes Domino Administration Tools

    • Favorite iSeries cheat sheets

      Here you'll find a collection of valuable cheat sheets gathered from across the iSeries/ community. These cheat ...