3
Calendar Deployment

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

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

• Deployment
• Pre-Installation Checklist
• User Licenses
• Installation Notes

Deployment

To realize the optimal Oracle Calendar server configuration for your organization, you must first evaluate who your users are, how they should be organized, and how the product will be installed and managed. Consider the following factors:

• 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 Oracle Calendar server is to determine the number of potential Oracle Calendar users in your organization. If growth is anticipated in your organization, 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: people with user accounts on an Oracle Calendar server node.
• Logged-on users: users who are connected to a node but not actively making requests of the database. This figure is generally estimated to be anywhere from 33-50% of configured users. 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 open 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.

  Note: Special consideration must be taken for users of Web clients. The Web client application running on the Web server establishes a pool of persistent connections to the calendar server at startup. Several users will share this pool of persistent connections when making requests through their Web browsers.

Acme Co. example

To illustrate the planning process for your Oracle Calendar server implementation, we will use a fictitious company called Acme Co. The 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 3-1 Acme Company: user base

User category	Estimates
Configured users	16,000
Logged-on users	8,000 (50% of configured users)
Active users	4,000 (25% of configured users)

Logical Divisions of Users

Once you have estimated 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. You should use both geographic and administrative divisions to group your users into nodes.

Acme Co. example

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

Table 3-2 Acme Company: geographic and administrative user divisions

Location	Number of Users	Divisions
Los Angeles	12,000	7,000 Engineering / 5,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

A node is created when an instance of the calendar server is installed. A node is a calendar database containing agendas and information for users and resources. 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:

• Node size

  The maximum capacity of an Oracle Calendar server node is 64,000 configured 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 heavily dependent on hardware and configuration. In an environment supporting any combination of Oracle Calendar Desktop clients (Windows, Mac, Linux, Solaris) and Oracle Connector For Outlook, 10,000 users is a good working figure for maximum configured users. For environments consisting only of Web clients, use 20,000 as a base number. Use caution in determining an appropriate number for a mixed environment. For more information on tuning these numbers, contact a technical consultant or Oracle support representative.

  See Appendix A, "Disk Space and Memory" for any additional node size restrictions.

• 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 64 Kbps or higher is suggested. If this is not possible, it may be wise to consider installing a local server.

• Scheduling between nodes

  More server resources are required when scheduling meetings between users on different nodes in an Oracle Calendar node network. For this reason, it is good practice to group users who work together on one node and thereby minimize the number of meetings involving users from other nodes.

• User migration

  Although it is possible to move individual users from node to node, the process can be lengthy and may alter or remove some information. Minimize 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. For a more detailed discussion of the unimvuser utility, see Appendix E, "Utilities" of the Oracle Calendar Reference Manual.

• Administrative considerations

  While the bulk of calendar server administration can be done remotely, there are 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.

  The time required to administer your calendar node network is also affected by the necessary repetition of some tasks. Certain features, such as holidays, are specific to each node. The tasks associated with these features, such as adding holidays, must be done separately on each node.

• Directory server

  Each node in a calendar node network that is linked to a directory server must point to the same directory server.

Acme Co. example

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

• The Los Angeles user base (12,000) is too large to group in a single node, thus she opted to create two nodes, following the administrative divisions, on two separate servers.
• The Chicago office is expected to steadily decrease as the sales force there is relocated to New York's office. Since the administrator wants to minimize the time required for administrative tasks, and not manage two nodes, she groups the New York and Chicago users in one node on a server located in New York. Having users in two different time zones on the same node will require a minor configuration change for the Chicago users to enable them to set their time zone from the client (see the [LIMITS] settimezone parameter in Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual).
• The final two nodes will be located on one Unix machine in Seattle. Two instances of the Calendar Server will be installed, one for all Seattle users, and the other for the Vancouver users, each with their own port number. Although there is no performance advantage in splitting the users between two calendar server installations on a single host, 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 3-3 Acme Company: node distribution

Node	Server Location	Server name	User Base
Node 1	Los Angeles	host1	LA: Engineering Division (7,000)
Node 2	Los Angeles	host2	LA: Administration Division (5,000)
Node 3	New York	host3	NY: Marketing (600) and Administration (400) Divisions Chicago: Marketing Division (500)
Node 4	Seattle	host4	Seattle: Engineering (1,500) and Marketing (500) Divisions
Node 5	Seattle	host5	Vancouver: Marketing Division (500)

See Appendix A, "Disk Space and Memory", 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 an Oracle Calendar system. The major tasks are:

• system administration on the UNIX or NT server (including monitoring and backups)
• adding, modifying, and deleting users, resources and event calendars
• manage administrative and public groups
• resource administration (assigning designates, creating categories)
• holiday administration
• front-line support
• client training

Different levels of administration tasks can be assigned to calendar users. For more information on administrative access rights and how to grant them, see Chapter 11, "Administrative Rights".

Pre-Installation Checklist

