Administrator s Guide June 2008

(1)

Administrator’s Guide

June 2008

Biscom, Inc. | 321 Billerica Rd. | Chelmsford, MA 01824 tel 978-250-1800 | fax 978-250-4449

(2)

Copyright  2008 Biscom, Inc. All rights reserved worldwide. Reproduction or translation of this publication (in part or whole, in any form or by any means) is forbidden without the express written permission of Biscom, Inc.

(3)

Notice

Information furnished by BISCOM, Inc. is believed to be accurate and reliable. However, no responsibility is assumed by BISCOM, Inc. for its use, or any

infringement of patents or other rights of third parties, which may result from its use. No license is granted by implication or otherwise under any patent or patent rights of BISCOM. BISCOM reserves the right to change hardware and software at any time without notice. Information provided in this manual is subject to change without notice.

(4)

v

Section 1: Introduction

Topics

This Installation Guide is written for system administrators who will be installing, configuring, and maintaining the Biscom Delivery Server application and servers. This guide is for both Windows and Linux versions; places where Windows or Linux specific information differs are noted. This guide will cover the following topics:

 Hardware and software requirements

 Installing, configuring, and customizing the application

 Licenses

 Starting and stopping the application

 Backing up the application data

 Considerations when scaling the application

 API development

 Support and troubleshooting

Conventions

The following conventions are used in this guide: Italic

is used for file, variable, and function names. It is also occasionally used for emphasis or to highlight key terms when they are first used or introduced.

Fixed width font

is used for code examples, file names, and other operating system text or commands. If punctuation and other symbols are used with this style, enter them exactly as shown.

Fixed<variable>

is used to show a string that contains both fixed and variable text. The variable text is usually left as a placeholder to indicate an area that the user or administrator may customize, such as the directory location in which an application is installed.

$ <command> [ param1 | param2 | param3 ]

is used in Linux environments to indicate that a command or script should be run from a terminal window. Square brackets indicate that a parameter or additional value should be entered – the vertical bar indicates that one parameter or value should be chosen.

(8)

2

This document uses Windows file system conventions, e.g. backslashes denote directory separators. If you are using Linux, you should replace backslashes with forward slashes as appropriate. If there are significant differences in the Windows and Linux information, it will be described separately.

For the purposes of this document, <BDS HOME> will be used as the location on the server where Biscom Delivery Server was installed. For example, this directory may be:

Windows:

C:\Program Files\Biscom Delivery Server

Linux:

(9)

Section 2: Hardware and Software Requirements

Server Hardware

Biscom Delivery Server will run on any hardware that is capable of running Microsoft Windows 2000 or higher operating systems, Linux, Solaris, and

other Unix-based operating systems. For better performance, we recommend installing Biscom Delivery Server on a machine with a CPU with

processing power equivalent to an Intel Pentium 4 running at 2GHz or greater and 2 GB of RAM or more.

The files, packages, reports, metadata, and other Biscom Delivery Server-specific data can be stored on the local hard drive. It is preferable to use a separate storage subsystem that supports redundancy via RAID array or other high availability techniques.

Biscom Delivery Server consists of multiple tiers that run different aspects of the application, including the Web tier, application server tier, and the back-end tier (database and file system). Each tier may be run on separate machines that may be physically located in separate areas of the network for security reasons. The Web tier must reside on a machine that is network accessible to end users who use Biscom Delivery Server through a Web browser, including those who may be external to your network.

For installation on a single machine, the onboard hard drive should be large enough to support the operating system with an additional 500 MB of space for the

components, including the Web server, application server, database server, and the Biscom Delivery Server application. This does not include space for storing packages and deliveries. Make sure to allocate enough storage space for your anticipated usage.

We recommend having a dedicated machine or machines for use with Biscom Delivery Server. We do not recommend installing Biscom Delivery Server on existing servers that are currently used for other applications.

Server Software

Biscom Delivery Server runs on Microsoft Windows 2000 and higher operating systems, several distributions of Linux, and Solaris. You must be an administrator of the server to install Biscom Delivery Server.

Biscom Delivery Server ships with several components such as the Java Development Kit, the Apache Web server, Jakarta Tomcat Java application server, MySQL

database, and JK Connector. If you are performing a typical/standard installation, these components will be installed for you.

BDS also supports Microsoft SQL Server 2005 on Windows and can be used in place of MySQL. To use Microsoft SQL Server 2005, please contact Biscom’s technical support group for assistance and documentation.

Linux-Specific Requirements

The Linux installation script uses RPM (RedHat Package Management) to install the components – make sure your Linux distribution supports RPM before starting the

(10)

4

installation. Other distributions that are not RPM-compatible may be installed manually. Please contact Biscom technical support for further information and assistance.

Because certain packages are specific to the operating system and version, these are not included in the BDS distribution. Additional RPMs needed prior to installation: - apr-devel

- apr-util-devel - httpd-devel

Please make sure your system has the necessary packages installed for your distribution before installing BDS.

Mail Server

BDS uses your existing mail server for email notifications sent to delivery recipients as well as access notification to senders when a recipient has viewed a delivery. In order to send these notifications, BDS must have a mail server configured to send these messages.

After installing BDS, you can configure the mail server on the Server Configuration page in the Web application. See the section on server configuration later in this manual for detailed instructions.

Client Software

Biscom Delivery Server client software includes the Outlook Add-in and the Biscom Delivery Manager. The Outlook Add-in integrates with Microsoft Outlook and adds a Secure Message button to the Outlook toolbar. Biscom Delivery Manager is a desktop client that supports drag and drop as well as multiple file upload and download to and from packages. Application and operating system requirements for the modules:

Web client: JDK 1.5 or higher (for the file upload/download applet) Outlook Add-in: Microsoft Office Outlook 2003 and 2007, .NET Framework 3.0

Biscom Delivery Manager: Windows XP, Windows Vista, JDK 1.5 or higher

(11)

Section 3: Installing, Uninstalling, and Upgrading

Biscom Delivery Server

Before you install, uninstall, or upgrade your server, make sure you are an

Administrator of the system with permissions to install and run applications. Note that you should not use the installer for upgrading an existing installation. Installation may destroy data in an existing installation. See the upgrade instructions below if you are upgrading an existing installation and want to preserve any existing data.

Installing Biscom Delivery Server

Windows:

1. Shut down IIS or any other web servers that are currently running.

Note: The Windows installer automatically installs the Apache web server. If you would like to use IIS, see the section on replacing Apache with IIS (p. 13).

2. Install the application.

