Administrator s Guide June 2008

Administrator s Guide June 2008 Biscom, Inc. 321 Billerica Rd. Chelmsford, MA 01824 tel 978-250-1800 fax 978-250-4449

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.

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.

Table of Contents Section 1: Introduction... 1 Topics... 1 Conventions... 1 Section 2: Hardware and Software Requirements... 3 Server Hardware... 3 Server Software... 3 Mail Server... 4 Client Software... 4 Section 3: Installing, Uninstalling, and Upgrading Biscom Delivery Server... 5 Installing Biscom Delivery Server... 5 Installing the Active Directory Connector... 9 Testing the Installation... 10 Uninstalling Biscom Delivery Server... 11 Upgrading an existing Biscom Delivery Server instance... 11 Using IIS as your Web Server on Windows... 13 Using SSL... 16 Installing SSL on Apache 2 for Windows... 16 Installing SSL on Apache 2 for Linux... 17 Troubleshooting SSL:... 18 Section 4: System and Application Configuration... 21 System Configuration through fds.properties... 21 Server Configuration through the Application... 22 Section 5: Encryption Module... 23 Encryption and Decryption... 23 Keys and Key Management... 23 Encryption Utililty... 23 Section 6: Licenses... 28 Licenses... 28 Starting and Stopping the Application... 29 Starting the Application... 29 Stopping the Application... 30 Section 7: Signing In for the First Time... 31 First Sign In... 31 Section 8: System and User Administration... 32 Server Information... 32 Server Configuration... 33 v

Manage Users... 48 Creating a New User... 49 Modifying an Existing User... 49 Inclusion and Exclusion Lists... 51 Deleting a User... 52 Importing Users... 52 Manage Users with LDAP or Active Directory... 54 Enabling Authentication Using LDAP... 54 Defining an Authentication Source... 55 Configuring the BDS Active Directory Connector... 56 Assigning Roles using Groups... 56 Viewing an Authentication Source... 57 Section 9: Managing Processes... 59 Delivery Notification... 59 SMTP Input Handler... 59 System Cleanup... 59 Section 10: Application Customization... 60 Customizing Look and Feel... 60 Using your own CSS file... 60 Changing the Logo... 60 Customizing Text Labels... 60 Editing Static Messages... 60 Editing Dynamic Messages... 61 Customizing Online Help... 62 Error Pages... 62 Section 11: Backing up the Application Data... 65 Directories and Files to Back Up... 65 Restoring from a Backup... 66 Section 12: Scalability and Server Tiers... 68 Scalability... 68 Server Tiers... 69 Section 13: API Development... 73 Extending Biscom Delivery Server... 73 Section 14: Support and Troubleshooting... 74 Logs... 74 Frequently Asked Questions... 74 Appendix A: Biscom Delivery Manager (BDM)... 76 Biscom Delivery Manager... 76 Installing Web services... 76 vi

Installing BDM Client... 77 Configuring BDM... 81 Starting and Stopping the BDM Service... 82 Uninstalling BDM... 82 Appendix B: Microsoft Outlook Add-in... 83 Installing the Microsoft Outlook Add-in... 83 Uninstalling the Microsoft Outlook Add-in... 92 Upgrading the Microsoft Outlook Add-in... 92 Appendix C: Time Zones... 93 vii

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

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: /home/admin/bds 2

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 3

installation. Other distributions that are not RPM-compatible may be installed manually. Please contact Biscom technical support for further information and assistance. Mail Server 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. 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 4

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 started. 5

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 c. Administrator s email address 6

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 c. Administrator s email address 7

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: $ cd bds-installer-<version> 8

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

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: Linux: 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. 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: $ /etc/init.d/apache status 10

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: Linux: 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. 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 biscom-shared.jar: a shared library 11

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 number. 12

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 13

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 Server\components\tomcat- 5.5\conf\uriworkermap.properties 14

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 rightclick 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. 15

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 16

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): $ openssl genrsa -des3 -out my-server.key 1024 17

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 18

Server/CN=bho2.biscom.com/emailAddress=bho@biscom.com 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/emailAddress=bho@biscom.com verify return:1 --- Certificate chain 0 s:/c=us/st=massachusetts/l=chelmsford/o=biscom/ou=biscom Delivery Server/CN=bho2.biscom.com/emailAddress=bho@biscom.com i:/c=us/st=massachusetts/l=chelmsford/o=biscom/ou=biscom Delivery Server/CN=bho2.biscom.com/emailAddress=bho@biscom.com --- 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 19

Server/CN=bho2.biscom.com/emailAddress=bho@biscom.com issuer=/c=us/st=massachusetts/l=chelmsford/o=biscom/ou=b iscom Delivery Server/CN=bho2.biscom.com/emailAddress=bho@biscom.com --- 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) --- 20

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. timezone: This must match the time zone format specified in Appendix B. 21

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

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. Continue/exit (C/X)? C 23

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 24

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 When all files have been processed, the following should be displayed: 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: Key k103243 generated successfully. 25

Press any key to continue... 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. Press any key to continue... 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: Are you sure you want to encrypt all files (Y/N)? Y 26

Processing file 3882 of 32357 (12% complete); Time remaining: 9 hr 20 min When all files have been processed, the following should be displayed: Encrypted 32357 files. Total time: 10 hr 29 min. Press any key to continue... 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 reencrypted 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 When all files have been processed, the following should be displayed: Processed all files encrypted using key k120234. Key k120234 has been removed. Press any key to continue... 27

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

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: $ /etc/init.d/mysql [ start restart ] 29

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: $ /etc/init.d/mysql stop 30

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 CSVcompatible spreadsheet. Also, if you are using LDAP or Active Directory, assign users and roles using security groups. 4. Sign in as a Sender and create a package and deliver it. 31

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

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

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

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

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 addin 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 36

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

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

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

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 mary@externalcompany.com 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: sales@telemarketingcompany.com, *@xxx.com, tom?@xyz.com The single email addresses from sales@telemarketingcompany.com will match, any email with @xxx.com and will match, and tom@xyz.com, 40

tom1@xyz.com, and tomz@xyz.com will all match. However, jane@telemarketingcompany.com, bob@xxxx.com, and tom10@xyz.com 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 inprogress 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. 41

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

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 43

message will be displayed in the main menu page the number of days specified before the user s password expires (if set to 0, no warning will be displayed). This message is displayed at every logon until the user changes his or her password. If the user s password has already expired, the user will be prompted to change his or her password before being allowed to enter the application. Require users to change password after admin update: This specifies the default value to use when an administrator resets a user s password or when creating a new user. Previously created users and users whose passwords were already reset are not affected by this setting. Allow old user password to be reused as new password: If set to Yes, users are allowed to use the same password after their current password expires. Some administrators may set this to no to force users to choose a different password for increased security. Enable external authentication source Set to Yes to integrate with an external authentication source such as LDAP or Active Directory. When set to Yes, BDS will scan through all configured and active authentication sources. External authentication source configuration You may select and delete one or more authentication sources from the list of sources. To view the list of authentication sources, click on the name of the authentication source. See the section Defining an Authentication Source for more information on the AD connector. 44

