我有一个相当复杂的工具链,所以准备一篇冗长的文章,直到找到问题:
我设法让PDFCreator和一个虚拟的PDF创建打印机在windows7下以服务器模式作为服务运行。该过程的下一步是PDFCreator在创建PDF之后调用VBScript。该脚本通过WebService将PDF上传到服务器,并轮询服务器以获得结果PDF。下载生成的PDF后,VBScript需要将其打印到已确认的打印机上。
现在为了打印,我使用了PDFCreator的集成COM对象,它提供了对GhostScript的访问。对于启动PDFCreator服务的任何帐户,这在windowsxp上都非常有效。例如,作为域用户可以从VBScript访问共享打印机,因为用户上下文与PDFCreator服务相同。
现在,我在Windows7上也尝试了同样的方法,并像以前一样使用了“本地系统”帐户,因为我的测试打印机是本地打印机(并且可以工作,即TestPage)。其效果是wscript停留在任务管理器中,永远不会完成。接下来,我激活了服务的交互模式,一个saw Ghostscript请求打印机打印到。正如我在VBScript中调用GS之前检查的那样,打印机确实存在,但是由于任何原因GhostScript都看不到打印机,尽管在打开的选择打印机的对话框中,打印机在那里。
经过几天的搜索,甚至尝试了一个新的管理员帐户都没有成功,我终于想出了一个办法让它工作。将PDFCreator服务的用户更改为“locale service”我首先得到一个错误,PDFCreator COM对象创建失败。好吧,我认为这是有道理的,因为“语言环境服务”比“语言环境系统”拥有更少的权限。我通过更改comexp.msc下的访问权限来绕过这个限制,并授予本地和远程COM和脚本访问的“locale service”权限。瞧,一切都成功了。
我不明白的是:为什么“locale service”帐户下的Ghostscript能够找到打印机,尽管该帐户的权限比“locale system”小?
以及:我需要为“locale system”或任何其他用户帐户设置哪个访问权限才能使其正常工作?
或者:这些账户之间是否有详细差异的综合清单?
非常感谢你和格里茨,
