Bug 6261

Client redirected printer is not showing as default in Windows 2016 what Appeon claimed get fixed in 02 April, 2021

Vipin Dwivedi
11 March, 2021
Product: PowerBuilder Category: PowerScript
Version: 2017 R3 Build: 1858, 1880 and 1915
Classification: Publishing: Public
Priority: P3
Status: Verifying Reason:
Communication Status: Waiting for Appeon
Mark Lee @Appeon 02 April, 2021
#23
Hello Vipin,

Since the IT apartment still can't provide such an environment for us, it is just our speculation of this issue and we are not sure about it so can you help to do the test?  
 
The underlying logic of the PowerBuilder Powerscript function PrintGetPrinter() will call the Microsoft OS API GetDefaultPrinterW() method. However, to integrate this method into PB requires encapsulation, etc. and also some effective judgment to some code logic so these might cause the differences. 
 
After we have the environment on our side, we will verify it and keep you updated.
 
Regards,
Mark Lee
Vipin Dwivedi 31 March, 2021
#22
(In reply to Mark Lee @Appeon from comment #21)
Hello Vipin,

We discussed internally and need your help to do the test this way, launch
your program via Remote App (Microsoft Tool), do not perform the print
action right away, wait for about 1 minute and then print to see if it gets
the client default printer. 
 
If yes, it seems that this is more like a Windows issue because if the user
connects to a fresh RDP session (or Remote App), it might take some time for
the Windows to start and redirect all the printers, if you print right after
the app is launched, it mightn't redirect all printers and will get the
server default printer. 

Regards,
Mark Lee
If that is the case then how Microsoft OS API GetDefaultPrinterW() method is pulling the correct default client printer but PowerBuilder Powerscript function PrintGetPrinter() does not? Which OS function exactly this Powerscript call? we should try calling that OS function explicitly and compare with GetDefaultPrinterW(). What's your thought? Vipin
Mark Lee @Appeon 31 March, 2021
#21
Hello Vipin,

We discussed internally and need your help to do the test this way, launch your program via Remote App (Microsoft Tool), do not perform the print action right away, wait for about 1 minute and then print to see if it gets the client default printer. 
 
If yes, it seems that this is more like a Windows issue because if the user connects to a fresh RDP session (or Remote App), it might take some time for the Windows to start and redirect all the printers, if you print right after the app is launched, it mightn't redirect all printers and will get the server default printer. 

Regards,
Mark Lee
Mark Lee @Appeon 30 March, 2021
#20
Hello Vipin,

Sorry to let you know that we are not familiar with the Remote App (Microsoft Tool) and we still need our IT department to set up this Remote App on Windows 2016 for us to test. So I can’t reply to you about this issue right now.
After the environment is configured, we will verify it and keep you updated.

Regards,
Mark Lee
Vipin Dwivedi 29 March, 2021
#19
(In reply to Vipin Dwivedi from comment #18)
(In reply to Mark Lee @Appeon from comment #17)
Hello Vipin,

Sorry, I need to reconfirm this issue with you.

1. I thought Remote App (Microsoft Tool) and RDP (mstsc) have the same logic
for remote connection but now from what you told us, it seems that they have
different logics.
We have not tested this issue with the Remote App (Microsoft Tool) yet, we
will try to configure it to verify the issue.


2. Just to get the current issue straight, hope you can help confirm the
following:
a) With PB 2017 1915, running the application through RDP (mstsc) on windows
2016 has no problem. Is this correct?
b) With PB 2017 1915, running the application through Remote APP (Microsoft
tool) on windows 2016, sometimes it happens sometimes it does not. Is this
correct?

Regards,
Mark Lee
With PB 2017 1915, running the application through RDP (mstsc) on windows
2016 has no problem. Is this correct?  I am not sure but looks okay. 

With PB 2017 1915, running the application through Remote APP (Microsoft
tool) on windows 2016, sometimes it happens sometimes it does not. Is this
correct? Yes
Hello Mark, Any luck? Vipin
Vipin Dwivedi 24 March, 2021
#18
(In reply to Mark Lee @Appeon from comment #17)
Hello Vipin,

Sorry, I need to reconfirm this issue with you.

1. I thought Remote App (Microsoft Tool) and RDP (mstsc) have the same logic
for remote connection but now from what you told us, it seems that they have
different logics.
We have not tested this issue with the Remote App (Microsoft Tool) yet, we
will try to configure it to verify the issue.


2. Just to get the current issue straight, hope you can help confirm the
following:
a) With PB 2017 1915, running the application through RDP (mstsc) on windows
2016 has no problem. Is this correct?
b) With PB 2017 1915, running the application through Remote APP (Microsoft
tool) on windows 2016, sometimes it happens sometimes it does not. Is this
correct?

