I’m running into issues with our Pilot server and reports.
We run ERP Live on its own server - app server, database, and report server all on one virtual machine. Works fine. When it came time to create a pilot, the vm makes it simple to just clone it, change the IP, change a few settings inside Epicor and tada! Pilot is up.
There was a problem with reports not working on pilot and the error was along the lines of “object TableName_GUID does not exist”. I couldn’t find that table in our live or pilot databases - odd. So, I wanted to see if just redeploying the reports to a new database would fix things up.
It didn’t. In short, the new database on the pilot server was created, but now LIVE was erroring out on reports - error message said that the new Pilot report database could not be found or connected to…
How is this possible? Two completely separated servers - but modifying one is affecting another.
Redeploying Live did not actually fix Live. In the end, I ended up changing the Live Root Folder to something non-blank and deploying, then changing it back and deploying.
This leaves me leery of making any changes to pilot. My best guess is that I should not have cloned.
Interesting note - my SSRS Reports Root Folder is blank for both Live and Pilot. And that seemed to be the only way I could get Live going again - redeploying Live with a non-blank root folder, then redeploying again to get it back to blank.
Not sure there is a standard way but I have used SQL for a long time to clean orphans from this table without any issues.I would restart your environments after this to just make sure they are clean.
Solving the problem:
From a 2017 post from @aidacra, you can DELETE FROM Ice.ExtServiceRegistration. If you want to avoid SQL, you can use the BL Tester to access Ice.Contracts.BO.ExtServiceRegistration.dll and execute DeleteByID(ServiceID, ServerName) for the test task agent you want to remove. Afterward, restart your production task agent and the app server to which it’s pointed which should clear up any issues.
Preventing the problem:
Preventative actions would include disabling the specific task agents via the task agent service configuration / admin console as shown below (I don’t mean the service) prior to cloning the VM. It seems you need to have the service running in order to remove the agent which would register the task agent at its destination from its origin on the cloned VM.
Another point to consider:
I run scripts against test databases after overwriting them with a copy of production to prepare them for use and disconnect any external links to production. You should also consider clearing Ice.ExtServiceRegistration in your test environment during this process.
