Integration for Notes 20.13 - Installation and Configuration of GRIP Subsystem

Create Mail-In Databases in the Domino Directory

Configuration of the GRIP Subsystem takes place in six steps:

1.    Create/Configure the Settings document in the Local GRIP Database

2.    Create Mail-In Databases in the Domino Directory

3.    Define AddUser processing parameters in NOTES.INI for BTCal

4.    Sign the agents in the Local and Remote GRIP Databases

5.    Add Hub Grip Server as Trusted Server on Domino Mail Servers

6.    Disable the manual agents and enable the scheduled agents

Create/Configure the Settings documents in the Local GRIP Database

Configuration of the GRIP system is defined via a series of Settings documents in the Local GRIP Database. To create a Settings document, open the Local GRIP Database on the Domino Coexistence Server (BTGRIPLocal.nsf) and click Create – Settings from the menu bar.

A settings document defines the following information:

Mail Server

This field contains the name of the Mail Server defined by the Settings document. The full Hierarchical Name of the Mail Server must be entered; however, the field may also contain reserved keywords "Default" and "Local". Local is used to define the Domino Coexistence Server. Default is used if a specific configuration document for a Mail Server is not found.

GRIP Server

This field contains the name of the Domino Server which houses the Remote GRIP database that services one or more Domino Mail Servers. The full Hierarchical Name of the GRIP Server must be entered; however, the field may also contain the reserved keyword "SameAsMailServer", which implies the same value as that of the Mail Server. For the Local Settings document, this field is ignored and can be left blank.

Mail-In DB Prefix

This field contains the prefix of the Mail-In Database associated with this Settings document. (Each GRIP Database in your GRIP subsystem must have an associated Mail-In Database. We will discuss this later.)  The prefix will be concatenated with the common name of the Domino Server to provide the full name of the Mail-In Database. Although the prefix for each GRIP database may be different from one another, it is recommended to use the same value for all and simply distinguish the Mail-In Database names by the common name of the Domino Server (shown later in the document). It is further recommended that the Mail-In DB Prefix for the Local Settings document be “ZZ Local GRIP”, and the Mail-In DB Prefix for all other Settings documents be “ZZ Remote GRIP”.

Server Domain

This field contains the Mail Domain of the Mail Server. It must match the Mail Domain value defined in the Mail-In Database document.

List of Domino Directories

This field contains the list of Domino Directories for all Domino Domains in the environment. Each Domino Directory listed must have a replica on the Coexistence Domino Server and must be defined either as part of Directory Assistance or cascading directories on the Coexistence Domino Server.

The following Settings Documents must be created in the Local GRIP Database:

• Local, to define the Domino Coexistence Server

• Default, or one or more Domino Mail Servers, depending on your GRIP Subsystem configuration, representing each Remote GRIP Database.

The Local Settings Document will be the same regardless of the configuration of your GRIP Subsystem, so let’s look at that one first:

Note that for the Local Settings document, the GRIP DB Server Name should be left blank. In this case, we are assuming the Domino Coexistence Server resides in Domain01, and there is a single NAB called names.nsf

Creation of the remaining Settings Documents differs depending on the configuration of your GRIP Subsystem; therefore, we will look at them separately.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Default Settings Document, as follows:

In this type of configuration, it is recommended that the Remote GRIP Database reside on the Domino Coexistence Server (DominoCoex01/Domain01 in our example).

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Settings document for each Domino Mail Server. For our purposes, let’s assume we have two Domino Mail Servers (DominoMail01 and DominoMail02), both residing in Domain01. In this case, you would define the following two Settings documents:

Multiple Hub GRIP Servers

In this scenario, there are many Domino Mail Servers, with multiple Hub GRIP Servers. Each Hub Server is responsible for one or more Domino Mail Servers. For this example, let’s assume we have three Hub GRIP Servers – DominoHub01, DominoHub02 and DominoHub03.

DominoHub01 is responsible for all of the North American Domino Mail Servers; DominoHub02 is responsible for two Domino Mail Servers in Europe (MailEurope01 and MailEurope02); DominoHub03 is responsible for two Domino Mail Servers in Asia (MailAsia01 and MailAsia02). For this environment, we would have to define the following Settings documents:

