Ensure IIS User has File Access

Epicor ERP 10
1

Ok - I must be missing something, but a new deployment on a test server of 10.1.500.14 fails consistently at the same point: “Ensure IIS User has File Access”

I have adjusted every account/permission I can think of, including some that shouldn’t be to try and get past this. A recent deployment using identical setting worked like a champ…

Here is the error

Application Server Setup Failed.
Errors:
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)
at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)

2

Did you share the epicordata folder on this new server. If not, share it and try again

3

Yes - reaffirmed all of the Shares are setup properly. Ports are all open on the firewall. I am going to review AV exclusions with the IT Managed Service Provider. That’s all I can imagine might be the issue at this point

4

AV exclusions have all been applied and the issue continues with the exact same error.
At this point probably just need to blow away the VM and start over.

5

I’ve come across it before on Windows 2012 R2… But on Windows 2016 it all worked fine. I had to follow the following:

Unsure as to why… sometimes IIS grants IIS_ISURS permissions and sometimes it doesn’t.

6

Thank you - turns out the problem is some how related to having an APPSERVER defined with the full servername.doaminname.com versus just server name

Example: If server name equals epicor1 and the Appserver node in the admin console is defined as epicor1.domainname.com then the deployment of a new instance fails every single time.

If I define it as just epicor1, and with EVERYTHING else identical…it works perfectly deploying a new instance.

This is likely a customer specific issue, but I stumbled across this little workaround out of sheer frustration. “It can’t hurt to try one more thing.” Dropping the .domainname.com solved it.