cancel
Showing results for 
Search instead for 
Did you mean: 

Can't upload .rpt's to CRS XI

Former Member
0 Kudos

Our company has had a staged version of Crystal Reports Server on our local network for a few months, running fine with no issues. We are trying to deploy it to a a production server but are having some issues.

When I try to upload a report to the server via InfoView, I get the following error:

Failed to read data from report file C:\WINDOWS\TEMP\tmp427.rpt. Reason: Failed to open print engine for C:\WINDOWS\TEMP\tmpreport\~cid1c5a12f45a920.rpt. Ensure that CRPE32 is installed on this computer.

For reference, two things which may be causing the error to occur on the production version, but not on the staging version:

- The staging version was installed to the default location. The production version was installed to a non-system drive (D:)

- The staging version was set up with CRS as the default website. On the production version, there are multiple websites running on the same server/IP.

Based on an [earlier post |] we tested and confirmed that changing IIS Application Pool to run under "Local System" instead of "Network Service" would resolve this issue, but our system administrator does not want to make this change for security reasons, and instead wants to know the minimal set of permissions that need to be assigned to Network Service to have CRS work correctly (keeping in mind the non-default location for the installation). Does anyone know where I could find this documentation?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

So that's it then? Does BO/SAP not have the necessary NTFS permissions documented for a non-default installation location of CRS XI?

Edited by: Fabio Beltramini on Apr 19, 2009 2:33 PM

Former Member
0 Kudos

Tested out a better solution myself. Apparently, the local Users group did not have any permissions set on the C: drive. I allowed Read & Execute, List Folder Contents, and Read access for the local Users group on the C: drive. Now, it works.

Did not find any solutions from SAP documentation on this.

Answers (2)

Answers (2)

denis_konovalov
Active Contributor
0 Kudos

Actualy most of the customer install to E:, 😧 and other drives, C: drive install is very rare.

Have you tried searching SAP Notes for this error ?

Usualy this is due to permissions with IIS or AppPool used by it.

Former Member
0 Kudos

Yes, as you mentioned, this error is caused by the permissions available to the Application Pool. We tested this.

However, we can't run IIS/the application pool under Local System, instead we need to know what specific permissions are necessary for this to work correctly under Network Service.

I have searched notes, documentation, forums, the web and found no mention of the correct/necessary permissions, only a few instances of this issue reported as resolved by the above resolution which we want to avoid.

denis_konovalov
Active Contributor
0 Kudos

There is definately no List like that.

If you have to use Network service, make sure it has access to BO direcotories, and to all temp directories.

If you trace this with FileMon tool and see on what files or directories Access Denied is received.

Former Member
0 Kudos

I am on IIS 5 and Windows 2000 Server.

My temporary solution that helps make things work is to add the ASPNET user to the Admin group. This is temporary as the Sys Admins will not like it.

There is no documentation on which folders need permissions set for which user. This forum has been very helpful. CRS XI install is flaky. I did an install on another test machine against the "C:" drive and there were no issues. When installing to the "D:" drive, I had to do an extra step of setting the "let IIS manage the IUSR account password" on the virtual directory anonymous access settings. This needed to happen on both the "businessobjects" and "crystalreportviewers115" virtual directories.

denis_konovalov
Active Contributor
0 Kudos

I'd say it's not CRSXI install that's flaky, it's IIS that's flaky depending on where it's web sites are.

To avoid this problems use Java application servers.

Former Member
0 Kudos

I am having the same problem. I also installed to the "D" drive. There has been no solution so far. Business Objects and SAP might have not encountered this before since people are always installing to their "C:" drive.

I am on IIS 5.0 and CRS XI.