Installation Guide

Introduction

This guide describes the installation process of migration-center. The following main steps of the installation process are subsequently described:

  • Preparing the Oracle database for migration-center

  • Installing the Client components of migration-center

  • Installing the database of migration-center

  • Installing the Server Components of migration-center

Install

The following section gives an overview of the system requirements, and paragraph 2.2 describes the preparation of an Oracle Standard Edition database for migration-center.

System requirements

For best results and performance, it is recommended that every component will be installed on a different system. Hence, the system requirements for each module are listed separately.

The required capacities depend on the number of documents to be processed. The values given below are minimal requirements for a system processing about 1.000.000 documents. Please see the Sizing Guide for more details.

Database Server

Component

Requirements

RAM

4 - 8 GB for Oracle

Hard disk storage

Depends on the number of documents to migrate, roughly 2 GB for every 100.000 documents.

CPU

2 - 4 cores

Oracle

Supported versions: 11g Release 2, 12c Release 1, 12c Release 2, 18c, 19c

Character set: AL32UTF8

Required components: Oracle XML DB

Operating system

All OS supported by Oracle

For a typical Oracle database creation please refer the section Preparation of the Oracle database. For more advanced topics regarding Oracle database configuration and administration please refer to Database administrator’s guide.

Server Components (Job Server)

Component

Requirements

RAM

By default, the Job Server is configured to use 1 GB of memory. This will be enough in most of the cases. In some special cases (multiple big scanner/importer batches) it can be configured to use more RAM.

Hard disk storage (log files)

300 MB + storage space for log files (~ 50 MB for every 100,000 processed files)

Hard disk storage (content files)

Variable. Refers to temporary storage space required for the content of scanned objects. Should be a network share if you plan to install multiple Job Servers.

CPU

2 - 4 cores

Operating system

Windows Server 2008, 2012, or 2016 Windows 7, 8, or 10

Linux

Java

Oracle JRE 1.8

OpenJDK 8, 11, 13

32 or 64 bit

Note that not all adapters are available on the Linux version of the Job Server.

Client

Component

Requirements

RAM

1 GB for MC client

Hard disk space

10 MB

CPU

1 core

Operating system

Windows Server 2008, 2012, or 2016

Windows 7, 8, or 10

Oracle client

Oracle Client / Instant Client 11g Release 2, 12c, 18c, 19c Important: 32 bit version

For the communication between the individual components, it must be possible to have access to the database from the Job Server and the Client. In addition, the Client must be able to access the distributed Job Server. The figure below outlines the communication of the individual components.

Preparation of the Oracle database

Migration-center uses an Oracle database to store information about documents, migration sets, users, jobs, settings and others.

The steps in the creation of a new database for migration-center are described next. Even though the description is very detailed, the installing administrator is expected to have a good degree of experience in configuring databases.

It is also possible to use Oracle Express Edition, but this version is not recommended for performance reasons and scalability due to its built-in limitations.

Starting the database configuration assistant

Oracle 11g offers the Database Configuration Assistant for database creation. In Microsoft Windows, the assistant is in the Oracle program group in the Start menu. For all other operating systems, please refer to the corresponding Oracle documentation to start the assistant.

The assistant will provide the user with a step-by-step guide through all the stages necessary for creating and configuring a database. With the [Back] and [Next] buttons, the user can navigate between the individual steps of the database configuration process, to change options.

The screenshots in this chapter were created on a Microsoft Windows System with Oracle 11.2.0.1.0. For other operating systems, the menus and dialogs may be different

After the start, the assistant will display a welcome note which can be skipped with [Next].

Step 1: Select operation

The first step determines the operation to be performed with the Configuration Assistant. “Create a database” is the appropriate choice here.

Step 2: Database template

The next menu shows all available database templates. „General Purpose“ is appropriate for creating a database instance for migration-center.

Step 3: Database identification

Define the database name here. The name must be unique, meaning that there should not be another database with this name on the network. The SID is the name of a database instance and can differ – if desired - from the global database name. In order to make an easy identification of the database possible, a descriptive name should be selected, for instance „migration“.

Step 4: Management options

