Knowledgebase : Product Technical Support > FileCatalyst Workflow and Webmail
 

Overview

This article will give you a brief summary on how to uninstall various FileCatalyst Products in Linux, Mac OSX, and Windows Environments.

 

Environment

FileCatalyst Server v3.4 and later.

FileCatalyst HotFolder v3.4 and later.

FileCatalyst TransferAgent v3.5 and later.

FileCatalyst  Central v3.5 and later.

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.
 

Resolution

Note: You may need elevated access to perform some of these commands

FileCatalyst Server

  1. Windows:
    1. Shutdown all the standalone FileCatalyst Server Remote Admin Application.
    2. Open the Services Manager by clicking on Start, search for Services.msc, and then running the application.
    3. Locate the FileCatalyst Server Service and click Stop.
    4. Open Control Panel from the Start menu then navigate to Programs and Features.
    5. Click on the FileCatalyst Server and hit Uninstall.
    6. Check the box to Force Deletion of C:\path\to\FileCatalyst Server\ when prompted.
    7. Hit Uninstall.

  2. Linux:
    1. If you are running the FileCatalyst Server stand-alone, such as ./fc_server.sh or ./fc_server_console.sh, FileCatalyst Server Admin (running stand-alone) will need to closed.
    2. Close the FileCatalyst Server Remote Admin Application, if it is open.
    3. Open a new Terminal window.
    4. Navigate to the folder where your server is installed. Typically the path used is /opt/utechsoft/server/.
    5. Execute the command:

      ./fc_server_shutdown.sh

    6. Verify the Service is stopped by running the command:

      ps -ef | grep -i "filecatalystserver"

    7. If you are running the FileCatalyst Server as a Service, stop the service by using the appropriate command needed for your version of Linux in the terminal window. For our example we use:

      service fcserver stop

    8. Remove the Service by navigating to the service_wrapper folder located within the Server installation folder. A sample path would look like /opt/utechsoft/server/service_wrapper/.
    9. Run the command ./uninstall.sh.
    10. You can now remove the folder structure by using the following command:

      rm -rf /opt/utechsoft/server/

  3. Mac OSX:
    1. Exit the FileCatalyst Server Remote Admin Application.
    2. Click to open the FileCatalyst Server in System Preferences located under the Apple menu.
    3. To stop the currently running service, click Stop Filecatalyst Server Service. You may be prompted to enter elevated user account credentials.
    4. To uninstall the FileCatalyst Server Service, uncheck the box labeled Start FileCatalyst Server on Start Up.
    5. Return to System Preferences and right-click on the FileCatalyst Server icon. Click remove from panel.
    6. From the Finder window and click on Applications.
    7. Find FileCatalystServer.app, right-click on it and delete it.
    8. Find FileCatalystServerAdmin.app and delete it as well.
    9. Use Finder to access the Library folder and open Application Support.
    10. Delete the Filecatalyst folder. A sample path would be /Library/Application Support/FileCatalyst/.

FileCatalyst  Hotfolder

  1. Windows:
    1. If you are running FileCatalyst HotFolder stand-alone, from File menu select the Exit FileCatalyst HotFolder option.
    2. If you are running FileCatalyst HotFolder as a service, click on Start, search for Services.msc, and run that application.
    3. Find the Hotfolder Service and stop it.
    4. Open Control Panel from the start menu and navigate to Programs and Features.
    5. Locate FileCatalyst Hotfolder and click uninstall
    6. Check the box to Force Deletion of C:\path\to\FileCatalyst HotFolder\ when prompted.
    7. Hit Uninstall.

  2. Linux:
    1. If you are running the FileCatalyst HotFolder stand-alone, such as ./fc_hotfolder.sh or ./fc_hotfolder_console.sh, FileCatalyst HotFolder Admin (running stand-alone) will need to closed.
    2. Close the FileCatalyst HotFolder Remote Admin Application, if it is open.
    3. Open a new Terminal window.
    4. Navigate to the folder where your FileCatalyst HotFolder is installed. Typically the path used is /opt/utechsoft/hotfolder/.
    5. Execute the command:

      ./fc_hotfolder_shutdown.sh

    6. Verify the Service is stopped by running the command:

      ps -ef | grep -i "filecatalyst"

    7. If you are running the FileCatalyst HotFolder as a Service, stop the service by using the appropriate command needed for your version of Linux in the Terminal window. For our example we use:

      service fchotfolder stop

    8. Remove the Service by navigating to the service_wrapper folder located within the FileCatalyst HotFolder installation folder. A sample path would look like /opt/utechsoft/hotfolder/service_wrapper/.
    9. Run the command ./uninstall.sh.
    10. You can now remove the folder structure by using the following command:

      rm -rf /opt/utechsoft/hotfolder/

  3. Mac OSX:
    1. Exit the FileCatalyst HotFolder Remote Admin Application.
    2. Click to open the FileCatalyst HotFolder in System Preferences located under the Apple menu.
    3. To stop the currently running service, click Stop Filecatalyst HotFolder Service. You may be prompted to enter elevated user account credentials.
    4. To uninstall the FileCatalyst HotFolder Service, uncheck the box labeled Start FileCatalyst HotFolder on Start Up.
    5. Return to System Preferences and right-click on the FileCatalyst HotFolder icon. Click remove from panel.
    6. From the Finder window and click on Applications.
    7. Find FileCatalystHotFolder.app, right-click on it and delete it.
    8. Find FileCatalystHotFolderAdmin.app and delete it as well.
    9. Use Finder to access the Library folder and open Application Support.
    10. Delete the Filecatalyst folder. A sample path would be /Library/Application Support/FileCatalyst/.

FileCatalyst TransferAgent

  1. Windows:
    1. Close FileCatalyst TransferAgent by right-clicking the tray icon and exiting the application.
    2. Open Control Panel from the start menu and navigate to Programs and Features.
    3. Locate FileCatalyst TransferAgent and click uninstall
    4. Check the box to Force Deletion of C:\path\to\FileCatalyst TransferAgent\ when prompted.
    5. Hit Uninstall.

  2. Linux:
    1. Close the FileCatalyst TransferAgent if it is open.
    2. Open a new Terminal window.
    3. Navigate to the folder where your FileCatalyst TransferAgent is installed. Typically the path used is /opt/utechsoft/trasnferagent/.
    4. Verify that there are not other instances of TransferAgent running by executing the command:

      ps -ef | grep -i "filecatalyst"

    5. You can now remove the folder structure by using the following command:

      rm -rf /opt/utechsoft/transferagent/

  3. Mac OSX:
    1. Quit the FileCatalyst TransferAgent Application.
    2. From the Finder windows and click on Applications.
    3. Find FileCatalystTransferAgent.app, right-click on it and delete it.
    4. Use Finder to access the Library folder and open Application Support.
    5. Delete the Filecatalyst folder. A sample path would be /Users/Admin/Library/Application Support/FileCatalyst/.

FileCatalyst Central

  1. Windows:
    1. Open the Services Manager by clicking on Start, search for Services.msc, and then running the application.
    2. Locate the FileCatalyst Central Service and click Stop.
    3. Open Control Panel from the Start menu then navigate to Programs and Features.
    4. Click on the FileCatalyst Central and hit Uninstall.
    5. Check the box to Force Deletion of C:\path\to\FileCatalyst Central\ when prompted.
    6. Hit Uninstall.

  2. Linux:
    1. Open a new Terminal window.
    2. Navigate to the folder where your FileCatalyst Central is installed. Typically the path used is /opt/utechsoft/central/.
    3. Execute the command:

      ./fc_central_stop.sh

    4. Verify the Service is stopped by running the command:

      ps -ef | grep -i "filecatalyst"

    5. If you are running the FileCatalyst HotFolder as a Service, stop the service by using the appropriate command needed for your version of Linux in the Terminal window. For our example we use:

      service fc_central stop

    6. Remove the Service by navigating to the service_wrapper folder located within the FileCatalyst Central installation folder. A sample path would look like /opt/utechsoft/central/service_wrapper/.
    7. Run the command ./uninstall.sh.
    8. You can now remove the folder structure by using the following command:

      rm -rf /opt/utechsoft/central/

FileCatalyst Workflow/Webmail

  1. Windows:
    1. Open the Services Manager by clicking on Start, search for Services.msc, and then running the application.
    2. Locate your Web Server (Tomcat, IIS, etc.) and stop the respective service.
    3. Using Windows Explorer, navigate to the Web Root location. A sample path would be C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\.
    4. Delete the workflow or webmail folder that was published to the Web Server.
    5. Delete the workflow.war or fcweb.war file in the Web Root location.
    6. Navigate to your workflow-config (or fcweb-config) folder and delete it. A sample path of this location is C:\workflow-config\.

  2. Linux:
    1. Open a new Terminal window.
    2. Stop the service that controls your Web Server (Tomcat).
    3. Verify the Service is stopped by running the command:

      ps -ef | grep -i "java"

    4. Navigate to your Web Server Root directory, we have used /opt/tomcat/webapps/ for this example.
    5. Delete the workflow or webmail folder that was published to the Web Server by running:

      rm -rf /opt/tomcat/webapps/workflow/ or rm -rf /opt/tomcat/webapps/webmail/ 

    6. Remove the workflow.war and webmail.war from /opt/tomcat/webapps/ directory.
    7. Navigate to your workflow-config (or fcweb-config) folder and delete it. A sample command would be:

      rm -rf /opt/tomcat/workflow-config/ or rm -rf /opt/tomcat/webmail-config/
       
  3. Mac OSX:
    1. Shutdown your Web Server by using System Preferences.
    2. Locate the Web Server you are using and shutdown the service.
    3. Use Finder to search for your workflow or webmail deployment folder. It will be located in your Web Server Root location.
    4. Delete the workflow or webmail folder once it is located.
    5. Search for fcweb.war or workflow.war in Finder and delete those files.
    6. Located your workflow-config or fcweb-config folder in Finder and delete it.

Overview

When deploying Workflow 5.0.x on Tomcat 9.0 an "HTTP Status 500 - Internal Server Error" is displayed after every restart of the Tomcat web server. The following exception is displayed in the browser:

Tomcat9 HTTP 500

Searchable Stack Trace:


Type Exception Report

Message AuthConfigFactory error: java.lang.reflect.InvocationTargetException

Description The server encountered an unexpected condition that prevented it from fulfilling the request.

java.lang.SecurityException: AuthConfigFactory error: java.lang.reflect.InvocationTargetException
     javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85)
     org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1239)


java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: Feature: http://apache.org/xml/features/allow-java-encodings
     org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65)
     org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345)

Environment

FileCatalyst Workflow v5.x
Tomcat 9.0

Resolution

The error displayed above can be resolved by modifying the catalina.properties file which is located inside the installation directory of the Tomcat 9.0 web server. Use the following steps to apply the solution:

  1. Shutdown the Tomcat 9.0 web server.
  2. Using a text editor open the catalina.properties file. It is usually located in /install-path-to-tomcat/conf/. Make a copy of this file before you continue further.
  3. At the very top of the file add the following properties:

    • javax.xml.parsers.DocumentBuilderFactory = com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
    • javax.xml.transform.TransformerFactory = com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
    • javax.xml.parsers.SAXParserFactory = com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
    • javax.xml.datatype.DatatypeFactory = com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl

  4. Please note that the properties above are case sensitive. Once these properties have been added to the top of the file you can save and close this file.
  5. Start the Tomcat web server.

Overview

The FileCatalyst Web Suite is shipped with an internal database (HSQL DB) which should only be used for testing purposes. The HSQL Database is a lightweight tool which does not offer any backup or recovery options. Before any FileCatalyst Web Deployment is moved into production it is imperative that an external database is used. We recommend the MySQL Community Server.

 

Environment

FileCatalyst Workflow v4.7 and later.

FileCatalyst Webmail v4.7 and later.

 

Resolution

Note: Before completing these steps you should back up your Workflow Configuration or FCWeb Configuration Folder. The location of your Configuration folder can be found in the About FileCatalyst screen.

You will also want to ensure users are not logged into the site during this process. To ensure this you can block the access ports (80 or 443 for SSL). The following Resolution instructions are based on a Windows Installation.

  1. Download and install MySQL Community Server from https://dev.mysql.com/downloads/windows/installer/5.7.html
    1. Fill out the necessary information, such as the installation paths. Keep track of the password you enter for the MySQL Root Password field as it will be needed in the next steps.

  2. Once installed, browse to your FileCatalyst Workflow/Webmail site and log in as Super Admin.
  3. Go to Modify Configuration at the top of the menu bar.
  4. Click on Edit Database Settings link under the Advanced Settings section.
  5. Select the MySQL radial to enable the Database Settings fields.
  6. Do not adjust the Driver and Path fields.
  7. Enter a Database Name. You can name it workflow or fcweb. Do not use a database name that already exists.
  8. The username should be root and the password should be what you entered during the MySQL Installation in step 1b.
  9. Click the button below to Convert Existing Data once. Depending on the size of your database this may take some time so wait for it to finish. To prevent any corruption during the conversion do not close the browser, refresh the page or navigate away.



Overview

On November 1st, 2019, FileCatalyst ended support for Java Applets. As such, FileCatalyst no longer re-signs, supports, or distributes Java Applets. Furthermore, FileCatalyst no longer provides any support for legacy products that still use or embeds Java Applets.

Java Applets were replaced with TransferAgent technology. TransferAgent appeared in v3.4.1 Build 7 which was released on September 24th, 2014, at which point the Java Applets were deprecated. The last build of Java Applets occurred 3 years later in v3.7.1 Build 10 (July 10th, 2017), and after 5 years support was concluded on November 1st, 2019.

However, it’s still possible to run old FileCatalyst/Unlimi-Tech Java Applets with expired certificates.

Environment

FileCatalyst Workflow 
FileCatalyst Applets

Resolution

Please see the attached PDF for the full guide. The settings in the guide must be performed on all client-side machines.

Overview

For FileCatalyst Workflow and Webmail (discontinued), we have been producing a Windows-based installer that contained an embedded Tomcat. In the last five years, we have seen many vulnerabilities with Tomcat which have been exposed such as POODLE, Logjam and other man-in-the-middle attack variants. In some cases, Tomcat has been very responsive to patching CATALINA and in other instances, there has been the need to engineer a solution. 

For the Windows platform, we currently have two ways you can install the Workflow product (Standalone Tomcat and Embedded Tomcat) and when it comes to hardening Tomcat or patching or even migration there are variations in the instruction sets. This leads to confusion, loss of productivity and ultimately impacts production. In many cases, we have found that our clients who have used the Windows installer need to migrate away from it at some point to the standalone Tomcat installation.

One of our goals at FileCatalyst is to make our products easier to use. As of November 30th, 2020, we will be removing the Windows Installer and standardizing our installs across Linux and Windows.

We will have migration documentation available on our KnowledgeBase and if you require assistance in migrating your instance you can always reach out to your FileCatalyst Account Executive to discuss your options.

Environment

FileCatlayst Workflow v5.1.2 and older
Windows OS only.

Overview 

This article will walk you through the different steps in creating and installing an SSL certificate on a Tomcat Webserver in a Windows Environment. The steps below will help you create a Java Keystore (JKS) which contains a Self-Signed SSL Certificate or one that has been purchased from a Certificate Authority. Our document was written and tested with Certificates purchased from Thawte or Digicert.


Here are quick links to sections within the article:




Environment

Tomcat 9.0
Workflow v5.0 and newer

Prerequisites


Resolution

Generate CSR and Keystore Container.


  1. Run the application and select Create A New Keystore and select the JKS radial.



  2. Right-click in the white space and select Generate Key Pair (Ctrl+G).


  3. Use the RSA Algorithm with 2048 key size.




  4. At the bottom of the window edit the Name section.



  5. Fill out your company information. This information will be needed to Generate the CSR. Please note that the CN field should be the Domain you are trying to secure.



  6. Once you have completed your entry hit OK. You will be prompted to enter an Alias name. Use tomcat and create a password. We suggest using a complex password with 8 characters. This password will be required for other steps, keep it handy. You should receive a message to confirm Key Pair Generation Successful. For this article, we will use changeit.

  7. Save the Keystore, for this article we will use companyssl.jks. We suggest using a folder on the root of C:\ called TomcatSSL. You will be prompted to Set a Keystore Password. Use the same one created in Step 6). 

  8. To Export the CSR, right-click on the tomcat entry and select Generate CSR. In the new window, you will see a path to where the CSR will be stored edit the path if necessary. You will receive a message confirming the CSR Generation Successful.




  9. At this point, you will have a Keystore file that contains:

    • Private Key (which is in the Keystore container)
    • Self-Signed Certificate (which is in the Keystore container)
    • CSR (separate file)

  10. The CSR can be uploaded to your Certificate Authority or Vendor for signing purposes. Once you have received your Certificate from your Authority Vendor use these steps to add it to your Keystore.

    Alternatively, you can choose to Deploy the Self-Signed Certificate.


Append Signed SSL Certificate to Keystore

In this step, we will replace the Self-Signed Certificate in your current Keystore (companyssl.jks) with the one you have purchased from the Certificate Authority. Please download the certificate as a full chain with a CRT extension. If you did not get a full chained certificate then create one here.

  1. Open the Keystore container (companyssl.jks) created when Generating the CSR.

  2. Right-click on tomcat and select Import CA Reply and use the From File option.



  3. From the file explorer, locate and select the SSL Certificate you have downloaded from the Certificate Authority.

  4. Once the import is complete right click on tomcat and navigate to View Details and select Certificate Chain Details. You should see a waterfall of certificates with the bottom one being your Domain SSL Certificate.




  5. Save the Keystore file and proceed to the Deploy SSL Certificate on Tomcat.

    Note: If you receive an error adding the full certificate chain to the keystore container you may still have your Self-Signed Certificate as part of your keystore. You will need to remove it. Right click on tomcat and select Edit Certificate Chain and choose Remove Certificate.



Creating an Entire SSL Certificate Trust Chain

There are many methods of creating a full chained certificate. This is an example of one method.

A full trust chain looks like:

-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: CA.crt)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----

We use Notepad++ for this section as it allows you to open multiple text files and let you flip between them.

  1. Open an empty text file and call it chained.crt.

  2. Open your Domain Certificate (PEM) in a text editor. This is the SSL certificate that your Domain is tied to. Copy the contents and paste them into the chained.crt file. 

  3. Open the Intermediate Certificate (PEM) and copy the contents. Paste it below your Domain Certificate. 

  4. Repeat the process again for the Root Certificate (PEM).
    Note in some cases your Intermediate and Root Certificates can be downloaded as a bundle. You can use the bundle to create the full chain as long as the end result is formatted in the illustration above.

  5. Save the chained.crt file and proceed to add it to the Java Keystore section.



Deploy SSL Certificate on Tomcat


In Tomcat there are many different ways to configure your connector. The example below uses a hardened and secure connector which supports the following clients:

  • Android 4.4.2 and later
  • Firefox 32 and later
  • IE 11 and later
  • IE Mobile 11 and later
  • Java 8 b132
  • Safari 7 and later
  • TLSv1.2

If you would like to use a less secure connector you can use the example shown here:

https://wiki.owasp.org/index.php/Securing_tomcat#Sample_Configuration_-_Good_Security 

For a more secure connection using the following steps:

  1. Shut down the Tomcat WebServer.

  2. Create a copy of the server.xml file located in <path-to-tomcat>/conf/.

  3. Open server.xml in a text editor and add the following connector:

    <Connector port="443"
    protocol="org.apache.coyote.http11.Http11NioProtocol"
    SSLEnabled="true"
    maxThreads="150"
    scheme="https"
    secure="true"
    keystoreFile="c:\Tomcat-SSL\companyssl.jks"
    keystorePass="changeit"
    clientAuth="false"
    sslProtocol="TLSv1.2"
    sslEnabledProtocols="TLSv1.2"
    ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
    />

  4. Save the file and start the Tomcat WebServer. 

Specify the path to your keystore file in keystoreFile="c:\tomcat-ssl\companyssl.jks". If your keystore password is not "changeit" then make the change to keystorePass="changeit" in the factory element. If a specific port does not need to be specified in the URL, such as https://mycompany.com:<port>, then port 443 should be specified in the connector. This change will provide seamless integration.

Once your Tomcat Server is back online you can test the SSL on  your webpage (https://mycompany.com:<port>) here: https://www.sslshopper.com/ssl-checker.html




Useful Tomcat Security Articles:

Overview

Internet Explorer has been the stock web browser that has been packaged in every Windows OS. As of November 30, 2020, Microsoft plans to end extended support for this browser. Following in the same footsteps we will also be terminating support for Internet Explorer browsers at this time as well.





You can read the full details of this update here: https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-apps-say-farewell-to-internet-explorer-11-and/ba-p/1591666

For our clients who are on Internet Explorer, we would highly recommend migrating your workflows to use Chrome, Firefox or Edge browsers.



Environment

Windows OS - Internet Explorer (all version)


FileCatalyst Workflow
FileCatalyst TransferAgent
FileCatalyst Server - Link/Upload/Download
In the current version, administrators will need 2 accounts--their admin account and their user account. Future versions will likely feature a method for switching between user and administrator mode in order to give those people a more seamless experience.

****Status Update ****

As of December 17, 2007 a new Switch To User button has been introduced that permits admins to switch between user and admin interfaces.

This new feture is availbale in all Enterprise versions of FC Web, Files2U and Doctera
Rather than forwarding to a distribution list from within the application, the best approach is to set up a rule in Outlook or other e-mail client (assuming it supports rules and filters) which will forward the request email to your list. Since the request email features a very specific subject line ("New User XYZ"), you could use this subject line to trigger your rule.

Note: This article assumes that you are using Apache Software Foundation's Tomcat 6.0 to deploy a server application (Unlimited FTP Servlet, FileCatalyst Web, Files2U, Doctera). It is likely that the information and files provided will also work with Tomcat 5.5 or 6.x+, but only 6.0 has been tested. Always make backups before replacing or modifying files.

---

Tomcat's default logging characteristics are more than up to the task of recording a huge number of messages; the daily rotation is sufficient for most needs. However, in certain environments or under certain conditions you may have noticed your "stdout.log" file (in your Tomcat/logs/ directory) is growing to unmanageable sizes during the course of a day. We have created a drop-in-place solution that will provide size-based rather than daily rotation. The files are rotated based on:

- Maximum File Size for an individual logfile (before a new one is started)
- Maximum number of logfiles to keep before rotating

Follow these steps to implement custom size-based log rotation:

1. Download and unzip this archive: http://www.utechsoft.com/support/documentation/tomcat_log_rotation.zip
2. Stop Tomcat
3. Copy tomcat-juli.jar to /Tomcat/bin
4. Copy tomcat-juli-adapters.jar to /Tomcat/lib
5. Copy log4j-1.2.15.jar to /Tomcat/lib
6. Copy log4j.properties to /Tomcat/lib
7. Copy tomcat_log_test.jsp to /Tomcat/webapps/ROOT
8. Edit log4j.properties.  MaxFileSize sets the threshold when the log file gets rotated.  MaxBackupIndex sets the number of rotated log files that are kept before the oldest gets deleted.
9. Edit /Tomcat/conf/context.xml to add swallowOutput="true" to the Context tag.  This must be set inside the “greater than/less than” braces.
 
Example:
 
<!-- The contents of this file will be loaded for each web application -->
<Context swallowOutput="true">

 
This will redirect the stdout to the a custom log file called "tomcat.log". Note that the stdout logs will still be created, but will contain no messages.
 
10. Start Tomcat
11. Check if the configuration was successful:
  a) go to your /Tomcat/logs directory to observe creation of the logs
  b) if tomcat.log exists, you have implemented the new log rotation correctly
  c) test rotation by pointing a browser at: http://localhost:8080/tomcat_log_test.jsp (substitute with appropriate host and port if applicable), which will simply create a harmless set of errors to dump to the log. Refresh this page as many times as necessary.

