on ‎2023 Mar 14 8:35 AM
We've recently added an SSL to our front facing client site. The rest of the site works and is able to make database calls through ASP.NET.
While accessing the site through HTTP the reports generate fine. If the protocol is changed to HTTPS, all reports are now returning the below image

The database connection is setup as an ODBC 32-bit connection so as I do not have to go through hundreds of reports to manually update the credentials (migrated from an older system). I've tried setting up the ODBC using the SQL Server Native Client 11.0 Version 2011.110.6540.00 and CR SQL Server Native Wire Protocol ODBC 7.1.5 Version 7.10.106.324. Either of these ODBC connections work within reports and while running the website locally in Visual Studio or in HTTP on IIS.
Crystal Reports 2016 Support Pack 5
Version 14.2.5.2618
Windows Server 2016 Standard
IIS 10.0
Microsoft SQL Server Standard (64 bit) Version 14.0.2047.8
As per this answer thread I've tried changing the application pool for the site to run in classic mode rather than integrated with no difference. The linked resource in the best answer returns a not found error.
Any help would be greatly appreciated!
Request clarification before answering.
Hi Daniel,
CR shouldn't care how you log into your web site, this I believe is a IIS configuration issue, likely permissions for the AppPool or possibly the IIS Temp Folder, CR require full read/write permissions.
I also suggest upgrading to SP 22, SP 25 is quite old:
https://wiki.scn.sap.com/wiki/display/BOBJ/Crystal+Reports%2C+Developer+for+Visual+Studio+Downloads
And see my blog on upgrading:
Fiddler may show you where it's failing or Possibly ProcessMonitor.
Does your app have the Viewer Embedded in it? IF so what happens when you export from the Viewer?
If you don't write a simple test program and remove CR from the picture and simply try to log onto the DB using ADO.NET and see if that works.
Don
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Don,
Thank you so much for your assistance, unfortunately after updating to SP 33, publishing, and restarting we still have the same issue.
This client has the same project being deployed to two locations, an internal only site with read/write to the database and an external reporting site with read only access. The internal site, which is HTTP only, does not have any issues with generating CR reports. The external site successfully generates reports when connected to via the HTTP protocol. When the user is connected via the HTTPS protocol is when the Database logon error occurs.
Using ProcessMonitor I did see one ACCESS DENIED for an AppData/Local folder, but adding the Full Access permission to the IIS_IUSR group did not fix the issue.
In order to access the reporting section clients must first login. This login process does use the ADO.Net System.Data.SqlClient namespace for DB queries. On the HTTPS version clients are able to login and dropdowns populated from the database also work.
I don't believe the Viewer is embedded in the app, at least no reference to it that I can find.
Use Google and search for how to...
Capture all IIS traffic, on the Web server in Fiddler | Telerik F
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Daniel,
Fiddle may show you it's trying to load a dll from the wrong place or could show a security issue.
CR runtime is platform specific so if your AppPool is 64 bit CR requires a 64 bit DSN, I don't see you mention that.
Set the Project to X64, not anyCPU, set up a 64 bit DSN
See if that helps.
CR does care if you use HTTP or HTTPS, security is all in the backend.
Don
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Don,
Our server admin created a domain user and added that user to the server's IIS_IUSR group. We then changed the app pool to run using this new user. The rest of the website still works, ADO.Net commands are able to run and view compiling has access to the necessary temp folders. Still unable to generate reports with CR.
I then updated the project to run using the x64 platform. Given all the changes I had to make to the project to get that to build, I think it's safe to say it was building as a x86 app. I then made a 64-bit DSN and add web.config transformations so if deployed on the x64 platform it'll use the new DSN name. Deploying the app in strict 64-bit and strict 32-bit modes did not make any difference other than I saw w3p3.exe running under their respective deployed platforms. I also confirmed after deployment that the deployed web.config had the correct DSN.
I apologize, I am unfamiliar with the usage of Fiddler. What would I setup to get the web app to display access denied or incorrect dll loading in Fiddler?
How about using Fiddler to see if it catches the permission issue.
If you run IIS under a specific user does that work?
CR must have full read/write permission to the IIS \Temp folder, when exporting we first attempt to write a file and the try to delete it to check permissions, if we can't the export will fail.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I guess I'm missing how Fiddler is supposed to help me diagnose the issue when all it does is capture web request traffic. It's not telling me anything new the browser wasn't already telling me. I have the error logs and stack trace already.
I'll have to talk with the server admin about setting up a new user for the app pool.
As it is, IIS_IUSR group has read/write permissions to the following:
C:\inetpub\temp
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
The reports generate fine when using the HTTP binding under the same app and app_pool, so that would lead me to believe it has all the file permissions it needs.
| User | Count |
|---|---|
| 8 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.