To manage the database, Oracle Enterprise Manager is recommended. In Oracle 11g, databases can be managed centrally using the Grid Control or locally using the Database Control. Since the choice of database management has no influence on the operability of migration-center, this can be configured according to personal preferences or company policies. For the purposes of this guide the local Database Control will not be selected here. E-mail notification and backup can be configured separately at a later time, if necessary.

Step 5: Passwords for system accounts

Once the database has been created, the passwords for the Oracle system accounts “SYS”, “SYSTEM”, “DBSNMP” and “SYSMAN” must be entered and confirmed. These accounts with their passwords are needed for the installation of the migration-center database schema.

Using the [Exit] button, the user can exit the database configuration and close the assistant.

These accounts/passwords grant full rights for the new Oracle database and should therefore be chosen and safeguarded carefully. The allocation of different passwords is recommended.

Step 6: Storage options

This step defines the storage method for the database. For use with migration-center the “File System” option is sufficient. For more information on the “ASM” method, please refer to the Oracle documentation.

Step 7: Storage location

In this step the paths in which the initialization parameters and the trace files are to be stored are determined. The preset values from the template can be retained.

Step 8: Recovery configuration

In this screen the initialization parameters for the database’s archive and recovery mode are specified. The default settings can be applied.

Step 9: Database content

In this step pre-defined example schemata can be added to the database. For migration-center no example schemata are required.

Step 10: Initialization parameters

In this step of the assistant there are several tabs on which the initialization parameters for the new database must be specified.

The memory values of the database need to be specified here. For migration-center, user-defined settings are required.

Please review the requirements in chapter System Requirements with regard to the recommended amount of memory allocated to the database instance

When processing mass data, it may be necessary to change the parameters after some time. This can be done retrospectively in the Oracle Enterprise Manager. To do so, select <Administration / Memory Parameters> in the menu. In the dialog box displayed the settings for the "SGA” and “PGA” values can be changed and saved.

At this point the block sizes and maximum number of user processes are defined. The default block size can be applied. The maximum number of processes should be set to 150.

The Unicode character set “AL32UTF8” should be selected here. This character set supports all languages specified in Unicode 3.1.

The figure below illustrates the selection.

Here the mode in which client applications access the database is specified. For migration-center, the “Dedicated Server Mode” connection type is appropriate and should be selected.

Step 11: Database storage

No modifications for the database storage are necessary for migration-center.

Step 12: Options

Optionally, at this point a script can be generated which contains all the settings for the creation of this database. With this script, the setup can be repeated later if necessary. Furthermore, this script can be used as documentation for the settings used.

At this point, the user has the last possibility to perform changes on previous pages by using the [Back] button. After confirming this step by selecting [Finish], the database will be created.

After the user selects [Finish], the assistant opens a window showing a summary of the previous settings. This summary can be stored for documentation purposes in an HTML file. By pressing the [OK] button, the database will be created and installed. This process can take some time.

The Oracle database Configuration Assistant generates the following tablespaces (we assume that unused tablespace is marked to be deleted. Refer to Step 4: Database- features):

  • INDX

  • SYSTEM

  • TEMP

  • TOOLS

  • UNDOTBS

  • USERS

Summary of the most important Oracle 11g installation parameters

Oracle components:

  • Oracle Database

  • Oracle XML DB

  • Oracle Net Listener

  • Oracle Call Interface

General options:

  • Oracle JVM

  • Enterprise Manager Repository (optional)

Initialization parameters:

  • Dependent on server

Character sets:

  • Database character set (AL32UTF8)

Data files:

  • Use standard parameters

Control files:

  • Use standard parameters

Redo log groups:

  • Use standard parameters

Installing migration-center

An installation assistant will help the user install migration-center. This assistant directs the user through all the steps necessary for the installation of migration-center by installing and configuring the components in the following order:

  • migration-center Client

  • migration-center database

  • migration-center Server Components

The three individual components of migration-center can also be distributed and installed with separate assistants. The following table shows the setup assistants on the installation medium:

Main installation assistant

setup.exe

migration-center Client

MigClient/MigClientSetup.exe

migration-center database

Database/InstallDataBase.exe

