Using the drive management feature of the $PRODUCT_NAME_WORKFLOW application, you can move the application data from $PRODUCT_NAME_WORKFLOW to a different drive and subsequently reconfigure the $PRODUCT_NAME_WORKFLOW application accordingly. Typical use cases include moving data to a newly installed hard drive or separating  data drive from the database drive to improve application performance.

To ensure that all functions are available, the PPD Tools Collection must be started as an administrator.

The Drive Management for $PRODUCT_NAME_WORKFLOW is available in the Applications menu under Workflow Configuration > Workflow Settings > Workflow Drives Management.

Figure 1: The Workflow Drives Management menu item in the Applications menu

In the Workflow Drives Management dialog, the database drive and the file management drive can be changed individually or together.      

After configuration – select the desired new drive letters in the Database Drive [1] and Filemanagement Drive [2] options – you can start the copy process by clicking the Copy Files and Reconfigure WF [3] button.

The dialog displays the size of the data to be copied. If there is insufficient storage space on the destination drive, a warning is displayed before the process starts. This function is password-protected.

Figure 2: The Workflow Drives Management dialog

The original directories, including all data, remain on the source drive but are renamed to *_toDelete. They serve as an additional backup in case any issues occur. These folders can be manually deleted once the $PRODUCT_NAME_WORKFLOW services has been started and is running without errors.

When executing the Copy Files and Reconfigure WF command, the following steps are performed:

1. All application services are stopped.
2. The relevant data is copied.
   • If the data drive is changed, the PMSDatabase folder is copied.
   • If the file management drive is changed, all folders except the PMSDatabase folder are copied. All folders for imported instances and backups are also copied.
3. The original directories in PMS_DATA are renamed to *toDelete.
4. The application is reconfigured. During this process, services are recreated and configuration files are rewritten.
5. If file management has been copied, all local shares referencing PMS_DATA in the int.global.path database table are updated.
6. Finally, all application services are restarted.