This example shows how you can use a Default Settings document to avoid having to create multiple Settings documents for multiple Domino Mail Servers. In this example, we explicitly define that to reach either of the Domino Mail Servers in Europe, the message would be sent to the Remote GRIP Database residing on DominoHub02 in Domain02. To reach either of the Domino Mail Servers in Asia, the message would be sent to the Remote GRIP Database residing on DominoHub03 in Domain03. To reach any other Domino Mail Server, we would use the Default, sending the message to the Remote GRIP Database residing on DominoHub01 in Domain01.

The Local GRIP Database functions as a conduit between BTCal and the Remote GRIP Database(s) using Notes mail as the transport. Therefore, each GRIP database (both Local and Remote) must be defined as a Mail-In Database in the Domino Directory.

Once you have created the Settings documents, you must define a Mail-In Database for each one. The name of the Mail-In Database MUST be the Mail-In DB Prefix followed by the common name of the Domino Mail Server. Based upon the Local Settings document defined in the previous section, you would define the Mail-In Database Definition as follows:

Next, we will look at the definitions for the Mail-In Databases for each of the three different GRIP Subsystem definitions.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Mail-In Database, as follows:

Notice the following:

• If you define a Mail Server Name in the Settings document, this must match the Server name in the Mail-In Database.

• The Mail-In DB Prefix in the Settings document must match the first part of the Mail-in name of the Mail-In Database.

• The full Mail-in name of the Mail-In Database must include the Mail-In DB Prefix followed by the common name of either the Domino Coexistence Server or the Domino Mail Server, depending on which database you are defining.

• The File name in the Mail-In Database must match the filename of either the Local or Remote GRIP Database.

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Mail-In Database for each Domino Mail Server, as follows:

Multiple Hub GRIP Servers

In this scenario, even though there are five Settings documents, there are only three Remote Hub Servers; therefore, so we only need to define three Mail-In Databases, as follows:

Define AddUser processing parameters in NOTES.INI for BTCal

The following parameters need to be configured in the NOTES.INI for AddUser and GRIP processing to work.

BTADDUSER

Accepted Value: Y/N

Default: N

This is the main switch for Add User processing and should be set to Y. If this is set to N, and a request to add a user comes in, an NDR is returned.

BTADDUSERWITHEXCEPTIONS

Accepted Value: Y/N

Default: Y

This parameter specifies whether BTCal supports the ability for a Notes user to add an Outlook user to an existing meeting that has exceptions (an occurrence in a series that has either been rescheduled or canceled). If this is set to N and the meeting has exceptions, an NDR is returned. This is customer-dependent, but the recommended setting is Y.

BTADDUSEREXCEPTIONSMAX

Accepted Value: <number>

Default: 5

This parameter specifies the maximum number of exceptions allowed, and is only applicable if BTADDUSERWITHEXCEPTIONS=Y. If the number of exceptions exceeds the value specified, an NDR is returned. This is customer-dependent, but the recommended setting is 50.

BTADDUSERDELAY

Accepted Value: <number>

Default: 0

This parameter specifies the number of seconds BTCal waits to receive all mail items pertaining to an add user request before processing the set of requests. When a Notes user adds an Exchange user to a meeting that has exceptions, Domino sends multiple AddUser requests to BTCal. (If there are no exceptions, Domino sends a single AddUser request to BTCal.) For AddUser processing to perform as expected, BTCal needs to wait to receive all of the separate AddUser requests before processing any of the requests. This is customer-dependent, but the recommended setting is 30.

BTADDUSERDELAYMAX

Accepted Value: <number>

Default: 0

This parameter specifies the maximum number of seconds BTCal waits to receive the original invitation from the Remote GRIP database. If the invitation is not received before this is reached, an NDR is returned. A value of 0 is used to indicate there is no maximum. The recommended value is 0.

BTADDUSERDB

Accepted Value: <database name>

Default: BTADDUSER.NSF

This parameter specifies the name of the Local GRIP Database that resides on the Domino Coexistence Server.. If BTADDUSER = Y and this parameter is not specified in NOTES.INI, BTCal terminates. The recommended value is BTGRIPLocal.nsf.

New Cache Document Creation

When adding an Exchange user to a Notes meeting that is not already in the cache, a new cache document is created.

Additionally, when a single user is added, a new type of cache document is created called AddUserDoc. This document contains the ApptUNID|Address key, along with the original dates and current dates. In the Notes cache document, two new fields have been added:

• $BTAUList

$BTAddUserList contains a list of addresses for those users added to single occurrences. 

Define AddUser processing parameters in NOTES.INI for BTCal

Configuration of the GRIP Subsystem takes place in six steps:

1.    Create/Configure the Settings document in the Local GRIP Database

2.    Create Mail-In Databases in the Domino Directory

3.    Define AddUser processing parameters in NOTES.INI for BTCal

4.    Sign the agents in the Local and Remote GRIP Databases

5.    Add Hub Grip Server as Trusted Server on Domino Mail Servers

6.    Disable the manual agents and enable the scheduled agents

Create/Configure the Settings documents in the Local GRIP Database

Configuration of the GRIP system is defined via a series of Settings documents in the Local GRIP Database. To create a Settings document, open the Local GRIP Database on the Domino Coexistence Server (BTGRIPLocal.nsf) and click Create – Settings from the menu bar.

A settings document defines the following information:

Mail Server

This field contains the name of the Mail Server defined by the Settings document. The full Hierarchical Name of the Mail Server must be entered; however, the field may also contain reserved keywords "Default" and "Local". Local is used to define the Domino Coexistence Server. Default is used if a specific configuration document for a Mail Server is not found.

GRIP Server

This field contains the name of the Domino Server which houses the Remote GRIP database that services one or more Domino Mail Servers. The full Hierarchical Name of the GRIP Server must be entered; however, the field may also contain the reserved keyword "SameAsMailServer", which implies the same value as that of the Mail Server. For the Local Settings document, this field is ignored and can be left blank.

Mail-In DB Prefix

This field contains the prefix of the Mail-In Database associated with this Settings document. (Each GRIP Database in your GRIP subsystem must have an associated Mail-In Database. We will discuss this later.)  The prefix will be concatenated with the common name of the Domino Server to provide the full name of the Mail-In Database. Although the prefix for each GRIP database may be different from one another, it is recommended to use the same value for all and simply distinguish the Mail-In Database names by the common name of the Domino Server (shown later in the document). It is further recommended that the Mail-In DB Prefix for the Local Settings document be “ZZ Local GRIP”, and the Mail-In DB Prefix for all other Settings documents be “ZZ Remote GRIP”.

Server Domain

This field contains the Mail Domain of the Mail Server. It must match the Mail Domain value defined in the Mail-In Database document.

List of Domino Directories

This field contains the list of Domino Directories for all Domino Domains in the environment. Each Domino Directory listed must have a replica on the Coexistence Domino Server and must be defined either as part of Directory Assistance or cascading directories on the Coexistence Domino Server.

The following Settings Documents must be created in the Local GRIP Database:

• Local, to define the Domino Coexistence Server

• Default, or one or more Domino Mail Servers, depending on your GRIP Subsystem configuration, representing each Remote GRIP Database.

The Local Settings Document will be the same regardless of the configuration of your GRIP Subsystem, so let’s look at that one first:

Note that for the Local Settings document, the GRIP DB Server Name should be left blank. In this case, we are assuming the Domino Coexistence Server resides in Domain01, and there is a single NAB called names.nsf

Creation of the remaining Settings Documents differs depending on the configuration of your GRIP Subsystem; therefore, we will look at them separately.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Default Settings Document, as follows:

In this type of configuration, it is recommended that the Remote GRIP Database reside on the Domino Coexistence Server (DominoCoex01/Domain01 in our example).

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Settings document for each Domino Mail Server. For our purposes, let’s assume we have two Domino Mail Servers (DominoMail01 and DominoMail02), both residing in Domain01. In this case, you would define the following two Settings documents:

Multiple Hub GRIP Servers

In this scenario, there are many Domino Mail Servers, with multiple Hub GRIP Servers. Each Hub Server is responsible for one or more Domino Mail Servers. For this example, let’s assume we have three Hub GRIP Servers – DominoHub01, DominoHub02 and DominoHub03.

DominoHub01 is responsible for all of the North American Domino Mail Servers; DominoHub02 is responsible for two Domino Mail Servers in Europe (MailEurope01 and MailEurope02); DominoHub03 is responsible for two Domino Mail Servers in Asia (MailAsia01 and MailAsia02). For this environment, we would have to define the following Settings documents:

This example shows how you can use a Default Settings document to avoid having to create multiple Settings documents for multiple Domino Mail Servers. In this example, we explicitly define that to reach either of the Domino Mail Servers in Europe, the message would be sent to the Remote GRIP Database residing on DominoHub02 in Domain02. To reach either of the Domino Mail Servers in Asia, the message would be sent to the Remote GRIP Database residing on DominoHub03 in Domain03. To reach any other Domino Mail Server, we would use the Default, sending the message to the Remote GRIP Database residing on DominoHub01 in Domain01.

