This is on my test server but still alarming. I can access Epicor fine but when on the server i get this when I open the Admin Console. Anyone seen this before?
got part of my answer from Epicor.
From Support:
navigate to C:\ProgramData\Epicor\AdministrationConsole
delete the xml files for databaseservermanagement and servermanagment
relaunch Epicor Administration Console
I did this and Admin Console opens fine now but I don’t have my DB or App server listed.
Whenever I’m told by tech support to delete files, I really just move them. That way I can restore them if the tech’s suggestion was the wrong path to go.
4 Likes
I got all my DB and App servers back…just had to Register Existing.
1 Like
Do you still have the initial problem? If it’s solved, a recap of what you did would be nice.
1 Like
Steps clarified to to fix issue.
Closed admin Console
Browsed to C:\ProgramData\Epicor\AdministrationConsole
Deleted the following files (Can move to another location for safety)
-
Epicor.Mfg.Adinistration.DatabaseServerManagement.Configuration.xml
and -
Epicor.Mfg.Administration.ServerManagement.Configuration.xml
Once deleted re-launch Epicor Administration Console.
** you will need to re add the following**
Right Click on Database Server Management and click Add Epicor Database Server
then Register Existing Database
Right click on Server Management and Click add Epicor Server
then Right click on Epicor server and Register Application Server
1 Like
What is corrupt is your local settings file for which servers you want to manage from that admin console. Think of it like a most recently used list.
I am more interested in what corrupted the settings file
I have not idea even how to figure out why it got corrupt. I was shocked when I logged on and started getting errors. It is a test server and it is hardly used.
Hmm… That’s going to be the real interesting thing. As you discovered, it’s just a blob of XML holding which servers you like to talk to. We’ve talked about changing that but currently it’s a simple file. If we did something in an install, a config change, etc it would be nice to find where it got broken. Of course anything in the OS that messes with the text file could mess it up (and why we considered moving it to a db instead of loose file).
Do you have a backup of the corrupted file? It might make an interesting diff to find the issue.
Just adding to what @ckrusen said, I never delete any files, I just rename them using the prefix ‘ORIG_’ and if needed I can just delete that prefix and it restores the file(s).
Glad you got it figured out.
no I didn’t back up the corrupt file. If it happens again i will get it for you.
1 Like
I normally do but since it was a test server and in a hurry I just did it. LOL
1 Like
@Bart_Elia, I’ve JUST had a very similar problem in the last hour creating a 10.2.300.3 DEV server. Opened a case with Epicor support and then found this thread. I’ll start by saying THANKS to @Kimberley and everyone here.
So I built the server and ran through ALL the steps to get my database upgraded and I get an error message from the EAC when trying to connect to the appserver
“Table ‘UserFile’ propeory mismatch between sender and receiver.”
Oddly, both the task agent and the client connect without issue.
I have regenerated the Data Model three times, recycled, rebooted, etc. a few times and am at a loss. No other error appears in the event viewer either.
The solution was to rename my “Epicor.Mfg.Administration.ServerManagement.Configuration.xml” to OLD and restart the EAC and re-register my appserver. Fixed it. But I noticed that it brought it back in as net.tcp:\… Granted I have a choice listed for each of the connection types, so fair enough. I removed the net.tcp entry and redeployed successfully as http - and I can still connect in EAC.
Best part - I’ve got both versions of the file for @Bart_Elia t to review if you want to. I’ll submit them on the EpicCare case CS0001224131 rather then here so I don’t have to strip them clean of hostnames and such.
2 Likes
Tyty ty.
The only thing worse than no logs or repro is an intermittent electrical issue in a car
LOL - Truer words have not been spoken.
Attach to existing ticket please 
What Version were you on and which Version are you going to? I’ve had similar issues in 10.2.200 - but not in 10.2.300.
Sorry to post on a very old topic, but I had this identical issue with the task agent service during a clean install of the 10.2.400 release and update 10.2.400.6.
Renaming the configuration files did not resolve it. I had to do a complete uninstall/reinstall making sure to cleanly delete all programdata files.
The reinstall worked. The only difference I know of between the two was this:
On the first pass, after successfully installing the Release 10.2.400.0, on the last dialog window I forgot to Uncheck the “Launch the Epicor Administration Console” . I then installed the update, went through normal steps and received the mismatch error.
Clean install I made sure to uncheck it. Could that have anything to do with it?
Another bump for this ancient thread, possibly with a solution (which I only found thanks to the work of others above)
In my case I have 10.2.200 & 10.2.300 installed on the same test server.
Server previously had 2 application servers registered, both on 10.2.300.16.
Adding a (new) 10.2.200.x application server completed successfully, I can login to it, but the same error regarding UserFile mismatch arose.
In my case inspecting the relevant config files (C:\ProgramData\Epicor\AdministrationConsole\Epicor.Mfg.Administration.ServerManagement.Configuration.xml) showed a line for my new application server and 1 of the properties specified was:
ServerVersionHint=“3.2.300”
That didn’t look right, but would explain the issue perfectly.
Manually setting this to 3.2.200 (after creating a backup), opening the admin console and resetting the password allowed the admin console to connect successfully. I notice that issues here all appear to relate to test/dev servers, I suspect having multiple versions installed is not unusual in this scenario so perhaps this is a more general solution?
Then again this may have been long since tidied up in 10.2.400/500 but maybe someone else ends up here via Google 
1 Like