Free PDF creation for Win2000/XP users delivered via ZENworks for Desktops

0 Likes

This Tip is for Novell Customers using a ZENworks for Desktops environment with Windows 2000 and Windows XP workstations.



Problem:



How to give users of Microsoft Windows 2000 and Windows XP the ability to create PDF documents at zero cost using open source software and distribute the solution via ZENworks!




Solution:



There are many solutions available that allow users to create PDF documents, but very few that do not involve considerable cost, or involve transferring documents to a central location to be converted into PDF documents.



This is how you can do it for ZERO $$$ using open source software, and utilize ZENworks for Desktops to distribute without requiring the users to have administrative rights to their workstations.



Because the MSI supplied by the author creates multiple threads during the install, the PDF application installation fails to create the required virtual printer when delivered via ZFD with elevated installation rights. To get around this problem, you need to use the attached InstallPrinter.exe (compiled directly from the PDF Creator author's source code) and push this as a second application in an application chain, after the author-supplied MSI has been installed. Once the InstallPrinter program has been executed on the target workstation, the PDFCreator application installation will be 'complete', allowing users to create PDFs from most Windows applications (including Microsoft Word).



  1. Download the PDFCreator application.




  • From this web page, choose to download the file: zPDFCreator-0_9_3-AD_DeploymentPackage-WithoutToolbar.msi


  • Create a ZFD application object to deliver the PDF Creator MSI to the target workstations. Make sure that you choose the install option 'unsecure system user'. This will provide the required elevated installation rights.


  • Create a second application object to deliver the InstallPrinter.exe (available below) with the following installation parameters:


    InstallPrinter.exe /Install /LogPath"C:\Program Files\PDFCreator" /AppDir"C:\Program Files\PDFCreator"


  • Configure this application to be delivered AFTER the PDFCreator main application has been installed, and again make sure that you choose the install option 'unsecure system user'.


NOTES: To uninstall the PDFCreator application from a workstation you must use an account that that has administrative rights to the workstation.

Labels:

How To-Best Practice
Comment List
Parents
  • Why are you using unsecure system user for this procedure?

    The first part of the install should be a .msi application object and .msi installations are automatically performed as the system user, except for "Current User" parts of the install. When a .msi application object installation runs, you will normally see at least 2 instances of msiexec.exe running in the task manager. One runs as system, the other runs as the user logged into the computer. If the .msi install itself is created properly, it should install as the system user and then register the printer components for the logged in user. Unfortunately, few .msi packages are created properly, which makes our job much more difficult.

    For the second part of the install, if you run as unsecure system, won't the same problem exist as the original install, where the printer object will be installed for the system user rather than the logged on user?

    Also, unless user interaction is required, IMO using unsecure system user is a bad idea, use secure system user instead.

    Note: These are just observations, I have not tested this procedure myself.
Comment
  • Why are you using unsecure system user for this procedure?

    The first part of the install should be a .msi application object and .msi installations are automatically performed as the system user, except for "Current User" parts of the install. When a .msi application object installation runs, you will normally see at least 2 instances of msiexec.exe running in the task manager. One runs as system, the other runs as the user logged into the computer. If the .msi install itself is created properly, it should install as the system user and then register the printer components for the logged in user. Unfortunately, few .msi packages are created properly, which makes our job much more difficult.

    For the second part of the install, if you run as unsecure system, won't the same problem exist as the original install, where the printer object will be installed for the system user rather than the logged on user?

    Also, unless user interaction is required, IMO using unsecure system user is a bad idea, use secure system user instead.

    Note: These are just observations, I have not tested this procedure myself.
Children
Related
Recommended