ColleagueR18InstallationProcedures 02212013

Installation Procedures
Reissued Manual as of February 21, 2013

This is a new edition of the Installation Procedures manual for Colleague Release 18. This edition replaces the previous version dated January 31, 2013. Changes were made for the certification of UniData 7.3.
Updating Your Manual

Replace all copies of your existing manual with this new edition as it will be the basis for all future updates.
Colleague by Ellucian Installation Procedures

Release 18 February 21, 2013
For corrections and clarifications to this manual, see AnswerNet page 3474
Banner, Colleague, Luminis and Datatel are trademarks of Ellucian or its affiliates and are registered in the U.S. and other countries. Ellucian, PowerCampus, Advance, Degree Works, fsaATLAS, Course Signals, SmartCall, Recruiter, and ILP are trademarks of Ellucian Company L.P. or its affiliates. Other names may be trademarks of their respective owners. 20062013 Ellucian Company L.P. and its affiliates. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or the information contained herein is prohibited. Contains confidential and proprietary information of Ellucian and its subsidiaries. Use of these materials is limited to Ellucian licensees, and is subject to the terms and conditions of one or more written license agreements between Ellucian and the licensee in question. In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other similar professional services. Ellucian makes no claims that an institution's use of this publication or the software for which it is provided will guarantee compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization's own choosing.
Prepared by: Ellucian 4375 Fair Lakes Court Fairfax, Virginia 22033 United States of America
Table of Contents
13
15
15 15 16 18
Introduction
About This Manual
Who Should Read This Manual What This Manual Covers How This Manual is Organized Where to Find More Information
19
19 20 20 20 22 22 22 24 27
Colleague Release 18 Description

In This Chapter Components Used for Colleague Operation Colleague Application Environment Application Server Database Server SA Valet Other Components Components Used for Colleague Installation Local Product Repository and Application Environments
29
29 30 30 31 32 33 33 34 36 38
Installation Overview
In This Chapter Installation of the Basic Release System Installation of SA Valet Creation of the Local Product Repository Population of the Local Product Repository Installation of an Application Environment Creation of a New Release 18 Application Environment Creation of the Application Environment Population of the Application Environment Cloning an Existing Application Environment
39
41
41 42 42 43
Preparation
Preparing for the Installation
In This Chapter Understanding Preparation for R18 Installation When to Perform These Preparation Steps High-Level Procedure for a New Application Environment
Installation Procedures, February 21, 2013
Table of Contents
43 44 46 47 48 49 49 49 50 50 52 53 54 54 55 56 56 56 57 57 57 58 58 60 61 62 63 63 65 68 71 72 72 73 73 74 76 77 77
High-Level Procedure for a New Application Server Computer High-Level Procedure for a New Database Computer Computer Configuration Example Configuration for SQL Server or Oracle Example Configurations for UniData Planning: Names, Directories, and Ports Application Environment Names Directory Structure Example Paths Directory Naming Conventions Directory Structure Example for SQL Server or Oracle Directory Structure Example for UniData DMI Listener Ports Identifying Ports That Are Already in Use Port 9000 Reserved for Datatel Daemon Checking Computer Requirements Operating System Requirement Hardware Requirements Installing Supporting Software Licensing Colleague Application Server Installing the JRE or SDK Server Mode Creating Supporting Files (UNIX Only) Installing the Datatel Daemons Prerequisites and Requirements for UNIX or Linux Permissions for UNIX Prerequisites and Requirements for Windows Stopping the Daemon (Replacement Only) Procedure for Installing a Datatel Daemon on Windows Procedure for Installing a Datatel Daemon on UNIX/Linux Daemon Auto-Start Setup (UNIX/Linux Only) Setting Up UniData for the Colleague Executables Installing UniData Configuring UniData on the Application Server Computer Resizing the Master VOC File Adjusting UniData Environment Variables Setting UniData Configuration Parameters Installing the Oracle Client on the Application Server (Oracle Only) Creating Administrative Users on the Application Server Computer
Table of Contents
79 79 80 81 81 82 84 85 87 87 87 88 93 93 93 94 95 95
Setting Up UniData Databases on the Application Server Computer Establishing Free Space for File Updates Setting Up Databases and Administrative Users on the Database Computer Setting Up SQL Server Installing SQL Server Creating Databases and Administrative Users for SQL Server Configuring SQL Server 2008 Setting up a SQL Server 2008 Database to Use C# Code Setting Up Oracle Installing Oracle Installing Oracle Patches Creating Instances, Tablespaces, and Users for Oracle Setting Up UniData on the Database Computer Installing UniData on the Database Computer Creating Administrative Users for UniData on the Database Computer Configuring UniData on the Database Computer Application Environment Preparation Worksheets
103
105
105 106 107 107 109 110 112 113 115 116 118 119
Release System
Installing SA Valet
In This Chapter SA Valet Installation Overview Before You Begin Software Updates Quick Start: Upgrading SA Valet Installing SA Valet Self Update Functionality Setting the Run as Administrator Options Installing JDBC Drivers (Oracle Only) Setting Up Hosts in SA Valet Defining LPR and Host Properties in a Second SA Valet Securing the Connection Between SA Valet and the Datatel Daemon
Table of Contents
121
121 121 122
Creating the Local Product Repository

In This Chapter Before You Begin Procedure for Creating the Local Product Repository
131
131 131 132 132 132 132 135 136 136
Populating the Local Product Repository

In This Chapter Before You Begin Populating the Local Product Repository Populating the Local Product Repository From the DVD Testing the DVD Drive Refreshing Licensing Information Loading the Release Package from the DVD Populating the Local Product Repository Over the Internet Local Product Repository (LPR) Tables
139
141
141 141 142 142 142 143 143 145 155
Application Environment Creation

Creating the Application Environment
In This Chapter Cloning an Existing Application Environment Before You Begin Retrieving Software Updates Full Release vs. Consolidated Full Release Full Release Consolidated Full Release Creating the Application Environment Upgrading DMI Listeners
157
157 157 158 159 162 163
Populating the Application Environment

In This Chapter Before You Begin Externally Authenticating the Administrative User (Oracle Only) Procedure for Populating the Application Environment Troubleshooting Using the COMO File Compiling/Validating Invalid Java Classes (Oracle)
165
165 166
Post-Install Procedures
In This Chapter Running Automated Post-Install Steps
Table of Contents
168 171 178 180 182 183 184 184 187
Update Computed Column Parameters (SQL Server and Oracle Only) Building the PERSON File Indexes Looking Up PERSON Records Without an ID Dictionary Date Conversion Modify WWW Files (RPI) Running the EDX Interface Load Utility Modify Campus Organizations SQL Function Defining the Permitted Number of Database Connections Setting up an Environment as Production
189
189 190 191 192 193 194 195 195 196 198 198 199 200 200
Setting Up New Environments

In This Chapter Building New File Indexes Building Application Security Defining Listener Parameters Creating a Printer Control Record Procedure for Creating the Printer Control Record on UNIX or Linux Creating the Printer Control Record and Validation Code on Windows Procedure for Creating the Printer Control Record (Windows) Procedure for Creating the VALID.PRINTERS Validation Code (Windows/Networked Printers) Specifying Permissions for Core Custom Code (UNIX/Linux Only) Understanding Permissions for Core Custom Code Procedure for Specifying Permissions for Core Custom Code Installing Software Updates and Custom Release Packages Procedure for Installing Software Updates and Custom Release Packages
201
203
203 204 205 205
Other Application Environment Procedures

Installing a New DMI Listener
In This Chapter Understanding DMI Listener Installation Planning Listener Ports
Table of Contents
205 205 206 207 212
Listener Installation Path Path to JRE or SDK Worksheets Procedure for Installing a New DMI Listener Defining Listener Parameters
213
213 213 214 215
Implementing Multiple DMI Data Access Servers

In This Chapter Before You Begin Implementing Multiple DAS Listeners Procedure for Implementing Multiple DAS Listeners
219
219 220 220 221 225 225 226 226 226 227 228 229 230 230 234 237 239 239 240 241 241 243 244 245
Cloning an Application Environment

In This Chapter Terminology Understanding Cloning High-Level Procedure for Cloning an Application Environment Preparing for Cloning Checking the Configuration Application Environment Name Directory Structure for Target Application Environment DMI Listener Ports Path to JRE or SDK Preparing for Cloning with the Colleague Portal (Portal Cloning) Before You Begin Copying the Active Directory Users Example Procedure Copying the SharePoint Portal (Portal Cloning) Updating User Permissions to the Test Active Directory Domain (Portal Cloning) Adding LDAP Groups to the Portal (Portal Cloning) Adding the LDAP Groups as Members of Constituency Sites Adding the LDAP Groups as Members of the Top-Level Portal Site Copying the Colleague Executables Procedure for Copying the Colleague Executables Creating an Administrative Login for the Application Server Setting Up the Application Environment in User Interface Copying the Colleague Data
10
Table of Contents
245 245 247 248 248 249 252 254 255 256 257 259 259 260 261 261 272 274 275 275 275 276 277 280 282 286 288 289 291 293 294 295 296 296 297
Copying Colleague Data for SQL Server Copying the Database Creating an Administrative User for the SQL Server Database Copying Colleague Data for Oracle Prerequisite Checks Creating the Instance, Tablespaces, and Users Copying Table Definitions Exporting the Data from the Source Schema Importing the Data to the Target Schema Verification Moving Indexes to the Index Tablespace Changing the Oracle Java Resolver Cleanup Copying Colleague Data for UniData Copying the DMI Listeners Running the Clone Application Environment Wizard Starting the New Listeners Correcting Environment-Specific Values Securing the BECU Form Environment-Specific Parameters Understanding Environment-Specific Parameters Cleanup Specifications Noteworthy Fields on the MECD Form Environment Cleanup Report Procedures for Changing Environment-Specific Parameters External VOC References Procedure for Correcting External VOC References Updating Portal Pointers and Settings (Portal Cloning) Updating the Domain Pointer for Users Updating the Primary Constituency of All Users (Portal Cloning) Updating SharePoint Colleague Connectors and Other Settings (Portal Cloning) Testing Your Results Setting Up User Access Features Installing and Setting Up Interfacing Software Worksheets
11
Table of Contents
301
303
303
Appendices
DMI Listener Names
Listener Naming Convention
305
305 305
Glossary
In This Appendix Definitions
12
Introduction
Introduction 0
About This Manual
Who Should Read This Manual

Anyone responsible for installing Colleague Release 18 should read this manual.
What This Manual Covers

This manual provides instructions for installing Colleague Release 18. Specifically, this manual covers: Preparing for Colleague installation. Installing SA Valet, Ellucians system administration software used for installing and maintaining Colleague. Creating and populating the local product repository of Colleague software. Creating Colleague application environments (such as production, test, and development) and installing software from the local product repository into those application environments.
15
Introduction: About This Manual
How This Manual is Organized

Table 1 shows the content of each chapter in this manual.
Table 1: Organization of This Manual Chapter
Introduction About This Manual Colleague Release 18 Description Installation Overview Preparation Preparing for the Installation 41 Considerations for setting up the computers and supporting software to support Colleague installation and operation. This chapter contains worksheets to help you define installation paths, ports, and other characteristics before you begin installing Colleague. 15 19 29 Information about this manual and its organization. Description of Colleague configuration during both normal operation and installation. Description of the installation of the basic release system and Colleague application environments.
Page
Description
Release SystemThese chapters describe the installation of SA Valet and the installation and population of the local product repository. These are procedures that you perform once, before you create Colleague application environments. Installing SA Valet Creating the Local Product Repository Populating the Local Product Repository 105 121 131 Procedure for installing SA Valet, Ellucians system administration application. Procedure for creating the local product repository (the database that stores Colleague software obtained from Ellucian). Procedure for retrieving Colleague software from Ellucian and storing it in the local product repository.
Application EnvironmentsThese chapters contain procedures to be performed each time you create an application environment. Application Environment Overview Creating the Application Environment 147 141 High-level information about creating an application environment. Procedure for creating a Colleague application environment and Colleague database. The application environment contains Colleague and Envision software, and the database contains Colleague data. Procedure for populating the application environment with software from the local product repository. Procedures to be performed only in new application environments after populating the application environment.
Populating the Application Environment Setting Up New Environments
157 189
16
How This Manual is Organized
Table 1: Organization of This Manual (contd) Chapter

Updating the Application Environment Post-Install Procedures
Page
192 165
Description
Procedures to be performed in all application environments after populating the application environment. Final post-install procedures to be performed in all application environments.
Other Application Environment Procedures Installing a New DMI Listener Implementing Multiple DMI Data Access Servers Cloning an Application Environment Appendices DMI Listener Names Running the Prior Version of SA Valet Glossary 303 305 305 Information about names assigned to DMI Listeners. Information about accessing SA Valet 2.4.0 temporarily., or permanently reverting to SA Valet 2.4.0 if needed. Definitions of terms associated with Colleague Release 18. 203 213 219 Procedure for installing a new DMI Listener in an application environment and for specifying Listener performance parameters. Procedure for installing and configuring secondary DAS Listeners. Procedures for creating a Colleague application environment by cloning an existing application environment.
17
Introduction: About This Manual
Where to Find More Information

Table 2 lists sources of information that provide additional assistance in installing and administering Colleague. Other procedure manuals for using Colleague are available from the Documentation area of the Ellucian client website (clients.datatel.com/documentation).
Table 2: Additional Sources of Information for Colleague Installation Type of Information
Setting up your Colleague application environments to make them available in User Interface (UI). Integrating Colleague with WebAdvisor. Using Envision Data Exchange to create interfaces between Colleague and third-party software, including e-learning systems, portals, and government reporting software. Updating your Colleague application environments with software updates from Ellucian. Other aspects of administering your Colleague application environments.
Source
User Interface 4.x Installation and Administration WebAdvisor Installation and Administration (currently for WebAdvisor 3.1.6) EDX Administration
Updating Colleague Software Managing Colleague Software Environments
18
Introduction 0
Colleague Release 18 Description
In This Chapter
This chapter describes the Colleague configuration for normal operation as well as the additional components used to install a Colleague full release or software update. Table 3 lists the topics covered in this chapter.
Table 3: Topics in This Chapter Topic
Components Used for Colleague Operation Components Used for Colleague Installation 20 24
Page
19
Introduction: Colleague Release 18 Description
Components Used for Colleague Operation

Figure 1 on page 21 shows the components for Colleague operation.
Note: Your configuration of computers may differ from the one shown in Figure 1. See Computer Configuration on page 46 for examples for UniData, SQL Server, and Oracle.
The following sections describe the main components shown in Figure 1 (the Colleague application environment, SA Valet, and other components). After completing the procedures in this manual, you will have installed SA Valet and one or more Colleague application environments. You will also have installed a local product repository, used during Colleague installation as described in Components Used for Colleague Installation on page 24.
Colleague Application Environment

An application environment consists of an application server and a database server. Components of each are described below.
Application Server
Key components of the application server are the following: Colleague executables. Programs and processes for UT, CORE, ST, HR, CA, and CF, running on a UniData virtual machine. The directory under which the Colleague executables are located is called the Colleague Executables Home Directory (CEHD).
DMI application server. A DMI Listener1 used for communication between: Colleague and the web server. Colleague and EDX/partner interfaces. Colleague and SA Valet, for SA Valet functions that use Colleague forms.
1. A DMI Listener is software that uses the Datatel Messaging Interface (DMI) protocol for communication. See the Glossary for more information about DMI Listeners.
20
Figure 1: Components Used for Colleague Operation

