Terminal Server Woes

[millap]

Hi all, I've attempted to install PrimoPDF on three of my Citrix server's. Everything at the local console end is fine - eg if I create a test file it prints and generates a pdf file correctly.

If I try the same thing through either Citrix Program Neighbourhood or Terminal Services client it generates a blank file.

I've looked through the rest of the Forum for any clues and have tried the suggested fixes (ie reinstalling Ghostscript, etc) but still nothing.

Any help would be greatly appreciated.
Thanks
millap

[Douglas Saltsman]

The reason this happens is this:

When you use terminal services it runs the OS under a user account instead of a system account. This means that all the environment variables will point back to directories under the user directory tree instead of the OS (it points to C:\Docs and Settings\User\windows instead of C:\windows)

Check my answer in this thread and apply them to yourself as it may take care of the problem. Of course, try the new installer as your first step as it would circumvent any reg access errors.

http://forums.primopdf.com/showthread.php?s=&threadid=9

[David Briscoe]

Douglas,

I too have installed the software on a Citrix Server and even after taking all the steps you have suggested on the forums I am still unable to produce the correct output from a client session. Do you have any other suggestions or are there any plans to make the software Citrix friendly in the near future.

Regards,

David.

[millap]

Hiya Douglas,

Also tried the suggested thread information and I'm still getting the same results. The new installer idea didn't work either which is a shame. It would have been a nice easy fix. Pity things in TS aren't ever simple

millap

[brad]

****o Everyone,

I think that I may be having the same problem as the rest of you. When I try to print through the Citrix environment I get a blank document.

I've done a lot of digging around. This is what I have found. Hopefully it will help us find a solution.

When a document is printed using PrimoPDF a postscript file is created in the windows temp folder. The file is prefixed with reda. In Citrix the file size is 0 bytes. This is why the PDF file generated is blank. I tried using a different PS print driver in the PrimoPDF printer settings with no change in behavior. I then tried unchecking the "run as user" check box, this was a tip from our tech support guys. Doing this created a reda file in the windows temp directory with a file size greater than 0 bytes. But, unfortunatly the primorun.exe application that is exec by PrimoPDF locked up and I was not able to create the PDF document.

[Douglas Saltsman]

I think Brad might be on to an answer.

With "run as user" unchecked, it seems the temp ps file is properly created which mean that the printer is running under the system account. Unfortunately with this value unchecked, when primomon creates the primo process, it doesn't have permissions to access the temp file that was created.

With it unchecked, the printer gets loaded under the context of the person that is TSing in. This prevents it from properly creating the temp file in the first place.


What might work:

Try right-clicking the primopdf printer and choosing the security tab. Add the 'everyone' group (for testing) and also choose the sharing tab and share the printer.

[millap]

Douglas, I've tried adding the everyone group, even giving creator/owner full rights to PrimoPDF still brings up a blank PDF file.

millap

[brad]

Is there any way to get the printer to print to the user account buffer instead of the system account buffer?

[Douglas Saltsman]

Douglas, I've tried adding the everyone group, even giving creator/owner full rights to PrimoPDF still brings up a blank PDF file.

millap


What I've found:

There's no way it's going to happen on the Citrix servers. There's just too many system elements that are taken out of play. :(

However, for the terminal service people. One thing I recommend doing would be to monitor the primorun.exe process using filemon from www.sysinternals.com This will allow you to see all file accesses performed by the redirection app that we use. It would be here you see a failure for file access and you would then be able to change the permissions on said file.

[David Briscoe]

Just to let you know that if I uncheck the "Run As User" box within port configuration from a Citrix client session I am able to generate a PDF file - a PrimoPDF Windows pops up on the Administrators desktop and I can do it that way. Obviously this is not acceptable but it may give you some further idea of how we can resolve the problems.

[MichaelAllen]

I'm running this under Win2000 Terminal Services and have this blank page problem as well. After reading all the info and trying the various suggestions, the problem still exists. I have some additional information that may tweak somone's mind:

I *can* also run it without "run as user" checked, and get it to pop up on the Admin screen, and get a PDF. Also, it runs just fine under the Admin account. But, running as another user (even with admin rights) I still get the blank page problem with a file of 722 bytes.

After turning on the "debug" information and examining the output, I have noticed that PrimoMon seems to be unaware that a required process is running. Here is the text from the debug log:

-----start log paste-----
PrimoMon WritePort: about to write 4096 bytes to port.
PrimoMon check_process: process isn't running.
PrimoMon check_process: flushing child stdin to unblock WriteThread.
::
::
::
::
PrimoMon WritePort: Process not running. Returning TRUE.
Ignoring 4096 bytes

