WS_FTP (v7.1) Deployment/Installation

— ny_wk

Deploying WS_FTP Server 7.1 means installing the Ipswitch FTP service on Windows, activating its license (online or offline), locking the listener to FTPS over SSL, wiring up Active Directory authentication, and exposing virtual folders for inbound and outbound files. This guide walks the full build end to end, fixes the gotchas that break a first deployment, and verifies every step so the server actually accepts secure connections.

Important compatibility note first. WS_FTP Server 7.1 is a legacy, end-of-life release. The product is now Progress WS_FTP Server (Progress acquired Ipswitch), and the modern supported line is the 8.x series. If you have any choice, deploy the current 8.x release on a supported Windows Server build, because 7.1 ships old TLS/SSL defaults and an old Microsoft IIS dependency that fail modern security baselines. The steps below remain useful for maintaining an existing 7.1 estate, migrating off it, or understanding how the product is wired.

Before you start: WS_FTP Server 7.1 prerequisites

A clean install fails most often because of missing platform pieces or an under-planned firewall. Confirm all of the following before you run the installer.

A licensed installer (WS_FTPServer71.exe) and a valid serial number. The activation account (the username and password you type during activation) is your Ipswitch/myipswitch.com customer login, not a Windows or AD account.
A supported Windows Server with local administrator rights. 7.1 relies on IIS for its web administration component, so the IIS role must be installed first.
Microsoft SQL Server or the bundled PostgreSQL for the configuration data store, depending on your edition.
A firewall plan. Decide your control-channel port and a fixed passive data-port range up front. FTPS cannot negotiate passive ports dynamically through a firewall the way plain FTP sometimes can, so you must pin a range and open it.
An SSL certificate path. Know whether you are generating a CSR for a public/enterprise CA or importing an existing certificate and key.

Plan your ports now. The classic 7.1 runbook deletes the default plaintext port 21 listener entirely and stands up an FTPS listener on a dedicated port instead. In the example build below the secure control port is 889 and the passive data range is 889–890; pick values that match your firewall change request and use them consistently everywhere.

Step 1: Run the WS_FTP Server 7.1 installer

Run WS_FTPServer71.exe and click Next on the welcome screen.
Select I accept the terms in the license agreement, then Next.
Accept the component and install-path defaults (click Next through the wizard) unless your standard requires a non-default drive.
When prompted for the server name, enter the host this instance will identify as, then Next.
Create the WS_FTP administrator account. This is a local WS_FTP user (for example wsftp_admin) used to log in to the Server Manager — it is not an Active Directory account. Record the username and password in your password vault.
Click Install and let the files copy.

The local admin account you create here is what you will use in Step 5 to open the Server Manager web console. Confusing it with an AD account is the single most common reason a new admin cannot log in afterward.

Step 2: Activate the WS_FTP Server license

Activation proves the install is licensed. There are two paths — online (the server has internet access) and offline (the server is isolated, which is common in production DMZs).

Online activation

When the installer asks for licensing, enter your serial number and click Activate.
Enter the username and password from your myipswitch.com account (the credentials used when the license was purchased), then Activate again.
On success the activation manager confirms the license and you can Finish.

Offline activation (no internet on the server)

Use this when the server cannot reach the activation service directly.

In the activation manager choose the offline option and click Generate File, then Save. By default the request file license.ofa is written to C:\Windows\SysWOW64\.
Copy license.ofa to any machine with internet access.
Open the vendor offline-activation page in a browser, click Browse, select license.ofa, and Submit.
The site returns a license.txt response file — Save it.
Copy license.txt back to the WS_FTP server under C:\Program Files\Ipswitch\Common.
Back in the activation manager click Next, Browse to the license file, and Activate, then Finish.

Note: the legacy offline-activation URLs from the original Ipswitch era have changed under Progress. If the old offline page no longer resolves, open a support case with Progress for the current offline-activation endpoint rather than guessing at a URL.

Moving a license between machines

A license is bound to a host, so a server rebuild or hardware refresh requires a clean hand-off.

On the old machine, run the activation manager and deactivate the existing license to release it.
On the new machine, activate using the same serial number (online or via the offline file flow above).

The server typically restarts after a successful activation. Plan a short maintenance window. Skipping the deactivation on the old box is what causes "already activated / seat in use" errors on the new one.

Step 3: First login to the WS_FTP Server Manager

The Server Manager is the IIS-hosted web console where all configuration happens.

Open WS_FTP Server Manager from the desktop shortcut or Start → All Programs → Ipswitch WS_FTP Server → WS_FTP Server Manager.
Enter the local admin username and password you created in Step 1 (for example wsftp_admin) and click Login.

Heads-up on a login gotcha: once you add a second host later (Step 7), the Server Manager may stop accepting a bare username and require the host suffix. If you get Authentication Failed after adding a host, log in with the fully qualified form, for example wsftp_admin@your-server.fqdn — the @host part tells the manager which host to authenticate against.