Application server computer SA Valet computer SA Valet DMI application server DMI data access server Colleague database computer
Installation Procedures, February 21, 2013 21
Colleague executables Application server (UniData VM Database server Datatel daemon Components addressed in this manual Components addressed in other Ellucian manuals DMI print server DMI RPC server web server EDX/partner interfaces UI client
Colleague database
RDBMS (Oracle, SQL Server, or UniData)
Datatel daemon
Colleague application environment
Database Server
Key components in the database server are the following: Colleague database. Database that contains Colleague data files (such as the PERSON file) as well as code files and validation files. You can use standard database queries, independent of Envision or Colleague, to query the database. DMI data access server (DAS). A DMI Listener used for communication between the Colleague executables and the Colleague database.
SA Valet
SA Valet is Ellucians system administration application. Both the DMI application server and DMI data access server, as well as other DMI Listeners that you will install, can be started and stopped from SA Valet.
Other Components
A Datatel daemon is installed on each computer that hosts a DMI Listener. The daemon is communication software that accesses DMI Listeners, performing functions normally performed by Telnet and FTP. The installation processes that use the daemon include creating a local product repository, creating an application environment, copying DMI Listeners as part of cloning an application environment, and upgrading DMI Listeners. The daemon is also used when starting and stopping DMI Listeners.
22
Other components, also shown in Figure 1 on page 21 and described below, support Colleague operation but are not addressed in this manual. DMI print server. A DMI Listener that controls access to printers in the Microsoft Windows environment. DMI RPC server. A DMI Listener that enables remote procedure calls (RPCs) to programs running in other environments, such as Microsoft Windows. UI clients. User Interface Desktop client software, installed on an end users PC, that provides a graphical user interface to Colleague. Web server. Third-party software that supports web software including WebAdvisor. EDX/partner interfaces. Interfaces between Ellucian software and thirdparty software, including e-learning systems, portals, and government reporting software. See Where to Find More Information on page 18 for the Ellucian manuals that address these other components. These components are not shown in the rest of the figures in this chapter.
23
Components Used for Colleague Installation

Figure 2 shows the components used during Colleague installation (in the dashed-line box). Components used during Colleague operation, discussed earlier, are shown for reference.
24
Figure 2: Components Used for Colleague Installation

SA Valet computer SA Valet Application server computer DMI application server Colleague database computer DMI data access server for Colleague database
Colleague executables UniData VM
Colleague database
Datatel daemon
RDBMS (Oracle, SQL Server, or UniData)
Installation programs
Datatel daemon
Datatel daemon
DMI data access server for product repository
Colleague release package (at Ellucian or on DVD)
Local product repository
RDBMS (Oracle, SQL Server, or UniData) Product repository computer
These components are used only during installation of a full release or software updates
25
The installation components include: Colleague release package. Contains the current version of Ellucian software. For a full release, the release package may be at Ellucian (in the Datatel product repository) or on a DVD. For a software update, the release package is at Ellucian. During installation, software from the release package is retrieved (from Ellucian or from the DVD) and installed in the local product repository. Local product repository. A database, installed at your site, that contains all released Ellucian software, current as of the last time you retrieved software from Ellucian. Specifically, the local product repository contains: Envision and non-Envision software. Previous versions as well as the current version of each component. Alpha or beta versions of software for which your institution is a field test site. Optional software, even if you have not licensed it. (Only software that you have licensed will be installed to the application environments.) Custom software developed by you or Ellucian. In addition to software, the local product repository contains: Information about the status of each application environment, including which software components are installed and the version of each component. Licensing information used to determine which components can be installed in the application environments. This licensing information is refreshed each time SA Valet contacts Ellucian to retrieve software. The local product repository is the holding tank from which you select licensed software to install in each of your application environments. The population of the local product repository and the subsequent installation of software in the application environments are separate steps, and need not be performed immediately one after the other. In particular, as you continue to use Colleague, you can periodically bring your local product repository up to date without necessarily updating the application environments at the same time. DMI data access server (DAS). A DMI Listener used to communicate with the local product repository. Installation programs. Programs installed with SA Valet and the application environment, used later in the installation process to install other software.
26
Local Product Repository and Application Environments

All versions of Ellucian software components are installed in the local product repository. Specifically, the initial installation creates a baseline with a version of each software component. Later, if an updated version of a component is included in a software update, it does not overwrite the original version but instead both versions are kept in the local product repository. As a result, you need to install only one local product repository and associated DMI data access server. You will likely have multiple application environments (such as production, test, and development), all receiving software from the single local product repository (Figure 3).
Figure 3: Example Configuration of a Local Product Repository and Application Environments
Application environment (production)
Application environment (test)
Application environment (development)
27
28
Introduction 3
Installation Overview
In This Chapter
This chapter provides an overview of Release 18 installation. Table 4 lists the topics covered in this chapter.
Installation of the Basic Release System Installation of SA Valet Creation of the Local Product Repository Population of the Local Product Repository Installation of an Application Environment Creation of a New Release 18 Application Environment Cloning an Existing Application Environment
Page
30 30 31 32 33 33 38
Comments
You will perform these procedures once, before you create Colleague application environments.
You will perform these procedures multiple times, once for each of your Colleague application environments.
29
Introduction: Installation Overview
Installation of the Basic Release System

This section describes the installation of SA Valet and the installation and population of the local product repository. These are procedures that you perform once, before you create Colleague application environments. This section describes what happens during each step, and subsequent chapters contain the procedures. Table 5 is a road map to the sections of this manual with the description and procedure for each step.
Table 5: Steps in Installation of the Basic Release System Step
Install SA Valet Create the local product repository Populate the local product repository
Description
page 30 page 31 page 32
Procedure
Installation of SA Valet
The following components are installed with SA Valet (Figure 4): SA Valet, Ellucians system administration application. Installation programs that are later used in the installation of other software on the product repository computer and the application server computer. The remaining Colleague installation steps are initiated from SA Valet, which is why SA Valet must be installed first. For the installation procedure, see Installing SA Valet on page 105.
Figure 4: Installation of SA Valet
SA Valet computer SA Valet
30
Installation of the Basic Release System
Creation of the Local Product Repository

Creation of the local product repository and its DMI data access server is initiated from SA Valet. The following components are created (Figure 5): DMI data access server for the local product repository. Database tables for the local product repository. Note the following: You must have already installed the relational database management system (RDBMS) and created the database (see Setting Up Databases and Administrative Users on the Database Computer on page 80). This step creates the product repository tables, but does not populate them with Colleague software; that occurs in the next step (see Population of the Local Product Repository on page 32). Specifications for the local product repository and DMI data access server are in the installation programs installed with SA Valet. For the installation procedure, see Creating the Local Product Repository on page 121.
Figure 5: Creation of the Local Product Repository
DMI data access server
Local product repository RDBMS (Oracle, SQL Server, or UniData)
Product repository computer
31
Population of the Local Product Repository

This step, also initiated from SA Valet, populates the local product repository with software from the Colleague release package (Figure 6) as well as customer licensing information. The release package may be at Ellucian (in the Datatel product repository) or on a DVD. Installation programs installed with SA Valet retrieve the software from the release package and send it to the local product repository through the DMI data access server and Datatel daemon. For the installation procedure, see Populating the Local Product Repository on page 131.
Figure 6: Population of the Local Product Repository
Colleague release package (at Ellucian or on DVD)
RDBMS (Oracle, SQL Server, or UniData) Product repository computer
32
Installation of an Application Environment

You can create a new Release 18 application environment or clone an existing application environment. Each of these options is discussed below.
Creation of a New Release 18 Application Environment

This section describes the creation and population of a new application environment. This section describes what happens during each step, and subsequent chapters contain the procedures. Table 6 is a road map to the sections of this manual with the description and procedure for each step.
Table 6: Steps in Installation of an Application Environment Step
Create the application environment Populate the application environment
Description
page 34 page 36
Procedure
page 141 page 157
33
Creation of the Application Environment

This step, initiated from SA Valet, creates the application environment (Figure 7 on page 35). The following components are installed: DMI data access server for the Colleague database. DMI application server. UniData virtual machine and a UniData account. Installation programs stored in the UniData account. Colleague database tables required for installing and running the DMI Listeners in the application environment.1 Data in those tables. For the procedure, see Creating the Application Environment on page 141.
1. You must have already installed the relational database management system (not shown on Figure 7). In addition, for SQL Server or Oracle, you must have created the database (see Setting Up Databases and Administrative Users on the Database Computer on page 80). For UniData, the Colleague installation programs create the database and account.
34
Figure 7: Creation of the Application Environment

Application environment SA Valet computer SA Valet DMI application server DMI data access server for Colleague database Installation programs Application server computer Colleague database computer
UniData VM Installation programs
Colleague database
Local product repository Product repository computer
Population of the Application Environment

This step, also initiated from SA Valet, populates the application environment with software from the local product repository (Figure 8 on page 37). The following components are installed: Colleague executables stored in the UniData account. Tables in the Colleague database used to store Colleague data (such as the PERSON table). Selected data, such as validation codes that are delivered with Elluciandefined values. For the installation procedure, see Populating the Application Environment on page 157.
36
Figure 8: Population of the Application Environment

Application environment Application server computer Colleague database computer
DMI application server DMI data access server for Colleague database Colleague executables
Colleague database
UniData VM
Local product repository Product repository computer
Cloning an Existing Application Environment

You will probably have multiple application environments, such as production, test, and development. After creating one application environment, you can create others by either repeating the procedures to create an environment or by cloning (making a working copy of) an existing application environment. For example, you might want to create a test environment by cloning your production environment. See Cloning an Application Environment on page 219 for the cloning procedure.
38
Preparation
Preparation 8
Preparing for the Installation
In This Chapter
This chapter provides considerations for setting up the computers and supporting software to support Colleague installation and operation. Table 7 lists the topics covered in this chapter.
Understanding Preparation for R18 Installation Planning: Names, Directories, and Ports Checking Computer Requirements Installing Supporting Software Setting Up UniData for the Colleague Executables Setting Up UniData Databases on the Application Server Computer Setting Up Databases and Administrative Users on the Database Computer Application Environment Preparation Worksheets
Page
42 49 56 57 72 79 80 95 95
In addition to this chapter, Managing Colleague Software Environments contains beneficial information about managing users and role-based security setup.
41
Preparation: Preparing for the Installation
Understanding Preparation for R18 Installation

Table 8 lists the topics covered in this section.
Table 8: Topics in This Section Topic
When to Perform These Preparation Steps High-Level Procedure for a New Application Server Computer High-Level Procedure for a New Database Computer Computer Configuration
Page
42 43 44 46
When to Perform These Preparation Steps

You will need to perform some or all of the steps in this chapter in the following situations: Initial setup. For initial setup, you must perform all of the procedures in this chapter. Create application environment. You will need to perform some of these procedures each time you create an application environment. See Table 9 on page 43. New server. If you are already on Release 18, you will still need to perform some of these procedures if you want to set up a new server for use with Release 18. See page 43 for a list of procedures for setting up a new application server. See page 44 for a list of procedures for setting up a new database server.
42
High-Level Procedure for a New Application Environment

Table 9 lists the steps in setting up a new application environment.
Table 9: HIgh-Level Procedure for a New Application Environment Step
Plan the application environment name, directory structure, and ports. Recheck hardware requirements. Recheck UniData configuration parameters on the application server computer and on the database computer. These parameters may change if adding an application environment changes the number of concurrent users. Create an administrative user for the Colleague executables. Create the database and the administrative database users. Set up the application environment in User Interface.
See...
High-Level Procedure for a New Application Server Computer

Table 10 lists the steps in setting up a new application server computer.
Table 10: High-Level Procedure for a New Application Server Computer Step
Check operating system requirement. Check hardware requirements. Install JRE and supporting files. Create datateltab file (UNIX only). Install the Datatel daemon. Add the new computer to the Hosts tab in each installation of SA Valet. Secure the connection between the daemon on the new computer and each installation of SA Valet. Install UniData
Reference
page 56 page 56 page 57 page 58 page 60 page 116 Managing Colleague Software Environments page 72
43
Table 10: High-Level Procedure for a New Application Server Computer Step
Resize the master VOC file Adjust UniData environment variables Set UniData configuration parameters. Create administrative users for the Colleague executables. Perform the steps below if you are using UniData. Establish free space for file updates. page 79
Reference
page 73 page 74 page 76 page 77
High-Level Procedure for a New Database Computer

Table 10 lists the steps in setting up a new database computer. These steps apply for all configurations where the Colleague executables and data are on separate computers. They do not apply to a UniData configuration.
Table 11: High-Level Procedure for a New Database Computer Step
Everyone should perform the steps in this section. Check operating system requirement. Check hardware requirements. Install JRE and supporting files. Create datateltab file (UNIX only). Install and start the Datatel daemon. Add the new computer to the Hosts tab in each installation of SA Valet. Secure the connection between the daemon on the new computer and each installation of SA Valet. page 56 page 56 page 57 page 58 page 60 page 116 Managing Colleague Software Environments
Reference
Perform the steps below if you are using the SQL Server database. Install SQL Server. Create databases and administrative users. page 81 page 82
44
Table 11: High-Level Procedure for a New Database Computer (contd) Step Reference
Perform the steps below if you are using the Oracle database. Install Oracle. Create instances, tablespaces, and users. page 87 page 88
45
Computer Configuration
The planning steps in this chapter, and the installation procedures later in this manual, contain different steps depending on your computer configuration. Three example configurations are shown below: SQL Server or Oraclesee page 47. UniDatasee page 48. Your computer configuration depends on your choice of relational database management system and other factors. Ellucians Professional Services Team can assist you in selecting a configuration.
46
Example Configuration for SQL Server or Oracle

Figure 9 is an example configuration for a SQL Server or Oracle database. In this example, the local product repository and Colleague databases, along with the associated DMI data access servers, are installed on one computer, while the Colleague executables (running on a UniData virtual machine) and associated DMI application servers are installed on a separate computer.
Figure 9: Example Computer Configuration for a SQL Server or Oracle Installation
Application server computer Database computer
DMI application server (production)
Colleague executables (production)
Colleague database (production)
DMI data access server (production)
DMI application server (test)
Colleague executables (test)
Colleague database (test)
DMI data access server (test)
DMI application server (development)
Colleague executables (development)
Colleague database (development)
DMI data access server (development)
DMI data access server (product repository)
UniData VM
SQL Server or Oracle RDBMS
47
Example Configurations for UniData

Figure 10 is an example configuration for UniData. The Colleague executables and data are combined in the same UniData account. In this deployment, the application server includes VOC pointers to UniData data files.
Figure 10: Example UniData Installation
Application server and database computer
DMI application server (production)
Colleague executables and database (production)
DMI data access server (production)
DMI application server (test)
Colleague executables and database (test)
DMI data access server (test)
DMI application server (development)
Colleague executables and database (development)
DMI data access server (development)
DMI data access server (local product repository)
UniData RDBMS
48
Planning: Names, Directories, and Ports

Planning ahead for your Colleague installation will simplify both installation and troubleshooting. Table 12 lists the planning topics covered in this section.
Table 12: Planning Topics in This Section Topic
Application Environment Names Directory Structure DMI Listener Ports Port 9000 Reserved for Datatel Daemon
Page
below 49 54 55
Application Environment Names

Ellucian recommends that you select names for application environments and use them consistently in the following places: Name of application environment in SA Valet (specified during Colleague installation). Name of database in User Interface (UI), specified during UI setup. Directory name (specified during Colleague installation). Use the worksheet in Table 24 on page 95 to specify your application environment names.
Directory Structure
During installation of the local product repository and application environments, you will specify the paths to the installation directories for DMI Listeners, Colleague executables, and (for UniData) the data. The installation processes will create those directories, so you dont have to create them before installing Colleague. However, you should plan the directory structure before installing.
49
This section contains figures that show example directory structures for different RDBMS configurations. Table 13 lists the locations of the example figures and the worksheets where you can record your installation paths.
Table 13: Location of Directory Structure Examples and Worksheets Situation
SQL Server or Oracle UniData
Example
Figure 11 on page 52 Figure 12 on page 53
Worksheet
Table 25 on page 96 Table 26 on page 97
Note: The example figures below show multiple directories (srv01, srv02, and so on) in each application environment for installing DMI application servers. You will install only one DMI application server in each environment using the procedures in this manual. You may install others later.
Example Paths
The examples paths in the worksheets are Ellucians suggestions for the end of the path. The beginning of the path may differ depending on your computer, operating system, and database. For example, Oracle is typically installed in the /u01/app/oracle directory. The recommended paths in the worksheets all start with the datatel directory. In this case, it might be appropriate to create a /u01/app/datatel directory for installation of Ellucian software.
Directory Naming Conventions

The example figures and worksheets in this section use the following conventions. While you do not need to use the example directory names, we recommend that you consider these conventions in naming your directories. When two computers are used, the directory structure starting at the datatel directory is the same on both. For example, the Colleague executables and DMI application server are under the datatel/coll18/production directory on the application server computer, and the DMI data access server for the Colleague database is under the datatel/coll18/production directory on the
50
database computer. This parallel structure clarifies the relationship between directories on the two computers. The coll18 directory under the datatel directory will help to maintain a clear directory structure when you install future Colleague releases (such as coll19). The application environment directories (for example, production, test, development) should match the application environment names you entered in Worksheet Item A on page 95. apphome is the directory where Colleague executables will be installed. This directory is also called the Colleague Executables Home Directory (CEHD). For a UniData environment, apphome will also contain the Colleague data. repository_das is the directory where the DMI data access server for the local product repository will be installed. datatel/coll18/coll18 is the directory where the local product repository will be installed in a UniData environment. das is the directory where the DMI data access server for the Colleague database will be installed. svr01 is the directory where the DMI application server will be installed. The svr designation is used, rather than a designation such as appsvr or wasvr (for WebAdvisor), because each DMI Listener can be assigned one or more roles. You might later install another DMI Listener and assign it the role of DMI application server, and then use the first DMI Listener for another role.
51
Directory Structure Example for SQL Server or Oracle

Figure 11 is an example directory structure for a SQL Server or Oracle database. Use the worksheet in Table 25 on page 96 to record the installation paths for your directory structure.
Figure 11: Suggested Directory Structure for SQL Server or Oracle
SQL Server or Oracle
52 Application server computer production apphome Installation Procedures, February 21, 2013 Database computer
Ellucian coll18
test
development
another environment
svr01 svr02 svrnn
apphome
svr01 svr02 svrnn
apphome
svr01 svr02 svrnn
apphome
svr01 svr02 svrnn
Ellucian coll18
repository_das
production das
test das
development das
Directory Structure Example for UniData

Figure 12 is an example directory structure for a UniData database. Use the worksheet in Table 26 on page 97 to record the installation paths for your directory structure.
Figure 12: Suggested Directory Structure for UniData
UniData
Application server and database computer Ellucian coll18
coll18
repository_das
production
test
development
another environment
das
apphome
svr01 svr02 svrnn
das
apphome
svr01 svr02 svrnn
das apphome
svr01 svr02 svrnn
DMI Listener Ports

The Colleague installation procedures in this manual create the following DMI Listeners: DMI data access server for the local product repository. DMI data access server for the Colleague database (at minimum, one for each application environment). DMI application server (one for each application environment). In addition, you may later install more DMI Listeners in each application environment for other purposes. Examples include: DMI print server. DMI RPC server. Dedicated DMI application server for SEVIS transactions. Additional DMI application servers to share the load for web transactions. During installation of each DMI Listener, you will specify the unsecure port for that Listener. Later, you can set up a secure port for each Listener. Ellucian recommends that you do the following to avoid confusion that might lead to port conflicts: Set aside a range of port numbers exclusively for Datatel DMI Listeners. The examples in Table 27 on page 98 use 7200 through 7299 for unsecure ports and 7300 through 7399 for secure ports. Specify ports for DMI Listeners, using the worksheet in Table 27 on page 98, before you begin installation. Make each port number unique within your network, even though it is possible to use the same port number on different computers. For example, even if your Colleague data and Colleague executables are on separate computers, you should still use different port numbers for the DMI data access server and the DMI application server.
Identifying Ports That Are Already in Use

In UNIX you can check the /etc/services and /etc/inetd.conf files (in Linux check the /etc/services and /etc/xinetd.conf files), where port numbers are reserved, to identify some port numbers that are already in use. However, not all assigned ports will appear in these files. Some software, including Datatel DMI Listeners, might not have an entry in those files. For Windows, there is no equivalent file where this information is stored.
54
On either UNIX or Windows, you can use the netstat command to identify ports that are currently in use. However, netstat will not identify ports that are assigned but are not in use when you run the command.
Port 9000 Reserved for Datatel Daemon

You will install one Datatel daemon on any computer that hosts any of the following: The local product repository A Colleague database An application server The daemon uses Port 9000. Make sure that you have no other applications using Port 9000 on those computers. However, be aware that the Internet Assigned Numbers Authority (IANA) has assigned port 9000 to the cslistener service (an IRC/communications package). This will cause a conflict with the Datatel daemon configured to run on that same port by default. Therefore, if you need to configure the Datatel daemon after installation to run on a different port, update the port in the DaemonPort parameter of the dmi.ini file in the Daemon installation folder, and then restart the daemon. If the DaemonPort parameter is changed to something other than 9000, then be sure to specify the same port to match in the Daemon Port # field of the Host Connection form for that server in the Hosts tab in SA Valet.
55
Checking Computer Requirements

Operating System Requirement
Colleague Release 18 runs on the Windows, UNIX, and Linux operating systems. Check the Product Certifications page on the Ellucian client website (http://clients.datatel.com/productcertifications) for current information about supported operating system versions.
Note: For more information about Linux, refer to Support Solution 4667: Linux Implementation Support Solutions.
Hardware Requirements
See the Colleague Hardware Configurations Guidelines page on the Ellucian client website at http://clients.datatel.com/solution_updates/ hardware_configurations.cfm for rule of thumb guidelines for hardware. Contact your client sales representative to discuss specific requirements for your site.
56
Installing Supporting Software

Licensing Colleague Application Server Installing the JRE or SDK Creating Supporting Files (UNIX Only) Installing the Datatel Daemons
Page
57 57 58 60
Licensing Colleague Application Server

Colleague Application Server (CAS) is a suite of technology components that Colleague is executed on. Using Release 18 requires that you license CAS. See your client sales representative for more information.
Installing the JRE or SDK

Install Java Runtime Environment (JRE) or the Software Development Kit (SDK) on the following computers: On any PC where SA Valet is installed, install either a JRE or SDK. On Windows servers, install the SDK. The SDK is required to support server mode on Windows as discussed below. For Oracle, install the SDK on the application server computer. The SDK includes the javac program used in generating computed columns for Oracle. For all other UNIX or Linux servers (other than the application server computer for Oracle), you can install either the JRE or the SDK. See AnswerNet page 4527 for current information about the supported versions of Colleague Release 18 supporting software.
57
During Colleague installation, you will be prompted for the path to the directory where JRE or SDK is installed on each server. Use the worksheet in Table 28 on page 100 to record the paths: SDK.Enter the path to the jre directory. Windows example:D:\jdk1.6.0_12\jre UNIX example:/opt/java6/jre JRE. Enter the path to the directory just above the bin directory. For example, if the path to the bin directory is /opt/java6/bin, you would enter / opt/java6.
Server Mode
DMI Listeners perform better when the JRE runs in server mode. To support server mode, do the following depending on your operating system: Windows servers. Instead of installing the JRE, install the Software Development Kit (SDK) on the application server computer and database computer. The SDK includes a JRE that supports server mode. UNIX/Linux servers. The JRE or SDK for your operating system may or may not support server mode. See AnswerNet page 4516 for information about the JRE version for your operating system vendor and whether that JRE supports server mode.
Creating Supporting Files (UNIX Only)

You must create two files that support the Datatel daemon: datatelenv_profile and datateltab. On UNIX computers, information about the location of DMI Listeners (DMI data access servers and DMI application servers) is stored in the /etc/datateltab file. The Datatel daemon writes to this file during installation of a local product repository or application environment, and reads from this file when you start one of those DMI Listeners from SA Valet. The datatelenv_profile file contains system variables and user information that is required for the Datatel daemon to automatically start. These files must be created on any UNIX computer that has a Datatel daemon. You must create these files before creating the product repository or any application environment.
58
Step 1. Log in to the computer using a login with permissions to create files in the /etc directory. For example, use the root login.
Step 2. Navigate to the /etc directory and create a file called datateltab. touch datateltab
Step 3. Still in the /etc directory, create a file called datatelenv_profile. touch datatelenv_profile
Step 4. Add the user that will start the daemon and any required system variables to the datatelenv_profile file. For example: USER=datatel LANG=C LC_ALL=en_US
Step 5. Create a UNIX group containing the logins that you will use to start the Datatel daemon. groupadd daemonusers For example, this group might contain just the single login datatel, if you will always start the daemon with that login.
Step 6. Assign the group permissions to the newly created group. For example: chgrp daemonusers datateltab chgrp daemonusers datatelenv_profile
Step 7. Set the permissions on the datateltab file to 664. chmod 664 datateltab The 6 permission gives read/write permission to the owner and anyone in the group. The login that starts the daemon must have read/write permissions for these files. The 4 permission gives read permission to all others. For example, this would permit Ellucian technical support analysts to view the file for troubleshooting purposes.
Step 8. Set the permissions on the datatelenv_profile file to 755. chmod 755 datatelenv_profile
59
The 7 permission gives read/write permission to the owner and anyone in the group. The login that starts the daemon must have read/write permissions for these files. The 5 permission gives read permission to all others. For example, this would permit Ellucian technical support analysts to view the file for troubleshooting purposes.
Installing the Datatel Daemons

Use this procedure to install the Datatel daemons. You must install one Datatel daemon on every computer that hosts the local product repository, an application server, a Colleague database, or a DMI Listener. A Datatel daemon is not required on the SA Valet PC. The daemon will automatically start at the end of the installation process. Table 15 lists the procedures in this section.
Table 15: Procedures for Installing and Starting the Datatel Daemons Procedure
Prerequisites and Requirements for UNIX or Linux Permissions for UNIX Prerequisites and Requirements for Windows Stopping the Daemon (Replacement Only) Procedure for Installing a Datatel Daemon on Windows Procedure for Installing a Datatel Daemon on UNIX/Linux Daemon Auto-Start Setup (UNIX/Linux Only)
Page
61 62 63 63 65 68 71
60
Prerequisites and Requirements for UNIX or Linux

Before installing the daemons, do the following on each computer where you will install a daemon: Create the datateltab and datatelenv_profile files. Make sure that any logins that you will use to start the daemon have read/ write permissions for these files.
Technical Tip: Environment variables that are required to establish an Oracle connection must be set within the /etc/datatelenv_profile configuration file (such as TNS_ADMIN).
Note: Changes to the datatelenv_profile do not take effect until the Datatel daemon is restarted and any associated DMI Listeners have been bounced.
For the procedure, see Creating Supporting Files (UNIX Only) on page 58.
UNIX/Linux Login and Shell Requirements

During the installation of the daemon, you will need to enter the login and password for a user on the UNIX or Linux machine. At the completion of the Daemon install, this user will be the owner of the daemon process; create the user if it does not already exist. That user must have the following permissions: Read/write privileges to the datateltab and datatelenv_profile files in the / etc directory. Read/write/execute privileges to the /tmp directory. Read/write/execute privileges to the directory where you will install the daemon.
61
In addition, this login must meet the following requirements: The login sequence cannot be interactive. The default shell for the login must be the Korn shell (ksh). You can specify the Korn shell for that user in the /etc/passwd file. (Oracle clients only) The login profile must set the Oracle system variables ORACLE_HOME, ORACLE_BASE and ORA_NLS10. (Solaris clients only) Modify the login profile to set the environment variable LC_ALL=en_US for the user starting the DMI Listeners.
Note: (For institutions using Oracle 10g) If you are running both Oracle 10g and Oracle 11g or Oracle 11g Release 2 on the same server, leave the Oracle system variables that are set in the login profile for the user starting the DMI Listeners to the Oracle 10g paths, until all environments are running on Oracle 11g or Oracle 11g Release 2.
The login profile for all users is stored in the /etc/profile file for the Korn shell and Bourne shell, and in the /etc/csh.login file for the C shell. If you cannot easily change the login profile to be non-interactive because the login profile is shared among several users, do the following: For the login that you will enter in the InstallShield, change the entry in / etc/password to specify a shell that is not in use at your school and that uses a different file for the login profile. Set up the login profile associated with that shell to set up all necessary system variables. If that shell is the Bourne or C shell, change to the Korn shell by including the command /bin/ksh in the login profile. This allows you to create a non-interactive login for use with the install without having to disrupt other users.
Permissions for UNIX

The Datatel daemon user should have permissions to execute the following commands. HP grep -i Physical /var/adm/syslog/syslog.log swapinfo -a echo selclass qualifier cpu;info;wait;infolog |
62
/usr/sbin/cstm uname -a SUN prtconf swap -l psrinfo -v uname -a AIX lsattr -El mem0 lsps -a lsdev -Cc processor lsattr -El proc0 uname -a Linux free cat /proc/cpuinfo uname -a
Prerequisites and Requirements for Windows

The InstallShield must be run from the windows server where this daemon is being installed. The user running the install must have administrator privileges on the Windows server.
Stopping the Daemon (Replacement Only)

If you are replacing an existing daemon, you must first stop the existing daemon. Use the appropriate procedure below for your operating system.
Stopping the Daemon on UNIX or Linux

To stop the daemon, locate the process ID and kill the process. To locate the process ID, enter the following command at the UNIX prompt: ps -ef | grep java
63
This command displays all running Java processes with their process IDs, enabling you to identify and kill the daemon process. The daemon process will be displayed with a line similar to the following: /opt/java6/jre/bin/PA_RISC2.0/java -Xmx512m -cp dmilistener.jar com.datatel.server.listener.DMIServerListener -ndaemon Ellucian recommends using the kill -15 command to stop the daemon process.
Stopping the Daemon on Windows

If you started the daemon from the installation folder using the startlistener.bat file, enter CTRL+C in the DOS-type daemon window to stop the daemon. If you started the daemon as a Windows service, use the procedure below. The daemon starts as a Windows service when it is automatically started after installation and after machine reboot.
64
Step 1. From the Windows Control Panel, open the Services folder.
Step 2. Select the DatatelDaemon service.
Step 3. From the Action menu, select Stop to stop the daemon.
Procedure for Installing a Datatel Daemon on Windows

Note: If you are replacing an existing daemon and installing into the existing directory, do the following before performing the procedure below:
1. Stop the daemon using the procedure on page 63. 2. Copy the dmi.ini, vaultPKI.p12, and dmi.keystore files off to another location. Also, copy the ./security/clientcas folder if you installed or updated any certificates in that directory. 3. Delete all contents from the daemon folder where the daemon is installed.a 4. After upgrading the daemon Listener, copy the files back to the daemon directory. If you copied the ./security/clientcas folder, also copy that folder back to its original location.
a. If you are using an SSL connection for any of your application listeners, then the vaultPKI.p12 for that secure connection is stored in the security directory under the daemon listener.
Step 1. Download the Datatel daemon from the Ellucian website, clients.datatel.com/ solution_updates/softwaredownloads.cfm.
Step 2. Download the InstallShield file to your PC. The file will have a name like DatatelDaemon150setup.exe.
Step 3. Run the file you just downloaded.

Note: If your institution uses Windows Server 2008, you must rightclick the file you just downloaded and choose Run as Administrator. If you do not do this, the Datatel daemon will not install successfully.
Step 4. On the Welcome window, click Next to continue.
65
Step 5. On the Customer Information window, shown in Figure 13 on page 66, enter your organization name and the code and password provided to you by Ellucian. Then click Next to continue.
Figure 13: Organization Verification Window
The installation program contacts Ellucian and uses the organization code and password that you entered to confirm the identity of your institution.
Step 6. On the License Agreement window, select I Accept the terms of the license agreement if you accept the license agreement. Then click Next to continue.
Step 7. In the Destination Folder window (Figure 14), enter the full path to the folder where you want to install the daemon. If you use the directory recommendations in Directory Structure on page 49, a suggested location is under datatel\coll18\daemon. However, you can install the daemon anywhere on the machine. If the directory does not exist, it will be created during the installation. Click Next to continue.
66
Figure 14: Daemon Installation Path
Step 8. In the Java JRE directory window (Figure 15), enter the full path to the directory where the java.exe file is installed. Click Next to continue.
Figure 15: Java JRE Directory Window
67
Step 9. On the Ready to Install window, click Install to begin the installation process.
Step 10. On the Installation Wizard Completed window, click Finish to exit the InstallShield. The daemon will automatically start after it is installed.
Procedure for Installing a Datatel Daemon on UNIX/ Linux

Note: If you are replacing an existing daemon and installing into the existing directory, do the following before performing the procedure below:
1. Stop the daemon using the procedure on page 63. 2. Copy the dmi.ini, vaultPKI.p12, and dmi.keystore files off to another location. Also, copy the ./security/clientcas folder if you installed or updated any certificates in that directory. 3. Delete all contents from the daemon folder where the daemon is installed.a 4. After upgrading the daemon Listener, copy the files back to the daemon directory.
a. If you are using an SSL connection for any of your application listeners, then the vaultPKI.p12 for that secure connection is stored in the security directory under the daemon listener.
Step 1. Download the Datatel daemon from the Ellucian website, clients.datatel.com/ solution_updates/softwaredownloads.cfm.
Step 2. Save the InstallShield file to your PC. The file will have a name like DatatelDaemon150UNIXsetup.exe.
Step 3. Run the file you just downloaded.
Step 4. On the Welcome window, click Next to continue.
Step 5. On the Customer Information window, shown in Figure 16, enter your organization name and the code and password provided to you by Ellucian. Then click Next to continue.
68
Figure 16: Customer Information Window
The installation program contacts Ellucian and uses the organization code and password that you entered to confirm the identity of your institution.
Step 6. On the License Agreement window, select I Accept the terms of the license agreement if you accept the license agreement. Then click Next to continue.
Step 7. In the Destination Folder window (Figure 17), enter the temporary path to the folder where you want to install the TAR file containing the daemon software. You will transfer this file to your UNIX or Linux server later in this procedure. If the directory does not exist, it will be created during the installation. Click Next to continue.
69
Figure 17: Temporary Destination Folder Window
Step 8. On the Installation Wizard Completed window, click Finish to complete the installation.
Step 9. Navigate to the directory where you installed the TAR file. Transfer this file to your UNIX or Linux server.
Note: Use binary mode if you are transferring the file to the UNIX or Linux server using ftp.
Step 10. Unpack the TAR file to the installation directory. If you are going to install the daemon into a directory where an older daemon was installed, you must make backups of the following files and delete the remainder of the contents of the directory. dmi.keystore vaultPKI.p12
Step 11. Edit the datateltab file in the /etc directory, following the syntax below: 0:daemon:<path for the daemon home directory>:<path to java bin directory>:Y For example: 0:daemon:/datatel/coll18/daemon/:/usr/java/jre1.6.0_12/bin:Y
70
Step 12. Edit the JRE entry in the startlistener script in the Daemon home directory. For example: JRE=/usr/java/jre1.6.0_12/bin/java.
Step 13. Start the Daemon by executing datatelmgr start daemon in the scripts directory.
Step 14. Continue below with Daemon Auto-Start Setup (UNIX/Linux Only).
Daemon Auto-Start Setup (UNIX/Linux Only)

The daemon can be set to automatically restart whenever the computer that hosts the daemon is restarted. To use this capability for UNIX or Linux, you must add the start script to the UNIX boot sequence. For the procedure, see Managing Colleague Software Environments. For Windows, no setup is required; the daemon is set for auto-restart.
ALERT! Ellucian strongly recommends that UNIX clients set the daemon and all Listeners to auto-start. Otherwise, when you restart the Listener, you will be prompted for a username and password. That username and password are stored in the process command stack and can be viewed by other users (for example, by using the ps command).
71
Setting Up UniData for the Colleague Executables

Note: This section applies to all clients, even those using Oracle or SQL Server for their databases.
This section contains procedures for installing and configuring UniData for the Colleague executables. Table 16 lists the topics covered in this section.
Installing UniData Configuring UniData on the Application Server Computer Installing the Oracle Client on the Application Server (Oracle Only) Creating Administrative Users on the Application Server Computer
Page
72 73 77 77
Installing UniData
Step 1. On the application server computer, install the UniData RDBMS as instructed by your UniData documentation. Check the Product Certifications page on the Ellucian client website (clients.datatel.com/productcertifications) for current information about supported RDBMS versions.
Note: You do not need to create the UniData account (equivalent to a SQL Server database or Oracle instance) for the Colleague executables. The Colleague installation program automatically creates the UniData account.
72
Configuring UniData on the Application Server Computer

Resizing the Master VOC File
When you create a new application environment using the procedure beginning on page 141, one of the files created will be the VOC file for the UniData account for the Colleague executables. The size of that VOC file is based on the size of the master VOC file in the UniData RDBMS installation. The default VOC file size, as delivered, is too small for Colleague requirements, and can cause the VOC file to go into Level 2 overflow after installation. To prevent this problem, use the procedure below to resize the master VOC file now, before creating any application environments. By resizing the master VOC file, you ensure that the VOC file in each new application environment is properly sized when it is created.
Step 1. At the operating system prompt, navigate to the sys directory that contains the master VOC file. Windows example: D:\IBM\ud73\sys
Step 2. Enter the following: memresize VOC 1361,16 The modulo/block size combination of 1361,16 is based on experience with installed Colleague Release 18 environments.
73
Adjusting UniData Environment Variables

Step 1. Ensure that the users $PATH contains $UDTBIN. On the Application Server computer, Colleague administrative and end-users need to have the $UDTBIN variable appended to their $PATH. You can set the variable in the global system profile (typically /etc/profile for ksh) or in each users $HOME/.profile. See your Operating System documentation for additional information.
Step 2. The UniData vfieldsize environment variable determines how much space to allocate to each user for evaluating virtual fields. If this variable is not set properly, users may receive error messages when they try to use or compile some virtual fields. This variable should be set to 6000 to allow all virtual fields to operate correctly. Do one of the following to set the vfieldsize environment variable for each user: In the ksh environment, edit each users .profile file (or edit only the /etc/ profile once for all users) and add the following command: export vfieldsize=6000 In the csh environment, edit each users .login file and add the following command: set vfieldsize 6000 In Windows, create a system variable through the Windows Control Panel. For example, in Windows Server 2003, go to Start/Settings/Control Panel/ System. In the System Properties window, select the Advanced tab and then click the Environment Variables button. In the System Variables section, click the New button to create the system variable (Figure 18).
Figure 18: Creating the VFIELDSIZE System Variable for Windows
74
Step 3. In some cases, users may receive error messages because too many dynamic files are open. Do the following to correct this problem: a. Shut down your database management system. b. Edit the udtconfig file, which is stored in the /usr/ud/include directory. c. Find the line that contains the command SHM_FIL_CNT=x, where x is a number. d. Change the number x to increase the amount of shared memory used to handle dynamic files. This number should represent the total number of dynamic files that can be open on your system (in all accounts), rounded to the nearest multiple of 1024. Calculate the proper value of SHM_FIL_CNT by summing the total number of dynamic files in each UniData account. You should change the value of SHM_FIL_CNT only if the total number of dynamic files on your system exceeds the current value of SHM_FIL_CNT. The default value of SHM_FIL_CNT is set to 2048 when UniData is installed. For example, if you have 750 dynamic files each in your live, test, education, and development accounts, your total number of dynamic files is 3000. Round this number up to the next nearest multiple of 1024, which would be 3072. In this case, you would change the command to read SHM_FIL_CNT=3072. e. Restart your database management system.
Step 4. In some cases, users may also receive error messages indicating that too many files are open or that a file cannot be opened. Do one of the following to correct this potential problem: You can change the number of files that your database management system keeps open at once, as follows: a. Determine the current number of files that the operating system allows a user to open at once. This number is defined as a kernel parameter. Use your operating system documentation to determine this number on your system. b. Divide the number of files that can be opened at once by the number of users on your system. c. Subtract 5 from the result. Use the resulting number as the NFILES setting in your udtconfig. If you do not want to change the number of files that your database management system keeps open at once, you can instead change the number of files that are allowed to be opened in your operating system, as
75
follows: d. Determine the NFILES setting in your udtconfig. e. Add 5 to the NFILES number. f. Multiply the result from the previous step by the number of users on your system. g. Reset the kernel parameter for the total number of open files to this resulting number. Keep in mind any other activity on your system and increase this number accordingly. Remember to recompile the kernel and use the new kernel on your next system reboot.
Setting UniData Configuration Parameters

Ellucian recommends resetting your UniData baseline configuration settings following a change in any of the following parameters: UniData version Number of users (this might change, for example, when you add an application environment) Computer memory If this is a new UniData installation, or if any of those parameters have changed since you last reset the baseline configuration, do the following:
Step 1. Make a copy of your current udtconfig file.
Step 2. Have all users logout of UniData and UNIX.
Step 3. Shut down UniData.
Step 4. Start SA Valet, then access Tools > Baseline Configurator.
Step 5. Click Calculate Recommended Values and make changes to the current udtconfig and kernel parameter values as suggested.Click Get default Values to populate the form with the default values obtained from running a systest-f command. Click Get udtconfig Values to populate the form with the current values from the udtconfig file.
76
Step 6. Save your changes and reboot your system.
Step 7. Restart UniData.
Installing the Oracle Client on the Application Server (Oracle Only)

If you plan to use the Execute SQL Statements (ESQL) form (the Envision interface to Oracles SQL*Plus), then install the Oracle client on the application server computer. The ESQL form uses a direct call to Oracles SQL*Plus on the application server, and therefore requires the Oracle client. See the Oracle web site for the Oracle client installation procedures.
Note: Ellucian does not recommend the use of ESQL and it may be deprecated in future versions of Colleague. If your institution does not use the ESQL form you do not need to install the Oracle client on the application server.
Creating Administrative Users on the Application Server Computer

On the application server computer, create one or more operating system logins. These operating system logins will be used for the Colleague executables. If you are using the UniData database, they will also be used for the local product repository and the Colleague databases. At this time, you should create a single administrative login, or in order to have greater flexibility in granting access to Colleague, create separate logins for the local product repository and each application environment. For example, if you have separate logins, you could provide the login for the production environment to only a few people, but the login for the test environment to a larger group. The examples in this manual use a single administrative login.
77
The logins must have privileges to read/write/execute in the directories where the Colleague executables will be installed (and in the directories where the Colleague data will be installed, if you are using the UniData database). The logins must also have privileges to the UniData demo account (such as C:\IBM\ud73\demo). Use the worksheet in Table 29 on page 101 to record your usernames. (For security, Ellucian recommends that you not record passwords on the worksheet.) You will be prompted for these usernames and passwords during Colleague installation. These logins will be used during Colleague operation to start and stop the associated DMI Listeners. For that reason, Ellucian recommends that usernames not be associated with an individual. For example, dont use the username jlsmith. When J. L. Smith leaves your institution and you disable that login, Colleague will not work.
Note: SA Valet is not intended to manage your logins and access groups.
Technical Tip: Any user that is given the same permissions as an administrator will be able to login to each repository/database and start/stop the DMI Listeners using their own username.
78
Setting Up UniData Databases on the Application Server Computer
Setting Up UniData Databases on the Application Server Computer

Establishing Free Space for File Updates
UniData requires that a certain amount of free space be available when files are updated. The larger the file, the greater the free space required. To ensure that enough free space is available, Rocket Software recommends that the largest partition available be configured at the end of the parttbl definition. This allows other partitions to fill first and keep this largest file partition available as free space. Software items delivered by Ellucian will be stored in the RELEASE_ITEM_ITEMS file in the local product repository. This is a large file, and it is updated any time you download software updates from Ellucian or when you upload your own release packages into the product repository. For this file, following Rocket Software's guidelines, you will need at least 1 GB of free space available. You may have more than that already available to handle growth in other large files (like STUDENT.ACAD.CRED and AR.INVOICE.ITEMS). If not, prepare to have at least 1 GB of free space available.
79
Setting Up Databases and Administrative Users on the Database Computer

Note: You can skip this section if you are using the UniData database. If that is your situation, use the procedures in Setting Up UniData Databases on the Application Server Computer beginning on page 79.
All clients must install the appropriate relational database management system (RDBMS) and create databases for the local product repository and Colleague data. See the page listed in Table 17 for your RDBMS.
Table 17: Location of Procedures for Creating Databases RDBMS
SQL Server Oracle UniData
Page
81 87 93
80
Setting Up SQL Server

Table 18 lists the SQL Server procedures in this section.
Table 18: SQL Server Setup Procedures Procedure
Installing SQL Server Creating Databases and Administrative Users for SQL Server Configuring SQL Server 2008 Setting up a SQL Server 2008 Database to Use C# Code Update Computed Column Parameters (SQL Server and Oracle Only)
Page
81 82 84 85 168
Installing SQL Server

On the database computer, install the SQL Server RDBMS as instructed by the vendor documentation. If the local product repository and Colleague database are on different computers, you will need to install the RDBMS on both computers. Check the Product Certifications page on the Ellucian client website (clients.datatel.com/productcertifications) for current information about supported RDBMS versions.
SQL Server Must Have ANSI Padding Enabled

ANSI padding must be enabled in SQL Server for successful installation. If ANSI padding is not enabled, you can experience data trimming issues. Figure 19 shows an example of enabling ANSI padding for the entire database instance. This is the recommended approach for enabling this setting (instead of per environment) so any future environments will also inherit this setting.
81
Figure 19: Enabling ANSI Padding for the Database Instance
Creating Databases and Administrative Users for SQL Server

Step 1. Create a database for the local product repository and one for each Colleague application environment. If desired, you can use a script to create a database. See page 84 for a sample script.
82
Use the worksheet in Table 30 on page 101 to record your database names. You will be prompted for these database names during Colleague installation. In order to clarify the relationship between the databases and the Colleague directories on the database computer, Ellucian recommends the following convention for database names: For the local product repository, use the same name as the release directory (coll18 in the example directory structure in Figure 11 on page 52). For the Colleague database, use the release directory and environment directory, joined with an underscore. See the examples in Table 30 on page 101.
Step 2. For each database that you created in Step 1, create a database user (using SQL Server authentication) with administrative privileges to create database tables and to create and edit data. For each application environment, the username and password must match the username and password for the operating system login that you created on the application server for that application environment (see Creating Administrative Users on the Application Server Computer on page 77).
SQL Server Script for Creating the Database

For SQL Server, you can use a script to create a database. Figure 20 on page 84 shows a sample script for using the CREATE DATABASE statement to create the local product repository database in SQL Server. Note the following: The database is on a separate physical drive (Drive D) from the transaction log (Drive E). This is expected to provide performance benefits because SQL Server will be writing to the transaction log at the same time it is writing to the database. The COLLATE statement defines alphanumeric sorting. Use Latin1_General_BIN as shown in the example. For a Colleague database, you would use a similar script, except that you would enter the database name (such as coll18_test) in place of the local product repository name (coll18).
Note: If you copy the script in Figure 20 from this PDF file, first paste it into a text editor (such as Windows Notepad) to remove hidden characters and then copy it from to the SQL application. If you copy directly from PDF to SQL, the script may not execute properly. However, this suggested copy and paste process might remove valid carriage returns. After pasting the text in the query window, compare your script to Figure 20 and enter carriage returns if necessary.
83
Figure 20: Sample CREATE DATABASE Script for Creating the Local Product Repository in SQL Server
CREATE DATABASE coll18 ON PRIMARY ( NAME = coll18_dat01, FILENAME = 'D:\sqlsvr\data\coll18_dat01.mdf', SIZE = 500MB, MAXSIZE = UNLIMITED, FILEGROWTH = 10% ), FILEGROUP IDX ( NAME = coll18_idx01, FILENAME = 'D:\sqlsvr\data\coll18_idx01.ndf', SIZE = 250MB, MAXSIZE = UNLIMITED, FILEGROWTH = 10% ) LOG ON ( NAME = 'coll18_log01', FILENAME = 'E:\sqlsvr\txlog\coll18_log01.ldf', SIZE = 500MB, MAXSIZE = UNLIMITED, FILEGROWTH = 10% ) COLLATE Latin1_General_BIN GO
Note: The script above is also available in AnswerNet document 34351.59. You can use the version in the AnswerNet document if the line breaks are removed when copying and pasting the script.
Configuring SQL Server 2008

Using Common Language Runtime (CLR) Integration
CLR provides an environment for running Microsoft .NET Framework or managed code. The CLR provides features such as just-in-time (JIT) compilation of code, memory allocation/management, exception handling, and security. You can define stored procedures, triggers, functions, types, and aggregates using managed code. Managed code compiles to native code prior to execution and can result in increased performance. The CLR hosted in Microsoft SQL Server is known as CLR integration. To enable CLR integration, the database administrator must have ALTER SETTINGS server level permission, which is held by the sysadmin and serveradmin fixed server roles.
84
Setting up a SQL Server 2008 Database to Use C# Code

The database administrator runs a command (or two for a migrated database) before computed columns can be deployed.
Enabling CLR Integration

The default is off for the common language runtime (CLR) integration feature. You must enable this feature before using objects that are implemented using CLR integration. Enable CLR integration by setting the clr enabled option of the sp_configure stored procedure to 1. sp_configure 'show advanced options', 1; GO RECONFIGURE; GO sp_configure 'clr enabled', 1; GO RECONFIGURE; GO Disable CLR integration by setting the clr enabled option to 0.
Note: When you disable CLR integration, SQL Server stops executing all CLR routines and unloads all application domains.
85
Allocating Memory
When you install SQL Server, Setup writes a set of default startup options in the Microsoft Windows registry. You can use these startup options to specify an alternate master database file, master database log file, or error log file. If your computer is configured with a large amount of memory and a large number of processors, then CLR integration may fail to load when starting the server. Start the server using the -gmemory_to_reserve SQL Server service startup option. Specify an adequately large memory value. -g memory_to_reserve This option specifies an integer number of megabytes (MB) of memory that SQL Server leaves available for memory allocations within the SQL Server process and outside the SQL Server memory pool. SQL Server uses memory outside of the memory pool to load items such as extended procedure .dll files and automation objects referenced in Transact-SQL statements. The default is 256 MB.
Disable Lightweight Pooling

Use lightweight pooling to reduce the system overhead associated with excessive context switching seen in symmetric multiprocessing (SMP) environments. Lightweight pooling can perform context switching inline and reduce user/kernel ring transitions. If you set lightweight pooling to 1 Microsoft SQL Server switches to fiber mode scheduling. The default value for this option is 0. If you are using the sp_configure system stored procedure to change this setting, you can change lightweight pooling only when show advanced options is set to 1. This setting takes effect after restarting the server. Common language runtime (CLR) execution is not supported under lightweight pooling. You must disable lightweight pooling before enabling CLR integration.
86
Setting Up Oracle
Table 19 lists the Oracle procedures in this section.
Table 19: Oracle Setup Procedures Procedure
Installing Oracle Installing Oracle Patches Creating Instances, Tablespaces, and Users for Oracle
Page
87 87 88
Installing Oracle
On the database computer, install the latest certified release of Oracle Enterprise Edition Database Server. Review the Oracle documentation preinstallation requirements to ensure the system kernel settings have been configured properly for Oracle. Depending on your institution's installation choices, you may need to install Oracle more than once. For instance, you might decide to contain the Release 18 local product repository in an isolated Oracle instance on a separate server, or you might decide to use multiple servers (or logical partitions) for the Oracle instances that will contain the schemas associated with the Release 18 application environments. Check the Product Certifications page on the Ellucian client website (clients.datatel.com/productcertifications) for current information about supported RDBMS versions.
Installing Oracle Patches

Install any major patchsets that Oracle has released for your Oracle Database Server release level.
87
Creating Instances, Tablespaces, and Users for Oracle

Planning Oracle Instances
You may choose to have two or more application environments share an Oracle instance. In the examples in the worksheet in Table 31 on page 102, there is one instance for the local product repository, one for the production application environment, and one shared by the test and development application environments. Sharing an instance may alleviate memory problems, while having separate instances provides additional flexibility for maintenance.
Creating Instances
Perform the steps below for each Oracle instance.
Step 1. Create Oracle instances for Colleague. Use the worksheet in Table 31 on page 102 to record your instance names. You will be prompted for these names during Colleague installation. Use the Oracle DBCA utility to create your instances. Within DBCA, use the Custom Database template. Otherwise, Oracle will use an internal seed database which can introduce an NLS_CHARACTERSET conflict.
Step 2. Set the global database name. The global database name is usually the Oracle database name concatenated with the hostname and domain name. Example: When creating a new Oracle instance with the name lpr01 on the db01 host in the mycollege.edu domain, set the global database name to: lpr01.db01.mycollege.edu.
Step 3. Set the Oracle SID (instance name). See the Example Instance Name column in Table 31 on page 102 for examples.
88
Step 4. Ensure the Oracle JVM is installed. If you are using the Oracle DBCA to create your instance(s), check the Standard Database Components and ensure the Oracle JVM option is checked (it is checked by default).
Step 5. Set the DB_BLOCK_SIZE for the instance; this value cannot be changed after database creation without destroying and recreating the entire database, so choose carefully. (An alternative would be to move data into alternate blocksize tablespaces. See the Oracle documentation for more information on this topic.) If you are not sure what DB_BLOCK_SIZE is appropriate, set the value to match the operating system page size. Execute the following command to display your page size: AIX: pagesize Solaris: pagesize HP-UX: getconf PAGESIZE Linux: getconf PAGESIZE
Step 6. Set the database character set as follows: Default database character set: WE8ISO8859P15 Default national character set: AL16UTF16 - Unicode UTF-16 Universal character set
Step 7. Set the Connection mode to Dedicated Server mode.
Creating Tablespaces
Perform the following steps to create primary and index tablespaces in each instance.
Step 1. Create the following Oracle tablespaces: One tablespace for the local product repository A tablespace for each Colleague application environment
89
Tablespace names. In order to clarify the relationship between the tablespaces and the Colleague directories on the application server computer, Ellucian recommends the following convention for tablespace names: For the local product repository, use the same name as the release directory (coll18 in the example directory structure in Figure 11 on page 52). For the Colleague data, use the release directory and environment directory, joined with an underscore (for example, coll18_test). See the examples in Table 31 on page 102. Exception: For the production environment, the tablespace name should not include the Colleague version number (for example, coll_production). This will ensure that the tablespace name is meaningful in the future when you upgrade your production environment to a later version of Colleague. Tablespace properties. Ellucian recommends the following properties for tablespaces: Locally managed. Automatic segment allocation. Autoextend turned on, with maximum and next sizes defined. Table 20 shows recommendations for the initial and maximum tablespace size.
Table 20: Recommended Tablespace Sizes for Oracle Component
Local product repository Application environment, new Colleague installation
Tablespace Size (Gigabytes) Initial Maximum

2.5 1.0 10.0 site-dependent
Datafile names. Ellucian recommends you create the datafiles associated to an application environment tablespace with the following naming convention: <application environment name>_<instance name>_<consecutive number>.dbf . Example: coll_production_dprod_01.dbf. If an additional datafile needs to be added to the tablespace later, it would be named coll_production_dprod_02.dbf, and so on. Figure 21 shows an example statement for creating a tablespace for an application environment.
90
Figure 21: Example Statement for Creating a Tablespace for a New Colleague Installation
CREATE SMALLFILE TABLESPACE "COLL_PRODUCTION" DATAFILE '/u02/oradata/dprod/ coll_production_dprod_01.dbf' SIZE 1024M AUTOEXTEND ON NEXT 128M MAXSIZE 4096M LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
Step 2. For each application environment tablespace that you created in Step 1 on page 89, create an associated index tablespace. Index tablespace names. The name of each index tablespace must be the name of the associated primary tablespace with _idx appended. Example: If the name of the primary tablespace is coll_production, then the name of the associated index tablespace must be coll_production_idx. Index tablespace properties. Ellucian recommends the following properties for index tablespaces: Locally managed. Automatic segment allocation. Autoextend turned on, with maximum and next sizes defined. Table 20 shows recommendations for the initial and maximum tablespace size.
Table 21: Recommended Index Tablespace Sizes Type of Installation
New Colleague installation
Tablespace Size (Gigabytes) Initial Maximum

1.0 site-dependent
Index datafile names. Ellucian recommends you create the datafiles associated to an index tablespace with the following naming convention: <application environment name>_idx_<instance name>_<consecutive number>.dbf . Example: coll_production_dprod_01.dbf. If an additional datafile needs to be added to the tablespace later, it would be named coll_production_dprod_02.dbf, and so on. Figure 22 shows an example statement for creating an index tablespace for an application environment.
91
Figure 22: Example Statement for Creating an Index Tablespace for a New Colleague Installation
CREATE SMALLFILE TABLESPACE "COLL_PRODUCTION_IDX" DATAFILE '/u04/oradata/dprod/ coll_production_idx_dprod_01.dbf' SIZE 1024M AUTOEXTEND ON NEXT 128M MAXSIZE 5120M LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO BLOCKSIZE 32K
Creating Users
Perform the following procedure in each Oracle instance.
Step 1. Create one Oracle user with the same username and password as the application server administrator (Worksheet Item U on page 101). Grant the privileges listed in Table 22 to that user.
Step 2. For the local product repository and for each Colleague application environment, create an Oracle user whose default tablespace is the one you created in Step 1 on page 89, and whose username matches the name of the tablespace. Grant the privileges listed in Table 22 on page 92 to that user. Use the worksheet in Table 31 on page 102 to record these usernames. (For security, Ellucian recommends that you not record passwords on the worksheet.) You will be prompted for these usernames and passwords during Colleague installation.
Table 22: Oracle Privileges Required for Administrative Users Oracle Privilege
ALTER ANY INDEX ALTER ANY TABLE ALTER ANY PROCEDURE ALTER SESSION CREATE ANY INDEX CREATE ANY TABLE CREATE ANY PROCEDURE CREATE ANY VIEW CREATE PUBLIC SYNONYM CREATE SESSION
92
Table 22: Oracle Privileges Required for Administrative Users Oracle Privilege
DELETE ANY TABLE DROP ANY INDEX DROP ANY TABLE EXECUTE ANY CLASS EXECUTE ANY PROCEDURE INSERT ANY TABLE LOCK ANY TABLE SELECT ANY DICTIONARY SELECT ANY TABLE UNLIMITED TABLESPACE UPDATE ANY TABLE
Setting Up UniData on the Database Computer

The discussion below refers to detailed procedures in the section on setting up a UniData environment on the application server computer.
Installing UniData on the Database Computer

On the database computer, install the UniData RDBMS. Check the Product Certifications page on the Ellucian client website (clients.datatel.com/productcertifications) for current information about supported RDBMS versions.
Creating Administrative Users for UniData on the Database Computer

Use the procedure in Creating Administrative Users on the Application Server Computer on page 77.
93
Configuring UniData on the Database Computer

Table 23 lists the steps required to configure UniData on the database computer. For the detailed procedures, see the page of this manual identified in Table 23.
Table 23: Steps to Configure UniData on the Database Computer Procedure
Resize the master VOC file. Set UniData configuration parameters. Establish free space for file updates.
Reference
94
Application Environment Preparation
Application Environment Preparation

After installing Colleague, you will use User Interface (UI) to access Colleague forms for post-installation processes. You must first set up your new application environments to make them available in UI. See User Interface 4.x Installation and Administration for detailed instructions.
Worksheets
Use the worksheets in this section to record information about the new (target) application environment. You may want to copy these worksheets (or print them from the PDF file) and record the information on the copies. This method makes the worksheets easily accessible both when you are filling them out and when you are referring back to your entries. The installation procedures later in this manual refer back to the ID column in each worksheet for the appropriate worksheet entries.
Table 24: Worksheet: Application Environment Names (Discussion on page 49) Application Environment
Production Test Development Others
Example Application Environment Name

production test development
Enter Your Application Environment Name
ID
Aa
a. During installation, specify the name for the application environment you are installing (such as production, test, or development).
95
Directory Structure Worksheet for SQL Server or Oracle

Table 25: Worksheet: Software Installation Paths for SQL Server or Oracle (Discussion on page 49) Component
Local product repository Application environment (production)
96 Application environment (test) Installation Procedures, February 21, 2013 Application environment (development)
Installed Software
DMI data access server for the local product repository DMI data access server for the Colleague database Colleague executables DMI application server DMI data access server for the Colleague database Colleague executables DMI application server DMI data access server for the Colleague database Colleague executables
Example Patha (see Figure 11 on page 52)

U)/datatel/coll18/repository_das W)D:\datatel\coll18\repository_das U)/datatel/coll18/production/das W)D:\datatel\coll18\production\das U)/datatel/coll18/production/apphome W)D:\datatel\coll18\production\apphome U)/datatel/coll18/production/svr01 W)D:\datatel\coll18\production\svr01 U)/datatel/coll18/test/das W)D:\datatel\coll18\test\das U)/datatel/coll18/test/apphome W)D:\datatel\coll18\test\apphome U)/datatel/coll18/test/svr01 W)D:\datatel\coll18\test\svr01 U)/datatel/coll18/development/das W)D:\datatel\coll18\development\das U)/datatel/coll18/development/apphome W) D:\datatel\coll18\development\apphome U)/datatel/coll18/development/svr01 W)D:\datatel\coll18\development\svr01
Enter Your Installation Path
ID
B
Cb Db Eb Cb Db Eb Cb Db
DMI application server
Eb
a. U = UNIX example; W = Windows example. b. During installation, specify the path for the application environment you are installing (such as production, test, or development).
Directory Structure Worksheet for UniData

