We’re currently running Windows authentication.
I’ve been asked to set up a second app server that would allow a username and password to log in with.
Does anyone have any documentation on setting up this second app server so that the database, assemblies, BPMs, etc., are pointing to the LiveSSO files to keep them in sync?
We did this at my old job and it was one of the worst decisions we made. I would recommend NOT doing this.
That said, I think there are other ways to do the same thing without having to set up a second server. Hopefully people can suggest some alternatives.
John–what were some of the issues that came up for you?
No matter how hard I tried to keep things in sync, they would never stay. I was the only one administering the system and always made sure to log in both ways to apply changes and also to save dlls in both environments. It just did not work.
The thing that annoyed me the most was BPMs. I would apply them in both environments and they would only ever stick in one consistently.
in 10.1 BPMs are stored at the DB level and no longer need to be “synced” between environments.
you can used a shared DLL path to share custom DLL’s as needed
Agree with Jose. Web farm support was a major effort in 10.1. I’d actually be curious about what is lacking from in the wild. I made our SaaS folks happy ( that’s a task 
) so I’d be curious what we missed.
As to the docs… I’ll have to review our System Management section and the install / architecture guides. I spent some time with docs on this but don’t remember what the resulting docs looked like.
One thing I would suggest reviewing is IF you need two app servers for mixed auth. Windows can run on net.tcp and username over https on the same endpoint. This is even in the admin console in 600
What version are you on?
We were on 10.0 at my old job. So, it sounds like my experience is not applicable in 10.1.
I would listen to the experts and give it a go.
Bart,
I’m currently on 10.1.500.16.
I’ll check out the install and architecture guides.
Thanks.
John, your pain was heard. Many hours went into improving. I still have a few pet improvement I am pushing to finish the effort but I have a lot of those across the product so try to listen to your pains, not my preferences. Please give it a look again as needed. I’ll be curious about current level of pain.
Appreciated!!
How would this be done on 10.1.500? Do you just change the client config to https username while the server endpoint remains Windows on net.tcp?
Correct.
That’s the missing usability piece for working against a single app server. Client Sysconfig has a single binding. An App Server supports one of each binding (net.tcp, http, https). There is no UI to manage selecting the different bindings (or app servers).
I personally have a collection of syconfigs and shortcuts with a variety of syconfigs noted on the shortcut. You would have to manage that somehow for your users. Pushing out thru group policy or similar tooling on the complex side, emailing a link to all to drop in their client folder on the simple side. Probably a few hundred options in between.
BTW - what’s the need for the various sign ons?
My question is from other chats I have had on the topic. For example, a customer wants to run Windows internally. They then want to reach out to their Sales in the field, a partner, etc that needs the external access. They will not be on the home active directory network. That’s where they need to expose the username over ssl as an example.
In those scenarios, many IT shops want to isolate the app server into the DMZ and lock down things different than internally with vanilla Windows security.
I was curious your scenario as I try to understand scenarios and struggles people have.
Upon trying that I immediately get this when I enter a username and password:
If I click retry it turns into this:
That looks like a certificate error?
Right will your Certs have to be valid and trusted. Even if internal they need to be installed in the clients. If your server has port 80 / 443 mapped to outside you can use Let’s Encrypt to get a valid cert for free.
The scenario we need it for is the shipping supervisor wants some key workstations placed around the warehouse that will be shared.
Despite them being shared, he insists on each user logging out of Epicor when they are done so that someone else can log in under their own username.
I have pushed the idea of a general “Warehouse” user, but they wanted to retain tracking abilities which would be lost with an anonymous user.
Ok, I see the need. Not external but more like wanting a lighter weight version to separate authentication (This box) from the authorization (various folks on the floor).
We have had those chats internally on that separation. We support that already in advanced integration scenarios and use that in Tasks for example. (On Behalf Of impersonation).
Thanks for the data point!!!
Don’t forget to use the same URL in the appserver address as specified in certificate.
From the certificate validation point of view https://servername.domain.com is not the same address as https://servername/
Jose,
I’ve never dealt with SSL certificates before.
Can you walk me through creating one or point me to a good resource?
I created a self-signed certificate on the server and installed it on my client, but I still receive that message.
For a decent walk thru on the server side I still go back to Scott Gu’s post when self signed came out in IIS:
My current preferred article on trusting it on the client is:
If anyone has better, I’d love to see them!
Looks like I needed to use https://isiepicor.ispdc.int/LIVE instead of https://isiepicor/LIVE.
It tries to connect, but now I get a mismatched bindings message.
