I think it’s the certificate authority that we are going through is all.
If digicert will issue an SSL for any domain then I think we won’t have an issue.
I’m still a bit confused about non-public servers. We have a big server with dozens of specific VMs on it. Some have specific thing.domain.com subdomains with certificates, for REST use over the WAN; but the TS farm is not exposed to the public internet, doesn’t have a domain or subdomain pointed at it, and isn’t accessed except over the LAN. So five servers involved (APP, SQL, TS1, TS2, TS3) and only APP will ever be accessed over the WAN.
I generated a self cert on APP and imported it into TS1, TS2 and TS3, which works; are you (@MikeGross ) saying that a wildcard cert would still be the right thing to use instead, even though I’ll never have TS1, TS2 or TS3 exposed to the WAN?
Or is it safe to use self cert because it ISN’T on the WAN?
Many thanks for the time you’ve already spent here!
Steve, this is the thing that I wish we could go to Epicor with and get help from support.
I think that they should be able to provide this level of support and give recommendations on it.
However, I find that they don’t and they say it’s your responsibility to understand and implement.
3 Likes
Well, yes. We use a wildcard cert from DigiCert for all internal servers as well. It’s just easier that way because it expires across the board so maintenance is easy - in that you cannot forget it - and some applications just do not like self-signed certs.
For you, with zero public access, you could get a wildcard cert OR you could set up your own cert authority internally. It would issue legit certs (issued by a proper authority) and all your apps would like it (if they didn’t like a self signed cert). Plus you’d get the ‘trusted’ indicator in your browsers.
It’s not that hard, but it’s still something you’d need to maintain, whereas we felt a legit public cert is easier in the end.
I will say that I think an on-prem Exchange server simply will not use a wildcard cert - you’ll need a dedicated unified communications cert for that.
4 Likes
Just remember that this is some high-level generic information - your situations might have things that may make this more difficult!
1 Like
That’s what we are saying too, a legit public cert is the way to go, they just won’t do it for us given our domain naming convention.
Like Mike says, a wildcard cert is more convenient to setup. They are a little less secure in that if an attacker creates a VM on the network, it will be automatically be trusted by other machines in the network as well.
However, DigiCert, along with other providers, have a solution called Managed PKI. It’s easier than running your own CA and more secure than having a wildcard.
3 Likes
Thanks for the input Mark!
Anyone know where to look for this?
There are no registered task agents. At one time, there was one, and it was working. There were never 3, this is a brand-new server and only has 2022.1 on it.
Any thoughts anyone?
ok, well TA help has:
And that table has:
with 3 server names that have a lower version of epicor because this is an upgrade-in-place
So I guess delete?
helluva yucky feeling but it worked…
2 Likes
Look here in the system monitor:
Select the agents that aren’t related to the Kinetic installation and then go to Actions->Remove Service Registration
I don’t see a place to do this in the Kinetic side, but you can in the classic…
5 Likes
That’s what I did with a UBAQ… It was a test system and all…
3 Likes
Nice Mark.
I had to do this, from Knowledge Page KB0121813 - EpicCare (epicor.com):
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Right-click Parameters, click New, and then click DWORD (32-bit) Value.
Type DisableStrictNameChecking and press ENTER.
Double-click the DisableStrictNameChecking registry value and type 1 in the Value data box, click OK
In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK. One per line.
Quit Registry Editor, and then restart the IISAdmin service.
1 Like
oh, cool Troy. I don’t search for KBs often enough
they’ve gotten much better than they used to be. i think they’ve started putting all their cases into the knowledge base now.
1 Like
Welp, go-live this weekend. I updated the wiki post up top with some things I learned, but others much smarter could probably add to it as well.
For THIS Friday afternoon rant, I’d like to look at ways to make this upgrade process segmented.
I started with (obviously) the upgrade procedure and the install procedure. They are pretty good, although they contain a few ambiguities and steps that turn out to be in the wrong order.
The process itself isn’t that complicated. You take a DB backup, spin that up into a dev 10.2 environment, do some prerequisites, restore it to a 2022.1 environment, allow some conversions to run, test and resolve issues (this part is a couple of months), rinse and repeat until no more issues.
Then you do this again but you start with locking everyone out, take a trial balance, do all the stuff, take another trial balance and make sure they’re identical, take an upgrade backup, do tests to make sure all is well, and if it is you restore the upgrade backup and let everyone back in. More or less.
I did 6 builds over the past 3 months and in the end, the cutover build this weekend is going to take me about 20 hours. This seems excessive for a process that has a lot of steps but isn’t actually that complex once you know all your mods work in the new version.
How might this be segmented? In this case we’re changing servers too, but even if we weren’t Epicor doesn’t advise having multiple versions running on the same machine. One of my dev boxes is quite happy but I’m hesitant to try it on 2022.X because several of my main issues came from the .NET framework changes needed by 2022.1. So I don’t think pre-installing vNext is a good idea.
Any other ideas? In an ideal world there would be lesser changes we could push to PROD during business hours.
Hope things went well for you this weekend. Good luck this morning.
We’re up this weekend.
4 Likes
thanks Mark! Yes, everything is good. There are a. couple of strange issues where some MES domain users can’t open Epicor, but so far we think it’s an LDAP problem.
We’ve found a few things where 2022.1.better enforces security, for example we now have to have certs on our terminal servers even though they aren’t pointed to by DNS records or open to the net. So we think it’s something similar
1 Like