Resolution:
Description:
============
The only way would be to recreate the domain and then reimport the applications and users. The steps for the activity are listed in the resolution section.

Environment:
===========
TIBCO Administrator 5.6.x
TIBCO Runtime Agent 5.6.x
OS : All

Resolution:
==========
Use the following procedure to migrate a file based domain to a database based domain. Using the procedure, you create an administration domain that uses a database for domain storage and add machines to the domain. After exporting applications and ACLs from the file-based domain, you import the same to the newly created database domain. After migration, you can clean-up the file based domain.

The following restrictions apply when migrating a file based domain to a database based domain:

Application domains are not moved to the new database domain. You must recreate application domains in the new database domain using TIBCO Administrator. See Working With Application Domains in the TIBCO Administrator User’s Guide for more information.

TIBCO Enterprise Message Service configurations are not moved to the new database domain and must be reconfigured using TIBCO Domain Utility. See EMS Server Plug-in the TIBCO Runtime Agent Domain Utility User’s Guide.

Application server configurations (Servlet Engines) are not moved and must be reconfigured using TIBCO Domain Utility. See "Adding or Updating a Servlet Engine to a Domain" in the TIBCO Runtime Agent Domain Utility User’s Guide.

Procedure
=========
1). Using TIBCO Domain Utility, create an administration domain that uses a database for domain storage. The domain name must be unique among domains running on the host machine. See Creating a Domain that Uses a Database in the TIBCO Runtime Agent Domain Utility User’s Guide for details.

2). Using TIBCO Domain Utility, add the machines that will host TIBCO applications to the new database administration domain. See Adding a Machine to a Domain in the TIBCO Runtime Agent Domain Utility User’s Guide for details.

3). Using the AppManage utility, export all applications in the file based domain to a directory. For example, the next command line exports all applications found in the myfiledomain domain to the c:\test directory.

AppManage -batchexport -dir c:\test -user user1 -pw pw1 -domain myfiledomain

4). Using the ExportDomainSecurity utility, export the ACLs used in the file based domain to the acls.xml file. For example, the next command line exports all ACLs found in the myfiledomain domain to the c:\test\acls.xml file.

ExportDomainSecurity –file c:\test\acls.xml –acls -user user1 -pw pw1 -domain myfiledomain

5). Using the AppManage utility, import the applications into the database domain. For example, the next command line imports all applications found in the c:\test directory to the mydatabasedomain domain.

AppManage -batchDeploy -nostart -user user1 -pw pw1 -domain mydatabasedomain

6). Using the ImportDomainSecurity utility, import the ACLs into the database domain. For example, the next command line imports all ACLs found in the c:\test\acls.xml file to the mydatabasedomain domain.

ImportDomainSecurity –file c:\test\acls.xml –overwrite -user user1 -pw pw1 -domain mydatabasedomain

7). Stop the applications in the file based domain before starting them in the database based domain. Note that you need not restart all applications at once. Applications can be stopped individually in the file based domain and started individually in the database domain.

8). After verifying that all applications are working correctly in the database domain, you can cleanup the file based domain as follows:

— Undeploy all applications from the file based domain
— Delete all applications from the file based domain
— Delete any secondary servers defined in the file based domain
— Remove each machine from the file based domain
— Delete the file based domain