a. Open the directory where the installer is located, either on a CD or the download location.

b. Double-click the Biscom Delivery Server installer named:

bds-full-<version>.exe and click the Next button to get

(12)

6

c. Accept the Biscom Software End User License Agreement to proceed.

d. Enter the directory under which to install Biscom Delivery Server.

e. Select Typical or Custom configuration.

i. For Typical installation:

1. Enter the values for the following: a. Application name b. Domain name

(13)

ii. For Custom installation:

1. Select the components to install (all components are selected by default).

2. Enter the values for the following (same as typical installation step):

a. Application name b. Domain name

(14)

8

3. Enter the Web server (Apache) port if different from the default port 80.

f. Click the Install button to start installing the components and the Biscom Delivery Server application.

Linux:

Note: Unlike the Windows installer, the Linux installer does not include a Web server. Most Linux systems already have a Web server installed. If your system does not to have a Web server pre-installed, install one before installing BDS. Apache 2.0.x compiles JK connector 1.2 to link Apache and Tomcat. Apache version 2.2 and higher can use the mod_proxy.so module to perform the redirect that the JK connector would normally handle.

1. Obtain the file named:

bds-install-<version>.tar.gz

2. Untar and unzip the file using the following command:

$ tar xvfz bds-install<version>.tar.gz

3. Change directories to the newly created directory:

(15)

4. Make sure the user you are logged in as has privileges to install software on your system. This is typically an administrator or root.

5. Run the install script:

$ ./install.sh

6. Biscom Delivery Server will be installed to the following directories:

a. Application Server: /usr/local/tomcat b. BDS HOME:

/<home directory of installation user>/bds

Solaris and other operating systems:

1. Operating systems that can run a J2EE application server, Web server, and MySQL database will most likely be able to run Biscom Delivery Server. 2. Installation of the components will need to be handled manually. Please contact

Biscom technical support for assistance if you need help installing the components manually.

3. This document may not have operating specific information. For Solaris and other Unix-based operating systems, please consult the Linux-specific documentation for guidance.

Installing the Active Directory Connector

BDS has a built-in LDAP and an Active Directory connector for standard LDAP and AD environments. A separate Active Directory Connector (ADC) is available for network environments that only use AD.

ADC should be installed on a machine by a user who has the proper permissions to install a Windows service, and the service should have appropriate rights or permissions to your AD server. Typically, the ADC can be installed on the same machine on which you’ve installed BDS, but it can also be installed on a machine that has the ability to connect to both the BDS machine as well as the AD server.

If you are experiencing issues connecting to your AD server with the built-in connector, follow the steps below to install the ADC on your Windows machine.

1. Download the BDS AD Connector installer to the machine on which you will be installing the software.

2. Verify that this machine has access to the AD server.

3. Double-click the installer and follow the prompts. The installer will create a new service called “BDSADConnector”.

4. Verify that the service is installed and it has been started. If the service is stopped, start the service up. We recommend you set the Startup type to Automatic to start when the machine starts up.

(16)

10

5. From the machine on which you installed BDS, verify that you can connect to the AD Connector service. The default port for the AD Connector is 65330.

6. To configure the connection, follow the instructions in the section Manage Users with LDAP or Active Directory.

Testing the Installation

Windows:

1. Once you have installed BDS, there will be an icon on the desktop. This is a shortcut to the application server. Double-click the icon to open the sign in Web page.

2. If the sign in page does not appear, check the following: a. In Windows Computer Management, open Services and

Applications > Services.

i. Ensure that the Web server Apache2 has been started. ii. Ensure that the application server Apache Tomcat has

been started.

iii. Ensure that the database server MySQL has been started. b. You can run BDS directly from the application server without going

through the Web server. To test this, go to the URL:

http://<server domain>:8080/<application name>

For example:

http://secure-server.biscom.com:8080/bds

i. If the sign in page appears, then the Web

server/application server connection is not working. ii. If the sign in page does not appear, the application server

is not available or not installed properly.

c. Check your firewall settings to make sure that there are no restrictions on the Web server port (e.g. port 80 or 443 for SSL). d. If you find no other issues but still cannot connect, uninstall the

application (see section below), verify any existing Web server is stopped, and re-install.

Linux:

1. Open a Web browser and go to the URL:

http://<server domain>:8080/<application name>

For example:

http://secure-server.biscom.com:8080/bds

2. If the sign in page does not appear, check the following:

a. Check the status of Apache Web server and make sure it is running:

(17)

b. Check the status of the Tomcat application server and make sure there is a Tomcat process running:

$ ps waux |grep tomcat

c. Check the status of MySQL by starting up the client:

$ mysql

i. Once signed in, check the status:

> status

Make sure the Uptime value is positive.

ii. If you cannot open the MySQL client, try restarting the MySQL server:

$ /etc/init.d/mysql start

d. Check your firewall and security settings to make sure that there are no restrictions on the Web server port (e.g. port 80 or 443 for SSL).

e. If you find no other issues and still cannot connect, uninstall the application (see section below) and re-install.

Uninstalling Biscom Delivery Server

Note: Uninstalling Biscom Delivery Server will remove all user data, including all packages and deliveries. If you need to keep this data, please back up the user data before uninstalling the application.

Windows:

1. From the Start menu, go to the Biscom Delivery Server program group, and open the Uninstall Biscom Delivery Server application.

2. Select the components to uninstall (all components are selected by default). 3. Click the Uninstall button. The components will be shut down (if they are

currently running) and uninstalled.

4. After uninstalling the application, you may be asked to reboot the system. Linux:

1. Log on as the user who installed Biscom Delivery Server initially (e.g. a user with administrator or root privileges who can add/remove software). 2. Change directories to the location you extracted the tar.gz installer. 3. Run the command:

$ ./uninstall.sh

Upgrading an existing Biscom Delivery Server instance

Upgrading BDS is a non-destructive process. All data will be preserved during the upgrade, but we recommend that you perform a full backup before starting the upgrade. Upgrading BDS involves three files and an upgrade script:

 bds.war: the application

 biscom-bds.jar: a BDS library

(18)

12

 upgrade.bat (Windows) or upgrade.sh (Linux): a script to perform the upgrade

The upgrade script is able to upgrade from any previous version to the latest version automatically. Follow the instructions below for your operating system.

Note: You should back up your data before performing an upgrade, including the data directory, recycle bin directory, configuration files, custom style sheets and logos, and log files. You should also export and back up all database data. See the section below on backing up your data.

Windows:

1. From your CD or from the download location, find the upgrade files. The files required for upgrading are:

a. bds.war

b. biscom-bds.jar

c. biscom-shared.jar

2. Shut down the application server (e.g. Apache Tomcat) through the Manage Services screen. Note that the Web server does not need to be shut down.

3. Delete any cached versions in the following folders under Tomcat:

a. <BDS HOME>/components/tomcat-5.5/webapps/bds

b. <BDS HOME>/components/tomcat-5.5/work/Catalina

4. In the existing installation, back up all files in the lib directory (<BDS HOME>/lib).

5. Copy the three upgrade files to the lib directory.

6. Open a command window and go to the <BDS HOME>/tools directory.

7. Run upgrade.bat.

8. In the Manage Services screen, restart the application server and the server should be back up.

9. Log on to the Web application and go to the System and User

Administration > Server Information page and verify the version

(19)

Linux:

1. Log on as the administrative user who initially installed the application. 2. From your CD or from the download location, find the upgrade files. The

files required for upgrading are:

a. bds.war

b. biscom-bds.jar

c. biscom-shared.jar

3. Shut down the application server (e.g. Apache Tomcat):

$ su <- must be logged in as root

$ /etc/init.d/tomcat stop

$ ps waux |grep java <- check until the Tomcat

process is no longer running

$ exit <- exit back into the admin

user which installed the application

4. Delete any cached versions in the following folders under Tomcat:

$ rm -r /usr/local/tomcat/webapps/bds* $ rm -r /usr/local/tomcat/work/Catalina

5. In the existing installation, back up all files in the lib directory (<BDS HOME>/lib).

6. Copy the biscom-shared.jar and biscom-fm.jar upgrade files to the

lib directory.

7. Copy the application bds.war to the webapps directory in Tomcat:

$ cp bds.war /usr/local/tomcat/webapps

8. Go to the tools directory and run the upgrade script:

$ cd ~/bds/tools $ ./upgrade.sh

9. Restart the application server:

$ su <- must be logged in as root

$ /etc/init.d/tomcat start

Using IIS as your Web Server on Windows

On Windows servers, IIS can be used instead of Apache. Apache does not need to be uninstalled, but Apache should be shut down through the Computer Management

(20)

14

console and startup should be manual so it does not start automatically when Windows starts. IIS requires a DLL that will redirect requests from the Web server to the application server.

1. Ensure that IIS is installed and running. Visit http://localhost and verify that the IIS page comes up.

2. Ensure that BDS is installed and running by accessing BDS through the application server directly. Visit http://localhost:8080/bds and verify BDS is running.

3. Verify that you have the following files saved in the application server configuration directory (e.g. C:\Program Files\Biscom Delivery Server\components\tomcat-5.5\conf):

a. workers.properties b. uriworkermap.properties c. isapi_redirect.properties d. isapi_redirect.dll

4. Open isapi_redirect.properties and update the properties to match your local configuration (e.g. if you selected an installation directory different than the default directory, you will need to update the property values accordingly). Sample file:

# Configuration file for the Jakarta ISAPI Redirector

# The path to the ISAPI Redirector Extension, # relative to the website

# This must be in a virtual directory with execute

# privileges

extension_uri=/tomcat/isapi_redirect.dll # Full path to the log file for the ISAPI Redirector

log_file=c:\Program Files\Biscom Delivery

Server\components\tomcat-5.5\logs\isapi_redirect.log

# Log level (debug, info, warn, error or trace) log_level=debug

# Full path to the workers.properties file worker_file=c:\Program Files\Biscom Delivery

Server\components\tomcat-5.5\conf\workers.properties

# Full path to the uriworkermap.properties file worker_mount_file=c:\Program Files\Biscom Delivery

(21)

5. Open the IIS management program: Control Panel > Administrative Tools -> Internet Information Services. Expand local computer --> Web Sites --> Default Web Site.

6. Create a virtual directory for the default web site: a. Right click the Default Web Site. b. Select New -> Virtual Directory. c. Click Next, enter tomcat as the alias.

d. Click Next, browse to the Tomcat conf directory (that contains the isapi_redirect.dll file), click OK.

e. Click Next, check the Execute checkbox. f. Click Next and finally click Finish. 7. Add an ISAPI filter for the default web site:

a. Right click the Default Web Site. b. Select Properties.

c. Click on the ISAPI Filters tab. d. Click Add...

e. Specify tomcat as the Filter Name

f. Browse and select isapi_redirect.dll in the Tomcat conf directory as the Executable

g. Click OK.

h. Click OK again to close the properties.

8. Verify Directory Security settings by opening the properties for the web site: a. Select Directory Security -> Edit Authentication and Access Control. b. Make sure that anonymous access if checked, and all authenticated

access checkboxes are unchecked.

9. On Windows 2003 Server, IIS has a Web Service Extensions folder. Select this folder and open the Add a new Web service extension from the right-click menu or from the links to the left of the list of extensions.

10. Name the extension (e.g. "Tomcat"). a. Add the file isapi_redirect.dll.

b. Check the Set extension status to Allowed checkbox. c. Click OK to add the extension.

11. Ensure IIS and Tomcat are running. Open a browser window and enter the URL: http://localhost/bds/Login.do. If everything is set correctly,

the BDS sign in page should come up.

12. To troubleshoot, refer to the ISAPI log file specified in the isapi_redirect.properties file.

(22)

16

Using SSL

Biscom Delivery Server supports the use of SSL (Secure Sockets Layer) to encrypt all transmissions between the client Web browser and the Web server. When Biscom Delivery Server is installed, SSL is not installed by default. SSL must be installed and configured after Biscom Delivery Server is installed. We recommend all users to log on to Biscom Delivery Server using SSL to ensure the highest level of security. SSL installation is independent of the Biscom Delivery Server application. Refer to your Web server documentation or Certificate Authority documentation for information on obtaining and installing an SSL certificate on your Web server.

Installing SSL on Apache 2 for Windows

1. Make sure Apache is running and working on port 80 (http). 2. Update the Apache configuration file located here: <BDS HOME>/

/components/Apache-2.0/conf/httpd.conf. a. Add: Listen 443

b. Update: ServerName <your server domain name>

c. Update: DocumentRoot <BDS HOME>/components/Apache-2.0/htdocs

example: DocumentRoot "C:/Program Files/components/apache-2.0/htdocs"

3. Start the Apache server and test the 443 port is working by going to the URL http:/yourdomain.com:443/ -- it won't be encrypted but it should show a valid web page.

