I need some help please! Probably in more way than one, but specifically I’m hoping somebody else here has already seen and solved this one:
It’s on Epicor 10.2.300.x - I have applied the very latest build (8), and still see the same issue. I also built a brand new Server 2012 R2 VM, installed new Epicor App server and it’s the same!
I have an open case with support (CS0001354080), but I need a quick resolution to be able to continue testing ready for planned upgrade from 10.1.600 to 10.2.300 in March!
One additional question - has the task agent started at all for you since the update?
Some patch levels now are requiring the uninstall and reinstall of the task agent? Have you tried this? I remember .2 to .7 calling out this need in the update guide.
After this answer I will have more suggestions probably.
Yep I spotted that there was an updated task agent installer in the 10.2.300.7 update, so uninstalled and reinstalled that one. I did the same for 10.2.300.8.
Another strange thing that I didn’t mention was that immediately after installing the task agent, it opens up the task agent config. This opened quickly, and said the service was running. I tried to add an agent, but it wouldn’t let me because LOCAL SERVICE is not setup for SSO - this is expected, so I stopped the windows service and changed the log on as to be the correct domain user which is linked to an Epicor user.
The service starts again perfectly from the windows services console, but when opening Task Agent config complains that the service isn’t running - which is blatently is!
If you go to C:\ProgramData\Epicor Software Corporation\ICE TaskAgent Service do you have additional info under the Logs folder? Do you have the 3.2.300.0 folder and a configuration file in that folder? If so, could you post the contents of each file?
I am not sure why, but in my experience the fully-qualified server.domainname.com\EpicorInstance gets wiped out and you have to manually enter it in the “Properties” of the Admin Console, then click the “Test Connection” button.
So, you need to specify something like this:
Name: server.domain.com/EPICORPROD1023
Endpoint: net.tcp://server.domain.com/EPICORPROD1023
Binding: Windows
Also, make sure you had clicked the “Token Authenication”.
If still having issues, completely uninstall the Task Agent and re-install the one under Supplemental Installs under the main ERP10\10.2.300 folder, not the service pack (10.2.300.8) folder.
I don’t give Epicor Support much credit in general, but under the Option of “Technical Support/Upgrades” I have some gotten decent support and usually a webex can resolve the issue.
One more thing, if using SSO you do need to make a manual changes in the web.config file of wherever the Epicor virtual directory is installed. It is documented well in the Installation Guide.
My case was escalated to another support tech today, and during a webex we partially resovled it.
I originally setup a VM called EpicorTEST02 onto which I installed 10.2.300.x for testing. When I was having issues with the Task Agent, and raised a support case, the first webex with tech wasn’t able to resolve. He suggested creating another Epicor application server, using Epicor user/password rather than SSO. I did this, still no joy. I then went even further and created another brand new VM (EpicorTEST03), new Epicor app server pointing back to the same DB. This was also not working, same error.
Today on the webex, I did the same thing that I had previously tried - uninstalling, reinstalling task agent service. On the 2nd time of doing this, and after having given the domain user that the task agent service was running under admin rights locally on this VM, it then worked. This was on EpicorTEST03.
BUT, going back to EpicorTEST02 and ensuring that the same steps were followed still didn’t resolve the error. At present my case is still open, pending me doing some more testing to try and get it working. It is good that it is working, but never had so much trouble - like you posted @danbedwards, I find SSO is normally just easy!
Well after much messing about on 10.2.300.8 in test environment, when upgrading live environment straight to 10.2.300.10 it just worked - AS IT SHOULD, and as it has always done on SSO. Very easy!
I therefore conclude rightly or wrongly that on 10.2.300.7 and 10.2.300.8 there was a bug, that got fixed.
This was on EpicorTEST03.