Bug 3153

Default printer redirect on Windows Server 2016 doesn't work with RemoteApp 31 March, 2021

Eric Cole
06 August, 2019
Product: PowerBuilder Category: PowerScript
Version: 2019 Build:
Classification: Issue Publishing: Public
Priority: P3
Status: Closed Reason: FIXED
Mark Lee @Appeon 05 February, 2020
#16
Hi Eric,

Glad to hear that. We will close this ticket!
If you have any further question please open a new ticket!

Regards,
Mark Lee
Eric Cole 05 February, 2020
#15
Yes, you can close it out.
Mark Lee @Appeon 04 February, 2020
#14
Hi Eric,

Thanks for sharing the information and let us know how to resolved it!
I also agree with you on that the issue now is more of a Windows issue.
So in this way, may I close this ticket?
 
Thanks for your understanding!

Regards,
Mark Lee
Eric Cole 04 February, 2020
#13
It's less of an issue on windows server 2016 than on windows server 2008.  It happens all the time on 2008, but not as often on 2016.

My workaround has worked for the most part on 2008 and we're in the process of moving all our users onto 2016.

The issue now is more a windows issue, where if the user connects a fresh RDP session and goes to print asap and it's less than 1 minute or so after the session started windows hasn't redirected all the printers yet, so it prints to the servers default printer.

But there's nothing that can be done about that, we've just told our users if you print right away after logging in it might not work.  I haven't heard any complaints since.
Mark Lee @Appeon 31 October, 2019
#12
Hi Eric,

Sorry for the late reply.
Unfortunately we can’t reproduce it on our side. 
We use the test cases of both ticket 1732 and ticket 1878 to verify it and we can change the redirected printer or server printer to print data in client and server side.
BTW, we use Windows 10 (version 1903) to remote to the Server Windows Server 2016.
 
1. Please can you check whether you the Printers is checked in the RemoteApp connect settings? (Comment 11)
2. Can you use the administrator account to login to the RemoteApp and try?
3. Kindly can you please provide another sample PB test case (with PBT/PBL) for us to reproduce it?

Regards,
Mark Lee
Mark Lee @Appeon 31 October, 2019
#11
RemoteApp printer settings
Mark Lee @Appeon 07 October, 2019
#10
Hi Eric,

Thanks for report the problem. We'll work on it and get back to you soon.
Thanks for your patience and understanding.

Regards,
Mark Lee
Chris Pollach @Appeon 04 October, 2019
#9
Hi Eric;

  Thank you for the update on your situation. Sorry that you are still having this issue! Sounds like either the RDT feature is interfering with the workaround or the newer MS-Windows O/S is (or both).

  I will now transfer this ticket over to the main Support / Engineering team to see if they have any updates to a newer workaround for W2016.

Regards ... Chris
Eric Cole 04 October, 2019
#8
Yes, still having the issue.  The issue isn't going to magically go away, I'm just hoping my workaround will be a fix for it.

Our current production environment is windows 2008, we've wanted to move to 2016 for awhile now, but this issue has kept us from moving.  You were able to fix this issue in all other cases with my previous tickets, but for whatever reason it still doesn't work when running the app as a remote app through remote desktop services, which is how all our users run it in production.  It also used to only be an issue on windows server 2016, but after I upgraded to PB 2019, it's now also an issue on 2008, which has increased the priority for us to find a fix.

The workaround has been deployed and it's working for some users but not all on windows server 2008.  It seems to work all the time on 2016, so we're transitioning some over to make sure.

And I used the ansi version and it worked:
FUNCTION Boolean GetDefaultPrinterA(REF String pszBuffer, REF Long pcchBuffer) library "winspool.drv" alias for "GetDefaultPrinterA;Ansi"
Chris Pollach @Appeon 04 October, 2019
#7
Hi Eric;

   I am following up on this ticket from Cedric. Are you still having this issue?

BTW: Since PB is now Unicode, please use the following external declaration for the "GetDefaultPrinter " command, as follows ...

