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:

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

• For a more in-depth guide for Mac OSX, Linux and Other Windows Platforms look at this guide: https://support.rackspace.com/how-to/modify-your-hosts-file/

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.

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.

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

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

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

8. 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.

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.

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:
   
   
   
   
   

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

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.

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:

• 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
• Remove Helper Links Box

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:

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.zip. http://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.

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:

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: 

• Windows
• MacOSX
• Linux

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.

• Visit the FileCatalyst Direct Server link on the AWS Marketplace: https://aws.amazon.com/marketplace/pp/B089J6KTTW  
  
  
• Click Continue to Subscribe.  You will need to sign into your AWS Account to continue.