Helllo!
We are migrating to SSO and getting this error frequently (but sometimes not) when attempting to login. We have validated folder permissions and both a custom and non custom alternate client cache location. Anyone have any ideas? Thanks!
We are also using a different domain login from the epicor user ID:
We use “Windows” as the endpoint method for the App Configuration. This makes the login automatic (like SSO). Just have make sure the Domain and Domain User ID match what the user logs into his client computer as.
Hi Calvin,
Thanks for your response. I wish that was the issue, alas we are using client based SSO, offloading https requests to a load balancer / “App Gateway” in an Azure environment. HTTPS is best for SSO in an Azure environment.
SSO works, but we 80% of the time get this message and cannot log in. We also have multiple RDS hosts but all permissions look good on each.
Make sure the user is logged into the domain and not the computer. We see this most often with folks with laptops.
And since it’s balking at the “user cache”, can you confirm there is the cache folders and files on the machine they are logging in on?
Thanks Calvin. I’m even getting the error. The client is being served up via an RDS remote app. I have confirmed that the client caches have “Everyone permissions” and epicor is creating the files on login. Our users must login to the remote app with their domain login. SSO works, the client cache is created, but we are still getting this error.
So with SSO disabled, RDS serves up the login window, and everything is honky doory?
I never fully understood it, but there are some SSO fields in the .sysconfig file. Have any of them been set? (I couldn’t tell you if they should be cleared or have values)
I’m trying to upload my 1 MB gif to show what is happening but the site is telling me its too big.
Even our third party vendor that set this all up does not know what is causing this epicor error. What seemed to work is making my domain login id MATCH the Epicor user id as a test. This could be a problem, as we would have to change all existing epicor user IDs that are linked to transactions and the like. But if that was truly the fix, then I don’t think I would be able to login at all successfully with my domain login id different than the epicor user id.
Be careful with your theory about using your domain id as the epicor id being a solution. Many temprorary files are created using the userId as a suffix to the file name (to keep them straight between users…
So having a userid without the number and dot prefix, isn’t really trying to make the same files.
And as a whim… Maybe it doesn’t like the . in the user id.
FWIW - we always make the userid the same as their domain id.
I believe this issue was due to
RDS server redirection
I moved our alternate cache to a central file server rather than having it on 4 individual term servers.
So far so good. And cleaner too, incase we need to wipe it out!
keep ya posted to see if this is now fully resolved
Update 11/14/19
this resolved the issue. Centralizing the client cache on a file server instead of having a separate user cache on each rds farm member with RDS redirection.
Update 2:
It was still broken but is now resolved. Essentially Modern home page w SSO was trying to log in quicker than our Azure user cache could mount on user windows login. For now, I added a brief 3 sec pause command in a batch file before Epicor logs in. Something funky with our RDS Azure setup, which Microsoft will need to be involved.