Table 26: Worksheet: Software Installation Paths for UniData Component
Installed Software
Local product repository data account DMI data access server for the local product repository
Example Patha (see Figure 12 on page 53)

U)/datatel/coll18/coll18 W)D:\datatel\coll18\coll18 U)/datatel/coll18/repository_das W)D:\datatel\coll18\repository_das U)/datatel/coll18/production/das W)D:\datatel\coll18\production\das U)/datatel/coll18/production/apphome W)D:\datatel\coll18\production\apphome U)/datatel/coll18/production/svr01 W)D:\datatel\coll18\production\svr01 U)/datatel/coll18/test/das W)D:\datatel\coll18\test\das U)/datatel/coll18/test/apphome W)D:\datatel\coll18\test\apphome U)/datatel/coll18/test/svr01 W)D:\datatel\coll18\test\svr01 U)/datatel/coll18/development/das W)D:\datatel\coll18\development\das U)/datatel/coll18/development/apphome W)D:\datatel\coll18\development\apphome U)/datatel/coll18/development/svr01 W)D:\datatel\coll18\development\svr01
Enter Your Path
ID
F G Hb Ib Jb Hb Ib Jb Hb Ib Jb
DMI data access server for the Colleague database Colleague executables and data DMI application server
Worksheets
a. U = UNIX example; W = Windows example. b. During installation, specify the path for the application environment you are installing (such as production, test, or development).
98
Table 27: Worksheet: DMI Listener Ports (Discussion on page 54) (Sheet 1 of 2) Unsecure Port Enter Example Your Port
7200
Component
Local product repository Application environment (production)
DMI Listener
DMI data access server for the local product repository DMI data access server for the Colleague database DMI application server Reserved for other DMI Listeners to be installed later
ID
K Ma Oa
Secure Port Enter Example Your Port

7300
ID
L Na Pa
DMI data access server for the Colleague database DMI application server Reserved for other DMI Listeners to be installed later
Ma Oa
Na Pa
Table 27: Worksheet: DMI Listener Ports (Discussion on page 54) (Sheet 2 of 2) Unsecure Port Enter Example Your Port Secure Port Enter Example Your Port
Component
DMI Listener
DMI data access server for the Colleague database DMI application server Reserved for other DMI Listeners to be installed later
ID
Ma Oa
ID
Na Pa
a. During installation, specify the port number for the application environment you are installing (such as production, test, or development).
Worksheets
100
Table 28: Worksheet: JRE Paths (Discussion on page 57) Computer where these components are installed
Example Path to JREa

U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre
Enter Your Path to JRE
ID
Q
Colleague data Colleague executables
Rb
Sb
Rb
Sb
Rb
Sb
a. U/JRE = UNIX example with the JRE installed U/SDK = UNIX example with the SDK installed (the SDK is required for Oracle on the application server computer) W = Windows example with the SDK installed b. During installation, specify the JRE path for the application environment you are installing (such as production, test, or development).
Table 29: Worksheet: Colleague Administrative Users (Discussion on page 77) Database
Local product repository Colleague database (production) Colleague database (test) Colleague database (development)
Example Username
administrator administrator administrator administrator
Enter Your Username
ID
T Ua
a. During installation, specify the username and password for the application environment you are installing (such as production, test, or development).
Table 30: Worksheet: SQL Server Database Names (Discussion on page 82) Database
Local product repository Colleague database (production) Colleague database (test) Colleague database (development)
Example Database Name

coll18 coll18_production coll18_test coll18_development
Enter Your Database Name
ID
V Wa
a. During installation, specify the database name for the application environment you are installing (such as production, test, or development).
Worksheets
Table 31: Worksheet: Oracle Instances and Usernames (Discussion on page 88) Component
Local product repository App environment (production) App environment (test) App environment (development)
102 Installation Procedures, February 21, 2013
Example Instance Namea

dlpr11 dprodc dtest11 dtest11
Enter Your Instance Name
ID
X Zd
Example Username
coll18 coll_production coll18_test coll18_development
Enter Your Usernameb
ID
Y AAd
a. In these example instance names, d indicates Datatel and 11 indicates Oracle version 11. b. This is the username that matches the tablespace name. See Step 2 on page 92. c. For the production environment, instance names and usernames should not include numbers indicating the Oracle or Colleague version. This will ensure that these names are meaningful in the future when you upgrade your production environment to a later version of Colleague. d. During installation, specify the database name for the application environment you are installing (such as production, test, or development).
Release System
Release System 22
Installing SA Valet
In This Chapter
This chapter provides procedures for installing SA Valet. See Installation of SA Valet on page 30 for a description of what is installed when you perform this procedure. Table 32 lists the topics covered in this chapter.
SA Valet Installation Overview Before You Begin Installing SA Valet Installing JDBC Drivers (Oracle Only) Setting Up Hosts in SA Valet Defining LPR and Host Properties in a Second SA Valet Securing the Connection Between SA Valet and the Datatel Daemon
Page
106 107 110 115 116 118 119
105
Release System: Installing SA Valet
SA Valet Installation Overview

You might be upgrading an earlier version of SA Valet, installing SA Valet for a new Colleague installation, or installing SA Valet on a second computer in order to manage an existing Colleague installation. Table 33 shows the procedures to perform in each case.
Table 33: Procedures for Installing SA Valet Situation
Upgrading an earlier version of SA Valet to 2.9.0 for an existing Colleague installation. Installing SA Valet as the first step in your Colleague installation.
Perform these procedures

Run the SA Valet 2.9.0 InstallShield See Quick Start: Upgrading SA Valet on page 109 for more information. Installing SA Valet on page 110 Installing JDBC Drivers (Oracle Only) on page 115 Setting Up Hosts in SA Valet on page 116 Securing the Connection Between SA Valet and the Datatel Daemon on page 119
Installing SA Valet on a second computer in order to manage an existing Colleague installation.
Installing SA Valet on page 110 Installing JDBC Drivers (Oracle Only) on page 115 Defining LPR and Host Properties in a Second SA Valet on page 118 Securing the Connection Between SA Valet and the Datatel Daemon on page 119
106
Before You Begin
Before You Begin

