Hi - Epicor upgraded part of their system with an AKS Infrastructure Improvement this last weekend and now some of the folders that we send data to in the Cloud are intermittently not accessible. So we have production being able to print zebra carton labels part of the time, can do automated emailing of documents part of the time, etc. etc. Wondered if anyone else had an experience like this after the weekend? Epicor is not being very helpful with a solution.
Thanks,
Jill
We will have our system done this weekend. Iāll post back.
All I know is that your EpicorData was moved to a different storage medium.
(Azure File Share)
They may have some bugs to work out.
If you are putting in a support ticket for this, select cloud services in the options.
Now that youāre in the cloud, you need to learn to be afraid of local storage like me!
ā I will be eternally grateful to @Banderson for sending this meme my way.
Hello, for AKS changes your path would change to C:\epi\fs\yourfolder
This would be specific to if you were using an azure file share for something like bartender. yourfolder would be what you named a top level folder in the āoldā azure file share
As for EpicorData Iām not sure where that was moved to havenāt looked yet
This can be verified by looking in System Agent in the Client Directory field, it will start with C:\epi\fs for AKS
Itās dealing with the writing internally that we are having issues with, so we are not even externally writing to it. Our FTP to the directory for our labeling software works fine. Its when we have customization/bpm/etcā¦ It doesnāt have issue creating the file, just randomly tells us that file path doesnāt exist. If they try again it 99% of the time works on the 2nd attempt. Issue is that when it does that it gives us an exception error and needs to kill, Epicor and go back in better then half the time. Seems like it happens more frequently if there are more users. Night shift has less of an issue and morning shift has issues when the office personal start arriving.
Specifally on our labels with this code(Yes the file path does exist, as it works on 2nd attempt as noted.):
System.IO.File.WriteAllText(OutputName, contents.ToString());
So is there an alternative to this if that method call is causing issues for being on the cloud? Not even sure itās related to that call since it seems like we have issues when we have multiple people logged in.
===============
The network path was not found. : ā\XXXXXXX\XXXXXX\LiveEDI\LabelDrop\MWoffline_FRM2153230_32024.txtā
The issue is most likely timing. AFS is a lot slower than local storage.
You may have to build in some delay or retry logic until it improves. (if it does)
If you have hard coded paths to EpicorData, youāll need to fix them and use the helper methods.
I was thinking that too. Did test a simple try/catch with that specific code and in testing caught the error then had small delay before attempting it again and went through fine.
In production it didnāt seem to help. Did an 8 second delay, maybe I need to try a more aggressive delay then.
8 seconds is a long time. Iād open a support ticket.
I know, so didnāt think need to do more time then that. Thought that was overkill to begin with. If it had worked I was expecting to shorten it a bit until it seemed to break again.
We have had a ticket in since Monday, I work with Jill that started this thread.
Weāve gotten virtually nowhere with them besides acknowledging the ticket and after several calls saying they are looking at it. Our CAM even told us something about them being busy with some internal software changes at their offices.
We do have hard coded paths to EpicorData in our System Agent:
Can we use the helper methods in the cloud? I didnāt think had the references available for that in the cloud. Took a look and tried it donāt find the references. Nor does it seem to work if just put them on the bpm manually. Maybe trying to use the wrong ones?
Thinking out loud, Bartender REST might be worth a crackā¦ 
Looking at rest api application actually for future state. But the here and now of suddenly being cut off to reliably write to a file directory within Epicor from inside of Epicor has us hobbled. Itās not that is it isnāt working itās just that seem we are running into timing issues after they did the Azure Kubernetes Services. Time delay even a long one like 8 seconds didnāt help.
Been told it is now case sensitive, not sure how true that is but looking at it.
We had multiple issues with emails, we ended up switching from using SMTP to Microsoft 365 to resolve them. Support was not able to figure out why all of a sudden the SMTP issue was occurring.
See the new āEmail Settings Maintenanceā application in Epicor, it allows selecting which approach to use and configure the settings for it (āitā being either SMTP or Microsoft 365)
Just an FYI and update, they got back with us noting a server issue and pending fix. They had us switch from the URL to an IP address when referencing this area for any calls to write to that file path.
\IPADDRESS\SAASNUMBER\LiveEDI\LabelDrop\
Yes, and you are supposed to! 
Hey all - sorry for the delayed response.
The intermittent file issue has been found and is being addressed. Problem relates to DNS propagation / forwarding and you should no longer need to use a specific IP Address in the file path.