ColleagueR18InstallationProcedures-02212013

Installation ProceduresReissued 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 ManualReplace all copies of your existing manual with this new edition as it will be the basis for all future updates.

Colleague by EllucianInstallation Procedures

Release 18February 21, 2013

For corrections and clarifications to this manual, see AnswerNet page 3474

http://clients.datatel.com/support/support.cfm?TYPE=ABCARD&ID=2B9675DE49154E68B628ACED68FC814E&pagenum=3474&Action=Search

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.

© 2006–2013 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 Introduction

15 About This Manual15 Who Should Read This Manual15 What This Manual Covers16 How This Manual is Organized18 Where to Find More Information

19 Colleague Release 18 Description19 In This Chapter20 Components Used for Colleague Operation20 Colleague Application Environment20 Application Server22 Database Server22 SA Valet22 Other Components24 Components Used for Colleague Installation27 Local Product Repository and Application Environments

29 Installation Overview29 In This Chapter30 Installation of the Basic Release System30 Installation of SA Valet31 Creation of the Local Product Repository32 Population of the Local Product Repository33 Installation of an Application Environment33 Creation of a New Release 18 Application Environment34 Creation of the Application Environment36 Population of the Application Environment38 Cloning an Existing Application Environment

39 Preparation

41 Preparing for the Installation41 In This Chapter42 Understanding Preparation for R18 Installation42 When to Perform These Preparation Steps43 High-Level Procedure for a New Application Environment

Installation Procedures, February 21, 2013 5

Table of Contents

43 High-Level Procedure for a New Application Server Computer

44 High-Level Procedure for a New Database Computer46 Computer Configuration47 Example Configuration for SQL Server or Oracle48 Example Configurations for UniData49 Planning: Names, Directories, and Ports49 Application Environment Names49 Directory Structure50 Example Paths50 Directory Naming Conventions52 Directory Structure Example for SQL Server or Oracle53 Directory Structure Example for UniData54 DMI Listener Ports54 Identifying Ports That Are Already in Use55 Port 9000 Reserved for Datatel Daemon56 Checking Computer Requirements56 Operating System Requirement56 Hardware Requirements57 Installing Supporting Software57 Licensing Colleague Application Server57 Installing the JRE or SDK58 Server Mode58 Creating Supporting Files (UNIX Only)60 Installing the Datatel Daemons61 Prerequisites and Requirements for UNIX or Linux62 Permissions for UNIX63 Prerequisites and Requirements for Windows63 Stopping the Daemon (Replacement Only)65 Procedure for Installing a Datatel Daemon on Windows68 Procedure for Installing a Datatel Daemon on

UNIX/Linux71 Daemon Auto-Start Setup (UNIX/Linux Only)72 Setting Up UniData for the Colleague Executables72 Installing UniData73 Configuring UniData on the Application Server Computer73 Resizing the Master VOC File74 Adjusting UniData Environment Variables76 Setting UniData Configuration Parameters77 Installing the Oracle Client on the Application Server

(Oracle Only)77 Creating Administrative Users on the Application Server

Computer

6 Installation Procedures, February 21, 2013

Table of Contents

79 Setting Up UniData Databases on the Application Server Computer

79 Establishing Free Space for File Updates80 Setting Up Databases and Administrative Users on the

Database Computer81 Setting Up SQL Server81 Installing SQL Server82 Creating Databases and Administrative Users for SQL

Server84 Configuring SQL Server 200885 Setting up a SQL Server 2008 Database to Use C#

Code87 Setting Up Oracle87 Installing Oracle87 Installing Oracle Patches88 Creating Instances, Tablespaces, and Users for Oracle93 Setting Up UniData on the Database Computer93 Installing UniData on the Database Computer93 Creating Administrative Users for UniData on the

Database Computer94 Configuring UniData on the Database Computer95 Application Environment Preparation95 Worksheets

103 Release System

105 Installing SA Valet105 In This Chapter106 SA Valet Installation Overview107 Before You Begin107 Software Updates109 Quick Start: Upgrading SA Valet110 Installing SA Valet112 Self Update Functionality113 Setting the Run as Administrator Options115 Installing JDBC Drivers (Oracle Only)116 Setting Up Hosts in SA Valet118 Defining LPR and Host Properties in a Second SA Valet119 Securing the Connection Between SA Valet and the Datatel

Daemon


Table of Contents

121 Creating the Local Product Repository121 In This Chapter121 Before You Begin122 Procedure for Creating the Local Product Repository

131 Populating the Local Product Repository131 In This Chapter131 Before You Begin132 Populating the Local Product Repository132 Populating the Local Product Repository From the DVD132 Testing the DVD Drive132 Refreshing Licensing Information135 Loading the Release Package from the DVD136 Populating the Local Product Repository Over the Internet136 Local Product Repository (LPR) Tables

139 Application Environment Creation

141 Creating the Application Environment141 In This Chapter141 Cloning an Existing Application Environment142 Before You Begin142 Retrieving Software Updates142 Full Release vs. Consolidated Full Release143 Full Release143 Consolidated Full Release145 Creating the Application Environment155 Upgrading DMI Listeners

157 Populating the Application Environment157 In This Chapter157 Before You Begin158 Externally Authenticating the Administrative User (Oracle

Only)159 Procedure for Populating the Application Environment162 Troubleshooting Using the COMO File163 Compiling/Validating Invalid Java Classes (Oracle)

165 Post-Install Procedures165 In This Chapter166 Running Automated Post-Install Steps


Table of Contents

168 Update Computed Column Parameters (SQL Server and Oracle Only)

171 Building the PERSON File Indexes178 Looking Up PERSON Records Without an ID180 Dictionary Date Conversion182 Modify WWW Files (RPI)183 Running the EDX Interface Load Utility184 Modify Campus Organizations SQL Function184 Defining the Permitted Number of Database Connections187 Setting up an Environment as Production

189 Setting Up New Environments189 In This Chapter190 Building New File Indexes191 Building Application Security192 Defining Listener Parameters193 Creating a Printer Control Record194 Procedure for Creating the Printer Control Record on UNIX

or Linux195 Creating the Printer Control Record and Validation Code

on Windows195 Procedure for Creating the Printer Control Record

(Windows)196 Procedure for Creating the VALID.PRINTERS

Validation Code (Windows/Networked Printers)198 Specifying Permissions for Core Custom Code (UNIX/Linux

Only)198 Understanding Permissions for Core Custom Code199 Procedure for Specifying Permissions for Core Custom

Code200 Installing Software Updates and Custom Release Packages200 Procedure for Installing Software Updates and Custom

Release Packages

201 Other Application Environment Procedures

203 Installing a New DMI Listener203 In This Chapter204 Understanding DMI Listener Installation205 Planning205 Listener Ports


Table of Contents

205 Listener Installation Path205 Path to JRE or SDK206 Worksheets207 Procedure for Installing a New DMI Listener212 Defining Listener Parameters

213 Implementing Multiple DMI Data Access Servers

213 In This Chapter213 Before You Begin214 Implementing Multiple DAS Listeners215 Procedure for Implementing Multiple DAS Listeners

219 Cloning an Application Environment219 In This Chapter220 Terminology220 Understanding Cloning221 High-Level Procedure for Cloning an Application

Environment225 Preparing for Cloning225 Checking the Configuration226 Application Environment Name226 Directory Structure for Target Application Environment226 DMI Listener Ports227 Path to JRE or SDK228 Preparing for Cloning with the Colleague Portal (Portal

Cloning)229 Before You Begin230 Copying the Active Directory Users230 Example Procedure234 Copying the SharePoint Portal (Portal Cloning)237 Updating User Permissions to the Test Active Directory