User Registration Allow self-registration: When set to No, the registration page is disabled. Require activation: If checked, new registrants will automatically receive an email with an embedded link. Clicking the embedded link is a required stop to complete and activate the registration. If this is not checked, a user can register and immediately sign into the application. Email activation helps associate the registrant with the email address supplied during the registration process. Registration not allowed message: If registration is disabled, you can display a message informing users that they are not allowed to register. Self-registration not allowed for: If self-registration is allowed, you can still restrict registration by not allowing registration for certain user email addresses, or address patterns. For example use *@hotmail.com, *@yahoo.com to not allow users to register from these domains. The registration page will still be available to these users, but when they submit the registration request, they will be denied. Confirmation email for self-registration: If set to Yes, users who register themselves and complete activation (if required), will receive a confirmation email verifying the registration. Assign roles for self-registered users: Select the roles to assign to users who self-register. The Recipient role is on by default, but some administrators may want to let users register and automatically assign additional roles. Allow Outlook add-in for new registrations: When set to Yes, selfregistered users will be able to use the Outlook add-in client. If set to No, 45

users can still install the Outlook add-in, but any deliveries created using the add-in will fail. This setting does not apply to LDAP or AD users. Password length: Enter a minimum and maximum length for user passwords. By default, this is between 1 and 50. You cannot set the maximum above 50. Require password reset question: You may want users to select (or enter) a password reset question. If set to Yes, users must fill out the password reset question and answer. If set to No, and no password reset question/answer are provided by the user, then the user will not be able to reset his or her password automatically and must request this from an Administrator. Maximum password reset attempts: Limits the number of times a user may attempt to reset their password before locking his or her account. Once locked, only an Administrator can unlock a user s account. predefinedpasswordquestion1-5: If at least one question is defined, then users can select one of these questions to answer. If predefined questions are not used, then users can enter their own freeform question. If you only want to provide three pre-defined questions, only enter three questions and question codes. predefinedquestioncode1-5: For each defined question, specify a unique code for the question. This is used by the application to match up the question that the user selected with the questions configured. This also allows administrators to make slight alterations to a question without breaking how user questions are looked up by the application as long as the code is not changed. 46

User Interface The Biscom Delivery Server user interface can be altered by using a custom Cascading Style Sheet and a custom logo. You can specify the location of the style sheet and logo in this section. The style sheet can be used to change font faces, font sizes, colors, etc. CSS style sheet location: Specifies the location on the file system of the custom style sheet. This can also be a valid URL. Logo location: Specifies the location on the file system of the logo. This can also be a valid URL. If a logo or URL is specified here, the logo width and logo height fields must be entered. Logo links to (optional): This is the URL to link to when the logo is clicked. If this property is not set, the logo will link to the Logon page (if a user is not currently logged on), or the main application page (if a user is currently logged on). Logo width: The width of the logo in pixels. Logo height: The height of the logo in pixels. Custom sign in text (top): This field enables administrators to modify or customize the area above the sign in text box (username/password fields). Administrators can use HTML and styles from the internal CSS style sheet or from an externally defined style sheet. Click the Reset to original value link to reset the content to the original content (when the server was initially installed). Custom sign in text (right): This field enables administrators to modify or customize the area to the right of the sign in text box (username/password fields). Administrators can use HTML and styles from the internal CSS style sheet or from an externally defined style sheet. Click the Reset to original 47

value link to reset the content to the original content (when the server was initially installed). Custom web page footer: This field enables administrators to modify or customize the bottom (footer) of every page in the web application. Administrators can use HTML and styles from the internal CSS style sheet or from an externally defined style sheet. Click the Reset to original value link to reset the content to the original content (when the server was initially installed). Manage Users The Manage Users tool allows Administrators to create, update, and delete users. Click the Manage Users icon or click the Manage Users link to display the list of users on the system. If your system has many users, retrieving these users may take several minutes. The Biscom Delivery Server application may display a message to warn you of this. You can continue to retrieve all users, or you can use the search feature and enter keywords to reduce the number of users to retrieve. In the Manage Users list, text for active users is shown in black; disabled users are shown grayed out; pending users are shown in green. 48

Creating a New User 1. From the User Manager page, click the Add link to create a new user. 2. An email address and password are required fields. One or more roles must also be assigned to the user at this time as well. 3. Display as is used when displaying the user in the application. If this field is not populated, the first and last names are used. If they are also not populated, the email address is used. 4. If you are assigning the Sender role to the user, the Inclusion and Exclusion list text boxes will become editable. See the section on Inclusion and Exclusion lists for information on how to use this feature. Also, the Allow Outlook add-in checkbox will become editable. This feature only applies for systems that have the Outlook module. 5. Click the Create button to create the user. Modifying an Existing User Administrators can modify existing users to change the user s name, password, or roles. The email address used as the user name cannot be modified. 1. Select the user to update or modify by clicking on the user s email address. Use the search box to search for users based on email address and first, last, and middle names. 49

2. The user update form is shown below: a. You cannot change the email address field for a user once created. You can update the user s name, company, and roles. b. If the user has the Sender role assigned, the inclusion and exclusion lists can be updated. See the section on Inclusion and Exclusion lists for information on how to use this feature. c. The user s status can be change to Active or Disabled. Disabled users will be prevented from logging onto the Biscom Delivery Server application to retrieve deliveries, send packages, view reports, or administer the system. d. An Administrator may lock user accounts or a user may lock his or her account by entering an incorrect password too many times. Once a user s account is locked, the user will no longer be able to log on until an administrator unlocks the account. Users who are locked out can still use the Outlook add-in to create deliveries, and can still view no sign-in 50

deliveries. User accounts are locked to prevent unauthorized access to the web application. e. User statistics are provided for quick information on the user, including the number of packages the user owns, how much storage space is being used by all files in the user s packages, and number of deliveries received and sent. More detailed information can be viewed through the User Activity reports. f. Click the Update button to save the changes you have made. 3. To reset the user s password, click the Click here to reset user password link. Note: Clicking this link will bring you to a new page. Any changes you may have made on the Update User page will be lost unless you have already clicked the Update button. a. Enter a new password and retype the password to confirm it. b. Click the Update button to save the new password. c. Click the Back button when you are satisfied with your changes. Inclusion and Exclusion Lists Inclusion and exclusion lists are used to restrict Senders from delivering packages to certain recipients. Your system administrator may have configured the system with global inclusion and exclusion lists. However, these global settings may be overridden on a per user basis by entering values into the text boxes. For example, if the global inclusion list is *@biscom.com but you want to override this to allow the user to send to any email address, you would enter an asterisk (*). Individual email addresses as well as email patterns may be specified in these lists. Patterns use the asterisk (*) and the question mark (?) for pattern matching. * will match 0 or more occurrences of characters.? will match 0 or 1 occurrences of a character. For example: robert??@somecompany.com will match Robert@somecompany.com, robertf@somecompnay.com, and robert23@somecompany.com; robertson@somecompany.com will not match however. *@anothercompany.com will match lisa@anothercompany.com and steve@anothercompany.com. 51