migration-center Server Components (Job Server)

ServerComponents/SPsetup.exe

This installation guide describes the installation by means of the main installation assistant, which initiates the setup routines of each individual component.

The installation is started with setupMigCenter.exe, which is to be found in the root directory of the installation medium/package.

The installation can be aborted before the component selection step by pressing the [cancel] button.

By pressing [Back], the user can navigate to the previous pages in order to change or edit options.

The migration-center installation package should not be placed in a folder/path containing special characters like “( ) ;” as this can interfere with the installation process.

Selecting components

At the following step, the user will choose the components of migration-center to install.

The following are different installation variants:

  • Full installation All components of migration-center are installed

  • Compact Installation This variant installs the migration-center Client and database only.

  • Custom installation The user-defined installation allows the user to select specific components.

The full installation is recommended as a first installation option, or a custom installation can be performed by selecting only components that need to be installed.

Although the components can be installed individually, for full functionality at least one instance of each component must be deployed and the components must be able to connect to one another.

By confirming the choice by selecting [Next], all chosen components will be installed one after another. For each of the components there will be an individual installation assistant.

migration-center Client

Installation of the migration-center Client starts with the welcome screen. The user will get to the next page by clicking [Next], while [Back] brings him back to the previous page, in case the entries there have to be corrected.

The installation can be cancelled by pressing [Cancel]. Only the installation of the current migration-center component will be interrupted. The setup assistant will continue installing the next component.

Select destination location

To install the Client, select the installation path for the application. The default installation path proposed by the installer is recommended but can be changed if needed.

Select start menu folder options

During the installation shortcuts in the Windows Start Menu will be created for migration-center. The name of the folder for these shortcuts can be set here.

Select shortcut placing options

During the installation shortcuts to the Desktop or to the Quick Launch Bar can be created.

Installation summary

Before starting the installation process, all previously set options are displayed. In order to change settings, the user can navigate to the previous pages by clicking [Back]. By clicking [Install], the installation is started.

Officially, Oracle Client 11gR2 32 bit is not supported on Windows 2012. By ignoring the warning during installation, it can be successfully installed and used properly on Windows 2012.

Database installation

This installation prepares the database for use with migration-center by creating a user, tables, installing the packages containing migration-center functionality and setting default configuration options. All of these objects will be grouped in a schema called FMEMC. Currently it is not possible to change the schema’s name or install multiple schemata on the same database instance.

The migration-center database installation program requires Oracle 11g/12c/18c/19c Client or Instant Client to connect to the Oracle server remotely or can be run locally on the Oracle server if the Oracle server machine is Windows-based.

Database connection

Next, the name of the Oracle database instance for migration-center, as well as the user account for accessing it must be entered. The specified database user must the predefined SYS user or an Oracle administrative user with enough privileges.

By selecting [Test Connection], the credential and connection to the selected database instance can be verified prior to starting the installation. A message box will confirm whether the connection could be established or return the error message from the server if not.

If selecting [Next], the connection test is performed and if the test is successful, the next window appears.

Enter your migration-center license key by copying and pasting it from the email message received from fme product support containing your licensing information.

Selecting the tablespaces path

At this point, the path for the tablespaces of the database is set. The default path provided by the selected database instance is recommended.

Also, the location for the database installation log file MigrationCenter.log can be set is set.

The migration-center database schema will be installed by clicking [Install].

The progress bar in the lower area of the screen informs the user about the progress of the database installation steps.

The log file records several database actions run by the setup routine. Therefore, this log data file is very useful for support in case problems occur during the installation, such as error messages due to insufficient privileges. The location for the log file should therefore be chosen carefully.

Selecting Listener port and date/time pattern

Listener port – is the port where the Oracle Listener is listening for incoming database connections. This is necessary for the scanner and importer to connect to the database instance. Configure accordingly to local Oracle configuration. By default, this is port 1521, but another port number can be entered here if the Oracle Listener is configured differently.

Date-time pattern – is the pattern used to display time and date values across the various migration-center components, such as the Client and adapters. Also, the scanner and importer will use this pattern for exporting/importing date-time attributes. Since migration-center is a distributed application and the various components can be installed on different machines with different regional settings, the definition of a common date/time format makes sense.