Domain (Portal Cloning)239 Adding LDAP Groups to the Portal (Portal Cloning)239 Adding the LDAP Groups as Members of Constituency

Sites240 Adding the LDAP Groups as Members of the Top-Level

Portal Site241 Copying the Colleague Executables241 Procedure for Copying the Colleague Executables243 Creating an Administrative Login for the Application Server244 Setting Up the Application Environment in User Interface245 Copying the Colleague Data


Table of Contents

245 Copying Colleague Data for SQL Server245 Copying the Database247 Creating an Administrative User for the SQL Server

Database248 Copying Colleague Data for Oracle248 Prerequisite Checks249 Creating the Instance, Tablespaces, and Users252 Copying Table Definitions254 Exporting the Data from the Source Schema255 Importing the Data to the Target Schema256 Verification257 Moving Indexes to the Index Tablespace259 Changing the Oracle Java Resolver259 Cleanup260 Copying Colleague Data for UniData261 Copying the DMI Listeners261 Running the Clone Application Environment Wizard272 Starting the New Listeners274 Correcting Environment-Specific Values275 Securing the BECU Form275 Environment-Specific Parameters275 Understanding Environment-Specific Parameters276 Cleanup Specifications277 Noteworthy Fields on the MECD Form280 Environment Cleanup Report282 Procedures for Changing Environment-Specific

Parameters286 External VOC References288 Procedure for Correcting External VOC References289 Updating Portal Pointers and Settings (Portal Cloning)291 Updating the Domain Pointer for Users293 Updating the Primary Constituency of All Users (Portal

Cloning)294 Updating SharePoint Colleague Connectors and Other

Settings (Portal Cloning)295 Testing Your Results296 Setting Up User Access Features296 Installing and Setting Up Interfacing Software297 Worksheets


Table of Contents

301 Appendices

303 DMI Listener Names303 Listener Naming Convention

305 Glossary305 In This Appendix305 Definitions


Installation ProceduresIntroduction

Introduction0

About This Manual

Who Should Read This ManualAnyone responsible for installing Colleague Release 18 should read this manual.

What This Manual CoversThis manual provides instructions for installing Colleague Release 18. Specifically, this manual covers:

Preparing for Colleague installation.

Installing SA Valet, Ellucian’s 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.


Introduction: About This Manual

How This Manual is OrganizedTable 1 shows the content of each chapter in this manual.

Table 1: Organization of This Manual

Chapter Page Description

Introduction

About This Manual 15 Information about this manual and its organization.

Colleague Release 18 Description

19 Description of Colleague configuration during both normal operation and installation.

Installation Overview 29 Description of the installation of the basic release system and Colleague application environments.

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.

Release System—These 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 105 Procedure for installing SA Valet, Ellucian’s system administration application.

Creating the Local Product Repository

121 Procedure for creating the local product repository (the database that stores Colleague software obtained from Ellucian).

Populating the Local Product Repository

131 Procedure for retrieving Colleague software from Ellucian and storing it in the local product repository.

Application Environments—These chapters contain procedures to be performed each time you create an application environment.

Application Environment Overview

147 High-level information about creating an application environment.

Creating the Application Environment

141 Procedure for creating a Colleague application environment and Colleague database. The application environment contains Colleague and Envision software, and the database contains Colleague data.

Populating the Application Environment

157 Procedure for populating the application environment with software from the local product repository.

Setting Up New Environments

189 Procedures to be performed only in new application environments after populating the application environment.


How This Manual is Organized

Updating the Application Environment

192 Procedures to be performed in all application environments after populating the application environment.

Post-Install Procedures 165 Final post-install procedures to be performed in all application environments.

Other Application Environment Procedures

Installing a New DMI Listener

203 Procedure for installing a new DMI Listener in an application environment and for specifying Listener performance parameters.

Implementing Multiple DMI Data Access Servers

213 Procedure for installing and configuring secondary DAS Listeners.

Cloning an Application Environment

219 Procedures for creating a Colleague application environment by cloning an existing application environment.

Appendices

DMI Listener Names 303 Information about names assigned to DMI Listeners.

Running the Prior Version of SA Valet

305 Information about accessing SA Valet 2.4.0 temporarily., or permanently reverting to SA Valet 2.4.0 if needed.

Glossary 305 Definitions of terms associated with Colleague Release 18.

Table 1: Organization of This Manual (cont’d)

Chapter Page Description


Introduction: About This Manual

Where to Find More InformationTable 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 Source

Setting up your Colleague application environments to make them available in User Interface (UI).

User Interface 4.x Installation and Administration

Integrating Colleague with WebAdvisor. WebAdvisor Installation and Administration (currently for WebAdvisor 3.1.6)

Using Envision Data Exchange to create interfaces between Colleague and third-party software, including e-learning systems, portals, and government reporting software.

EDX Administration

Updating your Colleague application environments with software updates from Ellucian.

Updating Colleague Software

Other aspects of administering your Colleague application environments.

Managing Colleague Software Environments


http://clients.datatel.com/documentation

Introduction0

Colleague Release 18 Description

In This ChapterThis 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 Page

Components Used for Colleague Operation 20

Components Used for Colleague Installation 24


Introduction: Colleague Release 18 Description

Components Used for Colleague Operation

Figure 1 on page 21 shows the components for Colleague operation.

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.

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.

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.


Co

mp

on

ents U

sed fo

r Co

lleagu

e Op

eration

Installation Procedures, F

ebruary 21, 201321

ue database computer

Colleague database

DMI data access server

Colleague application environment

RDBMS (Oracle, SQL Server, or UniData)

Datatel daemon

Figure 1: Components Used for Colleague Operation

ColleagApplication server computer

Colleague executables

DMI application server

SA Valet computer

SA Valet

Components addressed in other Ellucian manuals

web server

UI client

DMI print server

DMI RPC server

EDX/partner interfaces

(UniData VM

Application server

Database server

Components addressed in this manual

Datatel daemon


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 Ellucian’s 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.


Components Used for Colleague Operation

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 user’s 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 third-party 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.



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.



Figure 2: Components Used for Colleague Installation

Application server computer



SA Valet computer

Installation programs

SA Valet

These components are used only during installation of a full release or software updates

Product repository computer

Local product repository

DMI data access server for product repository

Colleague release package (at Ellucian or on DVD)

UniData VM

Colleague database computer

DMI data access server for Colleague database


Colleague database


Datatel daemon

Datatel daemon


Datatel daemon



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.



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)




Introduction3

Installation Overview

In This ChapterThis chapter provides an overview of Release 18 installation. Table 4 lists the topics covered in this chapter.


Topic Page Comments

Installation of the Basic Release System 30 You will perform these procedures once, before you create Colleague application environments.Installation of SA Valet 30

Creation of the Local Product Repository 31

Population of the Local Product Repository 32

Installation of an Application Environment 33 You will perform these procedures multiple times, once for each of your Colleague application environments.

Creation of a New Release 18 Application Environment 33

Cloning an Existing Application Environment 38


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.

Installation of SA Valet

The following components are installed with SA Valet (Figure 4):

SA Valet, Ellucian’s 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

Table 5: Steps in Installation of the Basic Release System

Step Description Procedure

Install SA Valet page 30 page 105

Create the local product repository page 31 page 121

Populate the local product repository page 32 page 131

SA Valet computer


SA Valet


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

SA Valet computer






SA Valet



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

SA Valet computer


SA Valet




DMI data access serverColleague

release package (at Ellucian or on DVD)


Installation of an Application Environment

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 Description Procedure

Create the application environment page 34 page 141

Populate the application environment page 36 page 157



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.


Installatio

n o

f an A

pp

lication

En

viron

men

t


ebruary 21, 201335



roduct repository computer



Colleague database

