I am getting the attached message when trying to save any change to bpm’s - even most basic tasks like changing from enabled to disabled. This is only happening in live, not in test and is only affecting existing method/data directives. If I try and add a new bpm within a method/table that already has a bpm I get the same error. The affected BPM’s are still working/triggering as expected within the system.
I initially thought something had changed with permissions and have spent quite a bit of time confirming IIS permissions on the appserver were ok and test and live IIS instance permissions are exactly the same. This is also happening even if I access Epicor on the app server where the bpm’s are stored and even using our domain admin account. Further testing within Epicor makes me think that there is something else going on.
In live if I go to a method/table that did not previously have a bpm on it, if I choose new, I am able to create and save a new bpm to the same directive group - with the bpm saving in the same folder in the folder that I am getting an access denied message on. Similarly if I try and edit and save these new bpm’s I am able to do so without issue. This would seem to indicate that there are no issues with IIS/file permissions on the server, just that Epicor itself cannot modify the files.
I have tried the directive update tool and it experiences the same behaviour, and it generates the same error. In case there was some kind of file locking going on I have cycled the servers/clint connections to both the application and database, on the server and all clients, all to no avail.
We are on version 10.0.7.4, and have no support agreement with Epicor. Has anyone else seen this kind of behaviour with BPM’s and if so can you please offer some suggestions as to what could possibly be going wrong and hopefully how to resolve.
I feel like I’ve had similar problems like this before and what I’ve done is open Epicor with the “Run as Administrator” option. I’d give that a try if you haven’t already!
I finally managed to fix this - the read only file attribute had been set for all of the dll’s for the existing bpm’s in folder C:\inetpub\wwwroot\E10Live\Server\Customization - manually unchecking for each file allowed me to fully manage the bpm’s.
I am the only person with admin rights on the server, this was all working without issue a couple of weeks ago and I have no recollection of doing any windows sys admin and no reason why I would do them in live and not test, particularly, making file attribute changes - mondo bizarro but must have been something I did, from the school of unexpected outcomes.
I’ll see if I can ever unintentionally replicate - guess what I am going to check every time I do anything on that server?