Create Mail-In Databases in the Domino Directory

The Local GRIP Database functions as a conduit between BTCal and the Remote GRIP Database(s) using Notes mail as the transport. Therefore, each GRIP database (both Local and Remote) must be defined as a Mail-In Database in the Domino Directory.

Once you have created the Settings documents, you must define a Mail-In Database for each one. The name of the Mail-In Database MUST be the Mail-In DB Prefix followed by the common name of the Domino Mail Server. Based upon the Local Settings document defined in the previous section, you would define the Mail-In Database Definition as follows:

Next, we will look at the definitions for the Mail-In Databases for each of the three different GRIP Subsystem definitions.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Mail-In Database, as follows:

Notice the following:

• If you define a Mail Server Name in the Settings document, this must match the Server name in the Mail-In Database.

• The Mail-In DB Prefix in the Settings document must match the first part of the Mail-in name of the Mail-In Database.

• The full Mail-in name of the Mail-In Database must include the Mail-In DB Prefix followed by the common name of either the Domino Coexistence Server or the Domino Mail Server, depending on which database you are defining.

• The File name in the Mail-In Database must match the filename of either the Local or Remote GRIP Database.

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Mail-In Database for each Domino Mail Server, as follows:

Multiple Hub GRIP Servers

In this scenario, even though there are five Settings documents, there are only three Remote Hub Servers; therefore, so we only need to define three Mail-In Databases, as follows:

The following parameters need to be configured in the NOTES.INI for AddUser and GRIP processing to work.

BTADDUSER

Accepted Value: Y/N

Default: N

This is the main switch for Add User processing and should be set to Y. If this is set to N, and a request to add a user comes in, an NDR is returned.

BTADDUSERWITHEXCEPTIONS

Accepted Value: Y/N

Default: Y

This parameter specifies whether BTCal supports the ability for a Notes user to add an Outlook user to an existing meeting that has exceptions (an occurrence in a series that has either been rescheduled or canceled). If this is set to N and the meeting has exceptions, an NDR is returned. This is customer-dependent, but the recommended setting is Y.

BTADDUSEREXCEPTIONSMAX

Accepted Value: <number>

Default: 5

This parameter specifies the maximum number of exceptions allowed, and is only applicable if BTADDUSERWITHEXCEPTIONS=Y. If the number of exceptions exceeds the value specified, an NDR is returned. This is customer-dependent, but the recommended setting is 50.

BTADDUSERDELAY

Accepted Value: <number>

Default: 0

This parameter specifies the number of seconds BTCal waits to receive all mail items pertaining to an add user request before processing the set of requests. When a Notes user adds an Exchange user to a meeting that has exceptions, Domino sends multiple AddUser requests to BTCal. (If there are no exceptions, Domino sends a single AddUser request to BTCal.) For AddUser processing to perform as expected, BTCal needs to wait to receive all of the separate AddUser requests before processing any of the requests. This is customer-dependent, but the recommended setting is 30.

BTADDUSERDELAYMAX

Accepted Value: <number>

Default: 0

This parameter specifies the maximum number of seconds BTCal waits to receive the original invitation from the Remote GRIP database. If the invitation is not received before this is reached, an NDR is returned. A value of 0 is used to indicate there is no maximum. The recommended value is 0.

BTADDUSERDB

Accepted Value: <database name>

Default: BTADDUSER.NSF

This parameter specifies the name of the Local GRIP Database that resides on the Domino Coexistence Server.. If BTADDUSER = Y and this parameter is not specified in NOTES.INI, BTCal terminates. The recommended value is BTGRIPLocal.nsf.

New Cache Document Creation

When adding an Exchange user to a Notes meeting that is not already in the cache, a new cache document is created.

Additionally, when a single user is added, a new type of cache document is created called AddUserDoc. This document contains the ApptUNID|Address key, along with the original dates and current dates. In the Notes cache document, two new fields have been added:

• $BTAUList

$BTAddUserList contains a list of addresses for those users added to single occurrences. 

New Cache Document Creation

Configuration of the GRIP Subsystem takes place in six steps:

1.    Create/Configure the Settings document in the Local GRIP Database