Make sure that the computer on which you are installing SA Valet meets the following requirements: Currently Supported Operating System and System Infrastructure software (see http://clients.datatel.com/solution_updates/certifications_cessations/ certifications_search.cfm for current requirements).
Note: See AnswerNet page 4527 for current information about supported JRE or SDK versions for use with Colleague. You may get an error when installing SA Valet if another version of the JRE is installed. See AnswerNet page 4401 for details.
TCP/IP connection to the Internet (to retrieve licensing information and software from Ellucian) Connections to: Application environment computer Database computer
Software Updates
The software components that make up SA Valet 2.9.0 are delivered in the SA Valet 2.9.0 Installer and also in a software update. Each individual component is backwards compatible and can be installed in any order, but the new features delivered with these components can not be used until all components are installed. See Release Highlights: SA Valet 2.9.0 for more details about the new features delivered with SA Valet 2.9.0. In order to deliver all of the new features of SA Valet 2.9.0, the components are contained in the SA Valet 2.9.0 Installer release.1 The required software components are listed in Table 34.
Technical Tip: Java 6 or 7 and .NET Framework 4 are not included in the SA Valet 2.9.0 release. You must install these components on any PC or server where SA Valet 2.9.0 will be installed prior to installing SA Valet 2.9.0.
1. A software release that is installed directly on a server by way of an InstallShield or other installer.
107
Table 34: Software Components Component

Java 6 or 7 (JRE or JDK) .NET Framework 4 SA Valet 2.9.0 Installer
Description
Software must be installed on any workstation or server where SA Valet 2.9.0 will be installed. Delivers all components needed to run SA Valet on your PC or Windows Server.
There is no specific prerequisite or sequence required for installing the software components listed in Table 34. The software update can be loaded before upgrading to SA Valet 2.9.0. However, the new features delivered with SA Valet 2.9.0 are not enabled until all components are delivered. Ellucian recommends that you keep DMI and all Colleague environments as current as possible to ensure that your institution is using the most recent version of Colleague.
108
Quick Start: Upgrading SA Valet
Quick Start: Upgrading SA Valet

If you already have an existing version of SA Valet that is set up to access your environments, Follow these steps:
Step 1. Retrieve and load the related software updates for SA Valet 2.9.0. The basic features of SA Valet will work without loading these software updates, but the new features will not be available. See Software Updates beginning on page 107 for more information.
Step 2. Run the InstallShield to install SA Valet 2.9.0. Follow the instructions in Installing SA Valet beginning on page 110. Your settings and environment information will be retained after the upgrade.
Step 3. Review the release highlights for SA Valet 2.9.0 to familiarize yourself with the changes and enhancements delivered with SA Valet 2.9.0. If you want to install SA Valet on a second computer, you must follow the procedures in Table 33 on page 106 for Installing SA Valet on a second computer in order to manage an existing Colleague installation.
109
Installing SA Valet
Follow these steps to install SA Valet. Note that your settings from a previous version of SA Valet 2.x are retained in the new version. Then set the Run as administrator option one time as described in the next section.
Step 1. Load the related software updates into the environment(s) you want to use with SA Valet 2.9.0. The basic features of SA Valet 2.9.0 will function when working with a Colleague environment that does not have these software updates loaded, but the new features will not work. See Software Updates beginning on page 107 for more information about the related software updates.
Step 2. From your web browser, access the SA Valet download page on the Ellucian website (http://clients.datatel.com/solution_updates/softwaredownloads.cfm).
Step 3. Download the Installer file to your PC. The file will have a name like SAValet290Setup.exe.
Step 4. If you have an older version of SA Valet installed on the installation computer that has a different minor version number (for example, the new SA Valet is version 2.9.0 and the existing version is 2.8.0), you do not need to uninstall the older SA Valet. The InstallShield will copy your settings from the older SA Valet to the new installation directory, and the older version will remain on the computer until you remove it. To access the prior version of SA Valet after installing 2.9.0, see Running the Prior Version of SA Valet on page 305.
Note: If you have previously installed a public security certificate in the previous version of SA Valet, you will need to manually copy that certificate from the clientcas folder of the previous version to the clientcas folder of SA Valet 2.9.0.
If you have an older version of SA Valet installed on the installation computer with the same major version, the same minor version, but a different point release number you must first uninstall the older SA Valet using the Windows Add or Remove Programs functionality. Your settings are not removed when SA Valet is uninstalled using this method.
110
Installing SA Valet
Step 5. Start the SA Valet Installer (Figure 23).

Figure 23: SA Valet
Step 6. Follow the prompts to install SA Valet. During installation, the Customer Information window (Figure 24) is displayed. Enter your organization name and the code and password provided to you by Ellucian. When you click Next, the installation program automatically contacts Ellucian and uses the organization code and password to confirm the identity of your institution.
Figure 24: Customer Information Window in SA Valet InstallShield
111
The SA Valet installer will prompt you for a new installation path of C:\Program Files (x86)\Ellucian\SAValet 2.9.0 by default. If you have SA Valet 2.8.x installed on this computer, the InstallShield automatically copies the following files from the previous installation: savalet.ini. Contains settings for LPRs and application environments. profile. Located in the security folder vaultPKI.p12. Contains your security settings. All .profile files. These are saved wizard profiles. ojdbc5.jar. (Oracle only).
Self Update Functionality

If you are currently using SA Valet 2.8.0, you can use the self update functionality to install version 2.9.0. After the SA Valet 2.9.0 software update (IN60745.59*10) has been downloaded into your LPR, you will be prompted by SA Valet to install the newer version (Figure 25)
Figure 25: Self Update Prompt
If you click Install Later, you will be prompted to install the update each time you launch SA Valet and connect to the LPR.
Note: You can disable these notifications by clicking Tools > Self Update, and then clearing the Notifications Enabled check box.
If you click Install Now, SA Valet 2.8.0 will download and then start the 2.9.0 installer.
112
Installing SA Valet
Setting the Run as Administrator Options

If you are running SA Valet on Windows Server 2008, Windows Vista, or Windows 7, complete the following procedure after you finish installing SA Valet. For other supported Windows operating systems, you can skip this procedure.
Step 1. For SA Valet 2.9.0, you must set the Run this program as an administrator option for the RelsysAlertsTrayApp.exe file.
Step 2. Go to the C:\Program Files (x86)\Ellucian\SAValet 2.9.0\rsalerts directory.
Step 3. Right-click on the RelsysAlertsTrayApp.exe file and select Properties.
Step 4. Select the Compatibility tab and select the Run this program as an administrator check box (Figure 26).
113
Figure 26: Select Apply and close.SA Valet Properties
a. For SA Valet 2.9.0, you must also set the Run this program as an administrator option for the RunSAValet.bat file. b. Go to the C:\Program Files (x86)\Ellucian\SAValet 2.9.0 directory. c. Right-click on the RunSAValet.bat file and select Properties. d. Select the Compatibility tab and select the Run this program as an administrator option. e. Select Apply and close.
Note: If your operating system does not provide the Run this program as an administrator option for the RunSAValet.bat file, then set it by going to All Programs > Ellucian, and right-clicking on SA Valet 2.9.0 > Properties > Compatibility and selecting the Run this program as an administrator option.
114
Installing JDBC Drivers (Oracle Only)
Installing JDBC Drivers (Oracle Only)

Note: You can skip this procedure if you upgraded from another version of SA Valet. The drivers were copied forward from the previous installation.
JDBC drivers allow Java applications (SA Valet and DMI Listeners) to interact with a SQL-compliant database such as Oracle. Because the driver is not a Ellucian product, you must download it from the Oracle web site.
Step 1. Download the Oracle JDBC driver file. See AnswerNet document 4527 for download instructions and the current supported version of the driver.
Step 2. Copy the driver file to two places in your SA Valet installation (Figure 27 on page 115): The SA Valet/lib folder. The driver file in this folder is used by SA Valet. The SA Valet/Install/dmi/lib folder. Each time you create a DMI Listener from SA Valet (for example, when creating the local product repository or an application environment), the driver file is copied to the lib directory for that DMI Listener, and is later used during Listener operation.
Note: If you ever need to update the JDBC driver, you should copy the new driver file to both lib folders under SA Valet, and to the lib folder under each DMI Listener you have already installed.
Figure 27: SA Valet Folders Where JDBC Drivers Should Be Installed

Program Files (x86) Ellucian SA Valet Install dmi lib lib Copy the JDBC driver file to both of these lib folders
115
Setting Up Hosts in SA Valet

Note: Perform this procedure only if you are installing SA Valet as the first step in your Colleague installation, or adding a new host computer to SA Valet. If you are installing SA Valet on another computer in order to manage an existing Colleague installation, perform the procedure in Defining LPR and Host Properties in a Second SA Valet on page 118 instead.
Use the following procedure to define each Colleague host computer in SA Valet. Each computer that hosts a Datatel daemon and a DMI Listener must be defined in SA Valet.
Step 1. In SA Valet, select the Hosts tab.
Step 2. Right-click the SA Valet node and select Add > Host Connection, as shown in Figure 28.
Figure 28: Selecting the SA Valet Node
Step 3. On the Host Machine Properties form (Figure 29), enter the following: Alias. Name of the host computer as you want it to appear in SA Valet. Host Server Name/IP. IP address or DNS name of that computer.
116
Setting Up Hosts in SA Valet
Figure 29: Example of the Host Machine Properties Form
Step 4. Click OK to create the host computer definition.
117
Defining LPR and Host Properties in a Second SA Valet

Note: Perform this procedure only if you have already installed Colleague and want to connect to it from a second installation of SA Valet.
The following properties must be known to SA Valet, and are stored in the SAValet.ini file: Properties for accessing the local product repository (LPR). Properties for accessing each Colleague host computer. Use the following procedure to establish those properties in a second installation of SA Valet.
Step 1. From an existing installation of SA Valet, copy the SAValet.ini file. The SAValet.ini file is installed with SA Valet (for example, in the C:\Program Files (x86)\Ellucian\SaValet 2.9.0 folder).
Step 2. For the second installation of SA Valet, replace the installed version of the SAValet.ini file with the version that you copied in Step 1.
Note: As an alternative to this procedure, you could view the LPR and host properties in an existing installation of SA Valet, and then enter them in the second installation of SA Valet. However, copying the SAValet.ini file as described above is much simpler and avoids possible data entry errors.
118
Securing the Connection Between SA Valet and the Datatel Daemon
Securing the Connection Between SA Valet and the Datatel Daemon

Ellucian recommends that you secure this connection in order to limit access to the Datatel daemon. See the Managing Colleague Software Environments manual for the procedure.
119
120
Release System 29
Creating the Local Product Repository

In This Chapter
This chapter provides the procedure for creating the local product repository and its DMI data access server. Table 35 lists the topics covered in this chapter.
Before You Begin Procedure for Creating the Local Product Repository
Page
121 122
See Creation of the Local Product Repository on page 31 for a description of what is installed. This procedure creates an empty local product repository. The procedure for populating it with Ellucian software is on page 131.
Before You Begin

Before performing this procedure, read the information in Preparing for the Installation beginning on page 41 and complete the planning and preparation steps described in that chapter.
121
Release System: Creating the Local Product Repository
Procedure for Creating the Local Product Repository

Step 1. In SA Valet, select the Environments tab.
Step 2. Select the SA Valet node.

Figure 30: Selecting the SA Valet Node
Step 3. From the Wizards menu, select Set Up Product Repository. If you have previously performed this procedure, you will see the Previous Entries Found window (Figure 31) which gives you the option to load the values that you entered previously. If you dont see that window, skip to Step 5.
Figure 31: Previous Entries Found Window
Step 4. In the Previous Entries Found window, click Yes if you want your previouslyentered values to populate the fields in this wizard. If you click No, the fields will be blank.
122
Step 5. On the Local Product Repository Setup (1/3) window (Figure 32), review the checklist of procedures that you need to perform before running this wizard.
Figure 32: Local Product Repository Setup (1/3) Window
Step 6. Click Next to continue.
Step 7. On the Local Product Repository Setup (2/3) window, enter the information listed below about the database to be used for the local product repository. Examples of the completed window are shown in Figure 33 on page 125 (SQL Server), Figure 34 on page 125 (Oracle) and Figure 35 on page 126 (UniData). Local Product Repository Name. Name of the local product repository as you want it to appear in SA Valet. The words (Product Repository) will be appended to your entry. For example, if you enter coll18 as shown in Figure 33, it will appear in SA Valet as coll18 (Product Repository) as shown in Figure 39. Host Name. Select the host computer where you want the local product repository to be created. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. Operating System. Type of operating system (UNIX or Windows) on that computer. Database Type. Oracle, UniData, or SQL Server. Database Port. Number of the port that the database uses for communications. The default value displayed in this box is the typical port number for the
123
database type you just selected. Database Name/Path SQL Server. Name of the database that you created for the local product repository (Worksheet Item V on page 101). Oracle. Name of the Oracle instance that you created for the local product repository (Worksheet Item X on page 102). UniData. Path to the directory where you want the installation program to create the account for the local product repository (Worksheet Item F on page 97). Username and Password SQL Server. Valid username and password for the database, with administrative privileges to create database tables and to create and edit data (Worksheet Item T on page 101). This username and password must already exist. If they do not exist, create them using the SQL Server administrative tools. Oracle. Username and password for the Oracle schema that will contain the local product repository (Worksheet Item Y on page 102). This username and password must already exist. If they do not exist, create them using the Oracle administrative tools. UniData. Valid username and password for the computer, with privileges to read/write/execute in the database directories (Worksheet Item T on page 101). This username and password must already exist. If they do not exist, create them using the operating system administrative tools.
124
Figure 33: Local Product Repository Setup (2/3) WindowSQL Server Example
Figure 34: Local Product Repository Setup (2/3) WindowOracle Example
125
Figure 35: Local Product Repository Setup (2/3) WindowUniData Example
126
Step 9. On the Local Product Repository Setup (3/3) window, enter the following information about the DMI data access server that will be installed for the local product repository. Examples of the completed window are shown in Figure 36 on page 128 (SQL Server) and Figure 37 on page 128 (UNIX/ UniData). Some fields are displayed only if you are using the UNIX operating system and/or UniData database. DMI_DAS Port. Number of the non-secure port that the DMI data access server should use for TCP communications (Worksheet Item K on page 98). DMI_DAS Installation Path. Full path to the directory where the DMI data access server (specifically, the dmilistener.jar file) should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item B on page 96. UniData. Worksheet Item G on page 97. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (Worksheet Item Q on page 100). UniData Runtime Path (bin). (Displayed for UniData only) Full path to the bin directory of the UniData installation on the computer where the DMI data access server will be installed. UNIX example:/usr/ud73/bin Windows example:D:\ibm\ud73\bin
Technical Tip: Your entry in this field must match the UniData environment variables. Make sure UDTBIN and UDTHOME match your entry in this field.
Server Group (UNIX only). (Displayed for UNIX/UniData only) Name of the group of UNIX users for this UniData account. In UNIX, access privileges are granted separately to an owner, a group of users, and all other users. For the UniData account created during this installation, the owner is the username that you enter in the Username box on the previous window (Figure 35 on page 126), and the group is the group that you enter in this box. The permissions are based on the umask setting for the owner. Environment Keystore Password. Enter a password to protect the keystore that is created with this installation. The keystore is the file dmi.keystore, created with this installation. The keystore contains the encryption key used to encrypt and decrypt passwords. Record this password in a safe place. You will need to provide it when you want to start the DMI data access server.
127
Figure 36: Local Product Repository Setup (3/3) WindowSQL Server Example
Figure 37: Local Product Repository Setup (3/3) WindowUNIX/UniData Example
Step 10. Click Install to start the installation. The progress of the installation, including a list of installed components, is displayed. At the end of the installation, an installation was successful message is displayed as shown in Figure 38.
128
Figure 38: Windows Displayed During and After Creation of the Local Product Repository
Note: The new DMI data access server will be named lprname_DB_LISTENER (for example, coll18_DB_LISTENER) in the operating system: for example, as a Windows service name or UNIX process ID.
Figure 39: Product Repository Name Displayed in SA Valet After Installation
129
130
Release System 39

In This Chapter
This chapter provides the procedure for placing a full Colleague release package into your local product repository. Two options exist: DVD option. Load the full release package from the Ellucian-provided Release 18 DVD. This option is faster than the Internet option. See Populating the Local Product Repository From the DVD on page 132. Internet option. Download the full release package over the Internet from the Datatel product repository. This process may take several hours. See Populating the Local Product Repository Over the Internet on page 136. See Population of the Local Product Repository on page 32 for a description of what is installed. Table 36 lists the topics covered in this chapter.
Populating the Local Product Repository Populating the Local Product Repository From the DVD Populating the Local Product Repository Over the Internet
Page
132 132 136
Before You Begin

Before performing this procedure, create the local product repository using the procedure in Creating the Local Product Repository on page 121.
131
Release System: Populating the Local Product Repository

Note: When populating the local product repository, the Registry User and the user who starts DMI must be the same.
Populating the Local Product Repository From the DVD

Testing the DVD Drive
If your DVD drive was manufactured before about 2004, it may have a problem accessing the data stored on the DVD. Ellucian recommends that you test the DVD before attempting to populate the local product repository. To test the DVD, attempt to copy the following file from the DVD to a local directory on the computer that hosts the local product repository: For Windows:\coll18\windows\rii_w1.txt For UNIX:\coll18\unix\rii_u1.txt This file is large (roughly 2 gigabytes). If this copy is successful, you will be able to reliably import from the DVD. If it is not, download the release package from the Internet instead as described in Populating the Local Product Repository Over the Internet on page 136.
Note: If you populate from the DVD without performing this test, and if there is a problem with the import, you may not receive an error message.
Refreshing Licensing Information

Before populating the local product repository from the DVD, perform the following procedure to refresh the licensing information stored in the local product repository.
132
Step 1. In SA Valet, connect to the local product repository if not already connected. To connect to the local product repository, right-click the product repository node, select Connect/Start Listener, and enter login information if prompted. You are already connected if the local product repository node is expanded to display application environment nodes.
Step 2. Right-click the product repository node and select View/Update Product Repository from the pop-up menu (Figure 40).
Figure 40: Product Repository Right-Click Pop-up Menu
Step 3. On the Update Local Product Repository window (Figure 41), enter the following information: Organization Code and Organization Password. Your organization code and password, provided to you by Ellucian. Remember organization code and password. If you check this box, the Organization Code and Organization Password fields will already be populated the next time you update the product repository (for example, to retrieve software updates).
133
Figure 41: Entering Organization Code and Password
Step 4. Click OK.
Step 5. In the next Update Product Repository window (Figure 42), click Refresh License.
Figure 42: Refreshing Licensing Information from the Datatel Product Repository
SA Valet will contact the Datatel licensing server to retrieve your current licensing information. During this process, a progress status message is displayed. At the end of the process, a Refreshing licenses is complete message is displayed as shown in Figure 43.
134
Figure 43: Licensing Update Complete
Step 6. Click OK to close the message box.
Step 7. In the Update Product Repository window, click Cancel. Do not click View Available Updates or Download Available Updates; these buttons are used only for retrieving release packages from the Datatel product repository.
Loading the Release Package from the DVD

For SQL Server 2005 and SQL Server 2008, instructions for loading the release package from the DVD are on the Ellucian website (http:// clients.datatel.com/solution_updates/downloads/R18DVDimport.cfm). For all other supported combinations of database type (UniData or Oracle) and operating system (Windows or UNIX), the instructions are on the Release 18 DVD. In addition to the instructions on the DVD, note the following: UniData on UNIX or Linux: One of the steps in populating the local product repository from the DVD is to copy the import utility to the BP directory and then run the convcode command. The import utility will be a file named either _R18.DVD.IMPORT or _r18dvd.imp. Before running the convcode command, you may need to change permissions on the file using the chmod command. Oracle: Before running the DVD load scripts, ensure that the Oracle shell variables have been set in the administrative users UNIX session. Figure 44 shows an example.
135
Figure 44: Example Oracle Shell Variables for Running the DVD Load Scripts
$ $ $ $ $ $ ORACLE_HOME=/u01/app/oracle/product/11.1; export ORACLE_HOME PATH=$ORACLE_HOME/bin:$PATH; export PATH ORACLE_SID=dlpr; export ORACLE_SID NLS_LANG=american_america.we8iso8859p1; export NLS_LANG NLS_DATE_FORMAT='MM/DD/RRRR SSSSS'; export NLS_DATE_FORMAT ORA_NLS10=$ORACLE_HOME/nls/data; export ORA_NLS10
Populating the Local Product Repository Over the Internet

Note: This process will likely take from several hours up to a full day, depending on the number of software updates that must be downloaded as well.
The process for retrieving the full Colleague release package is the same as the process you will periodically use later to retrieve software updates. For the procedure, see Updating Colleague Software.
Local Product Repository (LPR) Tables

APPL_ENVIRON_CONFIG. Each environment built from the LPR will have a row in this table. ENVIRON_RELEASE_PKGS. Tracks release packages loaded into each environment. RELEASE_PKGS. Information about downloaded release packages. RELEASE_ITEMS. Keeps track of the items delivered on a release package. Each item delivered on a package will have a row in this table. RELEASE_ITEM_ITEMS. The actual encrypted item. RELEASE_PKG_PREREQS. Holds information about prerequisite release packages. RELEASE_PKG_GROUPS. Holds a list of all software update groups and their assigned IDs.
136
RELPKG_GROUP_PKGS. Holds information about which software updates are included in a software update group. The group ID is from the RELEASE_PKG_GROUPS file. SU_PARMS. Used by SA Valet to connect with the DPR.
137
138
Application Environment Creation
Application Environment Creation 44

In This Chapter
Perform these procedures for all application environments. This chapter provides the procedure for creating a Colleague application environment, as well as post-creation procedures for upgrading DMI Listeners and Oracle-only upgrade steps. Table 37 lists the topics covered in this chapter.
Before You Begin Retrieving Software Updates Full Release vs. Consolidated Full Release Creating the Application Environment Upgrading DMI Listeners
Page
142 142 142 145 155
Cloning an Existing Application Environment

You will probably want to create multiple application environments, such as production, test, and development. After creating one application environment, you can create others by either repeating the procedures to create an environment or by cloning (making a working copy of) an existing application environment. For example, you might want to create a test environment by cloning your production environment. See Cloning an Application Environment on page 219 for the cloning procedure.
141
Application Environment Creation: Creating the Application Environment
Before You Begin

Before performing this procedure, read the information in Preparing for the Installation beginning on page 41 and complete the planning and preparation steps described in that chapter.
Retrieving Software Updates

Before creating the application environment, update your local product repository by retrieving the latest software updates from Ellucian. These may include IP-type software updates, which are automatically used by the Create Application Environment wizard. When downloading software updates in SA Valet, specify retrieval code CFR2011 to download the latest Consolidated Full Release package (CFR53268.41-1805*16) into your LPR. See Updating Colleague Software for the procedure.
Note: If you no longer need a Consolidated Full Release package in your LPR, you can use the Purge CFR Packages (PCFR) process to remove it.
Full Release vs. Consolidated Full Release

Technical Tip: You must use SA Valet 2.4.0 or newer.
You have two options when installing a new application environment: Full Release or Consolidated Full Release. The differences are discussed below.
142
Full Release vs. Consolidated Full Release
Full Release
Technical Tip: Due to the large number of software updates that will need to be installed, Ellucian highly recommends that you use the latest Consolidated Full Release (CFR) when building new application environments.
The Colleague Full Release (FR) is the initial release of Colleague Release 18. The FR was built on January 30, 2006. Since that time, Ellucian has released many software updates, updates which are not installed initially. After you have installed the full release, you must also install any subsequent software updates that contain new functionality or defect resolutions that you require. Determining which software updates to install is a time-consuming task. You can save time by installing a Consolidated Full Release instead.
Consolidated Full Release

A Consolidated Full Release (CFR) is a software update that includes references to the most recent version of every item released at the Release 18 level at the time the CFR was built (see Figure 45 on page 144 for an example). Installing the CFR installs the FR and also installs the most recent version of every released item.
Table 38: Available Colleague Consolidated Full Releases CFR Package
CFR36020.63-1805*10 CFR53268.41-1805*16
Release Date
February 2008 May 2011
If you do not want to be at the most recent release levels for all items, you must install either the 2006 FR or the 2008 CFR, and then all the software updates that you determine are needed. If the most recent versions of all products are acceptable, you can install the 2011 CFR and save yourself a significant amount of time.
143
Figure 45: Example Items Installed with the Consolidated Full Release
Full Release
Item A Rev 1
Item B Rev 1
Item C Rev 1
Software Update 1
Item A Rev 2
Software Update 2
Item A Rev 3
Software Update 3
Item B Rev 2
Consolidated Full Release
Installing the Full Release (FR) requires you to install all software updates. In order to install the latest version of Item A, you must install Software Update 1 and then Software Update 2.
Installing the Consolidated Full Release (CFR) does not require you to install all software updates. The latest version of Items A, B, and C are automatically installed with the CFR.
144

Follow the procedure below to create an application environment. See Creation of the Application Environment on page 34 for a description of what is installed.
Step 1. In SA Valet, select the Environments tab.
Step 2. Select the node for the local product repository (Figure 46).
Figure 46: Selecting the Local Product Repository
Step 3. Connect to the local product repository if not already connected. To connect to the local product repository, right-click the product repository node, select Open, and enter login information if prompted. You are already connected if the local product repository node is expanded to display application environment nodes.
Step 4. From the Wizards menu, select Set Up Colleague Application Environment, shown in Figure 47.
145
Figure 47: Set Up Colleague Application Environment Menu Option
If you have previously performed this procedure, you will see the Previous Entries Found window (Figure 48) which gives you the option to load the values that you entered previously. If you dont see that window, skip to Step 6.
Step 5. In the Previous Entries Found window, click Yes if you want your previouslyentered values to populate the fields in this wizard. If you click No, the fields will be blank.
Step 6. On the Set Up Colleague Application Environment (1/3) window, enter the information listed below about the Colleague database. Examples of the completed window are shown in Figure 49 on page 148 (SQL Server), Figure 50 on page 148 (Oracle) and Figure 51 on page 149 (UniData). Colleague Environment Name. Name of the Colleague application environment as you want it to appear in SA Valet (Worksheet Item A on page 95)
146
Host Name. Select the host computer where you want the Colleague database to be installed. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. Operating System. Type of operating system (UNIX or Windows) on that computer. Database Type. Oracle, UniData, or SQL Server. Database Port. Number of the port that the database uses for communications. The default value displayed in this box is the typical port number for the database type you just selected. Database Name/Path SQL Server. Name of the database that you created for the Colleague database (Worksheet Item W on page 101). Oracle. Name of the Oracle instance that you created for the Colleague database (Worksheet Item Z on page 102). UniData. Path to the directory where you want the installation program to create the account for the Colleague executables and data (Worksheet Item I on page 97). Username and Password SQL Server. Valid username and password for the database, with administrative privileges to create database tables and to create and edit data (Worksheet Item U on page 101). This username and password must already exist. If they do not exist, create them using the SQL Server administrative tools. Oracle. Username and password for the Oracle schema containing the Colleague data (Worksheet Item AA on page 102). This username and password must already exist. If they do not exist, create them using the Oracle administrative tools. UniData. Valid username and password for the computer, with privileges to read/write/execute in the database directories (Worksheet Item U on page 101). If they do not exist, create them using the operating system administrative tools.
147
Figure 49: Set Up Colleague Application Environment (1/3) Window SQL Server Example
Figure 50: Set Up Colleague Application Environment (1/3) WindowOracle Example
148
Figure 51: Set Up Colleague Application Environment (1/3) Window UniData Example
Step 8. On the Set Up Colleague Application Environment (2/3) window (Figure 52), enter the following information about the Colleague DMI data access server that will be installed.
Figure 52: Set Up Colleague Application Environment (2/3) Window
DMI_DAS Port. Number of the non-secure port that the Colleague DMI data access server should use for TCP communications (Worksheet Item M on page 98). DMI_DAS Installation Path. Full path to the directory where the Colleague DMI data access server (specifically, the dmilistener.jar file)
149
should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item C on page 96. UniData. Worksheet Item H on page 97. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (Worksheet Item R on page 100). Environment Keystore Password. Enter a password to protect the keystore that is created with this installation. The keystore is the file dmi.keystore, created with this installation. The keystore contains the encryption key used to encrypt and decrypt passwords. Record this password in a safe place. You will need to provide it to start the Colleague DMI data access server.
Step 10. On the Set Up Colleague Application Environment (3/3) window, shown in Figure 53, enter the information listed below about the application server.
150
Figure 53: Set Up Colleague Application Environment (3/3) Window
Step 11. In the Enter Application Server Host Information section of the window, enter the following information: OS Type. Type of operating system (UNIX or Windows) on the computer on which the application server will be installed. Host Name. Select the host computer. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. Username and Password. Valid username and password for that computer, with administrative privileges to read/write/execute in the directories where the Colleague executables will be installed. (Worksheet Item U on page 101). This username and password must already exist and must match the database username and password that you entered earlier (see page 147). For UNIX, this user will be the owner of the Release 18 directory structures
151
created by this installation. Group (UNIX only). Name of the group of UNIX users for this UniData account. In UNIX, access privileges are granted separately to an owner, a group of users, and all other users. For the UniData account created during this installation, the owner is the username that you enter in the Username box on this window, and the group is the group that you enter in this box. The permissions are based on the umask setting for the owner.
Note: This group is overridden with whatever primary group is assigned to the installing user. The primary group of the installing user is also the group used on all new files created (apphome directory, etc). It is essential for users such as datatel and dmiadmin to be members of that primary group, so that they can access necessary files and directories.
Step 12. In the Enter Colleague Application Information section of the Set Up Colleague Application Environment (3/3) window, enter the following information: Application Installation Path. Full path to the directory where the UniData account should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item D on page 96. UniData. Worksheet Item I on page 97. This must match your entry in the Database Name/Path field on the Set Up Colleague Application Environment (1/3) window (Figure 51 on page 149). Path to C# Compiler (csc.exe). For SQL Server clients only, enter the path to the C# Compiler on your application server, for example, C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. The csc.exe executable in this directory is used during the compilation of SQL Server computed columns and subroutines. These components are compiled into DLLs by csc.exe. The compiler must be version 2 or greater. UniData Runtime Path (bin). Full path to the bin directory of the UniData installation on the computer where the application server will be installed. UNIX example:/usr/ud73/bin Windows example:D:\ibm\ud73\bin UniData Port. Port number assigned to the UniData database. In almost all cases, you should accept the default port (31438).
152
Step 13. In the Enter DMI Application Server (DMI_AS) Information section of the Set Up Colleague Application Environment (3/3) window, enter the following information: DMI_AS Port. Number of the non-secure port that the DMI application server should use for TCP communications (Worksheet Item O on page 98). Later, you can set up secure communications for the DMI application server, including specifying a secure port. See Managing Colleague Software Environments. DMI_AS Installation Path. Full path to the directory where the DMI application server (specifically, the dmilistener.jar file) should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item E on page 96. UniData. Worksheet Item J on page 97. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (Worksheet Item S on page 100).
Step 14. In the Enter First DMI Admin User Information section of the Set Up Colleague Application Environment (3/3) window, enter a username and password for a DMI administrative user (Worksheet Item U on page 101). This username and password must match the database username and password that you entered earlier (see page 147). The install creates one DMI administrative user, with administrative privileges to change DMI data (for example, to add a user). Record this username and password in a safe place. You will need to provide them when you first access Colleague.
Step 15. Click Install to start the installation.
153
Step 16. On the Choose Full Release Type window, shown in Figure 54, choose the Full Release type you want to install. See Full Release vs. Consolidated Full Release on page 142 for more information. Click OK to continue.
Figure 54: Choose Full Release Type Window
The progress of the installation, including a list of installed components, is displayed. At the end of the installation, an installation was successful message is displayed (Figure 55).
Technical Tip: Due to the large number of software updates that will need to be installed, Ellucian highly recommends that you use the latest Consolidated Full Release (CFR) when building new application environments.
Figure 55: Windows Displayed During and After Creation of the Application Environment
154
Upgrading DMI Listeners
Upgrading DMI Listeners

When you create an application environment, temporary versions of the DMI application server and the DMI data access server are created from components installed with SA Valet. These DMI Listeners are sufficient to complete the creation of the application environment but are not fully functional DMI Listeners. At this point, you need to do the following from SA Valet to upgrade the DMI Listeners to a full DMI release level: Update your local product repository with the latest software updates from Ellucian. These will include the DMI software updates needed to upgrade the Listeners. Run the Manage DMI Updates process to upgrade the Listeners.You must install DMI software updates through 12/31/2010. When installing the DMI updates, mark any DMI pre-install instructions Complete, but ignore the instructions themselves. After installing the DMI updates, you must go back into Manage DMI Updates and mark the post-install instructions Complete (again ignoring the instructions). See Updating Colleague Software for the procedures.
155
156
Populating the Application Environment

In This Chapter
Perform these procedures for all application environments.
Note: Populating the application environment for a full Colleague installation will likely take several hours.
This chapter provides the procedure for populating a Colleague application environment. See Population of the Application Environment on page 36 for a description of what is installed.
Before You Begin

Before performing this procedure, create the application environment using the procedure in Creating the Application Environment on page 141.
Note: The Populate Application Environment process is phantomed by SA Valet. Therefore, you may need to ensure that your account contains a VOC entry for PHANTOM: :AE VOC PHANTOM Top of "PHANTOM" in "VOC", 2 lines, 9 characters. *--: P 001: V 002: PHANTOM Bottom
157
Application Environment Creation: Populating the Application Environment
Externally Authenticating the Administrative User (Oracle Only)

When you created this application environment, you entered the username and password for an operating system login on the application server computer (Step 11 on page 151). Before running the Populate Application Environment wizard, you must set up that user in the Oracle database as externally authenticated. Otherwise, the wizard would fail because it would need a password for the Oracle database. For example, enter the following command at the SQL Plus prompt: SQL> alter user admin_user identified externally; Later, after running the wizard, reconfigure the admin user in Oracle. If you intend to leave the admin user configured for external authentication, no action is necessary. If, instead, you want to put the password verification in Oracle, use a command like the following at the SQL Plus prompt: SQL> alter user admin_user identified by new_password;
158
Procedure for Populating the Application Environment

Step 1. In SA Valet, connect to the application environment that you want to populate, if not already connected. You are already connected if the application environment node is expanded to display other nodes as shown in Figure 56.
Step 2. Right-click the application environment node and select from the pop-up menu (Figure 56).
Figure 56: Populating the Application Environment
159
Step 3. In the Confirm Action window, click Yes to start the process of populating the application environment.
Figure 57: Starting the Population of the Application Environment
An Initializing message is displayed briefly, followed by a box showing the progress of the installation (Figure 58).
Note: At the beginning of the installation, the progress indicator bars may be unchanged for about ten minutes while UniData prepares for the installation.
Figure 58: Messages Displayed During Population of the Environment
160
At the end of the installation, a message box indicates the result: An installation was successful message (Figure 59) indicates that the application environment was populated. You are done with this procedure. An error during installation message (Figure 60) indicates an unsuccessful installation. Click OK in the Error window to view details about the error.
Figure 59: Message Indicating Successful Population of the Environment
Figure 60: Message Indicating an Error in Populating the Environment
Step 4. (Oracle only) Set up the administrative login on the application server so that it is not externally authenticated. See Externally Authenticating the Administrative User (Oracle Only) on page 158 for more information.
161
Troubleshooting Using the COMO File

Each time you install an Envision software update or populate the application environment, a COMO file is created and stored in the INSTALL_LOGFILES directory located in the application environment. For example, the COMO filename O_SU22540.48-485_010_14135_57316 includes: The letter O The release package ID: SU22540.48-485 The build number: 010 The release package installation date and time in internal format: 14135_57316 If you suspect a problem may have occurred during installation of a release package into an environment, you can look at the COMO file in the INSTALL_LOGFILES directory.
162
Compiling/Validating Invalid Java Classes (Oracle)
Compiling/Validating Invalid Java Classes (Oracle)

Java classes that are deployed to an Oracle database may show an initial status of INVALID. This status can be misleading since java classes are validated at runtime. Therefore, an INVALID status does not indicate that the java class is either accessible or inaccessible. 1. You can validate the java classes an INVALID status using the ALTER JAVA CLASS command with the COMPILE option as follows:
SQL> ALTER JAVA CLASS "com/datatel/server/cc/SCalcAge" COMPILE;
Note: This does not compile the java class. Instead, all dependencies of the java class are validated to make sure it is executable. If the java class can be validated, the status of the java class is updated to VALID.
2. If the ALTER JAVA CLASS command reports compilation errors, use the SHOW ERRORS command in SQL*Plus to display the cause of the failed validation. For example:
SQL> alter java class "com/datatel/server/cc/SCalcAge" compile; Warning: Java altered with compilation errors. SQL> show errors Errors for JAVA CLASS /SCalcAge: LINE/COL ERROR -------- ---------------------------------------------------------0/0 ORA-29521: referenced name java/lang/StringBuilder could not be found
3. Instead of compiling them one by one, you can generate a script to validate all of the java classes showing a status of INVALID. The following sample script resets the resolver (which causes a compile) of all invalid java classes that are not a part of the base '/com/datatelx' classes.
163
-- start of script to resolve any invalid non-datatelx classes -set heading off set pagesize 0 set verify off set linesize 132 set feedback off set echo off prompt Enter the Schema name in UPPERCASE accept SchemaName spool reset_resolver.cmd (select 'ALTER JAVA CLASS '||upper(owner)||'."'||dbms_java.longname(name)||'" RESOLVER (("com/*" &SchemaName)(* PUBLIC)) RESOLVE;' from dba_java_classes where upper(owner) = upper('&SchemaName') and not(dbms_java.longname(name) like 'com/datatelx%')) intersect (select 'ALTER JAVA CLASS '||upper(owner)||'."'||dbms_java.longname(object_name)||'" RESOLVER (("com/*" &SchemaName)(* PUBLIC)) RESOLVE;' from dba_objects where upper(owner) = upper('&SchemaName') and status != 'VALID' and not(dbms_java.longname(object_name) like 'com/datatelx%')) / spool off set feedback on set echo on @reset_resolver.cmd -- end of script --
Note: If you want to compile ALL Java classes in a schema, reset the Java class resolver for each class and then validate any invalid Java classes iteratively until all dependencies are resolved. Then use the more comprehensive script included in AnswerNet document 5077.
164
Post-Install Procedures
In This Chapter
Perform these procedures for all application environments.
Technical Tip: Before completing the procedures in this chapter, refer to User Interface 4.3 Installation and Administration for procedures on setting up UI for your new environment.
This chapter contains final post-install procedures to be performed in all application environments. Any topics marked with (Consolidated Full Release) can be skipped if you did not create the application environment using the Consolidated Full Release. Table 39 lists the topics covered in this chapter.
Running Automated Post-Install Steps Update Computed Column Parameters (SQL Server and Oracle Only) Building the PERSON File Indexes Looking Up PERSON Records Without an ID Dictionary Date Conversion Modify WWW Files (RPI) Defining the Permitted Number of Database Connections Setting up an Environment as Production
Page
166 168 171 178 180 182 184 187
165
Application Environment Creation: Post-Install Procedures
Running Automated Post-Install Steps

Some Envision post-install steps for the full Colleague release have been automated. Perform the procedure below to run a subroutine that completes those post-install steps. You can run this process only once in an application environment. If it has already been run in this application environment, you will see a message to that effect and will not be able to run the process.
Technical Tip: Run the Full Release Post Install (FRPI) process after populating the application environment from SA Valet but before installing all Ellucian-delivered software updates.
Step 1. From the UT application, access the Full Release Post Install (FRPI) form, shown in Figure 61.
Figure 61: Full Release Post Install (FRPI) Form
Step 2. In the Execute Now field, enter Yes.
Step 3. Save your changes to start the process.
166
Running Automated Post-Install Steps
This process generates a COMO file to record progress messages. Example file name: O_POST_COLL1805_02_2010Q4. The process stores error messages in a file in the INSTALL_PROGS directory. Example file name: ERROR_CFR53268.41-1805_16.
Step 4. After building a new environment from the 2011 CFR, the first time you login to the environment, UI will display this warning message alerting the installer that FRPI must be run next.
Figure 62: System Warning Message to run the FRPI Process
On successful completion, the FRPI process automatically removes this message. After the FRPI process completes, you should restart all listeners for the environment. For UI 4.2, you must also restart the IIS network service for the new application environment. Until the IIS network service is restarted, UI 4.2 will continue to show the FRPI warning message, even though it has been removed from the database.
Figure 63: Restarting the IIS Network Service
167
Update Computed Column Parameters (SQL Server and Oracle Only)

As you develop custom computed columns, you will need to generate your custom computed columns and any associated IS-type subroutines using Colleague Studio. Use the Computed Column Parameters form in SA Valet to update the required paths to external software used in generating computed columns. This is the operating system path to the compiler on the application server. For SQL Server, the C# compiler (csc.exe) executable is used during the compilation of SQL Server computed columns and subroutines. These components are compiled into assemblies by the C# compiler. This is the path in the .NET framework that is used by the computed column generators. For example, C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. For Oracle, the java compiler (javac) is used to compile computed columns into java classes. Enter the path on the application server to the Java Development Kit, where the java compiler and jar commands are stored. For example, /opt/java15/bin. For Oracle, you must also specify the Oracle home directory on the database server, which is used when deploying computed columns. Follow these steps below to set the path to the compiler for Oracle and SQL Server.
Step 1. Start SA Valet.
Step 2. Expand the environment for which you want to define the path to the C# compiler. Log in if necessary.
Step 3. When the node for the environment is expanded, double-click on the Configuration > Computed Column Params option (see Figure 64).
168
Update Computed Column Parameters (SQL Server and Oracle Only)
Figure 64: Accessing the Computed Column Parameters form
Step 4. Enter your DMI login and password if prompted. The Computed Column Parameters form is displayed (see Figure 65).
169
Figure 65: The Computed Column Parameters form
Step 5. For SQL Server, enter the path to the C# compiler on the application server in the first field. For Oracle, enter the path to the java compiler on the application server and the path to the Oracle home directory on the database server in the second and third fields, respectively.
Technical Tip: This path is used to set the ORACLE_HOME environment variable prior to executing Oracle's loadjava utility. Any other environment variables that are required to establish an Oracle connection by the utility must be set within the /etc/datatelenv_profile configuration file (such as TNS_ADMIN) followed by the requisite bounce of the Datatel daemon, and subsequent bounce of the DAS used to deploy computed columns and IS subroutines.
See the online help for more details.
Step 6. Click OK to save your changes.
170
Building the PERSON File Indexes

Use the procedures below to build both the Soundex and Partial Name indexes for the PERSON file.
Step 1. Access the Validation Codes (VAL) form in the CORE application (enter CORE-VAL in the Form Search text box). Enter FORMATTED.NAME.TYPES in the Validation Code ID LookUp prompt to access the FORMATTED.NAME.TYPES validation code table. The form is displayed as follows:
Figure 66: Example of the Validation Codes (VAL) Form
Step 2. Make sure that the code for each formatted name type you want to index is marked with a Y in the first special processing field.
Step 3. Save your changes.
Step 4. Access the User File Index Specification (UTMI) form (Figure 67).
171
Figure 67: Example of the User File Index Specification (UTMI) Form
Step 5. At the User File Specifications LookUp prompt, enter PERSON.
Step 6. At the File Index Association LookUp prompt, enter an ellipsis (...) to display all existing indexes on the resolution form (Figure 68 on page 173). If the resolution form shows both the Soundex and Partial Name indexes (as in the example in Figure 68), you are done with this procedure. Otherwise, continue with this procedure to build the missing indexes.
172
Figure 68: UTMI Resolution Form
Step 7. If Soundex indexing was not yet defined, complete this step. On the UTMI form, enter the information listed in Table 40.
Table 40: Entries on the UTMI Form to Define Soundex Indexing Prompt or Field
User File Specification LookUp Enter PERSON If this record is not found, add it. File Index Association LookUp Enter PERSON.SOUNDEX.INDEX If this index association is not found, add it. Constructing File Name Leave this field as it is.
Response
173
Table 40: Entries on the UTMI Form to Define Soundex Indexing (contd) Prompt or Field
Index Association Data Elements
Response
Verify that the following data elements are in this group. If any are missing, enter them, one on each line: NAME.HISTORY.LAST.NAME NAME.HISTORY.FIRST.NAME NAME.HISTORY.MIDDLE.NAME BIRTH.NAME.LAST BIRTH.NAME.FIRST BIRTH.NAME.MIDDLE LAST.NAME FIRST.NAME MIDDLE.NAME NICKNAME PERSON.FORMATTED.NAMES PERSON.CORP.INDICATOR PERSON.FORMATTED.NAME.TYPES
Subroutine To Calculate Index Keys Index Null Keys?
Enter S.MIO.INDX.SOUNDEX Enter Yes if you want to produce an index table entry for a null index key; otherwise enter No. Enter PERSON.SOUNDEX.VALUES. Enter 2. Leave all other fields on this form as they are.
Primary File Storage Field Name Alternate Storage File Position All remaining fields
Step 8. Save your changes. When you save these settings, the following dialog box is displayed: WARNING: Index will be disabled until rebuilt using UTBI.
174
Step 9. Acknowledge this message by clicking on the OK button.
Step 10. If Partial Name indexing was not yet defined, complete this step. On the UTMI form, enter the information listed in Table 41.
Table 41: Entries on the UTMI Form to Define Partial Name Indexing Prompt or Field
User File Specification LookUp Enter PERSON If this record is not found, add it. File Index Association LookUp Enter PERSON.PARTIAL.NAME.INDEX If this index association is not found, add it. Constructing File Name Index Association Data Elements Leave this field as it is. Enter the following data elements, one on each line: NAME.HISTORY.LAST.NAME NAME.HISTORY.FIRST.NAME NAME.HISTORY.MIDDLE.NAME BIRTH.NAME.LAST BIRTH.NAME.FIRST BIRTH.NAME.MIDDLE LAST.NAME FIRST.NAME MIDDLE.NAME NICKNAME PERSON.FORMATTED.NAMES PERSON.CORP.INDICATOR PERSON.FORMATTED.NAME.TYPES Subroutine To Calculate Index Keys Index Null Keys? Primary File Storage Field Name Enter S.MIO.INDX.PARTIAL Enter Yes if you want to produce an index table entry for a null index key; otherwise enter No. Enter PERSON.PARTIAL.VALUES.
Response
175
Table 41: Entries on the UTMI Form to Define Partial Name Indexing (contd) Prompt or Field
Alternate Storage File Position All remaining fields Enter 4. Leave all other fields on this form as they are.
Response
Step 11. Save your changes. When you save these settings, the following dialog box is displayed: WARNING: Index will be disabled until rebuilt using UTBI.
Step 12. Acknowledge this message by clicking on the OK button.
Step 13. In the Core system, access the File Indexing (UTBI) form (Figure 69).
Figure 69: Example Rebuild File Indexing (UTBI) Form
176
Step 14. Enter the information listed in the table below on the UTBI form.
Table 42: Entries on the UTBI Form Prompt or Field

Rebuild Index for File Indexing Function All remaining fields Enter PERSON. Enter A. Leave all other fields on this form as they are.
Response
Step 15. Save your changes on the UTBI form to build the indexes.
177
Looking Up PERSON Records Without an ID

Use the procedure below to deactivate the default security for the PERSON file. Additional steps are needed to use privacy codes in WebAdvisor. See the Setting Up Privacy Codes section of the WebAdvisor Installation and Administration manual for implementation instructions. A record for the PERSON file needs to exist in the UFSPECS file to allow process level security management to occur. In case this record does not exist, create one to enable lookups on a PERSON record without an ID by following these steps:
Figure 70: Example Record Security Specification (UTMR) Form
Remove the line containing COLLEAGUE.PERSON.ID
178
Looking Up PERSON Records Without an ID
Step 1. In the UT application, access the Record Security Specification (UTMR) form. At the LookUp prompt, enter PERSON to set security criteria against the PERSON file. If prompted to add a record, enter Yes.
Step 2. If a record exists, remove the line containing COLLEAGUE.PERSON.ID.

Note: If an undefined data condition is specified for COLLEAGUE.PERSON.ID, then an error message may display during PERSON LookUp.
Step 3. Turn off security by setting the Enforce Current Security Definition field to No. The default is Yes.
Step 4. Finish from the UTMR form. You must exit and re-enter the application for the changes to take effect.
179
Dictionary Date Conversion

Perform this procedure only if this is a UniData environment. Use the Dictionary Date Convert (DDCV) form to change the data dictionary formats for date fields so that they are consistent with the date formats specified on the International Parameters (INTL) form. You should complete the INTL form before you use this form. Refer to Getting Started with Colleague Core for detailed information about setting up international parameters.
Step 1. From any application, access the DDCV form (Figure 71).
Figure 71: Example of the Dictionary Date Convert (DDCV) Form
Step 2. In the Application to convert field, select an application. You will repeat this procedure for each application: UT, Core, ST, CF, CA, and HR.
Step 3. Save your changes on the DDCV form.
180
Dictionary Date Conversion
Step 4. Repeat the procedure for each application.

Technical Tip: If you access the DDCV form and try to cancel, you may need to use the Cancel All icon (appears as the red layered Xs) on the User Interface menu bar.
181
Modify WWW Files (RPI)

Note: If you did not create the application environment using the Consolidated Full Release, you do not need to complete this step. See Full Release vs. Consolidated Full Release beginning on page 142 for more information.
New file specifications were delivered to clean up remaining issues revolving around the definition of WebAdvisor work files (the WWW files). Perform this procedure to complete this file clean-up.
Step 1. Execute the WebAdvisor File Maintenance (WAFM) utility from UT. This utility ensures that all WebAdvisor work files are defined correctly.
Step 2. Stop and re-start the DAS Listener to ensure the file specifications for these files are refreshed in the DAS cache.
182
Running the EDX Interface Load Utility
Running the EDX Interface Load Utility

Run the EDX Interface Load Utility (EDIL) process to update EDX triggers. Step 1. Access the EDIL form in the UT application (enter UT-EDIL in the Form Search text box).
Step 2. In the Clear all existing trigger definitions field, enter No.
Step 3. In the Subscriber Interfaces to Load field, enter RGIN.

Figure 72: Example of the EDX Interface Load Utility (EDIL) Form
183
Modify Campus Organizations SQL Function

Institutions licensed for the Campus Organizations (CO) module running on Microsoft SQL Server environments must run the following SQL script in Microsoft SQL Server Management Studio in order for a computed column to function correctly: ALTER FUNCTION [dbo].[CMPM_CAMPUS_ORG_PURPOSE](@id [nvarchar](254)) RETURNS [nvarchar](1996) WITH EXECUTE AS CALLER AS EXTERNAL NAME [Colleague].[Datatel.CC.CmpmCampusOrgPurpose].[cmpmCampusOrgPurpose]
Defining the Permitted Number of Database Connections

The Colleague executables access the Colleague database through the DMI data access server. The maximum number of simultaneous connections is defined in the Max Concurrent Connections field on the DMI Server Properties form in SA Valet (Figure 73 on page 185). That value should be at least equal to your institutions number of Colleague Application Server (CAS) licenses. Use the procedure below to set the value.
Note: If this value is set too low, your users may see a message like max sessions has been reached when they try to access Colleague.
184
Defining the Permitted Number of Database Connections
Figure 73: Max Concurrent Connections Defined on the Configure Listener Properties Form
Step 1. Perform the following steps to determine your number of Colleague Application Server (CAS) licenses: a. Access the operating system prompt on your application server computer. b. Change directories to the UniData bin directory. c. At the operating system prompt, enter listuser. The number of CAS licenses is the number of licensed users displayed (Figure 74).
185
Figure 74: Number of CAS Licenses Displayed by the Listuser Command
Step 2. Perform the following steps to set the number of maximum simultaneous connections: a. In SA Valet, connect to the application environment if not already connected. If the application environment node is expanded, you are already connected. b. Right-click the node for the DMI data access server (the node whose description ends in _DB_LISTENER), and then click Properties. The Configure Listener Properties form displays, as shown in Figure 73 on page 185. c. In the Max Concurrent Connections field, enter a value at least equal to the number of CAS licenses as determined above. d. Click OK to save the change and close the form. e. Stop and restart the DMI data access server so that the change will take effect.
186
Setting up an Environment as Production
Setting up an Environment as Production

Follow the procedure below to review application environment parameters. Specifically, use this form to specify whether or not this is a production environment.
Step 1. In SA Valet, right-click on an application environment and select the Environment Accounts Setup option (Figure 75).
Figure 75: Selecting Environment Accounts Setup
Step 2. On the Environment Accounts Setup window, review the information about the application environment. An example of the completed window is shown in Figure 76. Production Environment. When appropriate, select the check box to indicate that this is your production environment. Otherwise, leave the check box cleared.
Note: Make sure to clear the check box in this field for any other application environment that you may have previously used as production.
187
Figure 76: Example Environment Accounts Setup form
Step 3. Click OK when you are done.
188
Setting Up New Environments
In This Chapter
This chapter contains procedures to be performed in new application environments after populating the application environment. Table 43 lists the topics covered in this chapter.
Building New File Indexes Building Application Security Defining Listener Parameters Creating a Printer Control Record Specifying Permissions for Core Custom Code (UNIX/Linux Only) Installing Software Updates and Custom Release Packages
Page
190 191 192 193 198 200
189
Application Environment Creation: Setting Up New Environments
Building New File Indexes

If you are using the UniData database, use this procedure to build indexes for Colleague files. This step is required to turn on the indexes.
Note: You must index files and tables using the Multiple File Indexing (UTBA) process from each application. You can use a saved list to isolate files that have an index association within each respective application. The keys must come from the appl.FILE.SPECS records.
Step 1. From the UT application, access the Multiple File Indexing (UTBA) form (Figure 77).
Figure 77: Multiple File Indexing (UTBA) Form
Step 2. In the Indexing Function field, enter B (Create and Build All).
Step 3. Save your changes on the UTBA form to create and build the indexes.
190
Building Application Security
Building Application Security

Perform the procedure below to cross-reference and build the UT security classes (UT.SECLASS) and UT process control (UT.PRCS.CTL) records.
Step 1. Access the application from which you want to build security. You must build security from within each application, in the following order: UT, CORE, CF, ST, HR, CA, and any custom applications.
Step 2. Access the Build Application Security (BSEC) form (Figure 78).
Figure 78: Example of the Build Application Security (BSEC) Form
Step 3. Enter Yes in the Run Build Security Process (Y/N)? field and save the information.
Step 4. Repeat the procedure for all applications, in the order listed in Step 1.
191
Defining Listener Parameters

The create application environment process created two DMI Listeners: a DMI application server and a DMI data access server for the Colleague database. The following are recommended procedures for defining Listener parameters. See Managing Colleague Software Environments for the detailed procedures. Memory allocation. To improve Listener performance, ensure that sufficient memory is allocated to the DMI Listeners. Auto-start. DMI Listeners, as installed, will not automatically restart when the computer that hosts the DMI Listener is restarted. You can specify that a DMI Listener will automatically restart on computer restart.
192
Creating a Printer Control Record

Printing from Colleague requires the following: A printer control record in the SYSDEFS file. The printer control record is specific to the operating system type (UNIX, Linux, or Windows) and, for UNIX, the vendor (for example, HP-UX or IBM AIX). (Only for Windows using networked printers) For each printer, an entry in the VALID.PRINTERS validation code in UT. You must perform these procedures if this is a new application environment, or an upgraded environment with a change to the operating system, vendor, or printing type. Use the appropriate procedure below for your operating system: UNIX/Linux. Procedure for Creating the Printer Control Record on UNIX or Linux on page 194. Windows. Creating the Printer Control Record and Validation Code on Windows on page 195.
193
Procedure for Creating the Printer Control Record on UNIX or Linux

Step 1. In the UT application, access the Create Printer Control Record (CPRC) form (Figure 79).
Step 2. In the Machine field, select your Unix vendor or LINUX, as appropriate.
Step 3. Save your changes on the CPRC form.

Figure 79: Create Printer Control Record (CPRC) Form for Unix Vendor or LINUX
194
Creating the Printer Control Record and Validation Code on Windows

Procedure for Creating the Printer Control Record (Windows)
Step 1. In the UT application, access the Create Printer Control Record (CPRC) form (Figure 80).
Step 2. In the Printer server is Local or Networked L/N field, enter one of the following: Enter L if all printers are defined as local printers to the computer on which the Colleague executables are installed. Enter N if you use a network print server. If you enter N, you will also need to set up the VALID.PRINTERS validation code using the procedure on page 196.
Step 3. Save your changes on the CPRC form.
195
Figure 80: Create Printer Control Record (CPRC) Form for Windows
Procedure for Creating the VALID.PRINTERS Validation Code (Windows/Networked Printers)

Perform this procedure only if you are on Windows and your printers are on a network print server.
Step 1. In the UT application, access the Validation Codes (VAL) form (Figure 81 on page 197).
Step 2. At the Validation Code ID LookUp prompt, enter VALID.PRINTERS. If the validation code does not exist, add it.
Step 3. From a blank line, detail to the Validation Code Detail (VALD) form.
Step 4. In the Code field, enter the Envision code that you want to assign to this printer.
196
Step 5. In the Description field, enter a description of this printer.
Step 6. In the Minimum Entry field, enter the exact same text as you entered in the Code field (Step 4). The Code and Minimum Entry fields must match exactly in order for printing to work.
Step 7. In the Special Processing 1 field, enter the network path to the printer. Example: \\PRINTSERVER\REG_HP4000N
Step 8. Save your changes on the VALD and VAL forms.
Step 9. Repeat this procedure for each printer that you want to use with Colleague.
Figure 81: VALID.PRINTERS Validation Code on the VAL and VALD Forms
Detail
These entries must match exactly.
197
Specifying Permissions for Core Custom Code (UNIX/Linux Only)

Understanding Permissions for Core Custom Code
The Edit Change Mode Command (CMCD) form, shown in Figure 82, allows you to specify permissions to be applied to your own custom code generated from Colleague Core, including ELF imports and exports, computed columns and computed column subroutines, and rules subroutines. When you generate the code, any permission information that you specify on the CMCD form, such as permissions, owner, and group, is applied to both the source and object code of all generated items. This addresses the situation where the developer's default permissions do not give rights to anyone else to read, write, or execute files created by them.
Figure 82: Example of the CMCD Form
Set the security so that developers and system administrators can read, write, and execute the generated programs, and Colleague users can read and execute the generated programs.
198
Specifying Permissions for Core Custom Code (UNIX/Linux Only)
Note that you must enter an at sign (@) as shown in Figure 82 to ensure that the source and object code have the permissions information applied.
Procedure for Specifying Permissions for Core Custom Code

Perform the following procedure to specify permissions to be applied to your own custom code generated from Colleague Core.
Step 1. From Colleague Core, access the Edit Change Mode Command (CMCD) form.
Step 2. Specify the appropriate permissions, owner, and group to be applied to all custom object and source code from Colleague Core. If you leave out any information, the default permissions for that user will be applied. For example, if you do not specify the chown command, the owner of each piece of code will be the current user.
Step 3. Save your work on the CMCD form.
199
Installing Software Updates and Custom Release Packages

At this point, you have populated the application environment with the Colleague software delivered with the Consolidated Full Release (CFR) package. Now you need to bring the application environment up to date by installing two other types of release packages: Ellucian software updates. Since releasing the full release package, Ellucian may have released software updates providing enhancements and bug fixes for the full release package. Custom release packages. If you installed other application environments before this one, you may have created custom release packages in those application environments. This custom software could have been created in that other R18 application environment.
Note: You might have custom development in any application environment, including test and production (live), not just those identified as development application environments.
There are several reasons to install the software updates and release packages at this point. For example, if you are migrating to SQL Server or Oracle: Some Ellucian software updates may affect the migration utilities that you will use. Your custom release packages might include custom file and field specifications. When you migrate your data, the migration will fail if those custom specifications have not yet been installed in this application environment.
Procedure for Installing Software Updates and Custom Release Packages

Both the Ellucian software updates and your custom release packages are in the local product repository. The installation procedures are the same for both. See Updating Colleague Software for the procedures.
200
Other Application Environment Procedures
Other Application Environment Procedures 82
Installing a New DMI Listener
In This Chapter
This chapter provides the procedure for installing a new DMI Listener in an application environment. Table 44 lists the topics covered in this chapter.
Understanding DMI Listener Installation Planning Procedure for Installing a New DMI Listener Defining Listener Parameters
Page
204 205 207 212
203
Other Application Environment Procedures: Installing a New DMI Listener
Understanding DMI Listener Installation

When you create an application environment, two DMI Listeners are installed with the application environment: DMI data access server for the Colleague database. DMI application server. You may need to install other DMI Listeners for other purposes. For example, these might include a DMI print server and DMI RPC server. Use the procedure in this chapter to install those DMI Listeners. The new Listener will be created with the same release packages as have been installed for the existing Listeners in the application environment. Specifically, the installation process creates the new DMI Listener by installing the following in turn: 1. Base DMI Listener components that are delivered with SA Valet. 2. A full DMI release package. 3. Any software updates to that DMI full release that have been installed on the other DMI Listeners in this application environment. As a result, all Listeners in the application environment, including the new Listener, will be at the same level. For Windows, the new Listener will also be registered as a Windows service.
204
Planning
Planning
The DMI Install wizard will prompt you for installation information including the Listener port, Listener installation path, and JRE path. Perform the steps below to define those values and record them on worksheets.
Listener Ports
Your new Listener will need an non-secure port and, potentially, a secure port. See DMI Listener Ports on page 54 for considerations in selecting Listener ports and determining ports that are already in use. Use the worksheet in Table 45 on page 206 to record the ports for your new Listener.
Listener Installation Path

The DMI Install wizard will prompt you for the installation directory path for your new Listener. See Directory Structure on page 49 for directory structure examples and considerations. Use the worksheet in Table 46 on page 206 to record the path for your new Listener.
Path to JRE or SDK

Java Runtime Environment (JRE) for UNIX, or the Software Development Kit (SDK) for Windows, must be installed on the computer on which you will be installing the new DMI Listener. If you have not yet done so, install the JRE or SDK using the procedure in Installing the JRE or SDK on page 57. The DMI Install wizard will prompt you for the path to the directory where the JRE or SDK is installed. Use the worksheet in Table 47 on page 206 to record the path: SDK on Windows server. Enter the path to the JRE directory. For example, D:\jdk1.6.0_12\jre. JRE on UNIX or Linux server. Enter the path to the directory just above the bin directory. For example, if the path to the bin directory is /opt/java6/ bin, then you would enter /opt/java6.
205
Worksheets
Use the worksheets in this section to record information about the new Listener. You may want to copy (or print from the PDF file) this page and record the information on the copy. This method makes the worksheets easily accessible both when you are filling them out and when you are referring back to your entries. The installation procedure later in this chapter refers to the ID column in each worksheet for the appropriate worksheet entries.
Table 45: Worksheet: Ports for New Listener Type

Non-secure Secure
Example
Port
ID
AB AC
Table 46: Worksheet: Installation Path for New Listener Example Patha
U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02
a. U = UNIX example; W = Windows example.
ID
AD
Table 47: Worksheet: JRE Path Example Path to JREa

U)/opt/java6 W)D:\jdk1.6.0_12\jre
ID
AE
206
Procedure for Installing a New DMI Listener

Perform the following procedure to install a new DMI Listener. Step 1. In SA Valet, connect to the application environment in which you want to install a new DMI Listener, if not already connected. You are already connected if the application environment node is expanded to display other nodes as shown in Figure 83.
Step 2. Right-click the node for the application environment and select Add New Listener from the pop-up menu, as shown in Figure 83.
Figure 83: Add New Listener Menu Option
207
Step 3. In the DMI Listener Roles Selection window, shown in Figure 84, select the roles that you want this DMI Listener to perform. Click Next to continue.
Figure 84: DMI Listener Roles Selection Window
Step 4. On the DMI Listener Information window (Figure 85 on page 209), enter the following information about the new DMI Listener. Listener Host Name. Select the host computer where you want the new DMI Listener to be installed. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. OS Type. Type of operating system (UNIX or Windows) on that computer. Listener Port. Number of the non-secure port that this DMI Listener should use for TCP communications (Worksheet Item AB on page 206). Listener Name. Name of this DMI Listener as you want it to appear in SA Valet. The Listener will appear as environment name_Listener name. For example, if you enter PrintServer in this field and the environment name is test, the Listener will appear in SA Valet as test_PrintServer. Listener Parent Path. Full path to the parent to the directory where the DMI Listener should be installed. Listener Installation Path. Full path to the directory where the DMI Listener (specifically, the dmilistener.jar file) should be installed (Worksheet Item AD on page 206). Any directories that do not yet exist will be created during the installation. If the full path already exists, the installation directory (the last node in the path) must be empty. Path to the JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (Worksheet Item AE on page 206).
208
Figure 85: DMI Listener Information Window
Step 5. Click Install to begin the installation process. The DMI components to install window (Figure 86) displays the components to be installed: the base components, a full release package, and possibly one or more software updates to the full release. In the example in Figure 86, there are no software updates.
Figure 86: Components to be Installed
Step 6. Click OK.
Step 7. If there are pre-install instructions, they will be displayed (Figure 87). Complete the pre-install steps and then click Yes.
209
Figure 87: Example of Pre-Install Instructions for a New DMI Listener
The installation process will install the base Listener components and then install all release packages, which will include at least a full release package and possibly one or more software updates. During installation of the base components and each release package, a progress window is displayed (Figure 88).
Figure 88: DMI Listener Installation Progress Window
Step 8. After all release packages are installed, click OK in the Installation was successful message box (Figure 89).
Figure 89: Successful Installation Message
After the last release package is installed, the message shown in Figure 90 is displayed.
210
Figure 90: Message Displayed After Last Release Package
Step 9. If there are post-install instructions, they will be displayed (Figure 91). Complete the post-install steps and then click OK.
Figure 91: Example of Post-Install Instructions for a New DMI Listener
Step 10. If you want to start the new Listener immediately, right-click the node for the new Listener and select Start Listener from the pop-up menu.
211
Defining Listener Parameters

The following are recommended procedures for defining parameters for the new DMI Listener. See Managing Colleague Software Environments for the detailed procedures. Memory allocation. To improve Listener performance, ensure that sufficient memory is allocated to the new Listener. Auto-start. DMI Listeners, as installed, will not automatically restart when the computer that hosts the DMI Listener is restarted. You can specify that the new Listener will automatically restart on computer restart.
212
Implementing Multiple DMI Data Access Servers

In This Chapter
This chapter contains information to assist you with implementing multiple DMI data access server (DAS) Listeners for your application environment. Multiple DAS Listeners can help improve performance. Table 48 lists the topics covered in this chapter.
Before You Begin Implementing Multiple DAS Listeners 213 214
Page
Before You Begin

Table 49 lists the tasks that must be complete before you can continue with the procedures in this chapter.
Table 49: Before You Begin Task
Install a DMI Listener with the database application server (DBAS) role.
Reference
Installing a New DMI Listener beginning on page 203.
213
Other Application Environment Procedures: Implementing Multiple DMI Data Access Servers
Implementing Multiple DAS Listeners

Default Colleague installations have one DMI application server and one DMI data access server (DAS). This configuration is fine for most institutions; however, if you determine that the DAS Listener is a performance hindrance to your Colleague implementation, you can install another DAS Listener to help alleviate the transaction load. Colleague transactions are routed to a DAS Listener according to the interface. Web transactions can be routed to one DAS Listener, UI transactions can be routed to a different DAS Listener, and SA Valet transactions can be routed to still a third DAS Listener.
Technical Tip: SA Valet uses the first DAS Listener, created as part of installing Colleague, to send transactions and cannot use any other DAS Listener. This DAS Listener also must be on the same server as the Colleague database and cannot be deleted.
To determine which DAS Listener serves which interface, use the Distribute DAS form, shown in Figure 92. This form was introduced with SA Valet 2.2.1; therefore, you must have SA Valet 2.2.1 or higher installed in order to use this feature.
Figure 92: Distribute DAS Form in SA Valet
In this example, the DAS Listener installed as part of the initial installation (coll18dev_DB_LISTENER) is used for web transactions. A second DAS Listener (coll18dev_UI_DB_LISTENER) is used for UI transactions. You should perform performance tests to determine if your choices for each DAS Listener are appropriate. For example, you might install a second DAS Listener on a different server than the server that hosts your Colleague database and initially set that DAS Listener to serve WebAdvisor transactions. However, after conducting performance tests, you determine that UI
214
transactions have a heavier load on your system and the DAS Listener installed on a separate server should serve UI transactions instead of WebAdvisor transactions. Users who are currently logged into UI or WebAdvisor will continue to use the DAS Listener that was assigned to their transaction type until the user logs off. The next time that user logs in, they will use the DAS Listener specified for their transaction type. Keep this in mind if you are changing the roles for previously-installed DAS Listeners or deleting a DAS Listener. Although you do not need to wait until your system is quiet to change roles for the DAS Listeners, it is a best practice to wait until your users are logged out before making such a switch. If you change the DAS Listener used for UI transactions, all UI users will use the specified DAS Listener. It is not currently possible to have a subset of UI users use a different DAS Listener from the remainder of your UI users.
Procedure for Implementing Multiple DAS Listeners

Follow these steps to implement multiple DAS Listeners.
Step 1. If you have not done so previously, use the DMI Install Wizard to install another DMI Listener with the database application server (DBAS) role. See Installing a New DMI Listener beginning on page 203 for more information.
Step 2. Connect to your application environment.
Step 3. Right-click on the application environment node and select Distribute DAS, as shown in Figure 93.
215
Figure 93: Distribute DAS Menu Option
The Distribute DAS form is displayed, as shown in Figure 94.

Figure 94: DAS Interface Parameters Form
216
Step 4. Select the DAS Listener you want to handle transactions for each interface.
Step 5. Click OK to save your changes.
217
218
Cloning an Application Environment

In This Chapter
This chapter provides the procedure for creating a Colleague application environment by cloning (making a working copy of) an existing application environment as well as your Colleague SharePoint Portal. Table 50 lists the topics covered in this chapter.
Terminology Understanding Cloning Preparing for Cloning Preparing for Cloning with the Colleague Portal (Portal Cloning) Copying the Active Directory Users Copying the SharePoint Portal (Portal Cloning) Updating User Permissions to the Test Active Directory Domain (Portal Cloning) Adding LDAP Groups to the Portal (Portal Cloning) Copying the Colleague Executables Setting Up the Application Environment in User Interface Copying the Colleague Data Copying the DMI Listeners Correcting Environment-Specific Values Updating Portal Pointers and Settings (Portal Cloning) Updating the Domain Pointer for Users Updating the Primary Constituency of All Users (Portal Cloning) Updating SharePoint Colleague Connectors and Other Settings (Portal Cloning) Setting Up User Access Features Installing and Setting Up Interfacing Software Worksheets
Page
220 220 225 228 230 234 237 239 241 244 245 261 274 289 291 293 294 296 296 297
219
Other Application Environment Procedures: Cloning an Application Environment
Terminology
In this chapter, the source application environment is the environment that is being cloned. The target environment is the new environment that results from cloning.
Understanding Cloning
Each of your application environments has a configuration defined by what software is installed, the version of each software component, and the data in the associated Colleague database. Cloning creates an application environment with the same software and data as an existing application environment. For example, you might want to clone your production environment to create a test or training environment. The target environment has the same set of installed software updates as the source environment. If you clone a source environment to replace an existing target environment (for example, you might want to refresh your test environment with data from your production environment), you must first delete the existing target database and apphome directory. For the procedure to delete an environment, see Removing an Application Environment in the Managing Colleague Software Environments manual. You must delete the target database and apphome directory to ensure that all associations from the LPR to the existing environment are removed. Otherwise, the LPR would still have associations to that environment and could cause errors. Note that you can instead create an application environment using the procedure for a full Colleague installation. The application environment created by that procedure contains the software components and versions as of the last full Colleague build created by Ellucian. The database contains no data (if it is a new installation).
Note: The target environment must use the same platform (for example, Windows to Windows, Unix to Unix) and relational database management system (RDBMS) as the source environment.
Technical Tip: If you implemented multiple DAS Listeners and assigned different DAS Listeners to each interface, the clone process will set each interface to use the primary DAS Listener. If you want UI and web transactions to be served by different DAS Listeners, you must specify which DAS Listener serves which transaction.
220
High-Level Procedure for Cloning an Application Environment

Cloning an application environment involves the steps listed in Table 51.
Table 51: Steps in Cloning an Application Environment Step
1. Prepare for cloning.
Summary
Recheck hardware requirements and UniData configuration parameters based on the addition of an application environment. Select application environment name, directory paths, DMI Listener ports, and DMI administrator username. Continue to the next step if you are cloning a portal environment. Otherwise, skip to Step 6.
Page
225
2. Prepare for portal cloning. 3. Copy the Active Directory users. 4. Copy the SharePoint portal. 5. Update user permissions to the test Active Directory domain. 6. Copy the Colleague executables.
If cloning the Colleague portal along with this application environment, perform steps that can be done ahead of time, such as creating a web application. Copy the Colleague Active Directory production users into your test Active Directory Domain Controller. Copy your production SharePoint site collection by backing up the production site collection and restoring it into the test environment. Update all references to user permissions to use the test Active Directory domain. The new test site collection includes the same permissions as your production site collection. Use operating system commands to copy the directory containing the Colleague executables. For a UniData installation, this step also copies the Colleague data.
228
230 234 237
241
7. Set up the environment in UI. 8. Copy the Colleague data.
Set up the new application environment to make it available in User Interface. SQL Server or Oracle. Use the database management system tools to create a copy of the database. UniData This step is not needed, because the Colleague data was copied with the Colleague executables.
244 245
9. Copy the DMI Listeners.
From SA Valet, run a wizard to copy the DMI application server, DMI data access server, and other DMI Listeners that you have installed in the source environment.
261
221
Table 51: Steps in Cloning an Application Environment (contd) Step

10.Correct environmentspecific values.
Summary
From User Interface, specify appropriate values for references to targets outside of the application environment (for example, e-commerce provider host address). Continue to the next step if you are cloning a portal environment. Otherwise, skip to Step 15 Update portal pointers and settings in the new test environment.
Page
274
11.Update portal pointers and settings. 12.Update the domain pointer. 13.Update the primary constituency of all users. 14.Update SharePoint Colleague connectors and other settings. 15.Set up user access features. 16.Install interfacing software.
289
Update the domain pointer for all users in the test environment registry. Primary constituency information is stored in the Shared Services of a SharePoint farm, so it is not migrated when a site collection is copied into a new server. Use the Colleague Servlet URLs form in the Colleague Portal Configuration Tool to update the location of all Colleague servlets to point to the servlets in the newly cloned test environment. If desired, set up single role access or Windows authentication in the target environment. If desired, install and set up WebAdvisor or third-party software and addon components (such as Safari, Campus Cruiser, Resource25, and Telephone Registration).
291 293
294
296 296
See the figures listed below for an overview of application environment cloning for different relational database management systems and configurations: SQL Server or Oracle. Figure 95 on page 223 UniData. Figure 96 on page 224
Note: Figures 95 and 96 do not show Colleague Portal components
222
Figure 95: SQL Server or Oracle Overview of Application Environment Cloning

Ellucian coll18
source
target
Application server computer apphome
svr01 DMI application server
svr02 svrnn
svr02 svrnn
Other DMI Listeners 1
apphome
Other DMI Listeners
3 4 Environment-specific values
Environment-specific values
Database computer
Colleague database (source)
Colleague database (target) RDBMS (Oracle or SQL Server)
2 SQL Server or Oracle Cloning steps: Copy Colleague executables Copy Colleague database Copy DMI Listeners Correct environmentspecific values datatel coll18
source das DMI data access server
target das DMI data access server
223
Figure 96: UniData Overview of Application Environment Cloning

Application server and database computer Ellucian coll18
224 apphome Installation Procedures, February 21, 2013 UniData
source
target
das
svr02 svrnn
das
svr02 svrnn
Other DMI Listeners 1
apphome
Other DMI Listeners
3 Environment-specific values Environment-specific values
Cloning steps: Copy Colleague executables and data Copy DMI Listeners Correct environment-specific values
Preparing for Cloning

Planning ahead for the cloning process will simplify both installation and troubleshooting. Table 52 lists the planning topics covered in this section.
Table 52: Planning Topics in This Section Topic
Checking the Configuration Application Environment Name Directory Structure for Target Application Environment DMI Listener Ports Path to JRE or SDK 225 226 226 226 227
Page
Use the worksheets in Worksheets beginning on page 297 to record information about the new (target) application environment.
Checking the Configuration

Because you are adding an application environment, you should recheck the items listed in Table 53.
Table 53: Configuration Items to Recheck Before Cloning an Environment Step
Recheck hardware requirements. Recheck UniData configuration parameters on the application server computer and on the database computer. These parameters may change if the process of adding an application environment changes the number of concurrent users.
Page
56 76
225
Application Environment Name

Ellucian recommends that you select names for application environments and use them consistently in the following places: Name of application environment in SA Valet, specified when you run the Clone Application Environment wizard. Name of database in User Interface (UI), specified during UI setup. Directory name (specified during Colleague installation). Use the worksheet in Table 60 on page 297 to specify a name for your target application environment.
Directory Structure for Target Application Environment

Your target application environment will need directories for DMI Listeners, Colleague executables, and (for UniData) the data. See Directory Structure on page 49 for directory structure examples and considerations. Use the appropriate worksheet section of Table 62 on page 298 to record the paths for your target environment.
DMI Listener Ports

The procedure in Copying the DMI Listeners on page 261 creates the following DMI Listeners in the new application environment: DMI data access server for the Colleague database. DMI application server. In addition, if you have installed other DMI Listeners in the source environment, you have the option to copy those as well. Examples include: DMI print server. DMI RPC server. Dedicated DMI application server for SEVIS transactions. Additional DMI application servers to share the load for web transactions.
226
Your target application environment will need an non-secure port and, potentially, a secure port for each Listener. See DMI Listener Ports on page 54 for considerations in selecting Listener ports and determining ports that are already in use. Use the worksheet in Table 61 on page 297 to record the Listener ports for your target environment.
Path to JRE or SDK

Java Runtime Environment (JRE) or the Software Development Kit (SDK) must be installed on the computers on which you will be installing the Colleague database, the Colleague executables, and any DMI Listeners. If you have not yet done so, install the JRE or SDK using the procedure in Installing the JRE or SDK on page 57. DMI Listeners perform better when the JRE runs in server mode, which you should use if supported by the JRE for your operating system. See AnswerNet document 4516 for information about the JRE version for your operating system and whether that JRE supports server mode. The Clone Application Environment wizard will prompt you for the path to the directory where JRE or SDK is installed. Use the worksheet in Table 63 on page 299 to record the path: SDK.Enter the path to the jre directory. Windows example:D:\jdk1.6.0_12\jre UNIX example:/opt/java6/jre JRE. Enter the path to the directory just above the bin directory. For example, if the path to the bin directory is /opt/java6/bin, you would enter / opt/java6.
227
Preparing for Cloning with the Colleague Portal (Portal Cloning)

In order to proceed with cloning for the Colleague Portal, you must have a test Active Directory domain that is separate from your production domain. The test server can be a smaller, lower performance server than your production Active Directory Domain Controller.
ALERT! If you are unable or do not desire to procure a test Active Directory Domain, you can skip the steps regarding copying users. However, you should still set up your own new test users in the production Active Directory. If you use the production Active Directory Domain to store test users, you do so at your own risk, since there is a chance of corrupting production user records by allowing updates to a production server from a test Colleague environment.
You must create the test SharePoint site in a separate farm from the production farm. This does not need to be a brand new farm; it can be one you use for your existing Colleague Portal test environment. Several test Colleague Portals can co-exist in the same test farm as long as they each have their own Web Application. You can not copy the production portal and attach it to an existing Colleague test environment. The Colleague Portal and the Colleague portal pointers must be synchronized. When copying a SharePoint portal, you must also clone the Colleague environment associated with it. Your Colleague production portal will be unavailable for a short period of time while a copy of the production SharePoint portal is being created. You should schedule the clone process during down time similar to the current Colleague clone process. You must perform a full backup of both your Colleague environment and your SharePoint production Portal before starting these procedures.
228
Preparing for Cloning with the Colleague Portal (Portal Cloning)
Before You Begin

The following tasks do not require downtime of your production environment and can be done ahead of time: 1. Have a copy of the following documentation handy for reference: Installation Procedures for Release 18 (current chapter) Implementing LDAP Integration Installation Procedures for the Colleague Portal 2. Create a new web application in your SharePoint test server (Step 3 on page 235). Do not create a new site collection in this web application. 3. Work with your system administrator to copy the correct objects and attributes from your production Active Directory domain to your test Active Directory domain, as described in Copying the Active Directory Users on page 230. Test with the scripts by exporting and importing a few users to become familiar with the process. Build the scripts using the instructions in this chapter so that it is ready to go when you start the cloning process. 4. Create the stsadm script with all of the users you are migrating, as described in Updating User Permissions to the Test Active Directory Domain (Portal Cloning) on page 237. Test it out with a few manually created users.
229
Copying the Active Directory Users

Note: This section is applicable for all institutions that use Active Directory authentication for their production users.
Begin by copying Colleague Active Directory production users into your test Active Directory Domain Controller.
Note: This copy relies on an Active Directory utility that does not copy passwords. You will be able to reset passwords for all migrated users to default values.
Use the native Active Directory CSVDE utility or any other standard Active Directory user management tool of your choice to export users from the production Active Directory and to import them into the test Active Directory. The copy will include both user definitions and constituency groups. If you have other non-Colleague security groups in the same organizational unit with your Colleague users, those groups will be included in the copy unless you remove them from the import list.
This pr
ALERT! This procedure is a suggested approach and Ellucian is not responsible for third-party software instructions. As such, the versions and urls to the suggested information may change.
For more details and advanced options for the CSVDE utility, see http://www.computerperformance.co.uk/Logon/Logon_CSVDE.htm. Use the following procedure to copy the users.
Example Procedure
Step 1. Log in to your production Active Directory server. Locate the ou where your Colleague users are stored. The instructions below assume that you have decided to export all users in this ou. See http://www.computerperformance.co.uk/Logon/Logon_CSVDE_Export.htm for instructions on how to select which users to export.
230
Step 2. Open a command window and type the following command, making sure to replace the values with your ou and domain.
Note: The command is divided up into several lines for readability. However, you should type it all in one line. Do not copy and paste the command directly into the command window since the character returns will invalidate the command.
Figure 97: Copy Command Example
Your newly created CSV file called CloneUsersExport.csv is located in the directory where you ran the command (for example, C:\Documents and Settings\spsadmin).
231
Step 3. Edit the newly created export file using Microsoft Excel. a. Perform a global find and replace if the name of the test LDAP server ou is different from the production LDAP server. b. Perform a global find and replace for the domain name from production to test. For example, replace the production server string DC=college with the test LDAP domain DC=testCC: OU=ColleagueUsers,DC=college,DC=com with OU=ColleagueUsers,DC=testCC,DC=com You can optionally delete any rows that contain users or groups you do not want to import into your test Active Directory. c. Use Microsoft Excel to sort the document using the objectClass column in Z-to-A order. This will sort all group type objects to the bottom of the document. Any row that has the value group in the objectClass column will be at the bottom of the list. Any row that has the value user will be at the top. Later, when you import group membership, the user objects will have been created. d. Save the file with a new name such as ClonedUsersImport.csv. Make sure the extension remains the same and is not changed to xslx. When prompted to keep the document format, click Yes.
Step 4. Log in to your test Active Directory domain controller to import these users into your test server. a. Create a new ou if one is needed. This ou should match the one in your .CSV file. b. Copy the new CSV import file CloneUsersImport.csv to the test Active Directory server. c. Open a command window and type: CSVDE -i -f ClonedUsersImport.csv Add a -k option to skip through errors such as user already exists and continue processing. Do not use this option the first time, so you can see if there are errors that might prevent the entire import from running
232
successfully.
Technical Tip: If you receive any error messages, check the Troubleshooting Errors section at http://www.computerperformance.co.uk/Logon/ Logon_CSVDE_Errors.htm for help.
d. Spot check a few users in your test ou to make sure the information was imported correctly before continuing. Specifically, double-check that group membership was imported correctly.
Note: Depending on the group policies in your test server, the system may not accept blank passwords for new users. See Updating Passwords at http://www.computerperformance.co.uk/ezine/ezine23.htm for a script that resets all users passwords and scripts to an initial complex password, if required.
233
Copying the SharePoint Portal (Portal Cloning)

Copy your production SharePoint site collection by performing stsadm operations to back up the production site collection and restore it into the test environment. For more information about stsadm commands, see http://technet.microsoft.com/en-us/library/cc706871.aspx
Step 1. Log in to your production SharePoint server. Open a command window and navigate to: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin
Step 2. Set your site collection to read-only mode so that users are not allowed to make changes to it during the backup process: stsadm -o setsitelock -url <URL name> -lock readonly
Example
stsadm -o setsitelock -url http://portal.datateluniversity.edu -lock readonly Check the status of the site collection using the getsitelock command. stsadm -o getsitelock -url <URL name> Back up the site collection using the backup stsadm command.
Note: This operation may take several minutes to a few hours to complete depending on the size of your site collection.
stsadm -o backup -url <URL name> -filename <backup path and file name>
234
Copying the SharePoint Portal (Portal Cloning)
Example
stsadm -o backup -url http://portal.datateluniversity.edu -filename D:\CloneBackups\DatatelSiteCollection083109.bak
ALERT! Type this command into the window manually. stsadm will not work if there are any stray ASCII characters in the command.
Step 1. After the backup operation has finished successfully, reset the status of the production site collection. stsadm -o setsitelock -url <URL Name> -lock none
Note: At this point, you can allow your production users to start using the production portal again.
Step 2. Copy the backup file you just created from your production server to your test SharePoint server.
Step 3. Log in to your test SharePoint server and create a new web application.
Note: Do not create a new site collection after creating the new web application. Later, you will import the production site collection into this new web application.
Step 4. Run the Portal Configuration Tool to apply the Colleague Portal software to the new web application by adding it to the list of applications in the Config Tool. See Installing Portal Solutions to a New Web Application in the Installing Portal Solutions section of the Installing Colleague Portal Software chapter of Portal Installation Procedures manual.
Step 5. Restore the site collection backup into the new web application: stsadm -o restore url <url of the new web app> -filename <UNC path>
235
Example
stsadm -o restore -url http://test.datatelu.portal.com -filename D:\temp\DatatelSiteCollection083109.bak
Step 1. Log in to the new site collection with your system administrator credentials to spot check a few sites. The Colleague/WebAdvisor connections have not been established yet. Therefore, the web parts that use Colleague data will not work. You will correct this situation after the new Colleague test environment has been created.
Step 2. If the new site collection looks correct, change its status to unlocked by running the following command: stsadm -o setsitelock -url <new web app url> -lock none If you have other site collections to copy, repeat these steps for each of the site collections. For example, if you are using the Colleague Portal course catalog feature and would like to copy that site collection, repeat these procedures for the course catalog site collection.
236
Updating User Permissions to the Test Active Directory Domain (Portal Cloning)
Updating User Permissions to the Test Active Directory Domain (Portal Cloning)
The new test site collection includes the same permissions as your production site collection. Use the StsadmMigrateUserTemplate.xlsx spreadsheet attached to AnswerNet document 7236, Cloning with the Colleague Portal to build a script to migrate all user permission references to the new test domain users.
Step 1. Open the StsadmMigrateUserTemplate.xlsx spreadsheet. Note that a few sample logins have been populated. Save the file with a new name.
Step 2. Use the export file you created during the Copying the Active Directory Users on page 230 step to paste the list of logins from the sAMAccountName column in the CloneUsersImport.csv file into the username column in the new spreadsheet. As you fill out the usernames, the formulas in the Script column will become populated automatically.
Step 3. Fill in the Former and New domain columns with the domain of your production server (copying users from) and the domain of your test Active Directory server (copying users to), respectively, for each row where you have a username to migrate.
Step 4. In your test SharePoint server, create a new text file called StsadmMigrateCloneUsers.bat. Copy and paste all the populated values from the Script column into the new text file (not including the column heading Script). Add a new line at the bottom of the file and enter the single word pause. The end of the text in the file should look something like this:
237
Step 5. Save the file.
Step 6. Double-click on the file to run the stsadm commands. This script will run for a few hours per several few thousand users.
Note: You do not need to wait for this step to finish before continuing to the next procedure. None of the other steps rely on the results of this script. You may leave the script running in the server and monitor it periodically while you finalize the cloning process.
238
Adding LDAP Groups to the Portal (Portal Cloning)
Adding LDAP Groups to the Portal (Portal Cloning)

Constituency groups have been created in the new LDAP domain. Perform the steps below to make those constituency groups (and consequently the people in those groups) members of the new portal.
Adding the LDAP Groups as Members of Constituency Sites

Do the following for each constituency site in the new portal:
Step 1. In a browser, access a constituency site (Example: portal.mycollege.edu/ student) as an administrator.
Step 2. Click Site Actions > Site Settings > People and Groups.
Step 3. In the left pane, click Site Permissions.
Step 4. On the Permissions page, click New > Add Users.
Step 5. On the Add Users page, in the Users/Groups box, enter the LDAP domain\name of the new constituency group created in the new LDAP domain (Example: test\const-student).
Step 6. Still on the Add Users page, click Give users permissions directly and check the Read - can view only check box. Then click OK. This assumes that you have accepted the Ellucian default permission level of Read for users in constituency sites. If desired, you can select another permission level instead.
Step 7. Repeat Steps 1 through 6 for all constituencies in the new portal.
239
Adding the LDAP Groups as Members of the TopLevel Portal Site

Now do the following to add all users to the top-level portal site:
Step 1. In a browser, access the top-level portal site collection (Example: portal.mycollege.edu) as an administrator.
Step 2. Click Site Actions > Site Settings > People and Groups.
Step 3. In the left pane, click Site Permissions.
Step 4. On the Permissions page, click New > Add Users.
Step 5. On the Add Users page, in the Users/Groups box, enter the LDAP domain\name of one of the new constituency groups created in the new LDAP domain (Example: test\const-student).
Step 6. Still on the Add Users page, click Give users permissions directly and check the Read - can view only check box. Then click OK. This assumes that you have accepted the Ellucian default permission level of Read for users in the top-level portal site collection. If desired, you can select another permission level instead.
Step 7. Repeat Steps 4 through 6 for all constituencies in the new portal.
240
Copying the Colleague Executables

Note: After copying the Colleague executables, do not perform any pre-install or post-install steps in the source environment until you have run the Clone Application Environment wizard (Copying the DMI Listeners on page 261). The wizard copies information about the software updates that are installed in the application environment. That copied information will not match the configuration in the target environment if you install software updates between the time that you copy the Colleague executables and the time that you run the wizard.
Procedure for Copying the Colleague Executables

Use the following procedure to copy the Colleague executables from the source application environment to the target environment. See Figure 98 on page 242 for an example in which the source application environment is production and the target application environment is training.
ALERT! Be sure to prevent users from accessing the target environment until the clone process has completed successfully. After production directories are copied but before the SA Valet Clone Environment Wizard is run, users will be able to login to the test environment but will actually be redirected to the production environment due to the SQLENVINIT command in the copied LOGIN paragraph. This command is not changed until the clone process is completed.
Use the appropriate path and directory from the planning worksheet: SQL Server or Oracle. Worksheet Item AN on page 298. UniData. Worksheet Item AR on page 298.
Note: If you have created temporary or backup directories and files under the Colleague executables directory in the source environment, those will be copied to the target environment. Consider cleaning up those directories either before making the copy, in the source environment, or after, in the target environment.
241
Step 1. (UNIX only) Log in to the computer with a login that has appropriate permissions on all files and directories to permit copying the files. In particular, if you have changed the permissions on any Colleague data files in order to restrict user access, make sure that the login is in the UNIX group with appropriate permissions on those files. For example, you might have restricted access to the PAYROLL.EXPORTS file in HR as recommended by Ellucian.
Step 2. On the application server computer, use the operating system tools to create the top-level directory for the target application environment.
Step 3. Use operating system tools to copy the Colleague executables directory and all subdirectories from the source application environment to the target application environment. If your target application environment is on a different Operating System platform (example: cloning from Solaris to AIX), you must run the UniData convcode, convdata, and convidx commands on any Colleague directory trees that you copy to the target application server.
Note: For a UniData installation, this step also copies the Colleague data.
Figure 98: Example of Copying the Colleague Executables

Create top-level application environment directory. Copy Colleague executables directory. datatel coll18
production apphome
training apphome 2
242
Creating an Administrative Login for the Application Server

Perform this procedure to create an administrative login.
Step 1. On the application server computer, create an operating system login for the new application environment, with privileges to read/write/execute in the directories where you just copied the Colleague executables. Use the worksheet in Table 64 on page 299 to record your username. (For security, Ellucian recommends that you not record passwords on the worksheet.) The Clone Application Environment wizard will prompt you for this username and password. See Creating Administrative Users on the Application Server Computer on page 77 for guidance on selecting the username.
243
Setting Up the Application Environment in User Interface

In order to use User Interface (UI) to access Colleague forms, you must first set up the new application environment to make it available in UI. See User Interface Installation and Administration for detailed instructions. Note the following: In the Database Name field, enter the name of your Colleague application environment as you want it to appear in UI (Worksheet Item AF on page 297). In the Database Path field, enter the path to the directory where you copied the Colleague executables: SQL Server or Oracle. Worksheet Item AN on page 298. UniData. Worksheet Item AR on page 298.
244
Copying the Colleague Data

Note: After copying the Colleague data, do not perform any pre-install or post-install steps in the source environment until you have run the Clone Application Environment wizard (Copying the DMI Listeners on page 261). The wizard copies information about the software updates that are installed in the application environment. That copied information will not match the configuration in the target environment if you install software updates between the time that you copy the Colleague executables and the time that you run the wizard.
Note: If you expect to clone multiple application environments from this source environment, you might want to define environment cleanup specifications in the source environment before copying the Colleague data. See Where to Define Cleanup Specifications on page 277 for more information.
Use the appropriate procedure listed in Table 54 for your RDBMS and configuration to copy Colleague data from the source to the target environment.
Table 54: Location of Procedures for Copying Colleague Data RDBMS
SQL Server Oracle UniData 245 248 260
Page
Copying Colleague Data for SQL Server

Copying the Database
Use SQL Server management tools to create a copy of the database. The following is a suggested procedure using the backup and restore functions in SQL Server Management Studio.
245
Step 1. From SQL Server Management Studio, right-click the icon for the source database and select Tasks/Backup.
Step 2. The Backup Database dialog box appears. Click Add and enter the location for the backup. Accept all other defaults and click OK to create the backup.
Step 3. Next, right-click Database and select Tasks/Restore Database.
Step 4. The Restore Database dialog box appears. Enter the desired name of the new (target) database in the To database field as shown in Figure 99.
Figure 99: Restore Database Dialog Box
Enter the name of the new database.
Step 5. A recommended name is the release directory and environment directory, joined with an underscore. For example: coll18_training. Use the worksheet in Table 65 on page 299 to record the database name. The Clone Application Environment wizard will prompt you for the database name.
246
Step 6. Click Options on the left panel and verify the restore the database files as window, and then click OK to create the new database.
Creating an Administrative User for the SQL Server Database

Step 1. For the new database that you just created, create a database user (using SQL Server authentication) with administrative privileges to create database tables and to create and edit data. The username and password must match the username and password that you created for the application server computer (see Creating an Administrative Login for the Application Server on page 243).
247
Copying Colleague Data for Oracle

Table 55 lists the topics in this section.
Prerequisite Checks Creating the Instance, Tablespaces, and Users Copying Table Definitions Exporting the Data from the Source Schema Importing the Data to the Target Schema Verification Moving Indexes to the Index Tablespace Changing the Oracle Java Resolver Cleanup 248 249 252 254 255 256 257 259 259
Page
Prerequisite Checks
Step 1. Determine the size of the Oracle tablespaces that contain the source schema. Typically (per Ellucians recommendations), all schema objects for a single application environment are stored in two tablespaces: one for tables and one for indexes. If you have customized the schema design and spread the objects across additional tablespaces, account for that in determining your space requirements. Use the Oracle Enterprise Manager tools to determine your space requirements.
Step 2. Verify that you have enough space on your database server file systems to accommodate new tablespaces large enough to contain a copy of the source dataset. Consult your Operating System documentation for assistance.
248
Creating the Instance, Tablespaces, and Users

Step 1. Record the instance name for the target environment in the worksheet in Table 66 on page 299. You might choose to have the target environment share an existing Oracle instance with an existing application environment, or you might choose to create a new instance. For either case, record the instance name in the worksheet. The Clone Application Environment wizard will prompt you for this instance name.
Step 2. If you are creating a new instance for the target environment, perform the following steps: a. Create the Oracle instance as described in Planning Oracle Instances on page 88. b. Set up the Oracle instance as described in Creating Instances on page 88.
Step 3. Create an Oracle tablespace for the data for the target environment. Tablespace name. In order to clarify the relationship between the tablespace and the Colleague directories on the application server computer, Ellucian recommends that the tablespace name be the release directory and environment directory, joined with an underscore. Example: coll18_training. Tablespace properties. Ellucian recommends the following properties for tablespaces: Locally managed. Automatic segment allocation. Autoextend turned on, with maximum and next sizes defined. Set appropriate initial and maximum sizes based on the total size of all of the tablespaces for the source environment, as determined in Step 1 on page 248.
Note: All of the data in the source dataset, including indexes as well as Colleague data, will initially be copied into this tablespace when you import data using the procedure on page 255. (Later, you will move the indexes to their own tablespace using the procedure on page 257.) Consequently, this tablespace needs to be large enough to accommodate the indexes as well as the Colleague data.
249
Figure 100 shows an example statement for creating the tablespace.

Figure 100: Example Statement for Creating the Tablespace for the Target Environment
CREATE SMALLFILE TABLESPACE "COLL18_TRAINING" DATAFILE '/u02/oradata/dprod11/ coll18_training_dprod11_01.dbf' SIZE 1024M AUTOEXTEND ON NEXT 128M MAXSIZE 4096M LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
Step 4. Create an index tablespace for the target environment. Index tablespace name. The name of the index tablespace must be the name of the primary tablespace with _idx appended. Example: If the name of the primary tablespace is coll18_training, then the name of the index tablespace must be coll18_training_idx. Index tablespace properties. Ellucian recommends the following properties for the index tablespace: Alternate block size set to the largest block size supported by your institutions configuration.1 Locally managed. Automatic segment allocation. Autoextend turned on, with maximum and next sizes defined. Set appropriate initial and maximum sizes based on the size of the index tablespace for the source environment, as determined in Step 1 on page 248. Figure 101 shows an example statement for creating the index tablespace.
Figure 101: Example Statement for Creating the Index Tablespace for the Target Environment
CREATE SMALLFILE TABLESPACE "COLL18_TRAINING_IDX" DATAFILE '/u04/oradata/dprod/ coll18_training_idx_dprod_01.dbf' SIZE 1024M AUTOEXTEND ON NEXT 128M MAXSIZE 5120M LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO BLOCKSIZE 32K
1. In order to create tablespaces with an alternate block size, you must first configure an additional memory pool that corresponds to the desired block size. See your Oracle documentation for the procedure.
250
Step 5. If you created a new instance for the target environment, create an Oracle user with the same username and password as the application server administrator (Worksheet Item AX on page 299). Grant the privileges listed in Table 22 on page 92 to that user.
Step 6. Create an Oracle user whose default tablespace is the one you created in Step 3 on page 249, and whose username matches the name of the tablespace. Grant the privileges listed in Table 22 on page 92 to that user. Use the worksheet in Table 66 on page 299 to record this username. (For security, Ellucian recommends that you not record passwords on the worksheet.) The Clone Application Environment wizard will prompt you for this username and password.
Step 7. If the source and target schemas reside in the same instance, some special processing is required to ensure that the import process does not write back into the source schema's tablespace during the data copy. Enter the following commands at the SQL Plus prompt: revoke unlimited tablespace from target_user; Revoke succeeded. alter user target_user quota 0m on source_tablespace; User altered. alter user target_user quota 4000m on target_tablespace; User altered. The following is an example where the source environment is coll18_test and the target environment is coll18_training, and the username is the same as the tablespace name per Ellucians recommendation: revoke unlimited tablespace from coll18_training; Revoke succeeded. alter user coll18_training quota 0m on coll18_test; User altered.
251
alter user coll18_training quota 4000m on coll18_training; User altered.

Note: Make sure that you re-grant unlimited tablespace after copying the data, as described in Step 1 of Cleanup on page 259.
Copying Table Definitions

Note: This procedure is needed before the data export/import to ensure that LOB data types (CLOB and BLOB) used in Colleague are copied properly.
Step 1. If the source and target schemas reside in different Oracle instances, create a DBLINK in the target schema to allow visibility to the source schema. For example: create public database link dprod connect to coll_production identified by <password> using dprod; Consult your Oracle documentation for help with DBLINK.
Step 2. Log in to SQL Plus as the target user (the one you created in Step 6 on page 251).
Step 3. At the SQL Plus prompt, create a query that will copy tables from the source to the target. Example query: set heading off set pagesize 0 select 'CREATE TABLE TARGET_SCHEMA.'||table_name||' AS (SELECT * FROM SOURCE_SCHEMA.'||table_name||' WHERE 1=2);'
252
from dba_tables where owner = 'SOURCE_USER';

Note: The never-true criterion WHERE 1=2 ensures that data is not copied; only tables are copied.
The following is an example query where the source environment is coll18_test and the target environment is coll18_training, and the associated Oracle schema names are the same as the Colleague environment names per Ellucians recommendation: select 'CREATE TABLE COLL18_TRAINING.'||table_name||' AS (SELECT * FROM COLL18_TEST.'||table_name||' WHERE 1=2);' from dba_tables where owner = 'COLL18_TEST'; The following is an example query where the source environment is coll_production, the target environment is coll18_test (using a DBLINK) and the associated Oracle schema names are the same as the Colleague environment names per Ellucians recommendation: select 'CREATE TABLE COLL18_TRAINING.'||table_name||' AS (SELECT * FROM COLL_PRODUCTION.'||table_name||'@dprod WHERE 1=2);' from dba_tables@dprod where owner = 'COLL_PRODUCTION';
Note: Replace dprod with the name of the DBLINK created in Step 1.
253
Step 4. Put your query into a temporary file. In the example below, the filename is create_tables.sql. spool create_tables.sql / (builds the query you just constructed) The status window will scroll as the query is built.
Step 5. After the building of the query is completed, turn off the spool capture: spool off
Step 6. Execute the query and store any error/warning messages in a log file. In the example below, the log file name is transfer.log. spool transfer.log @create_tables.sql The status window will scroll as the query is executed.
Step 7. After the execution of the query is completed, turn off the spool capture: spool off
Step 8. At the UNIX operating system prompt, use a text editor (such as vi) to review the log file for errors.
Exporting the Data from the Source Schema

Step 1. Check to make sure that the location where you intend to run the export utility has enough free disk space.
Step 2. At the UNIX operating system prompt, use a text editor (such as vi) to create an export parameter file. USERID=SYSADMIN/DATATEL (username and password for an Oracle administrative login)
254
OWNER=COLL18_TEST (username for the source schema) LOG=coll18_test_export.log (a filename for the log file) file=coll18_test_export.dmp (a filename for the export file) FEEDBACK=10000 DIRECT=Y
Step 3. Run the export utility. In the following example, the export file that you just created is named exp.param. $ exp parfile=exp.param
Step 4. Review the LOG file for any errors.
Importing the Data to the Target Schema

Note: Before importing, make sure that the default target tablespace is large enough to accommodate all of the data in the source dataset, including indexes as well as Colleague data. Later, you will move the indexes to their own tablespace using the procedure on page 257.
Step 1. At the UNIX operating system prompt, use a text editor (such as vi) to create an import parameter file. USERID=SYSADMIN/DATATEL (username and password for an Oracle administrative login) FROMUSER=COLL18_TEST (username for the source schema) TOUSER=COLL18_TRAINING (username for the target schema) LOG=coll18_training_import.log (a filename for the log file) file=coll18_test_export.dmp (export file created earlier) FEEDBACK=10000 IGNORE=Y
255
Step 2. Run the import utility. In the following example, the export file that you just created is named imp.param. $ imp parfile=imp.param
Step 3. Review the LOG file for any errors.
Verification
Use the following procedure to create and execute a query that will provide a count of objects in the source and target schemas. These counts should be the same in the two schemas.
Step 1. If the source and target schemas are in different Oracle instances, create a DBLINK in the target schema to allow visibility to the source schema. Consult your Oracle documentation for help with DBLINK.
Step 2. At the SQL Plus prompt, create and execute a query that will provide a count of objects in the source and target schemas. Example query when the source and target schemas are in the same Oracle instance: select owner, object_type, count(1) from dba_objects where owner in ('COLL18_TEST','COLL18_TRAINING') group by owner, object_type order by object_type Example query when the source and target schemas are in different Oracle instances: select owner, object_type, count(1) from dba_objects where owner = 'COLL18_TRAINING' group by owner, object_type union
256
select owner, object_type, count(1) from dba_objects@test where owner = 'COLL18_TEST' group by owner, object_type order by 2 In the example query above, the DBLINK name is test as indicated by the phrase dba_objects@test.
Moving Indexes to the Index Tablespace

Note: Depending on the size of the indexes, this procedure (specifically, Step 6 on page 258) could take several hours.
The export/import procedure above copies both the tables and indexes into the default tablespace for the target username. The indexes need to be moved from that tablespace into the index tablespace you created in Step 4 on page 250. Use the procedure below.
Step 1. Log in to SQL Plus as the target user (the one you created in Step 6 on page 251).
Step 2. At the SQL Plus prompt, create a query that will select the indexes to be moved. Example query: set heading off set pagesize 0 select 'alter index COLL18_TRAINING.'||index_name||' rebuild compute statistics tablespace COLL18_TRAINING_IDX;'
257
from dba_indexes where owner = 'COLL18_TRAINING' and tablespace_name != 'COLL18_TRAINING_IDX';
Step 3. Put your query into a temporary file. In the example below, the filename is move_coll18_training_idx.sql. spool move_coll18_training_idx.sql / (builds the query you just constructed) The status window will scroll as the indexes are selected.
Step 4. After the building of the query is completed, turn off the spool capture: spool off
Step 5. At the UNIX operating system prompt, use a text editor (such as vi) to review the move_coll18_training_idx.sql file. Each index that matched the limiting criteria from Step 2 on page 257 should have an entry such as this: alter index COLL18_TRAINING.IX_AARS rebuild compute statistics tablespace COLL18_TRAINING_IDX;
Note: Depending on the size of the indexes, the next step could take several hours.
Step 6. Execute the query to move the indexes and store any error/warning messages in a log file. In the example below, the log file name is move_coll18_training_idx.log. spool move_coll18_training_idx.log @move_coll18_training_idx.sql The status window will scroll as the query is executed.
258
Step 7. After the execution of the query is completed, turn off the spool capture: spool off
Step 8. At the UNIX operating system prompt, use a text editor (such as vi) to review the log file for errors.
Step 9. Repeat the verification procedure described in Verification on page 256 to confirm that the number of objects in the target schema is still the same as in the source schema.
Changing the Oracle Java Resolver

The export/import process above uses Oracle tools to copy all the objects associated with the source schema, including the java objects. However, these Oracle tools do not properly change the Java resolver for the java objects. The Java resolver (which is the hierarchy Oracle uses to find the appropriate Java classes) must be corrected so that the java objects for the target environment do not refer back to the schema/Java resolver for the source environment. To change the Java resolver, execute the scripts provided in AnswerNet document 5077.
Cleanup
Step 1. If you revoked unlimited tablespace for the target user (in Step 7 on page 251), re-grant unlimited tablespace: grant unlimited tablespace to coll18_training;
Step 2. When you are satisfied that the copy was successful, delete the export (.dmp) file and the log files to free up disk space.
Step 3. If you created a DBLINK in Step 1 on page 252, you can delete it.
259
Step 4. If desired, reduce the size of the default tablespace in the target environment. You made the default tablespace large enough to accommodate indexes as well as Colleague data (Step 3 on page 249). Having moved the indexes to their own tablespace, you can now reduce the size of the default tablespace. On the other hand, you may want to leave the tablespace size unchanged if you expect to repeat this cloning process. For example, you might periodically clone your production environment to create a test environment, in which case you might want to leave the test default tablespace large enough for both indexes and data rather than changing the size before and after each cloning procedure.
Copying Colleague Data for UniData

No action is needed. You copied the Colleague data along with the Colleague executables, using the procedure in Copying the Colleague Executables on page 241.
260
Copying the DMI Listeners

Running the Clone Application Environment Wizard Starting the New Listeners
Page
261 272
Running the Clone Application Environment Wizard

Note: If you have performed any pre-install or post-install steps in the source environment since you copied the Colleague executables (page 241) or Colleague data (page 245), you must repeat the copy before running this wizard. The wizard copies information about the software updates that are installed in the application environment. That copied information will not match the configuration in the target environment if you have installed software updates between the time that you copy the Colleague executables and the time that you run the wizard.
Follow the procedure below to use the Clone Application Environment wizard to create DMI Listeners in the target environment by copying the Listeners from the source environment. This procedure copies all files and directories under the directories for the existing Listeners, except that log files are not copied. This procedure also updates the Colleague database, the Colleague executables, and the local product repository with information about the new application environment. For convenience, the wizard will complete some fields with suggested entries based on the source environment and on your entries in this wizard. Modify the suggested entries as required.
Technical Tip: JVM arguments are not copied from the source environment.
Step 1. In SA Valet, connect to the source application environment if not already connected.
261
See the Managing Colleague Software Environments manual for the detailed procedure for connecting to the local product repository and then to the application environment. You are already connected if the application environment node is expanded to display other nodes as shown in Figure 102.
Step 2. Click on the node for the source application environment to select it (Figure 102).
Figure 102: Selecting the Source Application Environment for Cloning
Step 3. From the Wizards menu, select Clone Application Environment. If you previously performed this procedure, you will see the Previous Entries Found window (Figure 103), which gives you the option to select the target that you cloned to before. Selecting a particular target will load the entries from the profile that was saved when you cloned this environment to that particular target. Selecting the blank entry will not load any of the profiles and you will then manually enter all of the information yourself in the wizard pages. If you dont see that window, skip to Step 4.
262
In the example, one of the profiles contained the target environment Dev. Another contained the target environment Test.
Step 4. On the Target Environment Information (1/7) window (Figure 104), enter the name of the new (target) application environment as you want it to appear in SA Valet (Worksheet Item AF on page 297). Click Next to continue.
Figure 104: Target Environment Information (1/7) Window
Step 5. On the Target Environment Information (2/7) window (Figure 105), select the host computer on which the target database is located. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. Click Next to continue.
263
Step 6. On the Target Environment Information (3/7) window, enter the information listed below about the Colleague database in the new (target) environment. Examples of the completed window are shown in Figure 106 on page 265 (SQL Server), Figure 107 on page 265 (Oracle) and Figure 108 on page 265 (UniData). Database Port. Number of the port that the database uses for communications. The default value displayed in this box is the port number for the RDBMS installation for the source database. If the source and target databases are on different computers, you might be using different ports in which case you would need to change the port number in this field. Database Name/Path SQL Server. Name of the database that you created for the Colleague database (Worksheet Item AY on page 299). Oracle. Name of the Oracle instance that you created for the Colleague database (Worksheet Item AZ on page 299). UniData. Path to the directory where you copied the Colleague executables and data (Worksheet Item AR on page 298). Username and Password SQL Server. Valid username and password for the database, with administrative privileges to create database tables and to create and edit data (Worksheet Item AX on page 299). This username and password may already exist. If they do not exist, create them using the SQL Server administrative tools. Oracle. Username and password for the schema containing the Colleague data (Worksheet Item BA on page 299). This username and password must already exist. If they do not exist, create them using the Oracle administrative tools. UniData. Valid username and password for the computer, with privileges to read/write/execute in the database directories (Worksheet Item AX on page 299). If they do not exist, create them using the operating system administrative tools.
264
Figure 106: Target Environment Information (3/7) WindowSQL Server Example
Figure 107: Target Environment Information (3/7) WindowOracle Example
Figure 108: Target Environment Information (3/7) WindowUniData Example
265
Step 8. On the Target Environment Information (4/7) window (Figure 109), enter the following information about the Colleague DMI data access server (DMI_DAS) that will be installed for the new (target) environment.
DMI_DAS Port. Number of the non-secure port that the Colleague DMI data access server should use for TCP communications (Worksheet Item AG on page 297). DMI_DAS Installation Path. Full path to the directory where the Colleague DMI data access server (specifically, the dmilistener.jar file) should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item AM on page 298. UniData. Worksheet Item AQ on page 298. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed on the database computer (Worksheet Item AU on page 299). Environment Keystore Password. Enter a password to protect the keystore that is created with this installation. The keystore is the file dmi.keystore, created with this installation. The keystore contains the encryption key used to encrypt and decrypt passwords. Record this password in a safe place. You will need to provide it to start the Colleague DMI data access server.
Step 10. On the Target Environment Information (5/7) window, shown in Figure 110, enter the information listed below about the application server.
266
Step 11. In the Enter Application Server Host Information section of the window, enter the following information about the new (target) environment: Host Name. Select the computer to which you copied the Colleague executables. You must have already defined this host using the procedure in Setting Up Hosts in SA Valet on page 116. Username and Password. Valid username and password for that computer, with administrative privileges to read/write/execute in the directories where the Colleague executables were copied (Worksheet Item AX on page 299). Group (UNIX only). Name of the group of UNIX users for this UniData account. In UNIX, access privileges are granted separately to an owner, a group of users, and all other users. For the UniData account created during this installation, the owner is the username that you enter in the Username box on this window, and the group is the group that you enter in this box. The permissions are based on the umask setting for the owner.
267
Step 12. In the Enter Colleague Application Information section of the Target Environment Information (5/7) window, enter the following information about the new (target) environment: Application Installation Path. Full path to the directory where you copied the Colleague executables. SQL Server or Oracle. Worksheet Item AN on page 298. UniData. Worksheet Item AR on page 298. This must match your entry in the Database Name/Path field on the Target Environment Information (3/ 7) window (Figure 108 on page 265). UniData Runtime Path (bin). Full path to the bin directory of the UniData installation on the computer where you copied the Colleague executables. UNIX example:/usr/ud73/bin Windows example:D:\ibm\ud73\bin UniData Port. Port number assigned to the UniData database. In almost all cases, you should accept the default port (31438).
Step 13. In the Enter DMI Application Server (DMI_AS) Information section of the Target Environment Information (5/7) window, enter the following information about the new (target) environment: DMI_AS Port. Number of the non-secure port that the DMI application server should use for TCP communications (Worksheet Item AI on page 297). Later, you can set up secure communications for the DMI application server, including specifying a secure port. See Managing Colleague Software Environments. DMI_AS Installation Path. Full path to the directory where the DMI application server (specifically, the dmilistener.jar file) should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item AO on page 298. UniData. Worksheet Item AS on page 298. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (Worksheet Item AV on page 299).
Step 14. In the Enter First DMI Admin User Information section of the Target Environment Information (5/7) window, enter a username and password for a DMI administrative user (Worksheet Item AX on page 299). This username and password must match the database username and password that you entered earlier (see page 264).
268
The install creates one DMI administrative user, with administrative privileges to change DMI data (for example, to add a user). Record this username and password in a safe place for use later. You will need to provide them when you first access Colleague. Click Next to continue.
Step 15. Proceed based on the next window displayed: If the window shown in Figure 111 is displayed, the source environment has other Listeners in addition to the DMI application server and DMI data access server. Continue with Step 16 to copy those Listeners. If the window shown in Figure 112 is displayed, the source environment has no other Listeners. Skip to Step 18 on page 270.
Figure 111: Target Environment Information (6/7) Window With Additional Listeners
Figure 112: Target Environment Information (6/7) Window With No Additional Listeners
269
Step 16. On the Target Environment Information (6/7) window, shown in Figure 111, enter the information listed below for each DMI Listener to be copied.
Note: This window displays one tab for each Listener in the source environment other than the DMI application server and DMI data access server. Enter this information for each Listener.
Note: The name on each tab is the name of the Listener in the source environment. Even if you choose a different name for the copied Listener in the new (target) environment, the name on the tab will be unchanged.
Clone this Listener. Select this check box if you want to copy this Listener, or clear the check box if you dont want to copy it. If you choose not to copy the Listener, skip the other fields on this form. Listener Name. Name of this DMI Listener as you want it to appear in SA Valet. The Listener will appear as environment name_Listener name. For example, if you enter PrintServer in this field and the environment name is training, the Listener will appear in SA Valet as training_PrintServer. IP address or DNS name. IP address or DNS name of the computer where you want to install the Listener. Port #. Number of the non-secure port that the Listener should use for TCP communications (Worksheet Item AK on page 297). Listener Parent Path. Full path to the parent of the directory where the Listener (specifically, the dmilistener.jar file) should be installed. Software Installation Path. Full path to the directory where the Listener (specifically, the dmilistener.jar file) should be installed. Any directories that do not yet exist will be created during the installation. SQL Server or Oracle. Worksheet Item AP on page 298. UniData. Worksheet Item AT on page 298. Path to JRE. Full path to the directory where the Java Runtime Environment (JRE) is installed (from Table 63 on page 299).
Step 18. On the Target Environment Information (7/7) window (Figure 113), review the information that you entered for each Listener to be installed.
270
If you want to change any of the entered information, use the Back button to return to the appropriate window.
Note: For the DMI application server (APP_LISTENER) and the DMI data access server (DB_LISTENER), you can go back to change any properties listed in the New Listener Information section except for the Listener name. For all other Listeners, you can go back to change all properties listed in the New Listener Information section.
Note: The name on each tab is the name of the Listener in the source environment.
Step 19. Click Install to start the copy. The process creates new Listeners by copying all files and directories under the directories for the existing Listeners, except that log files are not copied. This process also updates the Colleague database, the Colleague executables, and the local product repository with information about the new application environment.
271
The progress of the copy process, including a list of copied components and updated records, is displayed. At the end of the installation, an installation was successful message is displayed.
Technical Tip: Settings for features you may have enabled, such as private IP, distributed DAS, autostart, or other DMI features that are not enabled by default, are not carried forward to the new environment. Refer to the appropriate procedures in this manual to enable any of these features for the new environment.
Step 20. Run the Build CS Object Index (BCSO) process. For more information, see Building Colleague Studio Object Indexes in the Post-migration Steps section of the Migrating Colleague Software Environments manual.
Note: You must run the BCSO process in order to use the Colleague Studio Show References feature in the new application environment.
Step 21. Review the Environment Accounts Setup information and determine whether or not this will be your production environment using the procedure outlined in Upgrading DMI Listeners on page 155.
Starting the New Listeners

The Clone Application Environment wizard creates the new DMI Listeners. The wizard will start the primary DAS Listener, but it will not start any other Listeners. Use the following procedure to start the Listeners.
Step 1. In SA Valet, connect to the new application environment that you just created, if not already connected. See the Managing Colleague Software Environments manual for the detailed procedure for connecting to the local product repository and then to the application environment. You are already connected if the application environment node is expanded to display other nodes as shown in Figure 114.
Step 2. Right-click the node for the new application environment and select Start All Listeners from the pop-up menu (Figure 114).
272
Figure 114: Starting All Listeners from SA Valet
273
Correcting Environment-Specific Values

A newly-cloned application environment includes several types of information whose values may not be appropriate, such as environmentspecific parameters and external VOC references. This section contains procedures for correcting those values. Table 57 summarizes each type.
Table 57: Environment-Specific Values Type
Environmentspecific parameters
Location
Colleague database
Description
Parameters whose values in the source environment are not appropriate in the target environment. Example: E-commerce parameters. Ellucian has delivered cleanup specifications to clear parameters that might cause problems if left unchanged. You can define your own custom cleanup specifications as well. Preserve the portal pointers from Colleague to SharePoint.
Basic Approach
(Optional) On the MECU and MECD forms, define custom cleanup specifications to specify new parameter values. From the BECU form, run the batch cleanup process to change the parameters, based on Elluciandelivered cleanup specifications and your custom cleanup specifications. Set the Remove Portal Information field to No (the default) when running the BECU process.
Page
275
External VOC references
VOC file in Colleague executables
References in the VOC to locations outside of the current environment. Current Ellucian-delivered software typically does not include external VOC references, but there may be some from previous Colleague releases (if this is an upgraded environment) and you may have created external VOC references in your own environments.
From the BECU form, generate a report of external VOC references. Use the UniData editor to correct or delete external VOC references as appropriate.
286
274
Securing the BECU Form

ALERT! Use Envision security to restrict access to the Environment Cleanup (BECU) form. Running the Envision cleanup process from this form in update mode will clear or reset many parameters in the application environment.
Environment-Specific Parameters
Table 58: Topics in this Section Category
Concepts
Topic
Understanding Environment-Specific Parameters Cleanup Specifications Noteworthy Fields on the MECD Form Environment Cleanup Report
Page
275 276 277 280 282 283 285
Procedures
Generating a Report of Changes For Existing Specifications Defining Custom Specifications Updating the Parameters
Understanding Environment-Specific Parameters

The source environment for the cloning may include parameters whose values in the source environment are not appropriate in the target environment. For example, if you cloned your production environment to create a training environment, and you use e-commerce in your production environment, ecommerce transactions would be sent from the training environment to your e-commerce provider if not corrected. To correct these parameters, you run a batch process from the Environment Cleanup (BECU) form. That process changes parameter values based on cleanup specifications defined on the Environ Cleanup Specs (MECU) and Environ Cleanup Specs Detail (MECD) forms.
275
The following is a suggested approach for changing environment-specific parameters: Run the BECU process in non-update mode to get a report of parameters that will be changed based on Ellucian-delivered cleanup specifications. Identify needed custom cleanup specifications not covered by the Elluciandelivered specifications. (If required) On the MECU and MECD forms, define custom cleanup specifications. Run the BECU process in non-update mode again. Review the report to confirm that the custom cleanup specifications are appropriate. Run the BECU process again, this time in update mode, to change the parameter values and get the report of changes made. For parameters that were cleared (set to null), go to User Interface (UI) forms and enter new values appropriate to the new environment.
Cleanup Specifications
Cleanup specifications are defined on the MECU and MECD forms (Figure 115 on page 279). There are two types of cleanup specifications: Ellucian cleanup specifications. Ellucian has identified parameters whose values should be changed after cloning. Generally, the Ellucian specifications clear out the field by setting the new value to null. Custom cleanup specifications. You can define your own custom specifications. These might be for parameters already included in a Ellucian specification (your custom specification will override the Ellucian specification) or for a parameter not covered by a Ellucian specification. If you have not built your own custom Envision applications, you will probably not need to specify any custom cleanup specifications.
Technical Tip: Cleanup specifications are stored in the ENVIRON.CLEANUP file in UT. The key to each record starts with a D or C, indicating Datatel or custom specification.
Overriding Ellucian Cleanup Specifications

You can view the Ellucian cleanup specifications on the MECD form. However, do not modify the Ellucian cleanup specifications. Your changes will be overwritten if Ellucian delivers an update to that specification on a future software update. Instead, create a custom specification for the same field. Your custom specification will override the Ellucian specification.
276
To disable a Ellucian-delivered specification, create a custom specification for that data element and enter NOUPD (no update) in the function field on the MECD form.
Where to Define Cleanup Specifications

If you expect to clone multiple application environments from one source environment, you might want to define custom cleanup specifications in the source environment before copying the Colleague data. For example, you might periodically clone your production environment to create a training or test environment. If you define cleanup specifications in the production environment, those specifications will be copied to each target environment.
ALERT! If you define custom cleanup specifications in the source environment, do not run the BECU process in update mode in the source environment. The process will change the parameters based on the cleanup specifications.
Noteworthy Fields on the MECD Form

The fields described in this section are particularly important for defining cleanup specifications. See online help for information about other fields on the MECU and MECD forms.
Record Key
Each cleanup specification defines a replacement value for a particular file and field. In the Record Key field, you further define the records whose value will change: For permanent key parameter files, the MECD process automatically populates this field from Envision specifications and changes it to inquiry only. No action is required. If you want to change the value for every record in the file, enter an asterisk (*). If you want to change just one record, enter the ID of that record. Note, however, that this means that the value in every other record in the file will be unchanged.
277
Value and Function

Use the Value and Function fields to define the replacement value for the parameter. Value can be any of the following: The replacement value. Double quotes (), which sets the value to null (clears the parameter). Left blank, if you specify NOUPD in the Function field (below). Function can be any of the following: IFEXTReplace if external path. The replacement value in the Value field will be used only if the original value of the parameter is a path to a location outside of the application environment. NOUPDReport but not update. The parameter will not be updated; it will have the same value in the target environment as in the source environment. Typically, you would use this in a custom specification to override a Ellucian specification, where the Ellucian specification would change the parameter value but you dont want it to change. This no update specification will be included on the environment cleanup report generated from the BECU process. (Generally, unchanged parameters are not included on the report.) Left blank. You can leave this field blank if you enter a value or double quotes in the Value field.
Maint Form and Fld Label

The Maint Form and Fld Label fields define the Envision form and field where you can later change the parameter value, if desired. Typically, you would use these cleanup specifications and the BECU process to clear parameter values, and later go to these Envision forms to enter appropriate values for the target environment.
278
Figure 115: Example of the MECU and MECD Forms
Detail
279
Environment Cleanup Report

You can use the BECU form in non-update mode to generate a report of parameters that will be changed. (The report is also generated when you run the process in update mode.) Figure 116 on page 281 is an example of the environment cleanup report. Note the following: Generally, the report shows only values that will be changed by the cleanup process. The exception is values that are unchanged because the specification is for NOUPD (no update); these values are indicated as Will Not Be Updated on the report. If a value is already null, and the specification is to make it null, it wont appear on the report. Example: You dont use Resource25, so the value for R25.DIR.PATH is null in your environments. The Ellucian specification for this parameter says to set this value to null. This wont show up on your report. For replacement values, <null> indicates that the field will be cleared out. For multi-valued fields, the values are separated by braces: value1}value2}value3. The Spec Src column indicates the source of the specification: Ellucian or custom. Cust-Ovr indicates that the source is a custom specification that overrides a Ellucian specification. The Mnemonic & Field Label column identifies the Envision form and field where you can change this value, if desired, after running the cleanup process. For example, you could use the cleanup specifications and the BECU process to clear parameter values, and later go to these Envision forms to enter appropriate values for the target environment.
280
Figure 116: Example of the Environment Cleanup Report
May 05 2005
ENVIRONMENT CLEAN-UP REPORT Report Mode
Page
Appl Data Element Name Physical File Name Spec Src Record Key Mnemonic & Field Label ---- ---------------------------- -------------------- -------- ------------------------------ ------------------------------UT RPTSET.UDMS.DCT.PATH UT.PARMS Cust-Ovr REPORTING.SETTINGS UT-RPGS Full Path to Safari Diction Original Value: datatel}safari}dict Will Not Be Updated: datatel}safari}dict UT RPTSET.UDMS.DIRPATH UT.PARMS Original Value: datatel}safari Will Be Replaced With: <null> RPTSET.UDMS.RULES.PATH UT.PARMS Original Value: safari.nrr Will Not Be Updated: safari.nrr VSPEC.DIR.DRIVE VIEW.SPECS Original Value: D Will Be Replaced With: <null> VSPEC.DIR.DRIVE VIEW.SPECS Original Value: C Will Be Replaced With: <null> VSPEC.DIR.PATH VIEW.SPECS Original Value: test}path Will Be Replaced With: <null> VSPEC.DIR.PATH VIEW.SPECS Original Value: testpath Will Be Replaced With: <null> Datatel REPORTING.SETTINGS UT-RPGS Full Path to Safari Server
UT
Cust-Ovr REPORTING.SETTINGS
UT-RPGS Safari Rules File
UT
Datatel
TED_TEST2
UT-VSNP Snap Table Drive Name
UT
Datatel
TED_TEST3
UT-VSNP Snap Table Drive Name
UT
Datatel
TED_TEST1
UT-VSNP Snap Table Path
UT
Datatel
TED_TEST2
UT
VSPEC.DIR.PATH VIEW.SPECS Datatel Original Value: piece1}piece2}piece3}piece4 Will Be Replaced With: <null>
TED_TEST3
Procedures for Changing Environment-Specific Parameters