FUNCTION boolean  GetDefaultPrinter ( Ref string pszBuffer, Ref ulong pcchBuffer ) Library "winspool.drv" Alias For "GetDefaultPrinterW"


Regards ... Chris
Eric Cole 26 September, 2019
#6
So now this is super weird.  I'm writing some code to try and work around this issue by calling the windows API function GetDefaultPrinterA.

So the first time I did it, it worked, called GetDefaultPrinterA, then called PrintSetPrinter.  Now the printer is set to the correct redirected default printer.

Here's the weird part, is now, even after killing my remote sessions and reconnecting, the default printer is correct, it's the redirected default printer.

The only way I'm able to reproduce again now is by these steps:
1. Run mstsc->click Show Options->Uncheck Printers on the Local Resources tab->connect
2. kill the session
3. Run mstsc again and check Printer on the Local Resources tab and connect
4. Now run the PB application through the remote app and try printing

Only then is it back to using the machines default printer instead of the local redirected one.

Now our users in our production environment never use mstsc.  So I'm moving forward with deploying this GetDefaultPrinterA/PrintSetPrinter fix when they log in and hoping it will be a workaround.
Eric Cole 26 September, 2019
#5
(In reply to Cedric Pernet from comment #4)
Hello Eric,
I'm sorry for the delayed update.
This case seems difficult to reproduce with the current details.

Are you using the PowerBuilder IDE on Windows Server 2008?

Could you please provide us with a reproducible test case in case you're
using the IDE outside Windows Server?

-Cedric
With the latest version of Powerbuilder it doesn't matter what version of windows you are on. It used to only be a windows server 2016 issue, but now it's happening on any OS. And I'm not running it through the IDE, it's being compiled and put on the server. The key to duplicate it is run it as a RemoteApp. So you have to setup Remote Desktop Services and then publish it as a remote app through that and then run it as a remote app. It's much easier to do that on windows server 2016 so I would recommend using it. Are you using a remote app? If not then that's why you can't reproduce it, it only happens when running it as a remote app. Best I can give you is a google search link as how to setup a remote app: https://newhelptech.wordpress.com/2017/07/23/step-by-step-how-to-deploy-remote-desktop-services-in-windows-server-2016/ Make sure you have Printers checked on the local devices and resources on the RDP connection so that it's redirecting local printers to the server when you connect. Then it's as simple as printing anything from the application that you ran as a RemoteApp. It will have the servers default printer selected instead of the local computer you are connecting to the server from.
cedric.pernet 26 September, 2019
#4
Hello Eric,
I'm sorry for the delayed update.
This case seems difficult to reproduce with the current details.

Are you using the PowerBuilder IDE on Windows Server 2008?

Could you please provide us with a reproducible test case in case you're using the IDE outside Windows Server?

-Cedric
Eric Cole 25 September, 2019
#3
Any chance I can get an update on this?

I updated to PB 2019 and now we're having this same issue on windows server 2008.  It was keeping us from updating to windows server 2016, now I have to go back to PB 2017 so we don't have this issue on our current production environment.
Eric Cole 10 September, 2019
#2
(In reply to Cedric Pernet from comment #1)
Hello Eric,
I'll be reproducing your issue and comparing it with the past cases that you
mention, I'll let you know any updates as soon as I can.

-Cedric
Any update on this? Were you able to reproduce?
cedric.pernet 06 August, 2019
#1
Hello Eric,
I'll be reproducing your issue and comparing it with the past cases that you mention, I'll let you know any updates as soon as I can.

-Cedric
Eric Cole 06 August, 2019
This is the same issue as Bug 1878 and 1732 except that it's only not working when running the application as a RemoteApp.

The weird thing is I remote in normally using the mstsc client and it works fine, default printer is the redirected local default printer, not the default printer of the server.

But if I publish it as a RemoteApp and connect through the server.address/RDWeb, it doesn't use the redirected default printer, it's back to using the default printer of the machine.
OS:
Windows Server 2016
Platform:
64-bit
Database Type:
Microsoft SQL Server
Database Version: