Seems that by doing the following steps, you reset the sandbox account permissions and set them back correctly:
- Put the farm account as managed account for the sandbox service
- Remove the sandbox service managed account
- Add the sandbox service account back as managed account
- Stop the sandbox service
- Put the sandbox account back as managed account for the sandbox service
- Start the sandbox service
For people who still have issues with their sandbox permissions, there’s a “workaround” that can be applied so that the sandbox worker process doesn’t have to use farm credentials for it to work. In essence you force user solutions to run on the same server where the call was made.
Open up central administration and go to system settings:
Next, click on manage user solutions:
Here, select the “All sandboxed code runs on the same machine as a request” and click ok:
That should “solve” most of the problems. It takes out the flexibility sandbox solutions offer and can be considered a temporary fix.
“Sandboxed code execution request failed”; The error I always received while trying to execute a sandboxed webpart on my web front end, while the Sandboxed Code Service was running on an application server. Both with different credentials.
After investigation and fiddling out how sandboxed code is managed, the problem could be narrowed down to a permission issue. When starting the sandboxed code service on the web front end, everything seemed to run fine. So what was not set right?
Firstly, the managed service account that runs the sandbox service has to be a member of the group “Performance Monitor Users”
Secondly, the managed service account which runs the web application pool is never added to the “WSS_WPG” group on the application servers.
After adding the service account of the web application pool to the WSS_WPG group on the application server, the sandboxed web parts ran without any issues.