Cannot install Service Connect on new Windows 2019 VM

I have an open case but… :slightly_smiling_face:

We are in the middle of an on-prem upgrade. I am installing Service Connect 11.2.100

  • Windows 2019 server
  • Server and client on the same machine
  • Database on SQL server 2019 running on Windows 2019, separate machine
  • All preparations from the install guide done as far as I can tell
  • Service usernames are domain users AND local admins, all currently working with Epicor and Service Connect current.


  • Install runs without error
  • Database created without error
  • Running service connect admin results in a long, long “Attempting to connect” message, finally an error
    • “Could not connect to license service” OR
    • “Admin Console was installed incorrectly”
  • Services do not start; logon service shows “Starting” indefinitely
  • IIS app pool running
  • Cannot access web-based tools

Attempts to resolve

I have removed and re-installed many times to try to rectify this:

  • removing server only;
  • removing client first and then server;
  • removing and re-installing client only;
  • using leaving service usernames both blank vs. populated;
  • attempting to manually start services
  • manually changing service logons
  • changing service startup from “Manual” to “Automatic”

Things I wonder about

A couple of possible ambiguities exist and I’ll update this list as I find more. Some are likely my own ignorance.

  • install guide says .NET 4.8 required, but installing Kinetic required version 6.x and you can’t downgrade;
  • “required software” section in the guide lists quite a few items that it then says are optional. Are they?
  • I have server/client on the same machine; do I still need to do anything to the firewall? Access to DB is working fine, and Kinetic itself, with DB on a different machine, is fine.
  • chrome version required is 30; current is 105. Does that matter?
  • “Add https binding” is mentioned in the context of SCIntegration service (WCF Version) but I don’t know what that is

Hi Steve,

Logon service shows “Starting” indefinitely – this usually means the Windows account used by Logon service does not have access to the SQL database created for ESC.
This would be visible in Windows Event Log - Application log, as errors from ScaLogonSrv; details contain the exact error and its stack.
You should definitely run ESC services under a Windows account (do not leave the user/password fields blank for Service Account in ESC installer); ESC services always access the database using that windows account, not an SQL user like sa; make sure that this account has full rights to ESCDB.
If ESC and MSSQL are on the same machine, you could use a local Windows account; if they are on separate machines (as it is in your case), you need a domain account.
Note: different installations of ESC have to use different databases; if you cloned the database of another installation and installed a new instance of ESC using the clone, most probably there will be some stuff to cleanup, as that cloned database will have leftover references to original machine name of the old installation.

ESC uses .NET Framework 4.8; Kinetic uses .NET 6, which is a different (modern) flavor of .NET that evolved from .NET Core. They can be installed and work side-by-side.
.NET Framework 4.8 is currently a feature of Windows that you may install/remove, and it is usually installed by default (and there are additional pieces like ASP.NET, for IIS integration, which are also installable as a windows feature).

Optional features listed in SC’s required software section (like SonicMQ, Rabbit MQ, IBM MQ, WSE 2/3) are necessary if you use corresponding input/output channel kinds (Sonic, Rabbit, IBMMQ) or are calling legacy Web Service references (WSE 2 / WSE 3).

Chrome is needed for Task Monitor; the version listed is the one that was tested a while ago, however, I do not remember issues on current Chrome, so, unless you observe issues in Task Monitor – use the current Chrome, and if you do – report them to support.

SC WCF Integration service is used when you invoke SC workflows from BPM or UBAQ in Kinetic, calls to it run through https, therefore the IIS on ESC server should have an https binding set up for the web site hosting this service (the Default Web Site, unless you selected to create a separate web site for ESC).


Thank you, that was amazing :slightly_smiling_face:

Having you here publishing a detailed answer really is what sets Epicor apart these days, very much appreciated.

I am redoing the install; in the meantime:

OK, that makes sense - I’m adding my domain epicorservice account as db_owner

Got it, done. Should I also have used the “NT log in” checkbox and a domain account on the dialog that sets up the DB in the first place? I used SA and it did create the DB, but it would be a good test of the service account’s access if it’s needed later.

OK, please excuse my ignorance - does that mean 4.8 is installed using “Roles & Features” and not with a downloadable installer?

  • In “Roles & Features” I see 4.7 but not 4.8;
  • Running the ndp48-web.exe or its offline version both bring up an error that basically says “you can’t downgrade”. Is there a different installer I should be using?

Got it, thanks.

And, sure enough - many, many thanks, it works. So my other questions are of interest but it works.


Either choice is good, as there, you are only specifying which credentials the installer should use for creating/updating the DB.
Note: there’s a known issue that DB converter (if you ever upgrade to a new release using the existing DB in-place) always runs with trusted connection, therefore the user running the installer should have rights on ESC DB for the duration of the DB converter run, independently of NT log on checkbox state (as that checkbox is so far only for the installer itself).

Oh, my.
Yes, I meant Roles & Features, and I wrongly thought Windows Server 2019 had .NET FW 4.8 as a feature, not .NET 4.7. I would guess that if you are getting the message about inability to downgrade, something already installed .NET 4.8 for you, and it got patched through Windows Update, so, you already have the .NET FW 4.8 installed, and it is newer build than that in ndp48.

To verify, in command Prompt, run this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /?
and see whether it tells that it’s own version 4.8.something or 4.7.something.
If it says it is 4.8.* – then you already have .NET FW 4.8 installed (.NET FW 4.* series are single-instance per machine, they cannot exist side-by-side).

1 Like

Everything works so far - thanks a million @AMS

Running into trouble again, this time on my production server (before I was building a test version).

The error from the event viewer is “Can’t connect to database server. SQL Server Network Interfaces: The target principal name is incorrect.”

Any ideas? I’m sort of at that brittle / slightly weepy point… :smirk:

I never saw such error, so, going wide:

  • Is the production server where you are installing Service Connect a clone of some other machine?
  • Is MSSQL installed on the same machine as Service Connect or on a different machine?
  • Is the machine where MSSQL is installed a clone (or did it get renamed)?
  • Is MSSQL log mentioning anything about inability to register an SPN?
  • Is MSSQL running under a domain account?
  • Is domain relationship on both machines (assuming SC and MSSQL are on different machines) all right?
  • Can you connect to MSSQL in question from any different machine?

Thanks for those threads to tug on:

  • Prod server not a clone as far as I know; all 4 servers (2 dev, 2 prod) were new W2019 VMs at the same time

  • MSSQL is on a different machine. We have Kinetic and SC on “Kinapp” and MSSQL on “KINSQL”. The only difference from Dev to Prod is in the naming, so DEV-KINAPP and DEV-KINSQL vs. RD-KINAPP and RD-KINSQL

  • AFAIK no clones or renames, but I will check with IT

  • No SPN-related entries in logs that I know to look at

  • MSSQL on prod sql machine is running under domain\epicorservice account. On dev sql machine (where everything works), it’s running under local service account. I will try changing this before re-installing SC

  • As far as I can tell domain setup is fine. All machines on same domain, I’m logging in as same domain user on all, domain\epicorservice is in admin group on all

  • I can connect to MSSQL using SSMS from all machines, including the prod server that’s giving trouble


So apparently, it should NOT run under a domain account?

I changed this to a local service account, and now it seems to work.

Thanks you!

When I asked about that, I remembered hearing somewhere that in order for MSSQL to be able to register and SPN (Service Principal Name) when running under a domain account, that account may need additional permissions in Active Directory.

Here’s a pretty good MS topic laying out the details: