This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Serv-U 15.3.2 Error Start Service. Error 1068

When installing Serv-U 15.3.2 the Serv-U service does not start. Error 1068. NT Authority/Network Service account failed. I configured it to log on to the Local System account and it worked.

Windows Server 2022 System.

Parents
  • Hello, from which type of Administrative account the installer ran? Thanks

  • Hi.

    Local adm. Installation in the same environment as 15.3.1

  • Based on investigation of the reported problem, we would conclude the following suggestions:

    1. It looks that Serv-U Host is set up such a way that starting a service (in our case it's Serv-U) under NT Authority\NetworkService account is not allowed. It may be a special constrain applied for security reason.
    2. If 1. is true, then we advise against relying on NT Authority\NetworkService. In this case, we would suggest manually switching Serv-U to run under either the previously used Local System account or another specially created or chosen one. Of course, the NT Authority\NetworkService can be chosen as well. However, it may require manual creating additional special conditions that allow starting Serv-U. Such Conditions cannot be "programmed" because their possible types, number and combinations make the challenge not feasible.
    3. In conclusion, so far we don't see any errors in Serv-U due to the reported issue. On the contrary, we see that Serv-U cannot be used with restrictions, possibly imposed for security reasons. Actually, this is exactly what we wanted: to block to use Serv-U to bypass protection.
Reply
  • Based on investigation of the reported problem, we would conclude the following suggestions:

    1. It looks that Serv-U Host is set up such a way that starting a service (in our case it's Serv-U) under NT Authority\NetworkService account is not allowed. It may be a special constrain applied for security reason.
    2. If 1. is true, then we advise against relying on NT Authority\NetworkService. In this case, we would suggest manually switching Serv-U to run under either the previously used Local System account or another specially created or chosen one. Of course, the NT Authority\NetworkService can be chosen as well. However, it may require manual creating additional special conditions that allow starting Serv-U. Such Conditions cannot be "programmed" because their possible types, number and combinations make the challenge not feasible.
    3. In conclusion, so far we don't see any errors in Serv-U due to the reported issue. On the contrary, we see that Serv-U cannot be used with restrictions, possibly imposed for security reasons. Actually, this is exactly what we wanted: to block to use Serv-U to bypass protection.
Children
  • As for 3rd - I had to roll back the virtual machine from backup, since SERV-U somehow lost the customer domain in the process of switching back from Local System (which caused the server identity go away) to Network service and back to Local System.

    Backup with switchback to Network service seemed to run, but the FTP users failed to login. So I had to export the server ID, change to Local System again and import the server ID.

    Best greetings from Germany
    Olaf