I am working in the nNavy's NMCI environment. For those of you who don't know what that means it is the Navy Marine Corps Intranet. In that environment unless you have what is called a "developer's seat" you have no admin rights on your machine. Additionally all the non-developer seats in the Navy are maintained exactly the same by a central organization. Local users and local IT personnel have no rights on these machines. (In fact, they can not even change printer cartridges.) We are loading reports onto a report server so that regular users can read them using the Report Manager. On viewing these reports in Report Manager they need to be able to print them out. However we are get the ActiveX control warning. But even if you click install, the ActiveX will not install and you still get the error. "Unable to load client print control." The Report server which is Windows Server 2003 has all current updates for Windows Server and for SSRS. All changes to client machine must be carried out Navy-wide to every client machine so it can not be pushed only to that small percentage of users using SSRS. Nor can't registry changes be made on clients. The only way a push could resolve the issue would be for to apply to the NMCI powers that be to do a push to the entire Navy. (And you can guess the likelihood of that happening in a service primarily composed of Oracle users.) So how is the navy supposed to use SSRS print? Edward R. Joell MCSD MCDBA

Hi I'm afraid I cannot help you with direct printing, since I've worked in a similar environment and it seems you will never get it resolved. The only alternative I can offer is to teach the users to export to PDF (or MS Word) and then print from the PDF file. Craig Bryden - Please mark correct answers

Exporting to PDF did not work very wellbecause of the size of the font and the report width. (the PDf export seems to be fixed at 8.5 x 11). Export to Excel with changes in formating adding page headers and footers, changing row heights, setting the print area, and then printing seemed to work. However this is a very labor intensive means to accomplish this. The thing that is bothering me is that the print function was working just fine on April 7, 2011. But then we started getting that message yesterday. Edward R. Joell MCSD MCDBA

Tough.. exactly what version of the print control is the HTML referencing? Right click view source etc... you should see a reference to rsclientprint somewhere in there followed by a version number. It's interesting that it worked until April 7. Perhaps another update was applied that introduced an activex killbit? You seem familiar with the rsclientprint control activex issue. If you can let us know the version of the client print control that the html is attempting to reference it may help. Is there any way you can leverage Microsoft Support from within the Navy without having to go through several phone calls and meetings? Just a thought... you are in a really restrictive environment to actually be able to fix anything. I've been in a similar type of organisation needing an update to be applied to fix a Dynamics CRM issue and found it helped with Microsoft on the end of the phone saying "This needs installing"

There is nothing in the Report Manager's report screen's view source that indicates what version of of the rsclient print it is trying to install. BTW we found out when this occurred that the version of SSRS we are working with is SSRS 2008 SP 2. There are no rsclientprint files anywhere on this NMCI machine as NMCI does random pushes to set machines back to the desire configuration it is possible there was some update run to prevent me from ever installing this control. OTOH I have no confidence in the competence or the accuracy of the statements coming from the Data Center's personnel on this issue. One of the issues I saw discussed had to do with updates to the version of rsclientprint that was on the server that would be attempted to be installed on the client machine. Seemed to be saying that if a certain update was applied, then this error would not be generated when the server delivered the activeX control to be installed. As far as I know there is no possiblity of the Navy's agreeing to change the configuration a few user's machines that would differentiate them from the standard set up for this level of user. It would be necessary for an application to be made to make the user's machine a "developer's seat" which would allow them to have administrative rights on the machine but with there would be other issues involved with that. What about if a user with developer's rights were to log onto this machine and try to do a print. Would a succesful install by this user then work for the user with limited rights? Edward R. Joell MCSD MCDBA