Chris McKenzie's Blog : Reporting

Issue with Adobe

taganov — Thu, 11 Aug 2005 18:17:00 GMT

I was trying to test the PDF export generated by Sql Server Reporting Services, but I couldn't get the pdf documents to open. It wasn't just the pdf documents generated by reporting services--I couldn't open any pdf at all. I tried the uninstall/reinstall of Adobe route, but to no avail. This in fact exacerbated my problems. Now everytime I attempted to open Acrobat, Adobe started using 95% of my processor power and wouldn't let go. It still wouldn't open my document

A quick google didn't really bring anything up. Most tips I found involved reading large files (my pdf file was 57kb in size). I tried to go to the Adobe site itself, but something on their site seems to start the Adobe browser plug-in--which of course started eating 95-100% of my processing power right away. I had to uninstall adobe just to use the Adobe web site to find out what my problem was.

I found the solution, albeit in an oblique way. Apparently Adobe generates a lot of temp files and doesn't always clean them up. I found an article on the Adobe Forums that suggested navigating to the root directory and running "del Acr*.tmp /s". Boy was I in for a surprise. Almost immediately the command-line staring filling up with messages that Acr0000.tmp was deleted--and it went all the way up to AcrFFFF.tmp. Wow. So, after deleting the more than 65000 temp files that Adobe had created, I was finally able to open my pdf files.

Hopefully this blog will help the next person that has this problem.

When Reporting Services "cannot decrypt the symmetric key."

taganov — Wed, 23 Mar 2005 18:42:00 GMT

"The report server cannot decrypt the symmetric key."

Follow these instructions:

http://support.microsoft.com/kb/842421

Installing SQL Server Reporting Services on Windows 2000 Server SP4 Domain Controller

taganov — Tue, 23 Mar 2004 13:38:00 GMT

As luck would have it, my first actual field-install of SQL Server Reporting Services was on a Windows 2000 Server SP4 Domain Controller. After installation, I got an error stating that the ReportServer could not be initialized. It took most of the day--but the solution is actually in the ReadMe file. Below is the excerpt from the ReadMe file that is relevant, along with the WorkAround proposed in the related Knowledge Base Article.

1.8. Reporting Services on a domain controller requires manual configuration after setupOn Windows 2003 server, no manual configuration is necessary in order for Reporting Services to install and run properly on a computer that is also a domain controller. On Windows 2000 server, Reporting Services installs properly on a domain controller, but is not activated. Do the following either before or after running setup in order to properly configure Reporting Services to run on a domain controller:

Grant Impersonate Privilege to the IWAM_<machine> account. For more information, see the Knowledge Base Article "IWAM Account Is Not Granted the Impersonate Privilege for ASP.NET 1.1 on a Windows 2000 Domain Controller with SP4" (KB 824308).

CAUSE

You may experience the behavior when the user account that you use to run the program does not have the Impersonate a client after authentication user right (the SeImpersonatePrivilege function). When you upgrade Windows 2000 Server Domain Controller to SP4, the user account (IWAM) is not granted SeImpersonatePrivilege, and then programs that use impersonation may not work correctly.

WORKAROUND

To work around the problem, manually assign Impersonate a client after authentication to the IWAM account. To do so, follow these steps:

Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.

Click Security Settings.

Click Local Policies, and then click User Rights Assignment.

In the right pane, double-click Impersonate a client after authentication.

In the Security Policy Setting window, click Define these policy settings.

Click Add, and then click Browse.

In the Select Users or Groups window, select the IWAM account name, click Add, and then click OK.

Click OK, and then click OK again.

To enforce an update of computer policy, type the following command:
secedit /refreshpolicy machine_policy /enforce

At a command prompt, type iisreset.

------steps not in the readme------

Remove the IWAM_<machine> account from the Guest group. Guest users cannot store or maintain encrypted content. For more information, see the Knowledge Base Article "Roaming Profiles Cannot Create Key Containers" (KB 265357).

Reboot the computer.

On both Windows 2000 and Windows 2003, if you are using a Windows account to connect to the report server database, the Windows user must be granted the privilege to log on locally to the domain controller on which the report server is running, even if the report server database is on a different computer. Domain users are not granted this permission by default. If any of the above steps are performed after setup is completed, run rsactivate.exe to activate your installation of Reporting Services.

Hopefully, this will save someone else from wasting a day trying to resolve this problem.

Happy Reporting!

SQL Server Reporting Services experiences

taganov — Thu, 04 Mar 2004 16:03:00 GMT

I'm in the middle of debugging and enhancing a group of Reports using SQL Server Reporting Services.

Overall I like the product a lot. It's got a very slick designer. The one-touch deployment is outstanding. It isn't lacking for much in the way of features. I still think the reports out to have a managed event-driven code-behind, but I'm able to work around that in most cases. The webservice API is fairly easy to use. I was able to use it to implement my own custom navigation and parameter UI fairly rapidly.

There is one major drawback that should be mentioned though. You cannot use SQL Server Security to access it. It relies on Integrated Windows Security. In the Enterprise Edition you can implement a custom Security extension, which will allow you to basically use any kind of security you can code. This is not available in the Standard version, however.

This creates a problem for me because the app I am working on is a LAN app that uses SQL Server Security. This means that each user has to be set up in a SQL Server role AND their Windows Account name as be set up in the same role--argh! As if security wasn't complex enough! Since our app is a web app, it also means that if a user to to another machine, logs into our app using their SQL Server Credentials, they still view reports in Reporting Services as if they were the logged into the Windows Account.

Am I the only one that finds it strange that an alleged “bolt-on“ to SQL Server can't use SQL Server Security? Does Analysis Services have the same security model?

Again, overall I think this product is outstanding, especially for a first effort. I just question the security model.

UPDATE

Roman writes: “What you have to remember is that RS is a combination of SQL Server and IIS components. SQL Server supports both Windows and SQL Authentication but IIS supports only Windows Authentication. If you wanted to avoid administering dual groups, you would have to switch from Standard to Windows in your other application and set up RS to use Windows Authentication in report data sources.”

You know, I get that. I really do. I guess I expected to be able to allow anonymous access to the Report Manager via IIS, and have the Report Manager query the user for SQL Server credentials when they access the reports. Since Microsoft has a graduated licensing model for Report Access, I guess that wasn't a viable solution for them.