The dropdown menu includes of 4 the mostly widely used date/time formats.

If the migration-center database schema was successfully installed, the [Finish] button appears, clicking the [Finish] button closes the installer.

Database objects created during migration-center database schema installation:

During the installation, the following Oracle Users will be created for migration-center.

User

Authorizations

FMEMC

This Oracle User is the owner of all migration-center objects and tablespaces

Default password is migration123. Password can be changed after authorization.

GRANT CONNECT TO FMEMC

GRANT RESOURCE TO FMEMC

GRANT CREATE JOB TO FMEMC

GRANT SELECT ON SYS.V_$INSTANCE TO FMEMC

GRANT SELECT ON SYS.DBA_DATA_FILES TO FMEMC

GRANT SELECT ON SYS.DBA_TABLESPACES TO FMEMC

GRANT CREATE VIEW TO FMEMC

Additionally the user FMEMC will be granted to use the following Oracle packages:

  • SYS.UTL_TCP TO FMEMC;

  • SYS.UTL_SMTP TO FMEMC;

  • SYS.DBMS_LOCK TO FMEMC;

  • SYS.UTL_RAW TO FMEMC;

  • SYS.UTL_ENCODE TO FMEMC;

  • SYS.DBMS_SCHEDULER TO FMEMC;

  • SYS.DBMS_OBFUSCATION_TOOLKIT TO FMEMC;

Furthermore, during the installation, the following tablespaces will be created for migration-center:

  • FMEMC_DATA (40MB)

  • FMEMC_INDEX (20MB)

These tablespaces are set to expand in steps of 10MBs according to the usage and needs of migration-center.

The user role FMEMC_USER_ROLE will be created and granted the required privileges on FMEMC schema objects. This role must be granted to any database user that needs to use migration center.

Database advanced installation

If default settings for the user FMEMC and tablespaces do not meet the requirements of the customer or conflict with internal company policies and guidelines, the migration-center database installation can be customized. This way, one may create the user FMEMC and the required necessary tablespaces manually before running the provided database installer by using the scripts located in <MIGRATION-CENTER package>\Database\Util.

The tablespaces can be separated or merged into any number of individual datafiles, but the tablespace’s names cannot be changed (FMEMC_DATA and FMEMC_INDEX must not be changed).

These tablespaces must be created prior to the creation of the FMEMC user.

After creating the tablespaces and the FMEMC user, the migration-center database installer can be run connected as user FMEMC instead of SYS.

Updating from an older migration-center database version

Before starting the update process it is always advised to back up the existing data.

The migration-center database installer supports updating migration center databases starting with version 3.0. The process will be performed automatically by the installer and does not require any user intervention.

An update can take in excess of 1 hour to perform, depending on the amount of data and database system performance. This is normal and does not mean the installer has stopped responding. Please do not try to close the installer application or otherwise intervene in the process.

Prerequisites for upgrading from version 3.0.x to 3.13

Before starting the update process it is always advised to back up the existing data.

The following conditions need to be fulfilled for the update procedure to work (these are checked by the installer):

  • The old database’s version must be one of the following: 3.0.x, 3.0.1.985, 3.1.0.1517, 3.1.0.1549, 3.1.1.1732, 3.1.2.1894, 3.2.0.2378, 3.2.1.2512, 3.2.2.2584, 3.2.2.2688, 3.2.3.2808, 3.2.4.3124, 3.2.4.3187, 3.2.4.3214, 3.2.4.3355, 3.2.5.3609, 3.2.5.3768, 3.2.6.3899, 3.2.6.4131, 3.2.7.4348, 3.2.7.7701, 3.2.7.7831, 3.2.7.7919, 3.2.8.7977, 3.2.8.8184, 3.2.8.8235, 3.2.8.8315, 3.2.9.8452, 3.3.8573, 3.4.8700, 3.5.8952, 3.5.8952, 3.6.8970, 3.7.1219, 3.8.0125, 3.9.0513, 3.9.0606, 3.9.0614, 3.9.0606, 3.9.0704, 3.10.0823, 3.10.0905, 3.11.1002. You can check your current database version in the Client’s “About” window. If your version is not one of the above please contact our technical support at support@migration-center.com.

  • Any running jobs (scanners, importers, schedulers, transformations, validations) must be finished or stopped.