4. Get OpenSSL and mod_ssl to generate a certificate signing request (CSR). Sites such as http://www.openssl.org and

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html may have the source code or binary files necessary. Our example will use Apache 2.0.54 and OpenSSL version 0.9.8a.

a. Unzip: Apache_2.0.54-Openssl_0.9.8a-Win32.zip b. Copy: bin\ssleay32.dll to WINNT\System32 c. Copy: bin\libeay32.dll to WINNT\System32 d. Copy: bin\OpenSSL.exe to a working directory

e. Copy: ssl.conf to <BDS HOME>/components/Apache-2.0/conf/ f. Update ServerName and DocumentRoot

g. Copy: openssl.cnf to the same working directory 5. Create a test certificate.

a. Open a cmd window and navigate to the working directory that contains openssl.exe

b. Enter command to create the CSR: openssl req -config openssl.cnf -new -out my-server.csr

When asked for "Common Name (e.g., your website’s domain name)", give the exact domain name of your web server

(23)

c. Enter command to remove the passphrase: openssl rsa -in

privkey.pem -out my-server.key

d. Enter command to generate a certificate: openssl x509 -in my-server.csr -out my-server.cert -req -signkey

my-server.key -days 365

e. Create directory: <BDS HOME>/components/Apache-2.0/conf/ssl f. Copy: my-server.cert and my-server.key to the ssl directory 6. Configure Apache and mod_ssl.

a. Copy: mod_ssl.so to <BDS HOME>/components/Apache-2.0/modules

b. Update httpd.conf and uncomment: LoadModule ssl_module

modules/mod_ssl.so

c. Add to the end of http.conf:

SSLMutex default

SSLRandomSeed startup builtin SSLSessionCache none <VirtualHost my-server:443> SSLEngine On SSLCertificateFile conf/ssl/my-server.crt SSLCertificateKeyFile conf/ssl/my-server.key </VirtualHost> d. Edit ssl.conf

i. Enter path to the certificate for: SSLCertificateFile conf/ssl/my-server.crt

ii. Enter path to the key for: SSLCertificateKeyFile conf/ssl/my-server.key

7. To generate a valid certificate for use in your production site, you must contact a Certification Authority (CA) such as Verisign, GeoTrust, Comodo, GoDaddy, etc., and provide your CSR.

Installing SSL on Apache 2 for Linux

1. Make sure Apache is running and working on port 80 (http). 2. Update the Apache configuration file located here:

/etc/httpd/conf/httpd.conf. a. Add: Listen 443

b. Update: ServerName <your server domain name>

3. Start the Apache server and test the 443 port is working by going to the URL http:/yourdomain.com:443/ -- it won't be encrypted but it should show a valid web page.

4. Make sure OpenSSL is installed and in your PATH.

5. Create a RSA private key for your Apache server (will be Triple-DES encrypted and PEM formatted):

(24)

18

Note: Although this is the more secure method, this will create a key that will require a password to be entered on every service restart. If you wish to omit the password for unattended restarts, use the following command:

$ openssl genrsa -out my-server.key 1024

6. Create a test certificate.

a. Enter command to create the CSR: openssl req -new key my-server.key -out my-server.csr

When asked for "Common Name (e.g., your websites domain name)", give the exact domain name of your web server b. Enter command to generate a certificate: openssl x509 -in

my-server.csr -out my-server.cert -req -signkey

my-server.key -days 365

c. Copy: my-server.cert and my-server.key to the Apache conf directory (e.g. /etc/httpd/conf)

7. Configure Apache and mod_ssl.

a. Ensure mod_ssl.so exists in the /etc/httpd/modules directory. b. Ensure that mod_ssl is being loaded: LoadModule ssl_module

modules/mod_ssl.so

c. Ensure ssl.conf is being included in http.conf:

Include /etc/httpd/conf.d/ssl.conf

d. Edit ssl.conf

i. Enter path to the certificate for: SSLCertificateFile /etc/httpd/conf/ssl.crt/my-server.crt

ii. Enter path to the key for: SSLCertificateKeyFile /etc/httpd/conf/ssl.key/my-server.key

8. To generate a valid certificate for use in your production site, you must contact a Certification Authority (CA) such as Verisign, GeoTrust, Comodo, GoDaddy, etc., and provide your CSR.

Troubleshooting SSL:

- Look at the following tutorials:

http://www.thompsonbd.com/tutorials/apachessl.php http://raibledesigns.com/wiki/Wiki.jsp?page=ApacheSSL

- If Apache doesn't start from the Service, look at the Application Log under Event Viewer/Application for useful debugging information.

- To test the certificate, try the following:

openssl s_client -connect my-server:443

This should return something like:

Loading 'screen' into random state - done CONNECTED(000006CC)

depth=0

/C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU=Biscom Delivery

(25)

Server/CN=bho2.biscom.com/[email protected] verify error:num=18:self signed certificate

verify return:1 depth=0 /C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU=Biscom Delivery Server/CN=bho2.biscom.com/[email protected] verify return:1 --- Certificate chain 0 s:/C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU=Biscom Delivery Server/CN=bho2.biscom.com/[email protected] i:/C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU=Biscom Delivery Server/CN=bho2.biscom.com/[email protected] --- Server certificate ---BEGIN CERTIFICATE--- MIICrTCCAhYCCQCBh4xGGXMbfjANBgkqhkiG9w0BAQUFADCBmjELMAkG A1UEBhMC VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcTCkNoZWxt c2ZvcmQx DzANBgNVBAoTBkJpc2NvbTEUMBIGA1UECxMLRmlsZU1hcnNoYWwxGDAW BgNVBAMT D2JobzIuYmlzY29tLmNvbTEdMBsGCSqGSIb3DQEJARYOYmhvQGJpc2Nv bS5jb20w HhcNMDYwMzE1MDI0NDA0WhcNMDcwMzE1MDI0NDA0WjCBmjELMAkGA1UE BhMCVVMx FjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcTCkNoZWxtc2Zv cmQxDzAN BgNVBAoTBkJpc2NvbTEUMBIGA1UECxMLRmlsZU1hcnNoYWwxGDAWBgNV BAMTD2Jo bzIuYmlzY29tLmNvbTEdMBsGCSqGSIb3DQEJARYOYmhvQGJpc2NvbS5j b20wgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKM0mZSfyg5ZpNBVRLTRKStl ZWB9mDL7 iMTm8Yqu2nVJZkfIXCIol9sa/s8cWFC9a7Loq81l4vpdjXKv20W2vapA p5dRulRK lnMJkpK9X3m//xgy6hagIWbG1AMN4GYM3PB6AvM1wEEX2I5bArBdQV5e +uCoiti4 QJX7COnUzWRjAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAa48B5Fy8pAFG ekHoXyhg azQiuRS9ya4by7DsM9QgC7ZrzDkJm1Ho4WKthiVyqAA+Rtx+FbgDlC5T TGLwoSdl sAsQjGudrtdLwdYicxsQl+rpZ1uIKUZl8ErKKvPTyjIJBgF0RDqstjoZ Lp3ZEZrI QL05FQdwFRFyFcuy/xgoS8o= ---END CERTIFICATE--- subject=/C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU= Biscom Delivery

