We have a data server where TaxCycle is installed as the Client Manager. Then our individual workstations are connected to that client manager.
We seem to be running into problem with the client manager connection, and I suspect it’s because of different version being run. Now I enable the Auto-update in the TaxCycle options on both the server and all machine.
I was under the impression that auto-update would run the update automatically depending on the frequency set in the options below, but with all the issues coming up, I’m suspecting that it an auto-check-for-update rather than an auto-update.
Am I understanding this correctly or am I missing something?
Does the auto-update still require someone to click “yes, please update now” (which would leave the server behind as there are generally no one logging into it), or is it actually automatic?
I suspect that the program needs to be running on the server for the auto update to work.
I have been running this setup for a number of years and basically follow this process to update.
I am running Windows Server 2008 R2 at the moment and have activated remote desktop on the server. When an update is pushed out by Taxcycle, I will log onto my server from my office computer using RDP and run the update then close the RDP session.
The only problem with leaving the program running on the server would be the weekly Microsoft update that will cause your server to reboot. I am not sure Taxcycle will automatically restart after the reboot; therefore, possibly causing the process to fail. That being said, let me know if it does work.
I guess we are back to the original status. The update to 6.1.31377.0 once again turned off the client manager on my server. Is there any way to stop the program from doing it?
I guess I am trained now to update the server and then go restart the Client manager; however, it would be nice it the program would not shut it down.
Mine is Windows Server 2008 R2 as well. I guess it is my system that is causing it; however, all I did was install the program and setup the client manger. No special modifications required to get it to work that many years ago.
That being said, I will just live with it. I plan on upgrading my server this summer anyways so I will see what happens after that.
We’re always keen to improve this, of course, but we need to figure out what is different about your server configuration so we can reproduce the problem that you see in our office.
I appreciate the offer; however, I am not sure there is an easy way to determine the cause. I have been running it on my server from the day it was released so it is possible it has something to do with the first installation or it has to do with the way the server was setup.
I now know what causes the server to stop responding and it is only 30 seconds to fix and I expect that when I upgrade the server the problem will go away.
Here is something you can try. I just ran the update from version 6.1.31567.0 and the Client Manager was up and running after the update.
The difference this time was I clicked the install update from the start page and let the program update and at the end the program restarts.
Usually I just let it load the update and close the program clicking on the prompt asking me it I want to update to the new version. When this happens, the program does not restart. Have you attempted to recreate this issue both ways?
We are having this same issue. Running an update thru RDP and run the update from the start screen. We also have the problem if the server need to be rebooted. We are running Server 2008 R2 as well. The problem I have is that I have to enter the server password on the properties screen under the logon tab every time I start the service. Again this is not a big deal but it would be nice if it restarted with out intervention.
Rebooted due to Microsoft updates and set again…