Fixing File System Permissions for the Events & Actions (E&A) Module

This guide helps IT and system administrators resolve file system permission errors when the Events & Actions (E&A) module attempts to delete, read, or write files on Windows servers running IIS.

Symptom

An E&A event configured with a File Delete action (or any file system action) fails with an error similar to:

System.UnauthorizedAccessException: Access to the path 'C:\Temp\Test.txt' is denied.
	 at System.IO.FileSystem.DeleteFile(String fullPath)
	 at APS.EventsAndActions.Actions.Storage.FileDeleteAction.RunActionAsync(...)

The file exists at the specified path, but the E&A action cannot perform the operation. The event may be logged as failed in the E&A event log.

Why It Happens

The Events & Actions module runs in-process inside the MCEverywhere web application as a Quartz.NET background job (RunActionJob). It is not a separate Windows service or standalone executable.

This means:

• File operations execute under the identity of the IIS application pool that hosts the MCEverywhere site.
• By default, IIS application pools run as ApplicationPoolIdentity, a virtual account with the naming pattern IIS AppPool\<PoolName> (e.g., IIS AppPool\MCEverywhere).
• There is no dedicated "E&A account" — the app pool identity is the security principal performing the file operation.

The Access Control List (ACL) on the target folder must explicitly include the correct virtual account identity.

Resolution Steps

Step 1 — Identify Which App Pool Serves the Site

Open an **elevated ** prompt and run:

Import-Module WebAdministration
Get-WebApplication | Select-Object Path, applicationPool
Get-Website        | Select-Object Name, applicationPool

Example output:

Path                                    applicationPool
----                                        ---------------
/                                            MCEverywhere
/SomeOtherApp                DefaultAppPool
 
Name                                 applicationPool
----                                        ---------------
Default Web Site               DefaultAppPool
MCEverywhere                  MCEverywhere

Locate the row corresponding to your MCEverywhere site. Note the applicationPool value — in this example, it is MCEverywhere.

Step 2 — Match the Running Worker Process to Its Account and Pool

Confirm the exact identity under which the worker process is running:

Get-CimInstance Win32_Process -Filter "Name='w3wp.exe'" | ForEach-Object {
	$o = $_.GetOwner()
	[pscustomobject]@{ PID = $_.ProcessId; User = "$($o.Domain)\$($o.User)"; Cmd = $_.CommandLine }
}

Example output:

PID  User                       Cmd
---  ----                       ---
4512 IIS APPPOOL\MCEverywhere   c:\windows\system32\inetsrv\w3wp.exe -ap "MCEverywhere" -v ...
6788 IIS APPPOOL\DefaultAppPool c:\windows\system32\inetsrv\w3wp.exe -ap "DefaultAppPool" -v ...

How to read the output:

• The User column shows the security principal executing the process (e.g., IIS APPPOOL\MCEverywhere).
• The Cmd column includes -ap "\<PoolName>", confirming which application pool the worker process serves.

Match the app pool name from Step 1 to the corresponding User identity. This is the account you must grant permissions to.

Step 3 — Grant the Correct Permissions

Grant the virtual account Modify permission (sufficient for delete, read, and write operations) on the target folder where the E&A action operates and where DataHub drops files.

Run the following command in an elevated Command Prompt or ****:

icacls "C:\Path\To\Folder" /grant "IIS AppPool\MCEverywhere:(OI)(CI)M" /T

Explanation:

• C:\Path\To\Folder — Replace with the actual folder path (e.g., C:\Temp or the DataHub import directory).
• IIS AppPool\MCEverywhere — Replace MCEverywhere with the app pool name identified in Steps 1–2.
• (OI)(CI) — Object Inherit and Container Inherit flags. Permissions propagate to all files and subfolders.
• M — Modify permission (includes Read, Write, Delete).
• /T — Apply recursively to existing files and subfolders.

Example:

icacls "C:\Temp" /grant "IIS AppPool\MCEverywhere:(OI)(CI)M" /T

To grant via Windows Explorer (GUI):

1. Right-click the folder → Properties → Security tab → Edit.
2. Click Add.
3. In the Enter the object names to select field, type:

   IIS AppPool\MCEverywhere

4. Click Check Names. The name will be underlined (resolved against "this computer").
5. Click OK.
6. In the Permissions list, check Modify (or Full Control if preferred).
7. Click Apply → OK.
8. On the Security tab, click Advanced → Change permissions → select the entry → Edit → check "Replace all child object permission entries..." → OK to propagate.

Step 4 — Verify

1. Re-run the E&A event that triggers the File Delete action.
2. Confirm the file is successfully removed from the target folder.
3. Check the E&A event log to ensure no UnauthorizedAccessException is recorded.

If the error persists:

• Double-check the folder path in the E&A action configuration.
• Verify the permissions were applied to the correct folder and inherited to child objects.
• Restart the IIS application pool to ensure any cached security tokens are refreshed:

  Restart-WebAppPool -Name "MCEverywhere"

Notes and Caveats

App Pool Names Vary by Environment

The application pool name may differ across environments:

• Production: MCEverywhere
• Staging: mcenext
• Development: mcx

Always confirm via Steps 1–2 rather than assuming a specific name.

Files on Network (UNC) Shares

If the E&A action targets a file on a network share (e.g., \\FileServer\Share\Folder), the IIS application pool identity presents itself to the remote server as the computer account (DOMAIN\MACHINE$), not as the virtual account.

Resolution:

1. Grant Share and NTFS permissions to the machine account on the remote file server:

   DOMAIN\WEBSERVER01$

   (Replace WEBSERVER01 with the actual hostname of the IIS server.)
2. Alternatively, configure the application pool to run as a domain service account with explicit credentials, then grant permissions to that account.

Applies to All E&A File System Actions

The identity and permission requirements described in this guide apply to all E&A file system actions:

• File Delete
• File Read (e.g., for content triggers)
• File Write/Create
• File Move/Copy

DataHub Import Location

If DataHub is configured to import files to a folder (e.g., C:\Temp), the same application pool identity must have Write permission on that folder for the import to succeed.

Summary

When troubleshooting E&A file system permission errors:

1. Remember that E&A runs in-process under the IIS application pool identity, not as a separate account.
2. Use to identify the exact app pool name and the virtual account (IIS AppPool\<PoolName>).
3. Grant permissions to the virtual account using icacls or Windows Explorer.
4. For network shares, grant permissions to the machine account (DOMAIN\MACHINE$).
5. Test and verify by re-running the E&A action.

This approach resolves the vast majority of UnauthorizedAccessException errors in E&A file operations on Windows + IIS environments.