RSClientPrint - unable to load client print control on terminal server

There is no policy that we have configured to do this. Other sites that active x work fine as far as I know. I will try to test this some more and post back on this. Thanks for the suggestion Chrismc

I have checked and we do not have a policy in place that blocks ActiveX controls from being installed on the terminal servers. In my searching though, I did find that in order to install an ActiveX control a user must have administrative rights on the machine where they wish to install it, in this case our Terminal Servers, but we can't give our users administrative permissions.

I did find this site (http://www.vinsvision.com/Default.aspx?tabid=66&EntryID=11) that talks about publishing activex controls through AD but you need an msi to do it, which the RSClientPrint does not have as it comes in cab. Are there other ways to publish an ActiveX where a user will be able to run it? Or is there a way to install an ActiveX from the console so that everyone on the machine has access to it without them having to install? If there is I haven't been able to find it yet.

Thank you for the response Auric1983,

For number 1 what all do you copy over as I am unsure. Everything in the profile directory?

For number 2, i have tried registering it which it says is successful. I then log on as a normal user and try to go to our reporting services site to print the report. It pops up asking to install the control, which when i press install it then comes up with the "unable to load client print control" error message.

For number 3, I get the same behaviour as for number 2.


I tried with creating a brand new user and then logging onto the server and it works for that user but not for any existing users. Any pointers on how to fix that one, since I really don't want to field calls from all of our users (150+) to recreate their profiles.

Thanks

there maybe a file lurking in the existing users setup that is not getting overwritten.
I'm not sure what exactly it downloads but if you can work that out and clear it out for the existing users, it may resolve your problem.

This link goes into some detail on what gets installed;
   http://www.kodyaz.com/articles/client-side-printing-silent-deployment-of-rsclientPrint.aspx

Cheers
Chris

Thank you Auric. I found the part about the update that brakes SSRS printing, and I have applied the updates to our Reporting Server that corrected that portion of the issue. Before those updates it didn't work on any of our clients and once that was installed the local clients were able to print. Now it is just a matter of getting it to work on the terminal servers.


I am in the process of deleting a profile for an existing user and then I will let it recreate and see if it works or not. If this works, I think deleting them and recreating them will be the way to get it working. Maybe I can back up their current profiles and then write a script that copies back the few things that they need out of them.

It should, we use a limited profile on our TS so the users don't have anything more than a default printer setting

Deleting an existing users profile and letting it get recreated did the trick. What a pain.

Too bad I can't find what is causing the issue. I have tried deleting everything to do with Internet Explorer from the profile but that didn't help. I guess I will need to start deleting profiles for people who need to print from SSRS.
[QUOTE Auric1983]
I've been through this a number of times, and the two ways we came up with to get around this is

1. Install on the terminal server as an administrative user, copy the profile for that user into the Default User dir all new accounts will be created w/ access to that activeX
2. You can manually copy the rsPrintClient.dll onto the server and regsrv32 the DLL
3. Create an MSI package and deploy via GPO http://bogdanbrinzarea.wordpress.com/2009/07/07/unable-to-load-client-print-control-and-deploying-rsclientprint-via-msi/
[/QUOTE]

For Auric's number 2&3 this worked for any new user that had logged on but not for already existing users. Since this isn't an issue on our dektops and only on our Terminal Servers I have opted to go with option 2 as what I am going to put in place to solve this issue and then delete the profiles of any users who need it that already exist and recreate their profile.

That's the one unfortunate piece that I haven't been able to figure out either.

In our case because all of our users are restricted via GPO on the terminal server they don't really have access to anything other than the Application we want them working in, so recreating a profile wasn't a big deal.  Just had to remind users to double check their default printer.