Best Practices for Configuration and Validation

Below is a collection of suggestions and guidelines for installing, configuring, and deploying EFT Server and/or DMZ Gateway software in a production environment.

Development Lab Environment

As with any mission-critical software or hardware, it is recommended that a testing, validation, development, or usability lab be established to provide a "sandbox" into which EFT Server and DMZ Gateway Server software can be deployed. This initial deployment allows for validation of the interoperability with other dependent components as well the validation of expected usage scenarios.

The lab environment should emulate (if not duplicate) the production environment at a network topography and application level. To do this, a clear vision of the production network and the proposed deployment of EFT/DMZ Gateway must exist. Typical deployments of EFT Server and DMZ Gateway Server consist of many other components from the enterprise, including Active Directory Server, SQL Server, SMTP Server, and a storage system such as a SAN (Storage area network; an architecture to attach remote computer storage devices such as disk arrays, tape libraries and optical jukeboxes to servers in such a way that, to the operating system, the devices appear as locally attached devices.). For DMZ Gateway, a firewall such as Microsoft ISA (Internet Security and Acceleration Server; Microsoft Proxy Server; Firewalling & Security product based on Microsoft Windows.) might be applicable. Finally, some deployments also include Microsoft Clustering, in which case various components are replicated to provide clustered resources.

For increased business continuity and risk mitigation, you should use the development lab environment as the starting point for any configuration changes in the system. That is, make the change in development and validate it prior to making the change in production.

A good testing tool is CuteFTP Professional.

Configuration Validation

The installation and configuration of EFT Server in either a lab or production environment should be validated by the EFT Server administrators/operators to ensure that the functions are working as expected. Use the checklist below to validate key items for an EFT Server and DMZ Gateway deployment. Print a PDF of the table below to check off items as you test. (You need Acrobat Reader to open the PDF.)

Service
	Make sure that the GlobalSCAPE EFT Server service is started on the computer.
	Make sure that the service is listening on the expected IP:PORT socket addresses on EFT Server. (To view the listening sockets, use "netstat -ona" from a command line or an application such as PrcView or TcpView.)
	Check the Event Viewer log to ensure that there are no errors in the Application log related to EFT Server or DMZ Gateway Server.
	Confirm that EFT Administrator shows the status of the system when it is launched and connected to EFT Server.
EFT Server User Management
	For each Site on EFT Server, ensure that the expected user accounts exist.
	To ensure that authentication is working as expected, attempt to log in to EFT Server as a user account on the system (using any protocol).
	To confirm permissions for the user account are working as expected, attempt a file transfer.
Protocol/Network
	For each protocol enabled on EFT Server, attempt a connection directly to EFT Server using a client that supports that protocol.
	For each protocol enabled through DMZ Gateway, attempt a connection to the appropriate DMZ Gateway IP:PORT and confirm that this route works as expected.
Auditing/Logging
	View the audit traces generated by the validation steps above.
	Confirm that the Auditing and Reporting module database has been populated with appropriate data (using either EFT Server Reporting interface or direct access to the SQL Server being used).
	Confirm that the text log files generated by EFT Server have been populated with the appropriate data.
Event Rules/Workflow Each customer has a unique set of Event Rule/workflow requirements, but these are the general validation steps. Confirm the following are working as expected:
	E-mail notifications. Test e-mail notifications by triggering an Event Rule that has an e-mail notification Action to confirm that Event Rules fire and that the SMTP configuration is correct.
	PGP operations. Confirm that OpenPGP keys are configured properly.
	Move/Copy/Download actions. Initiate Event Rules that perform remote file uploads/copies/download so that connectivity originating from EFT Server to a remote system is properly configured. In this step, also confirm that a log file is generated that audits outbound connection information (a "cl*.log" file in the designated Server Log File location).
	Custom Commands. EFT Server is responsible for triggering those external commands, so that is what should be validated with respect to EFT Server. Any actions carried out by those external tools should be validated independently. Confirm that a "CMDOUT.LOG" file is generated in the EFT Server installation folder as the result of an invoked Custom Command.
	Folder Monitor Rules. Ensure that the Event Rules are properly enabled and responsive to files added to the folder being monitored.
Cluster/Failover Testing
	For cluster deployments, the failover and failback operations of the cluster should be confirmed. After a failover/failback, confirm that the newly active server behaves properly; that is, the failover is transparent and the configuration/operation is as expected. This can be summarized by the prior set of tests operating against the newly active node in the cluster.
Load Testing
	If you expect high volumes of traffic or back-end processing within EFT Server, you should verify that the resource utilization levels on EFT Server are within acceptable tolerances. There are numerous load-testing tools available, ranging from simple batch files running command-line FTP to highly complex synthetic transaction generators. GlobalSCAPE's Quality Assurance team performs load testing of our servers as part of our standard validation process for releasing software and can provide guidance and/or tools to assist in load testing.