Inclusion List Exclusion List This defines the list of recipients to whom the Sender can deliver packages. This defines the list of recipients to whom the Sender cannot deliver packages. If a recipient matches the pattern or email address on both the inclusion and exclusion list, the exclusion list match will take precedence and the Sender will not be able to deliver packages to that recipient. Deleting a User Administrators can delete users from the system. When deleting a user, all packages that are owned only by the user and deliveries associated with the user will no longer be valid. Any recipients who have received deliveries from a deleted user will no longer have access to those packages. Any deliveries of a package owned by a deleted user will also be inaccessible even though the sender is currently an active user. Note: This is a function that should be used with caution as it permanently removes the user from the system the user cannot be restored. 1. From the Manage Users list, select the checkbox to the left of the email address and click the Delete button. A confirmation page will display the selected users. 2. Click the Delete Users button to permanently delete the selected users. Importing Users Administrators can import users from an XML or a CSV file to quickly create and register a large number of users. 1. From the Home page, click the System and User Administration icon or click the System and User Administration link. 2. Click the Manage Users icon or click the Manage Users link. 52

3. Click the Import link. 4. Select a file to import. The file must be formatted in XML or as a tab-delimited file. For import format details, see Appendix B. Standard tab delimited files have one tab between each column. Some files have columns separated by more than one tab in order to visually align the data under the column headings. If your text file uses multiple tabs between column data, select the checkbox to treat consecutive tabs as a single tab. This feature only works if all import fields contain text. If any field is not entered (left empty), the import will fail. 5. Enter a password (and confirm the password) for users in the import file who do not have an assigned password. Since passwords are required for all users, this field cannot be blank when importing and registering users. 6. Click the Import button to import the users. The results of the import are displayed, with a summary of the import results, and the result of each individual user: a. : The user was imported successfully b. : The user was imported, but with a warning. The typical warning is when a user is imported with the Sender role designated, but the system s maximum number of Senders has been reached. The user is imported, but the user will not have the Sender role. c. : Imported user already exists in the system and was not imported. d. : User was not imported because the user information provided was invalid (e.g. an invalid email address) 53

Manage Users with LDAP or Active Directory For organizations that use directory services such as LDAP or Microsoft Active Directory (we will use LDAP as the general term for LDAP and Active Directory), administrators can perform user management through their primary directory services management software. BDS uses security groups to assign roles to users, and users can sign in to the application using their network username and password. Because BDS accesses the directory service directly rather than through a synchronization process, any changes to a user in the directory immediately is reflected in BDS. Changing a user s password in the directory immediately changes the BDS password. Enabling Authentication Using LDAP To enable support for LDAP, administrators must set the Enable external authentication source to Yes under the Sign In and Password section of the System and User Administration page. Enabling this will display a link to the External authentication source configuration page. 54

A list of external authentication will be shown. Click the Create External Authentication Source link to create a new authentication source, click the name of a source to view the source details, or click the edit icon to change an existing source. Defining an Authentication Source When creating or editing an existing authentication source, you are shown a page with three main sections: the source meta data (e.g. name and type of source), the role mappings, and any pre-windows 2000 mappings you may need to add. You can add multiple authentication sources. When a user signs in using their network credentials, each source is searched in the order in which they are listed. Or, if you installed the BDS AD Connector, enter information in the Active Directory connector settings. The meta data includes the authentication source name, type of source (LDAP or Active Directory), status, realm (usually the same as the domain), authentication method (Simple or Kerberos), protocol (ldap or ldaps), and port (389 by default). 55

Configuring the BDS Active Directory Connector If you installed the BDS ADC, this information supersedes the other authentication source meta data. To use the ADC, make sure the Use Active Directory connector checkbox is selected, and enter the host name where the connector is installed, and connector port. The default connector port is 65330. For machines that require a proxy to access AD, you can define the proxy within the fds.properties configuration file. Add or edit the lines, using your proxy host name and proxy port number: adcproxyserverhost=<proxy host name> adcproxyserverport=<proxy port> Assigning Roles using Groups The next section of the page shows the security groups that are assigned to roles. Groups can contain nested groups. You can enter one group name per line, multiple group names on a single line separated by semicolons. Spaces and commas are valid characters within groups and you should not use these characters to separate multiple groups. 56

For domains that were created on pre-windows 2000 servers (i.e. NT domains) can be entered here to map to a standard domain. Viewing an Authentication Source The authentication viewing page shows the list of roles and the mappings defined for each role. Roles can be mapped to multiple groups. To delete an entire group of role mappings, check the checkbox next to the role, and click the Delete button. To delete the entire authentication source, click the Delete External Authentication Source link. 57

58

Section 9: Managing Processes Biscom Delivery Server has three processes that perform various system functions: delivering email notifications, retrieving SMTP messages, and cleaning up the system. Administrators can start or stop each process individually from within the application. From the System and User Administration menu, click the Manage Server Processes icon or link. To start a process, click the green Start icon. To stop a process, click the red Stop icon. If a process is currently running, the Start icon will be disabled and grayed out and the Stop icon will be enabled. If a process is currently stopped, the Stop icon will be disabled and grayed out, and the Start icon will be enabled. The process status will visually show that the process is in the middle of starting or stopping. Delivery Notification The delivery notification process sends notifications out when a Sender creates a normal or express delivery. If this process is stopped, no delivery notifications will go out. Once the process is restarted, all notifications that had been queued up will be delivered. This does not prevent users from receiving deliveries they will still be able to see any packages a sender delivers to them immediately, but they will not be notified via email that their delivery is available. SMTP Input Handler The Outlook Add-in and the email API require the SMTP input handler process to be running in order to process incoming email with delivery instructions. BDS uses an email account on the organization s email server to retrieve and process Biscom Delivery Server API commands embedded in an email message. System Cleanup The system cleanup process runs every twelve hours and deletes any files associated with deleted packages. When a package is deleted, the files are put into the recycle bin directory. When the system cleanup process runs, it permanently deletes the files from the system. To force the process to run immediately, stop and restart the process. 59

Section 10: Application Customization Customizing Look and Feel Biscom Delivery Server is easy to customize to match the look and feel of your company. Biscom Delivery Server provides two areas that are easily customizable: the logo that appears on the top of every page and the colors, fonts, tables, and other user interface attributes as controlled by a Cascading Style Sheet or CSS file. The user interface is controlled through the server configuration utility in the application, which allows an Administrator to specify the location of a custom logo, and specify a different CSS file. Using your own CSS file Update the property for the CSS style sheet location. A default CSS file is provided. To change the behavior of a style, update the default CSS file (typically by overriding the existing styles) and rename it. Reference this new CSS filename in the CSS property. The CSS file can reside either at a URL location that is accessible via a hyperlink, or located in a location under the Web server document root. Changing the Logo Any image can be used to replace the Biscom Delivery Server logo. The image can be any width but because the application window is resizable, this may produce undesirable effects if the browser is resized too small. One way to minimize the effects of window resizing is to use a logo with a relatively small width, and use a background color that blends in with the logo background: #layoutlogo { height: 50px; background-color: #002c77; width: 100%; } Change the background-color value to the color that best matches the logo, often this is the logo s background color. The image can reside either at a URL location that is accessible via a hyperlink, or located in a location under the Web server document root. ; and the text labels in the Web application and notification messages Customizing Text Labels Editing Static Messages All the text labels in the Web application and the email notification messages can be customized. A properties file called application.properties contains key-value pairs, where the key is the message name and the value is the actual message displayed. For example: label.delivery.date.available=date available The key for the first message is: label.delivery.date.available 60

