Bill Foster - 2018-01-26

I'd be interested in what people have experienced trying to run the UFTP client as a Windows service. I was interested in doing so on our Windows 7 & 10 systems. The reason I took this path was because:
1. The nature of the UFTP client seemed like it should be run as a service. No UI needed and it runs in the background listing for a broadcast.
2. I needed a way to start the client and this is a way it could be done early on in the boot cycle and a user login was not required.
3. Services are monitored by the OS and one can configure the service to be restarted if it crashes. This was the main reason I was attracted to this strategy.
4. I've worked with other Multicast clients in the past and they were run as a service.
5. The Windows client is distributed from SourceForge with the tools necessary to run the client as a Windows service and they give the instructions on how to do so. This being so, it must be the right thing to do right?

I pursued this direction setting it up as specified with some help from information on other web sites as well. I chose to get the instsrv.exe and srvany.exe from the Microsoft web site since I was concerned about the legalities of distributing these tools from a different source. The latest version is available free as part of the Windows Server 2003 Resource Kit Tools (https://www.microsoft.com/en-us/download/details.aspx?id=17657). Yes, this is the latest version. From what I have read, this version has been tested by others and they found that it works fine on many versions of Windows including Windows 10. I was able to get everything up and functional in our lab. It worked and operated quite well. I began running a lengthy systems test that took several days. During this test I discovered some short falls:
1. I found at times the uftpd.exe app was not running. This was intermittent. It would happen after an auto-shutdown and startup of our systems overnight. Looking further I found that the SRVANY.EXE process was running fine but uftpd.exe was not. There was no logging in the event log or other logs as to why uftpd.exe was not running. I suspect that uftpd.exe is dependent on services that may not have been up at the time the service was started. There are ways to add dependencies for the service to delay it's startup but I would need to determine what those are. I found this clue on the Microsoft web site:
"The failure may be because your program is dependent on another application (or service) and that was not ready when it was started by Srvany. If so, try to add relevant services as dependencies. I suggest "Workstation" and "Remote Procedure Call (RPC)" if your application expects to use the network."

    From <https://social.technet.microsoft.com/Forums/windowsserver/en-US/75f73016-08cc-42c6-a475-2093ab39248e/problem-with-srvanyexe-after-server-crash?forum=winservergen>
  1. The main reason I chose to run it as a service was to take advantage of the service being restarted if it crashed. As you can see in #1, this was not the case. Also, I tested killing the uftpd.exe process using task manager and saw that nothing happened. The SRVANY.EXE continued to run and the uftpd.exe client was not restarted. It wasn't until I killed the SRVANY.EXE process that the system restarted the service, bringing up ufptd.exe as a result. One can watch the system event log to monitor service activity. When I killed SRVANY.EXE it logged that the service had stopped and said the it would be started in 60 seconds. Sure enough, the service was restarted 60 seconds later and uftpd.exe came back up. When I killed the uftpd.exe process nothing was logged. It appears as though some sort of relationship between SRVANY.EXE needs to be in place but I haven't seen anything to indicate that this is possible. This finding removed the primary purpose in my mind for running it as a service.

At this point I have abandoned this strategy and have decided to start the client using a Windows registry Run key. Hopefully the client is stable enough to not require monitoring and restarting. There are third party tools that provide more advanced means to run this as a service but I have chosen not to pursue them due to time constraints. Should reliably prove to be an issue in the future I will pursue this option further.