Print Page | Close Window

No PDF found

Printed From: www.exp-systems.com
Category: PDF reDirect
Forum Name: Programming
Forum Discription: VBA and Batch Tools to control PDF reDirect Pro
URL: http://www.exp-systems.com/Forum_exp/forum_posts.asp?TID=479
Printed Date: 22 Nov 24 at 6:17PM


Topic: No PDF found
Posted By: esiesi
Subject: No PDF found
Date Posted: 24 Mar 09 at 3:18PM

We have written a dot net console application which spools out reports out of MS-Access database.

This utility runs well on my desktop and on our build server. It successfully generates the PDF documents to the file system according to a configuration for each report.

My desktop profile is windows XP professional with service pack 3 -- 3.19 GHz with 1.50GB of RAM. The build server profile is windows server 2003 service pack 2 -- 1.80GHz with 512 MB of RAM running on vmware.

PDF redirect was installed as Administrator on both of these machines and our utility runs as a specific user. PDF reDirect Pro v2 (Install_PDFR_Pro_v228)

--- The problem

Utility is installed on our test server -- windows server 2003 service pack 2 -- 1.80GHz with 1.47GB RAM -- same steps followed for installation -- everything installed as Administrator and specific user runs our utility.

On this particular server when our utility runs, we can see the document showing up in the printer spool for PDF redirect Pro V2 and we can see it showing up in the Merge List on the PDF redirect Pro v2 console but the PDF document does not get generated on the file system in the folder where it should appear -- This behavior is the same as the build box at runtime with the exception of the PDF document not being where it is supposed to be.

I have searched all drives for any PDF document and was not able to locate any of the PDF documents we where expecting -- thought perhaps PDF redirect has spooled the report elsewhere.

I have checked the contents of 'Documents and Settings' for the specific user under Application Data for PDF redirect. I have compared these files to those on our build box and the behavior is very much consistent, all the same files exists including the thumbnails for the reports that were spooled but again no PDF document found in the requested directory.

I have walked through processMON and fileMON to verify registry keys and DLL dependencies between our build server (where it works) and this test server (where it does not work) and found no differences.

I can open MS-Access and spool a PDF document out manually to the file system using PDF redirect (same user that runs the console application). The document is seen going through the PDF redirect Pro V2 queue as well as the merge list and finally shows up in the proper directory.

No errors were found in the Bug_Reports folder after debugging was turned on from the PDF reDirect Pro console.  The temporary pdf document exists in the Temp folder along with the thumbnail jpeg under 'Document and Settings'.  However the PDF does not show up in the final directory.
 
We are thinking permissions issue but are not able to figure it out.  We have granted full access to this user on our utiltity and the target directory where we expect to see the PDF but we are still not seeing the final PDF document.  When we grant Administrator to this user, the PDF does generate in the proper directory.
 
In our production environment we cannot grant Administrator to any console application
 
Any thoughts?



Replies:
Posted By: Michel_K17
Date Posted: 24 Mar 09 at 8:23PM
Hello,
 
   I am sorry to hear of the problem: hopefully we can get the problem resolved.

   I do know that the installation process that must be followed is different on a server than on a regular PC, particularly if your user is using a Terminal Server connection rather than logging on the physical machine. See below for the installation instructions.

   Typically, if the program is not installed correctly, then Windows is not clear as to which user generated the print request, and the printing process which begins life as a "System" process does not transition down to the user's account, stays in the System realm, and may not, for example, have the rights necessary to write to a shared drive for example.

   The flaw in my example above is that you said that it works fine when you do it manually.

   My recommendation for now: please do a remove, and re-install using the procedure given below. If that still does not work, please let me know, and I'll provide with a special version of the port monitor that logs what is going on. With that, we can determine (hopefully) the root cause.

   There is an error log integrated with PDF reDirect >> Preferences >> General, but that one only records what is going after the Port Monitor has passed on the stick to the convertor and the user interface.

   I hope that helps, and that we find a solution.
 
   Best regards,
 