Table 59 lists the procedures in this section.
Table 59: Procedures in this Section Procedure
Generating a Report of Changes For Existing Specifications Defining Custom Specifications Updating the Parameters
Page
below 283 285
Generating a Report of Changes For Existing Specifications

Step 1. From the UT application in the target environment, access the Environment Cleanup (BECU) form (Figure 117).
Figure 117: Generating the Environment Cleanup Report From the BECU Form
Step 2. In the Run Environment Cleanup field, enter Yes.
282
Step 3. In the Update Mode field, enter No.
Step 4. Save your changes on the BECU form to generate the report. If you have not yet defined any custom specifications, the report will show parameters that will be changed based on Ellucian cleanup specifications.
Step 5. Identify needed custom cleanup specifications not covered by the Elluciandelivered specifications. If you have customized Colleague or created custom Envision applications, review your custom Envision files for possible candidates for additional cleanup specifications.
Step 6. Do you want to define custom specifications?
Yes. Continue with Defining Custom Specifications below. No. Skip to Updating the Parameters on page 285.
Defining Custom Specifications

Step 1. From the UT application, access the MECU form (Figure 115 on page 279).
Step 2. In the Custom Cleanup Specifications table, go to an empty line in the Data Element column and detail to the MECD form.
Step 3. At the Application LookUp prompt, enter the application (ST, CORE, etc.) that contains the data element for which you want to specify a new value.
Step 4. At the Data Element LookUp prompt, enter the data element for which you want to specify a new value.
Step 5. In the Record Key field, enter the record whose value should be changed, or enter an asterisk (*) to change all records. If this field is inquiry-only, no action is required. See Record Key on page 277 for more information about this field.
283
Step 6. In the Value and Function fields, specify the desired new value for this data element. See Value and Function on page 278 for a description of these fields.
Step 7. (Optional) In the Maint Form and Fld Label fields, enter the Envision form and field where this data element value can be changed. Typically, you would use the cleanup process to clear parameter values, and later go to these Envision forms to enter appropriate values for the target environment.
Step 8. (Optional) In the Comments field, record a description of this custom specification.
Step 9. Save your changes on the MECD form to save the custom specification.
Step 10. Repeat Steps 2 through 9 for all custom specifications that you want to define.
Step 11. Save your changes on the MECU form.
Step 12. Repeat Steps 1 through 5 on page 282 to generate a new report from the BECU form and confirm that the new custom cleanup specifications are appropriate.
284
Updating the Parameters

Figure 118: Running the Cleanup Process From the BECU Form
Step 2. In the Run Environment Cleanup field, enter Yes.
Step 3. In the Update Mode field, enter Yes.
Step 4. In the Remove Portal Information field, enter No.
Step 5. Save your changes on the BECU form to update the parameters based on the cleanup specifications. The process will update the parameters and generate the environment cleanup report. Keep the report as a record of what was changed.
Step 6. Restart the application Listener. In SA Valet, connect to the local product repository, then connect to the application environment, and then right-click
285
on the application Listener node and select Stop Listener. See Managing Colleague Software Environments for the detailed procedure.
Step 7. (Optional) For parameters that were cleared (set to null), go to the appropriate Envision forms and enter new values appropriate to the new environment.
External VOC References

The source environment for the cloning may include references from the VOC to locations outside of the environment. Ellucian-delivered software typically does not include external VOC references, but you may have created these in your own environments. The following is a suggested approach for correcting external VOC references: From the Environment Cleanup (BECU) form (Figure 120 on page 288), generate a report of external VOC references. Review the report to identify needed corrections. Using the UniData editor, correct or delete the VOC references as appropriate. From the BECU form, generate the report again to confirm that any remaining external references are appropriate. Table 119 on page 287 is an example of the VOC external references report. Note the following: The process checks VOC entries of the following types: F (files), DIR (directories), C (cataloged), and R (remote). The VOC Entry Contents column displays the F1, F2, and F3 values (if they exist) from each VOC entry with an external reference. An arrow (-->) on the report indicates an external VOC reference.
286
Figure 119: Example of the VOC External References Report
May 05 2005 VOC Item Name -------------------------------ALEX
VOC EXTERNAL REFERENCES Environment Path: D:\dev\etk48dev
Page
VOC Entry Contents --------------------------------------------------------------------DIR -->D:\DEV\ETK482DEV\ALEX D__PH_ C -->D:\DEV\ETK482DEV\ALEX\_ALEXC2 F -->D:\ETK48DEV\ALTEST.FILE -->D:\ETK48DEV\D_ALTEST.FILE F -->D:\ETK48DEV\ALXF1 -->D:\ETK48DEV\D_ALXF1 F -->D:\ETK48DEV\ALXF2 -->D:\ETK48DEV\D_ALXF2 F -->D:\ETK48DEV\ALXF3 -->D:\ETK48DEV\D_ALXF3
ALEXC2 ALTEST.FILE
ALXF1
ALXF2
ALXF3
BMA.UT.FILE
F -->D:\ETK48DEV\BMA.UT.FILE -->D:\ETK48DEV\D_BMA.UT.FILE
Arrow (-->) indicates external VOC reference.
Procedure for Correcting External VOC References

Figure 120: Generating the VOC External References Report From the BECU Form
Step 2. In the Report External VOC References field, enter Yes.
Step 3. Save your changes on the BECU form to generate the report.
Note: Generating the report may take several minutes.
Step 4. Review the report to identify needed corrections.
Step 5. Using the UniData editor, correct or delete the VOC references as appropriate.
Step 6. Repeat Steps 1 through 4 to generate a new report and confirm that the new VOC external references are appropriate.
288
Updating Portal Pointers and Settings (Portal Cloning)
Updating Portal Pointers and Settings (Portal Cloning)

If youre using the Colleague Portal, perform this procedure to update pointers and settings in the new test environment.
Step 1. In SA Valet, connect to the newly cloned test Colleague environment.
Step 2. Add a new Portal node pointing to the new site collection you created in Copying the SharePoint Portal (Portal Cloning) on page 234. For detailed instructions, see Defining Portal Connection Properties in Colleague in the Post-Install Configuration chapter of the Portal Installation Procedures.
Step 3. Log in to the new Colleague test environment and access the Portal Parameters (PTLP) form.
Step 4. Detail to each of the available parameters forms to see if the value in the test environment should be updated in any way. .
Technical Tip: Pay special attention to the constituency group name prefix specified on the Portal Group Prefixes (PLGP) form. See Figure 121 on page 290.
289
Figure 121: Portal Group Prefixes (PLGP) Form
Step 5. You can use the Web User ID and Pin Options (WUIP) form to find out whether or not you are using a custom subroutine for domain or context. If you are using a custom LDAP domain subroutine or a custom context subroutine, check to see if either one of the routines contains references to the LDAP production server. If so, update them to reference the test server instead.
290
Updating the Domain Pointer for Users
Updating the Domain Pointer for Users

Note: This section is applicable for all institutions that use Active Directory authentication for their production users.
You will need to update the domain pointer for all users in the test environment registry. When you perform a clone of a Colleague environment, the LDAP environment setup (SA Valet setting) is reset so that you are not updating production servers. You updated these values to match the test LDAP server using the procedure in Copying the DMI Listeners on page 261. However, individual user records were not updated. This means that user registry records in the ORG.ENTITY.ENV file still contain references to the production LDAP server. This does not present a security risk since the Colleague test environment has no knowledge of the production LDAP server name and therefore will not use it for anything.
Step 1. Update the domain pointer for all users in the registry in the test environment, including those that you did not migrate from the production LDAP server. This will completely remove all references to the production LDAP server.
Step 2. You can do this by running the Assign Dir Server to Resource (ADTR) process in your new test Colleague environment for all records in the ORG.ENTITY.ENV file. Leave the Saved List Name and Resources Included fields empty. See Figure 122 on page 292.
291
Figure 122: Assign Dir Server to Resource (ADTR) Form
292
Updating the Primary Constituency of All Users (Portal Cloning)
Updating the Primary Constituency of All Users (Portal Cloning)

If you are using the Colleague Portal, update the primary constituency of all of your users in the new test SharePoint portal. Since primary constituency information is stored in the Shared Services of a SharePoint farm, this information is not migrated when a site collection is copied into a new server. Use the EDX Initialize/Synchronize (EDIS) process to trigger the PRTL subscriber for the ORG.ENTITY.ENV file, topic PRTL-USER, for all users that were copied from the test LDAP server to the production LDAP server.
Figure 123: EDX Initialize/Synchronize (EDIS) Form
293
Updating SharePoint Colleague Connectors and Other Settings (Portal Cloning)

Step 1. Log into your test SharePoint server. Use the Colleague Servlet URLs form in the Colleague Portal Configuration Tool (Figure 124) to update the location of all Colleague servlets to point to the servlets in the newly cloned test environment.
Figure 124: Colleague Servlet URLs
Step 2. If you have also cloned your course catalog site collection, confirm that the web application for the course catalog is also updated with the new Colleague servlets.
Step 3. Log in to the cloned test course catalog and access Site Actions > Site Settings > Modify all Site Settings.
294
Updating SharePoint Colleague Connectors and Other Settings (Portal Cloning)
Step 4. Select Site Collection Features to locate the Course Catalog Timer Job feature and deactivate it.
Step 5. Re-activate the Course Catalog Timer Job feature to reset the pointers for the course catalog timer job.
Step 6. If custom search scopes existed in your production Shared Services provider (for example, My Team Sites or Course Catalog scopes), access the Shared Services provider in the SharePoint test server and manually recreate the search scopes. Make sure to use the corresponding url in the test server for each scope. The custom search scopes will not have been copied with the site collection copy. Repeat for any other environment-specific search setups such as Crawl Rules.
Testing Your Results

Step 1. Log into the portal as a member of a constituency, a class team site, and as an administrator.
Step 2. Ensure that all web parts are working and that all permissions are correct. Keep in mind that if you exported and imported Active Directory users, their passwords were reset to either a blank (if you do not have group policy restrictions on your test LDAP server) or to the password you specified. As a result, you may have to reset the password for individual users the first time they login.
295
Setting Up User Access Features

You might have set up the source environment to use either or both of the following user access features: Windows authentication (SQL Server only) Single role Colleague access (SQL Server and Oracle only) Those settings are not copied to the target environment. If you want the target environment to use Windows authentication or single role access, you will need to set them up using the procedures in Managing Colleague Software Environments.
Installing and Setting Up Interfacing Software

The cloning process creates a working Colleague application environment, but it does not copy WebAdvisor, the Colleague portal, or third-party software and add-on components (such as Safari, Campus Cruiser, Resource25, and Telephone Registration). If you want to use those components in the target environment, you will need to install and set them up separately.
296
Worksheets
Worksheets
Use the worksheets in this section to record information about the new (target) application environment. You may want to copy these worksheets (or print them from the PDF file) and record the information on the copies. This method makes the worksheets easily accessible both when you are filling them out and when you are referring back to your entries. The procedures in this chapter refer to the ID column in each worksheet for the appropriate worksheet entries.
Table 60: Worksheet: Name of Target Application Environment (Discussion on page 226) Example Application Environment Name
training
Enter a Name for Your Target Application Environment
ID
AF
Table 61: Worksheet: DMI Listener Ports for Target Application Environment (Discussion on page 226) DMI Listener
DMI data access server for the Colleague database DMI application server Other DMI Listeners
Example
Unsecure Port Enter Your Port
ID
A G AI A K
Example
Secure Port Enter Your Port
ID
A H AJ A L
297
298
Table 62: Worksheet: Directory Structure for Target Application Environment (Discussion on page 226) Configuration
SQL Server or Oracle Use this section if you are using SQL Server or Oracle
Installed Software
DMI data access server for the Colleague database Colleague executables DMI application server Other DMI Listeners
Example Patha
U)/datatel/coll18/training/das W)D:\datatel\coll18\training\das U)/datatel/coll18/training/apphome W)D:\datatel\coll18\training\apphome U)/datatel/coll18/training/svr01 W)D:\datatel\coll18\training\svr01 U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02 U)/datatel/coll18/training/svr03 W)D:\datatel\coll18\training\svr03
ID
AM
AN AO AP
UniData Use this section if you are using UniData Installation Procedures, February 21, 2013
DMI data access server for the Colleague database Colleague executables and data DMI application server Other DMI Listeners
U)/datatel/coll18/training/das W)D:\datatel\coll18\training\das U)/datatel/coll18/training/apphome W)D:\datatel\coll18\training\apphome U)/datatel/coll18/training/svr01 W)D:\datatel\coll18\training\svr01 U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02 U)/datatel/coll18/training/svr03 W)D:\datatel\coll18\training\svr03
AQ
AR AS AT
Worksheets
Table 63: Worksheet: JRE Paths (Discussion on page 227) Computer

Database computer App server computer Other computerb
Example Path to JREa

U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre
ID
AU
AV
AW
a. U/JRE = UNIX example with the JRE installed U/SDK = UNIX example with the SDK installed (the SDK is required for Oracle on the application server computer) W = Windows example with the SDK installed b. If you plan to install DMI Listeners on computers other than the database computer or application server computer, a JRE or SDK must be installed on those computers as well.
Table 64: Worksheet: Colleague Administrative User (Discussion on page 243) Example Username
administrator
Enter Your Username
ID
AX
Table 65: Worksheet: SQL Server Database Name (Discussion on page 246) Example Database Name
coll18_training
Enter Your Username
ID
AY
Table 66: Worksheet: Oracle Instance and Username (Oracle Only) (Discussion on page 249) Example Instance Namea
dtrain11
Enter Your Instance Name
ID
AZ
Example Username
coll18_training
Enter Your Usernameb
ID
BA
a. In this example instance name, d indicates Datatel and 11 indicates Oracle version 11. b. This is the username that matches the tablespace name. See Step 6 on page 251.
299
300
Appendices
Appendices
DMI Listener Names
Listener Naming Convention

When you create a DMI Listener from one of the wizards in SA Valet, it is assigned a name as shown in Table 67.
Table 67: DMI Listener Names Wizard
Create Local Product Repository Create Application Environment or Clone Application Environment
DMI Listener
DMI data access server for the local product repository DMI data access server for the Colleague database DMI application server Other application environment Listeners
Listener Name Syntax

lpr name_DB_LISTENER
Example
coll18_DB_LISTENER
environment name_DB_LISTENER
test_DB_LISTENER
environment name_APP_LISTENER environment name_listener namea
test_APP_LISTENER test_PrintServera
New DMI Listener or Clone Application Environment
a. You specify the listener name in the New DMI Listener wizard or the Clone Application Environment wizard.
This Listener name appears in several places, including: In Windows, this name appears in the Services folder (Figure 125 on page 304). In UNIX, this name appears as the process ID if you view a list of running processes. It also appears as the Listener name in the datateltab file.
303
Appendices: DMI Listener Names
Figure 125: Example of DMI Listener Name in Windows Services Folder
304
Appendices A
Glossary
In This Appendix
This appendix defines terms associated with Colleague Release 18.
Definitions
A
account
No longer used as a Colleague term. Live and test accounts are now referred to as production and test application environments. Main and remote accounts no longer exist. However, UniData clients will continue to use account in reference to a UniData database.
application
Datatel Colleague Student, Datatel Colleague Finance, Datatel Colleague HR, Datatel Colleague Core, Datatel Envision Runtime (UT), and Datatel Colleague Advancement.
application server (Datatel application server)

Colleague executables, running on a UniData virtual machine (VM), and the DMI Listener, that work together to make the Colleague application run. In Release 18 architecture, the database does not reside on this server. Clients will likely have production, test, and development application servers.
305
Appendices: Glossary
C
Colleague application environment
The combination of an application server, database server, and other software components that work together to perform Colleague functions. Clients will likely have production, test, and development application environments.
Colleague executables
Colleague software components that run on a UniData virtual machine (VM). These are part of the application server.
columnar I/O
An efficient method of accessing data from a database in which only the required fields/columns are retrieved, not the whole record/row of data. Release 18 includes columnar I/O for all processes that would noticeably benefit from this performance enhancement.
computed column
Previously known as a virtual field or I-descriptor. Some computed columns are calculated every time they are read from the data, and some have the value stored. See also stored computed column.
D
database or database environment
The database itself (UniData, SQL Server, Oracle). The location where the data files/tables reside.
database server
The combination of the DMI data access server and the database itself.
306
Definitions
database independent architecture

The new system architecture including a database server and separate application server. With this architecture, the application software has no direct interaction with the database.
Datatel daemon
Communications software used to access DMI Listeners and to transfer files during installation. It performs functions typically performed by Telnet and FTP. The daemon is designed to work with all operating systems supported by Datatel. (Telnet and FTP are not consistent across the operating systems.)
DMI
Datatel Messaging Interface. A highly efficient message structure for communication between DMI Listeners and other Datatel software components.
DMI Listener
Datatel server software for the Datatel system that follows the J2EE models. DMI Listener roles are extensible through the use of Java extensions (plugins). A DMI Listener utilizes the DMI protocol for communication. There will be multiple DMI Listeners in a single application environment. Each DMI Listener can be assigned one or more roles. Roles are defined by the extensions that you install in your environment. Currently, Datatel delivers the following extensions/roles for DMI Listeners: DMI data access server (DBAS) DMI application server (APPS) DMI print server (DMI_PS) DMI Windows INAS Services (INAS) DMI reporting database access server (RDAS) All DMI Listeners have the following functionality: Security Data transformation services using XML/XSLT Thread management Java Runtime Environment (JRE)
307
DMI application server (APPS)

Software that provides access to the Datatel application. Most external software that interfaces with Colleague uses this Listener to exchange communications. A DMI application server has the following additional specialized functionality: Application server for WebAdvisor, between the Web server and Colleague, and other web software. The UniData runtime environment. Communications hub for EDX/partner interfaces.
DMI data access server (DBAS)

Software that controls access to the data in the database environment. This is the primary method for the application environment to communicate with the database environment. A Colleague installation includes a DMI data access server for the product repository database, as well as a DMI data access server in each application environment for the Colleague database. JDBC-based extensible database interface is the DMI data access servers additional specialized functionality.
DMI print server (DMI_PS)

Software that controls access to printers in the Microsoft Windows environment. DMI print server acts as a print server between the application server and the printer. This role is used for stylesheet printing.
DMI reporting database access server (RDAS)

This role is used for the DataOrchestrator ODS reporting solution. Listeners with this role must be installed on the ODS target database server. You must also specify the DBAS role for a Listener to be used for the DataOrchestrator ODS reporting solution.
DMI Windows INAS services (INAS)

Software that sends INAS transactions to the College Board. Transactions include application data and calculated data like Estimated Family Contributions (EFCs). Listeners with this role must reside on a Windows server.
308
Definitions
E
emitter
Datatel uses emitters on the data access server to translate information into a language that the native database understands. The emitter translates an abstract syntax tree (AST) into code of a specific language. The emitter uses the AST that the lexer/parser produced. Emitters can work off the same abstract syntax tree and produce code for multiple languages.
I
installation/release account
Obsolete term. In Release 17, what was referred to as the installation account and the main account are combined in Release 18 to become the application environment.
L
lexer
Datatel uses lexers to perform linear/lexical analysis and convert a stream of characters into tokens. These tokens are sent to parsers.
live account
Obsolete term, now called the production environment.
local product repository

A designated location on your system where the Datatel release system stores all Datatel software versions needed for Colleague. The release system installs only your licensed software components from the product repository to the application environments.
309
M
main account
Obsolete term. See Colleague application environment.
P
parser
Datatel uses parsers to create a tree of tokens (abstract syntax tree). This produces an intermediate representation of information that can be sent to an emitter and translated into a variety of software languages.
R
release account
Obsolete term. In Release 17, what is referred to as the release account and the main account is combined in Release 18 to become the Colleague application environment.
S
SA Valet
The application tool that supports Datatel system administration. Datatel SA Valet administers the DMI servers on the Datatel system and runs on a Microsoft Windows machine. In Release 18, SA Valet is also the interface for the release system.
310
Definitions
server
A collection of software dedicated to a specific use. For example, a print server is a collection of software dedicated to the function of printing. Application servers are collections of software dedicated to accessing a specific application. The computer that a server program runs on is also frequently referred to as a server.
stored computed column

A computed column for which the calculated value is stored in a file related to the appropriate data file. Stored computed columns do not have to be recalculated every time they are requested from the database.
T
transaction server
Obsolete term. This functionality is now part of the application server.
U
user remote account
Obsolete term. These do not exist in the Release 18 architecture.
V
virtual field/I-descriptor
Obsolete term. This is now called a computed column.
311
virtual machine (VM)

Software that acts as an interface between the application code and the microprocessor that actually performs the programs instructions. Datatel uses a UniData virtual machine and a Java VM (JVM).
312

ColleagueR18InstallationProcedures 02212013

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ColleagueR18InstallationProcedures 02212013

Caricato da

Copyright:

Formati disponibili

Installation Procedures

Reissued Manual as of February 21, 2013

Updating Your Manual

Colleague by Ellucian Installation Procedures

Colleague Release 18 Description

Installation Procedures, February 21, 2013

Installation Procedures, February 21, 2013

Installation Procedures, February 21, 2013

Creating the Local Product Repository

Populating the Local Product Repository

Application Environment Creation

Populating the Application Environment

Installation Procedures, February 21, 2013

168 171 178 180 182 183 184 184 187

Setting Up New Environments

Other Application Environment Procedures

Installation Procedures, February 21, 2013

205 205 206 207 212

Implementing Multiple DMI Data Access Servers

Cloning an Application Environment

Installation Procedures, February 21, 2013

Installation Procedures, February 21, 2013

Installation Procedures, February 21, 2013

About This Manual

Who Should Read This Manual

What This Manual Covers

Installation Procedures, February 21, 2013

Introduction: About This Manual

How This Manual is Organized

Populating the Application Environment Setting Up New Environments

Installation Procedures, February 21, 2013

How This Manual is Organized

Table 1: Organization of This Manual (contd) Chapter

Installation Procedures, February 21, 2013

Introduction: About This Manual

Where to Find More Information

Updating Colleague Software Managing Colleague Software Environments

Installation Procedures, February 21, 2013

Colleague Release 18 Description

Installation Procedures, February 21, 2013

Introduction: Colleague Release 18 Description

Components Used for Colleague Operation

Colleague Application Environment

Installation Procedures, February 21, 2013

Figure 1: Components Used for Colleague Operation

Installation Procedures, February 21, 2013 21

RDBMS (Oracle, SQL Server, or UniData)

Components Used for Colleague Operation

Colleague application environment

Introduction: Colleague Release 18 Description

Installation Procedures, February 21, 2013

Components Used for Colleague Operation

Installation Procedures, February 21, 2013

Introduction: Colleague Release 18 Description

Components Used for Colleague Installation

Installation Procedures, February 21, 2013

Components Used for Colleague Installation

Figure 2: Components Used for Colleague Installation

Colleague executables UniData VM

RDBMS (Oracle, SQL Server, or UniData)

DMI data access server for product repository

Colleague release package (at Ellucian or on DVD)