Epicor needs to take the Crack Barrel or “New Coke” approach. We know they won’t but it would go a long way.
We aren’t against Linux or containers. Or the general directions of a web based ERP. But their methods are flawed.
I can think of a lot of things they’ve created in the past week. Fear. Anxiety. Dread.
With a little forethought it could have been avoided. Instead of mucking up everyone’s Pilot environment, why not create a new LinuxSandbox environment? Then you could run it side by side with Pilot, see what’s broken…and work TOGETHER on a stable solution.
Instead, they just broke Pilot. Cheaper and easier for them I suppose.
Cheap
The separate Linux environment is how any of us would have done it.
I did get another update from Support:
–
If the output for EDI output is based on a report style, the current suggestion is to change the output location of the report style in question.
What you would need to use /epi/fs/ in the places you are using \XXXXX.file.core.windows .net\
for example /epi/fs/XXXXX/Pilot/Outbound instead of
\XXXXX.file.core.windows .net\XXXXX\Pilot\Outbound
Please let me know your result either way.
–
My questions are
Is this the official solution?
Can I make these changes in my production environment now in preparation or do I need to wait for the update?
Just got around to testing Bartender reports on Pilot. So they really did break SSRS Bartendener Reports! Unbelieveable.
Was there any notice at all about the path issue affecting AZ File Shares for SSRS? How could this pass QA?
They’ve been warning us about paths for months, we do as advised in prep for linux, and then they go and migrate unannounced and break it beyond our control?
Unbelievable.
Would really like to hear @timshuwy 's incident report on this.
Welcome to the club. I posted the code to fix it here:
Mentioned this in another thread…I think they sent an email Friday to ALL Flex 1 customers affected by the Pilot environmental changes. We also had a meeting with them on Friday (before the email) and came to an understanding on a path forward.
Thanks for your reply. I understand the c# path thing that’s on us but Report Style SSRS output paths is on them. was never mentioned in advance. Am I wrong?
Plus more! Like not informing us that our Pilot environments were going to Linux Containers in the maintenance announcement.
And more, I had the filepath working to the file share. Linux containers came along and boom
I do have good news.
The problem created from my case has been marked as solved.
I can get to the MES via the proper link now. Still testing fileshare.
Still not working: (I do have a case open)
File writing error: Access to the path ‘/usr/local/app/\{yourcompany}.file.core.windows.net{yourcompany}\Live\OCS_2.5X1NonpartSticker__2-18-2026_6_32_AM_12.bt’ is denied.
It is working in Production
Yes I got this from support a little bit ago w/r/t the MES issue:
–
A HotFix is available for this issue in Pilot. It will take about 45 minutes to implement. No one will be able to be logged into Pilot while this is being implemented. Please provide a time for a maintenance window, so this HotFix can be placed in Pilot.
–
There is a Hotfix G that was rolled out the the Flex customers and we’re getting tonight that is supposed to fix the MES login issue. Submit a support ticket to have it applied to your system if you’re like us and on cadence customer.
I can get to my MES thanks 
Its using the file share that is no longer working in Pilot. Hoping the best for your team.
Hmm, I had to have Support fix our FileShare to be pointed to FTP since we’re legacy but they should be able to fix your’s to a azure share and get you a way to access it. I know at a previous employer they gave us a powershell script to map a drive to it in Windows.
We got the powershell script but still cannot fully access the Azure File Share like we need to. We can get the to folder and create folders in it but it will not work with some of our programs that want to auto write something in there. Waiting to hear back from EpicCare.
The azure file share script only maps it for the current user. If you have a service running under something else, like localservice for instance, you’ll need to either run the service as a user it’s mapped to, or use something like nirsoft to run the script for that.
I’ll summarize. It was set up. Epicor did something on their back end and made it work for server side items like functions and bpms.
I’ve been using it for weeks in Pilot and Live.
Then they implemented Linux containers and it no longer works in Pilot.
I put a case in and they have not figured out how to fix it yet. Other customers are reporting this problem.
An update to this issue where the MES/Data Collection URL was opening the Office/Homepage instead of MES/Data Collection in Pilot on Linux. We opened a ticket with support and after initial attempt to resolve there was a pending conversion that appeared to be stuck in the “started” state that popped up when logging into Pilot. Per Epicor support, they applied a hotfix and also the conversion now displays as completed and the MES URL is working. I did notice some strange behavior in Chrome, per attached, where the login button in PILOT MES is doubled and the top half of the form is missing. A browser refresh/F5 resolves the issue. I deleted all browser history but the issue comes back after a few launches of Pilot. We are seeing the display issue in PILOT in Chrome only. We are not seeing the issue in Live in Chrome. Also, we are not seeing the issue with Edge browser in Pilot or Production.
Thanks for confirming that the hotfix fixed the issue and reporting back some oddities on the display side.