Link to home
Start Free TrialLog in
Avatar of layfieldgroup
layfieldgroup

asked on

RSClientPrint - unable to load client print control on terminal server

Hi,

We run a SQL Server 2005 server with Reporting Services enabled, both running on the same machine; Windows Server 2003 Standard R2 x64. We keep running into the "unable to load client print control" error when users try to print reports from our terminal servers. I was able to solve the issue for our users that run locally on their computers but not for the users who run off of the terminal servers. To solve the issue for the local users, all i did was installed the update for SQL server and then the end users were able to open and print their reports. This however didn't solve the issue on the terminal servers.

Our terminal servers are Windows 2003 Standard x86 and Windows 2003 Standard R2 x64 with all of the latest updates as of the 15th installed on them.

In my testing, any user who has administrative rights on the terminal servers can run and print reports without getting the "unable to load client print control" error message. If it is the first time a user has tried to print a report it asks if they want to install the ActiveX, which they click install to, and then it works. I have tried adding a user to have administrative rights and go in and get this installed under their profile and then remove the administrative rights, but as soon as they try printing again it fails with the unable to error.

I have also tried to manually install the RSClientPrint from the cab file that the reporting server has and it installs successfully but still doesn't allow a user to print the reports.

Has anyone been able to get this to work on a terminal server or have any ideas?

Thanks
Avatar of Chris McGuigan
Chris McGuigan
Flag of Canada image

This is a wild shot in the dark but is there some policy in place against the terminal server to prevent it running ActiveX?

Avatar of layfieldgroup
layfieldgroup

ASKER

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.
ASKER CERTIFIED SOLUTION
Avatar of Auric1983
Auric1983
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.

Ya, thats pretty much the same case for us too, but our users who use the terminal servers do everything on them. So they need their favorites backed up, the outlook NK2 email address cache file, and some other things as well.

Thank you for you help in finding a solution that will get us able to print from SSRS Auric.