Anything to consider when setting up a second App Pool for the same DB in EAC?
We currently have just the one App pool for our Production DB, and it uses “Windows” for the Net TCP Binding. This automatically selects the E10 user to login as by finding the E10 user account whose OS username matches the username currently logged in to the workstation.
I want to add another App pool (pointing to the same DB) using “UsernameWindowsChannel”, so that I (or others) could login to different E10 User acct.
Should I use the same settings (as the original App pool) for things like the SSRS?
Any special requirements when updating the App pools (say from 10.x.y.13 to 10.x.y.25)?
Should I separate the client installations on the work stations?
Like:
Windows Net TCP: c:\epicor\ERP10.1Client_WIN
and
UserWinChan Net TCP: c:\epicor\ERP10.1Client_UWC
We do this all the time - All the SaaS systems do this for example. I run this all the time on my ‘dev’ laptop as well so as to not mess up playing with REST versus Windows Auth or the like so well supported.
The intent in real production is to separate a few things.
The first is the WCF limitation of no duplicate channels of same type. You cannot do two flavors of net.tcp or https, etc on same app pool.
The second is to isolate db access. You can have one app pool / web.config with limited SQL rights and another with more advanced rights for admin level needs so a different db connection. Since ERP is a vanilla IIS app, all the tricks for limited access to an IIS instance can be used.
Third is workloads. You can isolate activity types (interactive vs tasks). The real value is moving these to different servers but having them isolated at the beginning and then playing with DNS to point to a different server as the load increases is a nice trick.
As to the client handling? They are different servers logically so each gets a separate client install. You can play with swapping urls but most folks do not have to worry about hd space these days.
Mileage may vary and your needs do not reflect the needs of someone else.
My concern was with the client caches and other client files from different Apps interfering. Better safe, than sorry (until the maintenance of unnecessary duplicates comes in to play).
That’s the struggle with the current client installed code - duplication (even if the same). Having a more granular instance is probably not going to be attempted.