Step 4: Replace plaintext FTP with an FTPS listener

This is the security heart of the build. You remove the default cleartext listener and create a dedicated SSL listener.

Click Listeners. Select the default Port 21 listener and click Delete. Plaintext FTP transmits credentials and data in the clear and must not survive a secure deployment.
From Home → Listeners, click Create.
Enter the server's IP address and the secure Port (for example 889).
Click Add, select the Host Name to bind, click OK, then Save.

Configure the passive data-port range

FTPS needs a fixed, firewall-friendly passive range or transfers will hang after the control channel connects.

Go to Host Settings → Firewall Settings and open Firewall — Passive Connection Settings.
Set the external IP address clients reach (this differs in QA, production and DR — confirm each environment's address).
Add the port range (for example 889–890) and Save.

Open the same control port and passive range on every firewall between the client and server. A mismatch here is the number-one cause of "connects but directory listing times out."

Step 5: Create or import the SSL certificate

FTPS requires a server certificate. Decide whether you are generating a new CSR for a CA to sign, or importing an existing certificate and key (the usual path for primary + DR pairs that must share one identity).

Verify the trusted root first

Before issuing anything, confirm the correct root CA is trusted on the server so the signed certificate will chain properly. In the certificate store, open Trusted Root Certification Authorities and confirm the expected root is present and valid (matching the fingerprint your PKI team supplies). If production is missing the right root, request it before continuing — a certificate that does not chain to a trusted root will be rejected by clients.

Generate a certificate and CSR

In the manager go to Server → Other Settings → SSL Certificates and click Create.
Fill in the certificate fields:
- Passphrase — a private-key passphrase you store securely.
- Name — a temporary friendly name (e.g. PrdTemp); you can rename later.
- Email — for production, the production-support distribution list.
- Common Name (CN) — must exactly match the hostname clients connect to (a mismatched CN/SAN throws certificate-name warnings).
Click Save, then select the new certificate and click Export Certificate Signing Request.
Export both the CSR and the private key and save copies to the DR server as well, so the secondary can import the identical identity.

Get the certificate signed and import it

From a machine with access, open your enterprise/public CA's web enrollment portal and choose the option to create a web-server certificate from a PKCS#10 request.
Paste the CSR contents from C:\Program Files\Ipswitch\WS_FTP Server\SSLFiles\*.csr and submit.
Download the signed certificate, saving it as a .cer file (name it to match the CSR for easy tracking).
Copy the .cer back to C:\Program Files\Ipswitch\WS_FTP Server\SSLFiles and import the key on both the primary and DR servers.
Point the host's SSL setting at the imported certificate, then Save.

Restart the WS_FTP service so the new certificate is loaded by the listener.

Step 6: Force SSL so transfers are always encrypted

Issuing a certificate is not enough — you must require it.

Go to the host's Other Settings → SSL Settings.
Enable Force SSL and Force SSL for the data channel, then Save.

Critical behavior: enabling Force SSL applies to all ports on that host, so any client must use FTPS. Forcing SSL on the data channel (not only the control channel) is what stops file contents from being sent in the clear — a control-only TLS configuration still leaks the actual data. On a legacy 7.1 box, also disable obsolete protocols (SSLv2/SSLv3 and weak ciphers) wherever the version exposes the option, and treat the inability to disable them as a reason to migrate to 8.x.

Step 7: Add Active Directory authentication on a second host

Production WS_FTP almost always authenticates real users against Active Directory rather than the local user database.

Go to Home → Change host → Create.
Enter the new Host name, and for User database select Microsoft Active Directory Database.
Click Configure and set the Organizational Unit to the full distinguished name (DN) of the OU that holds your service/user accounts, for example:
OU=Service Accounts,OU=Domain Administration,DC=office,DC=adroot,DC=example,DC=net
Click OK, then Save.

Use the correct DN per environment — development, production and DR live in different OUs and domains, so copy the exact string from your directory rather than editing one by hand.

Synchronize and lock down AD users

Go to Home → Change Host and select the new AD host.
Click Users, then Synchronize to pull accounts from the chosen OU.
Open each relevant user, enable Lock user to home folder, and Save. This jail prevents a user from traversing outside their assigned directory.

Remember the login change from Step 3: after the second host exists, log in to the manager with admin@host.fqdn if a bare username returns Authentication Failed.

Wire the new host into the listener and firewall

Add a passive range for the new host: Home → Change host → select the host → Other Settings → Firewall — Passive Connection Settings, add 889, 890, set the external IP, Save.
Attach the host to the listener: Listeners → click the IP for port 889 → Add → select the host → OK.
Select the new host and click Set Default, remove the old default binding, then Save.

Step 8: Restart services and create virtual folders

After binding changes, restart the services so they take effect.

Go to Services, select the WS_FTP Server, web, and SSL notification services (you do not need the SSH/SFTP service unless you also serve SFTP), and click Restart.

Now publish the directories users will actually read from and write to using virtual folders, which map a friendly name to a real path.

Go to Home → Folders → Create virtual folder.
Create SEND pointing to a real path such as E:\stage\send.
Set Virtual display location to Display in user so the folder appears in the user's root.
Click Add, select the correct user(s), OK, then Save.
Repeat to create REC pointing to E:\stage\rec.

Turn up logging for the first weeks

During rollout, raise the log level so you can troubleshoot quickly.

Go to Server → Other Settings → Log Settings.
Set Logging level to Verbose and Save.

Dial logging back to a normal level once the server is stable, because verbose logs grow fast and can fill the system drive.

Common pitfalls and how to avoid them

Using an AD account to log into the Server Manager. The console admin (wsftp_admin) is a local WS_FTP account. After a second host is added, use the admin@host.fqdn form.
Forgetting the passive port range. Clients connect on the control port but data listings and uploads time out. Pin the range (e.g. 889–890) and open it on every firewall.
Forcing SSL on the control channel only. File contents still travel in the clear. Always enable Force SSL for the data channel too.
Certificate CN/SAN mismatch. The Common Name must match the hostname clients use, or every connection throws a name-mismatch warning.
Not exporting the key to DR. Import the same certificate and private key on the DR server so failover does not break trust.
License left active on the old host. Deactivate before activating elsewhere to avoid seat-in-use errors.
Leaving SSLv2/SSLv3 enabled. 7.1 defaults are weak; disable legacy protocols or, better, move to the supported 8.x line.

Verification: confirm the deployment actually works

Do not declare success from the GUI alone — test like a real client.

Service state: confirm the WS_FTP and web services are Running in the Services panel and in Windows services.msc.
Listener bound: from the server, run netstat -ano | findstr 889 and confirm the port is in LISTENING state on the expected IP.
Plaintext is gone: attempt a plain FTP connection on port 21 — it should fail/refuse, proving the cleartext listener is removed.
FTPS handshake: connect with an explicit-FTPS client (for example FileZilla set to "Require explicit FTP over TLS") on port 889 and confirm the certificate presented matches your CN and chains to a trusted root.
AD auth: log in with a synchronized AD user and confirm they land in their home folder and cannot navigate above it (lock-to-home working).
Data channel encrypted: upload a file into SEND and download from REC; verify the client reports TLS on the data connection, not just the login.
Logs: open the verbose log and confirm the successful TLS session, the user authentication, and the file transfer are all recorded.

When all seven checks pass on both the primary and DR servers, the deployment is complete and resilient.

Key Takeaways

WS_FTP Server 7.1 is end-of-life — build it only to maintain or migrate an existing estate, and prefer the supported Progress WS_FTP 8.x line for new work.
Delete the port 21 plaintext listener and replace it with a dedicated FTPS listener, then enable Force SSL for both control and data channels.
Pin a passive data-port range and open the control port plus that range on every firewall, or transfers will hang after connecting.
The Server Manager admin is a local account, not AD; once a second host exists, log in as admin@host.fqdn.
Export the certificate and private key to DR and verify with a real FTPS client, AD login, and an actual upload/download before sign-off.

Frequently Asked Questions

Is WS_FTP Server 7.1 still supported?

No. Version 7.1 is a legacy, end-of-life release from the original Ipswitch era. The product is now Progress WS_FTP Server, and the supported line is the 8.x series. Keep 7.1 only to maintain existing systems, and plan a migration to a current version on a supported Windows Server, since 7.1 carries outdated TLS defaults and an old IIS dependency.

What is the difference between FTPS and SFTP in WS_FTP?

FTPS is FTP wrapped in SSL/TLS (the SSL listener and certificate this guide configures), using a control channel plus a passive data-port range. SFTP is a different protocol that runs over SSH on port 22 and is handled by WS_FTP's separate SSH server component. They are not interchangeable; configure whichever your clients require, and you do not need the SSH service running if you only serve FTPS.

Why do my FTPS uploads connect but then time out?

Almost always a passive-port problem. FTPS opens a second connection for data on a port from the passive range, and if that range is not pinned in WS_FTP and opened on the firewall, the data channel never establishes. Set a fixed passive range (for example 889–890), set the correct external IP, and open both the control port and the range on every firewall in the path.

Can I move a WS_FTP license to a new server?

Yes. Run the activation manager on the old server and deactivate the license to free the seat, then activate the same serial number on the new server, online or via the offline .ofa/license.txt file flow. Deactivating first prevents "already activated" errors.

Found this helpful? Subscribe to @explorenystream on YouTube for more sysadmin and deployment walkthroughs.