Considerations regarding updating database version older than 3.1.0.x

  • Due to the new update feature released with migration-center 3.1.0, a new instance of an existing scanner may detect updates for objects scanned with previous versions even though the objects haven’t changed from the previous scan. This behavior always applies to virtual documents or documents that have dm_relations and occurs due to the information used by the new features in migration-center 3.1 not being available in the previous release. For this reason, a new scan will recreate this information on its first run.

  • Transformation rules created with a version older than 3.1.0 which use the system attribute r_folder_path might need to be reconfigured. This is because migration-center 3.1 now stores absolute folder paths instead of paths relative to “scanFolderPaths” as was the case with the previous versions.

  • Database update from previous versions older than 3.1.2: as a result of the update process increasing the default size for attribute fields to 4000 bytes (up from the previous 2000 bytes), Oracle’s internal data alignment structures may fragment. This can result in a performance drop of up to 20% when working with updated data (apparent when transforming / validating / resetting). A clean installation is not affected, neither is new data which is added to an updated database, because in these cases the new data will be properly aligned to the new 4000 byte sized fields as it is added to the database.

  • If the database contains Virtual Documents and objects that are part of scanned Dctm Relations (this does not apply to FileSystem adapter) some additional checks are done by installer. In case any of these checks fail an error is raised by the installer. In this case stop the installation and contact our technical support at support@migration-center.com.

Considerations regarding updating database version 3.1.2

Due to changes and new functionalities implemented in migration-center version 3.2 that rely on additional information not present in older releases, the following points should be considered when updating a database to version 3.2 or later:

  • The concatenate function will only have 5 parameters for newly added transformation rules. Reason: the “Concatenate” transformation function has been extended to 5 parameters for version 3.2. Transformation rules using the “Concatenate” function and created with a previous version of migration-center will retain their original 3 parameters only.

  • The system rule “mc_content_location”, which allows the user to define or override the location where the objects’ content files are stored will be available for use only in migration sets created after the database has been updated to version 3.2 Reason: the “mc_content_location” system rule is new to migration-center version 3.2 and did not exist in previous versions

  • The Filesystem scanner won’t create the “dctm_obj_link” attribute anymore Reason: with version 3.2 of migration-center scanners and importers are no longer paired together. The “dctm_obj_link” attribute was created automatically by the Filesystem scanner in previous iterations because it was a Filesystem-Documentum adapter. Since this no longer applies to the current Filesystem scanner which is just a generic scanner for filesystem objects and has no connection to any specific target system, it won’t create any attributes specific to particular target systems either. If objects scanned with a Filesystem scanner are intended to be migrated to a Documentum system, the “dctm_obj_link” rule must be created and populated with transformation rules in the same way as any other user-defined rule.

  • The Filesystem scanner won’t detect changes in a file’s metadata during subsequent scans for files which have been scanned prior to updating to version 3.2 Reason: detecting changes in a file’s external metadata (in addition to the file’s content) is a new feature of the Filesystem scanner in migration-center 3.2; previous versions of migration-center did not store the information which would be required by the current Filesystem scanner to detect such changes. A change to a file’s modification date would trigger the update mechanism though and would also enable full 3.2 functionality on subsequent scans.

Updating a previous database version to current version

A previous version of the migration-center database can be updated to the current version. The installer will detect supported database versions eligible for update and offer to update the database structure, migration data and stored procedures to the current version.

Running the database installer in update mode

The first step is connecting to the database instance as user SYS. If an old database version is detected on that database instance, the following screen appears:

Before clicking [Next] make sure you backed up your old database first!

Enter a location for saving the database installation/update log file. In case of any errors this log file will be requested by our technical support staff.

After clicking “Next” the appropriate database scripts will be executed. Some of them might take several minutes to execute; this depends on the amount of existing data in the database being upgraded.

Backup a migration-center database

To back up a database used by migration-center it is sufficient to back up only the data within the FMEMC schema. The easiest way to do this is with Oracle’s “exp”. See screen shot below for the basic steps required to back up a schema. For more information consult the documentation provided by Oracle.

Starting with Oracle 11g release 2, the empty table might not be exported at all. This happens when the database parameter DEFERRED_SEGMENT_CREATION is set to TRUE. Initially this parameter is set to TRUE. To force exporting all tables from FMEMC schema the following commands should be run connected as user FMEMC:

ALTER TABLE SCHEDULER_RUNS ALLOCATE EXTENT;

ALTER TABLE SCHEDULERS ALLOCATE EXTENT;

Restoring a migration-center database

To restore the backup, follow the steps below:

  1. If the database instance where the backup should be restored does not contain an FMEMC schema and FMEMC user, please create them first.

  2. Use Oracle’s “imp” utility for importing the dump file previously created by the “exp” utility. See screen shot below for the basic steps required to restore a database schema from a dump file. For more information consult the documentation provided by Oracle.

Note: The same character sets in the Oracle Client should be used when exporting and importing the data.

Installation of the Server components on Windows

The migration-center Server Components include the adapters which connect to the various source and target systems, as well as the Job Server service which runs the jobs employing those adapters.

Before starting the installation note that JAVA_HOME or JRE_HOME need to be set appropriately.

After starting the installation, a welcome screen appears. Click [Next] to move on to the next step.

The installation of the Job Server can be cancelled anytime by clicking [cancel].

Select destination location

Next, the user will select the installation location for the Server Components. The default installation path proposed by the installer is recommended but can be changed if needed.

Server components folder in the start menu

During the installation, shortcuts are created for migration-center Server Components in the Windows start menu. The location of the shortcuts can be configured here. Furthermore, an entry is created in the Windows Start Menu Startup folder, in order to allow the automatic start of the Job Server.

Select Job Server port

At this point the TCP listening port of the Job Server is configured. The port specified here is used by the migration-center client to control the Job Server. The default port is 9700 and can be changed if needed.

Different Job Servers on different machines can all use the default port number, the same port number but different from the default port, or entirely different port numbers each.

The port specified for each Job Server during installation must be specified when adding a new Job Server location in the client pointing towards that respective Job Server.

Select the folder where the log files will be saved

Default value is the logs folder in the Server Components installation folder, but it can be set to any valid local path or UNC network share. Note the location set here must allow write access for the account used to run the migration-center Job Server service, which is the component writing the log files.

Completion of the installation

The Job Server is installed on the system by selecting [Install].

Multiple installations of the Server Components

Depending on the requirements or possibilities of each migration project, it can make sense to install multiple Job Servers across the environment, either to share the workload, or to exploit performance advantages due to the geographical location of the various source and/or target system, i.e. installing the Job Server on a node as close as possible to the source or target system it is supposed to communicate with.

In terms of throughput, local installations will provide benefits over remote installations and local networks will always be faster than remote networks.

Besides throughput, latency needs to be considered as well, since increased latency can affect performance just as much, even leading to timeouts or connection breakdowns in severe cases.

Ending the installation process

If all selected components are installed, the installation will be ended by selecting [Finish].

Uninstalling previous versions of the mc Server Components

A clean installation of the mc Server Components may require uninstalling the previously installed version first and would be recommended if upgrading while skipping over several intermediate versions.

To uninstall the mc Server Components follow the steps below:

  1. Stop the mc Job ServerJob Service if it is currently running; this can be done

    • using the Windows Services application

    • using the “Stop service” shortcut in Start Menu/All Programs/fme AG/migration-center Components <currently installed version>

  2. Uninstall the mc Server Components; this can be done

    • Using the Programs and Features applet in Windows Control Panel

    • using the “Uninstall” shortcut in Start Menu/All Programs/fme AG/migration-center Components <currently installed version>

Uninstalling will not delete the log files having been generated in the mc Server Components installation folder, as the user may want to keep log files for future reference. Thus, it is up the user whether to delete or archive leftover log files after the uninstaller has completed removing the application’s files.

Installation of the Server Components on Linux

