Error 1053 after configuration steps for Network Reshare
Brand new installation on 2003R2 host. Initial install works and starts without error. Configure the host to support Network Reshare (user added to policy to allow login as service, act as part of the OS) and attempt to start the service. Fails with error 1053. No, it's not a network interface issue (access the host over RDP).
Since the error is a generic one, how do I diagnose the problem?
Error 1053 is a generic service failure code and could be caused by many different things.
However, if you see this error while starting the Acronis Access Connect service the most likely cause is that there are no IP addresses available for the service to listen on.
Also, even though you stated that it's not a network interface issue the other most common reason is a network interface has been disabled because of an unplugged cable. If everything is OK with cabling then in attempt to resolve this issue, verify that the network interfaces on the Acronis Access Connect host are enabled and configured properly.
Already confirmed this, repeatedly. It's not a network interface issue.
I remember a support case where the issue with the same symptoms and similar troubleshooting steps was resolved by completely disabling IPv6 using the registry: http://tweaks.com/windows/40099/how-to-properly-disable-ipv6/. I don't think it should be a general solution, rather just a worthwhile test.
As mentioned, error 1053 is a generic service failure code and the following KB article https://kb.acronis.com/content/39622 explains the most common root causes. However, if it is not the case and the trick with IPv6 disabling doesn't work or is unacceptable, we have to take a look at the logs. The main ones are the ExtremeZ-IP Logs folder (C:\Program Files (x86)\Group Logic\ExtremeZ-IP\Logs) and the ExtremeZ-IP LOG_Startup file in C:\Program Files (x86)\Group Logic\ExtremeZ-IP.
Feel free to collect them and open a support ticket at http://www.acronis.com/en-us/contactsupportgl.html.
I'm on an 2003 server. IPv6 was on by default in 2008 (and newer).
What caused the service to behave to radically different by switching from no account to a named account?
That's a good question and logs can help us to find this out (if all the solutions above were not effective), otherwise we can only make guesses and speculate. BTW, please note that Acronis Access Connect won't support Windows Server 2003 in future since it is already not supported by Microsoft (the end-date was July 14, 2015), so migration is worth it: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/.
What logs do you need?
How did this get out of Beta with this functionality not working? I followed the steps in the documentation and it fails to start and reports a generic error, suggesting that the error trapping or exception handling is incomplete.
I realize 2003 is off-support. It's not relevant to the issue as we're demoing the features to determine whether it will work for us and whether we should purchase it. So far it's been a stunning failure.
In order to run Acronis Access Connect (formerly ExtremeZ-IP) Service under the credentials of a domain user, you must first allow the domain user the ability to "Act as part of the operating system". Please refer to the following articles for more details: https://kb.acronis.com/content/39551 and http://www.acronis.com/en-us/support/documentation/AccessConnect/index.html#30098.html.
As mentioned above, the main logs we are interested in are the ExtremeZ-IP Logs folder (C:\Program Files (x86)\Group Logic\ExtremeZ-IP\Logs) and the ExtremeZ-IP LOG_Startup file in C:\Program Files (x86)\Group Logic\ExtremeZ-IP.