Michel Korwin-Szymanowski
EXP Systems LLC
www.exp-systems.com
--------------------------
Installing programs on a Windows Terminal or Citrix Server
 

    How PDF reDirect Pro is installed on a server makes a difference. If you simply run the installation program, then the program will not support the remote desktop clients. As explained in the Windows Server documentation, you need to install programs either via the Add/Remove Control Panel, or via the command line with the right command to ensure that the program will support multiple clients.

   Check the documentation that came with your Windows Server software, particularly the topic on setting up Terminal Services. Here is a partial reprint:

 - You should install programs on a terminal server before giving clients access to the terminal server. Doing so ensures that you can test each program before clients access it, and can reduce the time it takes to perform program tuning.

 - Use either of the following methods to install programs for multisession Terminal Server access:

 - Use Add or Remove Programs in Control Panel (recommended).

 - Use the change user command at the command prompt before and after installing the program.

 - One of the primary functions of the change user command is to ensure that program files are installed to the systemroot rather than the windows subdirectory of the user's home directory (%homepath%\windows). This makes the programs available for multisession access.

 - Before the program is installed, type change user /install at the command prompt to place the system in install mode and turn off .ini file mapping. The system then records how the setup APIs initially install the program.

 - After the program is installed, type change user /execute at the command prompt to return the system to execute mode, restore .ini file mapping, and redirect user-specific data to the user's home directory.

 - When the user opens the program, user-specific registry setting files (.ini, .dll, .ocx, and so on) are propagated as needed to the user's home directory.

 - Add or Remove Programs, which runs the change user command, is the preferred method of installing programs. Enter change user at the command prompt only when you install a program by another method and want to ensure multisession access. For example, when Internet Explorer prompts you to install an add-on program, use change user at the command prompt to ensure that the program is installed for multisession access.


-------------
Michel Korwin-Szymanowski
EXP Systems LLC


Posted By: esiesi
Date Posted: 24 Mar 09 at 10:34PM
Thank you Michel for your reply,
 
to give you a little more info on the runtime environment.  Our utility is controlled by job scheduling software.  All this software does is simply pass the command line that you would normally execute on the command line and allows us to integrate this job into bigger job plans and other back office tasks.  There is only one user used to interface anyone of the utilities we have running on this particualr class of servers.  We can elimiate the job control software causing us any issues in this case as the problem still exist from the command line logged in as that user.
 
I have followed your steps via Add/Remove Programs and i encounter errors during the install if it is not performed as Administrator.  I have successfully un-installed, rebooted, re-installed and rebooted as Administrator.  I have given full permissions to the execution user to be able to manage and print documents against the PDF reDriect Pro v2 default  printer.  I also have full control on the directory where the PDF documents are to be printed.  Full control on the runtime utility for this user and all dependent DLLs.
 
We have used the debugging/tracing feature and no errors appear in this file.  Also no errors are reported at runtime from the utility.
 
We have noticed that we can only print PDF documents if the execution user is Administrator.   No PDF documents show up even if the PowerUser perms are granted to the user.
 
Only one user is used to execute our utility.  Although this is running on a windows server, no users interact directly with the utility.  All executions are control by a job control software.  The same behavior takes place whether we use the job control software or not.
 
On our build server the user executing the utility has Administrator perms and as mentioned the PDF do get created onto the file system.
 
As mentioned previously, the strange thing is that when logged in to the server as the same user that would run the utility i am able to go into ms-access and print the pdf document.  However the same user running the executable from the command line and no PDF appear in the same directory.
 
 


Posted By: Michel_K17
Date Posted: 24 Mar 09 at 11:05PM
Hi,

   Thank you for your detailed descriptions and for trying the re-installation: it saves a lot of time.

   As best as I can tell, from what you are describing, it really does sound like the Port Monitor does not transition from the system to the user's process.

   I'll send you by e-mail a special version of the Port Monitor that will log what is going on. hopefully that will tell us where the problem is.

   Cheers!

 


-------------
Michel Korwin-Szymanowski
EXP Systems LLC



Print Page | Close Window