Not all adapters are available on the Linux version of Server Components. The ones available are:

  • Scanners: Documentum, Filesystem, Database, eRoom, Exchange

  • Importers: Documentum, Filesystem, InfoArchive

The Linux version of the migration-center Server Components can be found in the folder ServerComponents_Linux.

In order to install the Migration Center Job Server extract the archive Jobserver.tar.gz in the desired location using the command:

tar -zxvf Jobserver.tar.gz

All necessary Job Server files will be extracted in the “Jobserver” folder.

To install the Job Server as a service / daemon, follow these steps:

1. Switch to the “bin” folder of the “Jobserver” folder

2. Run the command sudo ./installDaemon.sh

Run the installDaemon.sh as a user that has administrative permissions (sudo).

Instead of installing the Job Server as a service/daemon, you can run it in the terminal by executing the script ./runConsole.sh in the bin folder

The default TCP listening port is 9701 and can be changed in “server-config.properties” file located in “lib/mc-core” folder.

For running Documentum Scanner or Importer on Linux the DFC (Documentum Foundation Classes) needs to be configured in “conf/dfc.conf” as it is described in the Scanner and Importer user guides.

Starting migration-center Client

During installation of migration-center Client, a desktop icon (optional) and a Start Menu entry were created. By default this can be found in Start-> (All) Programs-> fme AG-> migration-center Server Components <Version>. The migration-center Client can be started by using the shortcuts from these locations.

Starting the Job Server on Windows

The Job Server is set up as a Windows service during the installation and can be managed using the regular Services Microsoft Management Console snap-in.

By selecting the “Migration Center Job Server” entry, the service can be manually started, stopped or restarted if needed. If the service is required to run using a specific user account, this can be configured on the Log On tab in the services’ properties.

In addition, the Job Server has shortcuts in the Start menu by which the service can be stopped or started directly without having to access the Services console. By default these can be found in Start-> (All) Programs-> fme AG-> migration-center Server Components <Version>.

Starting and running the Job Server on Linux

The Job Server is setup as a service (daemon) and can be started or stopped by running the following scripts inside the “Jobserver/bin” folder

  • ./startDaemon.sh for starting the daemon

  • ./stopDaemon.sh for stopping the daemon

Instead of installing the Job Server as a service/daemon, you can run it in the terminal by executing the script ./runConsole.sh in the bin folder.

Uninstall

The following paragraphs describes how to uninstall the individual components of migration-center.

Uninstalling the migration-center Client

The migration-center Client can be uninstalled by using „Add or Remove Programs“ or “Programs and Features” item in the Control Panel (depending on the version of Windows used). You can find the Client listed under the name „migration-center Client <Version>“, it can be uninstalled by selecting the entry and clicking [Remove].

Uninstall links are also provided in the Start Menu program group created during installation. By default, this is Start-> (All) Programs-> fme AG-> migration-center Client <Version>.

Uninstalling the migration-center database schema

Uninstalling the migration-center database schema will delete all data within that schema. It is no longer possible to recover the information after that. Please back up the database schema before uninstalling it.

An uninstall script is provided with migration-center; it can be found in database/util/drop_fmemc_schema.sql. Run this script against the Oracle database instance the FMEMC schema should be removed from using the Oracle administration tool of your choice.

Make sure no connections with the user FMEMC exist, otherwise the script will fail to execute properly. Should this happen, the script can be re-run after closing all connections of the user fmemc.

Uninstalling the migration-center Server Components on Windows

The migration-center Server Components can be uninstalled by using “Add or Remove Programs” or “Program and Features” item in the Control Panel (depending on the version of Windows used). You can find the Server Components listed under the name “migration-center Server Components <Version>” and can be uninstalled by selecting the entry and clicking [Remove].

Uninstall links are also provided in the Start Menu program group created during installation. By default, this is Start-> (All) Programs-> fme AG-> migration-center Server Components <Version>.

Uninstalling the migration-center Server Components on Linux

To uninstall the Job Server as a service/daemon, follow these steps:

  • Go to the “bin” folder inside “Jobserver” folder

  • Run the command ./uninstallDaemon.sh

Run uninstallDaemon.sh as a user that has administrative permissions (sudo).

Last updated