Figure 7: Creation of the Application Environment



SA Valet computer


SA Valet

P

Application environment

UniData VM



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 Ellucian-defined values.

For the installation procedure, see “Populating the Application Environment” on page 157.


Installatio

n o

f an A

pp

lication

En

viron

men

t


ebruary 21, 201337






Colleague database

Figure 8: Population of the Application Environment



SA Valet computer


SA Valet

Application environment


UniData VM



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.


Installation ProceduresPreparation

Preparation8

Preparing for the Installation

In This ChapterThis 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.

In addition to this chapter, Managing Colleague Software Environments contains beneficial information about managing users and role-based security setup.


Topic Page

Understanding Preparation for R18 Installation 42

Planning: Names, Directories, and Ports 49

Checking Computer Requirements 56

Installing Supporting Software 57

Setting Up UniData for the Colleague Executables 72

Setting Up UniData Databases on the Application Server Computer 79

Setting Up Databases and Administrative Users on the Database Computer

80

Application Environment Preparation 95

Worksheets 95


Preparation: Preparing for the Installation

Understanding Preparation for R18 Installation

Table 8 lists the topics covered in this section.

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.

Table 8: Topics in This Section

Topic Page

When to Perform These Preparation Steps 42

High-Level Procedure for a New Application Server Computer 43

High-Level Procedure for a New Database Computer 44

Computer Configuration 46



High-Level Procedure for a New Application Environment

Table 9 lists the steps in setting up a new application environment.

High-Level Procedure for a New Application Server Computer

Table 10 lists the steps in setting up a new application server computer.

Table 9: HIgh-Level Procedure for a New Application Environment

Step See...

Plan the application environment name, directory structure, and ports. page 49

Recheck hardware requirements. page 56

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.

page 76

Create an administrative user for the Colleague executables. page 77

Create the database and the administrative database users. page 80

Set up the application environment in User Interface. page 95

Table 10: High-Level Procedure for a New Application Server Computer

Step Reference

Check operating system requirement. page 56

Check hardware requirements. page 56

Install JRE and supporting files. page 57

Create datateltab file (UNIX only). page 58

Install the Datatel daemon. page 60

Add the new computer to the Hosts tab in each installation of SA Valet.

page 116

Secure the connection between the daemon on the new computer and each installation of SA Valet.


Install UniData page 72



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.

Resize the master VOC file page 73

Adjust UniData environment variables page 74

Set UniData configuration parameters. page 76

Create administrative users for the Colleague executables.

page 77

Perform the steps below if you are using UniData.

Establish free space for file updates. page 79

Table 10: High-Level Procedure for a New Application Server Computer

Step Reference

Table 11: High-Level Procedure for a New Database Computer

Step Reference

Everyone should perform the steps in this section.

Check operating system requirement. page 56

Check hardware requirements. page 56

Install JRE and supporting files. page 57

Create datateltab file (UNIX only). page 58

Install and start the Datatel daemon. page 60

Add the new computer to the Hosts tab in each installation of SA Valet.

page 116

Secure the connection between the daemon on the new computer and each installation of SA Valet.


Perform the steps below if you are using the SQL Server database.

Install SQL Server. page 81

Create databases and administrative users. page 82



Perform the steps below if you are using the Oracle database.

Install Oracle. page 87

Create instances, tablespaces, and users. page 88

Table 11: High-Level Procedure for a New Database Computer (cont’d)

Step Reference



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 Oracle—see page 47.

UniData—see page 48.

Your computer configuration depends on your choice of relational database management system and other factors. Ellucian’s Professional Services Team can assist you in selecting a configuration.



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

Colleague database (production)


Colleague executables (production)


UniData VM

DMI data access server (production)

DMI application server (production)

Colleague database (test)

Colleague executables (test)


DMI data access server (test)

DMI application server (test)

Colleague database (development)

Colleague executables (development)


DMI data access server (development)

DMI application server (development)


DMI data access server (product repository)

Database computer

SQL Server or Oracle RDBMS



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

Colleague executables and database (production)


UniData RDBMS

DMI data access server (production)

DMI application server (production)


DMI data access server (test)

DMI application server (test)


DMI data access server (development)

DMI application server (development)


DMI data access server (local product repository)

Colleague executables and database (test)

Colleague executables and database (development)


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.

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 don’t have to create them before installing Colleague. However, you should plan the directory structure before installing.

Table 12: Planning Topics in This Section

Topic Page

Application Environment Names below

Directory Structure 49

DMI Listener Ports 54

Port 9000 Reserved for Datatel Daemon 55



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.

Example Paths

The examples paths in the worksheets are Ellucian’s 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

Table 13: Location of Directory Structure Examples and Worksheets

Situation Example Worksheet

SQL Server or Oracle Figure 11 on page 52 Table 25 on page 96

UniData Figure 12 on page 53 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.



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.


Preparatio

n: P

reparing

for th

e Installatio

n

52Installation P

rocedures, February 21, 2013

racle

atabase. Use the worksheet in ructure.

another environment

apphome svr01 svr02 svrnn

Directory Structure Example for SQL Server or O

Figure 11 is an example directory structure for a SQL Server or Oracle dTable 25 on page 96 to record the installation paths for your directory st

Figure 11: Suggested Directory Structure for SQL Server or Oracle


Ellucian

coll18

production

apphome svr01 svr02

test development

svrnn

Database computer

Ellucian

coll18

production test development

das dasdas

repository_das

apphome svr01 svr02 svrnn apphome svr01 svr02 svrnn

SQL Server or Oracle

Plan

nin

g: N

ames, D

irectories, an

d P

orts


ebruary 21, 201353

worksheet in Table 26 on page 97

velopment

e svr01 svr02 svrnn

another environment

Directory Structure Example for UniData

Figure 12 is an example directory structure for a UniData database. Use the to record the installation paths for your directory structure.

Figure 12: Suggested Directory Structure for UniData


Ellucian

coll18

production

apphome svr01 svr02

test de

svrnndas

repository_das

apphome svr01 svr02 svrnn apphomdasdas

coll18

UniData


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.



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.



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.

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.

Note: For more information about Linux, refer to Support Solution 4667: Linux Implementation Support Solutions.


http://clients.datatel.com/productcertifications


http://clients.datatel.com/solution_updates/hardware_configurations.cfm

http://clients.datatel.com/solution_updates/hardware_configurations.cfm

Installing Supporting Software

Installing Supporting SoftwareTable 14 lists the topics covered in this section.

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.


Topic Page

Licensing Colleague Application Server 57

Installing the JRE or SDK 57

Creating Supporting Files (UNIX Only) 58

Installing the Datatel Daemons 60



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.



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



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 Page

Prerequisites and Requirements for UNIX or Linux 61

Permissions for UNIX 62

Prerequisites and Requirements for Windows 63

Stopping the Daemon (Replacement Only) 63

Procedure for Installing a Datatel Daemon on Windows 65

Procedure for Installing a Datatel Daemon on UNIX/Linux 68

Daemon Auto-Start Setup (UNIX/Linux Only) 71



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.

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.

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.



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.

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” |

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.



/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



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:

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.

/opt/java6/jre/bin/PA_RISC2.0/java -Xmx512m -cp dmilistener.jar com.datatel.server.listener.DMIServerListener -ndaemon



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

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.

Step 4. On the Welcome window, click Next to continue.

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.

Note: If your institution uses Windows Server 2008, you must right-click the file you just downloaded and choose “Run as Administrator”. If you do not do this, the Datatel daemon will not install successfully.


http://clients.datatel.com/solution_updates/softwaredownloads.cfm


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.



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



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

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.

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.




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.



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.

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

Note: Use binary mode if you are transferring the file to the UNIX or Linux server using ftp.



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).



Setting Up UniData for the Colleague Executables

This section contains procedures for installing and configuring UniData for the Colleague executables. Table 16 lists the topics covered in this section.

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: This section applies to all clients, even those using Oracle or SQL Server for their databases.


Topic Page

Installing UniData 72

Configuring UniData on the Application Server Computer 73

Installing the Oracle Client on the Application Server (Oracle Only) 77

Creating Administrative Users on the Application Server Computer 77

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.




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.



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 user’s $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 user’s .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 user’s .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



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



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.



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 Oracle’s SQL*Plus), then install the Oracle client on the application server computer. The ESQL form uses a direct call to Oracle’s SQL*Plus on the application server, and therefore requires the Oracle client.

See the Oracle web site for the Oracle client installation procedures.

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.

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.



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, don’t 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.


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.




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.

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.

Table 17: Location of Procedures for Creating Databases

RDBMS Page

SQL Server 81

Oracle 87

UniData 93



Setting Up SQL Server

Table 18 lists the SQL Server procedures in this section.

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.


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.

Table 18: SQL Server Setup Procedures

Procedure Page

Installing SQL Server 81

Creating Databases and Administrative Users for SQL Server 82

Configuring SQL Server 2008 84

Setting up a SQL Server 2008 Database to Use C# Code 85

Update Computed Column Parameters (SQL Server and Oracle Only) 168




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.



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.



Figure 20: Sample CREATE DATABASE Script for Creating the Local Product Repository in SQL Server

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.

CREATE DATABASE coll18ON 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_BINGO

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.



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.



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.



Setting Up Oracle

Table 19 lists the Oracle procedures in this section.

Installing Oracle

On the database computer, install the latest certified release of Oracle Enterprise Edition Database Server. Review the Oracle documentation pre-installation 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.


Installing Oracle Patches

Install any major patchsets that Oracle has released for your Oracle Database Server release level.

Table 19: Oracle Setup Procedures

Procedure Page

Installing Oracle 87

Installing Oracle Patches 87

Creating Instances, Tablespaces, and Users for Oracle 88





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.



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



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.

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.

Table 20: Recommended Tablespace Sizes for Oracle

Tablespace Size (Gigabytes)Component Initial Maximum

Local product repository 2.5 10.0

Application environment, new Colleague installation

1.0 site-dependent



Figure 21: Example Statement for Creating a Tablespace for a New Colleague Installation

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.


Autoextend turned on, with maximum and next sizes defined. Table 20 shows recommendations for the initial and maximum tablespace size.

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.

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

Table 21: Recommended Index Tablespace Sizes

Tablespace Size (Gigabytes)Type of Installation Initial Maximum

New Colleague installation 1.0 site-dependent



Figure 22: Example Statement for Creating an Index Tablespace for a New Colleague Installation

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.

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

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



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.


Creating Administrative Users for UniData on the Database Computer

Use the procedure in “Creating Administrative Users on the Application Server Computer” on page 77.

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

Table 22: Oracle Privileges Required for Administrative Users

Oracle Privilege




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 Reference

Resize the master VOC file. page 73

Set UniData configuration parameters. page 76

Establish free space for file updates. page 79


Application Environment Preparation

Application Environment PreparationAfter 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.

WorksheetsUse 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)

ApplicationEnvironment

Example Application Environment Name

Enter Your Application Environment Name

ID

Production production Aa

a. During installation, specify the name for the application environment you are installing (such as production, test, or development).

Test test

Development development

Others —

—

—


Preparatio

n: P

reparing

for th

e Installatio

n

96Installation P


Directory Structure Worksheet for SQL Server or Oracle

our Installation Path ID

B

Cb

Db

Eb

Cb

Db

Eb

Cb

Db

Eb

elopment).

Table 25: Worksheet: Software Installation Paths for SQL Server or Oracle (Discussion on page 49)

Component Installed Software Example Patha

(see Figure 11 on page 52)Enter Y


DMI data access server for the local product repository

U)/datatel/coll18/repository_das W)D:\datatel\coll18\repository_das


DMI data access server for the Colleague database

U)/datatel/coll18/production/das W)D:\datatel\coll18\production\das

Colleague executables U)/datatel/coll18/production/apphome W)D:\datatel\coll18\production\apphome

DMI application server U)/datatel/coll18/production/svr01 W)D:\datatel\coll18\production\svr01



U)/datatel/coll18/test/das W)D:\datatel\coll18\test\das

Colleague executables U)/datatel/coll18/test/apphome W)D:\datatel\coll18\test\apphome

DMI application server U)/datatel/coll18/test/svr01 W)D:\datatel\coll18\test\svr01



U)/datatel/coll18/development/das W)D:\datatel\coll18\development\das

Colleague executables U)/datatel/coll18/development/apphome W)D:\datatel\coll18\development\apphome

DMI application server U)/datatel/coll18/development/svr01 W)D:\datatel\coll18\development\svr01

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 dev

Wo

rksheets


ebruary 21, 201397

r Your Path ID

F

G

Hb

Ib

Jb

Hb

Ib

Jb

Hb

Ib

Jb

ent).

Directory Structure Worksheet for UniData

Table 26: Worksheet: Software Installation Paths for UniData

Component Installed Software Example Patha

(see Figure 12 on page 53)Ente


Local product repository data account

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

Colleague executables and data

U)/datatel/coll18/production/apphome W)D:\datatel\coll18\production\apphome

DMI application server 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

DMI application server 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

DMI application server U)/datatel/coll18/development/svr01 W)D:\datatel\coll18\development\svr01

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 developm

Preparatio

n: P

reparing

for th

e Installatio

n

98Installation P


Secure Port

ID ExampleEnter

Your Port ID

K 7300 L

Ma Na

Oa Pa

Ma Na

Oa Pa

Table 27: Worksheet: DMI Listener Ports (Discussion on page 54) (Sheet 1 of 2)

Unsecure Port

Component DMI Listener ExampleEnter

Your Port


DMI data access server for the local product repository 7200




Reserved for other DMI Listeners to be installed later





Wo

rksheets


ebruary 21, 201399

Na

Pa

evelopment).

Secure Port

ExampleEnter

Your Port ID


DMI data access server for the Colleague database Ma

DMI application server Oa


a. During installation, specify the port number for the application environment you are installing (such as production, test, or d

Table 27: Worksheet: DMI Listener Ports (Discussion on page 54) (Sheet 2 of 2)

Unsecure Port

Component DMI Listener ExampleEnter

Your Port ID

Preparatio

n: P

reparing

for th

e Installatio

n

100Installation P


h to JRE ID

Q

Rb

Sb

Rb

Sb

Rb

Sb

r development).

Table 28: Worksheet: JRE Paths (Discussion on page 57)

Computer where these components are installed Example Path to JREa Enter Your Pat

Local product repository U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre


Colleague data

U/JRE)/opt/java6 U/SDK)/opt/java6/jre W)D:\jdk1.6.0_12\jre




Colleague data





Colleague data




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, o

Wo

rksheets


ebruary 21, 2013101

77)

er Your Username ID

T

Ua

vironment you are installing (such as

2)

Your Database Name ID

V

Wa