Once the tomcat.log file reaches the threshold size (MaxFileSize), new incremental files will appear, named: tomcat.log.1, tomcat.log.2, tomcat.log.3 etc. (up to the MaxBackupIndex number).  Once the MaxBackupIndex is reached, the oldest current tomcat.log.x file will be deleted and the rest will be rotated through.

In the past FileCatalyst/Unlimi-Tech used its own method of showing applets in browsers. As more browsers became available, Java took it upon themselves to release a standard way to deploy these applets within the browser. 

This article will show you how to migrate the legacy javascript files to use the new deployJava method.  

Before making any changes, make a backup of your existing JavaScript file or server side script file that contains the JavaScript code to launch the applet. 

Download the latest version of the applet you have and extract it to an accessible location. 

In the extracted folder you will see the default JavaScript file we ship out. Edit it and populate it with the settings from your existing JavaScript file or Server Side Script. 

Copy the deployJava.js that was in the download package to the same folder location as the existing JavaScriipt file or Server side script file.

If you wish to update the applet, copy the latest .jar file to this location and override the one that is there. 

Add the following line
<script type="text/javascript" src="deployJava.js"></script> in your HTML or Server side script file. This line has to go above the line that calls the applet JavaScript file or the <script> tag that has the applet deploy code in it. 


Here is a comparison between the old .js format and the new .js format.

Old .js format looks like this
// Connection related settings
var server                      = "";
var port                        = "";
var user                        = "";
var pass                        = "";
var encrypt                     = "";
var ek                          = "";
var clientConnectKey            = "";     
var enableSSL                   = "";
var maxRetries                  = "";
var waitRetry                   = "";


New .js format looks like this
var parameters = {
    server			             :"",
    port			             :"",
    user			             :"",
    pass			             :"",
    mode			             :"",   
    enableSSL		             :""
};

var attributes = {
    name: "FileCatalyst",
    code: "unlimited.fc.client.FileCatalystCart.class",
    archive: "FileCatalystApplets.jar",
    width:width,
    height:height
};
var version = '1.5';
	
if (typeof(deployJava) == 'undefined'){
    document.write("<h2>deployJava.js is missing, make sure that you also include deployJava.js in your html</h2>");
}else{
    deployJava.runApplet(attributes, parameters, version);
}
	
	

 

There are usually 5 steps required by the user to complete a job in FileCatalyst Workflow:

  1. Log in to the system 
  2. Click on “create a new Job”
  3. User selects and completes one of their available order forms, with the user providing meta data for the upload
  4. Click on “upload files”, at which point the user selects files from their local system and uploads them to the server
  5. Click on the final confirmation

It is sometimes beneficial to skip some of those steps. Here is how you can configure FileCatalyst Workflow to skip some of those steps:

ActionHow to bypass
1. Log in Enable anonymous access in “General Settings”.
2. Select job form

Assign user status to “Job Entry, no file storage”. User MUST have a single form assigned and therefore the form selection will be skipped.

To have a single order form assigned to a user you can:

  • have only a single order form created in the system
  • have mutiple order forms but only a single order form has "is private" option unchecked in the system
  • have a user assigned to a single group that has only a single order form assigned
  • have a user assigned to multiple order forms but all the groups share the same single order form
3. Complete order form Set the content of the form to have no fields or to have all hidden fields (with default values pre-set).
4. Upload file(s) Uncheck the “At least one file” option under the order form properties; user will be able to create a job with meta data only
5. Confirmation Go to “Modify Configuration -> Configure Job Submission Steps” (or in older versions of the software, “Configure Workflow”) and remove the Confirm step from the list.

 

The above configuration options allow you to reduce the number of steps taken. The trade-off is flexibility and granularity of information. You can easily imagine that automatic job creation with no form to fill out will provide very little useful information to the system, but on the other hand you will have enabled a very simple file transfer process.

A side note for anonymous users. It is possible to append other parameters to the log in the URL. This will take the user directly to the desired form or to pre-fill certain values on that order form

Example:

http://myFCWEBServer.com/fcweb/logonAnonymous.do?form=default&TextAreaField=Here+are+the+files&firstName=John&lastName=Smith&[email protected]

The above will automatically select the default order form, with the text area filed set to “Here Are the files” and the email recipient to be “[email protected]”. Remember to always URL encode your values (in this example + becomes a white space).

Overview

All of our FileCatalyst Products are installed with default memory limits, including both initial reserve and maximum memory. However, these can be configured to fit your specific needs and environment. This article will go through the configuration process for FileCatalyst Workflow or Webmail for Windows, Linux, and MacOSX

NOTE:

  • For all environments:
    If you are using a 32-bit Operating System or Java 32-bit, the maximum memory you can define for JAVA is limited to 1.5GB of memory.  64-bit Operating Systems running 64-bit Java do not have such memory limitations.
  • It is also recommended (but not required) to set the minimum and the maximum memory to the same value, as this allows JAVA to allocate a single continuous block of the memory from the OS on startup.
  • Have all Tomcat Server Service shut down before editing any configuration files.


Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

 

Resolution 

Windows

When FileCatalyst Webmail or Workflow is installed on a Windows machine, there are two ways to increase the memory used.

  1. The first is to use the tomcat7w.exe or tomcat8w.exe, which is located in the \apache-tomcat\bin folder. A sample path would be C:\Program Files\Apache Software Foundation\Tomcat 7.0\bin\.
    1. Run tomcat7w.exe or tomcat8w.exe as an administrator. You can right-click the file and select the Run as Administrator.
    2. When the Tomcat Properties opens, select the Java tab.
    3. Increase Initial and Maximum Memory Pools as required. We recommend using identical values so the memory block is contiguous.

  2. The second method is to edit your catalina.bat file.
    1. Open the catalina.bat file in a text editor, which is located in the \apache-tomcat\bin. A sample path would be C:\Program Files\Apache Software Foundation\Tomcat 7.0\bin\
    2. Add the following line:

      set JAVA_OPTS="-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"

      Again we recommend using identical values for both Xms and Xmx so your memory block is contiguous.

Linux

For a deployment of FileCatalyst Webmail or Workflow is installed on a Linux machine, the catalina.sh startup script needs to be editted.

  1. Navigate to the /apache-tomcat/bin/ folder and open the catalina.sh file in a text editor such as vi.
  2. Add the following line at the bottom of the file:

    export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"

    We recommended that the Xms and Xmx values be identical so your memory block is contiguous.

MacOSX

When FileCatalyst Webmail or Workflow is installed on a MacOSX machine, the catalina startup script.

  1. Navigate to the /apache-tomcat-/bin/ folder using Finder.
  2. Edit the catalina.sh file in a text editor.
  3. Add the following line at the end of the file:

    export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"

    We recommended that the Xms and Xmx values be identical so your memory block is contiguous.

Overview

A Workflow download link can be set to expire after a set number of days. In this article we will use the example of 1 day, however, this can be changed to reflect the expiry time your deployment requires.

 

Environment

FileCatalyst Workflow v4.8 and newer.

FileCatalyst Webmail v4.8 and newer.

 

Resolution

To attach an expiry date to the download link we will need to create a Job Data Field, append it to a Form and set the expiry date.

 

Create Job Data Field:

1) Login to Workflow as Super Admin.

2) Click on Modify Configuration tab from the top menu bar.

3) Under the Job Configuration section, click on the Job Data Fields link.

4) On the right side of the page, you will see a dialog that will let you add a new field.

5) Fill out the Field ID, Display Label and select “expireupload” from the drop down list. For this article we used:

Field ID: JobExpiry

Display Label: Job Expiry

6) Hit Add New and do not forget to hit Save.

 

Adding the Job Expiry Data Field to the Form:

1) Click on Modify Configuration.

2) Under the Job Configuration section, click on the Order Forms link.

3) For this example, we will use the Distribution Form. Hit the “+ beside it to expand the contents.

4) Click on Form 1.

5) When you land on the Edit Form #1 page, look for the Fields section, in the drop-down menu select Job Expiry and hit Add Field.

6) Check the Hidden Box for this specific field and hit Submit.

7) You will be taken back to the Edit Forms page, hit Save to apply the settings.

 

Configuring the Expire Jobs after 1 day:

1) Go back to the Edit Forms page.

2) Expand the form you were editing, for this example, it's the Distribution form.

3) There is a text field labelled Days before upload expires:,  enter a whole number of days to set the length of time.

4) Hit Save.

Overview

The Workflow landing page automatically formats the company logo to align to the left. The page was designed to place the logo image on the top left portion.  

 

Environment

FileCatalyst Workflow v4.8 and later.

FileCatalyst Webmail v4.8 and later.

 

Resolution

This can be achieved by editing the Application Common Style Sheet (CSS).

  1. Login to the FileCatalyst Workflow as the Super User, by default it is Init and we strongly recommend changing this if you still use Init.
  2. Click on Modify Configuration on the top Menu Bar.
  3. Locate the Template Setup and click on Common Style Sheet*.
  4. You can reference the image on the page and apply margin changes by adding the following block into the textbox:

    div#headerLogo img
    {
    margin-left: auto;
    margin-right: auto;
    float: none;
    }

  5. Hit Save to apply the changes.
  6. You will need to log out and clear your cache for changes to take effect.



Overview

The Workflow Logon page can be customized to display a message from the administrator or to show a service message to users.

 

Environment

FileCatalyst Workflow v4.8 and later.

 

Resolution

This can be achieved by editing the HTML Header configuration for the Logon Page and the Application Common Style Sheet (CSS). 

HTML Header Configuration

  1. Login to the FileCatalyst Workflow as the Super User, by default it is Init and we strongly recommend changing this if you still use Init.
  2. Click on Modify Configuration on the top Menu Bar.
  3. Locate the Template Setup Section and click on HTML Headers. A smaller pop-up window will show you the options of the pages you can edit. Select **Default**.
  4. Copy the text withing the text area that is present into a text editor, then can press Cancel.
  5. Repeat Step 3 and click on the Logon link.
  6. Paste the contents from your text editor into this the text area field.
  7. Add the following<div id ="logonMessage"></div> and augment your code so that it looks like:

    <div>
    <div id="headerLogo" class="headerLogoClass pageWidth" align="center">
     <img src="logo.gif" style="float:none">
     <div id="logonMessage">
     Enter your message here.
     </div>
     </div>

  8. Click Save.
  9. You will need to log out and clear your cache for changes to be visible.

 

CSS Configuration

  1. Click on Modify Configuration.
  2. Locate the Template Setup and click on Common Style Sheet* (CSS).
  3. For a test we added a box around some text on the Logon page of FileCatalyst Workflow. You can reference the <div id="logonMessage"> in the CSS by adding the following:

    #logonMessage
    {
    border: 1px solid #cc0000;
    margin-top: 20px;
    padding: 8px;
    }

  4. Hit Save.
  5. You will need to log out and clear your cache for changes to take effect.

Note: Step 3 is an example of custom changes you can make to that message.

 

Overview

When your clients use HTTPS as a connection method and are unable to launch the upload applet, their Java settings may be at fault.

The error in question appears with the typical generic message such as:


Error. Click for details.


When clicking this message, you will see a more in depth message:

Application Error

ClassNotFoundException

unlimited.fc.client.FileCatalystCartFCWeb.class

 

Environment

FileCatalyst Workflow v4.9.4 and later.

FileCatalyst Webmail v4.9.4 and later.

Windows Environment.

 

Resolutions

  1. From the client machine, open Control Panel and then double-click on Java.
  2. In the Java Control Panel, select the Advanced tab and then scroll to the bottom.
  3. Uncheck Use SSL 2.0 compatible ClientHello format.
  4. Click on the General tab and navigate to Temporary Internet File section and hit Settings.
  5. Select Delete Files... and select all the checkboxes and hit OK.
  6. When you are back in the General Tab, hit Apply and restart your browser.

Overview

When attempting to launch any of our web-based FileCatalyst Applets and are redirected to the Java download page, this is due to a disparity between the type of Java installed on your system and the type of web browser you have installed.

If your Java version and your web browser are different bit architecture types, and 32-bit or 64-bit, your system attempts to correct this.

 

Environment

FileCatalyst Workflow v4.0 and later.

FileCatalyst Webmail v4.0 and later.

FileCatalyst Applets v3.4 and later.

Windows Environment.

 

Resolution

  • To check your Java version, open a Command Prompt and enter the following command:

    java -version 

  • Following is an example of output from this command:

    java version "1.8.0_31"

    Java (TM) SE Runtime Environment (build 1.8.0_31-b13)

    Java HotSpot (TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

  • This example shows that Java RE is version 1.8.0_31 and that it is the 64-bit architecture.

  • The process to check your web browser version varies depending upon the web browser in question. In general, a quick Google search will bring up instructions for your specific web browser. The version will display "64-bit" if it is the 64-bit type; there will be no indicator however if it is the 32-bit type.

  • If your Java is the 64-bit architecture and your web browser is the 32-bit architecture you will be redirected to java.com to download the appropriate Java type. 

Overview

MySQL tables may need to be repaired if the following errors are found in FileCatalyst Workflow or FileCatalyst Webmail logs:

2013-01-14 16:08:45,686 ERROR sys  -   Error on Query: SELECT * FROM DOCTERA_PRINTFILES WHERE jobID='OO1EU846RUN9ZJ20'
Error Message is: Table 'DOCTERA_PRINTFILES' is marked as crashed and should be repaired
2013-01-14 16:08:45,686 ERROR user  - Error in getFilesForJob
java.sql.SQLException: Table 'DOCTERA_PRINTFILES' is marked as crashed and should be repaired
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3536)

 

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.


Resolution

Repairing MYSQL Tables

  1. Backup of your MySQL database before attempting to repair any of the tables.
  2. Run the MYSQL command line tool.
  3. Run the use command to point to the database used by your FileCatalyst Workflow or Webmail product. For example:

    use workflow or use webmail or use fcweb

  4. Execute show tables command. The result should look like:

    doctera_anonymous_users
    doctera_contacts
    doctera_groups
    doctera_jobarchive
    doctera_jobs
    doctera_logs
    doctera_printfiles
    doctera_userprefs
    doctera_users

  5. Check the tables by using check table command. Use the following command:

    CHECK TABLE DOCTERA_ANONYMOUS_USERS, DOCTERA_CONTACTS, DOCTERA_GROUPS, DOCTERA_JOBARCHIVE, DOCTERA_JOBS, DOCTERA_LOGS, DOCTERA_PRINTFILES, DOCTERA_USERPREFS, DOCTERA_USERS extended;

    Your results will look like:

    Table Op Msg_Type Msg_Txt
     workflow.doctera_anonymous_users check status OK
     workflow.doctera_contacts check status OK
     workflow.doctera_groups check status OK
     workflow.doctera_jobarchive check status OK
     workflow.doctera_jobs check status OK
     workflow.doctera_logs check status OK
     workflow.doctera_printfiles check status OK
     workflow.doctera_userprefs check status OK
    workflow.doctera_users check status OK

     

  6. Run the repair command for the tables that require repair. That is for any table which does not return the status of OK. The command would look like:

    REPAIR TABLE DOCTERA_ANONYMOUS_USERS, DOCTERA_CONTACTS, DOCTERA_GROUPS, DOCTERA_JOBARCHIVE, DOCTERA_JOBS, DOCTERA_LOGS, DOCTERA_PRINTFILES, DOCTERA_USERPREFS, DOCTERA_USERS extended;

  7. Additionally, you can run a single line repair and optimization command after backing up your database:

    mysqlch.eck -u root -p --auto-repair --check --optimize --all-databases

 

Overview

When installing FileCatalyst Webmail or Workflow from the Windows Executable that we provide, you may encounter an issue when trying to start the FileCatalyst Webmail or Workflow Service. This is due to either Java not being configured properly on your machine or User access Control permissions. The following article will show a workaround to help you get it configured as a service.

 

Environment

FileCatalyst Workflow v4.9.4 and later.

FileCatalyst Webmail v4.9.4 and later.

Windows Server 2008.


Resolution

  1. Go to the installed location for FileCatalyst Webmail or Workflow through Windows Explorer. This should be under C:\Program Files\FileCatalyst Web Workflow\.
  2. Navigate into the apache-tomcat folder then into bin folder. A sample path would look like C:\Program Files\FileCatalyst Web Workflow\apache-tomcat/bin/.
  3. Open the Tomcat7fcwebw.exe file. You may need to run this file as Administrator. To do this, right-click on this and select Run as Administrator.
  4. This will open the FileCatalyst/Tomcat Service Manager. Go to the Java tab.
  5. Uncheck the Use Default and specify the Java Virtual Machine Location as follows:

    <install directory FileCatalyst Web Workflow>\Java\jre7\bin\server\jvm.dll

    For example, a full path would be: C:\FileCatalyst Web Workflow\Java\jre7\bin\server\jvm.dll

  6. Hit OK.

Overview

For every job submission in FileCatalyst Workflow, an email message is sent out to the User and/or Administrator. These email messages can be configured with the customized content. This article will walk you through adding custom content in an email message.

 

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

 

Resolution

  1. To allow senders to enter a custom subject of the email message sent to the recipient, the following tasks should be performed:
    1. Log into the Workflow deployment as a Super Admin User. By default, it is called init.
    2. From the top menu bar, click the Modify Configuration button.
    3. Click on the link for Recipient E-mail under the Content Configuration section.
    4. In the editing window labeled Edit ReceipientEmail_email.txt, insert the following code at the very beginning just before the <html> tag:

      {JOB,userDefinedFieldData(subjectField)} from {USERFULLNAME}

      The first line is the subject of the email sent to the recipient.
    5. Hit Save.
    6. You should be taken back to Modify Configuration page with the text RecipeintEmail_email.txt saved ok in red. This will confirm your changes have been saved.

  2. Configure the Job Field:
    1. From the Modify Configuration menu, click on the link to Job Data Fields located under the Job Configuration section.
    2. Search the pre-loaded fields for one called subjectField. If it exists, skip to the next step in the guide. If it does not exist locate the New Field section and add the following:

      Field ID:            subjectField
      Display Label:    Email Subject
      Type:                text (from drop down list)
      Display Format: ROWS="1" COLS="80"

    3. Click Save.
    4. You should be taken back to Modify Configuration page with the text config.xml saved ok in red. This will confirm your changes have been saved.

  3. Configure the Job Form:
    1. In the Modify Configuration page locate and click on the Order Forms which is under the Job Configuration section.
    2. Expand the Form you want to customize by hitting the + symbol.
    3. Click on Form 1 button to open the form options.
    4. Add the subjectField from the Fields drop-down menu.
    5. Position the location of the subjectField using the arrows to the left.
    6. Click on the Submit button once the field is positioned.
    7. Hit Save on the Edit Order Forms page to save the changes made to the Form. This step is important.
      The users will not be able to set their own custom subject message and it will append to the email.

Overview

In FileCatalyst Workflow, it is possible to add a Job Data Field which will allow the end user to send files to any email address and have the system notify the sender when the status of the Job has been changed. This article will guide you through adding this field to your order form.

 

Environment

FileCatalyst Workflow v4.9 and later.

 

Resolution

  1. Log into FileCatalyst Workflow as the Super Admin User.
  2. Click on Modify Configuration and go to the Order Forms under the Job Configuration section.
  3. Select the Order Form you would like to edit by expanding the window using + and clicking on Form 1.
  4. In the Fields section select Notify when download occurs from the drop down list.
  5. Hit Add Field and use the clickable arrows to position this field on your form.
  6. Click the  Submit button.
  7. Click Save to confirm that changes have been applied.

 

Note:

  • If you wish, you can also set the Notify Sender Field on the order form as Hidden, and set the default to YES. This will hide that field and make the download notifications always work with all jobs and all the users.
  • There are 3 types of download email notifications in Workflow:
    • The first notification is sent to the sender as soon as a recipient clicks on the download link.
    • The second notification is sent when the recipient has downloaded all the files via the Java Applet when Md5 checksum succeeded and the Job is flipped to Sent and Received or Shipped status.
    • If the recipient has decided to use the individual download links (not the applet) a link to Notify the sender that the download was successful, is provided on the download page. When this link is clicked by the recipient the Job is flipped to Sent and Received or Shipped status and an email is sent.

Overview

When uploading files to FileCatalyst Workflow or Webmail using the HTML Form Upload, there may be many dropped connections or no connectivity for links with high latency (>300ms). During an upload via HTML form (not the Java Applets) the transfer can sometimes be interrupted with timeouts and restarts or the upload progress status window will not update and will show a Page Not Found or Page Can’t be displayed error. 

 

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

 

Resolution

The high latency link can be accommodated by adjusting the Web Server timeout settings.

  1. Shutdown the Tomcat Web Server service.
  2. Using a text editor open /<path to tomcat>/conf/server.xml file.
  3. Locate the connector that looks like:

    <Connector port="80" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

  4. Add the following properties to the connector:

    <Connector port="80" protocol="HTTP/1.1"
    connectionTimeout="80000"
    disableUploadTimeout="true"
    maxPostSize="-1"
    redirectPort="8443" />

  5. Save the file and close the text editor.
  6. Restart the Tomcat Web server.

Note:

Summary of the properties added:

  • connectionTimeout: The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. This was increased to 80000.
  • disableUploadTimeout: This allows the servlet container to use a different, longer connection timeout while a servlet is being executed, which in the end allows either the servlet a longer amount of time to complete its execution, or a longer timeout during data upload.
  • maxPostSize: The maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value less than or equal to 0. In this case, it disables the maximum file size.

Overview

Logs are one of the critical pieces of information requested by FileCatalyst Support. Below is a list of those viewed as most useful from a support perspective and their default locations. If support has requested logs for a given event please remember that they are rotated every 24 hours at the time set in the configuration file and archived with the dates shown in the name.


Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.


Resolution

Note: The following log locations are shown for FileCatalyt Workflow, if you would like to see them for FileCatalyst Webmail, replace the Workflow entries with name of the name of the Webmail folder.

FileCatalyst Workflow:

  1. Web Server Logs:

    • Windows Location<path to Tomcat>\logs\ 
    • Linux Location: /opt/tomcat/logs/ or <tomcat_home>/logs/
    • Mac OSX Location: <path to tomcat_home>/logs/

      • tomcat7-stderr.<yyyy-mm-dd>.log
      • tomcat7-stdout.<yyyy-mm-dd>.log
      • catalina.<yyyy-mm-dd>.log

        These logs will show us issues with the Tomcat Web Server and its service. Any errors or exceptions that are caught by the Tomcat engine will be stored in these files.

  2. FileCatalyst Workflow Application Logs:

    • Windows Location<path to Tomcat>\webapps\logs\workflow\
    • Linux Location: /opt/tomcat/webapps/logs/workflow or <tomcat_home>/webapps/logs/workflow/
    • Mac OSX Location: <path to tomcat_home>/webapps/logs/workflow/

      • webapp.log 

        This is a catch-all log, it will contain more granular information about the FileCatalyst Workflow deployment, file transfers and the background process that launch.

  3. Internal FTP Session Logs:

    • Windows Location:  <path to>\workflow-config\FTPSessionLogs\
    • Linux Location: <path to>/workflow-config/FTPSessionLogs
    • Mac OSX Location:  <path to>/workflow-config/FTPSessionLogs

      • The path to the Workflow-Config logs can be found on the About FileCatalyst page of the FileCatalyst Workflow deployment.
      • Format <user><JobID><YY:mm:dd>_<hh:mm:ss>.log

Overview

In IPv4, the local machine loopback IP 127.0.0.1 is mapped to the hostname localhost. For the majority of testing situations, this will be fine. However, there are a few reasons you might want to associate your local machine with your organization's public domain name or even an arbitrary domain name but yet have this name resolve entirely on the local machine instead of the public internet.

For example:

  1. You are testing SSL certificates and are using a production certificate. This will cause redirections to the actual Public domain, which will conflict with your test environment.
    When testing SSL certificates in a test environment, many people will generate a self-signed certificate tied to the localhost instead of the public domain. However, this is not always ideal. Testing might require ensuring that the actual public certificate is valid and works alongside the web application. The problem is that the production certificate is generated using your actual public domain, as soon as a redirect is performed, you will be dumped out of your test environment and into the public site.
  2. Parts of your web application built in-house have hard-coded references to the domain and you do not want to be taken out to the public internet during testing.
  3. Simplified URL entry into the address bar or using the DNS as a hostname.

This article will outline the steps to add an alias to the hosts file in a Windows Environment, which will redirect a DNS name to the loopback IP address.  The resolution steps will apply to Linux and other *nix Systems.

Environment

FileCatalyst Server v3.4 and later.

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

Resolution

  1. Click the Start button and search for notepad.exe.
  2. Right-click on Notepad and select Run as Administrator.
  3. Browse to C:\Windows\system32\drivers\etc\ and open the hosts file.
  4. On a new line, enter the IP followed by the domain name, separated by at least one space. For example: 127.0.0.1 www.mydomain.com
  5. Save the file and close Notepad.
  6. Restart your machine for the changes to take effect.

Whenever www.mydomain.com is called, this DNS will resolve to 127.0.0.1 on this machine.

 

Notes

Overview

FileCatalyst Workflow offers full control and customization of your deployment. It allows administrators or web architects to provide the connecting client with the look and feel of the companies design. One configurable element is the Footer of a web page. Many IT Admins have used this area to attach a message to the clients offering contact details and hours of operation. This is just one example of a use case for the footer. This element can be configured through the Admin Console of FileCatalyst Workflow. This article will outline how to deploy a footer on every Workflow web page.

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

Resolution

This solution will require some customization from a Web Developer but it is a good starting point. To deploy this solution please complete all of the steps outlined below:

  1. Login in as Super Admin User.
  2. Click on the Modify Configuration button in the top menu bar.
  3. Under Template Setup, click on HTML Footer link. Choose **Default** from the list.
  4. Create a DIV and give and ID. For example:

    <div class="footerMessage">This is a sample footer message!</div>

  5. Hit the Save button.
  6. From the Modify Configuration page, click on Common Style Sheet from the Template Setup Menu.
  7. Add the bottom of this file add your customizations. I tested using:

    .footerMessage {
    background-color: white;
    border: 2px solid red;
    height: 60px;
    vertical-align: middle;
    margin-top: 10px;
    width: 623px;
    margin-left: auto;
    margin-right: auto;
    }

    The ID used in step 4, needs to be called here. This is the section where the customizations of how the message is displayed. Do not make changes to the template file itself. These get overwritten on upgrades of Workflow. Any changes made to the Common Style Sheet will get carried forward when upgrades take place.


  8. Hit the Save button.
  9. Logout of Workflow and clear the browser cache. You will notice that your changes are displayed once the cache is cleared.



 

Google+

Products: FileCatalyst Direct (server), Webmail and Workflow

Option 1: 

Use IPTables

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 8080

Replace 80 with the low port of your choice and replace 8080 with the actual port the server is listening on

Option 2:

Use authbind. The authbind package is designed to allow users to bind servers upon a low-numbered port. The package is available for most Linux platforms.

Debian Example:

[email protected]:# apt-get install authbind

 

Once installed the software is configured via files located beneath /etc/authbind. There are three subdirectories:

  • /etc/authbind/byport
  • /etc/authbind/byuid
  • /etc/authbind/byaddr

The manpage to the authbind program explains how these subdirectories are used. But as a simple example we can allow the user skx to bind to port 80 by running the following commands:

[email protected]:~# touch /etc/authbind/byport/80
[email protected]:~# chown skx:skx /etc/authbind/byport/80
[email protected]:~# chmod 755 /etc/authbind/byport/80

Here we have created a file with the name 80 (which is used to specify that the user may bind to port 80). This file is executable to the user skx - this is sufficient for the user to bind to port 80 - if they prefix their command with authbind.

If you installed FC Direct / Webmail / Workflow on Linux/Unix and after a few hours of Tomcat or FC Server running you notice that the server is not responding or image files are not loading or Java applets are not loading. Or you see an error "Too many open files" in the logs. Make sure that you don't have any limits for maximum open files. 


To view all available resource limits, type ulimit -a.

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 8191
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 8191
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited


You can use "ulimit -n" to change the lopen files limit. You should increase the open files limit to at lease 60000.
This parameter must be changed by the user who runs tomcat and that it must be done each time prior to starting tomcat.

More on ulimit...

ulimit provides control over the resources available to the shell and to processes started by it, on systems that allow such control.

Usually, you have to increase the values of some of the Linux kernel limits before your install or run many applications.

With ulimit you can set two kind of limits:

1. Soft limit: is the value that the kernel enforces for the corresponding resource.
2. Hard limit:
acts as a ceiling for the soft limit.

An unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process may make arbitrary changes to either limit value.

Checking the values of the kernel limits

# ulimit -a
core file size (blocks, -c) 1
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 59517
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 6695364
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 59517
virtual memory (kbytes, -v) 6301520
file locks (-x) unlimited

Changing temporally the value of a limit

With ulimit you can change the value of one limit for the current shell:

# ulimit -n 60000

This command sets the maximum number of opened files to 60000 for the current shell.

Making permanent changes to a limit

Linux servers have a PAM (plugabble authentication) module that handles system limits:

“By default limits are taken from the /etc/security/limits.conf config file. Then individual files from the /etc/security/limits.d/ directory are read. The files are parsed one after another in the order of “C” locale. The effect of the individual files is the same as if all the files were concatenated together in the order of parsing. If a config file is explicitely specified with a module option then the files in the above directory are not parsed.”

In our example we will set the maximum number of files to 16384 for all users of the system (values can be set for individual users or groups as well):

# vi /etc/security/limits.conf

Add two lines for each limit:

* soft nofile 60000
* hard nofile 60000

Reboot your machine and test the new limits configuration:

# ulimit -a
core file size (blocks, -c) 1
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 59517
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 6695364
open files (-n) 60000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 59517
virtual memory (kbytes, -v) 6301520
file locks (-x) unlimited

 

Environment

FileCatalyst Direct Suite v3.0 and later.

 

Overview

Communication between the Client Side software and the FileCatalyst Server is always done through the Control Socket or Command Channel. This connection is usually configured over a non-secure Port such as 21 or a Port secured using SSL, such as 990. The login credentials and commands like, GET, PUT, LS and more.

Once the credentials are verified between the FileCatalyst Server and the Client Side software, a separate link is negotiated where the data flow takes place. Data does not normally flow back and forth over the Command Channel for FileCatalyst Products using UDP acceleration.

Exactly what range is configurable on the FileCatalyst Server?

By default, we specify the port range to be 8000-8999. You are free to change this as you see fit, however, keep in mind that for every command you send out (LS/DIR, PUT, GET, etc), one port needs to be opened up and closed. Thus, if you’re transferring 1000 small 1k files, you are spending all of your time opening and closing sockets (so it’s preferable to zip archive these files). It also means that if you limit the port range to a very small number (say, 10 ports), you are potentially setting yourself up for a port availability issue, even with 1 user connecting. Ports are released by Java relatively quickly, but the OS can hang onto some ports for a long time. These release times vary from OS to OS. The FileCatalyst server does recycle the port list, but it’s always a good idea to have more rather than less.



Overview

Some networks will have IPV6 enabled by default and this may cause an issue with licensing products. This is an issue that has been reported for customers using Unlimi-tech Applets and FileCatalyst Applets. 

Microsoft has posted a Knowledgebase Article on how to disable IPV6 globally and for a specific NIC. These solutions can be deployed automatically or manually.

The guide can be accessed here: https://support.microsoft.com/en-us/kb/929852


Environment

FileCatalyst Direct Suite v3.4 and later.

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

Unlimi-tech Applets all versions.

Windows Environment.

 

Resolution:

The following is an excerpt from the full solutions article using manual steps:

  1. Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
  2. In the User Account Control dialogue box, click Continue.
  3. In Registry Editor, locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

  4. Double-click DisabledComponents to change the entry.

    If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:

    1. In the Edit menu, point to New, and then click DWORD (32-bit) Value.
    2. Type DisabledComponents, and then press Enter.
    3. Double-click DisabledComponents.

  5. Type the following values in the Value Data Field to configure the IPv6 protocol to the intended state, and then click OK:
    1. Type 0x10 to disable IPv6 on all non-tunnel interfaces (both LAN and Point-to-Point Protocol [PPP] interfaces).
  6. A restart of the machine will be required for the settings to be refreshed.

Overview

TransferAgent on Windows 8 and later may not be able to list Mapped Network Drives (with drive letters). This is due to a Microsoft setting in their User Access Control (UAC). Microsoft’s implementation of User Access Control (UAC) in Windows 8 restricts the visibility of mapped network drives to TransferAgent and other Windows services. Rather than disabling or lowering the UAC levels, a registry entry can be added to allow the TransferAgent application to access these drives.

 

Environment

FileCatalyst TransferAgent v3.5 and later

 

Resolution

  1. Log on with an Administrator level account to the Windows machine.
  2. Unzip the file enablelinkedconnections.zip located in the application installation directory. For example C:\Program Files\FileCatalyst\TransferAgent\
  3. Double-click enablelinkedconnections.reg to add the registry entry to the Windows machine.
  4. Reboot the computer to have the changes take effect.

Overview

With the upgrade to Windows 10 and Windows Server 2012, there is a web browser upgrade from Microsoft that replaces Internet Explorer with Edge Browser.

 

Environment

FileCatalyst Workflow v4.7 and later.

FileCatalyst Webmail v4.7 and later.

FileCatalyst Java Applets v3.4.2 and later

Note: These products are affected only in a Windows 10 or Windows Server 2012 environment using Java (JRE/JDK) version 8 and later.

 

Frequently Asked Questions

Oracle has released a memo on Windows 10 compatibility with their Java products. Here is the article found on their website: http://www.java.com/en/download/faq/win10_faq.xml

Is Java supported in Windows 10?

Yes, Java was certified on Windows 10 starting with Java 8 Update 51.

Will Java run in my browser on Windows 10?

Internet Explorer 11 and Firefox will continue to run Java on Windows 10. The Microsoft Edge browser does not support plug-ins and therefore will not run Java.

How do I find the Java Control Panel in Windows 10?

From Windows Search, type in Java. In the search results, select Configure Java. The Java Control Panel will appear.

From the Edge browser, how do I open a URL in Internet Explorer?

The Edge browser allows you to open the same URL in Internet Explorer. Select the More Actions option located at the top of the Edge browser and click on Open with Internet Explorer.

Why am I not seeing any indication of Applet content in Edge as I do in other browsers?

Even when Java is disabled, other browsers provide a visual cue to users if Applet content is available on a page. Edge, however, does not, and users must manually load the page in another browser. System administrators and individuals can manage their users Compatibility View List in Edge to help with prompts to supported browsers, and if serving public-facing content, users can email Microsoft at [email protected] to be included in their global whitelist.

You can access this page from this link as well: http://www.java.com/en/download/faq/win10_faq.xml

Overview

This article describes how to change Data Ports of the Internal FileCatalyst Server, which is deployed with FileCatalyst Workflow and FileCatalyst Webmail as the backend FTP Server. These ports can be changed through the FileCatalyst Server Remote Administration Web Applet or a standalone installation of the FileCatalyst Server Remote Admin. For the purposes of this article, we will make the changes utilizing the Web Applet which can be launched only through Firefox or Internet Explorer.

 

Environment

FileCatalyst Workflow 4.8 and later.

FileCatalyst Webmail 4.9.5 and earlier.


Resolution

  1. Login as Super Admin to FileCatalyst Webmail/WorkFlow.

  2. Click on Modify Configuration tab, it is located on top menu bar.

  3. Under the Internal Servers section, click the link to Configure Internal FTP Server.

  4. Click on Launch Admin Applet.

  1. FileCatalyst Server Admin Applet for Internal_FTP_Server will launch into the GUI for Server Administration.

  2. Click on the Advanced tab on the left side.

  3. Change the Data Port Range fields to the desired values.

  4. Hit Apply to accept the changes.


Note: You must restart FileCatalyst Webmail/Workflow when you make any configuration changes to the Internal FTP Server. This can be achieved by accessing the Modify Configuration page and clicking the Restart System link under the System Restart section.

  

Overview


Any FileCatalyst application that previously used embedded Java applets in a browser has a migration path to FileCatalyst TransferAgent. Moving forward with this solution, we have been able to bring functionality of this product into:

  • Google Chrome v42 and newer.
  • Firefox v40 and newer.
  • Internet Explorer v10 and newer.

 

In Internet Explorer, users have found that the application “stalls” at the “Launching TransferAgent” loading screen.  In most cases, this is not an application hang or stall. Older versions of Internet Explorer have a harder time loading modern JavaScript pages and in some cases, the Internet Explorer or Edge browser is dropped into compatibility mode. This forces a newer instance of Internet Explorer to run an emulation of an older version. You could see an Edge browser or Internet Explorer v11 browser get placed into “IE5 (document mode)” environment.

Environment

FileCatalyst Workflow v4.8 and later.

FileCatalyst Webmail v4.8 and later.

FileCatalyst TransferAgent Deployment all versions.

FileCatalyst Link.

 

Resolution

From an application perspective, we have altered our landing pages to include “DOCTYPE” tags and "X-UA-Compatible” tag to force the browser into an emulation environment from Internet Explorer's latest release available.

To change the emulation mode in Internet Explorer, navigate to the webpage that attempts to load the TransferAgent:

  1. As the spinner is moving and the screen is grey, open Developer Tools. You can access this menu by:
    1. Hitting F12 on your keyboard.
    2. Right-Click on in the grey area and click Inspect Element.
    3. Press Alt in the web browser and click on Tools when it appears. Select Developer Tools from the dropdown list.
  2. In the Developer Console, look for the Emulation tab.
  3. Under the Mode section, use the dropdown list for Document Mode and select "11" or newer.
  4. Refresh the page.

Note: In step 3, if you noticed that your default Document Mode is less than 10, you should check your Compatibility View settings from the Tools menu and remove this website from the list.



Overview

Restricting access to users that are not within a specific Active Directory or LDAP group is possible within FileCatalyst Workflow and FileCatalyst Direct.

 

Environment

FileCatalyst Server v3.5 and later.

FileCatalyst Workflow v4.9.5 and later.

FileCatalyst Webmail v4.9.5 and later.

  

Resolution

The following Context String is an example where any user in the Sample_GP group will be denied access:

SECURITY_PRINCIPAL=section\{userinput} 

SEARCH_FILTER=(&(sAMAccountName={userinput})(objectClass=user)(!(memberOf=CN=Sample_GP,OU=Security,OU=Example_Groups,dc=section,dc=company,dc=com)))

SEARCH_BASE=dc=section,dc=company,dc=com

SECURITY_GROUPS=

This will deny anyone in the group Sample_GP the ability to log into the system.

 

Overview

If you run into issues while using a FileCatalyst Web Application (such as Workflow, Central, and TransferAgent) or certain Unlimi-Tech transfer applets, there are two important reasons for knowing how to view and understand the JavaScript console:

  1. The support team may ask for additional information, such as the errors being reported.
  2. To spot any errors you may have introduced in a configuration file.

 

Environment

FileCatalyst Workflow v4.9.4 and later.

FileCatalyst TransferAgent Deployment Package v3.5 and later.

FileCatalyst Central v3.5 and later.

 

Resolution

Opening the console:

  1. Google Chrome
    1. Click the Menu icon.
    2. Cursor down to the More Tools fly-out menu.
    3. Open Developer Tools.
    4. On the top menu bar in the Developer Tools Window, click on Console.

  2. Firefox
    1. Click the Menu icon.
    2. Select Developer.
    3. Open the Web Console.

  3. Safari
    1. The Open the Tools from Safari, they must first be enabled:
      1. Open Safari Preferences.
      2. Switch to the Advanced Pane.
      3. Check the Show Develop Menu in Menu Bar check box.

    2. After the step above, the Web Inspector will be available. You can add it to the menu bar with Customize Menu Bar, which will create a quick-access icon. Or you can fire it up the longer way:
      1. Select Develop from the main menu.
      2. Click on Show Error Console.

  4. Internet Explorer 9 and later:
    1. Open the Tools menu, in compact view, this looks like a gear cog.
    2. Select F12 Developer Tools.
    3. Switch from the DOM Inspector to the JavaScript console by clicking the Console.

Catching errors:

  • If there are errors in the JavaScript, they should be prominently visible in the JavaScript console. Once it is opened, you may clear it to start with a fresh view, and then refresh the page and step through your failure scenario. At the point of failure, if it is a JavaScript issue, you will see an error reported, generally with red text to emphasize the fact that it is an error.
  • Errors come with text that is meant to be as meaningful as possible, and an additional link is supplied which will take you to the source of the error. For example:

    Uncaught ReferenceError:   someFunction is not defined    main.js line 1566

  • The application is trying to use a piece of code called someFunction but it doesn't exist. At the right, you can generally click the main.js line 1566 and the view will change you to a view of the JavaScript with the questionable function highlighted for you.

