10.2.700 >> 2022.1

Version 10.X / 202X.Y → 202X.Z

This topic covers tips, tricks and known issues for making the jump between the two above sessions.

Tips:

An SSL certificate that isn’t wildcard, used with a net.tcp appserver in 10.2.700, doesn’t seem to be able to satisfy the requirements for 2022. Somewhere there’s a @Bart_Elia comment that there are a lot of endpoints in Kinetic, so maybe that’s why.

Getting a “SPLIT_STRING” Issue on initial login? Check and update the compatibility level in SQL server on the specific user database and make sure it’s 2017 or higher. On a similar note, the WIndows version / SQL server version matches in the upgrade guide are the ONLY ones that work. Make sure you use one of the options listed.

If you have an on-prem setup using RDS / RemoteApps instead of clients, you need a self-signed certificate from your AppServer installed on each TS. You ALSO still need a public certificate if you have anything connecting from outside, like SalesForce making Epicor API calls. In order to make this work, you need the self-signed certificate binding on port 443 WITH server name and the public cert binding separately, WITHOUT server name. This is all assuming the old-fashioned server.domain.local naming convention.

Don’t use IIS to create self-signed certificates - they don’t work with this setup. Use Admin Console to create the certs when you create the AppServers.

If Solution CABs won’t install properly, especially UD fields but even internal objects, make sure you ran Epicor as administrator to install them.

EMWW / EMW / EKW has changed its licensing system. In 10.2.700 there was just a license code to enter. In 2022.1 you have to open a request in EpicCare to “download a copy of a license I already own” and for some reason, that option sometimes doesn’t appear. I had to log out of EpicCare and back in, and there it was. You then import that license into your appservers in EAC.

The version of EMW that works with 10.2 does not work with 2022.1. To upgrade EMW go to downloads.biscit.com and enter your license key to access the downloads area. They recommend using the Play Store instead, but our devices don’t have the play store and aren’t going to. We transfer the APK to the device via bluetooth and tap to install. There are details in the guide on EpicWeb, make sure you follow them especially redoing the setup of DataWedge if you’re using it. Also make sure you uninstall the old EMW version first.

The version of System.Data.SqlClient that ships with Kinetic doesn’t work - it seems to just be a redirect. I don’t think they expect it to be added as a reference in custom code. We were relying on it for custom BPMs and resolved this with the Microsoft.Data.SQLClient. I got the DLL by creating a CMD-based dotnet project, adding the nuget Microsoft.Data.SQLClient package it, and running it. This compiles everything into its folders and I just borrowed the DLL from there. I know it’s hacky.

Known Issues:

Solution workbench has improved 100% lately, but it still doesn’t seem to collect up the RDLs from BAQ Reports.

4 Likes

Interesting - I enabled the Kinetic part tracker in my build and it’s fine:

BUT now, if I try to use Open With

image

I get mistreated

image

@SteveFossey - Check to see permissions in menu maintenance for the SVGO0013 part tracker link under Executive Analysis. There are 11 out of the box part tracker menu links, and seems like the context menu is going to one you’ve got locked down.

1 Like

I will check, thanks, but why would this spontaneously change?

If you have ever in the past customized the Context Menu it may be referencing an invalid ID. I know going from 10.2.600 to 10.2.700 we had to reset a bunch of Part Context Customizations because Epicor changed Menu IDs… If you have it Customized you are still stuck with the “old” xml in the database.

2 Likes

Latest error found during upgrade of 10.x to 2022.1 - it looks like the IIS setup scripts have a glitch that does not remove the Basic Authentication (only Anonymous should be enabled) at the site/subsite level.

The error is “Attempted to perform an unauthorized operation error” when trying to connect to appserver from Epicor Administration Console"

See EpicCare KB - KB0122549

6 Likes

Oh duh… if you’re like me, ignorant of basic SSL concepts, going from net.tcp to https might get pretty frustrating.

Especially if you’re using RDS deployment and didn’t realize the cert from the appserver needs to be imported on to each TS in the collection.

Also it seems certs generated in the EAC work but others don’t.

I’m not completely clear on one thing, the docs say to use a public trusted cert but when I go to buy one it seems to need a DNS record. My appserver isn’t on the wider network.

My dev server is though, and adding its trusted cert to the TS. farm didn’t help, but adding a. self signed cert generated by the EAC did.

I have a working setup now but unclear if it’s safe, so any wisdom would be appreciated.

1 Like

Steve - look into a wildcard cert. They are a little more $$ up front, but you can list as many servers as you like on the certificate. I have a single wildcard cert with 20+ servers listed on it. As far as DNS goes, do you not have a public registrar for your DNS - like Network Solutions or GoDaddy ? If I recall correctly, they are the DNS it’s looking for, pointed at your public IP address, so it can verify that you actually exists legitimately. I forget the details but it should be just a little bit more research for you to get it done.

The one caveat is that the EAC like the wildcard certs well enough, but it always seems to be some sort of glitch when updating the certs each year. Also, other applications may need some special attention in getting the wildcard cert to work - we’ve not found anything that can’t be overcome.

1 Like

Mike, we couldn’t get a wildcard to work with 2022.1.6 and it’s been documented it doesn’t work…

Last I heard.

What version are you on?

A single SSL cert has always worked, there has never been an issue with it.

EDIT: It doesn’t work sometimes* - see Haso’s KB article link below.

v2021 in Production - but I’ve got a v2022.1 installation in my sandbox… let me check this issue and get back to you.

Let me add this… it doesn’t work, “sometimes.”

Epicor was supposed to get back to me about the issue because they had dev on it, but I haven’t heard anything.

So yeah - just made it all work. 2022.1.4, with a wildcard cert issued by DigiCert.
The images shows a secure browser connection, and the IIS and EAC windows show that I’m using the *.ashworth.com cert…

1 Like

There is a good KB Article on Certs:
https://epiccare.epicor.com/epiccare?id=epiccare_kb_article&sys_id=20652843db4d3f0826d3a9a5ca961942&table=kb_knowledge

I think Epicor had a bug in earlier 2022 with certain certs. I think it’s fixed in the latest .7

I know there is still an open SSO Wildcard SSL Bug however.

2 Likes

Yes, that was the issue for us. Our wildcard cert was not the FQDN.

Also, when it says the FQDN of the server hosting Epicor ERP, it is talking about the VM, right?

Not the appserver name in the admin console, right?

I’ve made this work with 2022.1.4 so maybe I’m before the error was introduced.

Yes, the name(s) in the wildcard cert must be the windows server names (the VM or physical server - NOT the Hypervisor host) and not the Appserver name. My VM Windows Server name is ‘epciorsandbox’ and that is what is listed in the wildcard cert.

and the domain you have your server on is ashworth.com?

yes

Thanks a lot for the help Mike.

Ours won’t work because we have a less than ideal domain setup where GoDaddy won’t issue an SSL because of the naming.

That doesn’t sound legit. Public is different than internal and when traffic comes through the firewall the outside rules do not apply. Now, if you’re in the cloud or have something really funky going on, then maybe it’s a problem. Happy to give you my two cents if you want it - here or DM/Offline.

Probably offline at some point Mike. I don’t have much expertise in this area so I would want to loop in my colleague.