nt you are installing (such as

Table 29: Worksheet: Colleague Administrative Users (Discussion on page

DatabaseExample

UsernameEnt

Local product repository administrator

Colleague database (production) administrator

a. During installation, specify the username and password for the application enproduction, test, or development).

Colleague database (test) administrator

Colleague database (development) administrator

Table 30: Worksheet: SQL Server Database Names (Discussion on page 8

DatabaseExample

Database NameEnter

Local product repository coll18

Colleague database (production) coll18_production

a. During installation, specify the database name for the application environmeproduction, test, or development).

Colleague database (test) coll18_test

Colleague database (development) coll18_development

Preparatio

n: P

reparing

for th

e Installatio

n

102Installation P


Table 31: Worksheet: Oracle Instances and Usernames (Discussion on page 88)

plename

Enter YourUsernameb ID

Y

ction AAd

t

velopment

es Oracle version 11.n page 92. not include numbers indicating the Oracle

l in the future when you upgrade your

nment you are installing (such as

ComponentExample Instance Namea

Enter Your Instance

NameID

ExamUser


dlpr11 X coll18

App environment (production)

dprodc Zd coll_produ

App environment (test)

dtest11 coll18_tes

App environment (development)

dtest11 coll18_de

a. In these example instance names, “d” indicates Datatel and “11” indicatb. This is the username that matches the tablespace name. See Step 2 oc. For the production environment, instance names and usernames should

or Colleague version. This will ensure that these names are meaningfuproduction environment to a later version of Colleague.

d. During installation, specify the database name for the application enviroproduction, test, or development).

Installation ProceduresRelease System

Release System22

Installing SA Valet

In This ChapterThis 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.


Topic Page

SA Valet Installation Overview 106

Before You Begin 107

Installing SA Valet 110

Installing JDBC Drivers (Oracle Only) 115

Setting Up Hosts in SA Valet 116

Defining LPR and Host Properties in a Second SA Valet 118

Securing the Connection Between SA Valet and the Datatel Daemon 119


Release System: Installing SA Valet

SA Valet Installation OverviewYou 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 Perform these procedures

Upgrading an earlier version of SA Valet to 2.9.0 for an existing Colleague installation.

• Run the SA Valet 2.9.0 InstallShield

• See “Quick Start: Upgrading SA Valet” on page 109 for more information.

Installing SA Valet as the first step in your Colleague installation.

• “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


Before You Begin

Before You BeginMake 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).

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.

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.

1. A software release that is installed directly on a server by way of an InstallShield or other installer.

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.


http://clients.datatel.com/solution_updates/certifications_cessations/certifications_search.cfm

http://clients.datatel.com/solution_updates/certifications_cessations/certifications_search.cfm


Table 34: Software Components

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.

Component Description

Java 6 or 7 (JRE or JDK) Software must be installed on any workstation or server where SA Valet 2.9.0 will be installed.

.NET Framework 4

SA Valet 2.9.0 Installer Delivers all components needed to run SA Valet on your PC or Windows Server.


Quick Start: Upgrading SA Valet

Quick Start: Upgrading SA ValetIf 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.”



Installing SA ValetFollow 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.

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.

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.




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



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.

If you click Install Now, SA Valet 2.8.0 will download and then start the 2.9.0 installer.

Note: You can disable these notifications by clicking Tools > Self Update, and then clearing the Notifications Enabled check box.


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).



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.


Installing JDBC Drivers (Oracle Only)

Installing JDBC Drivers (Oracle Only)

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.

Figure 27: SA Valet Folders Where JDBC Drivers Should Be Installed

Note: You can skip this procedure if you upgraded from another version of SA Valet. The drivers were copied forward from the previous installation.

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.

SA Valet

Install

dmi

lib

Copy the JDBC driver file to both of these lib folders

lib

Program Files (x86)

Ellucian



Setting Up Hosts in SA Valet

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.

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.


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.



Defining LPR and Host Properties in a Second 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: Perform this procedure only if you have already installed Colleague and want to connect to it from a second installation of SA Valet.

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.


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.




Release System29

Creating the Local Product Repository

In This ChapterThis 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.

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 BeginBefore 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.


Topic Page


Procedure for Creating the Local Product Repository 122


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 don’t 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 previously-entered values to populate the fields in this wizard.

If you click No, the fields will be blank.



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



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.




Figure 33: Local Product Repository Setup (2/3) Window—SQL Server Example

Figure 34: Local Product Repository Setup (2/3) Window—Oracle Example



Figure 35: Local Product Repository Setup (2/3) Window—UniData Example



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

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.

Technical Tip: Your entry in this field must match the UniData environment variables. Make sure UDTBIN and UDTHOME match your entry in this field.



Figure 36: Local Product Repository Setup (3/3) Window—SQL Server Example

Figure 37: Local Product Repository Setup (3/3) Window—UNIX/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.



Figure 38: Windows Displayed During and After Creation of the Local Product Repository

Figure 39: Product Repository Name Displayed in SA Valet After Installation

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.




Release System39


In This ChapterThis 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.

Before You BeginBefore performing this procedure, create the local product repository using the procedure in “Creating the Local Product Repository” on page 121.


Topic Page

Populating the Local Product Repository 132

Populating the Local Product Repository From the DVD 132

Populating the Local Product Repository Over the Internet 136


Release System: Populating the Local Product Repository


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.

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.

Note: When populating the local product repository, the Registry User and the user who starts DMI must be the same.

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.



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).



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.



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 user’s UNIX session. Figure 44 shows an example.


http://clients.datatel.com/solution_updates/downloads/R18DVDimport.cfm

http://clients.datatel.com/solution_updates/downloads/R18DVDimport.cfm


Figure 44: Example Oracle Shell Variables for Running the DVD Load Scripts

Populating the Local Product Repository Over the Internet

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.

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.

$ 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



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.




Installation ProceduresApplication Environment Creation

Application Environment Creation44


In This ChapterPerform 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.

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.


Topic Page


Retrieving Software Updates 142

Full Release vs. Consolidated Full Release 142

Creating the Application Environment 145

Upgrading DMI Listeners 155


Application Environment Creation: Creating the Application Environment

Before You BeginBefore 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 UpdatesBefore 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.

Full Release vs. Consolidated Full Release

You have two options when installing a new application environment: Full Release or Consolidated Full Release. The differences are discussed below.

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.

Technical Tip: You must use SA Valet 2.4.0 or newer.


Full Release vs. Consolidated Full Release

Full Release

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.

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.

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.

Table 38: Available Colleague Consolidated Full Releases

CFR Package Release Date

CFR36020.63-1805*10 February 2008

CFR53268.41-1805*16 May 2011



Figure 45: Example Items Installed with the Consolidated Full Release

Item C Rev 1Item B Rev 1Item A Rev 1Full Release

Item A Rev 2

Item A Rev 3

Item B Rev 2

Software Update 1

Software Update 2

Software Update 3

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.



Creating the Application EnvironmentFollow 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.



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 don’t see that window, skip to Step 6.


Step 5. In the Previous Entries Found window, click Yes if you want your previously-entered 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)



Host Name. Select the host computer where you want the Colleague database to be installed.


Operating System. Type of operating system (UNIX or Windows) on that computer.

Database Type. Oracle, UniData, or SQL Server.


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).


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.




Figure 49: Set Up Colleague Application Environment (1/3) Window—SQL Server Example

Figure 50: Set Up Colleague Application Environment (1/3) Window—Oracle Example



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)



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).



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.



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.


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



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.

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.



UniData Port. Port number assigned to the UniData database.

In almost all cases, you should accept the default port (31438).

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 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.



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).

Figure 55: Windows Displayed During and After Creation of the Application Environment

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.


Upgrading DMI Listeners

Upgrading DMI ListenersWhen 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.





Populating the Application Environment


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 BeginBefore performing this procedure, create the application environment using the procedure in “Creating the Application Environment” on page 141.

Note: Populating the application environment for a full Colleague installation will likely take several hours.

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


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;


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



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).

Figure 58: Messages Displayed During Population of the Environment

Note: At the beginning of the installation, the progress indicator bars may be unchanged for about ten minutes while UniData prepares for the installation.



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.



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.


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;

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.

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.