Regards,
Mark Lee
With PB 2017 1915, running the application through RDP (mstsc) on windows
2016 has no problem. Is this correct?  I am not sure but looks okay. 

With PB 2017 1915, running the application through Remote APP (Microsoft
tool) on windows 2016, sometimes it happens sometimes it does not. Is this
correct? Yes
Mark Lee @Appeon 24 March, 2021
#17
Hello Vipin,

Sorry, I need to reconfirm this issue with you.

1. I thought Remote App (Microsoft Tool) and RDP (mstsc) have the same logic for remote connection but now from what you told us, it seems that they have different logics.
We have not tested this issue with the Remote App (Microsoft Tool) yet, we will try to configure it to verify the issue.


2. Just to get the current issue straight, hope you can help confirm the following:
a) With PB 2017 1915, running the application through RDP (mstsc) on windows 2016 has no problem. Is this correct?
b) With PB 2017 1915, running the application through Remote APP (Microsoft tool) on windows 2016, sometimes it happens sometimes it does not. Is this correct?

Regards,
Mark Lee
Vipin Dwivedi 23 March, 2021
#16
I think there is some confusion as I was just stating we have 2 platforms, 1 with an issue and 1 without that publish the same application.

Microsoft RemoteApp is where the problem exists. When working with Microsoft they are stating it's working as designed with the OS change they introduced.  We use a external facing portal to publish our application and is how the customers access the product from remote clients. 

Citrix, when this issue was identified, created a patch (Hotfix CU5 for LTSR 7.15) to adjust how applications published through Citrix work with the change Microsoft Introduced.

Let me know if you have any question.
Mark Lee @Appeon 22 March, 2021
#15
Hello Vipin,

Thanks for your feedback.
1. I'm a little confused by your description. Do you mean that for your application exposed through Remote APP (Microsoft tool) on Windows Server 2016 Citrix machine with version 1915, sometimes the issue happens sometimes it does not?
If this is the case, would it work fine if your application is exposed through Remote APP (Microsoft tool) on a Windows Server 2016 VM instead of a Citrix machine with version 1915.
 
So far I haven't had this issue happen on Windows Server 2016 VM in my test.
 
2. Based on what you said, can it be considered that it would have the issue if Citrix has the patch added due to change in Windows 2016 default printer registry path change? If so, would it be possible that you share the solution with us so that when other customers run into a similar issue we can help them out? Thanks in advance!