The value for this key is: Date available Messages can also contain placeholders for variable data. These placeholders are numbered and surrounded by curly braces: msg.password.length=you must enter a password that is between {0} and {1} characters long Although the application.properties file cannot be modified, administrators can edit a file called bdscustom.properties to change the text that appears for a particular key in application.properties. Note: Administrators cannot define new keys, only modify the value of existing keys. The text customization file is located here: <BDS HOME>/config/custom/resources/bdsCustom.properties If this file does not exist, simply create a new text file in this directory and name it bdscustom.properties. Example: To change the text Date available to Available date, you would add the following line to bdscustom.properties: label.delivery.date.available=available date Now, whenever the application looks up the label.delivery.date.available key, the value Available date will be inserted instead of Date available. Note: If you accidentally enter keys with the same name, the value used will be the key that is defined last in the bdscustom.properties file. After editing the bdscustom.properties file, restart the application server for your changes to take effect. Editing Dynamic Messages Administrators can also modify and customize messages that contain dynamic text. For example, a delivery notification email will contain content that is specific to the delivery, such as the delivery name, who viewed the delivery, and when it was viewed. The message that defines the delivery notification is email.delivery.view.notification.body=your delivery \ has been viewed.\n\n\ Delivery : {0}\n\ Delivery viewed by : {1}\n\ \n\ Delivery sent on : {2}\n\ Delivery viewed on : {3}\n\ \n\ Package \n\ : {4}\n\ 61

\n\ Please note: This email was sent from a \ notification-only address that cannot \ accept incoming emails. Please do not \ reply to this message.\n The curly braces surrounding the number indicate a substitution field. {0} is the variable or placeholder for the delivery name. {1} is the variable for who viewed the delivery. The numbering is important each number represents a different value, and the same numbers much be used in any customized content. As an example, we may want to change the delivery notification email from the default message above to: email.delivery.view.notification.body=your delivery \ has been viewed.\n\n\ The delivery {0} was viewed by {1}\n\ on {3}\n\ \n We would enter this edited key-value pair into the bdscustom.properties file and restart the application server for the change to take effect. Note that we ve removed several variables in the new message the variable {2} no longer is part of the message, but {3} is still in the message. Note: Messages that span multiple lines use the backslash character to indicate that the message is continued on the next line. The control character \n inserts a new line into the message. Some characters are reserved for use such as the single quote and the curly brace. If you need to have a single quote or curly brace appear in the displayed message, use single quotes around the character. To show a curly brace, use {. To display a single quote, use two single quotes:. Customizing Online Help Online help in the BDS Web application is accessible by all users by clicking the Help icon in the main menu. BDS provides administrators the ability to create their own help file and link to it from the built-in help icon. The help pages can be a mini site that contains multiple pages. To specify the location of your custom help, enter the URL of the first or index page in the User Interface section of the Server Configuration page. When you specify a custom help site, a new browser window will open when users click the Help icon. To revert to the default help page, remove the URL from the custom help text field. Error Pages When the Biscom Delivery Server is offline (i.e. the application server is shut down), or another problem occurs, error pages are predefined that will be delivered to the 62

browser user by the web server. Administrators may want to modify or customize these error pages to reflect the problem better within their environment and customize the look and feel to match the application or organization s web site. The pages are under the Apache document root directory: <BDS HOME>/components/apache-2.0/htdocs With file names: error404.html, error500.html, error503.html error503.html is shown here as an example: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/tr/html4/strict.dtd"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>biscom Delivery Server not available</title> <style type="text/css"> body { background-color: #eee; margin: 0px; font-family: Tahoma,Verdana,Arial,Helvetica,sans-serif; #header { width: 100%; vertical-align: top; } height: 50px; background: #fff url('/images/bds_logo.gif') no-repeat; } #footer { height: 34px; background: url('/images/powered_by_biscom.gif') no-repeat right; } </head> </style> #container { background: #fff; } #message { padding: 10px 75px 75px 75px; } h1 { h2 { font-size:1em; color:#333; font-weight: bold; padding-bottom: 10px; } font-size:.8em; color:#505050; font-weight: normal; } <body> <div id="container"> 63

<div id="header"></div> <div id="message"> <h1> </h1> <h2> The server is currently unavailable. Please try again later. If you continue to have problems accessing the server, please contact your system administrator. </body> </html> </div> </div> </h2> <div id="footer"></div> 64

Section 11: Backing up the Application Data Directories and Files to Back Up Biscom Delivery Server stores files on the file system, users, deliveries, and package metadata in the database, and license, configuration, and log files on the file system. Any customizations are typically stored under the Web server document root. Back up all files and subdirectories under the directories specified or located in the locations listed below. Before backing up the BDS server, ensure that the application server has been shut down. Configuration Back up all configuration files from the config directory, including: fds.properties biscom.properties db.properties ldap.properties log4j.properties Files and license Database Open fds.properties to find the location where user files are stored: o docroot o o protectedrecyclebindir licensefile Back up the license file. The database should be exported and saved to your backup location. Please refer to the MySQL documentation, or the database documentation of the database you are using if it is different than MySQL, for details on exporting the database. Windows: Create a Windows batch file. A sample batch file may look like: echo Biscom Delivery Server Database Backup "C:\Program Files\Biscom Delivery Server\components\mysql- 4.1\bin\mysqldump.exe" -u fds -- password=fds bds > "C:\Program Files\Biscom Delivery Server\backup\db\bds-backup.sql" echo Batch file completed 65

Linux: This batch file can be called and run on a regular basis using the Windows control panel application Scheduled Tasks. Run the mysqldump command with the name of the application: $ mysqldump {app name} > bds-backup.sql Make sure the dump file, e.g. bds-backup.sql in this example, is backed up along with the other data. Log files The logs are stored in a directory that is specified by the properties file log4j.properties. The location of the log4j.properties file is specified in biscom.properties: o logpropertiesfilename Open the log4j.properties file and look for the following properties showing the name and location of the three log files: o o o log4j.appender.bdsalllog.file log4j.appender.bdsrollinglog.file log4j.appender.bdsdbrollinglog.file Customization files If the application has been customized with a logo or cascading style sheet, back these files up as well. If you are unsure of the location, view the Server Configuration page to see the settings. Restoring from a Backup Restoring BDS from a backup involves the following steps: 1. Shut down the application server 2. Copy any existing data files and the database to a new location 3. Restore the database 4. Copy user files from the backup location to the current file location 5. Verify configuration files and edit if needed Database Locate the exported database dump file. Navigate to the bin directory in the MySQL installation location, and run the following command (for both Windows and Linux) that has the following syntax: 66

mysql h <hostname> -u <username> -p <database name> < <export file> Example: mysql h localhost -u fds -p bds < bds-backup.sql User files Locate and copy the backup user files to the appropriate data and recycle bin directories. Customizations Update or apply any existing customizations. Once the files and database are restored, restart the application server. 67

Section 12: Scalability and Server Tiers Scalability Scalability provides better performance and increased capacity to handle users by adding servers that run the Biscom Delivery Server application. Each additional server more evenly distributes the workload, thus making the application more responsive with larger numbers of users. We recommend that anyone who is looking to scale their system first conduct a network architecture and application usage review to better understand the requirements of the system and its users. Also, determining the bandwidth requirements based on expected usage can help ensure system responsiveness. Scabilitity is also tied into how the various application tiers are deployed. By default, Biscom Delivery Server installs on a single machine. Moving the Web, Application Server, File System, and Database tiers to separate machines can improve performance as well as provide additional security by storing user data in more secure locations on the network. 68

Server Tiers Web Server Tier The Web server tier is a lightweight process, and acts as the interface between client Web browsers and the application server. Requests from clients are relayed through the Web server to the application server layer to begin processing the request. Responses from the application layer is then returned to the client via the Web server. When deployed in an environment with heavy bandwidth issues, it is critical to size the network bandwidth appropriately to ensure an adequate response to file uploads and downloads. Deploying two or more Web servers with load balancing ensures that user sessions will not be interrupted even if one server becomes disabled. This configuration also allows for adding more web servers to handle load as the number of users on the system increases. Application Server Tier All business and application logic is contained in the application server tier receiving and processing client requests, accesing back end resources such as the file system and database as needed. No user data is stored at the application server tier. Clustering the application servers provides redundancy as well as better processing performance. This is the most important tier in terms of increasing performance and capacity to handle simultaneous user sessions. Back-end Tier (File System and Database) File System The file system contains all the user data, including files that are part of packages. Biscom Delivery Server works with both local and network-based file systems. Default installation creates a data directory on the local server. To use a different data directory, which may reside on a separate server, simply update the docroot value in fds.properties. The docroot may be a local drive, a network drive, or a UNC path. Note that backslashes must be escaped with a backslash. Windows: docroot = C:\\apps\\bds\\data Linux: or docroot = \\\\dataserver\\data docroot = /home/admin/bds/data or docroot = /mount/dataserver/data 69

Database The database contains all the metadata, including user information, package and delivery information, as well as the relationships between users and the packages and deliveries. All user, package, and delivery transactions are stored in the database, and reports can be generated by running queries against the database. Separating the Web Server and Application Server Tiers The JK Connector is the mechanism that connects the Web server to the application server. This connector maps URL patterns to workers which can represent different application server instances. The configuration file for the connector is called workers.properties, and is usually located in: Windows: <BDS HOME>/components/apache-2.0/conf Linux: /etc/httpd/conf/workers.properties Note: The location of the workers.properties file is defined in the web server s configuration file httpd.conf using the property JkWorkersFile. All workers are listed in the workers list: worker.list=ajp12, ajp13, worker1, worker2, Workers are defined using the following properties: # # Defining a worker named ajp13 and of type ajp13 # Note that the name and the type do not have to match. # worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.worker1.port=8009 worker.worker1.host=192.168.0.101 worker.worker1.type=ajp13 The Apache Web server configuration file httpd.conf loads the JK module and maps the URL to the appropriate worker. #JK configuration LoadModule jk_module modules/mod_jk.so JkWorkersFile "/etc/httpd/conf/workers.properties" JkLogFile "/etc/httpd/logs/mod_jk.log" JkLogLevel info JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" 70

JkMount /bds ajp13 JkMount /bds/* ajp13 JkMount /bds2 worker1 JkMount /bds2/* worker1 The last four lines perform the URL mapping starting from the document root.. Wildcards (*) can be used in the patterns. When the Web server sees the URL https://secure-server.biscom.com/bds/login.do, the request will be redirected to the ajp13 worker, which points to the application server instance running on localhost on port 8009 in our instance. The URL https://secure-server.biscom.com/bds2/login.do would match the second mapping to worker1. Worker1 points to an instance on the server specified by the IP address 192.168.0.101 on port 8009. The application server could be running on a physically separate machine. Note: When changing the worker host property, ensure that the machine and port can accept TCP communications from the Web server. This may require configuration changes to your firewall. Separating the Application Server Tier and Database Tier The configuration file <BDS HOME>/config/db.properties can be modified to point to a database server running on a different machine. # Define values for a specific pool fdspool.database = MYSQL fdspool.url = jdbc:mysql://127.0.0.1/bds?useunicode=true&charac terencoding=utf-8 The property fdspool.url defines the JDBC URL that the database resides. To use a database on the machine db.biscom.com, change the value from 127.0.0.1 to db.biscom.com: fdspool.url = jdbc:mysql://db.biscom.com/bds?useunicode=true&ch aracterencoding=utf-8 When changing the location of the database server, ensure that the database grants permission to the host name or IP of the server where the application server resides. GRANT ALL PRIVILEGES ON <database name>.* TO 'fds'@'<machine IP>' IDENTIFIED BY 'fds'; Or GRANT ALL PRIVILEGES ON <database name>.* TO 'fds'@'<machine name>' IDENTIFIED BY 'fds'; Examples: 71

GRANT ALL PRIVILEGES ON bds.* TO 'fds'@'localhost' IDENTIFIED BY 'fds'; GRANT ALL PRIVILEGES ON bds.* TO 'fds'@'127.0.0.1' IDENTIFIED BY 'fds'; 72

Section 13: API Development Extending Biscom Delivery Server If you purchased the Software Development Kit, you have the ability to extend Biscom Delivery Server to suit the needs of your business, such as working with your workflow or business process management, and integrating with and extending existing applications. Creating your own custom application from the ground up is possible using the BDS APIs. BDS supports a native Java API, a platform/os/programming language neutral Web services API, as well as an easy-to-use SMTP API. Please refer to the SDK documentation for the API as well as sample code and other documentation. Java API The Java API provides both high level and low level API calls that support methods for user authentication, package and delivery creation and management, user and group management, and report generation. The Java SDK provides a comprehensive Application Programming Interface to the Biscom Delivery Server back end, allowing developers to build a custom secure delivery application. For more information, see the SDK documentation. Web Services API SMTP API Web services uses an XML-based call structure when invoking the API and can be called from any language, operating system, platform, and development environment that supports XML web services calls. The WSDL file contains the available API calls and many development environments will be able to import and provide an easy way to access the API. BDS provides a both a Java client library wrapper as well as a.net client library wrapper that for development. The Web services API requires an additional web application to process the API calls. This WAR file is deployed to the application server in the same manner the BDS application is deployed. The SMTP API is an XML-based API that leverages the ease and simplicity of email to deliver files and messages securely. BDS can be configured to watch a designated mailbox and look for specially formatted messages. BDS messages consist of embedded XML commands for secure and notification, adding recipients, setting delivery options, and submitting files. 73

Section 14: Support and Troubleshooting Logs Biscom Delivery Server maintains several event logs to help identify potential problems and can be useful for troubleshooting problems and when talking to technical support personnel. The log files are stored in the log directory under the installation (<BDS HOME>) location by default. However, the log file locations and names may be changed by updating the appropriate properties in the log4j.properties file. Logs will grow to a certain size before rolling over. The size and number of backup (rolled over) logs are set in the log4j.properties files as well and can be modified by adjusting the <log name>.maxfilesize and <log name>.maxbackupindex properties. By default, these values are set to 100KB maximum size and 20 backups for each of the logs. bdsrolling.log The application log bdsdbrolling.log The database log bdsall.log External system logs Frequently Asked Questions Q. I updated the fds.properties file, but why aren t my changes appearing in the application? A. Changes to any of the properties files require restarting the application server to pick up the new changes. Q. How do I upgrade my license? A. License upgrades are performed by replacing your old license file with the new license file. The license file is an XML file that contains information on license expiration and restrictions such as the maximum number of Senders. Changing the XML content will invalidate the license. If the new license file is named differently than the old license file, you must update the licensefile property in fds.properties. The application server must be restarted to recognize the new license. Q. Can I move the location of the files after installation? A. Yes, but special care must be taken when making any changes to the files system. 1. Shut down the application server. 2. Find the locations of the files and directories where user data is stored. 74

These locations can be found in the fds.properties files under the two properties docroot and protectedrecyclebindir. 3. Copy the files and directories to the new locations. 4. Update the docroot and protectedrecyclebindir properties in the fds.properties file with the new location of the files. 5. Start the application server, and test the application. 6. Once testing is complete, the old files may be deleted. 75

Appendix A: Biscom Delivery Manager (BDM) Biscom Delivery Manager Biscom Delivery Manager is a desktop application that communicates with the Biscom Delivery Server using the Web services API. BDM is designed to enhance the server by providing users with the ability to quickly and efficiently create packages, upload files, and download files. BDM runs as a Windows background service, and if it is in the process of uploading or downloading a file, will run even when no user is logged on to the machine. When uploading or downloading files, BDM supports file restart if network connectivity drops. When network connectivity is reestablished, BDM will gracefully continue the upload or download from the point of failure. Power failures that bring a desktop down while BDM is processing will also be handled gracefully by BDM when power is restored and the machine restarts, the BDM service will restart and any pending uploads or downloads will resume from the point of failure. Installing Web services The Web services application is axis2.war which can be found on your BDS CD or it may have been sent to you in a secure delivery. This application needs to be deployed to the application server. Deploying axis2.war: Windows: 1. Stop the application server Apache Tomca through the Windows Computer Management utility. 2. Copy axis2.war to the <BDS HOME>\components\tomcat-5.5\webapps directory. 3. Start up the application server. 4. Go to http://localhost:8080/axis2/ to ensure the Web services application is running. You should see the Apache Software Foundation logo as well as three links for Services, Validate, and Administration. Click the Services link and verify that all listed services have a Service Status of Active. Linux: 1. Stop the application server (e.g. /etc/init.d/tomcat stop). 2. Copy axis2.war to the application server s webapps directory, e.g. /usr/local/tomcat/webapps. 3. Start up the applications (e.g. /etc/init.d/tomcat start). 4. Go to http://localhost:8080/axis2/ to ensure the Web services application is running. You should see the Apache Software Foundation logo as well as three links for Services, Validate, and Administration. Click the Services link and verify that all listed services have a Service Status of Active. 76

Installing BDM Client Each user who wants to use the Biscom Delivery Manager must install the client on their desktop. Users must be registered BDS users and have the Sender role assigned. BDM comes packaged as a Windows installer which must be run from each desktop that wishes to run the client application. BDM installs as a Windows service, and also adds a shortcut to the BDM application in the Start menu. Note: If an older version of BDM has already been installed on the desktop system, uninstall the older application before installing the newer application. You will see the following dialog boxes. You may update the location in which you install the Biscom Delivery Manager application. 77

78

Installation troubleshooting Some systems may have issues running the application as the Local System Account. If the application does not start up, or does not allow users to sign in, view the Computer Management application by right clicking My Computer > Manage. 79

Double click the Biscom Delivery Manager service to open the properties window. Click on the Log On tab. If the Local System account is selected, choose the This account option and enter an account (e.g. the network logon credentials of the user who logs onto the PC regularly or a network administrator) that has permission to run the service. 80

Click OK. Stop and restart the Biscom Delivery Manager Service for the changes to take effect. Configuring BDM Once installed, BDM will run using default configuration. However, BDM can be customized to change the look and feel of the application, or adjust the upload/download transfer rate. The following files located at <BDS HOME>/config can be modified: bdm.properties uploadchunksize = 614400 uploadchunksize: this value can be changed for more efficient file transfers. For users on the internal network, a larger chunk size may increase transfer speeds. For users outside the network (i.e. communicating to a server over the Internet), the default chunk size will probably be most efficient. When making changes to this value, the BDM service must be stopped and restarted, and users must exit and restart the client application. bdsc.properties logofile = C:\\Program Files\\Biscom Delivery Manager\\images\\bds_logo.gif iconfile = C:\\Program Files\\Biscom Delivery Manager\\images\\bds-upload-16.ico windowbackgroundcolor = eeeeee 81

Starting and Stopping the BDM Service From the Control Panel, start the Add/Remove Programs utility. Select Biscom Delivery Manager and press the Remove button. The application will be uninstalled. Uninstalling BDM From the Control Panel, start the Add/Remove Programs utility. Select Biscom Delivery Manager and press the Remove button. The application will be uninstalled. 82

Appendix B: Microsoft Outlook Add-in Installing the Microsoft Outlook Add-in If you have the optional Outlook Add-in module installed, your users can take advantage of the Biscom Delivery Server Microsoft Outlook Add-in, which allows users to create express deliveries from within their email environment. To use the add-in, the following conditions must be met: An email account on the mail server must be created and configured to be the recipient of message stubs. When a secure message is sent through BDS, a small email message is also created and sent to this email address, and contains the message and list of files attached. This email account should not be used for anything other than receiving Biscom Delivery Server messages with the proper data. Each user who wants to use the Outlook Add-in must be running Microsoft Outlook 2003 or Outlook 2007, on Windows XP or Windows Vista. Each user who wants to use the Outlook Add-in must have the Outlook Addin client installed on their machine with the proper configuration (mail server and email account properly defined). Each user who wants to use the Outlook Add-in must have the Sender role assigned, and have the Allow Outlook Add-in checkbox checked in the Update User page (by default, this is not checked). If using LDAP or Active Directory, any user who wishes to use the Outlook Add-in should be a member of a group that is assigned the Outlook Add-in role in the external source authentication definition. Note: This takes precedence over the Allow Outlook Add-in checkbox in the user management page. How it works: 1. When a user clicks the New Message button, a normal message form will open. Senders can add recipients as they would normally, enter a subject, and type in text in the memo field. To attach files, users can use the menu item Insert > File, or users can simply drag and drop files from their desktop onto the memo field. 83

2. Based on the settings in the server configuration, the different aspects may trigger the message to go out through BDS. For example, if the total size of the attachments exceeds the size limit defined in BDS, or a keyword matches the list of keywords defined, then the message will be delivered through BDS. Otherwise, the message will go out normally through the mail server. 3. Users can change the delivery method in the toolbar or the options ribbon. A drop down menu called Use BDS has three selectable values: Default, Yes, and No. The Default value (which is the default setting for users) will follow the policies defined by the BDS administrator. The Yes value will force sending the message securely through BDS. The No value will force the message to go through the regular mail server. Note: The No value can be disabled by the administrator, so senders only have the choice of using the default settings or to force the message to go out securely. 4. If the message meets the criteria for delivery through BDS, a stub message is sent to the mailbox defined by the administrator, containing the message in the memo field, and the names of the files delivered, but this message does not contain the actual files. A separate process will upload the files to the BDS server and create a delivery to be sent to the recipients listed in the message. Users can view the status of the file upload by going to the Sent folder, right clicking on the message and selecting the Status menu option. If the upload is still in progress, the user will see the progress meter of each file upload. 84

Enabling Users on the BDS Server You must enable your users to utilize the add-in. This is done differently for your LDAP/AD users and your non-ldap/ad users. 1. For non-ldap/ad users, go to the Manage Users page under System and User Administration. When creating a new user, select the checkbox for Allow Outlook add-in. When updating an existing user, select the user from the Manage Users list, and select the Allow Outlook add-in checkbox. Note that the user must have the sender role assigned. 85

For LDAP/AD users, you enable the BDS add-in by adding the security groups that the user belongs to. So, if you have a group called domain senders who have the sender role assigned to them and will be using the add-in, simply add this group to the role mapping field Outlook Add-in. 86

Setting up Users with the Client End users can install the BDS Outlook add-in by simply double-clicking the Setup.exe file. The add-in can also be pushed out through Microsoft Group Policy if you are running Active Directory. Please contact Biscom technical support if you are interested in using Group Policy to distribute the BDS Outlook add-in. To install the add-in on a user s desktop directly: 1. Make sure the user s Outlook client has been shut down. 2. Double-click the Setup.exe file and follow the setup instructions. The first step is to install the Microsoft Office Primary Interop Assemblies as a requirement to run the BDS add-in. 3. You will be prompted to start the installation of the BDS software. Click Next to start the installation. 87

4. Select the installation directory. 5. Click Nex to perform the installation. 88

6. Once installation is complete, you can close the installer. 7. When a user first starts up Outlook, a BDS configuration form will be displayed. This configuration can also be viewed at any time afterwards by going to the Tools menu and selecting BDS Configuration. Each user must enter their username and password. If the other fields were not pre-populated, then the user must also enter the domain, server name, and SSL setting. For LDAP/AD users, in addition to the username and password fields, the proper domain must be entered. Non- 89

LDAP/AD users will leave the domain field blank. 8. The add-in supports a direct internet connection or proxy server. The user can also try to have the add-in automatically detect the proxy settings. 90

Configuring Policies for the Add-in To configure the add-in behavior and policies, BDS administrators should open the Outlook Add-in Configuration page in Server Configuration. 91

1. Enable Outlook add-in: Must be set to Yes to use the add-in 2. Server email address: The mailbox on the mail server that receives the stub messages from each user 3. Policy synchronization interval (in minutes): How often the add-in communicates with the BDS server to retrieve the policies. The default value is 60 minutes. 4. Policies a. Keywords (Subject line): One keyword or keyword phrase per line. If a phrase is used, it will be matched exactly, for example social security. This is not case sensitive. If a user enters a keyword or keyword phrase that is defined by an administrator, the message will be sent through BDS. Note, the email body and any attachments are not scanned for keywords. Keywords are also matched optimistically so, if the keyword is secure, then the words secure and securely will match. But security will not match. b. Total attachment size (KB): Define the maximum attachment size limit that will trigger a secure delivery. c. Allow users to bypass policy: If set to Yes, senders can force a message that matches a BDS policy to be sent through the mail server. If set to No, senders will not see the option to disable sending through BDS in the Outlook client. 5. Delivery Settings a. Notify when recipients access this delivery: Select whether to be notified the first time each recipient opens the secure delivery, or every time a recipient opens the delivery. b. Email addresses to notify: Specify one or more recipients to notify when a secure delivery is opened. Or, use the reserved word SENDER, to have notifications sent back to the original sender of the delivery. Uninstalling the Microsoft Outlook Add-in To prevent a user from using the Outlook add-in, you can disable outlook by deselecting the Allow Outlook add-in checkbox when updating the user or removing the user from the LDAP/AD group mapped to the Outlook Add-in. To fully remove the add-in from a user s Outlook client, follow these steps: 1. Shut down the user s Outlook client and confirm that no Outlook processes remain. 2. Go to the Control Panel and open Add/Remove Programs (Windows XP) or Programs and Features (Windows Vista) and uninstall the add-in. Upgrading the Microsoft Outlook Add-in Simply run the new Setup.exe file and the new add-in will upgrade the existing addin. All user values will be saved and will not have to be re-entered. 92

Appendix C: Time Zones Time Zone Time Zone Time Zone Africa/Abidjan America/Nipigon Atlantic/Jan_Mayen Africa/Accra America/Nome Atlantic/Madeira Africa/Addis_Ababa America/Noronha Atlantic/Reykjavik Africa/Algiers America/Panama Atlantic/South_Georgia Africa/Asmera America/Pangnirtung Atlantic/St_Helena Africa/Bamako America/Paramaribo Atlantic/Stanley Africa/Bangui America/Phoenix Australia/Adelaide Africa/Banjul America/Port_of_Spain Australia/Brisbane Africa/Bissau America/Port-au-Prince Australia/Broken_Hill Africa/Blantyre America/Porto_Acre Australia/Darwin Africa/Brazzaville America/Puerto_Rico Australia/Hobart Africa/Bujumbura America/Rainy_River Australia/Lindeman Africa/Cairo America/Rankin_Inlet Australia/Lord_Howe Africa/Casablanca America/Regina Australia/Melbourne Africa/Ceuta America/Rosario Australia/Perth Africa/Conakry America/Santiago Australia/Sydney Africa/Dakar America/Santo_Domingo Europe/Amsterdam Africa/Dar_es_Salaam America/Sao_Paulo Europe/Andorra Africa/Djibouti America/Scoresbysund Europe/Athens Africa/Douala America/Shiprock Europe/Belfast Africa/El_Aaiun America/St_Johns Europe/Belgrade Africa/Freetown America/St_Kitts Europe/Berlin Africa/Gaborone America/St_Lucia Europe/Bratislava Africa/Harare America/St_Thomas Europe/Brussels Africa/Johannesburg America/St_Vincent Europe/Bucharest Africa/Kampala America/Swift_Current Europe/Budapest Africa/Khartoum America/Tegucigalpa Europe/Chisinau 93

Africa/Kigali America/Thule Europe/Copenhagen Africa/Kinshasa America/Thunder_Bay Europe/Dublin Africa/Lagos America/Tijuana Europe/Gibraltar Africa/Libreville America/Tortola Europe/Helsinki Africa/Lome America/Vancouver Europe/Istanbul Africa/Luanda America/Whitehorse Europe/Kaliningrad Africa/Lubumbashi America/Winnipeg Europe/Kiev Africa/Lusaka America/Yakutat Europe/Lisbon Africa/Malabo America/Yellowknife Europe/Ljubljana Africa/Maputo Antarctica/Casey Europe/London Africa/Maseru Europe/Luxembourg Africa/Mbabane Antarctica/Mawson Europe/Madrid Africa/Mogadishu Antarctica/McMurdo Europe/Malta Africa/Monrovia Antarctica/Palmer Europe/Minsk Africa/Nairobi Antarctica/South_Pole Europe/Monaco Africa/Ndjamena Arctic/Longyearbyen Europe/Moscow Africa/Niamey Asia/Aden Europe/Oslo Africa/Nouakchott Asia/Alma-Ata Europe/Paris Africa/Ouagadougou Asia/Amman Europe/Prague Africa/Porto-Novo Asia/Anadyr Europe/Riga Africa/Sao_Tome Asia/Aqtau Europe/Rome Africa/Timbuktu Asia/Aqtobe Europe/Samara Africa/Tripoli Asia/Ashkhabad Europe/San_Marino Africa/Tunis Asia/Baghdad Europe/Sarajevo Africa/Windhoek Asia/Bahrain Europe/Simferopol America/Adak Asia/Baku Europe/Skopje America/Anchorage Asia/Bangkok Europe/Sofia America/Anguilla Asia/Beirut Europe/Stockholm America/Antigua Asia/Bishkek Europe/Tallinn America/Aruba Asia/Brunei Europe/Tirane America/Asuncion Asia/Calcutta Europe/Vaduz 94

America/Barbados Asia/Chungking Europe/Vatican America/Belize Asia/Colombo Europe/Vienna America/Bogota Asia/Dacca Europe/Vilnius America/Boise Asia/Damascus Europe/Warsaw America/Buenos_Aires Asia/Dubai Europe/Zagreb America/Caracas Asia/Dushanbe Europe/Zurich America/Catamarca Asia/Gaza Indian/Antananarivo America/Cayenne Asia/Harbin Indian/Chagos America/Cayman Asia/Hong_Kong Indian/Christmas America/Chicago Asia/Irkutsk Indian/Cocos America/Cordoba Asia/Ishigaki Indian/Comoro America/Costa_Rica Asia/Jakarta Indian/Kerguelen America/Cuiaba Asia/Jayapura Indian/Mahe America/Curacao Asia/Jerusalem Indian/Maldives America/Dawson Asia/Kabul Indian/Mauritius America/Dawson_Creek Asia/Kamchatka Indian/Mayotte America/Denver Asia/Karachi Indian/Reunion America/Detroit Asia/Kashgar Pacific/Apia America/Dominica Asia/Katmandu Pacific/Auckland America/Edmonton Asia/Krasnoyarsk Pacific/Chatham America/El_Salvador Asia/Kuala_Lumpur Pacific/Easter America/Ensenada Asia/Kuching Pacific/Efate America/Fortaleza Asia/Kuwait Pacific/Enderbury America/Glace_Bay Asia/Macao Pacific/Fakaofo America/Godthab Asia/Magadan Pacific/Fiji America/Goose_Bay Asia/Manila Pacific/Funafuti America/Grand_Turk Asia/Muscat Pacific/Galapagos America/Grenada Asia/Nicosia Pacific/Gambier America/Guadeloupe Asia/Novosibirsk Pacific/Guadalcanal America/Guatemala Asia/Omsk Pacific/Guam America/Guayaquil Asia/Phnom_Penh Pacific/Honolulu 95

America/Guyana Asia/Pyongyang Pacific/Johnston America/Halifax Asia/Qatar Pacific/Kiritimati America/Havana Asia/Rangoon Pacific/Kosrae America/Indianapolis Asia/Riyadh Pacific/Kwajalein America/Inuvik Asia/Saigon Pacific/Majuro America/Iqaluit Asia/Seoul Pacific/Marquesas America/Jamaica Asia/Shanghai Pacific/Midway America/Jujuy Asia/Singapore Pacific/Nauru America/Juneau Asia/Taipei Pacific/Niue America/La_Paz Asia/Tashkent Pacific/Norfolk America/Lima Asia/Tbilisi Pacific/Noumea America/Los_Angeles Asia/Tehran Pacific/Pago_Pago America/Louisville Asia/Thimbu Pacific/Palau America/Maceio Asia/Tokyo Pacific/Pitcairn America/Managua Asia/Ujung_Pandang Pacific/Ponape America/Manaus Asia/Ulan_Bator Pacific/Port_Moresby America/Martinique Asia/Urumqi Pacific/Rarotonga America/Mazatlan Asia/Vientiane Pacific/Saipan America/Mendoza Asia/Vladivostok Pacific/Tahiti America/Menominee Asia/Yakutsk Pacific/Tarawa America/Mexico_City Asia/Yekaterinburg Pacific/Tongatapu America/Miquelon Asia/Yerevan Pacific/Truk America/Montevideo Atlantic/Azores Pacific/Wake America/Montreal Atlantic/Bermuda Pacific/Wallis America/Montserrat Atlantic/Canary Pacific/Yap America/Nassau America/New_York Atlantic/Cape_Verde Atlantic/Faeroe 96

Index API Development, 72 Application Customization, 60, 62 Installing, 5, 9 Licenses, 28 Logs, 73 SSL, 16 Starting, 29 Starting and Stopping, 29 Stopping, 30 Ungrading, 11 Uninstalling, 11 Application Customization, 60 Backing up the Application Data, 65 Conventions, 1 Data Backup, 65, 66 Defining an Authentication Source, 55 Frequently Asked Questions, 73 Installing, Uninstalling, and Upgrading Biscom Delivery Server, 5 Introduction, 1 Licenses, 28 Logon, 31 Managing Processes, 59 Microsoft Outlook Installing, 82 Uninstalling, 92 Scalability, 68, 69 Scalability and Server Tiers, 68 Server Configuration, 33 Information, 32 Signing In for the First Time, 31 Support and Troubleshooting, 73 System Configuration Application, 22 Configuration fds.properties, 21, 23 Hardware Requirements, 3 97

Software Requirements, 3, 4 System and Application Configuration, 21, 23 System and User Administration, 32 System Processes Delivery notification, 54, 55, 59 SMTP input handler, 59 System cleanup, 59 Users Creating, 49 Deleting, 52 Importing, 52 Inclusion and Exclusion Lists, 51 Manage, 48, 54 Modifying, 49 Resetting Password, 51 98