The obvious thing to do is to create an identical user locally on each server, same user - same password. Let's assume we created a non-administrator user called ReportServiceUser. We made the user non-administrator because we care about security.
Next, you logon to the middle tier, find the application pool that hosts your WCFService, and use ReportServiceUser as the identity.
Then you logon to the Report Server and give ReportServiceUser access to the site and the reports. This is all very similar to the procedure explained in the earlier blog entry.
Try to run the report through Report Manager from the middle tier and you may or may not succeed. But if you use your application to run the report from the WCFService you will fail. You will also see that the application pool has stopped. Open up event viewer on the middle tier and look at the System events...
First we got three warnings, then we got an error. The error tells us the services was stopped but it's the first warning that has the important error code.
Simply searching Google on the error code will normally tell you the next step to take. In this case we find that ReportServiceUser does not have the required roles to act as an application pool identity. You need to give the user the ability to logon as a batch job and the ability to logon as a service.
Browse to Administrative Tools -> Local Security Policy. Then choose User Rights Assignment.
You need to add ReportServiceUser to both the highlighted rights. To do this, right-click one of them and select "Properties". In the popup click on the [Add User or Group] button and add ReportServiceUser. Then repeat for the other.
Now recycle the application pool to use these new capabilities.