To ensure a quick deployment and minimize later tuning, a number of configuration issues should be considered before installation. Calendar server behaviour can be controlled by parameters set in the $ORACLE_HOME/ocal/misc/unison.ini file. For more information on these parameters, see Appendix C, "Server Parameters" of the Oracle Calendar Reference Manual.

• Kernel parameters

  Operating system kernel parameters must be evaluated, and if necessary tuned, for each installation. See Appendix B, "Adjusting Kernel Parameters" for information concerning the relevant parameters for each supported operating system, the procedure used to alter the current values, and the formulae used to derive correct settings for your installation.

• Client connections

  The [ENG] maxsessions parameter determines the number of available client connections to the calendar server. Set it high enough to accommodate the traffic and expected usage of each node, but be aware that setting this value too high will waste system resources.

• Resource Relative DN

  Installations using external LDAP directory servers can specify a location in the LDAP hierarchy in which all resources will be located by default. Consult the documentation on the [LDAP] resourcerelativedn parameter for details.

• Attachments

  The [LIMITS] allowattachments parameter enables or disables the ability of the calendar clients to attach files to events or tasks. If attachments are allowed, they may be limited in size using the [LIMITS] maxattachmentsize parameter.

• Group administration

  The server offers four different group types: personal, members-only, public and administrative. All users have the right to create personal and members-only groups. The rights to create public and administrative groups must be assigned by the administrator. See Chapter 12, "Groups" for more details on the differences between the group types and the methods used to change default administration rights.

• ACE security framework

  The calendar server's Authentication, Compression and Encryption (ACE) framework is an extensible system ensuring the security and integrity of all information passing from server to server and between servers and clients. By default, the ACE framework is enabled and cannot be disabled unless you are using a standalone installation of the calendar server; in which case use the [ACE] frameworkenable parameter to disable it.

• Resource scheduling

  Resources can either be set up on a first-come first-served basis where double-bookings are not permitted, they may be set up to allow conflicts to occur. Resources can also be restricted to only a few users or be available to all but requiring approval. The default value for the [ENG] allowresourceconflict parameter prohibits double-bookings. See Chapter 9, "Calendar Resources" for more details on managing resources.

The following table presents a list of the major items to consider before installing the calendar server. In the case of a standalone installation of the calendar server with no external directory, only the first 6 items need to be considered:

Table 3-4 Installation information checklist

Item	Accepted Values	Mandatory or Optional	Default Value
Node-ID	Recommended Node-ID ranges: 1-5: Evaluation 6-100: Test 101-9999: Permanent 10000-59999: Future use 60000+: Reserved (NOTE: this number must be unique across all connected nodes)	Mandatory	1
Node Alias	A descriptive word of up to 32 characters (no spaces)	Optional	N/A
Time Zone	See Appendix F, "Time Zone Table" of the Oracle Calendar Reference Manual	Mandatory	N/A
Number of Concurrent Users	Any number between 15 and 2000(NT) or 5000(UNIX)	Mandatory	100
Mail Notification	Enabled (Yes) or Disabled (No)	Mandatory	Yes
Mail Host	Any host	Mandatory if mail notification enabled	local host
Node (SYSOP) Password	Up to 15 alphanumeric characters in length	Mandatory	N/A
Base URL for Directory Server	A URL in this format: ldap://<LDAP host>:<LDAP port>/<Base DN>	Mandatory	ldap://<local host>:389/<no default for Base DN>
Base DN	The point in the directory hierarchy from which searches are performed	Mandatory	N/A
SuperUser DN	User with "unrestricted access". Must be a DN already in the directory server	Mandatory	none
Calendar server Administrators' Parent DN	Any DN, offset from the base DN	Optional	If present, unison.ini value; otherwise N/A
Calendar server Administrators' Group DN	A new group created under the base DN	Mandatory	If present, unison.ini value; otherwise "Calendar Server Admins"

User Licenses

Your calendar server has an unlimited user license. Subject to hardware capabilities and the technical limitations on node size, you may create as many user, resource and event calendar accounts as you need.

Installation Notes

Ensure that you complete all the instructions the Oracle Collaboration Suite Installation Guide.

Distributed Installations

Multiple instances of the calendar server can be installed on the same Unix or Linux host (not on Windows). Whether one instance or many instances of Oracle Calendar are installed on one host, each instance will include many components (even in the standalone mode) which will be installed on the same host. These components include the Calendar Server, Oracle Calendar Administrator, Oracle Sync Server, Oracle Calendar Web client, Oracle Calendar Web Services and Oracle Calendar SDK. If you wish to run different components on different hosts (for example, to run Web calendar clients on a different host from the calendar server) you must keep the following in mind.

• When the Calendar Server is installed in a standalone mode, Web clients identify themselves to the calendar server using a shared key stored in both the Web client and server configuration files. This shared key must match exactly across all Web clients and server instances. As this key is generated automatically by the installation procedure, and is different for each install, you will have to perform this configuration manually. See the Appendix C, "Security" for more information on shared keys.
• If you wish to use multiple calendar server nodes, whether on the same host or distributed across multiple hosts, you must connect the nodes into a network. See Chapter 7, "Calendar Node Networks", for details.