Numerous other features can be validated within EFT Server. The above set represents the key elements that are most often used and are the most critical to successful operation in a production environment.

Prescriptive Guidance for Maintenance

The following are guidelines for maintaining the good health of an EFT Server and DMZ Gateway server deployment, and reducing long-term costs of maintenance and operation.

Configuration Backup - For disaster recovery and business continuity, it is important to keep backups of EFT Server and DMZ Gateway server configuration. Backing up the configuration can be accomplished with a variety of tools such as Symantec Backup Exec, Ghost / VMWare to make images of the system, GlobalSCAPE Continuous Data Protection (CDP), or even a simple script file.

Database Backup and Truncation - If you are using the Auditing and Reporting module (ARM), the SQL Server to which the audit records are stored should include EFT Server ARM tables as part of the typical database maintenance plan. This includes proper monitoring of the tables and transaction logs, backing up the data and having a retention policy to archive (or purge) old data.

Restarting Services - Given the facility of the Microsoft Cluster in failing over and failing back while providing high resource availability, it is recommended that you design a maintenance schedule in which the EFT Server service is cycled at least once per quarter to once per month. Failing over to the backup node, restarting the service, then failing back and restarting the other node would suffice in re-establishing a baseline state of the EFT Server service to ensure optimal health.

Data Archival and Retention - It is suggested that a policy be put in place and enforced by which old data is periodically archived and/or purged, because no disk is limitless and performance can degenerate as more files are added to the Server. Therefore, a storage management policy should include regular inspection of available hard disk space and health (error count, fragmentation, etc.) as well as archiving and/or purging user data and Server Log Files (CMDOUT.log found in the application folder, and all other logs found in the Log folder specified at the Server level in EFT Server).

Performance Counter Monitoring - DMZ Gateway (Server designed to reside in the demilitarized zone to provide secured communications with EFT Server behind intranet firewalls without requiring any inbound firewall holes between the internal network and the DMZ.) Server provides a Performance Counter object to the computer on which it is installed. This object provides a standard Windows mechanism to view activity through DMZ Gateway and, in general, assess the fundamental health of the system as a whole. It is recommended that the enterprise operations practices include monitoring the key performance counters (automatically is preferred) by adding the "EFT Gateway" performance object to Microsoft's Perfmon, and monitoring items such as "Active Sites" (indicates up/down state of EFT Server through DMZ Gateway) and "Active Client Connections" (indicates activity through the DMZ Gateway to EFT Server).

Event Log Alerting - EFT Server will log error conditions to the standard Windows Event Viewer. It is recommended that the operations team for an enterprise include the EFT Server error checks in their monitoring techniques, looking for an ERROR event generated with a source of "GlobalSCAPE EFT Server" or "GlobalSCAPE EFT Gateway" service.

Procedure for Cold Standby Setup

Below are few recommendations for achieving a backup server image that is ready to be quickly turned on and accept "real" traffic.

In all situations, if we are copying a configuration file from one system to another, care must be taken with hardware-specific resources, such as IP addresses, physical paths/partitions, and so on. If possible, it is recommended that the EFT Server configuration use the generic "All Incoming" IP Address for incoming socket connections so that differences in computer IP addresses do not prevent proper operation of the system if the Cold Standby comes online.

Furthermore, we must take care with the connections and IP-access restriction lists between EFT Server and DMZ Gateway. If the DMZ Gateway is configured to allow only one EFT Server IP address to connect to it, then the Cold Standby server must have the same IP address to connect; alternately, the DMZ Gateway IP access list must include all possible IP addresses (possibly a Class C subnet) so that multiple servers from the approved network segment may connect.

Virtualization Software - A great solution from a cost- and resource-saving standpoint, it is also quite easy to manage due to the "software" nature of the solution. The approach would be to create an image within a Virtual system (using a tool such as VMWare or Microsoft Virtual PC) by installing and activating EFT Server or DMZ Gateway server software. Once this is done, the steps required to bring the system online include first copying the configuration files (which were backed up using a process described above), then bringing the virtual image online and starting the service.

System Backup Software - Another quick and easy option is to create a disk or system image of a configured EFT Server or DMZ Gateway server (using a product such as Norton Ghost); when a Cold standby needs to be "stood up" and made hot, the image can be installed on a computer, backup configuration copied, and the service started.

Periodic Backup to Cold Standby Machine - If resources permit, the quickest way to get a "Cold" computer to become "Hot" is to have a computer dedicated to this function. It should have EFT Server and/or DMZ Gateway server installed and activated, but the service should be stopped. A process to copy the configuration periodically from the "Hot" server to the "Cold" server would keep the two in synch, and if the "Hot" system goes down, the "Cold" system can simply start the service.