Deployment and Installation

This chapter outlines the deployment and installation of Netscape Calendar Server. Prior planning is an integral part of a successful implementation of Calendar Server in your organization. It is highly recommended that you read this chapter before installing the server, to ensure an installation that is customized to the needs of your particular situation.

The following sections cover the information that you need to get your Calendar Server up and running:

• "Deployment"


• "Pre-installation checklist"
• "Configuration of search parameters"


• "Installation"

Deployment

To plan the optimal Calendar Server configuration for your organization, you need to determine the following:

• Number of users


• Logical divisions of users


• Grouping users to create nodes


• Product administration

Number of users

The first step in planning a successful deployment or "roll-out" of Calendar Server is to determine the number of potential Calendar users in your organization. If growth in the organization is anticipated, factor this into your calculations. The final tally forms the basis for the value you supply for configured users in later calculations.

The categories of users are:

Configured users:

those with user accounts on a Calendar Server node which they access using a Netscape Calendar client.

Logged-on users:

users who are connected to a node, but are not actively making queries of the database (node). This figure is derived from the number of configured users, and is generally estimated to be anywhere from 33-50% of this number. Try to forecast how your users will use the calendaring application. For example, if everyone starts work at the same time, you might anticipate a period of peak usage in the morning where up to 75% of all users will be logged-on at once. Also, a number of users may choose to stay logged-on all day, keeping the calendaring application in the background to permit quick and frequent access.

Active users:

logged-on users who are making an access request to the database. To estimate the number of active users at any point in time, take 10-25% of the total number of configured users. As with logged-on users, base this number on your highest estimate of peak usage.

Acme Co. example

To illustrate the planning process for your Calendar Server implementation, we will use a fictitious company called Acme Corporation. The Calendar administrator at this company has chosen to make her estimates of logged-on and active users high, to ensure that she has adequate resources and that the users can expect uniformly good performance.

Table 1.1  Acme Corporation: User Base 

User category	Estimates
Configured users	12,000
Logged-on users	6,000 (50% of configured users)
Active users	3,000 (25% of configured users)

Logical divisions of users

Once you have enumerated your user base, the next step is to group these users according to location and function. Here it is important to identify not only geographic divisions, but also functional or other administrative divisions within your organization. Both geographic and administrative divisions are used in the next step, where the users are grouped to create nodes.

Acme Co. example

Thus, in our Acme Co. example, the total user population of 12,000 is distributed in the following manner:

Table 1.2  Acme Corporation: Geographic and Administrative User Divisions 

Location	Number of Users	Divisions
Los Angeles	8,000	5,000 Engineering / 3,000 Administration
New York	1,000	600 Marketing / 400 Administration
Chicago	500	500 Marketing
Seattle	2,000	1,500 Engineering / 500 Marketing
Vancouver	500	500 Marketing

Grouping users to create nodes

With the logical divisions among your user base clearly delineated, you are now ready to group your users into nodes. Before making these decisions, however, a number of factors must be considered:

A node is a Calendar database containing all user and resource information and agendas

• Node size

The hypothetical maximum size of a Calendar node is 9,990 users; however, for performance reasons, this limit is not recommended except under exceptional circumstances of infrequent user connections. The recommended capacity, per node and per server, is a limit of 5,000 users. Further to this limitation, the Calendar server can be configured to restrict the number of concurrent connections (i.e. the number of logged-on users), up to a maximum of 5,000 for UNIX servers and 3,800 for Windows NT servers.

 

See Appendix B, "Sizing Guidelines" for any additional node size restrictions related to a particular hardware or operating system.

• Network issues

Although server-to-server calendar communication requires low network bandwidth, in order to obtain acceptable performance for users accessing a remote server, a network bandwidth of 64Kbps or higher is suggested. If this is not possible, it may be wise to consider implementing a local server.

• User migration

It is much easier to migrate an entire node of users than to move individual users from node to node. Also, agenda data involving remote nodes is lost when individual users are moved. Thus, you want to eliminate, or at best restrict, the need to move individual users as a result of either reaching maximum node capacity, or the need to split a node according to logical divisions.

• Administrative considerations

While the bulk of the Calendar Server administration can be done remotely, there are the obvious tasks related to system maintenance that might require an on-site administrator. If you do not have personnel to manage back-up media and system problems at a branch office, then it is probably not a good idea to locate a server there.

 

A further consideration in terms of the investment of time required to administer your Calendar Server network is the repetition of some tasks, such as adding holidays, which must be done on each node.

Acme Co. example

Our Calendar server administrator has attempted to integrate all of the above variables with her user base calculations to arrive at the following configuration. In achieving this balance, she has considered a number of factors specific to her situation:

• The Los Angeles user base is too large to group in a single node, thus she has opted to create two nodes, following the administrative divisions, on two separate servers.


• The New York and Chicago users are grouped in one node on a server located in New York. The administrator wants to minimize the time required for administrative tasks, and not manage two nodes, as the Chicago office is expected to steadily decrease as the sales force there is relocated to New York's office. Having users in two time zones on one node will require a minor configuration change for the Chicago users to enable them to set their time zone from the client.


• The final two nodes will be located on one server in Seattle. All Seattle users will be on one node, and all Vancouver users will be on the other node. Although there is no performance advantage in splitting the users between two nodes on a single server, a number of other factors have contributed to this decision. The on-site administrator is located in Seattle and the network bandwidth between the Seattle office and the Vancouver office is sufficient for the expected traffic. The Vancouver office is on a separate node, however, as it is expected to grow and eventually maintain its own support division. Thus, it is anticipated that the node will eventually migrate to a server in Vancouver.

The final configuration:

Table 1.3  Acme Corporation: Node Distribution 

Node	Server Location	Server Number	User Base
Node 1	Los Angeles	1	LA: 5,000 Engineering Division
Node 2	Los Angeles	2	LA: 3,000 Administration Division
Node 3	New York	3	NY: 600 Marketing and 400 Administration Divisions  Chicago: 500 Marketing Division
Node 4	Seattle	4	Seattle: 1,500 Engineering and 500 Marketing Divisions
Node 5	Seattle	4	Vancouver: 500 Marketing Division

 

Note:

See Appendix B, "Sizing Guidelines" for information concerning memory and disk requirements for your installation.

Product administration

As a final task in this deployment exercise, determine who will be responsible for the different tasks which are part of setting up and maintaining a Calendar calendaring system. The major tasks are:

• system administration on the UNIX or NT server (which includes monitoring and backups)


• adding, modifying, and deleting users and resources


• resource administration (assigning designates)


• holiday administration


• front-line support


• client training

Pre-installation checklist

To enable a quick deployment and minimize later tuning, a number of configuration issues should be considered in advance of your installation. The following behavior is controlled by parameters set under Server Preferences | Manage Calendar Server. For more information on setting and modifying parameters, see Chapter 7, "Server Configuration."

• Logged-on user limit

The parameter lck_users determines the maximum number of logged-on users. The default value is 100. Although setting this number too high will waste system resources, it must be set relative to the size and expected usage of each node.


• Mail notification

The parameter mail enables or disables mail notification for all event or task creation. The default value enables this feature.


• Resource scheduling

Resources can either be set up on a first-come, first-served basis where double-bookings are not permitted, or they may be set up to allow conflicts to occur. The default value for the parameter resourceconflicts permits double-bookings.


• Enabling attachments

The parameter allowattachments enables or disables the attachment of files to events or tasks created by clients. The default value disables this feature. If attachments are allowed, they may be limited in size using the parameter maxattachmentsize.

Configuration of search parameters

Calendar Server search parameters

• Maximum size of returned set for a search

This parameter defines the maximum number of records returned by a directory search.
 

• Minimum length of search string

This parameter determines the minimum number of search characters which must be entered by the user when performing a directory search from the client.
 

Netscape Directory Server search parameters

• Size limit

Specifies the maximum number of entries to return from a search operation. See the Netscape Directory Server Administrator's Guide for a more detailed discussion of this and the following parameter.
 

• Look through limit

Specifies the maximum number of entries in the Directory Server to be searched in response to a search query.

Tuning for speed vs flexibility

Option 1

• wildcard search of entire Calendar Server user base permitted
• administrator must assess impact on performance
• higher stress on machine resources

Option 2

• administrator sets minimum number of characters required for a search to a positive integer (>1) thus forcing users to enter a search value and limit scope of search
• free search not permitted
• search will be faster and more efficient than in above option

less stress on machine resources

Installation

For full installation instructions, please see the Readme file supplied on the distribution media.