2.    Create Mail-In Databases in the Domino Directory

3.    Define AddUser processing parameters in NOTES.INI for BTCal

4.    Sign the agents in the Local and Remote GRIP Databases

5.    Add Hub Grip Server as Trusted Server on Domino Mail Servers

6.    Disable the manual agents and enable the scheduled agents

Create/Configure the Settings documents in the Local GRIP Database

Configuration of the GRIP system is defined via a series of Settings documents in the Local GRIP Database. To create a Settings document, open the Local GRIP Database on the Domino Coexistence Server (BTGRIPLocal.nsf) and click Create – Settings from the menu bar.

A settings document defines the following information:

Mail Server

This field contains the name of the Mail Server defined by the Settings document. The full Hierarchical Name of the Mail Server must be entered; however, the field may also contain reserved keywords "Default" and "Local". Local is used to define the Domino Coexistence Server. Default is used if a specific configuration document for a Mail Server is not found.

GRIP Server

This field contains the name of the Domino Server which houses the Remote GRIP database that services one or more Domino Mail Servers. The full Hierarchical Name of the GRIP Server must be entered; however, the field may also contain the reserved keyword "SameAsMailServer", which implies the same value as that of the Mail Server. For the Local Settings document, this field is ignored and can be left blank.

Mail-In DB Prefix

This field contains the prefix of the Mail-In Database associated with this Settings document. (Each GRIP Database in your GRIP subsystem must have an associated Mail-In Database. We will discuss this later.)  The prefix will be concatenated with the common name of the Domino Server to provide the full name of the Mail-In Database. Although the prefix for each GRIP database may be different from one another, it is recommended to use the same value for all and simply distinguish the Mail-In Database names by the common name of the Domino Server (shown later in the document). It is further recommended that the Mail-In DB Prefix for the Local Settings document be “ZZ Local GRIP”, and the Mail-In DB Prefix for all other Settings documents be “ZZ Remote GRIP”.

Server Domain

This field contains the Mail Domain of the Mail Server. It must match the Mail Domain value defined in the Mail-In Database document.

List of Domino Directories

This field contains the list of Domino Directories for all Domino Domains in the environment. Each Domino Directory listed must have a replica on the Coexistence Domino Server and must be defined either as part of Directory Assistance or cascading directories on the Coexistence Domino Server.

The following Settings Documents must be created in the Local GRIP Database:

• Local, to define the Domino Coexistence Server

• Default, or one or more Domino Mail Servers, depending on your GRIP Subsystem configuration, representing each Remote GRIP Database.

The Local Settings Document will be the same regardless of the configuration of your GRIP Subsystem, so let’s look at that one first:

Note that for the Local Settings document, the GRIP DB Server Name should be left blank. In this case, we are assuming the Domino Coexistence Server resides in Domain01, and there is a single NAB called names.nsf

Creation of the remaining Settings Documents differs depending on the configuration of your GRIP Subsystem; therefore, we will look at them separately.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Default Settings Document, as follows:

In this type of configuration, it is recommended that the Remote GRIP Database reside on the Domino Coexistence Server (DominoCoex01/Domain01 in our example).

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Settings document for each Domino Mail Server. For our purposes, let’s assume we have two Domino Mail Servers (DominoMail01 and DominoMail02), both residing in Domain01. In this case, you would define the following two Settings documents:

Multiple Hub GRIP Servers

In this scenario, there are many Domino Mail Servers, with multiple Hub GRIP Servers. Each Hub Server is responsible for one or more Domino Mail Servers. For this example, let’s assume we have three Hub GRIP Servers – DominoHub01, DominoHub02 and DominoHub03.

DominoHub01 is responsible for all of the North American Domino Mail Servers; DominoHub02 is responsible for two Domino Mail Servers in Europe (MailEurope01 and MailEurope02); DominoHub03 is responsible for two Domino Mail Servers in Asia (MailAsia01 and MailAsia02). For this environment, we would have to define the following Settings documents:

This example shows how you can use a Default Settings document to avoid having to create multiple Settings documents for multiple Domino Mail Servers. In this example, we explicitly define that to reach either of the Domino Mail Servers in Europe, the message would be sent to the Remote GRIP Database residing on DominoHub02 in Domain02. To reach either of the Domino Mail Servers in Asia, the message would be sent to the Remote GRIP Database residing on DominoHub03 in Domain03. To reach any other Domino Mail Server, we would use the Default, sending the message to the Remote GRIP Database residing on DominoHub01 in Domain01.

