Follow

How do I move a TimeXtender Project from one Server to Another?

Before you start

In order to safely and efficiently move a TimeXtender deployment from one server to another, you have to consider how your current setup is configured. Without considering these key questions, you may run into problems during the migration process.

  • Do you use multiple environments?
    • If so, are they located on this server?
    • If not, can you connect to them from the new server?
  • Are you using history in any of your projects?
  • Do the users, user groups and service accounts have the same access and rights to the new server?
  • Do you use SSIS?
    • If so, is SSIS installed and running on the new server?
      • If SSIS is running on the new server, can all the users and service accounts access the Integration Services server through SQL management studio?
        • If not, see the Troubleshooting section
      • Do you use Analysis Services?
        • If so, is SSAS installed and running on the new server?
      • Do you have the installation files for the version of TX DWA you are currently using?
        • If not, you must either request a copy of your version's installation files or upgrade to the newest version of TX DWA. Upgrade or install TX DWA

How to move from one server to the other

Broadly speaking, there are two ways to transfer a project across servers.  One is to backup and restore TX DWA databases onto the new server.  The other way is to transfer only the project metadata using a project export.

Transferring only metadata is fast and easy, but is not appropriate in all cases.  The primary drawback is that data not currently present in the source system will be lost in a metadata-only transfer.  If you are using history in your project, especially Type II SCD functionality, we strongly recommend using database transfer and restore instead.  

Method 1: database backups

Backup and restore all databases

  1. Create full backups of your project repository(ies) and other related databases.
  2. Transfer the backups to the new server and restore them there.
  3. After you have restored the databases you need to install TX DWA. Upgrade or install TX DWA
  4. When you start it up the first time you point it to the newly restored repository and press ok.

Update multiple environment settings if applicable

  1. After you did the first steps, you need to log into TX DWA as the server service user.
  2. Point it to the other repository.
  3. Open the "Windows Service Setup"
  4. Start the Server Service as that user account and close TX DWA.
  5. Open TX DWA as the first user and open the "Environment Properties".
  6. You should be able to see all environments and global databases.

Deploy/execute all projects. You do not need to run a full deployment, as the underlying database structure will be present thanks to the full migration process. 

Method 2: project exports

Transfer project metadata

  1. Start the current version of TX DWA, open a project and press the X logo.

    KB_1.png

  2. Choose Import/Export and press Export Project. Save it somewhere ideally as ProjectName_16_xx_xx.

    KB_2.png

  3. If you use multiple environments, these settings won’t be saved, so a good idea would be to set all the global databases back to the project settings before you export them.

    KB_3.png

  4. If you have more than one project, then press close project, open another project and export that as well. Keep doing it until you have no more projects.

After you have exported those you need to install the same version of TX DWA as you had on the old server. This is because the exported projects are locked to the version of the TX DWA software they have been exported from. Upgrade or install TX DWA

Import metadata and rebuild databases

  1. Install and register the TX DWA software.
  2. When prompted, create a new repository and give it the same name as the old repository.
  3. Import the project.
  4. When prompted, run the connection manager

    KB_4.png

  5. Run the wizard and remember to create all the databases, as they are not present on the new server.

Update multiple environment settings if applicable

  1. Any environmental settings for this environment will be lost with this transfer method.
  2. Follow the guide in this link to set up multiple environments.

To complete the move, do full Deploy/Execute of all projects you have transferred to the new server.

Troubleshooting

  • Problem: Error when deploying SSIS packages on the new server, or accessing the Integration services database on SQL management studio.
    • Solution: Ensure all users are set up in the administrators AD group or have added in the DCOM settings.  See Component Services
  • Problem: Error when executing the OLAP cubes.
    • Solution: Grant the SSAS service user read rights on the data warehouse database.  See the troubleshooting page for this error.
  • Problem: The new server has the SQL server as an instance.
    • Solution: Change the server from localhost to "ServerB\NamedInstance". Change the SSIS server name to a non-instanced server name, for example, "ServerB"
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.