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.

Known Issues:

It’s like the Quebec government works here:

image

@josecgomez if y’all add the 2022-1 tag, I’ll update…

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.

1 Like

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.

1 Like

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.