-- 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_classeswhere 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_objectswhere upper(owner) = upper('&SchemaName')and status != 'VALID'and not(dbms_java.longname(object_name) like 'com/datatelx%'))/spool offset feedback onset 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.



Post-Install Procedures


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.

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.


Topic Page

Running Automated Post-Install Steps 166

Update Computed Column Parameters (SQL Server and Oracle Only) 168

Building the PERSON File Indexes 171

Looking Up PERSON Records Without an ID 178

Dictionary Date Conversion 180

Modify WWW Files (RPI) 182

Defining the Permitted Number of Database Connections 184

Setting up an Environment as Production 187


Application Environment Creation: Post-Install Procedures

Running Automated Post-Install StepsSome 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.

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.

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.


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



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).


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).



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.

See the online help for more details.

Step 6. Click OK to save your changes.

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.


Building the PERSON File Indexes

Building the PERSON File IndexesUse 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).



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.



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 Response

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.



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.

Index Association Data Elements 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

Enter S.MIO.INDX.SOUNDEX

Index Null Keys? Enter Yes if you want to produce an index table entry for a null index key; otherwise enter No.

Primary File Storage Field Name Enter PERSON.SOUNDEX.VALUES.

Alternate Storage File Position Enter 2.

All remaining fields Leave all other fields on this form as they are.

Table 40: Entries on the UTMI Form to Define Soundex Indexing (cont’d)




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


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 Leave this field as it is.

Index Association Data Elements 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 Enter S.MIO.INDX.PARTIAL

Index Null Keys? Enter Yes if you want to produce an index table entry for a null index key; otherwise enter No.

Primary File Storage Field Name Enter PERSON.PARTIAL.VALUES.



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

Alternate Storage File Position Enter 4.


Table 41: Entries on the UTMI Form to Define Partial Name Indexing (cont’d)




Step 14. Enter the information listed in the table below on the UTBI form.

Step 15. Save your changes on the UTBI form to build the indexes.

Table 42: Entries on the UTBI Form


Rebuild Index for File Enter PERSON.

Indexing Function Enter A.




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


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.

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.

Note: If an undefined data condition is specified for COLLEAGUE.PERSON.ID, then an error message may display during PERSON LookUp.



Dictionary Date ConversionPerform 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.


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 X’s) on the User Interface menu bar.



Modify WWW Files (RPI)

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.

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.


Running the EDX Interface Load Utility

Running the EDX Interface Load UtilityRun 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



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:

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 institution’s number of Colleague Application Server (CAS) licenses. Use the procedure below to set the value.

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]

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.


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).



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.


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.



Figure 76: Example Environment Accounts Setup form

Step 3. Click OK when you are done.



Setting Up New Environments

In This ChapterThis chapter contains procedures to be performed in new application environments after populating the application environment. Table 43 lists the topics covered in this chapter.


Topic Page

Building New File Indexes 190

Building Application Security 191

Defining Listener Parameters 192

Creating a Printer Control Record 193

Specifying Permissions for Core Custom Code (UNIX/Linux Only) 198

Installing Software Updates and Custom Release Packages 200


Application Environment Creation: Setting Up New Environments

Building New File IndexesIf you are using the UniData database, use this procedure to build indexes for Colleague files. This step is required to turn on the indexes.

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.

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.


Building Application Security

Building Application SecurityPerform 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.



Defining Listener ParametersThe “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.


Creating a Printer Control Record

Creating a Printer Control RecordPrinting 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.



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



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.



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.



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.



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.


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.



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.

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.

Note: You might have custom development in any application environment, including test and production (live), not just those identified as development application environments.


Installation ProceduresOther Application Environment Procedures

Other Application Environment Procedures82

Installing a New DMI Listener

In This ChapterThis chapter provides the procedure for installing a new DMI Listener in an application environment. Table 44 lists the topics covered in this chapter.


Topic Page

Understanding DMI Listener Installation 204

Planning 205

Procedure for Installing a New DMI Listener 207

Defining Listener Parameters 212


Other Application Environment Procedures: Installing a New DMI Listener

Understanding DMI Listener InstallationWhen you create an application environment, two DMI Listeners are installed with the application environment:



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.


Planning

PlanningThe 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.



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 Example Port ID

Non-secure AB

Secure AC

Table 46: Worksheet: Installation Path for New Listener

Example Patha Enter Your Installation Path ID

U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02

AD

a. U = UNIX example; W = Windows example.

Table 47: Worksheet: JRE Path

Example Path to JREa Enter Your Path to JRE ID

U)/opt/java6 W)D:\jdk1.6.0_12\jre

AE



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



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.


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).



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.



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.



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.



Defining Listener ParametersThe 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.



Implementing Multiple DMI Data Access Servers

In This ChapterThis 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 BeginTable 49 lists the tasks that must be complete before you can continue with the procedures in this chapter.


Topic Page


Implementing Multiple DAS Listeners 214

Table 49: Before You Begin

Task Reference

Install a DMI Listener with the database application server (DBAS) role.

“Installing a New DMI Listener” beginning on page 203.


Other Application Environment Procedures: Implementing Multiple DMI Data Access Servers

Implementing Multiple DAS ListenersDefault 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.

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

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.


Implementing Multiple DAS Listeners

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.



Figure 93: Distribute DAS Menu Option

The Distribute DAS form is displayed, as shown in Figure 94.

Figure 94: DAS Interface Parameters Form


Implementing Multiple DAS Listeners

Step 4. Select the DAS Listener you want to handle transactions for each interface.

Step 5. Click OK to save your changes.





Cloning an Application Environment

In This ChapterThis 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.


Topic Page

Terminology 220

Understanding Cloning 220

Preparing for Cloning 225

Preparing for Cloning with the Colleague Portal (Portal Cloning) 228

Copying the Active Directory Users 230

Copying the SharePoint Portal (Portal Cloning) 234

Updating User Permissions to the Test Active Directory Domain (Portal Cloning) 237

Adding LDAP Groups to the Portal (Portal Cloning) 239

Copying the Colleague Executables 241

Setting Up the Application Environment in User Interface 244

Copying the Colleague Data 245

Copying the DMI Listeners 261

Correcting Environment-Specific Values 274

Updating Portal Pointers and Settings (Portal Cloning) 289

Updating the Domain Pointer for Users 291

Updating the Primary Constituency of All Users (Portal Cloning) 293

Updating SharePoint Colleague Connectors and Other Settings (Portal Cloning) 294

Setting Up User Access Features 296

Installing and Setting Up Interfacing Software 296

Worksheets 297


Other Application Environment Procedures: Cloning an Application Environment

TerminologyIn 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 CloningEach 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.


Understanding Cloning

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 Summary Page

1. Prepare for cloning. 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.

225

2. Prepare for portal cloning.

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.

228

3. Copy the Active Directory users.

Copy the Colleague Active Directory production users into your test Active Directory Domain Controller.

230

4. Copy the SharePoint portal.

Copy your production SharePoint site collection by backing up the production site collection and restoring it into the test environment.

234

5. Update user permissions to the test Active Directory domain.

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.

237

6. Copy the Colleague executables.

Use operating system commands to copy the directory containing the Colleague executables.

For a UniData installation, this step also copies the Colleague data.

241

7. Set up the environment in UI.

Set up the new application environment to make it available in User Interface.

244

8. Copy the Colleague data.

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.

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



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

10.Correct environment-specific values.

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

274

11.Update portal pointers and settings.

Update portal pointers and settings in the new test environment. 289

12.Update the domain pointer.

Update the domain pointer for all users in the test environment registry. 291

13.Update the primary constituency of all users.

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.

293

14.Update SharePoint Colleague connectors and other settings.

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.

294

15.Set up user access features.

If desired, set up single role access or Windows authentication in the target environment.

296

16.Install interfacing software.

If desired, install and set up WebAdvisor or third-party software and add-on components (such as Safari, Campus Cruiser, Resource25, and Telephone Registration).

296

Table 51: Steps in Cloning an Application Environment (cont’d)

Step Summary Page

Note: Figures 95 and 96 do not show Colleague Portal components


Understanding Cloning

Figure 95: SQL Server or Oracle Overview of Application Environment Cloning


Ellucian

coll18

source

apphome

svr01 svr02

target

svrnn

Database computer

datatel

coll18

source target

dasdas

RDBMS (Oracle or SQL Server)

Colleague database (source)

Colleague database (target)

Environment-specific values




Other DMI Listeners apphome

svr01 svr02 svrnn


Other DMI Listeners


1

2

3

3

4

Cloning steps:Copy Colleague executablesCopy Colleague databaseCopy DMI ListenersCorrect environment- specific values

SQL Server or Oracle


Oth

er Ap

plicatio

n E

nviro

nm

ent P

roced

ures: C

lon

ing

an A

pp

lication

En

viron

men

t

224Installation P


Figure 96: UniData Overview of Application Environment Cloning

arget

3

svr01 svr02 svrnn


Other DMI Listeners

ent-specific


Ellucian

coll18

source

apphome

svr01 svr02

t

svrnndas




Other DMI Listeners

12

Cloning steps:Copy Colleague executables and dataCopy DMI ListenersCorrect environment-specific values

apphome

das


UniData

Environmvalues

Preparing for Cloning

Preparing for CloningPlanning ahead for the cloning process will simplify both installation and troubleshooting. Table 52 lists the planning topics covered in this section.

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 52: Planning Topics in This Section

Topic Page

Checking the Configuration 225

Application Environment Name 226

Directory Structure for Target Application Environment 226

DMI Listener Ports 226

Path to JRE or SDK 227

Table 53: Configuration Items to Recheck Before Cloning an Environment

Step Page

Recheck hardware requirements. 56

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.

76



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:



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.


Preparing for Cloning

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.



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.

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.

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.


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.



Copying the Active Directory Users

Begin by copying Colleague Active Directory production users into your test Active Directory Domain Controller.

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.

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.

Note: This section is applicable for all institutions that use Active Directory authentication for their production users.

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.

This prALERT! 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.


http://www.computerperformance.co.uk/Logon/Logon_CSVDE.htm

http://www.computerperformance.co.uk/Logon/Logon_CSVDE_Export.htm


Step 2. Open a command window and type the following command, making sure to replace the values with your ou and domain.

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).

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.



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



successfully.

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.

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.

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.


http://www.computerperformance.co.uk/ezine/ezine23.htm

http://www.computerperformance.co.uk/Logon/Logon_CSVDE_Errors.htm

http://www.computerperformance.co.uk/Logon/Logon_CSVDE_Errors.htm


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

Examplestsadm -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.

stsadm -o backup

-url <URL name>

-filename <backup path and file name>

Note: This operation may take several minutes to a few hours to complete depending on the size of your site collection.


http://technet.microsoft.com/en-us/library/cc706871.aspx

Copying the SharePoint Portal (Portal Cloning)

Examplestsadm -o backup

-url http://portal.datateluniversity.edu

-filename D:\CloneBackups\DatatelSiteCollection083109.bak

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

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.

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>

ALERT! Type this command into the window manually. stsadm will not work if there are any stray ASCII characters in the command.

Note: At this point, you can allow your production users to start using the production portal again.

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.



Examplestsadm -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.


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:



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.


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.



Adding the LDAP Groups as Members of the Top-Level 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.


Copying the Colleague Executables


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.

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: 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.

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.

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.



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.

Figure 98: Example of Copying the Colleague Executables

Note: For a UniData installation, this step also copies the Colleague data.

datatel

coll18

production

apphome

training

apphome

Create top-level application environment directory.Copy Colleague executables directory.

1

2



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.



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.


Copying the Colleague Data


Use the appropriate procedure listed in Table 54 for your RDBMS and configuration to copy Colleague data from the source to the target environment.

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.

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.

Table 54: Location of Procedures for Copying Colleague Data

RDBMS Page

SQL Server 245

Oracle 248

UniData 260



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

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.

Enter the name of the new database.



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).



Copying Colleague Data for Oracle

Table 55 lists the topics in this section.

Prerequisite Checks

Step 1. Determine the size of the Oracle tablespaces that contain the source schema.

Typically (per Ellucian’s 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.


Topic Page

Prerequisite Checks 248

Creating the Instance, Tablespaces, and Users 249

Copying Table Definitions 252

Exporting the Data from the Source Schema 254

Importing the Data to the Target Schema 255

Verification 256

Moving Indexes to the Index Tablespace 257

Changing the Oracle Java Resolver 259

Cleanup 259



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.


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.



Figure 100 shows an example statement for creating the tablespace.

Figure 100: Example Statement for Creating the Tablespace for the Target Environment

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

institution’s configuration.1

Locally managed.


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" 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

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.

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



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 Ellucian’s recommendation:

revoke unlimited tablespace from coll18_training;

Revoke succeeded.

alter user coll18_training quota 0m on coll18_test;

User altered.



alter user coll18_training quota 4000m on coll18_training;

User altered.

Copying Table Definitions

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);'

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

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.



from dba_tables

where owner = 'SOURCE_USER';

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 Ellucian’s 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 Ellucian’s 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: The never-true criterion WHERE 1=2 ensures that data is not copied; only tables are copied.

Note: Replace “dprod” with the name of the DBLINK created in Step 1.



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)



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

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

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 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'


union



select owner, object_type, count(1) from dba_objects@test

where owner = 'COLL18_TEST'


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

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;'

Note: Depending on the size of the indexes, this procedure (specifically, Step 6 on page 258) could take several hours.



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;

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.

Note: Depending on the size of the indexes, the next step could take several hours.



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.



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.


Copying the DMI Listeners

Copying the DMI ListenersTable 56 lists the topics covered in this section.

Running the Clone Application Environment 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.

Step 1. In SA Valet, connect to the source application environment if not already connected.


Topic Page

Running the Clone Application Environment Wizard 261

Starting the New Listeners 272

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.

Technical Tip: JVM arguments are not copied from the source environment.



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 don’t see that window, skip to Step 4.




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.




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).


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).


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.




Figure 106: Target Environment Information (3/7) Window—SQL Server Example

Figure 107: Target Environment Information (3/7) Window—Oracle Example

Figure 108: Target Environment Information (3/7) Window—UniData Example



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).



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.




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.


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.



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.



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).



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



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.

Clone this Listener. Select this check box if you want to copy this Listener, or clear the check box if you don’t 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.

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.



If you want to change any of the entered information, use the Back button to return to the appropriate window.


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.

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.



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.

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.

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).

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.

Note: You must run the BCSO process in order to use the Colleague Studio Show References feature in the new application environment.



Figure 114: Starting All Listeners from SA Valet



Correcting Environment-Specific Values

A newly-cloned application environment includes several types of information whose values may not be appropriate, such as environment-specific parameters and external VOC references. This section contains procedures for correcting those values. Table 57 summarizes each type.

Table 57: Environment-Specific Values

Type Location Description Basic Approach Page

Environment- specific parameters

Colleague database

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.

(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 Ellucian-delivered cleanup specifications and your custom cleanup specifications.

Set the Remove Portal Information field to No (the default) when running the BECU process.

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



Securing the BECU Form

Environment-Specific Parameters

Table 58 lists the topics covered in this section.

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, e-commerce 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.

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.

Table 58: Topics in this Section

Category Topic Page

Concepts Understanding Environment-Specific Parameters 275

Cleanup Specifications 276

Noteworthy Fields on the MECD Form 277

Environment Cleanup Report 280

Procedures Generating a Report of Changes For Existing Specifications 282

Defining Custom Specifications 283

Updating the Parameters 285



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 Ellucian-delivered 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.

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.

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.



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.

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.

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.



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:

IFEXT–Replace 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.

NOUPD–Report 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 don’t 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.



Figure 115: Example of the MECU and MECD Forms

Detail



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 won’t appear on the report. Example: You don’t 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 won’t 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.


Co

rrecting

En

viron

men

t-Sp

ecific Valu

es


ebruary 21, 2013281

Page 1

Mnemonic & Field Label-------------------------------PGS Full Path to Safari Diction

RPGS Full Path to Safari Server

UT-RPGS Safari Rules File

UT-VSNP Snap Table Drive Name

UT-VSNP Snap Table Drive Name

UT-VSNP Snap Table Path



Figure 116: Example of the Environment Cleanup Report

May 05 2005 ENVIRONMENT CLEAN-UP REPORT Report Mode

Appl Data Element Name Physical File Name Spec Src Record Key ---- ---------------------------- -------------------- -------- ------------------------------ UT RPTSET.UDMS.DCT.PATH UT.PARMS Cust-Ovr REPORTING.SETTINGS UT-R Original Value: datatel}safari}dict Will Not Be Updated: datatel}safari}dict

UT RPTSET.UDMS.DIRPATH UT.PARMS Datatel REPORTING.SETTINGS UT- Original Value: datatel}safari Will Be Replaced With: <null>

UT RPTSET.UDMS.RULES.PATH UT.PARMS Cust-Ovr REPORTING.SETTINGS Original Value: safari.nrr Will Not Be Updated: safari.nrr

UT VSPEC.DIR.DRIVE VIEW.SPECS Datatel TED_TEST2 Original Value: D Will Be Replaced With: <null>

UT VSPEC.DIR.DRIVE VIEW.SPECS Datatel TED_TEST3 Original Value: C Will Be Replaced With: <null>

UT VSPEC.DIR.PATH VIEW.SPECS Datatel TED_TEST1 Original Value: test}path Will Be Replaced With: <null>

UT VSPEC.DIR.PATH VIEW.SPECS Datatel TED_TEST2 Original Value: testpath Will Be Replaced With: <null>

UT VSPEC.DIR.PATH VIEW.SPECS Datatel TED_TEST3 Original Value: piece1}piece2}piece3}piece4 Will Be Replaced With: <null>


Procedures for Changing Environment-Specific Parameters

Table 59 lists the procedures in this section.

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.

Table 59: Procedures in this Section

Procedure Page

Generating a Report of Changes For Existing Specifications below

Defining Custom Specifications 283

Updating the Parameters 285



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 Ellucian-delivered 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.



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.



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



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.


Co

rrecting

En

viron

men

t-Sp

ecific Valu

es


ebruary 21, 2013287

Page 1

----------

Figure 119: Example of the VOC External References Report

May 05 2005 VOC EXTERNAL REFERENCES Environment Path: D:\dev\etk48dev

VOC Item Name VOC Entry Contents-------------------------------- -----------------------------------------------------------ALEX DIR -->D:\DEV\ETK482DEV\ALEX D__PH_

ALEXC2 C -->D:\DEV\ETK482DEV\ALEX\_ALEXC2

ALTEST.FILE F -->D:\ETK48DEV\ALTEST.FILE -->D:\ETK48DEV\D_ALTEST.FILE

ALXF1 F -->D:\ETK48DEV\ALXF1 -->D:\ETK48DEV\D_ALXF1



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.

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.

Note: Generating the report may take several minutes.


Updating Portal Pointers and Settings (Portal Cloning)

Updating Portal Pointers and Settings (Portal Cloning)

If you’re 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.



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.


Updating the Domain Pointer for Users

Updating the Domain Pointer for 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.

Note: This section is applicable for all institutions that use Active Directory authentication for their production users.



Figure 122: Assign Dir Server to Resource (ADTR) Form


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



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.


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.



Setting Up User Access FeaturesYou 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.


Worksheets

WorksheetsUse 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

Enter a Name for YourTarget Application Environment

ID

training AF

Table 61: Worksheet: DMI Listener Ports for Target Application Environment (Discussion on page 226)

Unsecure Port Secure PortDMI Listener Example Enter Your Port ID Example Enter Your Port ID


AG AH

DMI application server AI AJ

Other DMI Listeners AK AL


Oth

er Ap

plicatio

n E

nviro

nm

ent P

roced

ures: C

lon

ing

an A

pp

lication

En

viron

men

t

298Installation P


26)

Your Installation Path ID

AM

AN

AO

AP

AQ

AR

AS

AT

Table 62: Worksheet: Directory Structure for Target Application Environment (Discussion on page 2

Configuration Installed Software Example Patha Enter

SQL Server or Oracle Use this section if you are using SQL Server or Oracle


U)/datatel/coll18/training/das W)D:\datatel\coll18\training\das

Colleague executables U)/datatel/coll18/training/apphome W)D:\datatel\coll18\training\apphome

DMI application server U)/datatel/coll18/training/svr01 W)D:\datatel\coll18\training\svr01

Other DMI Listeners U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02


UniData Use this section if you are using UniData


U)/datatel/coll18/training/das W)D:\datatel\coll18\training\das


U)/datatel/coll18/training/apphome W)D:\datatel\coll18\training\apphome

DMI application server U)/datatel/coll18/training/svr01 W)D:\datatel\coll18\training\svr01

Other DMI Listeners U)/datatel/coll18/training/svr02 W)D:\datatel\coll18\training\svr02



Worksheets

Table 63: Worksheet: JRE Paths (Discussion on page 227)

Computer Example Path to JREa Enter Your Path to JRE ID

Database computer


AU

App server computer


AV

Other computerb


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)

ExampleUsername

Enter Your Username ID

administrator AX

Table 65: Worksheet: SQL Server Database Name (Discussion on page 246)

ExampleDatabase Name

Enter Your Username ID

coll18_training AY

Table 66: Worksheet: Oracle Instance and Username (Oracle Only) (Discussion on page 249)

ExampleInstance Namea

Enter Your Instance Name

IDExample

UsernameEnter YourUsernameb ID

dtrain11 AZ coll18_training 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.




Installation ProceduresAppendices

Appendices

DMI Listener Names

Listener Naming ConventionWhen you create a DMI Listener from one of the wizards in SA Valet, it is assigned a name as shown in Table 67.

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.

Table 67: DMI Listener Names

Wizard DMI Listener Listener Name Syntax Example

Create Local Product Repository


lpr name_DB_LISTENER coll18_DB_LISTENER

Create Application Environment or Clone Application Environment


environment name_DB_LISTENER test_DB_LISTENER


environment name_APP_LISTENER test_APP_LISTENER

New DMI Listener or Clone Application Environment

Other application environment Listeners

environment name_listener namea test_PrintServera

a. You specify the listener name in the New DMI Listener wizard or the Clone Application Environment wizard.


Appendices: DMI Listener Names

Figure 125: Example of DMI Listener Name in Windows Services Folder


AppendicesA

Glossary

In This AppendixThis 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.


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 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.


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 (plug-ins). 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)



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 server’s 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.


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.



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.


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.



virtual machine (VM)

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


ColleagueR18InstallationProcedures-02212013

Documents

ibm ud73 bin unidata port

datatel coll18 training svr03

datatel coll18 training svr01

datatel coll18 training svr02

datatel coll18 training apphome

datatel coll18 training das

datatel coll18 test svr01

datatel coll18 production svr01