Checking Port and Firewall Access
If you are experiencing problems with connection or job timeouts, firewalls and port access are two of the first items to look at. You will need private access through the firewall for cfp_windows if the Windows App is installed, and public access for Cloud FastPath. The Windows App will request that you allow access through the firewall during installation. Additionally, you will need access via port 443 to the IP addresses for ctl.www.cloudfastpath.com and www.cloudfastpath.com. You can obtain that IP address with the nslookupcommand. For example, to get the IP address for ctl.www.cloudfastpath.com, open the command window and enter:
If you cannot open port 443, you can switch the Win app to port 61614 by right clicking the Win app cloud icon in the system tray and selecting Register Computer…. Change the Service Port from 443 to 61614, re-enter your password, and click Register.
You may also need to configure access to the IP addresses for any POPs that the Windows app must access. Ask email@example.com for assistance with setting up your account with static IP POPs.
Checking for Proxies
After firewall issues, proxies are the most common cause of connection issues. To determine whether the Windows app machine has a proxy, you can enter this command:
netsh winhttp show proxy
This powershell command may show proxies if the command above does not:
Get-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’
The proxy could also be defined via the HTTP_PROXY, HTTPS_PROXY, FTP_PROXY environment variables.
Proxies are not supported by the Windows app.
Checking for Antiviral and Security Software
Anti-viral software and other security systems have in some instances also prevented the Windows app from starting or connecting. They should be evaluated in the normal course of troubleshooting.
If All of the Above Still Fail:
If you are still having issues, the following command can sometimes shed light on the hops the Win app is taking to get to ctl.www.cloudfastpath.com:
Identifying where the break in connection is occurring can sometimes point to IT set-up issues or other reasons for failure to connect.
Also ensure that the installing user is an admin for the Windows apps installed in App mode. For Windows apps that will run in service mode, the user should be a local admin on the installing machine.
For a Windows app that has been connected for a while, but suddenly stops connecting, a new download of the .msi file from the CFP dashboard or from https://www.cloudfastpath.com/winapp can frequently resolve the issue. Even though the tasks for the Windows app update automatically and remotely, the .msi file should be updated every 8 weeks or so as a best practice. You can install the new .msi over the old one; uninstall of the old .msi is not needed.
There are several utilities in the directory C:\Program Files (x86)\Tervela\Cloud FastPath\utils for the machine where the Windows app is installed:
- troubleshooter.bat: copies Win app log files and places them in a folder on the desktop. These can then be uploaded to a shared folder on a service provider so Tervela can diagnose connectivity issues. Do not email this folder as it is generally too big to go through mail and may contain information about files and folders that should not sent via insecure protocols.
- show_attached_drives.bat: lists out all of the drives that are currently connected to the Win app for the currently logged in user. The command powershell gwmi Win32_NetworkConnection accomplishes the same thing.
- cfp_drive_insomnia.bat: for drives that are poorly connected to the host and prone to disconnection due to inactivity, cfp_drive_insomnia periodically pings the drive and thereby keeps the connection alive.
Each of these batch files may be run by double clicking them.
The following link provides useful information on Windows error codes (e.g. code 5, code 65):
Sometimes knowing whether the code relates to a permission issue, network issue, or something else is useful in identifying why files won’t transfer over.
This link addresses a scenario when URL drives don’t show up when the Win app is run as an admin, but do show up when run as a non admin: