Introduction
There are two types of databases in the GRIP subsystem: Local and Remote. There is always only one Local GRIP Database per Domino Coexistence server. Definition of the Remote GRIP Database(s) depends upon how you have your GRIP Subsystem configured.
The following scenarios outline possible implementations of the GRIP Subsystem:
-
Single Local and Remote GRIP Databases
This configuration may be appropriate for a Centralized Domino Environment with a relatively small number of Domino Servers located in the same Data Center. There is a single Remote GRIP database which may reside either on the Domino Coexistence Server or a designated "Hub GRIP Server”. A Hub GRIP Server is defined as any Domino Server that contains a Remote GRIP Database. It is recommended that the Remote GRIP Database reside on the Domino Coexistence Server.
-
Each Mail Server is a GRIP Server
This configuration may be appropriate for a small to medium-sized distributed Domino Environment. There are multiple Remote GRIP Databases, each residing on a separate Domino Mail Server.
-
Multiple Hub GRIP Servers
This configuration may be appropriate for a very large Domino Environment with multiple Domino Server locations in different Data Centers. There are multiple Remote GRIP databases, with each residing on a designated "Hub GRIP server”.
Installation
Installation consists of creating one Local GRIP Database and one or more Remote GRIP Databases, depending on your configuration.
Regardless of what configuration you use, you will only have one Local GRIP Database. So, first you should create the Local GRIP Database on the Domino Coexistence Server. The DB should be created using the BTGRIPLocal.ntf template distributed as part of the BTCal release. (Note that in future releases of BTCal, the filename will change to include a version number.)
Next is the creation of the Remote GRIP Database(s). Where you create each database depends on your configuration. Regardless of where the database is created, you should create it using the BTGRIPRemote.ntf template distributed as part of the BTCal release.
-
Single Local and Remote GRIP databases
Create a single Remote GRIP Database on the Domino Coexistence Server.
-
Each Mail Server is a GRIP Server
Create multiple Remote GRIP Databases, one on each Domino Mail Server.
-
Multiple Hub GRIP Servers
Create multiple Remote GRIP Databases, one on each "Hub GRIP server”.
The filenames of the Local and Remote GRIP databases are immaterial; recommended values are BTGRIPLocal.nsf and BTGRIPRemote.nsf, respectively. If you are creating multiple Remote GRIP DBs, they can each be called BTGRIPRemote.NSF. We will use these names as examples throughout the document.
Configuration
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.
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.
Create/Configure the Settings documents in the Local GRIP Database
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
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.
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.