Is there something different between the Enterprise Search URL in Company Maintenance between Epicor 10 and Epicor 2024.1? We can’t seem to get it to work in 2024.1. The Enterprise Search path in the Admin Console matches what we have, but if I click Launch Search from there, it displays a URL that isn’t the same, which fails (unsurprisingly). If I edit the URL to match, I get this message:
I can’t remember where I saw it (EpicWeb or EpicCare, maybe), but something put out by Epicor that they have temporarily deactivated Enterprise search. We are also on 2024.1 and have been unable to use it. Was a little unclear if that was for just cloud or also on-prem.
Thanks for the response. That made me search for ‘epicor deactivated enterprise search?’ and I found a link to another post on this forum, which had not come up with I searched the forum itself. What is happening with Enterprise Search? Disabled Globally
That does seem to explain it. I have let our team know.
Another wrinkle we found, apparently the search sort of works when on our VPN, but it doesn’t do partial matches anymore. It used to be we could type in the first 4 characters of a customer name and get results, now we can only get results that match a name completely. (not what I tried, but Good would bring up Goodyear, but now you have to type Goodyear to get it to work, for example)
Off VPN, we get nothing at all, no matter what. They hadn’t told me that was the issue, and I had tried it both on and off the VPN. I did have to switch companies to make it work at all, but then it worked IF I was on our VPN AND I spelled out a match completely. (and when I typed in a name that matched a Salesrep last name, that came up, but when that name was part of a customer name, it didn’t work).
Enterprise search was disabled for cloud only customers. If you are on prem it could be something else
We are indeed on prem
Hello all, I’m going to take a shotgun approach in this answer. I don’t check in every day but I will plan on looking back here Monday if there are follow-ups.
First Enterprise search and cloud:
This was actually a Windows 2019 bug at its root. The container for ES and all our containers at the time are based on windows 2019 and switching off to a new OS based on all the testing and reconfiguration requires to ensure stability was a non starter. by the time a way to work around it was found the number of issues reported and concern in the customer base was such that the decision was made the decision to disable is for that release.
What it means for 2025.1
That individual problem has since been resolved, but it pointed out that for our cloud team ES was a fairly expensive app to maintain not form a hardware resource side but from a personnel side. Evaluating that we made the decision for 2025.1 to bring ES into the app server itself. starting in 2025.1 it is no longer a separately installed application but it is delivered as part of the application server and all maintenance is done using the browser UI. On prem customers in controlled release will likely have noticed ES is no longer part of the admin console and is no longer an extension to install. Also we have moved the scheduling of ES index rebuilds into the task agent by creating a process you can submit using task agent schedules. This takes control over when indexes are rebuilt or incrementally updated out of the hands of cloud operations and places it in the hands of our cloud customers. It also mean there is no longer a need for an enterprise search container for cloud operations to mange or deal with. As a result I fully expect enterprise search to return as a standard cloud feature with 2025.1 the difference now is the cloud team will not automatically set it up for you. Each of you as a cloud customer will make the decision whether or not to turn on enterprise search, to create your index and to set up your indexing schedule with the process - the cloud operations team will no longer have to maintain that. So it will not automatically ‘be on’ for 2025.1 but you can turn it on yourself creating your index off the standard template and scheduling the reindex times.
Next: is there a URL difference between Epicor 10 and kinetic 2025.1 for what you set in company maintenance?
No there is no difference the same value will work for both.
Now… you mention that it only works when on the VPN. keep in mind that the URL in question is a Fully qualified domain name (FQDN) if that server is not exposed to the internet via your corporate DMZ then they can only have access to that URL while on the VPN because it will not evaluate on the internet domain name servers. by the same token if you do expose the server enterprise search is on in your DMZ are you exposing it as the same FQDN or as a public facing one that is different to take advantage of your corporate cert for https encryption?
Most likely you are facing a configuration/setup issue regarding the url used to reach the ES server and who can evaluate that url and establish an https protocol connection with it. Support can help a bit but this is mostly an IT area and not their specialty.
It used to be I could share for Good and find Goodyear but now that does not work
So there is likely no change in this area at least not a significant one. ES breaks down data into words. Goodyear is a single word in its mind because it doesn’t’ understands that is a combined phrase. I have not looked in a while but I think it would interpret GoodYear as two separate words Good and Year because of the cases. I’m not 100% sure on that. But either way it takes text breaks it into words the same logic when building the index is used when parsing the search phrase you provide.
ES is exact match at eth word level (not case level) by default. so if you enter the search term good it will find Good or good or GOOD or variation of them but it will not find Goodyear . not it might find GoodYear if it treats it as two sperate words but I do not know that for sure). YOu can use some wildcards in your searches it is in the help somewhere but some examples:
just for fun my favorite is - -Good says find rows that have my other criteria but DO NOT have the word good in it. can be handy in rare occasions.
Wrap up
I think i covered the thread pretty well but let me know. Special thanks to certain fellow employees of Epicor who randomly send me team chats with epiuser links when I miss things like this 
Doesn’t seem like cloud customers are enabled to maintain this actually, maybe I am misunderstanding what you wrote?
This part is on cloud admin. You can only go to Index Maintenance, and Index rebuild
I copied the message @pferrington sent above (thank you!) and sent it to the IT director, his response is ‘We need the URL for Enterprise Search to be the public FQDN. We know that’s the issue because if we punch through the internal server name and make it available via public dns, it works. So would stand to reason that configuring it the same with the correct public FQDN should work, but Epicor still tries to resolve the internal name.’
I don’t really know what that means, I work within Epicor, not with the setup. Is there something I can tell him?
What Patrick wrote is for 2025.1 only, it is not applicable for your version
So what is the process to have it turned on then, if we can’t do it ourselves? Support case?
Yes, probably. Same as usual in such cases I guess.