Configuration errors:

  • Configuration errors will appear the same way. JavaScript doesn't know that it was a typo in configuration; it just knows that some JavaScript failed. However, when the error refers to problems within a configuration file, the error occurs in configuration.js line 23, it is worth considering that the problem may have been introduced during the configuration phase.

  • When a Configuration is handled by the JavaScript, it must still follow JavaScript conventions and rules. Here are some common culprits:

    • Missing Commas:
      The items in a list of configurable parameters might be done with a bunch of key-value pairs. These are identified by the key:value pattern (a colon separating them) and the entire pair is separated from the next with a comma. Here is an example that contains an error:


      var config = {
        name: "Server 1",
        hostname: "myserver.site.com"
        port: 21
      }

      The missing comma after the hostname means that the rest of that Configuration variable will be dropped. The application probably expects a port value, and when none is found, it will send an error to the JavaScript console.

    • Missing Semicolons:
      In some cases, configurable parameters are each individual variables. They follow a parameter=value; pattern, often preceded by var. JavaScript interpreters are a liberal with semicolons, but sometimes a missing semicolon can introduce errors. Here is an example that might break in some browsers:


      var name = "Server 1";
      var hostname = "myserver.site.com"
      var port = 21;

    • Incorrect Type of Information:
      The Configuration document will describe the type of value expected. Typically, JavaScript comments (//) also reinforce the type. Types used in FileCatalyst Configuration files tend to be:

      1. String: is text surrounded by quotation marks.
      2. Boolean: is true or false, not surrounded by quotation marks.
      3. Integer: is a number, not surrounded by quotation marks.

When the wrong type is provided, JavaScript can break. Here is an example in which every line is correct:

var config = {

  hostname: "myserver.site.com", // string 
  port: 21, // integer
  autoconnect: true //boolean
}

and here is the same example with every line incorrect:

var config = {
  hostname: myserver.site.com, // supposed to be a string, but quotation marks are missing 
  port: "21", // supposed to be an integer, but the quotation marks indicate it's a string 
  autoconnect: "true" // again, the quotation marks change this from a boolean to a string
}

 

Overview

This article will provide a guide on how to enable the Java Console for MacOSX.

 

Environment

FileCatalyst Applets v3.4 and later.

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

Unlimi-tech Applets all versions.

MacOSX Environment.

 

Resolution

  1. After Java JDK or JRE are installed open System Preferences through Apple Menu.
  2. Open Java application.
  3. When the new window opens, navigate to the Advanced tab.
  4. Scroll down and select the Show Console radial.
  5. Click OK to save your changes.

Overview

A Distribution job allows a client to submit a set of files and send them to a list of users for download. When a user receives an email to download files from a FileCatalyst Workflow/Webmail deployment, the default email contains the access link and some generic particulars about the files available and the total size. All forms in FileCatalyst Workflow or Webmail can be modified to add a layer of security to access the download page for files sent to a client. Enabling and adding the Secure Email Authentication to a Distribution form will prompt the Workflow/Webmail instance to generate a secure pin which is emailed to the user when they access the download page.

The Secure Email Authentication Job Data Field (EmailAuth) submission procedure is:

  1. Sender uploads a file using FileCatalyst Workflow or Webmail.
  2. Recipients receive an email with a download http(s) link to download the files and clicks on this access link.
  3. When the recipient clicks on the link FileCatalyst Workflow/Webmail automatically sends the recipient a separate email which contains a secure automatically generated token ID which is only valid for 15 minutes. The recipient must provide this token ID before they can access the file(s). Failure to download the files within 15 minutes will cause the ID to be deactivated and the recipient will have to repeat this entire process. 

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 to v4.9.5.

Resolution

This solution has to be deployed while modifying a few elements of the FileCatalyst Workflow application. Follow all the steps outlined to ensure the solution is deployed correctly.

  1. Creating the Job Data Field:

    1. Login to the FileCatalyst Workflow or Webmail deployment as the Super Admin User. By default, this user is called init.
    2. Click Modify Configuration on the top menu bar.
    3. Under the Job Configuration section, select the Job Data Fields link.
    4. On the top right-hand side locate the Quick Add drop down list. Select Enhanced Email Authentication. Hit the Add New button.
    5. This will create an entry into the Job Data Fields section automatically. Scroll to the bottom of this page and hit Save.
    6. You will be redirected to the Modify Configuration page where you will see config.xml saved ok in red. 

  2. Adding the Job Data Field to a Form:

    1. From the Modify Configuration page, select the Order Forms link under the Job Configuration section.
    2. Expand the Distribution Form by clicking on the + beside the Form name.
    3. Edit the Form by clicking on Form 1  button.
    4. Locate the Fields section in the middle of the page. Highlight Email Authentication (qEmailAuth) and hit Add Field.
    5. When this field is added, make sure to hide the field using the check box. Leave the field under default value blank. The secure pin will be generated automatically.
    6. Hit the Submit button.
    7. When redirected to the Edit Order Forms page, hit Save. Do not skip this step. 
    8. You will be redirected to the Modify Configuration page where you will see config.xml saved ok in red. 

With older versions of our web applications, users might enter a large number of recipients into their list (exceeding 256 characters), resulting in the error:

Error saving transaction, Exception saving job, Data truncation: Data too long for column 'RecipeintEmail' at row 1

This means that the 30 emails exceeded the maximum length of the field in the database. The data type for the recipient's field needs to be changed, thusly:

On the Server go to Start - All Programs - MYSQL Administrator

Login to localhost as root, with an appropriate password.

In MySQL Admin go to Catalogues - fcweb (or other name for your database if applicable; for example, doctera)


Double-click on Doctera_Jobs

Scroll down until you see Recipeint_Email

Change the Data type from VARCHAR(255) to TEXT. Save and apply the changes.

The transaction with a long email recipient list should then start working. The side effect of this change is that the database will grow a bit faster, but if you have plenty of disk space this shouldn’t be an issue.


Update Nov 8th, 2010
If you don't have MySQL Admin installed, you can alter the table using mysql command line interface. Simply type in mysql at command prompt
Than connect "your+db_name";
Than type in:
ALTER TABLE doctera_jobs CHANGE COLUMN RecipeintEmail RecipeintEmail TEXT NULL DEFAULT NULL ;

Overview

When FileCatalyst Workflow has been installed using the Windows Executable Installer, it sets the default landing page to an install confirmation page rather than forwarding traffic to the initial log on page.

This article only applies to the Windows Operating Systems only and as of the publication date of this article, the Windows Executable Installer for FileCatalyst Webmail is no longer. The last available release for this installer is v4.9.5.

Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9.5 and earlier.

Windows Operating System Only.

Resolution

By default, the loading page for the application is the splash screen verifying that FileCatalyst Workflow or Webmail is installed correctly. By changing the automatic redirect in the browser to another landing page and reducing the entry for the timer to 0, the page will redirect immediately to the log on page of the application. Use the following instructions to deploy the full solution:

  1. Shut down the FileCatalyst Web Workflow or FileCatalyst Webmail service from the Service Manager Application.
  2. Open the index.html page in a text editor. The default location of the file is in ROOT folder located in, C:\FileCatalyst Web Workflow\apache-tomcat\webapps\ROOT\.
  3. Locate the tag <META http-equiv="refresh" content="5; URL=/workflow"> and change content to = 0.
  4. Save the file and close the editor.
  5. Restart the FileCatalyst Web Workflow or FileCatalyst Webmail service from the Service Manager Application for the changes to take effect.

Overview

There are many steps to limit access to a download page when using FileCatalyst Workflow. The current behavior of the application will not expire links to the download page automatically. This guide will walk you through the steps to disable the download link the client receives in their email. There are some limitations to this solution:

  • If you send a job with multiple files, for example, 5 files and the user that receives the package only downloads 3 out of 5 files,  the Job Status will never change status to Shipped or Sent and Received.
  • If you have multiple recipients, for example, 5 email addresses, the link will not expire until ALL users have downloaded ALL the files that were sent in the Job Submission.

If the conditions stated above are met, then the Job Status will change, to Shipped.

Environment

FileCatalyst Workflow v4.9 and later.

Resolution

With the solution supplied in this article, the download page becomes inaccessible after the Job Status changes to Shipped. Each Job Submission has a variety of Statuses that can be assigned depending on what state the Job is in. Use the following steps to deploy this solution:

  1. Login as Super Admin User. By default, it is Init.
  2. Click Modify Configuration in the top menu bar.
  3. Navigate to the Job Status Fields link under the Job Configuration section.
  4. Uncheck the box corresponding to either Shipped or Sent and Received Field under the Downloadable column. If you wish to disable access to the download page for any other status you can edit them in this section.
  5. Hit the Save button.

Note:

This article can also be combined with adding and expiry date or time to a Job Form. Combining the two solutions will provide a more thorough way of specifying an expiry to the download link. Use the following link to this article to deploy the solution:  http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/289/0/how-to-set-the-expire-period-for-workflow-download-links

You can find configuration information for UDP buffers here:  https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Web_Platform/5/html/Administration_And_Configuration_Guide/jgroups-perf-udpbuffer.html

Please give this page a read.


This article explains the impact of UDP buffer sizes on high-speed transfers. It also tells how to increase the values for Linux.
Too little UDP buffer space causes the operating system kernel to discard UDP packets. The resulting packet loss has consequences described below.

Latency--The time that passes between the initial transmission of a UDP packet and the eventual successful reception of a retransmission is latency that could have been avoided were it not for the intervening loss.

Bandwidth--Assuming that the initial transmission was not frivolous, it's likely that UDP loss will result in retransmission. Bandwidth used for retransmissions may become significant, especially in cases where there is a large amount of loss or a large number of receivers experiencing loss. 

CPU Time--UDP loss causes the receiver to use CPU time to detect the loss, request one or more retransmissions, and perform the repair. Note that efficiently dealing with loss among a group of receivers requires the use of many timers, often of short duration. Scheduling and processing such timers generally require CPU time in both the operating system kernel ("system time") and in the application receiving UDP ("user time"). Additional CPU time is required to switch between kernel and user modes.

On the sender, CPU time is used to process retransmission requests and to send retransmissions as appropriate. As on the receiver, many timers are required for efficient retransmission processing, thus requiring many switches between kernel and user modes.

Memory--UDP receivers that can only process data in the order that it was initially sent must allocate memory while waiting for retransmissions to arrive. UDP loss causes such receivers to receive data in an order different than that used by the sender. Memory is used to restore the order in which it was initially sent.

Perhaps the two most significant consequences of too much UDP buffer space are slower recovery from loss and physical memory usage. 

Each of these is discussed in turn below.

Slower Recovery--To best understand the consequences of too much UDP buffer space, consider a stream of packets that regularly updates the current value of a rapidly-changing variable in every tenth packet. Why buffer more than ten packets? Doing so would only increase the number of stale packets that must be discarded at the application layer. Given a data stream like this, it's generally better to configure a ten-packet buffer in the kernel so that no more than ten stale packets have to be read by the application before a return to fresh ones from the stream.

It's often counter-intuitive, but excessive UDP buffering can actually increase the recovery time following a large packet loss event. UDP receive buffers should be sized to match the latency budget allocated for CPU scheduling latency with knowledge of expected data rates. 

Physical Memory Usage--It is possible to exhaust available physical memory with UDP buffer space. Requesting a UDP receive buffer of 32 MB and then invoking ten receiver applications uses 320 MB of physical memory. 

Assuming that an average rate is known for a UDP data stream, the amount of latency that would be added by a full UDP receive buffer can be computed as:

    Max Latency = Buffer Size / Average Rate

Note: Take care to watch for different units in buffer size and average rate (e.g. kilobytes vs. megabits per second).

Assuming that an average rate is known for a UDP data stream, the buffer size needed to avoid loss a given worst case CPU scheduling latency can be computed as:

    Buffer Size = Max Latency * Average Rate

Note: Since data rates are often measured in bits per second while buffers are often allocated in bytes, careful conversion may be necessary.


The kernel variable that limits the maximum size allowed for a UDP receive buffer has different names and default values by kernel given in the following :

Default UDP buffers:
Linux net.core.rmem_max 131071 
Solaris udp_max_buf 262144 
FreeBSD, Darwin kern.ipc.maxsockbuf 262144 
AIX sb_max 1048576 


Windows None we know of Seems to grant all reasonable requests 

The examples in this table give the commands needed to set the kernel UDP buffer limit to 8 MB. Root privilege is required to execute these commands.

Recommended UDP Buffers (8+MB):
Linux sysctl -w net.core.rmem_max=8388608 
Solaris ndd -set /dev/udp udp_max_buf 8388608 
FreeBSD, Darwin sysctl -w kern.ipc.maxsockbuf=8388608 
AIX no -o sb_max=8388608 (note: AIX only permits sizes of 1048576, 4194304 or 8388608) 


Making Changes Survive Reboot
The AIX command given above will change the current value and automatically modify /etc/tunables/nextboot so that the change will survive rebooting. Other platforms require additional work described below to make changes survive a reboot.

For Linux and FreeBSD, simply add the sysctl variable setting given above to /etc/sysctl.conf leaving off the sysctl -w part.

We haven't found a convention for Solaris, but would love to hear about it if we've missed something. We've had success just adding the ndd command given above to the end of /etc/rc2.d/S20sysetup.


Interpreting the output of netstat is important in detecting UDP loss. Unfortunately, the output varies considerably from one flavor of Unix to another. Hence, we can't give one set of instructions that will work with all flavors.

For each Unix flavor, we tested under normal conditions and then under conditions forcing UDP loss while keeping a close eye on the output of netstat -s before and after the tests. This revealed the statistics that appeared to have a relationship with UDP packet loss. Output from Solaris and FreeBSD netstat was the most intuitive; Linux and AIX much less so. Following sections give the command we used and highlight the important output for detecting UDP loss.

Detecting Solaris UDP Loss
Use netstat -s. Look for udpInOverflows. It will be in the IPv4 section, not in the UDP section as you might expect. For example:

IPv4:
udpInOverflows = 82427

Detecting Linux UDP Loss
Use netstat -su. Look for packet receive errors in the Udp section. For example:

Udp:
38799 packet receive errors

Detecting Windows UDP Loss
Use netstat -s. Look for Receive Errors in the UDP Statistics for IPv4 section. For example:

UDP Statistics for IPv4
Receive Errors = 131213

Detecting AIX UDP Loss
Use netstat -s. Look for fragments dropped (dup or out of space) in the ip section. For example:

ip:
77070 fragments dropped (dup or out of space)
7.9.5. Detecting FreeBSD and Darwin UDP Loss
Use netstat -s. Look for dropped due to full socket buffers in the udp section. For example:

udp:
6343 dropped due to full socket buffers

FIPS 140-2 Compliant Mode for SunJSSE

Reproduced from http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/FIPS.html In Sun's Java SE implementation version 7 or later, the SunJSSE provider, which contains the SSL/TLS implementation, can be configured to operate in a FIPS 140-2 compliant mode instead of its default mode. This document describes the FIPS 140-2 compliant mode (subsequently called "FIPS mode").

Configuring SunJSSE for FIPS Mode

SunJSSE is configured in FIPS mode by associating it with an appropriate FIPS 140 certified cryptographic provider that supplies the implementations for all cryptographic algorithms required by SunJSSE. This can be done in one of the following ways:

  1. edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider to list the provider name of the FIPS 140 certified cryptographic provider. For example if the name of the cryptographic provider is SunPKCS11-NSS, change the line from security.provider.4=com.sun.net.ssl.internal.ssl.Provider to security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS The class for the provider of the given name must also be listed as a security provider in the java.security file.
  2. at runtime, call the constructor of the SunJSSE provider that takes a java.security.Provider object as a parameter. For example, if the variable cryptoProvider is a reference to the cryptographic provider, call new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider).
  3. at runtime, call the constructor of the SunJSSE provider that takes a String object as a parameter. For example if the cryptographic provider is called SunPKCS11-NSS call new com.sun.net.ssl.internal.ssl.Provider("SunPKCS11-NSS"). A provider with the specified name must be one of the configured security providers.

Within a given Java process, SunJSSE can be used either in FIPS mode or in default mode, but not both at the same time. Once SunJSSE has been initialized, it is not possible to change the mode. This means that if one of the runtime configuration options is used (option 2 or 3), the configuration must take place before any SSL/TLS operation.

Note that only the specified configured provider will be used by the SunJSSE for any and all cryptographic operations. All other cryptographic providers including those included with the Java SE implementation will be ignored and not used.

Difference Between FIPS Mode and Default Mode

In FIPS mode, SunJSSE behaves in a way identical to default mode, except for the following differences.

In FIPS mode:

  • SunJSSE will perform all cryptographic operations using the cryptographic provider that was configured as described above. This includes symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.
  • If the configured cryptographic provider reports any error by throwing an exception, SunJSSE will abort the current operation and propagate the exception to the application.
  • If the configured cryptographic provider believes it had a critical error such as a self test failure per FIPS guidelines, it needs to remain in an error state until it is re-initialized. The application using the SunJSSE configured with the FIPS cryptographic module will have to be restarted. This ensures that the FIPS module will not allow critical errors to compromise security.
  • Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception.
  • The list of ciphersuites is limited to those that utilize appropriate algorithms. The current list of possible ciphersuites is given below. Any attempt to enable a ciphersuite not on the list will fail with an exception.

Ciphersuites Usable in FIPS Mode

The following is the current list of ciphersuites which can be used by SunJSSE in FIPS mode with their names and the id as assigned in the TLS protocol provided that the configured cryptographic FIPS module supports the necessary algorithms. Note that although SunJSSE uses the prefix SSL_ in the name of some of these ciphersuites, this is for compatibility with earlier versions of the specification only. In FIPS mode, SunJSSE will always use TLS 1.0 or later and implement the ciphersuites as required by those specifications.

SSL_RSA_WITH_3DES_EDE_CBC_SHA

0x000a

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

0x0016

TLS_RSA_WITH_AES_128_CBC_SHA

0x002f

TLS_DHE_DSS_WITH_AES_128_CBC_SHA

0x0032

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

0x0033

TLS_RSA_WITH_AES_256_CBC_SHA

0x0035

TLS_DHE_DSS_WITH_AES_256_CBC_SHA

0x0038

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

0x0039

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

0xC003

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

0xC004

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

0xC005

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

0xC008

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

0xC009

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

0xC00A

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

0xC00D

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

0xC00E

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA

0xC00F

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

0xC012

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

0xC013

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

0xC014

TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA

0xC017

TLS_ECDH_anon_WITH_AES_128_CBC_SHA

0xC018

TLS_ECDH_anon_WITH_AES_256_CBC_SHA

0xC019

Conclusion
When SunJSSE is configured in FIPS 140-2 compliant mode together with an appropriate FIPS 140 certified cryptographic provider, for example Network Security Services (NSS) in its FIPS mode, SunJSSE is FIPS 140 compliant.

Overview

The POODLE attack (which stands for "Padding Oracle On Downgraded Legacy Encryption") is a man-in-the-middle exploit which takes advantage of Internet and security software clients' fallback to SSL 3.0. This can be remedied by specifying the specific SSL Protocol to be used by the Tomcat Web Server Connector.

This patch should be done at the same time as Logjam TLS Vulnerability Fix.

You can access the Knowledgebase Article here: http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/305/55/workaround-for-tomcat-ssl-and-tls-logjam-vulnerability

 

Environment

FileCatalyst Workflow v4.9.4 and later.

FileCatalyst Webmail v4.9.4 and later.

Tomcat v7.0 and later.

 

Resolution

  1. Shutdown your Apache Tomcat service.
  2. Locate your Tomcat installation directory. For the purposes of this document, we will be using Windows Environment Paths. Typically it is installed in C:\Program Files\Apache Software Foundation\Tomcat 7.0\, this could be different for you.
  3. Navigate to the conf directory.
  4. Open the server.xml file in a text editor.
  5. Locate the connector named:

    <!-- Define a non-blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->

  6. Replace your current connector properties for sslEnabledProtocols with:

    sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"

  7. Remove the following:

    sslProtocol="TLS"

  8. An example of the edited connector definition:

    <!-- Define a non-blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->
    <!--FCWeb HTTPS Connector2-->
    <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"port="8443" minSpareThreads="5" maxSpareThreads="75"
    enableLookups="true" disableUploadTimeout="true"
    acceptCount="100" maxThreads="200"
    scheme="https" secure="true" SSLEnabled="true"
    keystoreFile="C:\Program Files\FileCatalyst Web Workflow/apache-tomcat/tomcat-ssl/.keystore" keystorePass="changeit"
    clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"/>

    <!-- Define a blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->
    <!--FCWeb HTTPS Connector1-->
    <Connector protocol="org.apache.coyote.http11.Http11Protocol"
    port="8443" minSpareThreads="5" maxSpareThreads="75"
    enableLookups="true" disableUploadTimeout="true"
    acceptCount="100" maxThreads="200"
    scheme="https" secure="true" SSLEnabled="true"
    keystoreFile="C:\Program Files\FileCatalyst Web Workflow/apache-tomcat/tomcat-ssl/.keystore"
    keystorePass="changeit"
    clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"/>

  9. Save the file and restart your Apache Tomcat Server.

Overview

Google has made changes in the default settings of Chrome version 42, released April 14th, 2015, that block Java applets from running in that browser.

This is part of Google’s announced strategy (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html) of eliminating all NPAPI (or NP-API) applet support by September 2015.

For FileCatalyst users, this means that right now you are going to be unable to run our Java applets, as well as everyone else, in your Chrome browsers. 

 

Environment

Google Chrome v42 and later for all Operating Systems.

 

Resolution

As of January 2016, the only web browsers that support Java Applets are:

  • Firefox
  • Internet Explorer v10 and later

FileCatalyst TransferAgent was released in March 2015 as an alternative solution to Java Applets running in Chrome and Firefox. We strongly recommend our users migrate to this application and if you would like more information on deployment and usage of TransferAgent please contact your FileCatalyst Sales Representative or submit a ticket in our FileCatalyst Support Portal.

As of February 2017, the only web browsers that support Java Applets are:

  • Safari
  • Internet Explorer v10 and later.

 

Overview

It's relatively easy for you to change your FileCatalyst Workflow site's default favico image, the icon that appears on browser tabs when people connect to your site. This image is hosted on your local web server, in the case of FileCatalyst Workflow, it is Apache Tomcat. 

Environment

FileCatalyst Workflow all versions.
Apache Tomcat v6.0, v7.0 and v8.0.

Resolution

To change this from the default favico.ico file, navigate to the Tomcat/webapps/ROOT folder and replace the existing favico.ico with your desired image.

Tomcat sets a default size of 32x32 pixels and we recommend staying with at least that size. Once the image has been replaced you will need to restart your Tomcat Web Server and clear your browser cache.

Overview

Every deployment of FileCatalyst Workflow or Webmail is shipped with an Internal FTP only FileCatalyst Server. The default path where the storage points to is within the Workflow or Webmail configuration folder. It is important that the FTP data and deployment configurations should be separated, for various reasons. 

The resolution method in this article can only be performed in Firefox or Internet Explorer as the usage of a Java Applet is required.



Environment

FileCatalyst Webmail v4.9 and later.

FileCatalyst Workflow v4.9 and later.

Firefox and Internet Explorer Web Browsers.

 

Resolution

  1. Log into FileCatalyst Workflow or Webmail as the Super Admin User. Be default, the account name is init.
  2. Navigate to the Modify Configuration button on the top menu bar.
  3. Click on the link for FC Servers / Script Execution, under the System Configuration section.
  4. Expand the Server details for the Internal Server and click Launch Admin Applet link. If launching Java applet is not possible, you can also download the Remote Admin application from our download site and connect to the Internal FC Server using the Remote Admin app.
  5. In another window, the FileCatalyst Remote Admin applet will load. Accept any Java security prompts that are displayed.
  6. When the applet loads, locate the doctera account and hit Edit.
  7. Under the Account Settings tab, enter the path to your Home Directory.
  8. Hit OK to apply the changes.
  9. Go back to the window that is logged in as the Super Admin User and click on Modify Configuration.
  10. Under the System Restart section, click the Restart System link.
Overview
FileCatalyst Workflow v4.9.9 introduced a new feature called Strict Security. This feature requires the use of the Administration account on the FileCatalyst Server to create and authenticate Virtual Users on the FileCatalyst Server. On Workflow deployments which have a large volume of activity the Server Remote Admin connections can multiply and remain open for long periods of time. These open connections hang and do not close properly. If you use Strict Security as part of your deployment the solution outlined in this article will be useful for you.

This article contains modifications that can be made to the Tomcat Web Server service. Please follow the steps in the resolution section to deploy the fix.

Environment
FileCatalyst Workflow v4.9.9 only.
FileCatalyst Server v3.7 only.
Apache Tomcat v7.0 and v8.0.

Resolution
The modification to the Tomcat Web service will require an addition of Java properties to the Java Additional properties section of the startup script. There are several ways to implement this change, we will cover our recommended method in this section.


  1. Shut down the Tomcat Web Server.
  2. Modifying the Java Additional properties:
    1. For Windows using our embedded Tomcat Installation. You can verify this in Services.msc, the service name will be listed as FileCatalyst Web Workflow or FileCatalyst Workflow.
      1. Using explorer navigate to the installation directory of FileCatalyst Workflow. Drill down into the bin directory inside the apache-tomcat folder. A sample path would be C:\FileCatalyst Web Workflow\apache-tomcat\bin
      2. Run the tomcat7fcwebw.exe application.
      3. Under the General tab make sure the Service Status is Stopped. If it is not hit the Stop button.
      4. Navigate to the Java tab.
      5. In the Java Options tab add the following on a new line:

        -Dunlimited.fc.server.api.globalFCAdminExpiry=1440

      6. Hit Apply to save your changes.

    2. In Windows using the standalone Tomcat Installation. You can verify this in Services.msc, the service name will be listed as Apache Tomcat 7.0 or Apache Tomcat 8.0.
      1. Using explorer navigate to the installation directory of Apache Tomcat. Drill down into the bin directory. A sample path would be C:\Tomcat 8.0\bin
        1. Run the tomcat7w.exe or tomcat8w.exe application.
        2. Under the General tab make sure the Service Status is Stopped. If it is not hit the Stop button.
        3. Navigate to the Java tab.
        4. In the Java Options tab add the following on a new line:

          -Dunlimited.fc.server.api.globalFCAdminExpiry=1440

        5. Hit Apply to save your changes.

    3. For all Linux based deployments, the Java Additional property needs to be added to the catalina.sh file.
      1. In a Terminal window, navigate to the Tomcat directory. Drill into the bin folder.
      2. Using vi or nano open the catalina.sh file.
      3. Locate the export JAVA_OPTS line and add the following property, if this line does not exist then you will need to add the full line:

        Property: 
        -Dunlimited.fc.server.api.globalFCAdminExpiry=1440
        Example:
        export JAVA_OPTS="-server -XX:MaxPermSize=256m -Xmx1200m -Xms1200m -Dfile.encoding=utf-8 -Dunlimited.fc.server.api.globalFCAdminExpiry=1440"

      4. Save your changes and close the file.

  3. Once the property is added, the Tomcat Web Server can be started.
  4. Log into Workflow using the Super Admin Account.
  5. Click on About FileCatalyst button on the top menu bar.
  6. Scroll down the page to Additional Java Info and in this subsection, you should be able to locate the parameter unlimited.fc.server.api.globalFCAdminExpiry if the modifications in step 2 were successful. You should see the following:


    FileCatalyst Workflow Settings

Overview

This is a guide on how to reset your Workflow template and create an empty background for your login page. When customizing your login page for FileCatalyst Workflow, you may notice that your fonts don't match or that they are different sizes. This occurs when the templates have been customized and certain fields have changed from the defaults. In this case, it is a good idea to reset your template.

 

Environment

FileCatalyst Workflow v4.7 and later.

FileCatalyst Webmail v4.7 and later.

 

Resolution

Reset Template:

  1. Login to FileCatalyst Workflow or Webmail as the Super Admin.
  2. Click on Modify Configuration on the top menu bar.
  3. Click on the Change Template link in the Template Setup section.
  4. Select FC Modern template from the drop down list and hit Change Template.
  5. Log out and clear your cache in your web browser. Make sure this works first.

Create a Blank White Background:

  1. Login to FileCatalyst Workflow or Webmail as the SuperUser.
  2. Click on Modify Configuration on the top menu bar.
  3. Click on the Common Style Sheet link in the Template Setup section.
  4. Edit the line before input { and after /*********************/ by inserting the following line of code:

    #headerLogo

    {
    background:white !important;
    }

  5. Hit the Save button and log out.
  6. Clear your web browser cache to make sure the settings were applied.

Overview:  

When trying to create a new job in FileCatalyst Workflow after an upgrade or a fresh install an error is generated:

HTTP Status 500 - Unable to compile class for JSP:
type Exception report
message Unable to compile class for JSP:
description The server encountered an internal error that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: [244] in the generated java file: [/fftdata/apache-tomcat-8.0.41/work/Catalina/localhost/ROOT/org/apache/jsp/jsp/editPrintJob_jsp.java]

The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit.

Stacktrace found in the Workflow System logs:

org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:198)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:457)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:585)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:363)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
org.apache.struts.action.ActionServlet.processActionForward(Unknown Source)
unlimited.core.g.h.process(Unknown Source)
unlimited.core.g.h.doGet(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
unlimited.core.b.ai.doFilter(Unknown Source)
note The full stack trace of the root cause is available in the Apache Tomcat/8.0.41 logs.

Environment: 

FileCatalyst Workflow v4.9.6 and later.

Apache Tomcat v7.0 and v8.0 only.

Resolution: 

Locate the file /<Tomcat_Home>/conf/web.xml and search the file for JspServlet. This should return an xml node of <servlet> containing some <init-param> values. You will need to add an additional <init-param> the same as the below:

<init-param>
<param-name>mappedfile</param-name>
<param-value>false</param-value>
</init-param>


The resulting block of the web.xml file, once you have inserted the above, should look like the code below:

<servlet>

<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>mappedfile</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet> 

Once the changes are made, save the file and restart the Tomcat service.

For the full article on this solution please go to https://www.assetbank.co.uk/support/documentation/knowledge-base/byte-limit-exceeded-error/

Overview

After upgrading any FileCatalyst TransferAgent Deployment, such as FileCatalyst Link or FileCatalyst Workflow, the client side previously connected using FileCatalyst TransferAgent Client Application may have issues reconnecting to the source server.  The local storage on the browser stores information about the TransferAgent deployment and caches these elements for future reference. This information gets populated into the Web Browsers local storage when a connection is Allowed through the Access Request Dialog. 

If a user chooses to Always Allow access to a site, the access information for the TransferAgent Deployment gets stored in the configuration file as a white listed Origin Policy. If any of the access information has changed or a connection could not be established the user will be presented with a message in the browser of:

A connection could not be established to one or more remote FileCatalyst Servers. Since no transfer is possible, the UI has been disabled. To retry later, simply refresh this page. If the problem persists, contact the organization managing this web application.

Environment

FileCatalyst TransferAgent Client Side Application v3.5 and later.

Resolution:

The following method applies to all browsers on MAC OSX, Windows and Linux Environments. To clear the Web Browsers local storage follow these steps:

  1. Connect to a TransferAgent Deployment (FileCatalyst Link or Workflow) using a browser.
  2. Right-click on the page select Inspect Element or Inspect. This may be different between browsers however there will be a similar option available.
  3. Navigate to the Console tab.
  4. Enter the following command in the console window and press enter to verify there is data stored in the browser's local storage.  Note, the location of the console text prompt varies by browser.

    localStorage

    This command will return a similar message to the following if a connection has been made:


    Storage {filecatalystLocalConfig: "{"agentInstalled":true,"launchAutomatically":true,…alse","markAlwaysLaunch":true,"objectStamp":true}", filecatalystTAPortValue: "12680", taParameters: "[{"name":"http.port","value":12680,"dataType":"INTEGER"}]", length: 3}

  5. Clear your local storage from the Console Tab using:

    localStorage.clear()

    The console should return a message of undefined. This indicates that all elements in the local storage have been cleared.


  6. Reconnect to the TransferAgent Deployment source site.
Overview

According to the knowledge base article here, "A computer in the FRITZ!Box home network (192.168.178.29) cannot access a web server on the same home network because the DNS request for this web server (my_domain.de) is answered with an IP address in the same home network (192.168.178.20)."  


"For security reasons, the FRITZ!Box suppresses DNS responses that refer to IP addresses in its own home network. This is a security function of the FRITZ!Box to protect against what are known as "DNS rebinding attacks".

FileCatalyst TransferAgent is a client application that spins up an internal web server which can be accessed by the URL (https://localhost.filecatalyst.net) that resolves to the loopback address. When we try to resolve localhost.filecatalyst.net the FRITZ!Box will return "DNS timed out" or "DNS request timed out". This specific domain is registered to resolve to 127.0.0.1. 

Environment

FileCatalyst TransferAgent v3.5 and later.


Fritz!Box Gateway

Resolution

Configure the FRITZ!Box according to the instructions from the above article to allow an exception for the loopback address. (https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-base/publication/show/663_No-DNS-resolution-of-private-IP-addresses/)


Overview

Every instance that is deployed on Amazon EC2 must have Firewall and specific ports configured. By default, most of the ports that are needed are not open for TCP or UDP connections. The FileCatalyst Server, FileCatalyst Workflow, and FileCatalyst Webmail deployments all need to have their respective ports opened for connectivity and data transfer.

This article will walk you through a typical security group setup for an Amazon EC2 instance.

The default ports for FileCatalyst Direct are:

  • Port 21 for TCP.
    This is used as the communication channel. Port 21 is a default specified in the FileCatalyst Server and is not secure. You can change this as long as both FileCatalyst Server and Client Applications are using the same port.

  • Port 22 for TCP.
    This port is used for SSH connections.

  • Port 990 for TCP.
    This Port is secured over SSL and is also used as the communication channel. The default value of 990 can also be changed in the FileCatalyst Server Remote Admin Application.

  • Port range 8000-8999 for TCP and UDP.
    Some firewalls and NAT devices require setting up 2 separate rules and others allow you to specify TCP and UDP. These ports are used to transfer the Data to and from the FileCatalyst Server and is commonly referred to as the Data Channel. 
  • Port 12400 for TCP.
    This is the Remote Admin Port. This port is exclusive to the FileCatalyst Server Remote Admin Application.

  • Port 12480 for TCP.
    The internal Web Server uses this port to broadcast all communications. The Admin Applet, Link, and Servlet are hosted from this Web Server.

The default ports for FileCatalyst Workflow/Webmail are:

  • Port 80 for TCP.
    HTTP inbound connections are accepted by the Tomcat Web Server on this port. 
  • Port 443 for TCP.
    HTTPS connections and secured communication to the Tomcat Web Server use this port. 

 

Environment

FileCatalyst Direct Suite v3.5 and later.

FileCatalyst Workflow v4.9.5 and later.

FileCatalyst Webmail v4.9.4 and later.

Linux and Windows Environments.

 

Resolution

 

  1. Log into your AWS Console. Click on Security Groups on the left-hand side.



  2. Click on the Create Security Group button, see the attached illustration below.



  3. Specify the Security Group Name and Description.



  4. Hit Add Rule to add your first port. Here is an example of adding a single port 21 on TCP for a connection originating from anywhere.



  5. This is an example of how to add a range of ports. We have added the FileCatalyst Data Port range for both TCP and UDP.




  6. Once all your Firewall Rules have been added, hit the Create button.

  7. Using the Security Group Name, you can add this of Firewall Rules to your EC2 Instance.
Note:

Quick Start Guide: How to add External File System Storage on the FileCatalyst Server

Overview

On a default landing page of Filecatalyst Workflow, there are a few elements that can be removed if you do not want them exposed to your clients. These changes can be made through some small Custom Style Sheet (CSS) tweaks and through the adjustment of the Language File. The elements that this article will edit are:

  • First Time Users? Register Here!
  • Forgot your password? Get your password here
  • Save password on this computer
  • Public Access (button)
  • Want to download files? Enter tracking number here

Environment

FileCatalyst Workflow v4.8 and later up to v4.9.

Resolution

  1. Edit the Common Style Sheet:

    1. Log into FileCatalyst Workflow as the Super Admin User. By default this account is Init.
    2. Click on Modify Configuration in the top menu bar.
    3. Access the link for Common Style Sheet under the Template Setup section.
    4. Scroll down to the bottom of the page and insert the following piece of code above /* uploadFiles.jsp configuration */

      #registerLink{display: none;}
      #getPasswordLink{display: none;}
      #setCookie{display: none;}

    5. Hit Save.

  2. Modify the Language File:

    1. The following is a list that contains default values for the respective elements available on the logon page of Workflow:
      • logon.ForgotPasswordButton=Get your password here

      • logon.ForgotPasswordMessage=Forgot your password?

      • logon.RegisterButton=Register Here!

      • logon.RegisterMessage=First time user?

      • logon.SetCookieMessage=Save password on this computer

      • logon.TrackingNumberMessage=Want to download files?

      • logon.DownloadFilesButton=Enter tracking number here

    2. To completely remove all of the buttons and links on the landing page search for each of the properties below and delete all the text after the equal sign (=):

      • logon.ForgotPasswordButton=

      • logon.ForgotPasswordMessage=

      • logon.RegisterButton=
      • logon.RegisterMessage= 

      • logon.SetCookieMessage= 

      • logon.TrackingNumberMessage= 

      • logon.DownloadFilesButton=

    3. Hit Save to apply the changes.

  3. Removing the Public Access button.

    1. From the Modify Configuration page select the General Settings link under the System Configuration section.
    2. Scroll down to Logon Settings section.
    3. Uncheck the Allow Anonymous Access to remove the Public Access button. 
    4. Hit Save.

  4.  Log out as the Super Admin User and clear your browser cache. Your changes will appear once the web browser caches the new logon page with updated changes.

 

Overview

On a default landing page of Filecatalyst Workflow, there are a few elements that can be removed if you do not want them exposed to your clients. These changes can be made through some small Custom Style Sheet (CSS) tweaks. 

If you are using an older version of Workflow (older than 5.0) please use the following article: https://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/324/9/hiding-elements-of-the-workflow-logon-page

The elements that this article will edit are:

Environment

FileCatalyst Workflow v5.0 and newer.

Resolution

  1. First Time Users? Register Here!
    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. Click on Modify Configuration in the top menu bar.
    3. Navigate to the General Settings section.
    4. Scroll down to the User Settings section and uncheck Allow Users to Self Register.
    5. Hit Save.

  2. Forgot Your Password
    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. Click on Modify Configuration in the top menu bar.
    3. Navigate to the General Settings section.
    4. Scroll down to the Logon Settings section and uncheck show reset password link on the login page.

    5. Hit Save to apply the changes.

  3. Removing the Public Access Button.

    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. From the Modify Configuration page select the General Settings link under the System Configuration section.
    3. Scroll down to Logon Settings section.
    4. Uncheck the Allow Anonymous Access to remove the Public Access button. 

    5. Hit Save.
  4. Want to download files? Enter tracking number here
    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. From the Modify Configuration page select the General Settings link under the System Configuration section.
    3. Navigate to the Edit Language File page using the link under Content Configuration.
    4. Search for the following properties and remove the contents after the equal sign ("=") leaving the parameters blank:

      • logon.DownloadFilesButton=
      • logon.TrackingNumberMessage=

    5. Hit Save.
  5. Save password on this computer
    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. From the Modify Configuration page select the General Settings link under the System Configuration section.
    3. Navigate to the Edit Language File page using the link under Content Configuration.
    4. Search for the following property and remove the contents after the equal sign ("=") leaving the parameter blank:

      • logon.SetCookieMessage=

    5. Hit Save.
    6. Under the Content Configuration select HTML Headers and select the link to modify the Logon page.
    7. Add the following content in the text box and hit Save to apply the changes:

      <style>
      #setCookie {
        display:none;
      }
      </style>

  6. Removing Helper Link Box
    This is located under the login credentials section and contains link to forgot your password, download files and user registration.

    To remove this whole box use the following steps:
    1. Log into FileCatalyst Workflow as the Super Admin User. By default, this account is called init.
    2. Under the Content Configuration select HTML Headers and select the link to modify the Logon page. These links are located on the Modify Configuration page.
    3. Add the following content in the text box and hit Save to apply the changes:

      <style>
      #helperLinks.card {
        display:none;
      }

      </style>

Overview

In Tomcat 9, the core engine starts up faster than previous Tomcat versions and the web front end is active. This means that the HTTP Connector is open and listening to requests from your web browser.

Our application which is a container in the application is still starting and as a result, the end user is presented with a HTTP 500 error.

Sample Stack Trace:

org.apache.catalina.core.StandardHostValve.invoke Exception Processing /workflow/
java.lang.SecurityException: AuthConfigFactory error: java.lang.reflect.InvocationTargetException
     at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85)
     at org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1239)
     at org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1232)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
     at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
     at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
     at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
     at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:791)
     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
     at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
     at java.lang.Thread.run(Unknown Source)


Error observed in the browser:



Environment
FileCatalyst Workflow v5.0.3

Tomcat v9.0

Resolution
This bug resides deeper in the Tomcat code which can not be fixed by FileCatalyst. We have escalated this up to the development team of Apache.

The resolution to this issue is to wait 1-2 minutes and Workflow will start up and synchronize with Tomcat 9.0.

Overview

In this article, we will address the Logjam Vulnerability and simultaneously harden the Tomcat Web Server to prevent a POODLE attack. The deployment of these patches should be done together.

A full technical brief is available at https://weakdh.org/. This site also contains details on the Logjam Vulnerability and what weaknesses are exploited.

 

You can access the Knowledgebase Article for the POODLE Fix here: http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/306/55/how-to-deploy-the-sslv3-poodle-fix-for-tomcat

We recommend that you go through this article first. 

 

Environment

FileCatalyst Workflow v4.9.4 and later.

FileCatalyst Webmail v4.9.4 and later.

Tomcat v7.0 and later.

 

Resolution

  1. Shutdown your Apache Tomcat service.
  2. Locate your Tomcat installation directory. For the purposes of this document, we will be using Windows Environment Paths. Typically it is installed in C:\Program Files\Apache Software Foundation\Tomcat 7.0\, this could be different for you.
  3. Navigate to the conf directory.
  4. Open the server.xml file in a text editor.
  5. Locate the connector named:

    <!-- Define a non-blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->

  6. Add the following property at the end of the connectors before “/>” to <!--FCWeb HTTPS Connector1--> and <!--FCWeb HTTPS Connector1 -->:

    ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"

  7. Your editted connectors should look like:

    <!-- Define a non-blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->
    <!--FCWeb HTTPS Connector2-->
    <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
    port="8443" minSpareThreads="5" maxSpareThreads="75"
    enableLookups="true" disableUploadTimeout="true"
    acceptCount="100" maxThreads="200"
    scheme="https" secure="true" SSLEnabled="true"
    keystoreFile="C:\Program Files\FileCatalyst Web Workflow/apache-tomcat/tomcat-ssl/.keystore"
    keystorePass="changeit"
    clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
    ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"/>

    <!-- Define a blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 -->
    <!--FCWeb HTTPS Connector1-->
    <Connector protocol="org.apache.coyote.http11.Http11Protocol"
    port="8443" minSpareThreads="5" maxSpareThreads="75"
    enableLookups="true" disableUploadTimeout="true"
    acceptCount="100" maxThreads="200"
    scheme="https" secure="true" SSLEnabled="true"
    keystoreFile="C:\Program Files\FileCatalyst Web Workflow/apache-tomcat/tomcat-ssl/.keystore"
    keystorePass="changeit"
    clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"  ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA" />

  8. Save the file and restart your Apache Tomcat Server.

Overview

FileCatalyst Webmail and Workflow uses Apache Tomcat Server that does require Java to be installed on the machine for the Web Server to access the Java Virtual Machine. Tomcat always looks for the environment variable JRE_HOME that points to the location of Java in the system before the FileCatalyst Webmail or Workflow WAR file is deployed.

In a Linux Operating System, the variable JRE_HOME often is not automatically set or updated after the Java is installed. This issue occurs more frequently when Java was installed through simple extracting files from the installer package or using the TAR file obtained from an Oracle repository.

 

Environment

FileCatalyst Workflow v4.7 and later.

FileCatalyst Webmail v4.7 and later.

Linux Environment.

Oracle Java 7 and later.

 

Resolution

  1. Check if the Java Environment Variables are properly set.
    1. Open a Terminal and run:

      java -version

      If this command returns an error “Command not found” or a similar message, this indicates the PATH variable is not properly set.

  2. To have a more permanent solution that will force the operating system to remember these variables after any restart, the /etc/environment file will need to be edited.
    1. Open the file (/etc/environment) using a text editor such as vi. The file has to be edited using elevated user permissions.
    2. The file may already contain an entry similar to:

      PATH="/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin"

      We will need to add the path to the Java bin directory to this list. Assuming your Java RE is located in /opt/java/jre1.8_91/, your modified PATH will look like:

      PATH="/opt/java/jre1.8_91/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin"

    3. Then add a new line with new variable:

      JRE_HOME="/opt/java/jre1.8_91/"

    4. Save the changes and close the file.

  3. Some Linux distributions recommend the addition modified variables to the /etc/profile file.
    1. Open the file /etc/profile using a text editor such as vi. The file has to be edited using elevated user permissions. Add the following lines at the end of the file:

      PATH=/opt/java/jre1.8_91/:$PATH
      JRE_HOME=/opt/java/jre1.8_91/
      export PATH
      export JRE_HOME

    2. Save the changes and close the file. Changes in profile will take effect after the machine is restarted.

Overview

This article describes how to upgrade an existing FileCatalyst Workflow installation to the latest release version. It is assumed that Workflow is deployed on Apache Tomcat. Please note if after your upgrade your Language File entries do not show, you will need to restart the Tomcat Web Server.

Environment

FileCatalyst Workflow v4.7 and later.

Resolution

Download Update:

You will need the latest WAR file from our website http://filecatalyst.software.

Contact your FileCatalyst Sales Representative in order to obtain a username and password. Locate and download the FileCatalyst Workflow application called fcwebworkflow_war.zip.

Upgrade Instructions:

  1. Log in as Super Admin to FileCatalyst Workflow. Click on the About FileCatalyst icon and make a note of the path to your Configuration Folder. Look for it in the field named Configuration Path.
  2. Stop Tomcat service.
  3. Make a backup copy of the Configuration Folder.
  4. Make a backup of MySQL Database, using a MySQL dump tool, or by any other method that you find convenient.
  5. Backup workflow.war and /workflow folder to a location outside of Tomcat. This folder and WAR file are located in /<Tomcat-Home>/webapps/
  6. Delete the workflow.war and /workflow folder from /<Tomcat-Home>/webapps/.
  7. Unzip the workflow.war from the fcwebworkflow_war.zip file and place it in /<Tomcat-Home>/webapps/.
  8. Delete the /<Tomcat-Home>/work/Catalina directory.
  9. Stop the service FileCatalyst Workflow.
  10. Modify the Tomcat web.xml file using this guide to prevent JSP Servlet Errors.
  11. Start Tomcat service. Tomcat will re-deploy the new WAR file and make a new directory /<Tomcat-Home>/webapps/workflow/ automatically.
  12. Open a web browser of your choice and access FileCatalyst Workflow as usual. If you are on the local machine, go to http://localhost/workflow or http://localhost:8080/workflow. (Assuming the Tomcat default port 8080, otherwise substitute an appropriate port)
  13. Log in with username Init with the password aaaaa.
  14. Click on the button for Existing or Custom Configuration Folder.
  15. Enter the path you noted in Step 1 from the Configuration Path.
  16. FileCatalyst Workflow will re-initialize and all your previous settings will be imported into the new deployment.

Roll-Back Guide

  1. Stop the Tomcat service.
  2. Delete the /<Tomcat-Home>/webapps/workflow/ directory.
  3. Delete the /<Tomcat-Home>/webapps/workflow.war file.
  4. Delete the /<Tomcat-Home>/work/Catalina directory.
  5. Place the backup version of workflow.war into /<Tomcat-Home>/webapps/ folder.
  6. You can either backup the existing configuration folder or delete it.
  7. Place the previously backup Configuration Folder in the original location.
  8. Start the Tomcat service. Tomcat will redeploy the WAR file and make a new directory /<Tomcat-Home>/webapps/workflow/ automatically.
  9. Open a web browser of your choice and access FileCatalyst Workflow as usual. If you are on the local machine, go to http://localhost/workflow or http://localhost:8080/workflow. (Assuming the Tomcat default port 8080, otherwise substitute an appropriate port)
  10. Log in with username Init with the password aaaaa.
  11. Click on the button for Existing or Custom Configuration folder.
  12. Enter the path you noted in Step 1 from the Configuration Path.
  13. FileCatalyst Workflow will re-initialize and all your previous settings will be imported into the new deployment.

Overview

As of May 2016, FileCatalyst Webmail will be discontinued and no further development will be done on the product. All maintenance and features will be released in the FileCatalyst Webmail suite. 

For any Windows users that have installed FileCatalyst Webmail using the self-executable installer, it is not available with this release. This article can still be referenced in your upgrade as the procedure is very similar. 

Environment

FileCatalyst Webmail v4.7 and later.

Resolution

Download Update:

You will need the latest WAR file from our website http://filecatalyst.software/fc-webmail-download.html.

Contact your FileCatalyst Sales Representative in order to obtain a username and password for the download portal. Locate and download the ZIP archive of FileCatalyst Webmail application called fcwebmail_war.ziphttp://filecatalyst.software/download/filesFCWeb/current/fcwebmail_war.zip

For the procedure below, when the path /<Tomcat-Home>/ is used, it refers to the path where the Tomcat Web Server resides. Windows users that have deployed FileCatalyst Webmail using the self-executable installer should note that the path to the Tomcat Home is C:\Program Files\FileCatalyst Webmail\apache-tomcat\ by default.

Upgrade Instructions:

  1. Login as Super Admin to FileCatalyst Webmail. Click on the About FileCatalyst icon and make a note of the path to your Configuration Folder. Look for it in the field named Configuration Path.
  2. Stop Tomcat service or FileCatalyst Webmail service if you are using the Windows self-executable installer.
  3. Make a backup copy of the Configuration Folder.
  4. Make a backup of MySQL Database, using a MySQL dump tool, or by any other method that you find convenient.
  5. Backup fcweb.war and /fcweb folder to a location outside of Tomcat. This folder and WAR file are located in /<Tomcat-Home>/webapps/. A sample path to a location using the Windows self-executable installer is C:\Program Files\FileCatalyst Webmail\apache-tomcat\webapps\.
  6. Delete the fcweb.war and /fcweb folder from /<Tomcat-Home>/webapps/.
  7. Unzip the fcweb.war from the fcwebmail_war.zip file and place it in /<Tomcat-Home>/webapps/.
  8. Delete the /<Tomcat-Home>/work/Catalina directory. This step is extremely important, do not continue to the next step without confirming the contents of this folder have been erased.
  9. Start Tomcat service or FileCatalyst Webmail service. Tomcat will re-deploy the new WAR file and make a new directory /<Tomcat-Home>/webapps/fcweb/ automatically.
  10. Open a web browser of your choice and access FileCatalyst Webmail as usual. If you are on the local machine, go to http://localhost/fcweb or http://localhost:8080/fcweb. (Assuming the Tomcat default port 8080, otherwise substitute an appropriate port)
  11. Login with username Init with the password aaaaa.
  12. Click on the button for Existing or Custom Configuration Folder.
  13. Enter the path you noted in Step 1 from the Configuration Path.
  14. FileCatalyst Webmail will re-initialize and all your previous settings will be imported into the new deployment.

Roll-Back Guide

  1. Stop the Tomcat service FileCatalyst Webmail service if you are using the Windows self-executable installer.
  2. Delete the /<Tomcat-Home>/webapps/fcweb/ directory.
  3. Delete the /<Tomcat-Home>/webapps/fcweb.war file.
  4. Delete the /<Tomcat-Home>/work/Catalina directory.
  5. Place the backup version of fcweb.war into /<Tomcat-Home>/webapps/ folder.
  6. You can either backup the existing configuration folder or delete it.
  7. Place the previously backup Configuration Folder in the original location.
  8. Start the Tomcat service FileCatalyst Webmail service . Tomcat will redeploy the WAR file and make a new directory /<Tomcat-Home>/webapps/fcweb/ automatically.
  9. Open a web browser of your choice and access FileCatalyst fcweb as usual. If you are on the local machine, go to http://localhost/fcweb or http://localhost:8080/fcweb. (Assuming the Tomcat default port 8080, otherwise substitute an appropriate port)
  10. Login with username Init with the password aaaaa.
  11. Click on the button for Existing or Custom Configuration folder.
  12. Enter the path you noted in Step 1 from the Configuration Path.
  13. FileCatalyst Webmail will re-initialize and all your previous settings will be imported into the new deployment.

Overview

If an existing install of FileCatalyst Workflow and Webmail needs to be moved/migrated/changed to an install on a new machine and the existing settings need to be maintained. This guide will provide instructions on how to backup your settings and export them to a new machine. Please note if after your upgrade your Language File entries do not show, you will need to restart the Tomcat Web Server.


Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.
 

Resolution

  1. Backup configuration and settings.

    1. Database
      1. If you are using an Internal HSQL DB, this will be copied in the next set of steps.
      2. If you utilize a MySQL DB, it is recommended that you use MySQL Workbench or a MySQL command line to take a full backup of the database.

    2. Workflow or Webmail Configuration.
      1. Log into the FileCatalyst Workflow or Webmail deployment as the Super Admin User.
      2. Click on About FileCatalyst on the top menu bar.
      3. The path listed under Configuration Path will be the location of your deployment.
      4. Copy this folder to the new machine.

    3. Web Server Settings
      1. Shut down the Tomcat Web Server service.
      2. Navigate to the Tomcat installation folder and copy the /<path to Tomcat>/conf/ folder to the new deployment.
      3. Move into the /<path to Tomcat/webapps/ROOT/, copy the contents of this folder to your new deployment. This folder will maintain your redirectors if they have been setup.

    4. SSL Certificated (optional)
      1. Backup your SSL Certificate Directory to your new machine.
      2. Open the <path to Tomcat>/conf/server.xml in a text editor.
      3. Search for the element in your SSL connector that has the following:

        keystoreFile="c:\tomcat-ssl\.keystore"

        The path after the equal sign will point to the SSL directory.

    5. Data
      1. If a FileCatalyst Direct Acceleration Server is being used then you can skip this step as the FileCatalyst Server contains the path to the storage device.
      2. If you are using the Internal FTP only FileCatalyst Server storage you can get the path to that from the Remote Admin Applet located inside the FC Servers / Script Execution page.
        Copying the contents of your whole FTP directory could take a while depending on the size of the directory.

  2. Install Log Rotation for Tomcat on the new server (only if you are using log rotation) using this guide: 

    http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/29/0/rotating-stdout-logfiles-with-tomcat

  3. Migration

    1. Tomcat Web Server
      1. Install Tomcat 9.0.X new machine. 
      2. Restore the backup of the Root folder back into /<path to Tomcat/webapps/ROOT/.
      3. Edit the <path to Tomcat>/conf/server.xml with the connector information from your old server.xml file.
      4. If you have SSL Certificates you can import them using Step 7 from this guide and your backed up SSL Certificate files:

        http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/295/66/tomcat-csr-and-ssl-certificate-installation-and-renewal

    2. MySQL DB
      1. Install MySQL Server and Workbench if you used this tool to manage your database.
      2. Restore your old database using Workbench or MySQL command line tools.

    3. FileCatalyst Workflow or Webmail
      1. Download the latest version of workflow.war or fcweb.war from our download page.
      2. Copy this WAR file into the /<path to Tomcat/webapps/ directory.
      3. Modify the Tomcat web.xml file using this guide to prevent JSP Servlet Errors.
      4. Start the Tomcat Web Server Service.
      5. Access the Workflow or Webmail landing page. You should see a default demo landing page.
      6. Login using init and the password aaaaa.
      7. When prompted choose a Custom Directory to use an Existing Setup.
      8. Specify the path to the configuration for folder and hit Change Folder and Restart.
      9. From the Modify Configuration menu, click on the Licenses link and provide your Sales Representative with the request string. Enter the License key here and hit Save.
      10. Under the System Restart section hit the Restart System link. This will remove the Demo Banner.

Note:

  • Make sure all your NAT devices and Ports point to this machine.
Overview

To cancel your FileCatalyst Spaces subscription you will need access to your deployment as the Super Admin. If you have forgotten your username or password please submit a ticket to [email protected] with your account name, subscription ID and company billing address so that we can verify your account. To proceed with the cancellation process use the steps below.

Resolution

  1. Log into your FileCatalyst Spaces deployment as the Super Admin.

  2. From the top menu bar navigate to the Modify Configuration page.

  3. Under the System Configuration section select the Manage your subscription link. 

  4. From the tab list select Subscription Details.

  5. At the bottom of the page, you will see the Cancel Subscription button.


Overview

If you have Workflow deployed on Tomcat 9 and have usernames that contain spaces the clients will experience authentication failures.

This was a result of a Tomcat 9 change and can be resolved by adding the following line to the context.xml.

Environment


FileCatlayst Workflow v4.9.9 and older
Tomcat 9

Resolution

1) Stop the Tomcat service.


2) Locate the context.xml and add the following lines before the closing tag:

<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>

The context.xml file is located in the conf folder within Tomcat i.e. C:\Tomcat 9.0\conf\



3) Start Tomcat service.

Overview

When a connection comes into the Tomcat Web Server it can be directed to use an HTTPS Socket rather than a non-secure HTTP Socket. Tomcat allows a configuration where HTTPS can be enforced only by the Workflow or Webmail deployment or a server wide rule can be enforced.

This article will discuss the how to redirect connections to HTTPS using the Tomcat Web Server. It is not necessary to use a server wide rule and an application wide rule. 


Environment

FileCatalyst Workflow v4.9 and later.

FileCatalyst Webmail v4.9 and later.

Tomcat Web Server v7.0 and later.

 

Resolution

Server Wide Rule:

  1. Shutdown the Tomcat Web Server Service.
  2. Locate the web.xml file which is located in /<Tomcat Root>/conf/web.xml folder.
  3. Edit the file web.xml and add the following to the end of the file just before the </web-app> tag:

    <!-- redirect all traffic to the SSL port -->
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>Automatic SLL Forwarding</web-resource-name>
        <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>

  4. Save the file and restart the Tomcat Web Server for the changes to take effect.

Application Wide Rule:

  1. Shutdown the Tomcat Web Server Service.
  2. Locate the web.xml file for the Webmail or Workflow deployment which is located in /<Tomcat Root>/webapps/workflow/WEB-INF/web.xml or /<Tomcat Root>/webapps/fcweb/WEB-INF/web.xml.
  3. Edit the file web.xml and add the following to the end of the file just before the </web-app> tag:

    <security-constraint>
       <web-resource-collection>
        <web-resource-name>Protected Context</web-resource-name>
          <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <!-- auth-constraint goes here if you requre authentication -->
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>

  4. Save the file and restart the Tomcat Web Server for the changes to take effect.

Set Redirect Port for Tomcat:

Any HTTP connections to your FileCatalyst Webmail or Workflow deployment will be redirected to HTTPS instead using the Connector redirect port set in server.xml.
Default installations of Tomcat have this redirectPort set to 8443. If this is not the HTTPS port you are using, you will need to update server.xml accordingly. 

Note:

If you modify the application specific web.xml, you will have to remember to re-insert this code every time you upgrade, because the upgrade procedure requires deleting the entire webapp folder including the WEB-INF/web.xml file.

 

Overview

The following instructions are provided as a guide to installing Java onto a system for use with FileCatalyst the Java API, SDK and CLI which do not have an embedded Java Runtime Environment and require one to run.

On Windows, Linux and OSX, many FileCatalyst v3.8 products (HotFolder, Server, TransferAgent and Central) do not need Java installed separately as a JRE (Amazon Corretto Java 8) is already pre-packaged in these applications.

Implementation notes: 

Environment

FileCatalyst Direct Suite v3.8

FileCatalyst Server

FileCatalyst HotFolder

FileCatalyst Central

FileCatalyst API/SDK

FileCatalyst Command Line (CLI)


Operating Systems:

Windows, MacOSX and Linux

Resolution

To access our Download Portal, please log in to your Support Portal Account and select the Get Download Credentials widget. If you do not have access to the Get Download Credentials widget, submit a ticket to Support to enable this feature.

Windows:

  1. Download Windows x64 Java 8u242
  2. Unzip Java bundle, place the tar bundle under C:\Program Files\Java\ (administrative privileges will be required)
  3. Open a command prompt and navigate to C:\Program Files\Java\bin\
  4. Test the Java version:

    C:\Program Files\Java\bin>.\java -version
    openjdk version "1.8.0_242"
    OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
    OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)

  5. Additional configuration may be required to:
    1. Modify the application script to use this specific Java version.
    2. Have the system path pointing to this location for the system to pick it up.

Linux:

  1. Download Linux x64 Java 8u242 JRE
  2. Execute the following commands from a terminal window:

    [email protected]:~$ sudo mkdir /opt/java
    [email protected]:~$ sudo cp ./amazon-corretto-8.242.08.1-linux-x64.tar.gz /opt/java/
    [email protected]:~$ cd /opt/java/
    [email protected]:/opt/java$ sudo tar -xvf amazon-corretto-8.242.08.1-linux-x64.tar.gz
    [email protected]:/opt/java$ sudo chown -R root:root /opt/java/amazon-corretto-8.242.08.1-linux-x64


  3. Test to ensure Java is installed:

    [email protected]:/opt/java$ /opt/java/amazon-corretto-8.242.08.1-linux-x64/bin/java -version
    openjdk version "1.8.0_242"
    OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
    OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)

  4. Additional configuration may be required to:
    1. Modify the application script to use this specific Java version.
    2. Have the system path pointing to this location for the system to pick it up.

MacOSX:

  1. Download OSX x64 Java 8u242
  2. Execute the following commands from a terminal window (from the directory where the package has been placed):

    sudo tar -xvf ./amazon-corretto-8.242.08.1-1-macosx-x64.tar.gz
    sudo chown -R root:wheel amazon-corretto-8.242.08.1-1-macosx-x64/
    sudo mv ./amazon-corretto-8.242.08.1-1-macosx-x64 /Library/Java/JavaVirtualMachines/
    cd /Library/Java/JavaVirtualMachines/


  3. Test the Java version:

    /Library/Java/JavaVirtualMachines/amazon-corretto-8.242.08.1-1-macosx-x64/Contents/Home/bin/java -version
    openjdk version "1.8.0_242"
    OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
    OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)

  4. Additional configuration may be required to:
    1. Modify the application script to use this specific Java version.
    2. Have the system path pointing to this location for the system to pick it up.

Overview

This article describes how to upgrade an existing FileCatalyst Workflow installation to the latest version of FileCatalyst Workflow 5.0. It is assumed that Workflow is deployed on Apache Tomcat and that the Windows Executable Installer was not used. Please note if after your upgrade your Language File entries do not show, you will need to restart the Tomcat Web Server.

Please use the following link to Windows Executable Installer Upgrade Guide. For Workflow deployments on v5.1.2 and newer you can now change your memory assigned to the Tomcat Server

Note: The upgrade guide for older Workflow Deployments (4.X) is located here.

Before you proceed please make sure the following System Requirements are met:

  • Amazon Corretto Java 8 (x64) and Tomcat 8.X or 9.X are now required. Java 9, 7 and 6 and Tomcat v4,v5,v6,v7 and v8.5 are NOT supported.
  • FileCatalyst Direct Server 3.7.3 or higher is only supported.

The following features have been removed in Workflow 5.0:

  • Third-party FTP Servers are no longer supported (including IIS-FTP, Filezilla, ProFTPd and others)
  • Webmail WAR file is no longer produced
  • Older Workflow 4.X page templates are no longer supported
  • Java Applets are no longer available as a file transfer method
  • Calculate Pricing features removed

Environment

FileCatalyst Workflow v4.9.9 and later
Open JDK 8 (Corretto)
FileCatalyst Server v3.7.3 and later
Tomcat 8.0.X or 9.0.X only

Resolution

Note: Please upgrade your Java installation to Open JDK 8 (Corretto), you can download it from Corretto.

Download the upgrade packages:

You will need to download the upgrade packages from our website http://filecatalyst.software. Contact your FileCatalyst Sales Representative in order to obtain a username and password.

Locate and download the FileCatalyst Workflow 5.0 application package called fcwebworkflow_war.zip. This file is for all upgrades as well as new deployments.
Locate and download the FileCatalyst Server 3.7.3 or higher application package chosen based on your Operating system. This file is for all upgrades as well as new deployments.


Upgrade Instructions:

Upgrade FileCatalyst Server using the following documentation: http://filecatalyst.software/download/filesFCDirect/current/documentation/server/Help.html#upgrades

Upgrade Workflow:

  1. Log in as Super Admin to FileCatalyst Workflow. Click on the About FileCatalyst icon and make a note of the path to your Configuration Folder. Look for it in the field named Configuration Path.
  2. Stop Tomcat service.
  3. Make a backup copy of the Configuration Folder.
  4. Make a backup of MySQL Database, using a MySQL dump tool, or by any other method that you find convenient.
  5. Backup workflow.war and /workflow folder to a location outside of Tomcat. This folder and WAR file are located in /<Tomcat-Home>/webapps/
  6. Delete the workflow.war and /workflow folder from /<Tomcat-Home>/webapps/.
  7. Unzip the workflow.war from the fcwebworkflow_war.zip file and place it in /<Tomcat-Home>/webapps/.
  8. Delete the /<Tomcat-Home>/work/Catalina directory.
  9. Stop the service FileCatalyst Workflow.
  10. Modify the Tomcat web.xml file using this guide to prevent JSP Servlet Errors.
  11. Start Tomcat service. Tomcat will re-deploy the new WAR file and make a new directory /<Tomcat-Home>/webapps/workflow/ automatically.
  12. Open a web browser of your choice and access FileCatalyst Workflow as usual. If you are on the local machine, go to http://localhost/workflow or http://localhost:8080/workflow. (Assuming the Tomcat default port 8080, otherwise, substitute an appropriate port)
  13. Log in with username init with the password aaaaa.
  14. Click on the button for Existing or Custom Configuration Folder.
  15. Enter the path you noted in Step 1 from the Configuration Path.
  16. FileCatalyst Workflow will re-initialize and all your previous settings will be imported into the new deployment.
  17. Once you completed your upgrade to FileCatalyst Workflow 5.0, your current FileCatalyst Workflow license will be invalidated. Please contact your sales rep and email them your request string to get a new key.
  18. If you upgraded your Java during the upgrade, you will need to update cacerts file if you use LDAP/Ad over SSL, consult online help for Workflow for more details

Roll-Back Guide

  1. Stop the Tomcat service.
  2. Delete the /<Tomcat-Home>/webapps/workflow/ directory.
  3. Delete the /<Tomcat-Home>/webapps/workflow.war file.
  4. Delete the /<Tomcat-Home>/work/Catalina directory.
  5. Place the backup version of workflow.war into /<Tomcat-Home>/webapps/ folder.
  6. You can either backup the existing configuration folder or delete it.
  7. Place the previously backup Configuration Folder in the original location.
  8. Start the Tomcat service. Tomcat will redeploy the WAR file and make a new directory /<Tomcat-Home>/webapps/workflow/ automatically.
  9. Open a web browser of your choice and access FileCatalyst Workflow as usual. If you are on the local machine, go to http://localhost/workflow or http://localhost:8080/workflow. (Assuming the Tomcat default port 8080, otherwise, substitute an appropriate port)
  10. Log in with username Init with the password aaaaa.
  11. Click on the button for Existing or Custom Configuration folder.
  12. Enter the path you noted in Step 1 from the Configuration Path.
  13. FileCatalyst Workflow will re-initialize and all your previous settings will be imported into the new deployment.

Overview

Before moving your FileCatalyst Workflow deployment from staging to live status, there are a few optional steps that can be taken to ensure that your Tomcat Web Server has been hardened. The Hardening of a Web Server is a process where the security on the Web Server is enhanced by applying specific changes to the configuration. This results in a reduced risk of malicious attacks on the Web Server.

Many of the steps shown below have been extracted from https://wiki.owasp.org/index.php/Securing_tomcat. Please visit this site to get more information.

This article will guide you through some of the sections of the Tomcat Server. The paths and configurations mentioned below are referenced based on Windows OS, however, the same configurations can be used on a Linux OS. 

 

Environment

FileCatalyst Workflow v5.0 and newer.

Apache Tomcat Web Server

Note:
These modifications should be applied to an external installation of Apache Tomcat and not to any instances that have used the self-executable installer. 

 

Resolution