(26)

20 Server/CN=bho2.biscom.com/[email protected] issuer=/C=US/ST=Massachusetts/L=Chelmsford/O=Biscom/OU=B iscom Delivery Server/CN=bho2.biscom.com/[email protected] ---

No client certificate CA names sent ---

SSL handshake has read 1221 bytes and written 346 bytes ---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit

Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: Session-ID-ctx: Master-Key: 9215F52BD24683629C2D2E360437AD4662995667E76BDD37A62A1030 67D7B446 0FD146F8370EA4582018078EEBC59E04 Key-Arg : None Start Time: 1142393894 Timeout : 300 (sec)

Verify return code: 18 (self signed certificate) ---

(27)

Section 4: System and Application Configuration

Biscom Delivery Server uses a properties file named fds.properties to configure several

server settings. Other Biscom Delivery Server configuration is handled through the Web application.

The configuration file is located in the config directory under the location that Biscom Delivery Server was installed, e.g. <BDS HOME>\config\fds.properties.

System Configuration through fds.properties

Any time the configuration file is updated, you will need to restart the application server. See the section below on starting and stopping the application.

The configuration file has the following format:

################ Server Configuration ################ domainName = bds.my-server.com appName = bds docRoot = c:\\apps\\bds\\data protectedRecycleBinDir = c:\\apps\\bds\\recyclebin licenseFile = c:\\apps\\bds\\license\\license.xml timezone = America/New_York ldapConfFilename = c:\\apps\\bds\\config\\ldap.conf ldapDefaultDomain = biscom.com ldapDefaultTimeout = 5

Note: The backslash used to separate directory names in Windows must be escaped by using another backslash. Any directory locations using

backslashes must be escaped in the properties files. For Linux, the double backslashes should be replaced with a single forward slash.

These properties can be updated to meet the specific needs of your organization:

 domainName: The hostname of the machine that Biscom Delivery Server has been installed on. By default, this value is set to localhost.

 appName: The application name. This appears in the URL after the domain name, e.g. https://<domainName>/<appName>.

 docRoot: The location of the user data files (note that this is not the Web server document root).

 protectedRecyleBinDir: The location where the system places deleted files (e.g. when a user deletes a package). The system permanently deletes these files periodically using the cleanup process (described later).

 licenseFile: The location in which the license file resides. See the section on Licenses for more information.

(28)

22

 ldapConfFilename: This points to the LDAP configuration file. This is an internal property and should not be changed by the administrator.

 ldapDefaultDomain: The default domain to use if no domain is specified when a user signs into the application. If this is defined, administrators may want to hide the domain field in the sign in page to reduce potential confusion for the user.

 ldapDefaultTimeout: The default timeout for LDAP queries.

Server Configuration through the Application

Several aspects of server configuration are handled through the application’s interface. Most of the configuration is application-specific rather than server-specific. This is covered in the System and User Administration section. Changes to the application configuration do not require a system restart.

(29)

Section 5: Encryption Module

BDS supports back-end encryption for files that are stored in the file system. BDS uses Advanced Encryption Standard (AES), a symmetric key encryption algorithm that is the current NIST-approved encryption algorithm, to encrypt files. Encryption is an optional module and can be enabled or disabled using a command line utility. Key management is also performed using the command line utility.

Encryption and Decryption

When you enable encryption, files that are uploaded and saved in packages are encrypted automatically. When an encrypted file is downloaded, BDS automatically decrypts the file and sends the unencrypted file to the requester.

Keys and Key Management

AES is a symmetric encryption algorithm that uses secret keys to perform the encryption. Managing these keys is an important aspect of encryption, and includes tasks such as key generation, selection, storage, and backup.

The secret keys used to encrypt files are also stored on the file system in an encrypted format. BDS internally manages the encryption of the secret keys. The encrypted keys are stored by default in the <BDS HOME>/kr directory. This location

can be changed using the utility.

When you enable encryption for the first time, a secret key is generated. The generated key will be selected as the default secret key for BDS. You can generate additional keys later, and change the default key to one of the newly generated keys. Additional key management features, such as removing keys, can be found in the utility’s Advanced Options.

Encryption Utililty

The encryption utility is a command line tool that is accessible only to BDS users with the Administrator role. The utility is available in the <BDS HOME>/tools directory, and can be started by running enctool.bat on Windows, and enctool.sh on Linux.

Note: Before starting the encryption utility, all BDS components should be shut down.

C:\BDS\tools>enctool.bat

NOTE: All BDS components must be shut down before using this tool. Please verify that all BDS components have been shut down. Then enter C to continue or X to exit.

(30)

24

Username: admin1 Password: ******

If sign in succeeds, the user will see the current encryption setting and the main menu:

Encryption is not enabled.

Main menu:

1. Enable/Disable encryption 2. Encrypt file system

3. Decrypt file system 4. List keys

5. Create a new key

6. Change key storage location 7. Change the default key 8. Advanced options

9. Exit

Option:

Enable/Disable encryption

This menu item will be Enable encryption if the current system is not encrypted. If the system is already encrypted, then the menu will be Disable encryption.

If encryption is enabled, all files uploaded from that point forward will be encrypted. Existing files stored in unencrypted form will not be encrypted automatically. If encryption is disabled, all files uploaded from that point forward, will not be encrypted. Existing files that are encrypted will not be automatically decrypted. Because this option can be toggled at any time, it is possible that some files in the system may be encrypted while others will not. The system handles both encrypted and unencrypted files automatically and no input or maintenance is needed by an administrator.

Encrypt file system

If encryption is enabled, then selecting this option will encrypt all unencrypted files in the file system. This is a potentially lengthy operation, and time considerations should be factored in before selecting this option.

Example:

Are you sure you want to encrypt all unencrypted files (Y/N)? Y

(31)

Processing file 386 of 4828 (8% complete); Time remaining: 1 hr 29 min