Regards,
Mark Lee
Vipin Dwivedi 17 March, 2021
#14
(In reply to Vipin Dwivedi from comment #13)
(In reply to Vipin Dwivedi from comment #12)
(In reply to Mark Lee @Appeon from comment #11)
Hello Vipin,

Thanks for your feedback and for providing the screenshots.
 
Do you mean the second time you run the code to get the printer, it picked
the correct printer?
 
What the difference between the first time and the second time you run the
code to get the printer?
 
If the result from the second run is correct then this issue is not related
to PowerBuilder. For a Citrix environment machine, it would need to take
some time to get the default mapping printer. You may refer to Roland
Smith's conclusion in the link below:
https://community.appeon.com/index.php/qna/q-a/windows-server-2016-and-
default-client-printer

Regards,
Mark Lee
Then how does OS function provides the correct information if this is an Citrix issue?
Answer to your other question - Yes, Second or third time it pick the correct printer. There is no difference in the code, since I wrote these code during startup the application. I have to restart the app each time. I will try to put somewhere in the program and will try to call them multiple time and see when it starts showing the correct printer.
I tried putting same code on one program which I can open multiple times and added on postopen event. Each time when I am opening the program it is taking server default printer while OS function GetDefaultPrinter() still pulling my local default printer. This goes away if I log off and and login back to the portal and re-run the application. I meant to say it is not working all the time. Other thing I would like to share that... we are exposing application two ways... Citrix way and Remote App (Microsoft Tool) way. It is working fine when running application through Citrix on windows 2016, even with 1858 version and the reason for working is CITRIX added some patch due to change in Windows 2016 default printer registry path change so because CITIRIX took care of it, we are having no issue with it. Application exposed through Remote APP (Microsoft tool) are having problem with version 1858. With version 1915, sometime it happens sometime it does not... so on and off. Let me know if any question. Vipin
Vipin Dwivedi 17 March, 2021
#13
(In reply to Vipin Dwivedi from comment #12)
(In reply to Mark Lee @Appeon from comment #11)
Hello Vipin,

Thanks for your feedback and for providing the screenshots.
 
Do you mean the second time you run the code to get the printer, it picked
the correct printer?
 
What the difference between the first time and the second time you run the
code to get the printer?
 
If the result from the second run is correct then this issue is not related
to PowerBuilder. For a Citrix environment machine, it would need to take
some time to get the default mapping printer. You may refer to Roland
Smith's conclusion in the link below:
https://community.appeon.com/index.php/qna/q-a/windows-server-2016-and-
default-client-printer

Regards,
Mark Lee
Then how does OS function provides the correct information if this is an Citrix issue?
Answer to your other question - Yes, Second or third time it pick the correct printer. There is no difference in the code, since I wrote these code during startup the application. I have to restart the app each time. I will try to put somewhere in the program and will try to call them multiple time and see when it starts showing the correct printer.
Vipin Dwivedi 17 March, 2021
#12
(In reply to Mark Lee @Appeon from comment #11)
Hello Vipin,

Thanks for your feedback and for providing the screenshots.
 
Do you mean the second time you run the code to get the printer, it picked
the correct printer?
 
What the difference between the first time and the second time you run the
code to get the printer?
 
If the result from the second run is correct then this issue is not related
to PowerBuilder. For a Citrix environment machine, it would need to take
some time to get the default mapping printer. You may refer to Roland
Smith's conclusion in the link below:
https://community.appeon.com/index.php/qna/q-a/windows-server-2016-and-
default-client-printer

Regards,
Mark Lee
Then how does OS function provides the correct information if this is an Citrix issue?
Mark Lee @Appeon 17 March, 2021
#11
Hello Vipin,

Thanks for your feedback and for providing the screenshots.
 
Do you mean the second time you run the code to get the printer, it picked the correct printer?
 
What the difference between the first time and the second time you run the code to get the printer?
 
If the result from the second run is correct then this issue is not related to PowerBuilder. For a Citrix environment machine, it would need to take some time to get the default mapping printer. You may refer to Roland Smith's conclusion in the link below:
https://community.appeon.com/index.php/qna/q-a/windows-server-2016-and-default-client-printer

Regards,
Mark Lee
Vipin Dwivedi 17 March, 2021
#10
ScreenShot.zip (92KB)

(In reply to Mark Lee @Appeon from comment #9)
Hello Vipin,

Thanks for your feedback.
Unfortunately no. We asked for the environment so that our development team
can use it to debug the issue.
 
So the video won't be of much help to the development team.

Regards,
Mark Lee
I have attached zip file contains two screen shot for same code. When running first time it is showing "Server Default Printer" which is Newton Pick, when running second time (same application) it has picked the "Client default printer" which is "SecurePrint on FDXX90PRNT4 (redirected)". In both the screen shot, the OS function always returns the client default printer ("Redirected one"). I hope this help. I am still trying to figure out how to send you the Remote link. Vipin
Mark Lee @Appeon 16 March, 2021
#9
Hello Vipin,

Thanks for your feedback.
Unfortunately no. We asked for the environment so that our development team can use it to debug the issue.
 
So the video won't be of much help to the development team.

Regards,
Mark Lee
Vipin Dwivedi 16 March, 2021
#8
(In reply to Mark Lee @Appeon from comment #7)
Hello Vipin,

Thanks for your feedback.
 
So sorry that due to the time difference between our time zones, it's hard
to arrange this meeting.
 
We suggest that you provide a remote VM machine with the app compiled by PB
2017 R3 1915 that can reproduce the issue for us to further analyze it.
Thanks!

Regards,
Mark Lee
Will that be fine if send you a video?
Mark Lee @Appeon 16 March, 2021
#7
Hello Vipin,

Thanks for your feedback.
 
So sorry that due to the time difference between our time zones, it's hard to arrange this meeting.
 
We suggest that you provide a remote VM machine with the app compiled by PB 2017 R3 1915 that can reproduce the issue for us to further analyze it. Thanks!

Regards,
Mark Lee
Vipin Dwivedi 15 March, 2021
#6
(In reply to Mark Lee @Appeon from comment #5)
Hi Vipin,

Thanks for your feedback.

We would recommend you to make the remote session during our working time
which is 9:00 am – 5:00 pm (we are in UTC+8 ) thus we can get immediate help
from other teams if necessary.
Please let us know when you are available for the meeting.

BTW, what TeamViewer version are you using? 

Regards,
Mark Lee
Hello Mark, I am running TeamViewer-14.0.12762. I work in CST timezone, located near Chicago. My working hour is 9 AM to 4 PM.
Mark Lee @Appeon 15 March, 2021
#5
Hi Vipin,

Thanks for your feedback.

We would recommend you to make the remote session during our working time which is 9:00 am – 5:00 pm (we are in UTC+8 ) thus we can get immediate help from other teams if necessary.
Please let us know when you are available for the meeting.

BTW, what TeamViewer version are you using? 

Regards,
Mark Lee
Vipin Dwivedi 12 March, 2021
#4
(In reply to Mark Lee @Appeon from comment #3)
Hi Vipin,
 
Did you verify with PB 2017 R3 Build 1915?
According to our latest verification, this issue has been fixed in the code
of this version.
 
If you have verified this version, did you use the updated runtime
corresponding to this 1915 version?
If you have verified PB 2017 R3 Build 1915 and found it has the same issue,
it's suggested to have a meeting to discuss it.
 
Let's schedule a remote session to debug it. 
We would recommend you to make the remote session during our working time
which is 9:00 ~ 17:00 (we are in UTC+8 ) thus we can get immediate help from
other teams if necessary. 
Please let us know when you can make the session and which tool you'd like
to use for this session (TeamViewer or GoToMeeting).
 
 
Best regards,
Mark Lee
Yes Mark, I did verify with 1880 and 1915 PB 2017-R3 and below is my observation. This is what I replied to Chris in Appeon Group. https://community.appeon.com/index.php/qna/q-a/issue-with-print-dialogbox-in-window-2016-not-showing-correct-default-printer Chris/Armeen, I download MR 1915 and re-build the Executable and deployed with 1915 PB runtime DLL. I see two observation here when running application through RDP 1 - When I call PB in-built function PrintGetPrinter() it returns local printer of server while GetDefaultPrinter() OS function (from library winspool.drv) gives redirect printer which is default to my local machine. so PrintGetPrinter() does not return the correct default printer therefore it highlight the non-default printer when print dialog box open. 2 - I put both function call at two three place.... so that I can see if changes at any moment. so I observed that it returns different default printer during first 2 calls PrintGetPrinter() - returns local to server default printer GetDefaultPrinter() OS function - returns redirect printer (local to my machine server) next call starts giving me same default printer from both function which is redirect printer (my local default). Looks like we still have issue in MR 1915. Kindly suggest. Let me know if you need any other detail. Let me know when you want me to do this session. I can do this with TeamViewer... Vipin
Mark Lee @Appeon 12 March, 2021
#3
Hi Vipin,
 
Did you verify with PB 2017 R3 Build 1915?
According to our latest verification, this issue has been fixed in the code of this version.
 
If you have verified this version, did you use the updated runtime corresponding to this 1915 version?
If you have verified PB 2017 R3 Build 1915 and found it has the same issue, it's suggested to have a meeting to discuss it.
 
Let's schedule a remote session to debug it. 
We would recommend you to make the remote session during our working time which is 9:00 ~ 17:00 (we are in UTC+8 ) thus we can get immediate help from other teams if necessary. 
Please let us know when you can make the session and which tool you'd like to use for this session (TeamViewer or GoToMeeting).
 
 
Best regards,
Mark Lee
Mark Lee @Appeon 11 March, 2021
#2
Hi Vipin,

Thanks for reporting this problem and providing the test case.
I can reproduce it on our side in PB 2017 1858.  
I checked with the development team and found that this issue hasn't been completely fixed in PB 2017, we only fixed part of it.
So you will still encounter the issue that it fails to get the Client redirected printer through RDP on Windows Server 2016.
 
According to my testing, using the same code in PB 2019 R2 2353 & R3 2670 don't have this issue.
So I suggest you upgrade your PB and see if the issue is gone.
 
If the issue still exists after the upgrade, we can set up a meeting to further check the issue.

Please feel free to let us know the results. Thanks.

Regards,
Mark Lee
Vipin Dwivedi 11 March, 2021
#1
n_vipin.sru (3KB)

*Phenomenon: Application running through RDP is not populating Client redirected Default printer  (My local default printer) in Print Dialog box or when call PrintGetPrinter(). It does not work in all three MR 1858, 1880,1915 version. I get correct default client redirected printer (My local default printer) when call OS function GetDefaultPrinter from Library "winspool.drv" Alias For "GetDefaultPrinterW"


*Reproduce Steps: I have attached the nvo object which has simple code. You need to call this nvo.Of_Init() and this will show you printer through messagebox. Make sure to run in windows 2016 server through RDP.


Remarks:
OS:
Windows Server 2016
Platform:
32-bit
Database Type:
SAP SQL Anywhere
Database Version:
17.0.10 Build 5923