Oracle Calendar Server Administrator's Guide Release 5.5 Part Number B10093-01 |
|
| View PDF |
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:
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:
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:
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.
User category | Estimates |
---|---|
Configured users |
16,000 |
Logged-on users |
8,000 (50% of configured users) |
Active users |
4,000 (25% of configured 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.
In our Acme Co. example, the total user population of 16,000 is distributed in the following manner:
With the logical divisions among your user base clearly delineated, you are now ready to group your users into nodes, calendar databases containing agendas and information for users and resources. Before making these decisions, however, a number of factors must be considered:
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 desktop calendar clients (Windows, Mac, Motif) and Oracle Outlook Connector, 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", and Appendix B, "Sizing Guidelines", for any additional node size restrictions.
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.
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.
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 the calendar server Reference Manual, Appendix C, "Utilities."
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, designates and members-only groups, are specific to each node. The tasks associated with these features, such as adding holidays or assigning designates, must be done separately on each node.
Each node in a calendar node network that is linked to a directory server must point to the same directory server.
Our administrator has attempted to integrate all of the above 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:
[LIMITS] settimezone
parameter in the calendar server Reference Manual, Appendix B, "Server Parameters").The final configuration:
See Appendix B, "Sizing Guidelines", for information concerning memory and disk requirements for your installation.
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:
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 /users/unison/misc/unison.ini
file. For more information on these parameters, see the calendar server Reference Manual, Appendix B, "Server Parameters."
Operating system kernel parameters must be evaluated, and if necessary tuned, for each installation. Refer to the calendar server Reference Manual, Appendix C, "Utilities," 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.
The [LCK] lck_users
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.
The [LIMITS] mail
parameter enables or disables e-mail notification for all event or task creation. The default value enables this feature.
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.
The [LIMITS] allowattachments
parameter 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 [LIMITS] maxattachmentsize
parameter.
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, either individually or in batch mode using a default user profile. See "Assigning administration rights" in Chapter 7, "Users and Groups", for a discussion of the differences between the group types and the methods used to change default administration rights.
When you install the calendar server in internal directory mode, a SYSOP (node) password will not be assigned to the node created during the installation process. Sign in to the node to set a password before adding users. See "Changing the SYSOP (node) password" in Chapter 6, "Server Administration", for instructions on this process.
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; use the [ACE] frameworkenable
parameter to disable it.
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 [ENG] allowresourceconflict
parameter prohibits double-bookings.
The following table presents a list of the major items to consider before installing the calendar server in internal directory mode:
The following table presents a list of the major items to consider before installing the calendar server to connect to an external LDAP directory.
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.
Ensure that you complete all the instructions listed in the Oracle Collaboration Suite Installation Guide.
Note that each time you install Oracle Calendar, the server, Oracle Calendar Administrator, Oracle Calendar Web calendar client and Oracle Calendar API are all installed on the chosen host. 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.