In order to successfully harden Apache Tomcat, you will need to resolve all of the issues below.

  1. Removing Server Banner or Server Name

    The Server Name is usually returned in the Response Headers. The Response Header can be customized to not return the name or type of Web Server that is being used.

    If you hit the landing page of FileCatalyst Workflow (http://www.yoursite.com/workflow) and Right Click on the page and select Inspect Element. You will find a docked window inside your browser, navigate to the Network Tab and reload the page. Click on the logon.jsp link and look for the Response Headers section.  A typical (default) response looks like:

    Content-Type:text/html;charset=UTF-8
    Date:Fri, 08 Jul 2016 14:36:40 GMT
    Server:Apache-Coyote/1.1
    Transfer-Encoding:chunked
    X-FRAME-OPTIONS:SAMEORIGIN

    Use the following steps to remove Server:Apache-Coyote/1.1 entry:

    1. Shutdown the Tomcat Web Server.
    2. Using a text editor open the Server.xml file. It is typically found in <Tomcat_Home>/conf/server.xml.
    3. Scroll down to your Connector Port add the following:

      Server=" " 

      Your modified Connector will look like:

      <Connector port="80" protocol="HTTP/1.1"
      connectionTimeout="20000"
      Server=" "
      redirectPort="8443" />

    4. Save the file and close the text editor.
    5. Start your Tomcat Web Server and the new changes will take effect.
    6. The new Response Header that is returned will have the following information:

      Content-Type:text/html;charset=UTF-8
      Date:Fri, 08 Jul 2016 14:45:55 GMT
      Server:
      Transfer-Encoding:chunked
      X-FRAME-OPTIONS:SAMEORIGIN
  2. Use SSL connections and force all connections to use HTTPS.

    1. For the Tomcat Web Server to accept SSL connections, a valid SSL Certificate needs to be deployed on the Web Server. Use the following guide to Generate and deploy the SSL Certificate to the Tomcat Server:
      http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/295/9/tomcat-csr-and-ssl-certificate-installation-and-renewal

    2. Once the SSL Certificate is deployed, all connectivity to the Web Server can be forced to use HTTPS. The steps to modify the configurations on the Web Server can be found here:
      http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/317/0/how-to-force-https-connections-in-workflow-or-webmail

  3. Run Tomcat from a non-privileged Account.

    It is best practice to use a separate account that has lowered permissions. This will protect other services running on the machine in case of any security breach.

    1. Create a user for the Tomcat Web Server.
    2. Linux - Change the ownership of the /<Tomcat_Home>/ directory to the newly created user.
      Windows - From the Service Manager, change the Tomcat Service properties to use another Logon Account.

  4. Removing unwanted applications the Webapps Directory.

    By default, Tomcat installs and deploys web applications which may not be required in your environment. These can be removed from Webapps directory (/<Tomcat_Home>/webapps/).

    1. The following folders may or may not be present but are not required for a FileCatalyst Workflow deployment:

      • Docs - This folder contains the Tomcat Documentation.
      • Examples - JSP and Servlets for demos are in this folder.
      • Manager - Web UI that allows deploy and deploy applications.

  5. Shutdown Port and Command

    The Tomcat Web Server is configured to be shut down on port 8005 and the command that is used is SHUTDOWN. Telnet to IP:port can be used to call a SHUTDOWN to the Tomcat Web Server.
    The port value and command string should be modified from the default values in the Server.xml file.

    1. Shutdown the Tomcat Web Server.
    2. Using a text editor open the Server.xml file and modify the following entry:

      <Server port="8005" shutdown="SHUTDOWN">

      These values should be changed to a Port value that is not in use and the command can be customized as well. Here is an example:


      <Server port="9889" shutdown="SHUTD0WNT0MCAT">

    3. Save the file and close the text editor.

  6. Change the Website Icon

    By default, the favicon.ico file located in the <Tomcat_Home>/webapps/ROOT/ folder will be loaded when anyone loads the FileCatalyst Workflow page or any other Tomcat Web Server page that is hosted on your machine. Replace this file (<Tomcat_Home>/webapps/ROOT/favicon.ico) with an icon of your choice and rename your file to favicon.ico and restart the Tomcat Web Server.

  7. Hide details from error pages
    Edit <tomcat_home>/conf/server.xml add the following valve to the host portion of the file:

    <valve classname="org.apache.catalina.valves.ErrorReportValve" showreport="false" showserverinfo="false"/>

Overview

This guide will provide a quick walkthrough on launching your own FileCatalyst Server and licensing it on an Amazon EC2 instance.

Environment

Amazon Linux Amazon Linux - 64-bit Amazon Machine Image
FileCatalyst Server v3.8

Deployment Guide

Launching FileCatalyst Server from the AWS Marketplace.

  • Select the version of the FileCatalyst Server you would like to use. We recommend using the option with the latest Release Date:

  • Choose the Region that you would like to use from the drop-down list.



  • Skip ahead one section and select the VPC Settings you would like to use.

  • When initially deploying the FileCatalyst Server, we strongly recommend that you use the preconfigured Security Group called "Create new based on seller settings". You will be able to modify these settings on your EC2 dashboard later.

  • To connect to the machine you will need a KeyPair. If there is an existing KeyPair you would like to use select it from the drop-down list.

  • Review the rest of your settings and Machine connection information on the "Launch this software" page and click on Launch at the bottom. 



Connecting to your FileCatalyst Server

  • From your EC2 dashboard, you will be able to see the instances that you have currently active. When the instance has completed set up (Status checks 2/2), select it and click on the "Connect" button at the top. This will show you a pop up on how to connect to your instance using PuTTY.


Amazon has provided documentation to assist with your connection to the Ubuntu deployment here: https://docs.aws.amazon.com/console/ec2/instances/connect/docs

Getting a license key

  • Connect to the FileCatalyst Server using PuTTY or a Terminal. Switch to the elevated root user using:

    sudo su

  • Change your working directory so that you are in the FileCatalyst Server installation path by executing:

    cd /opt/utechsoft/server

  • Once you are in the folder, you will need to stop the FileCatalyst Server service if it is running.

    service fcserver stop

    Your expected output should be:



  • Set execute permissions on the launch scripts in the installation folder. Make sure your current working directory is still /opt/utechsoft/server/. Run the following command to set the permissions:

    chmod u+x *.sh

  • The next step is to install a license key on the FileCatalyst Server. Run ./fc_server_console.sh and the FileCatalyst Server will attempt to start up. At this point, a request string will be shown:



    Send the request string to your Sales Rep at FileCatalyst indicating what type of license you would like and how many concurrent connections you need. They will send you a key with the appropriate features enabled. Please copy and paste the Request String. Taking a screen capture of the request string may delay you getting a License key. 

    If you do not have the contact for a Sales Rep please send the Request String to [email protected]

Applying the license key

  • Make sure your FileCatalyst Server is off before you proceed. You can run ps -ef | grep java in the terminal and make sure no instance is running. If you do see that there is an instance running please stop the application.

  • Under /opt/utechsoft/server directory, edit fcconf.conf in a text editor. Paste your license key you received after the = sign:

    ## License key

    FCServer.server.config.license=<Enter Key Here>

  • Save the file.

Recommended: Change the Remote Admin Password

  • To change the Remote Administration password run the following command from /opt/utechsoft/server:

    java -jar FileCatalystServer.jar -passwdadmin

    The output should look like:


Launching the FileCatalyst Server

 

Enable Masquerade Address


The FileCatalyst Server itself now needs to know that it's working through a NAT device. To enable this:

  • Open the Server Remote Admin Application.
  • Select Advanced on the left-hand side.
  • Check the box to Enable Masquerade Address.
  • In the address field, enter the Public IP. This is not the IP of the machine running the FileCatalyst Server. If the network device acts as a gateway between your network and the public internet, you can find the public internet address quite easily by browsing from any machine to this site: http://whatismyip.com 
    Alternatively, you can obtain your Public IP (IPv4) from your EC2 instance management console. Do not use your DNS.
  • Hit Apply.



Note:

Quick Start Guide: How to add External File System Storage on the FileCatalyst Server
Overview

With the release of Tomcat v9.0.19 (April 12, 2019) we have had clients report that our Workflow WAR file deployment has not been successful.


This issue has been escalated to our Development team. In the meanwhile, we recommend that our clients use Tomcat v9.0.16 which can be downloaded from the Tomcat repository available here:

https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.16/bin/

Please note this does not apply to any clients who have used the Windows self-executable installer.

Environment

Workflow 5.0 to 5.0.4

Workflow (legacy builds) 4.9.7 to 4.9.9.


Overview

When connecting to a landing page of a Tomcat Web Server directly at http://mycompany.com/ you will not be redirected to FileCatalyst Workflow or Webmail automatically. This will hit the landing page of the Tomcat Server. For FileCatalyst Workflow or Webmail to be accessed there must be a /workflow or /fcweb appended to the end of the URL.

We can edit the index page in the Root folder of the Tomcat Web Server so that URLs can be redirected to Workflow or Webmail.

 

Environment

FileCatalyst Workflow v4.9 and later.

 

Resolution

  1. Shut down the Tomcat Web Server service.
  2. Navigate to the <path to Tomcat>/webapps/ROOT/ directory and open the index.html page in a text editor. If a page does not exist create it.
  3. Delete or comment out everything between the <BODY> and </BODY> tags in order to hide the content.
  4. Add the following lines of code in this file:


    <HEAD>
     <meta HTTP-EQUIV="REFRESH" content="0; url=/workflow">
    </HEAD>

  5. Save the index.html file and restart the Tomcat Web Server service.

FileCatalyst Workflow Release Notes

  • Open JDK 8 (Amazon Corretto) is now required. Tomcat 8.0.X or 9.0.X are now required. Java 9, 7 and 6 and Tomcat v4,v5,v6,v7,v8.5 are NOT supported.
  • Third party FTP Servers are no longer supported (including IIS-FTP, Filezilla, ProFTPd and others)
  • FileCatalyst Remote Web Admin must be enabled on the Direct Server and the web port must be provided in Workflow.
  • Webmail WAR file is no longer produced.
  • FileCatalyst Direct Server 3.7.3 or higher supported
  • Older 4.X page templates are no longer supported
  • Java Applets are no longer available as file transfer method (since v5.0)
  • Calculate Pricing features removed

Version 5.1.3

Build 1070 (October 21, 2020)

  • Notice: As of Nov. 30 2020, Windows Installer will no longer be produced, consult FileCatalyst_Web_Tomcat_Installation.pdf on how to install or upgrade FileCatalyst Workflow moving forward
  • Fixed: High packet loss on lower speeds when using TransferAgent
  • Fixed: In TransferAgent installer, the recommended install option does not delete the older version of TransferAgent
  • Fixed: File Area not working in Internet Explorer, support of Internet Explorer will end on Nov. 30th 2020
  • Fixed: Secure Authentication email template does not contain the correct tracking number
  • Fixed: Files uploaded via Request Files upload form, can't be easily identified, rename mask was added for files uploaded via Request Files
  • Fixed: Wrong directory when sending distribution job for files selected from a file area
  • Fixed: Communication error with internal FileCatalyst server on Linux
  • Fixed: The "date" job data field type parses invalid dates incorrectly
  • Fixed: "Request files here" icon appears to users with File Area access only
  • Fixed: Two File Area icons appear on the main user menu when a 'job submission only' user is assigned to a File Area with 'My file Area' option enabled
  • Using: FileCatalyst Direct Server 3.8.1 Build 103
  • Using: FileCatalyst TransferAgent 3.8.1 Build 99



Version 5.1.2

Build 1033 (July 30, 2020)
  • Added: TLS 1.2 support
  • Added: Make temp username more informative when using strict security
  • Added: A scroll bar is added to New Job and File Area drop down menu items when there are many items on the list
  • Added: Remote Admin Applets removed, only HTML Remote Admin is now supported
  • Added: Users and temp users must change password on the next logon when they're sent a new password via email
  • Fixed: View Logs in File Area not working
  • Fixed: Remote Admin Connection to FC Server breaks after upgrading
  • Fixed: Some Tags in email templates get corrupted up when saving non-default email template
  • Fixed: In Form Upload, when XHR upload fails the user is never redirected to error
  • Fixed: Database parameters field not working
  • Fixed: Generating reports on large databases is slow
  • Fixed: Confusing behaviour when TransferAgent shuts down due to inactivity while the web page is still loaded
  • Fixed: mysql-connector updated to version 5.1.49
  • Fixed: Submitting files from file area from a directory starting with _ is no longer allowed
  • Fixed: Alignment for User and Job data fields on anonymous order forms
  • Fixed: Not all dates displayed follow the format set in the language file via button.datePicker.format
  • Fixed: User Profile Changed To User email template doesn't accept locale
  • Fixed: Various end user messages and errors are not getting translated
  • Fixed: The flag "Don't allow to use existing password" doesn't work
  • Fixed: Reflected Cross-Site Scripting (XSS-r) vulnerability
  • Fixed: JQuery was updated
  • Fixed: Contact Operator emails are not getting translated
  • Fixed: TwoWay_workflowdefault.properties for TransferAgent are not respected
  • Fixed: Users can view Address Book Contacts of other users in the system
  • Fixed: PW_USEDPASSWORDS column is cleared if it contains clear text passwords on legacy installations
  • Fixed: Internal FC Server doesn't always work on Linux
  • Fixed: Sensitive information in config.xml is not encrypted
  • Fixed: {INITDIR} {USERNAME} tags in the path to group folder don't work
  • Fixed: Usernames containing a white space are no longer allowed for both temporary and regular users
  • Fixed: Image Video Preview
  • Using: FileCatalyst Direct Server v3.8 Build 11
  • Using: FileCatalyst TransferAgent v3.8 Build 10

Version 5.1.1

Build 964 (March 30, 2020)
  • Fixed: FileArea Session logs are not captured on Chrome, due to a code change in Chromium, see Disallow sync XHR on page dismissal
  • Fixed: Date Picker not using user language
  • Fixed: When sending distribution jobs and setting the Expiry Date to today, the link is expired for today. The link should work until midnight of the day the job was sent
  • Fixed: Removed unused library .jar files
  • Fixed: {APPLICATIONROOT} in email templates adds an extra white-space
  • Fixed: Regular Admin View Groups - Open Folder link is broken
  • Fixed: Admin activities for FileAreas are not logged.
  • Fixed: Duplicate required field statements on Edit My profile for end user
  • Fixed: On pages: Edit My Profile, Forgot Password and Invite Others, Submit and Cancel Buttons don't use the correct language
  • Fixed: Not all items are translated on View Job Popup
  • Using: FileCatalyst Direct Server v3.7.3 Build 37
  • Using: FileCatalyst TransferAgent v3.7.3 Build 37

Version 5.1

Build 947 (Jan 31, 2020)
  • Added: "Request Files Here" feature, allows File Area users to Request files from outside users to upload into a chosen folder in a FileArea. Request File Here links can be configured to automatically expire after XX days
  • Added: Ability to set multiple languages, each language is loaded dynamically based on the "Accept-Language" request header Administrators can create any number of language files based on POSIX Locales
  • Added: Text contained in forms, job status and fields can now be loaded as a custom language property, to better support the new multi-language feature
  • Added: Language parameter to email substitution tags, so the email templates can be created in multiple languages. Ex: {JOBINFO#FR}
  • Added: TransferAgent installer now supports MacOS 10.15 Catalina with permission-based access prompts
  • Added: TransferAgent Installer for Windows is now signed with Extended Validation (EV) Certificate
  • Fixed: Users with Job Submission only status, assigned to a group with Shared Folder option checked, don't see the File Area icon in the main menu
  • Fixed: Address Book for admin users is always empty
  • Fixed: Don't delete temp user when a file transfer is ongoing, when navigating away from a file transfer page
  • Fixed: List of users disappears after adding a user to a group
  • Fixed: "Send Selected Files" is broken in IE11
  • Fixed: In-line installer for TransferAgent in IE11
  • Fixed: Download Location shows wrong download path when individual file is downloaded via UDP
  • Fixed: User and password cookies are now secure and http only
  • Fixed: Expired and archived jobs with enhanced security send multiple emails when download link is clicked
  • Fixed: CSR Forgery protection broke links in the emails to admin, user to get files or view PDF for a job. Getting files from an email which contains a link to a tracking number was not affected.
  • Fixed: The max length of FileCatalyst Server ID, Order Form ID, Group ID is now set to varchar(255)
  • Fixed: When Internal FileCatalyst Server is used, and the Super Admin clicks on Remote Admin link, the host value may change
  • Fixed: No error is reported if the Remote Admin Password is wrong in FileCatalyst Server when using 12480 HTTP Admin port
  • Fixed: Error messages disappear on list users when show users per page is changed
  • Fixed: Save merged language files alphabetically
  • Fixed: Selected row in FileArea is now more visible
  • Fixed: recipientemailCC field type not working unless the field ID is RecipientEmailCC
  • Fixed: Missing email notifications when form upload fails
  • Fixed: Two email notifications sent when upload fails via TransferAgent for a new Job
  • Fixed: Request String sometimes is created against a non routable network address
  • Fixed: Job, User Group List, "Add Field" is now alphabetised
  • Fixed: Forgot Password email feature resets password for users with "User Can Change Password" check box unchecked in their profile
  • Fixed: Form upload, shows a cryptic error when maximum number of concurrent connections is exceeded on the Direct Server
  • Using: FileCatalyst Direct Server v3.7.3 Build 37
  • Using: FileCatalyst TransferAgent v3.7.3 Build 37

Note: Tomcat v9.0.19 released on April 12, 2018, is currently not supported. Please use Tomcat v9.0.20 or higher

Version 5.0.5

Build 840 (Aug 2, 2019)
  • Added: New setting "Job File Rename Mask" under FileCatalyst Servers, script execution. To allow mass rename of all the files being uploaded to Workflow
  • Added: Import/Export users to/from CSV
  • Added: XML Transformation based on an XSL file
  • Added: New tag {USERNAME_REPLACE_CHARS} in Job Files Target Location and Job PDF, JSON and XML target location
  • Added: New property to Field was added. Data URL - this option will fetch the data for the given field from a URL
  • Added: New local and public host field for FileCatalyst Servers, to allow better integration with FileCatalyst Server Reverse Proxy
  • Added: REST API is now used for creating temporary users/files on the FileCatalyst Direct Server when Strict Security is turned on. New field added to FileCatalyst Servers - Remote Admin HTTP Port. The time for creating the temporary accounts on FileCatalyst Server was greatly reduced.
  • Fixed: Admin Overview page taking a long time to load
  • Fixed: Broken pagination link on user list
  • Fixed: Locked fields are not locked in order forms
  • Fixed: Edit Contact in Address Book
  • Fixed: Reject files containing reserved characters in the file name
  • Fixed: Make sure that all cookies have secure flag set
  • Fixed: Ability to connect to FC Servers with TLS 1.2 only support
  • Fixed: Set autocomplete=off to all password fields
  • Fixed: Several functional issues with Job Files Target Location and Job PDF, JSON and XML target location
  • Fixed: Pagination for Jobs By Date report
  • Fixed: Content-Security-Policy header
  • Fixed: CSR Forgery protection, session TOKEN added to every link in the application on the end user pages (not admin)
  • Fixed: Message AuthConfigFactory error: java.lang.reflect.InvocationTargetException error when accessing Tomcat 9.0.XX for the first time after deploying Workflow
  • Fixed: Internal Direct Server doesn't startup properly when doing a clean install from the Windows Install file, subsequent restart of Tomcat Service fixes Internal Server issues.
  • Using: (Workflow) FileCatalyst Direct Server v3.7.3 Build 25
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.3 Build 25

Version 5.0.4

Build 896 (Mar 4, 2019)
  • Added: Make TA install Optional on download, even if the default download method is set to TA
  • Added: Show FileArea data usage on the admin dashboard and on the data usage summary report
  • Added: Caching of data usage summary report on admin Dashboard
  • Fixed: HotFolder Job submission when Strict Security is enabled
  • Fixed: Updated default upload methods and protocols to TA and auto, make all protocols available even if the method is http download only
  • Fixed: Prevent infinite loop when creating temp user for strict security fails
  • Fixed: Notify sender when the job is downloaded drop-down is now always visible on edit job
  • Fixed: acceptEmail field for user not being saved
  • Fixed: Banned IP filters start blocking all requests under certain conditions
  • Fixed: Don't allow to go from edit job straight to my file area without first cancelling the job
  • Fixed: Minimum and recommended TA versions now work with FileArea
  • Fixed: Fixing null-pointer when password is not provided from HotFolder
  • Fixed: Added trailing slashes to temp user home directory so things will work with accounts pointing to object storage
  • Fixed: Cancelling of form upload form (not octet stream)
  • Fixed: Margin formatting for help text for orderform fields
  • Fixed: Files uploaded using Hotfolder to workflow filearea end up in root when strict security is enabled.
  • Fixed: New account registered does not send email to admin
  • Fixed: putFileLocal when uploading via HTTP Servlet
  • Fixed: Always show preferredServer on the admin side if we have more than one site created
  • Using: (Workflow) FileCatalyst Direct Server v3.7.3 Build 14
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.3 Build 13

Version 5.0.3

Build 867 (Nov 26, 2018)
  • Added: New installer for TransferAgent contains prepackaged with Java Runtime(JRE), JRE is no longer required to be pre-installed on end user's system
  • Added: Ability to filter the email addresses for Distribution jobs based on groups on top of the existing IP based filters
  • Added: Ability to restrict, super admin and regular admin login by IP Ranges (ex. 192.168.1-255.1-255) on top of the existing CIDR filters. Added ability to blacklist IP's and Ranges as well
  • Added: Ability to restrict uploads/download to FileAreas by filename or extension
  • Added: Internet Explorer X-UA-Compatible meta tag to disable IE from running in compatibility mode
  • Added: Support for Jersey 2 - RESTful API
  • Fixed: When a user attempts to use Workflow with TransferAgent that has an expired SSL certificate, they now get properly prompted to upgrade TransferAgent
  • Fixed: Submitting files from FileAreas is not working from Internet Explorer
  • Fixed: All controls for browsing/adding files are disabled once the upload is started with TransferAgent
  • Fixed: Emails failing to send due to a conflict in mail API libraries
  • Fixed: When a user cancels the upload, the redirect goes to Error URL instead of Cancelled URL
  • Fixed: File list pane scrolling in TransferAgent
  • Fixed: Pagination of user list in admin
  • Fixed: Strict Security not working with home accounts pointing to object storage (s3://)
  • Fixed: Multiple problems with Edit File Properties
  • Fixed: LDAP/AD over SSL in Java 8, consult online help for more details
  • Fixed: All Dates on Job Lists follow button.datePicker.format configurable from the language file
  • Fixed: When all the available job status fields are set not to visible to users, users are getting a blank page when they login
  • Fixed: Submit button missing in FileArea when there is only one FileCatalyst Server site defined
  • Using: (Workflow) FileCatalyst Direct Server v3.7.3 Build 5
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.3 Build 5

Version 5.0.2


Build 783 (July 20, 2018)
  • Fixed: Downloading Individual files via UDP marks the entire job as shipped in Distribution jobs.
  • Fixed: Uploading files over 2GB with form upload reports files size of 1KB
  • Added: Sample code on how to submit jobs with files in FileAreas with the API
  • Fixed: Upgraded Windows Installer with Tomcat 8.0.53
  • Using: (Workflow) FileCatalyst Direct Server v3.7.2 build 8
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.2 build 8

Version 5.0.1


Build 763 (May 28, 2018)
  • Added: "Test Connection" Button to upload, download and file area.
  • Fixed: Submission of files from sub-folders in FileArea
  • Fixed: Broken redirect to submit and finalize job when address book is disabled in Distribution jobs
  • Fixed: On mobile devices, always redirect to form upload as TransferAgent is not available on any mobile device
  • Fixed: Number of files allowed to upload on mobile devices is now set to 4 instead of 1
  • Fixed: Export Help as HTML
  • Fixed: Date picker on user expiry date selection broken
  • Fixed: Moved maxfiles / maxsize warning to a better place on the upload page
  • Fixed: Custom Header missing on the logon page
  • Fixed: Display "Bandwidth Tuning Properties" on Edit My Profile
  • Fixed: Distribution forms with a blank space will let you continue and upload files without entering an email address
  • Fixed: Logo element in template is now a plane simple img tag
  • Fixed: Sticky Footers
  • Fixed: Minor but highly visible color and style adjustments to themes
  • Using: (Workflow) FileCatalyst Direct Server v3.7.2 build 8
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.2 build 8

Version 5.0


Build 697 (March 29, 2018)
  • Added: Brand new end user interface based on HTML5
  • Added: Brand new admin Interface based on HTML5
  • Added: Admin Dashboard
  • Added: New templating mechanism, old templates are no longer supported
  • Added: Ability to assign templates to groups
  • Added: Ability to Import/Export Templates
  • Added: Five new templates redesigned from the ground up using HTML5, two of those new templates follow the dark theme (white text on a dark background)
  • Added: Silent Installer for TransferAgent for automated corporate deployments to multiple workstations
  • Added: Delete Selected Files button in FileArea, to delete multiple files with a single click
  • Added: New daily data usage report
  • Added: Remote Admin to the internal FileCatalyst Server now uses HTML5 Admin (not the Java Applet)
  • Fixed: HTML Form upload sometimes fails when many files are selected for upload (8 or more files)
  • Using: (Workflow) FileCatalyst Direct Server v3.7.2 build 5
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.2 build 5

Version 4.9.9

Java 7 and Tomcat 7.0.59 or higher are now required. Java 8 and Tomcat 8 (not 8.5) are also supported. Java 9 and 6 and Tomcat v4,v5,v6, v8.5 and v9 are NOT supported.

Reloading the default language file for 4.9.9 might be required.

Webmail WAR file is no longer produced.


Build 131 (October 25, 2017)

  • Impoved: (Workflow) In-line installer of TransferAgent. All detection and install prompts are more clear and easier to read. The user is also guided through step-by-step images and text on how to install TransferAgent.
  • Fixed: (Workflow) Detection to check if TransferAgent is already installed in a web browser gets occasionally frozen, resulting in a never ending progress spinner.
  • Fixed: (Workflow) Download link to the installer of TransferAgent is broken in Internet Explorer/Edge in File Area.
  • Fixed: (Workflow) In General settings, open known file types with default application in browser not getting saved.
  • Fixed: (Workflow) Android App not finalizing jobs.
  • Using: (Workflow) FileCatalyst Direct Server v3.7.1 build 9
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.1 build 26
  • Using: (Workflow) FileCatalyst Direct Applets v3.6 build 45

Build 512 (July 5, 2017)

  • Added: (Workflow) Submit files from file areas using API (requires fcapi 3.7.2 or higher).
  • Added: (Workflow) Always enable the FTPS port on the Internal FC Server.
  • Added: (Workflow) Always enable HTTP Access when starting the Internal FC Server.
  • Fixed: (Workflow) Strict Security doesn't work with Internal Server
  • Fixed: (Workflow) Don't prompt the end user for upgrade of TransferAgent when connecting with TA 3.7.1
  • Fixed: (Workflow) Memory leak with SessionData objects not getting deleted.
  • Fixed: (Workflow) If you disable Upload JSON On Job Submission it is re-enabled on service restart.
  • Fixed: (Workflow) Missing langauge entries for Video Preview.
  • Using: (Workflow) FileCatalyst Direct Server v3.7.1 build 9
  • Using: (Workflow) FileCatalyst TransferAgent v3.7.1 build 9
  • Using: (Workflow) FileCatalyst Direct Applets v3.6 build 45

Build 486 (April 4, 2017)

  • Added: (Workflow) File Area now works with TransferAgent (Java Applets are no longer required to access file areas).
  • Added: (Workflow) TransferAgent now supports Linux.
  • Added: (Workflow) Ability to embed an order form within an iFrame on another web site.
  • Added: (Workflow) Ability to force form upload as the upload method in specific order form.
  • Added: (Workflow) Ability to specify custom CSS with an order form.
  • Added: (Workflow) Cross-Site Request Forgery (CSRF) protection.
  • Fixed: (Workflow) Single file download with UDP now works when Strict Security is enabled.
  • Fixed: (Workflow) Apostrophy not working in TransferAgent when set via the language file.
  • Fixed: (Workflow) Proper handling of uploads and downloads when strict security is turned on and the end user doesn't start the transfer before the 20 minutes temp account timeout.
  • Fixed: (Workflow) Internal Server startup creates corrupt fcconf.conf file
  • Fixed: (Workflow) Strict Security when the FC Home directory uses UNC paths (ex: \\192.168.1.2\somefolder\).
  • Fixed: (Workflow) Potential concurrency conflicts when two TransferAgent uploads start exactly at the same time.
  • Using: (Workflow) FileCatalyst Direct Server v3.7 build 3
  • Using: (Workflow) FileCatalyst TransferAgent v3.7 build 3
  • Using: (Workflow) FileCatalyst Direct Applets v3.6 build 45

Version 4.9.8

NOTICE: Java 7 and Tomcat 7 are now required. Java 8 and Tomcat 8 (not 8.5) are also supported. Java 9 and 6 and Tomcat v4,v5,v6, v8.5 and v9 are NOT supported.

Build 115 (Febuary 16, 2017)

  • Fixed: (Workflow) Form uploads with iPhone and iPad.
  • Fixed: (Webmail + Workflow) Cross Site Scripting vulnerabilities.
  • Fixed: (Workflow) Job Files Target Location with Java Applets and Strict Security.
  • Fixed: (Workflow) Downloads with email auth, pin or password not working when manually entering the tracking number on older templates.
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 48
  • Using: (Workflow) FileCatalyst TransferAgent v3.6 build 48
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 45

Build 113 (January 24, 2017)

  • Fixed: (Workflow) Server stability when Strict Security option is used.
  • Fixed: (Workflow) TransferAgent not working on Mac.
  • Fixed: (Workflow) Download files doesn't work with older page templates.
  • Fixed: (Workflow) HTTP fall back servlet now automatically switches between FTP/FTPS as needed
  • Fixed: (Workflow) In TransferAgent added compatibility when Accept-Language header set to es-419
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 48
  • Using: (Workflow) FileCatalyst TransferAgent v3.6 build 48
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 45

Version 4.9.7

NOTICE: Java 7 and Tomcat 7 are now required. Java 8 and Tomcat 8 (excluding 8.5) are also supported. Java 9 and 6 and Tomcat v4,v5,v6, v8.5 and v9 are NOT supported.

Build 437 (December 12, 2016)

  • Fixed: (Workflow) Video Image Preview doesn't work when Tomcat is running on Linux.
  • Added: (Webmail + Workflow) Display LDAP/AD port in debug system log as parsed from the configuration.
  • Fixed: (Workflow) _shipped json, xml file creation error when xml.filename.prefix contains either <FILENAME> or <FILENAME.EXTENSION>.

Build 434 (November 7, 2016)

  • Fixed: (Workflow + Webmail) When using Java upload Applet, file name of the uploaded file includes the name of the file + path and all slashes are replaced by "--"
  • Fixed: (Workflow) Strict Security switch now accepts FileCatalyst Servers v3.7

Build 433 (November 3, 2016)

  • Added: (Workflow) Ability to generate low resolution preview of almost any video file sent via a distribution form. (ffmpeg required)
  • Added: (Workflow) Strict Security Switch in General Settings so the proxy FTP account is not passed to the client applications, rather a temporary account is created on the fly. This option requires Filecatalyst Direct Server 3.6 Build 30 or higher and no thrid party FTP servers can't be used.
  • Added: (Workflow) Import of Address Book from LDAP/AD now has a search string for better control on what contacts to automatically import.
  • Added: (Workflow) The event when TransferAgent starts on the client's machine and communicates back to Workflow is now logged in Job History Log both for uploads and downloads.
  • Added: (Webmail + Workflow) Custom location of upload temp folder for form uploads.
  • Added: (Webmail + Workflow) Email recipient auto-complete field now works with up/down and enter keys.
  • Added: (Workflow) File name for XML/JSON can now be set to the filename or filename.extension of the first file uploaded for the job.
  • Fixed: (Webmail + Workflow) Updated certificate for Java Applets, New cert will expire in Sept. 2019
  • Fixed: (Workflow) logon_internal.jsp is now disabled if SecureAuth is not turned on.
  • Fixed: (Webmail + Workflow) In Admin pages, Auto-Complete of user/password is now disbaled on pages that require a user/password to another service/system.
  • Fixed: (Webmail + Workflow) Can't set Confirm Step in Distribution jobs when Address book is enabled.
  • Fixed: (Workflow) Installing TransferAgent does not require admin rights on Windows.
  • Fixed: (Webmail + Workflow) Cross Site Scripting vulnerabilities.
  • Fixed: (Webmail + Workflow) Form upload will now accept files with reserved characters in the file name: ex: slshaes, |, "<", ">" and change the illegal character to "--"
  • Fixed: (Webmail + Workflow) Restrict access to uploadtemp folder.
  • Fixed: (Webmail + Workflow) Some error messages not working for form upload (in form, not Octet-Stream)
  • Fixed: (Workflow) Force the end user to upgrade TransferAgent if not up-to-date.
  • Fixed: (Workflow) Transfer Agent progress does not indicate when MD5 verification is occurring.
  • Fixed: (Workflow) Updated Workflow API example in the documentation.
  • Fixed: (Webmail) Merged missing langauge entries.
  • Using: (Workflow) FileCatalyst TransferAgent v3.6 build 46
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 45
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 43

Version 4.9.6

NOTICE: Java 7 and Tomcat 7 are now required. Java 8 and Tomcat 8 are also supported. Java 9 and 6 and Tomcat v4,v5,v6 and v9 are NOT supported.

Build 398 (May 3, 2016)

  • Added: (Webmail + Workflow) Select All Check-box on the address book popup
  • Fixed: (Workflow) On TransferAgent pages, X-UA-Compatible META tag moved to the correct location so it gets parsed by IE correctly
  • Fixed: (Webmail + Workflow) Email Authentication download method, users must paste the authentication token from email and can't click on the link directly
  • Fixed: (Workflow) FCTransferAgent.exe requires admin rights to run
  • Fixed: (Webmail + Workflow) Auto-Deletion thread doesn't delete files linked into other jobs
  • Improved: (Workflow) The initial launch message for TransferAgent so end users don't confuse the download of the Plugin with the download of the package
  • Using: (Workflow) FileCatalyst TransferAgent v3.6 build 23
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 21
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 21

Build 396 (April 15, 2015)

  • Fixed: (Webmail + Workflow) Job Files Target Location containing {JOBID} returns null
  • Fixed: (Workflow) Updated X-UA-Compatible tags to remove IE 9, 8, 7 as supported browsers.
  • Fixed: (Workflow) Added DOCTYPE tag for better support for IE 10,11 and Document Mode Emulation
  • Fixed: (Workflow) FCTransferAgent.exe identified as Installer to web browsers
  • Fixed: (Workflow) TransferAgent redirects to success URL even if MD5 checksum fails.
  • Fixed: (Workflow) Jobs that redirect to Error leave "Job Submitted" in Job History log.
  • Fixed: (Workflow) On download files, TransferAgent launch dialog does not stop the spinner, making the download page unusable
  • Fixed: (Workflow) Files transferred with TransferAgent have the last modified date (MaintainLastModified) set to current month minus 1
  • Fixed: (Workflow) Upload/Download web pages get locked when a user Rejects "FileCatalyst TransferAgent Access Request" dialog
  • Using: (Workflow) FileCatalyst TransferAgent v3.6 build 22
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 21
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 21

Build 394 (March 23, 2015)

  • Fixed: (Webmail + Workflow) Backwards compatibility with older HotFolder and Android App
  • Fixed: (Webmail + Workflow) Add users to the FC Server automatically not working when only a single server is defined
  • Using: (Webmail + Workflow) FileCatalyst TransferAgent v3.6 build 12
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 12
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 12


Build 393 (Feb 25, 2016)

  • Added: (Workflow Only) New upload and download methods - TransferAgent. Java Applets are no longer be required
  • Added: (Workflow Only) Ability to start a file transfer and be able to close the web browser while the transfer is still in progress
  • Added: (Workflow Only) To maximize the bandwidth, TransferAgent will upload multiple files concurrently - the multi-client approach
  • Added: (Workflow Only) Use LDAP/AD Utility Account to fetch user information upon login
  • Added: (Workflow Only) Generate and upload JSON file for the job, so it can be parsed by external applications
  • Added: (Workflow Only) Search users with LDAP/AD Utility Account before attempting the bind
  • Added: (Workflow Only) Display PermaLinks on Order forms for quick access by the end user
  • Added: (Webmail + Workflow) Rename FTP/FC Site ID tool
  • Added: (Webmail + Workflow) Download entire help as HTML and improved help navigation menu
  • Added: (Webmail + Workflow) Which account invited the temp user is now tracked in the user comments field
  • Added: (Workflow Only) Tracking number and Job ID now present in all email distribution type of jobs
  • Added: (Workflow Only) On job list for end user, TrackingNumber column automatically appears if distribution type of jobs are present
  • Added: (Webmail + Workflow) New Download Transmittal List, users can now quickly discover which recipient has downloaded the files
  • Fixed: (Webmail + Workflow) HTML Form Upload, uploading multiple files in Firefox fails
  • Fixed: (Webmail + Workflow) HTML Form Upload, legacy form (not octet-stream) deletes the entire uploadtemp folder after upload
  • Fixed: (Webmail + Workflow) HTML Form Upload, Copy files to FTP is more robust
  • Fixed: (Webmail + Workflow) HTML Form Upload, file names containing UTF-8 characters don't show properly
  • Fixed: (Webmail + Workflow) In FTPServlet quote command affecting other commands if there is a failure
  • Fixed: (Webmail + Workflow) In FTPServlet cleaning uploadtemp is more robust
  • Fixed: (Webmail + Workflow) When French language is set as default language, calendar displayed is wrong
  • Fixed: (Webmail + Workflow) No more length limit on SMTP server field
  • Fixed: (Webmail + Workflow) On user list, clicking on sort by User Status, returns black row/column matrix
  • Fixed: (Webmail + Workflow) FileArea Applet fails to upload files to IIS-FTP in HTTP
  • Fixed: (Webmail + Workflow) Download Applet fails to download folders in HTTP
  • Fixed: (Webmail + Workflow) StyleSheetTag errors are now quiet
  • Fixed: (Webmail + Workflow) Automatically generated password for 'Invite Others' doesn't follow Global Password Properties
  • Fixed: (Workflow) XML and JSON not providing the correct sourceIP of the end user submitting the files
  • Fixed: (Webmail + Workflow) Removed the pre-compiler tool
  • Fixed: (Webmail + Workflow) Stability of the Internal FileCatalyst Server
  • Fixed: (Workflow) Auto-Deletion, not deleteing files uploaded by anonymous users
  • Fixed: (Workflow) Poodle fix in the Windows installers is missing
  • Fixed: (Webmail + Workflow) Older templates not displaying correctly for the download page
  • Discontinued: (Webmail) Webmail Installer is no longer produced, only the WAR file is now available
  • Using: (Webmail + Workflow) FileCatalyst TransferAgent v3.6 build 12
  • Using: (Webmail + Workflow) FileCatalyst Direct Applets v3.6 build 12
  • Using: (Webmail + Workflow) FileCatalyst Direct Server v3.6 build 12

Known issue:

  • HTTP transfers in TransferAgent can occasionally fail, please report any issues with HTTP transfers to our help desk
Looking for more release notes?

Please check our download site for the full product release notes.

Overview

FileCatalyst Workflow ships with the following default Super Admin User credentials:

Username: init
Password: aaaaa

These are not ideal for a live production environment so we recommend modifying this prior to taking your deployment live.

In more recent versions of Workflow, the super admin user credentials are hashed in the config.xml file.

 

Environment

FileCatalyst Workflow v4.9.9 and later.

Resolution

Change Admin Username and Password

To change these credentials first log into FileCatalyst Workflow as the Super Admin User (init) and navigate to the Modify Configuration page.

  1. Select the Admin User link under the System Configuration section.
  2. Enter a new Username.
  3. Enter a new Password for the Username.
  4. Hit the Save button.

    Your configuration will now be saved in the config.xml and you will have to log in with the new credentials from this point forward.

    If you wish to verify that the new credentials have saved successfully you can examine the config.xml located within the workflow-config folder. Simply search for the "systeminfo" tag.

  5. Stop your Tomcat web server service and restart it for your changes to take effect.


Reset Admin Username and Password

If you lost your Admin Username and Password, you will not be able to reset it through the Workflow UI in a web browser. You will need direct access to the machine that Workflow is installed on. To reset the password use the following guide:

  1. Shutdown the Tomcat Web Server service.
  2. Navigate to the workflow-config folder and open the config.xml file in a text editor
  3. Search for "systeminfo" tag and change the Username and Password. Please see image in the Overview section.
  4. Save and close this file.
  5. Start the Tomcat Web Server service and log in using your new credentials.
  6. Navigate to the backup folder inside the workflow-config folder. Open the most recent config{TIMESTAMP}.xml file. 
  7. Search for "systeminfo". You will see that your password is still in cleartext. Please delete this file as a new backup with a hashed password will be created on the next restart.

Overview

This article is designed to migrate your FileCatalyst Workflow instance which was installed using the executable installer. This installer includes an embedded Tomcat Web Server.

As of November 30, 2020, we will no longer be producing this installer.

This article will walk you through all the necessary steps needed to back up your Workflow deployment and migrate the application over to a stand-alone Tomcat Web Server install.

Article Quick Links

Environment

FileCatalyst Workflow v4.9.9 and newer.
Windows OS only.


Resolution

Warning: Do not skip any steps in this section or you may experience problems with your migration. 

  1. Backup configuration and settings:

    1. Database
      1. If you are using an Internal HSQL DB, this will be copied when backing up the Workflow Configuration files in the next step.
      2. If you utilize a MySQL DB, it is recommended that you use MySQL Workbench or a MySQL command line to take a full backup of the database.

    2. Workflow Configuration.
      1. Log into the FileCatalyst Workflow deployment as the Super Admin User.
      2. Click on About FileCatalyst on the top menu bar.
      3. The path listed under Configuration Path will be the location of your deployment. Copy this into a text editor and then browse to this location.
      4. Copy this folder and its contents to a new location, such as C:\workflow-config\. For the rest of this article, we will reference C:\workflow-config\.


    3. Web Server Settings
      1. Shut down the FileCatalyst Web Workflow service.



      2. Navigate to the installation folder and copy the \apache-tomcat\conf\ folder to your backup location. The default location for this installation is "C:\Program Files\FileCatalyst Web Workflow" or "C:\Program Files\FileCatalyst Workflow".
      3. Browse to \apache-tomcat\webappts\ROOT\ and copy this folder and its contents to your backup location. This folder will maintain your redirectors if they have been configured in the index.html file.

    4. SSL Certificate (optional)
      1. Backup your SSL Certificate Directory to your backup location.
      2. Open the \apache-tomcat\conf\server.xml file in a text editor.
      3. Search for the element in your SSL connector that has the following:

        keystoreFile="c:\tomcat-ssl\.keystore"

        The path after the equal sign will point to the SSL directory. Backup your SSL certificates.

  2. Install Amazon Corretto Java JDK 8:

    1. Go to the Amazon Corretto Java JDK 8  page and download the MSI file.
    2. Install Amazon Corretto Java JDK 8 using the installation instructions provided by Amazon.
    3. As a quick test, open the command prompt and run java -version, if your output looks similar to the one below it is configured properly:



      Note: You may need to set your JAVA_HOME directory.


  3. Install Tomcat 9.0:

    1. Go to the Apache Tomcat Download page and look for "32-bit/64-bit Windows Service Installer". Note: We do not support the use of Tomcat 9.5 or 10.0, or versions below 9.0.
    2. Install the application outside of the Program Files directory. For this article, we will use the path C:\Tomcat 9.0\.
    3. Do not start the Tomcat Server at this moment.


  4. Internal FileCatalyst Server Modifications (optional)

    This step is only required if you are using the Internal FileCatalyst Server. If you are using your own custom SSL Certificates, instead of commenting out the parameters below ("#") specify the new path to each element.

    1. Navigate to the Workflow Config folder (C:\workflow-config\) and rename the backup folder to backup-old. (C:\workflow-config\backup-old\)
    2. Open the fcconf.conf file in a text editor.
    3. Search for FCServer.server.config.private.key and comment it out by adding a "#" in front of it. If you are using your own SSL Certificate point this parameter to your Private Key.

      #FCServer.server.config.private.key=C:/FileCatalyst Web Workflow/apache-tomcat/fcservercert.pvk

    4. Search for FCServer.server.config.certificate.file and comment it out by adding a "#" in front of it. If you are using your own SSL Certificate point this parameter to your Certificate File.

      #FCServer.server.config.certificate.file=C:/FileCatalyst Web Workflow/apache-tomcat/fcservercert.pem

    5. Search for FCServer.server.config.default.certificate.location and comment it out by adding a "#" in front of it. This parameter will the Internal FileCatalyst Server where to re-generate 

      #FCServer.server.config.default.certificate.location=C:/FileCatalyst Web Workflow/apache-tomcat

  5. Deploy FileCatalyst Workflow

    1. Download the FileCatalyst Workflow ZIP.
    2. You will need a Username and Password to access this file. Please contact your Account Executive to obtain access to this page.
    3. Unzip the file.
    4. Copy the WAR file contained in the zip file into the C:\Tomcat 9.0\webapps\ directory.
    5. Modify the Tomcat C:\Tomcat 9.0\conf\web.xml file using this guide to prevent JSP Servlet Errors.
    6. Start the Tomcat Web Server Service.
    7. Access FileCatalyst Workflow in your browser using http://127.0.0.1/workflow/ or http://127.0.0.1:<port>/workflow/. You should see a default demo landing page.
    8. Login using init and the password aaaaa.
    9. When prompted choose a Custom Directory to use an Existing Setup. 
    10. Specify the path to the configuration folder that you created in step 1b. For example, C:\workflow-config\, and hit Change Folder and Restart.
    11. Once the service has restarted, log back in using your username and password.
    12. From the Modify Configuration menu, click on the Licenses link and provide your Sales Representative with the request string. Enter the License key here and hit Save.
    13. Under the System Restart, section hit the Restart System link. This will remove the Demo Banner.
    14. Stop the Tomcat Web Server.
    15. Replace the contents of C:\Tomcat 9.0\webapps\ROOT\ with the files from your backup. If you have had redirectors setup before they would be in your index.html file.
    16. Start the Tomcat Web Server.

      Note: After completing step 4k, your older configurations, customizations, User DB and email preferences are restored. 

  6. SSL Install (optional)

    If you previously had an SSL Certificate installed on your Workflow and have backed up your Keystore you can use the following article to modify the connector in C:\Tomcat 9.0\conf\server.xml to enable SSL:

    https://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/439/0/tomcat-csr-generation-and-ssl-installation-gui-method#InstallSSL

  7. Some other useful articles for your Tomcat Web Server:

    Harden Tomcat: https://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/333/0/how-to-harden-tomcat-web-server

    Force SSL Redirection: http://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/317/0/how-to-force-https-connections-in-workflow-or-webmail

    Redirect HTTP Root to /workflow:
    https://support.filecatalyst.com/index.php?/Knowledgebase/Article/View/148/0/how-to-redirect-webmail-or-workflow-from-the-tomcat-root-to-fcweb-or-workflow


Overview

This article will give a quick walkthrough of the installation procedure or the upgrade of an SSL Certificate with the Generation of a Certificate Signing Request (CSR).

For an additional fee, our FileCatalyst Support team can assist you with this process. The setup and debug of SSL certificates are not covered under our Support SLA.

Please contact your account representative for more details. This fee is waived if the SSL Certificate is purchased from FileCatalyst. 

These instructions assume you acquired your certificate containing a full chain.

Note: To renew or upgrade an existing certificate please follow the same steps as for a new certificate, however, use a different name for the keystore file, for example, -keystore .keystoreNew

Quick Links to Sections in this article:

Environment

FileCatalyst Workflow
Tomcat 9.0
 

Resolution

Prerequisites

An installation of Java JDK is required to proceed. The keytool and java commands must be recognized system-wide. 

Amazon Corretto Windows Installer: https://corretto.aws/downloads/latest/amazon-corretto-8-x64-windows-jdk.msi

Windows  Documentation: https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/windows-7-install.html  

Amazon Corretto Linux Installer: https://corretto.aws/downloads/latest/amazon-corretto-8-x64-linux-jdk.tar.gz

Linux Documentation: https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/generic-linux-install.html  

Generate CSR and Keystore Container

By default Tomcat will expect the password to be "changeit". If you choose a different password you will have to make an additional change in the server.xml file.

  1. Open a Command Prompt.

  2. Create a new folder on your system to store the Tomcat SSL. We used the following command:

    mkdir C:\Tomcat-SSL\

  3. Navigate to the Tomcat-SSL directory, by using the command:

    cd C:\Tomcat-SSL\

  4. Steps to Java Keystore File:

    Use the keytool command to create the CSR. Use the following command to execute the process:

    keytool -keysize 2048 -genkey -keyalg RSA -alias tomcat -keystore companyssl.jks

    Fill out the prompts:

    Note: When prompted for the first and last name, DO NOT type your first and last name. Instead, type the Fully Qualified Domain Name (FQDN) for the site you are securing with this certificate (e.g., www.yourdomain.com, mail.yourdomain.com). Are you are ordering a Wildcard Certificate? Then your FQDN must begin with an asterisk (*). (e.g.,*.yourdomain.com).



  5. In the last step, specify the same password (changeit) for the companyssl.jks and the keyEntry. If there was an error in the process you will receive the following error message when you restart the Tomcat Engine: 

    java.security.UnrecoverableKeyException: Cannot recover key

  6. --IMPORTANT--
    At this point, make a copy of the companyssl.jks keystore container before you proceed. The container has your private key in it and can not be regenerated.
    --IMPORTANT--

  7. To acquire a signed SSL certificate from a vendor you will need to extract the CSR from the companyssl.jks keystore. Run the following in the command prompt:

    keytool -certreq -alias tomcat -keyalg RSA -file companyname.csr -keystore companyssl.jks

    The output of this command will yield a CSR file named companyname.csr.

    At this point, if you may wish to use a self-signed certificate which is in the keystore (companyssl.jks). You can proceed to the Install SSL Connector on Tomcat section.


Append and Import SSL Certificate to Keystore Container

Download a full chain certificate from your Certificate Authority for use with a Tomcat WebServer. These files usually are already chained with the domain certificate and the intermediate certificate with a .p7b extension.

  1. Download your domain certificate to the Tomcat-SSL directory.

  2. Import the domain certificate (p7b) into the keystore (companyssl.jks) using the following command:

    keytool -import -alias tomcat -file your_site_name.p7b -keystore companyssl.jks

  3. You should get a confirmation that the Certificate reply was installed in keystore.

  4. If you are prompted to trust the certificate, type y or yes.

  5. The installation of this file loads all necessary certificates to your keystore.

    Your keystore file (your_site_name.jks) is now ready to be used on your Tomcat Server. Now, you can proceed to the Install SSL Connector on Tomcat section



Install SSL Connector on Tomcat

In Tomcat there are many different ways to configure your connector. The example below uses a hardened and secure connector which supports the following clients and connections:

  • Android 4.4.2 and later
  • Firefox 32 and later
  • IE 11 and later
  • IE Mobile 11 and later
  • Java 8 b132
  • Safari 7 and later
  • TLSv1.2

If you would like to use a less secure connector you can use the example shown here:

https://wiki.owasp.org/index.php/Securing_tomcat#Sample_Configuration_-_Good_Security 

For a more secure connection use the following steps to implement the connector:

  1. Shut down the Tomcat WebServer.

  2. Create a copy of the server.xml file located in <path-to-tomcat>/conf/.

  3. Open server.xml in a text editor and add the following connector:

    <Connector port="443"
    protocol="org.apache.coyote.http11.Http11NioProtocol"
    SSLEnabled="true"
    maxThreads="150"
    scheme="https"
    secure="true"
    keystoreFile="c:\Tomcat-SSL\companyssl.jks"
    keystorePass="changeit"
    clientAuth="false"
    sslProtocol="TLSv1.2"
    sslEnabledProtocols="TLSv1.2"
    ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
    />

  4. Save the file and start the Tomcat WebServer. 

    Specify the path to your keystore file in keystoreFile="c:\tomcat-ssl\companyssl.jks". If your keystore password is not "changeit" then make the change to keystorePass="changeit" in the factory element. If a specific port does not need to be specified in the URL, such as https://mycompany.com:<port>, then port 443 should be specified in the connector. This change will provide seamless integration.

    Once your Tomcat Server is back online you can test the SSL on  your webpage (https://mycompany.com:<port>) here: https://www.sslshopper.com/ssl-checker.html


Useful Tomcat Security Articles

Overview

This document outlines the files and folders that are needed for a recovery scenario.

 

Environment

FileCatalyst Direct Suite v3.4 and later.

  

Resolution 

FileCatalyst Direct Server:

  • Data
    Assuming your data is not being stored on a mounted device with its own backup process, the data directory will need to be backed up.

  • Database
    FileCatalyst Server database is labelled .fcdb. This is backed up internally in our \FileCatalyst Server\backup\ folder daily and on service restarts.


  • Configuration
    FileCatalyst Server uses a file labelled fcconf.conf. This is backed up internally in our \FileCatalyst Server\backup\ folder daily.

FileCatalyst HotFolder:

  • Configuration
    We use a configuration file named fchf.conf. This backed up internally in the \FileCatalyst HotFolder\backup\ folder daily.
    Additionally, HotFolder uses three XML files which are also backed up daily:

    • hotfolders.xml
    • sites.xml
    • schedule.xml

FileCatalyst Workflow (or Webmail):

  • Data
    The data will be stored on the associated FTP server. This will be either external (on the same hardware, or remote) or internal. 
    Internal data will be stored in \workflow-config\ftproot\ or \fcweb-config\ftproot\, depending on your product.

  • Database
    The database is your MySQL backend and dump files can be scheduled with MySQL Workbench tool.
    If you have not yet migrated from the default HSQL Database to a MySQL Database you must do so. The HSQL Database is for testing purposes only and is not intended for use in a production environment.

  • Workflow (Webmail) Configuration
    All of the necessary files are located in \workflow-config\ or \fcweb-config\, depending on the product. The specific path to the Configuration Folder is located under the About FileCatalyst page in the FileCatalyst Workflow (or Webmail) deployment. 
If you are using FileCatalyst Webmail or Web Workflow with MySQL 4 or higher and the system during heavy usage hours becomes unstable, slow, freezes or is not responding.
Restarting Tomcat, temporarly clears these problems.

Please make the following change to MySQL configuration.

Edit
On Windows:
C:\Program Files\MySQL\MySQL Server 5.0\my.ini (use the path as configured on your server)

On Linux:
/etc/my.cnf

And add the following lines:

max_connections=400
max_user_connections=150

The default value of max_connections is 100 and the default value max_user_connections is 40.


Overview

By default, anonymous job submissions are enabled on the FileCatalyst Workflow deployment. If one of your requirements is to have Anonymous Job Submissions disables follow the instructions in this article.

Environment

FileCatalyst Workflow v4.8 and later.

Resolution

  1. Log into FileCatalyst Workflow as the Super Admin User. By default this account is Init.
  2. Click on Modify Configuration in the top menu bar.
  3. Select the General Settings link under the System Configuration section.
  4. Scroll down to Logon Settings section.
  5. Uncheck the Allow Anonymous Access to remove the Public Access button. 
  6. Hit Save.
  7. Clear the web browser cache and reload a new landing page. Your changes will take effect after the cache has been cleared.

 

Overview

The distribution form on FileCatalyst Workflow allows any user to submit a job and add multiple email addresses to the sender list. An administrator of the Workflow deployment can view who has accessed or downloaded the files from the email link. This feature is not shown by default, however, it can be added to the Manage Jobs page easily. The list will show the administrator or an admin user 

The list uses a red x or a green check mark to denote whether those specific email addresses have tried to access the download page. Follow the steps in the Resolution section to add this checklist to the Manage Jobs page.

Environment

FileCatalyst Workflow v4.9.6 and later.

Resolution

To deploy this solution you will need to access the FileCatalyst Workflow deployment as the Super Admin User. Use the following guide to add the Job Transmittal list to the Manage Jobs page:

  1. Login to the FileCatalyst Workflow deployment as the Super Admin User. By default, the username is init and the password is aaaaa.
  2. Navigate to the Manage Jobs page from the top menu bar.
  3. At the top of the Job List, click on Add a field. Select Download Transmittal List from the list, a new column populated with email addresses will appear.

Note:

The steps outlined in the Resolution can also be applied to an Admin user accounts and Regular user accounts as well. For Regular User accounts the Manage Jobs page can be found by clicking View Jobs. 

Overview
Many clients who have deployed FileCatalyst Workflow in a Linux environment will have other applications that could change the default character set used by the Operating System. This change could be made in the background and may not be visible to the user.

When a system does not use the UTF-8 character set, there may be some issues when rendering file names. Some customers have experienced issues with users trying to download files with Chinese, Japanese, Russian, Cyrillic, Italian and other non-English characters. Tomcat has the ability to set the system’s default character set when the service starts. 

Environment
Apache Tomcat v7.0 and v8.0.

Resolution
The following steps will help you add the property to set the system’s default character set to Tomcat’s startup script:
  1. Locate the startup.sh file inside /Tomcat-Home/bin/ folder.
  2. Using a text editor such as vi open startup.sh.

    Insert the following line after the commented section called:

    # -----------------------------------------------------------------------------
    # Start Script for the CATALINA Server
    # -----------------------------------------------------------------------------

    export JAVA_OPTS="-Dfile.encoding=utf-8"

  3. Save the file and close the editor.