djdrew
asked on
Default Printer Changes using Terminal Server
Hey everyone been working on this issue for a week now and still can not find a solid solution. I'll attempt to give few details and things I have tried already and will fill in any needed information.
Have multiple users located at multiple sites in the country and we just switched them from Citrix to Terminal Services. We are using Windows Server 2008 R2. but I believe the RDS is standard Windows 2008.
When they select the printer they want as default and remote into their session it changes the printer default to the Adobe PDF printer OR the Microsoft Document printer.
You can always change it back to which ever printer you want when in session but when you log off and back on it switches it right back to the Adobe OR the Microsoft Document printer.
They all have .NET 3.5 and remote desktop version 6.1 or 7 depending on service pack.
I have even tested it myself on one of our RDS test servers and it happens to me.
I have checked Group Policy settings for printer redirection and it is not configured so I assume that means it should just be keeping the default printer when remoting in.
I have also made sure for the remote desktop settings under Local Resources--Printers was checked, though I think since we are using Terminal Services Easy Printing it should automatically be redirecting the printers they have..
Any ideas, suggestions, things to look for or at, or any other information needed please let me know!
Have multiple users located at multiple sites in the country and we just switched them from Citrix to Terminal Services. We are using Windows Server 2008 R2. but I believe the RDS is standard Windows 2008.
When they select the printer they want as default and remote into their session it changes the printer default to the Adobe PDF printer OR the Microsoft Document printer.
You can always change it back to which ever printer you want when in session but when you log off and back on it switches it right back to the Adobe OR the Microsoft Document printer.
They all have .NET 3.5 and remote desktop version 6.1 or 7 depending on service pack.
I have even tested it myself on one of our RDS test servers and it happens to me.
I have checked Group Policy settings for printer redirection and it is not configured so I assume that means it should just be keeping the default printer when remoting in.
I have also made sure for the remote desktop settings under Local Resources--Printers was checked, though I think since we are using Terminal Services Easy Printing it should automatically be redirecting the printers they have..
Any ideas, suggestions, things to look for or at, or any other information needed please let me know!
ASKER
The printers are installed on a seperate server and for some users they have printers only their building can see.
If i set GP to redirect default printer only the one or two other printers that redirect that they use on occasion for checks etc would not redirect then correct?
I can share the printers on the other server and see what happens.
If i set GP to redirect default printer only the one or two other printers that redirect that they use on occasion for checks etc would not redirect then correct?
I can share the printers on the other server and see what happens.
ASKER
All printers were already being shared
I have seen this exact problem on XP as well. This is a longshot, but . . .
The fix was installing the .NET 3.5 Family update for .NET 2.0 through 3.5 on the host machine (in your case, the 2008 Term Server).
(KB951847 was the XP etc. KB)
If you have the latest updates for ALL the .NET stuff on your 2008 server, then this probably isn't going to be helpful.
If not, try this:
Here's the operative part:
Here's the link for the Server 2008 3.5 version:
Apparently, it had to the 'Family' update, because just putting the newest 3.5 on didn't fix it.
I'd recommend using Windows Update, but here's a link to the MS Download Page for .NET and Server 2008.
This problem appeared after an XP remote desktop to another XP machine. Every time the user logged in to the remote XP machine, the default printer on both machines was changed to XPS or PDF. The fix was coincidental: During a Quickbooks 2010 install on the host machine, .NET had to be upgraded. The upgrade failed, and the only fix was to remove and reinstall .NET.
The logs showed that the host machine would not install .NET 3.5 Family Update for .NET versions 2.0 through 3.5
After a process of trying to fix that problem, we finally had to completely remove .NET and reinstall it.
After going through the process to reinstall .NET, the XPS and PDF problem disappeared (and the 3.5 .NET Family update was successful.)
The fix was installing the .NET 3.5 Family update for .NET 2.0 through 3.5 on the host machine (in your case, the 2008 Term Server).
(KB951847 was the XP etc. KB)
If you have the latest updates for ALL the .NET stuff on your 2008 server, then this probably isn't going to be helpful.
If not, try this:
Here's the operative part:
Here's the link for the Server 2008 3.5 version:
Apparently, it had to the 'Family' update, because just putting the newest 3.5 on didn't fix it.
I'd recommend using Windows Update, but here's a link to the MS Download Page for .NET and Server 2008.
This problem appeared after an XP remote desktop to another XP machine. Every time the user logged in to the remote XP machine, the default printer on both machines was changed to XPS or PDF. The fix was coincidental: During a Quickbooks 2010 install on the host machine, .NET had to be upgraded. The upgrade failed, and the only fix was to remove and reinstall .NET.
The logs showed that the host machine would not install .NET 3.5 Family Update for .NET versions 2.0 through 3.5
After a process of trying to fix that problem, we finally had to completely remove .NET and reinstall it.
After going through the process to reinstall .NET, the XPS and PDF problem disappeared (and the 3.5 .NET Family update was successful.)
Sorry, the link didn't get in the post ;(
Here it is:
http://www.microsoft.com/downloads/en/results.aspx?freetext=.NET+server+2008&displaylang=en&stype=s_basic
Here it is:
http://www.microsoft.com/downloads/en/results.aspx?freetext=.NET+server+2008&displaylang=en&stype=s_basic
ASKER
interesting. I just checked our TS and it does not have any .NET installed on it. So should I install 2.0 first then 3.0 then 3.5? or just installing from that link should be okay
I would use Windows Update, custom and let it tell me how to do it. If you pick the .net installs, it will tell you what order to put them in. In fact if you pick them all, it will install them in the right order.
However, I think the 3.5 family update will do the trick. If it needs pre-requisites, it will complain.
Hope it helps!
However, I think the 3.5 family update will do the trick. If it needs pre-requisites, it will complain.
Hope it helps!
Some possible verification that .net is involved:
http://blogs.technet.com/b/askperf/archive/2008/02/17/ws2008-terminal-services-printing.aspx
This article shows the "Easy Print" universal driver in 2008 Terminal Services using .net to route the printing.
It also shows GDI to XPS as a workflow block. IT would not surprise me to find out that the developers used .net as part of the lingo that makes it work.
Because the RDC client, MSTSC.EXE, is a native Win32 application, and the WPF printing infrastructure uses managed (.Net Framework) API's, a managed wrapper was created to support Terminal Services Easy Print. When a document is printed from a remote desktop session using the Easy Print driver on the Terminal Server, the RDC client calls the managed wrapper, TSWPFWRP.EXE, to assist with processing the print job on the client. TSWPFWRP.EXE is only used for Easy Print redirected printer functionality and is only invoked when printing.
An important note - for any client computers that do not support the Terminal Services Easy Print feature, only client printers that have a corresponding driver on the Windows Server 2008 Terminal Server can be redirected in a Terminal Server session.
http://blogs.technet.com/b/askperf/archive/2008/02/17/ws2008-terminal-services-printing.aspx
This article shows the "Easy Print" universal driver in 2008 Terminal Services using .net to route the printing.
It also shows GDI to XPS as a workflow block. IT would not surprise me to find out that the developers used .net as part of the lingo that makes it work.
Because the RDC client, MSTSC.EXE, is a native Win32 application, and the WPF printing infrastructure uses managed (.Net Framework) API's, a managed wrapper was created to support Terminal Services Easy Print. When a document is printed from a remote desktop session using the Easy Print driver on the Terminal Server, the RDC client calls the managed wrapper, TSWPFWRP.EXE, to assist with processing the print job on the client. TSWPFWRP.EXE is only used for Easy Print redirected printer functionality and is only invoked when printing.
An important note - for any client computers that do not support the Terminal Services Easy Print feature, only client printers that have a corresponding driver on the Windows Server 2008 Terminal Server can be redirected in a Terminal Server session.
Sorry,
I meant to put qutoes around the last two paragraphs--they are from the article. ;)
I meant to put qutoes around the last two paragraphs--they are from the article. ;)
ASKER
I have not yet tried downloading and installing .NET for the TS.
I did however test, from my PC and from a remote session on the server, adding a printer and setting it as my default and then logging in to the session. On all occasions it kept my Default selection. I am using Windows 7 and the main TS is Server 2008 R2.
I need to pin point all the users having this issue still but could it be an OS issue with XP in general when using remote desktop?
I did however test, from my PC and from a remote session on the server, adding a printer and setting it as my default and then logging in to the session. On all occasions it kept my Default selection. I am using Windows 7 and the main TS is Server 2008 R2.
I need to pin point all the users having this issue still but could it be an OS issue with XP in general when using remote desktop?
ASKER
Tested it on an XP machine and default printer did not change, I can not figure out why it effects some users and not all. Very frustrating.
I'd like to know if the users have different printer drivers. If the workstation has the exact same driver on their workstation, the print system doesn't go through the same process.
If the workstation does not have the (exact!) driver, then 'Easy Print' takes over (in 2008 Remote Desktop Services). Also, remote desktop can substitute close previous versions: like LJ4 driver will work on an LJ5si--it just won't have the same features.
Each substitution, whether Easy Print or previous driver uses a different path in the print system. So if the bug only happens in one particular section, it would only happen when that section came in to play.
The article I referenced states that the developers used .net in the Easy Print system--that could be where the bug is.
I would also think that 7 uses different systems than XP. Doesn't mean it won't happen in 7, but it does mean that the circumstances might be different if it happens at all.
Regarding the exact driver--Citrix techs have stated that a difference in capitals or the version number of the driver can have a detrimental effect. Since Citrix was involved in the RDP development, this could be at least a similar issue.
If the workstation does not have the (exact!) driver, then 'Easy Print' takes over (in 2008 Remote Desktop Services). Also, remote desktop can substitute close previous versions: like LJ4 driver will work on an LJ5si--it just won't have the same features.
Each substitution, whether Easy Print or previous driver uses a different path in the print system. So if the bug only happens in one particular section, it would only happen when that section came in to play.
The article I referenced states that the developers used .net in the Easy Print system--that could be where the bug is.
I would also think that 7 uses different systems than XP. Doesn't mean it won't happen in 7, but it does mean that the circumstances might be different if it happens at all.
Regarding the exact driver--Citrix techs have stated that a difference in capitals or the version number of the driver can have a detrimental effect. Since Citrix was involved in the RDP development, this could be at least a similar issue.
ASKER
So if the user is using a different driver on their local machine then what is on the server this could potentially be causing the printer they want to be set as default to be changed to the Adobe PDF or Microsoft Document Writer? The printers still redirect and print fine, just will not stay as default when they log in and out.
That is the theory. If you go to the link, look at the diagram. Note that if the printer driver on the 2008 RDP unit and the driver on the client machine match, no Easy Print driver etc. If they don't match, the process flow takes you through the section of the program that uses Easy Print. Since we're blazing new ground here, and my only example was XP to XP, you won't know for sure until you test.
Everything is speculation until you fire the magic bullet.
I think that your observation that certain machines don't have the conflict is interesting. 2008 and Windows 7 are very similar -- so matching print drivers are more likely. For example, most print drivers actually say 2008, Vista, Windows 7. If they support one, they support all.
Since some computers change (you stated "I have even tested it myself on one of our RDS test servers and it happens to me." ) I suggest you compare one that doesn't loose the default with one that does. Look at the print drivers and see if they match.
Could you clear this up? You have client machine, RDS machine and then a 3rd machine that has the printers on it?
i.e. the printer is on a share when viewed from RDS?
Everything is speculation until you fire the magic bullet.
I think that your observation that certain machines don't have the conflict is interesting. 2008 and Windows 7 are very similar -- so matching print drivers are more likely. For example, most print drivers actually say 2008, Vista, Windows 7. If they support one, they support all.
Since some computers change (you stated "I have even tested it myself on one of our RDS test servers and it happens to me." ) I suggest you compare one that doesn't loose the default with one that does. Look at the print drivers and see if they match.
Could you clear this up? You have client machine, RDS machine and then a 3rd machine that has the printers on it?
i.e. the printer is on a share when viewed from RDS?
ASKER
correct they are shared from a different server.
and I realized when I first was testing the change I added the printer while in the session. Realizing my mistake there I added the printer before I logged into the session and it did not redirect.
All of our users though had to have the printers added before they remote in because while in session their priviledges are prtetty limited.
and I realized when I first was testing the change I added the printer while in the session. Realizing my mistake there I added the printer before I logged into the session and it did not redirect.
All of our users though had to have the printers added before they remote in because while in session their priviledges are prtetty limited.
Thanks! I would think that if you connect to the printer sharing server from the clients and install the printers, then when you go to the RDS unit it would bypass the possible printer issues. Since the driver would install from the server that shares the printers, it would match the one on the RDS unit.
If nothing else, it would clear up the question of mis-matched drivers. The reason I think this happens is related to the mechanism that redirects the printing. The absence of a driver match makes the RDS computer go to the universal driver. This u-driver is also used to connect to the MS document printer and XPS as well as PDF.
Citrix has a similar universal driver, and you changed from Citrix to MS RDS. Since something in this chain is foobar, making the print path more direct might help (by having the correct driver in the first place you bypass all this universal driver mechanism stuff) .
If nothing else, it would clear up the question of mis-matched drivers. The reason I think this happens is related to the mechanism that redirects the printing. The absence of a driver match makes the RDS computer go to the universal driver. This u-driver is also used to connect to the MS document printer and XPS as well as PDF.
Citrix has a similar universal driver, and you changed from Citrix to MS RDS. Since something in this chain is foobar, making the print path more direct might help (by having the correct driver in the first place you bypass all this universal driver mechanism stuff) .
There's another piece of info I need: whether you're printing to a shared printer installed on the workstation, or a shared printer installed on the RDS server.
If the job is created on the RDS server and it has connections to the shared printers, that's one system, and if the job is coming to the workstation and then directly to the shared printers, that's another system.
(you should try explaining that to some of my customers ;-)
i.e. does the workstation point the job to a printer image on the RDS server, or does the workstation point the job to a printer image on its own printers list.
If the job is created on the RDS server and it has connections to the shared printers, that's one system, and if the job is coming to the workstation and then directly to the shared printers, that's another system.
(you should try explaining that to some of my customers ;-)
i.e. does the workstation point the job to a printer image on the RDS server, or does the workstation point the job to a printer image on its own printers list.
ASKER
I believe the answer to that question is to its own printer image on tis own printers list, I added them from the Network Directory to their machine to have the printers re-direct from their machine to the remote session. No printers are added on the actualy TS.
I have to install .NET at night when people are nto logged in which is difficult because someone is always logged in incase I have to restart the machine.
I have to install .NET at night when people are nto logged in which is difficult because someone is always logged in incase I have to restart the machine.
ASKER
bah i forgot how server 08/windows 7 are configured with 3.5 already installed in the Features (Windows Components)
All 3 of them (workstation, termserv and print server) should be 3.5 at least and the remote desktop version 6.1 at least.
That is good. The problem applies that the term svc process makes the TS (RDS in 2008) 'render' the job and send it to the print queue on the workstation.
So the RDS does have 3.5?
That is good. The problem applies that the term svc process makes the TS (RDS in 2008) 'render' the job and send it to the print queue on the workstation.
So the RDS does have 3.5?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks djdrew!
Secondly: could you configure Group Policy on the TS to redirect default printer only and make sure that user have his default printer defined locally correct before logon to TS.
Thirdly: make sure that all printers is configured as a shared printers, not local printers on the TS.