a week ago - last edited a week ago
I have just installed a fresh copy of V19 Pro update 4 on four Windows 7 Pro 64 bit workstations. One of the machines was just built with a fresh install of Win7 Pro 64 bit. On all 4 machines the Scheduler service was not installed. After searching for the knowledge base I stumbled on this article http://kb.act.com/app/answers/detail/a_id/25101/kw
Well it is nice that a patch was issued. However it appears that this problem has been going on for quite a while. It seems that the problem exists in multiple versions going back several years. I suspect that this problem exists on all systems, but most users just have not noticed it. You will not discover this problem unless you try and launch the ACT Scheduler.
Why is this not being fixed with each new release of the product? Why is the problem not fixed via an update for existing installations?
I would ask the developers to fix this problem once and for all. I would ask the user community to check their systems and confirm that their systems also have this problem...
This issue is certainly not one that affects all users. It's cause is most likely an environmental issue, affecting the installation process, or modifying it afterwards.
Some potential culprits could be:
I did not personally experience this issue on my installation of Act! v19 on Windows 10, and I would expect that most users don't either.
Wednesday - last edited Wednesday
Thanks for your reply. Well again this is the case on 4 different Win7 64 bit machines. One of which was a brand new build. With this in mind then registry permissions could not be the problem. Antivirus software is not the problem either. All machines are running Microsoft Security Essentials. UAC checking is also not the problem. All machines are running default level UAC checking. Here is the thing, the other ACT services get installed just fine. Since all services are stored under the same registry key and were not interfered with by Antivirus or UAC checking, I can not see how any of these conditions apply. BTW, do you actually use the scheduler? Have you tried and launch it via the Tools menu?
Wednesday - last edited Wednesday
Thanks for your testing. I just do not understand how this has happened on all four of my installations. I will installing a 5th machine in the next week or so. It will also be a fresh Windows install as well. I will see what happens this time and post my results.
BTW are your Win7 machines 32 or 64 bit?
I also notice after I installed the patch, the scheduler does launch, however the service which is set to automatic start is not running. When I try to manually start, it start and stops immediately. Perhaps this is because I do not have any tasks created yet. Could you please confirm this behavior on your machines?
I was wondering if you could also have a look at my other post? Thanks for your support...
Once again thanks for your reply. I am going to create a database back task in the next few days. Then I will see if the service will stay running. Do you happen to have any active scheduled tasks? If you check your services mmc, you should be able to see if the service is running. If not then try and start it and see what happens. Thanks for your support...
I have some good news and bad regarding this issue. The good news is that once I created a task, the service stays running. The bad news is that there is a problem with the User Interface program. The user interface for the scheduler triggers UAC checking. Even worse you cannot disable the UI. The service will re-enable the UI registry startup entry every time the service is started. It should also be noted that the UI is not even required for the tasks to run. Yet it is forced on the user. This has been a problem for a long time. It seems the developers have chosen not to fix this. Here are the articles regarding this issue...
This one does not work...
This one offers a work around, but it is not very clean and causes issues. Please read this one carefully. Pay special attention the the last post by holisticdeveloper. He has proven that the UI is not required for the tasks to run. He also states that with this workaround, you cannot make any changes to the tasks.
This needs to be addressed by the development team. The service should not re-enable the registry startup key for the UI. The usage of the UI should be the users choice, not forced on them. Could you please forward this to development?