PrimoMon Cancelling print job
PrimoMon EndDocPort: starting
PrimoMon EndDocPort: process finished after 0 seconds

PrimoMon EndDocPort: 0 bytes written to printer
PrimoMon EndDocPort: ending
-----end log paste-----

So, I think the question is: How can we make this thing aware that the process (whatever it is) is actually running (and can be checked for).

Thoughts?

Cheers,
Mike

[Francois Gand]

****o all,


Francois from Toronto....


I just timed out after writing a 1 hour memo to you guys and I lost everything....

So.... I will try to make this one short....


If you install PRIMOPDF on the client-side as a default printer driver it MAY show in an end-user's remote session if checked under the Remote Desktop Connection's Local Resources.

If so, then the PDF creation is beautiful and blazing fast.

The only issue that we are having right now is that NOT ALL workstations (98s and XP Pros) are showing their local PRIMOPDFs (local default printer driver) inside of a TS session.... and we have absolutely no clue why.

But when it does ..... it is PERFECT.

It works great and fast.

I have got to go and perhaps will find the spirit to re-write again what I wrote earlier in great depth....

Will keep an eye here...

Take care.

Francois

[Francois Gand]

****o all....


I decided to get back in here and give you a few more thoughts on the current TS situation.

It seems -- based on a full day of research and the MSKB and MSDN inputs -- that Terminal Services MAY have a "hidden cache" of some sort when it comes down to showing a "local default printer driver" inside of a TS session.

When switching diverse local "primary default printer driver" (s), TS sessions will not always show the REAL -- CURRENT -- default printer driver from the end-user logging into a TS server.... even if the PRINTERS option is indeed c heck in the end-user's LOCAL DEVICES in the Remote Desktop Software (i.e. TS client).

One KB article referred to waiting at least 60 seconds when switching default printer drivers AND doing that while logged in into a TS session AND performing manually a change in the printer driver's DEVICE SETTINGS and again doing another change in any other tabs of the printer driver properties.


To me this is absolutely insane.... yet not surprising from Microsoft per se...

Anyway, I have tried that numerous times and did NOT succeed.


As for right now, PRIMOPDF has -- successfully -- been able to print in a TS environment (with a completely default installation) -- ONLY -- on 1 of our XP Pro end-user station set with PRIMOPDF as the local primary default printer driver (loaded into any TS sessions initiated from that specific XP Pro box...))......

Unfortunately, other XP Pro machines AND 98 workstations have been completely unsuccessful at showing PRIMOPDF as the actual default printer driver in their own TS sessions.

Once again, we have no clue why.... (and we are a pretty heavy TS provider for years now...)


Any input from you guys would be great.

:-)

Francois / Toronto

[johnlkerr]

Hi All

I have installed Primopdf on a 2003 term server and I am not having the blank output probs described above, but when I print to the primopdf printer from within a TS session the output dialog appears on the console ??

Any suggestions ??

I have tried installing the printer on the client (as suggested by Francois) but TS refuses to install this printer when I log in (I think this is because it does not consider the primo port a local port ??)

Cheers
John

[TeknoMusicMan]

http://forums.primopdf.com/showpost.php?p=302&postcount=13
As for right now, PRIMOPDF has -- successfully -- been able to print in a TS environment (with a completely default installation) -- ONLY -- on 1 of our XP Pro end-user station set with PRIMOPDF as the local primary default printer driver (loaded into any TS sessions initiated from that specific XP Pro box...))......

I'm having the exact same problem. Only the first workstation we installed PrimoPDF on is working while connected to our Win2003 server TS session.

I'm not sure why but all three printers installed locally on that workstation show up when its connected to a TS session. All other workstations just seem to show their Default printers.

If anyone could shed some light onto this issue i'd appreciate it.

[darmitage]

Take a look at this...

Printers That Use Ports That Do Not Begin With COM, LPT, or USB Are Not Redirected in a Remote Desktop or Terminal Services Session (http://support.microsoft.com/default.aspx?scid=kb;en-us;q302361)

It instructs you to modify your local registry to tell TS to include non-standard ports.

I also found it useful to delete any existing keys (not values though) under HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDR. The next time you connect to the Terminal Server it will repopulate with all the printers it knows how to handle.

I don't remember exactly, but I think it also helped to set the PrimoPDF printer as your local default, for at least the first time you connect to the server.

Hope this helps.

[TeknoMusicMan]

That did it. Thanks man

[VictorE]

no dice for me. i added the value to my client, rebooted the client, and connected to my metaframe server. when i printed to the primopdf printer, i got a blank page. i did not see any new values in that key after i logged back onto my metaframe server.