When all files have been processed, the following should be displayed:

Encrypted 4828 files. Total time: 1 hr 20 min. Press any key to continue...

Decrypt file system

Decrypting the entire file system will decrypt all encrypted files in the file system. Like the encryption option, this is potentially a lengthy operation and should be considered before proceeding.

Example:

Are you sure you want to decrypt all encrypted files (Y/N)? Y

Processing file 3476 of 4828 (72% complete). Time remaining: 23 min

Decrypted 4828 files. Total time: 41 min. Press any key to continue...

Listing keys

This option lists all existing keys used in the system. The current key used for encryption will be highlighted.

Example:

1. k1 07/04/07 2. k25 12/26/07

3. k1003 01/01/08 default

Press any key to continue...

Creating a new key

This option is used to add a key to the system. Keys are generated automatically by the system and no input is required from the user.

Example:

(32)

26

Changing key storage location

The default storage location is <BDS_HOME>/kr. Use this option to change the location.

Example:

Current directory for keys: C:\BDS

Are you sure you want to change the directory (Y/N)? Y Please enter new directory: D:\SecretKeyLoc

Directory for storing keys updated successfully. Press any key to continue...

Changing the default key

To change the default key used to encrypt files, select the key from the list of keys. When the default key is changed, all files moving forward will be encrypted using the new default key. Existing files will not be re-encrypted. To change all existing files to use the new default encryption key, set the default key here, and then encrypt the entire file system using the Advanced Options menu (see below).

Example:

List of keys:

1. k1 07/04/07 2. k120234 12/26/07

3. k1230 01/01/08 default

Are you sure you want to change the default key (Y/N)? Y Please enter the number of the key you want to select as default: 2

Default key changed to k120234 successfully.

Advanced options: encrypt full file system

The encryption option in Advanced Options provides the ability to change the encryption of all files, including existing files encrypted using different keys. (The standard encryption option, described above, only encrypts unencrypted files, and leaves encrypted files alone.)

Example:

(33)

Processing file 3882 of 32357 (12% complete); Time remaining: 9 hr 20 min

Encrypted 32357 files. Total time: 10 hr 29 min.

Advanced options: remove a key

Removing keys from the system requires all files encrypted using the key to be decrypted first. If encryption is currently set to “enabled,” the files must also be re-encrypted using the default encryption key. Once all files have been decrypted, the selected key is removed from the system.

Example:

List of keys:

1. k120234 12/26/07

3. k1230 01/01/08 default

Are you sure you want to remove a key (Y/N)? Y

Please enter the number of the key you want to remove: 1 Are you sure you want to remove key k120234 (Y/N)? Y

Processing file 3781 of 8795 (43% complete) encrypted using key k120234; Time remaining: 2 hr 23 min

Processed all files encrypted using key k120234. Key k120234 has been removed.

(34)

28

Section 6: Licenses

Licenses

Biscom Delivery Server installs a 30-day trial license by default, which supports five Senders and unlimited recipients. Biscom Delivery Server licenses are XML files that contain information on product features and licensed modules. The license requires a valid license key and serial number. These are used in conjunction to verify the validity of the license. Modifying these values (e.g. the product, module, expiration date, maximum senders, or other features) will invalidate the license.

A license will have the following structure:

<?xml version="1.0" encoding="UTF-8"?> <bds-licenses> <license key="001242w120fd87e1a7d110650d3403lep90"> <product>bds</product> <module>base</module> <serial-number>trial</serial-number> <expiration>d30</expiration> </license> </bds-licenses>

To install a new license, obtain the license XML file and place it in the license directory (as specified in the fds.properties configuration file). Open the

fds.properties file and update the value for the licenseFile property by

specifying the name and directory location of the license file. See the section on System and Application Configuration for more information on the fds.properties

file.

After copying the license to the proper license location, stop and restart the application server to enable the new license.

(35)

Starting and Stopping the Application

Starting the Application

The installation scripts normally start up the applications upon completion or after a server reboot. But in cases where the application is not running, use the following steps to start the application.

Windows:

1. Log on to the computer with a user that has privileges to start and stop Windows services.

2. Open the Windows Services manager by going to Start Menu > Control Panel. Double-click the Administrative Tools icon, and then double-click the Services icon.

3. Start up the services in the following order if not already started: a. Database (MySQL by default).

b. Web server (Apache2 by default).

c. Application server (Apache Tomcat by default). Biscom Delivery Server should now be running and accessible.

Linux:

1. Log on to the computer as a user that has privileges to start and stop the application server, web server and database server (often an administrator or root).

2. Ensure the Web server is running. This will vary from system to system – use the command you are most comfortable with. For example, the following command may be used:

$ /etc/init.d/httpd [ start | restart ]

3. Ensure the database is running. This will vary from system to system – use the command you are most comfortable with. For MySQL, the following command may be used:

(36)

30

4. Start up the application server. For Apache Tomcat the following command may be used:

$ /etc/init.d/tomcat [ start | restart]

Biscom Delivery Server should now be running and accessible.

Stopping the Application

To stop the application, simply shut down the application server. Some changes to the configuration will require a restart of the application server. The Web server and database server usually do not need to be shut down and restarted for configuration updates.

Windows:

1. Log on to the computer with a user that has privileges to start and stop Windows services (usually an Administrator of the system).

2. Open the Services manager by going to Start Menu > Control Panel. Double-click the Administrative Tools icon, and then double-click the Services icon.

3. Find the application server (e.g. Apache Tomcat) service and click the Stop button.

4. Optionally stop the MySQL and Apache2 services if desired.

Linux:

1. Log on to the computer as a user that has privileges to start and stop the application server, web server and database server.

2. To stop the application server:

$ /etc/init.d/tomcat stop

3. To stop the Web server:

$ /etc/init.d/httpd stop

4. To stop the database server:

(37)

Section 7: Signing In for the First Time

First Sign In

Now that you’ve completed the initial installation and started up the application, you’re ready to sign in for the first time. Fresh installs of Biscom Delivery Server have a single user preconfigured who has been assigned the Administrator role. The username is admin and the password is admin. This is a temporary password which should be changed as soon as possible.

One of the first tasks is to configure the application to work in your environment – setting default behavior, customizing the look and feel, and setting default

parameters. Once the system is configured properly, the next task is to create users, including other Administrators who can manage the system and users. You can create as many users with Administrator, Report, and Recipient roles. However, you are limited to creating only up to the licensed number of Senders you have

purchased.

The steps to get the server prepared for users to start sending files:

1. Specify an SMTP mail server to use to send delivery and access notifications. This is performed in the Server Configuration section and is described in more detail below.

2. Customize the application with your organization’s messages, logo, etc. The common customization done are:

a. Company name and system b. Logo

c. Text in the sign in page d. Delivery notification message e. Footer text in delivery notifications f. User registration behavior

g. Package settings and restrictions

3. Create users manually (one at a time) or import them from an XML or CSV-compatible spreadsheet. Also, if you are using LDAP or Active Directory, assign users and roles using security groups.

(38)

32

Section 8: System and User Administration

Administrators have access to system configuration and user management. From the Home page, click the System and User Administration icon or

click the System and User Administration link.

Server Information

Server information contains configuration settings and system statistics including license serial number and key, number of Senders supported by the license, users and roles currently active, pending, and disabled, and the number, size, and status of all packages and deliveries.

(39)

Server Configuration

Configuration updates are reflected immediately in the application without requiring an application server restart. Any user with the Administrator role can update the system configuration by going to System and User

Administration > Server Configuration Server Configuration

 Company name: Name of your company.

 System name: The system name that is used when a system generated email or other notification is sent to a user. This is used, for example, when a user resets his or her password – the system will notify the user via email, and the email will be signed using the system name.

Email and Notification Settings

BDS sends email notifications to recipients of deliveries, as well as to senders when a recipient has viewed a delivery. BDS leverages your existing mail server when sending notifications and you must specify your mail server to enable notification. The mail server configuration is found by signing into the Web application as an Administrator and opening the System and User Administration > Server Configuration page. Enter the mail server information and if required, any authentication information in the Email Notification Settings section.

(40)

34

 Notification mail server: Enter the SMTP server to use for sending out delivery and access notifications.

 Notification mail server username: If the mail server used to deliver notifications requires authentication, enter the username for authentication - otherwise, leave this property blank.

 Notification mail server password: If mail server authentication is required, use this property to enter the password for authentication - otherwise, leave this property blank.

 Confirm notification mail server password: Re-enter the password to confirm.

 Notification sender: Sets the notification email address that sends the notification. Set this property to SENDER to use the email address of the user who has sent the delivery.

 Notification CC address: Automatically forward all delivery notifications to the address specified in this field.

 Notification link protocol: This specifies the protocol used for the delivery URL in the notification email sent to recipients. Set to http by default. Can be set to https if an SSL certificate has been installed on the Web server.

 Notify user when password reset by an administrator: Whether to send an email to the user when an administrator resets the user’s password.

 Notify user when password reset by user: Whether to send a confirmation email to the user when the user resets his or her own password.

 System notification sender: This sets the email address from which system notifications are delivered. For example, this is the email address that Senders receive when a recipient views a delivery. If no value is entered for this property, the email address will be notify@<domain name>.

(41)

Microsoft Outlook Add-in Settings

 Allow SMTP Input (API): Set this to Yes if your server supports the SMTP API. This is an optional module.

 Outlook server: The IP address or host name of your mail server used with the Outlook Add-in.

 Outlook mail server username: The username to log onto the mail server to retrieve messages sent from the Outlook Add-in.

 Outlook mail server password: The password to log onto the mail server to retrieve messages sent from the Outlook Add-in.

 Confirm Outlook mail server password: Re-enter the password to confirm.

 Configure Outlook add-in policies: Click this link to go to the Outlook add-in configuration page to define policies and default settings. If you click this link before updating the configuration, any changes you made will be lost.

Outlook Add-in Configuration

Administrators configure the Outlook add-in settings on this page – including enabling and disabling the add-in for all users, and defining the policies such as keywords and file size limitations. See Appendix B for details on configuring the policies for the Outlook add-in.

(42)

36 Delivery Settings

 Default secure message: If text is entered for this property, it will be the default secure message used when creating deliveries.

Note: This secure message does not apply to deliveries created with the Outlook Add-in; the add-in only uses the text entered in the original message.

 Default delivery notification message: If text is entered for this property, it will be the default message used for delivery notifications. This message can be change or deleted by Senders before sending the delivery out.

Note: This delivery notification message is applied to Outlook add-in messages as the default message.

 Delivery notification footer: If text is entered for this property, it will be appended to the bottom of all notification messages. This message is always sent with the notification message and cannot be deleted by the sender. For example, a standard disclaimer or company byline can be entered.

 Delivery expires after (in days): If a number is entered for this property, it is used to calculate and enter a default delivery expiration date when a delivery or express delivery is created. A Sender can delete this expiration date before sending the delivery.

 Always require recipients to sign in: This setting allows administrators to remove the Require recipients to sign in checkbox as one of the delivery

(43)

parameters. If set to Yes, senders cannot create no sign-in deliveries, and any existing deliveries that did not require sign in will immediately require users to sign in.

 Require recipients to sign in by default: This is the value used in checkboxes for deliveries. For Outlook add-in deliveries, because the sender does not have the option to choose the sign in requirement, this value will be used. For example, if this is set to Yes, then any Outlook add-in deliveries will require sign in; if set to No, the Outlook add-in deliveries will not require sign in.

 Configure limited sender settings: Click this link to go to the limited sender configuration page and define delivery settings for users who do not have the Sender role assigned. If you click this link before updating the configuration, any changes you made will be lost.

Limited Sender Settings

View and update the limited sender settings on this page, including enabling and disabling this feature. Limited sender can be configured to give external users the ability to send files into an organization, but restricts various features that full senders can access. Deliveries created by limited senders can be viewed in the Deliveries Sent page, but cannot be edited. Other restrictions may apply, based on the settings defined in this section by an administrator.

(44)

38

 Enable limited senders: To enable limited sending for non-Senders, set this value to Yes. This will provide a delivery page with the restrictions settings defined below.

 Require sender to sign in: If this is checked, only authenticated users will have the ability to create limited deliveries. If unchecked, the limited delivery capability is available even without signing into the application. This enables administrators to provide the limited delivery form outside the application. Senders using this form will be required to enter their email address before a delivery can be created.

Note: If you do not require senders to sign in, users can

potentially create deliveries and spoof the sender’s email address.

 Recipient settings

o Allow user to type in: Select this to permit users to freely enter

any email address in the recipient field. Administrators can restrict the recipients to certain domains or even individual email addresses by entering patterns and addresses in the Restrict recipients to text box.

(45)

o Use default value: Select this to automatically send deliveries to a specific email address. The recipient can be displayed to the sender (if the Visible checkbox is checked) or hidden.

 Message settings: You can show or hide the subject field or message field to the sender. If the subject field is hidden, a default subject message is used. If the message field is hidden, the default secure message defined in the system configuration is used.

 File upload settings: You can select the number of file upload slots to display, from zero to three slots. You can also limit the size of the files a limited sender can upload.

 Delivery settings: Limited senders do not have the ability to change the delivery options like full senders. Delivery options are pre-defined by the administrator. The delivery options you can configure are: sending an email notification to recipients, requiring recipients to sign into the application to retrieve their delivery, and automatic package deletion (if this is set to 0, then the package will never be deleted).

Package Settings

 File upload slots per page: This sets the number of file upload slots per page when creating deliveries (both normal deliveries of an existing package as well as express deliveries). Valid values are between 1 and 10.

 Notify user when added as a package owner or sender: If set to yes,

a notification email will be sent to users who are added as an owner or a sender of a package. This informs people if they are given access to edit and/or deliver a package.

(46)

40

 Allow users to delete multiple packages: If set to yes, Senders can select and delete multiple packages from the Manage Package list. Senders can only delete packages that they own. Because this can be a potentially dangerous operation that can quickly delete many packages and all associated deliveries, this feature can be disabled by an administrator.

 Package deletes after (in days): Define the number of days newly created packages will be valid before being deleted by the system.

 Reminder before package deletion (in days): System sends an email reminder to all package owners and senders whose packages will be deleted shortly.

 Hide auto-deletion fields if not editable: For users who cannot override the auto-deletion values, the auto-delete fields are displayed but grayed out and uneditable. If this is an uneditable field, some administrators will choose to hide it from the sender.

 List of owners who can override deletion: Enter a specific user or user pattern (using wildcards like ? and *) who can override the deletion dates. These users can change the dates for deletion and email reminders, as well as completely override the deletion by deleting the date entirely. Multiple email addresses or patterns should be separated by commas.

Note: Package deletion is permanent and will delete all files, deliveries, replies, and files uploaded through replies. Recipients will no longer see deliveries in their Received Deliveries list for deleted packages, and any delivery notifications links in email will no longer be valid.

 Unrestricted senders: If defined, this is the list of Senders that are not subject to the inclusion and exclusion lists. So, if this list contains

*@biscom.com, then all Senders who have an email address matching

@biscom.com are exempt from the inclusion/exclusion rules. A Sender with

email address [email protected] will be subject to the inclusion/exclusion rules. If a user has an inclusion or exclusion list defined at the user level (not at this system level), then that takes precedence over their inclusion on this unrestricted senders list, and they will be subject to the inclusion/exclusion restrictions defined for their specific user account.

 Default recipient inclusion list: If defined, this is a list of recipients or recipient patterns that are acceptable recipients for all Senders. An

Administrator may override this on a per user basis. If any delivery recipient matches any email or patterns specified in this list, they will be allowed as recipients. Pattern matching is supported through the asterisk (*) and the question mark (?), which specify 0 or more occurrences, or 0 or 1 occurrences of character, respectively.

For example, for the list specified as follows:

[email protected], *@xxx.com, [email protected]

The single email addresses from [email protected]

(47)

[email protected], and [email protected] will all match. However,

[email protected], [email protected], and

[email protected] will not match.

If this list is not defined, or a single asterisk is used, all recipients are allowed.

 Default recipient exclusion list: If defined, this is a list of recipients’ emails or email patterns that are not acceptable recipients for all Senders. An Administrator may override this on a per user basis. Similar to the recipientInclusionList, this defines the set of email addresses that will be rejected by Biscom Delivery Server if added as recipients to a delivery.

 File type restrictions: If defined, this comma-separated list defines the list of files that are restricted from being uploaded to the system and

downloaded from the system. Pattern matching is supported through the asterisk (*) and the question mark (?), which specify 0 or more occurrences, or 0 or 1 occurrences of character, respectively.

 Allow applet for upload and download: A Java applet is available for users to upload and download files. Senders can take advantage of the applet when creating an express delivery or creating or editing packages to upload multiple files by simply dragging and dropping them onto the applet. Recipients can use the applet to download multiple files simultaneously. If you do not want to provide the applet functionality, set this radio button to No, and file uploads will be handled through the standard Web file upload component. For downloads, the files will be saved individually by clicking on the file name.

 File upload and download with applet allowed for: If you do enable the applet, you can still restrict the users who can use the applet’s functionality. Enter a list of users or wildcard pattern who can use the applet. For example, to allow everyone in the Biscom.com domain to use the applet, the value for this property would be *@biscom.com.

 Days before purge: The number of days before deleted files are moved to the recycle bin.

 Days before wipe: The number of days before recycle bin files are permanently deleted.

 Days before purge for in-progress files: The number of days that “in-progress” files are allowed to stay on the files system before being purged. This value should be set to 1 or greater in order for files being uploaded by the desktop client or Outlook add-in to successfully transfer.

(48)

42 Contact and Group Settings

Administrators can define a Microsoft Exchange Server connection to access the global address list (GAL) from the Web interface when delivering files or creating packages. Senders can automatically pull contacts from the GAL to use as delivery recipients and package owners and senders.

(49)

Sign In and Password

 Session timeout (in minutes): The timeout in minutes for all users who log on. If not set, the default timeout is 15 minutes.

 Show domain field on sign in page (for LDAP/AD only): If you have configured your server to use LDAP/AD to authenticate users, you have the option to show a domain field below the username and password fields. For organizations that have users authenticate with their domain as part of their username (e.g. corp-domain\john smith), the domain field may be hidden.

 Turn auto-complete on/off: Enables or disables the auto-complete attribute in the sign in page.

 Enable high security (logon password encrypted): Set to yes to enable client-side password encryption (requires clients to have Javascript turned on in their browsers). If this is set to yes, client browsers cannot use the remember password feature that some browsers support.

Note: Enable high security is not compatible with LDAP/AD. Set this property to no if you are configured to use LDAP/AD.

 Require re-authentication for viewing each delivery: If set to yes,

recipients who click on notification links will always need to re-authenticate to view a delivery. If this is set to no and a recipient is already logged in,

then clicking on a delivery link will open the delivery without forcing the user to go through the authentication step.

 Maximum logon attempts before locking user account: This

determines the number of attempts a user may try logging on before having their account locked. Only an administrator can unlock a user’s account.

 Automatically expire user password: Set to yes to enable password expiration. When this is enabled, enter the number of days that the password remains valid (if set to 0, passwords never expire). A warning

Administrator s Guide June 2008