Create Mail-In Databases in the Domino Directory

The Local GRIP Database functions as a conduit between BTCal and the Remote GRIP Database(s) using Notes mail as the transport. Therefore, each GRIP database (both Local and Remote) must be defined as a Mail-In Database in the Domino Directory.

Once you have created the Settings documents, you must define a Mail-In Database for each one. The name of the Mail-In Database MUST be the Mail-In DB Prefix followed by the common name of the Domino Mail Server. Based upon the Local Settings document defined in the previous section, you would define the Mail-In Database Definition as follows:

Next, we will look at the definitions for the Mail-In Databases for each of the three different GRIP Subsystem definitions.

Single Local and Remote GRIP Databases

In this scenario, since there is a single Remote GRIP Database, you need to create only a single Mail-In Database, as follows:

Notice the following:

• If you define a Mail Server Name in the Settings document, this must match the Server name in the Mail-In Database.

• The Mail-In DB Prefix in the Settings document must match the first part of the Mail-in name of the Mail-In Database.

• The full Mail-in name of the Mail-In Database must include the Mail-In DB Prefix followed by the common name of either the Domino Coexistence Server or the Domino Mail Server, depending on which database you are defining.

• The File name in the Mail-In Database must match the filename of either the Local or Remote GRIP Database.

Each Mail Server is a GRIP Server

In this scenario, since each Domino Mail Server contains a Remote GRIP Database, you must define a Mail-In Database for each Domino Mail Server, as follows:

Multiple Hub GRIP Servers

In this scenario, even though there are five Settings documents, there are only three Remote Hub Servers; therefore, so we only need to define three Mail-In Databases, as follows:

Define AddUser processing parameters in NOTES.INI for BTCal

The following parameters need to be configured in the NOTES.INI for AddUser and GRIP processing to work.

BTADDUSER

Accepted Value: Y/N

Default: N

This is the main switch for Add User processing and should be set to Y. If this is set to N, and a request to add a user comes in, an NDR is returned.

BTADDUSERWITHEXCEPTIONS

Accepted Value: Y/N

Default: Y

This parameter specifies whether BTCal supports the ability for a Notes user to add an Outlook user to an existing meeting that has exceptions (an occurrence in a series that has either been rescheduled or canceled). If this is set to N and the meeting has exceptions, an NDR is returned. This is customer-dependent, but the recommended setting is Y.

BTADDUSEREXCEPTIONSMAX

Accepted Value: <number>

Default: 5

This parameter specifies the maximum number of exceptions allowed, and is only applicable if BTADDUSERWITHEXCEPTIONS=Y. If the number of exceptions exceeds the value specified, an NDR is returned. This is customer-dependent, but the recommended setting is 50.

BTADDUSERDELAY

Accepted Value: <number>

Default: 0

This parameter specifies the number of seconds BTCal waits to receive all mail items pertaining to an add user request before processing the set of requests. When a Notes user adds an Exchange user to a meeting that has exceptions, Domino sends multiple AddUser requests to BTCal. (If there are no exceptions, Domino sends a single AddUser request to BTCal.) For AddUser processing to perform as expected, BTCal needs to wait to receive all of the separate AddUser requests before processing any of the requests. This is customer-dependent, but the recommended setting is 30.

BTADDUSERDELAYMAX

Accepted Value: <number>

Default: 0

This parameter specifies the maximum number of seconds BTCal waits to receive the original invitation from the Remote GRIP database. If the invitation is not received before this is reached, an NDR is returned. A value of 0 is used to indicate there is no maximum. The recommended value is 0.

BTADDUSERDB

Accepted Value: <database name>

Default: BTADDUSER.NSF

This parameter specifies the name of the Local GRIP Database that resides on the Domino Coexistence Server.. If BTADDUSER = Y and this parameter is not specified in NOTES.INI, BTCal terminates. The recommended value is BTGRIPLocal.nsf.

When adding an Exchange user to a Notes meeting that is not already in the cache, a new cache document is created.

Additionally, when a single user is added, a new type of cache document is created called AddUserDoc. This document contains the ApptUNID|Address key, along with the original dates and current dates. In the Notes cache document, two new fields have been added:

• $BTAUList

$BTAddUserList contains a list of addresses for those users added to single occurrences. 

Data flow in the GRIP system