And this might explain why something was working in Pilot on 1/29 and does not work this afternoon. Don’t think it’s filepaths and labels as we’re on Azure already.
I noticed a weird message on an interactive error this afternoon…possibly a system.io thing? Method listed in an error message was “ThrowExceptionForIoErrno”. I remember hearing something about eventual deprecation but don’t think I saw a deadline.
EDIT - confirmed in CMP - we got moved to Linux.
Check our CMP, we were surprised too that something WAS working but not isn’t.
Yep - they flipped us to Linux in Pilot. Terrific.
I remember having hope… good times.
All my non-prod environments are Linux now. Testing to commence next week. Good thing I don’t have a major implementation kicking off next week OH WAIT
I hear ya! We got a CRM and implementing Epicor in our new plants projects going on right now.
Yeah we’re headed to 2025.2 in two weeks…and right now we can’t test some of the most critical pieces of our operation. They worked on 1/29 and now they don’t. Tremendous.
Ah shoot. Checking CMP our Pilot and Third environments are Linux now. Testing our custom label program based on data directives outputting to an Azure File Share errors out.
Add it to the list of issues we’re facing.
Here’s my error, if anyone else has anything similar:
Program Ice.Services.Lib.RunTask when executing task 3542996 raised an unexpected exception with the following message: RunTask:
System.ArgumentException: The value cannot be an empty string. (Parameter ‘path’)
Thanks for starting this thread.
Without seeing the code there isn’t much to go on here, all we can tell is that it is passing an empty path when it is expecting it not to be empty.
Probably, you will need to add some logging using Application.Logging since this is in a data directive, so that you can get an eyeball on the state of your variables at various points during the execution.
Once you determine where your path variable is coming up blank, then we can fix that bit.
Never start troubleshooting on a Friday night lol. Taking a look today, looks like it is a problem with our Azure File Share output location. Removing the Azure File Share allows the report to complete without error (however, there is no output location so no drop file and no label).
Going to add this to my EpicCare ticket. I’m assuming the Linux container can’t resolve the Azure File Path. Removing the output path that was saved allows the report to complete, but I now get an ‘Invalid Output Location’ error when trying to put it back and save. It is in the following format: “\\TENANTID.stuff.stuff.windows.net\blahblahblah”
You might try using the linux compatible syntax for that UNC, which is just the other type of slashes, it might work if they automagically ported your azure file share mapping from windows to linux.
Thanks, but no dice. Still errors out. I’ve updated the EpicCare case, will report back here if I hear anything.
I agree and I despise the maintenance announcements. The complete lack of information in them is alarming. In one of the emails they mentioned early February and I actually reached out to support to better understand the downtime a few weeks ago which is how I knew.
Three more maintenance announcements in the last five hours.
Pilot/additional hotfix (maybe it’ll fix what they broke for us last week) - Tuesday 2/9
Production hotfix - Saturday 2/14
Production NGINX scheduled maintenance - Saturday 2/14
Happy Monday.
Instead of being helpful the maintenance notices are more just a heads up you’re going to have a bad day. Can bet on a headache following them.
What’s worst for me is my users asking reasonable questions that I can’t answer unless I submit a support ticket asking for the answers.
Like the following:
Welcome to Hell
Population-us…
docker does has volumes that are persistent. You can access the file system, assuming epicor has set the privileges as such, just remember on linux the slash is the wrong way around!
Or it’s the correct way around. 
Who says Windows is the correct way 