Windows 7 本地系统和本地服务之间的服务差异
我有一个相当复杂的工具链，所以准备写一篇冗长的文章，直到解决问题：
我设法在 Windows 7 下获得 PDFCreator 和一个虚拟 PDF 创建打印机，以服务器模式作为服务运行。该过程的下一步是 PDFCreator 在创建 PDF 后调用 VBScript。该脚本通过 WebService 将 PDF 上传到我们的服务器，并轮询服务器以获取生成的 PDF。下载生成的 PDF 后，VBScript 需要将其打印到已配置的打印机。
现在，为了打印，我使用 PDFCreator 的集成 COM 对象，它可以访问 GhostScript。对于启动 PDFCreator 服务的任何帐户，这在 Windows XP 上都可以完美运行。例如，作为域用户可以从 VBScript 访问共享打印机，因为用户上下文与 PDFCreator 服务相同。
现在我在 Windows 7 上尝试了同样的操作，并像以前一样使用“本地系统”帐户，因为我的测试打印机是本地打印机（并且可以工作，即 TestPage）。效果是 wscript 保留在任务管理器中并且永远不会完成。接下来，我激活了该服务的交互模式，并看到 Ghostscript 要求打印机进行打印。正如我在 VBScript 中调用 GS 之前检查的那样，打印机确实存在，但出于某种原因，GhostScript 看不到打印机，尽管在打开的选择打印机的对话框中，打印机就在那里。
经过几天的搜索，甚至尝试为该服务指定一个新的管理员帐户也没有成功，我终于想出了一种让它工作的方法。将 PDFCreator 服务的用户更改为“区域设置服务” 我首先收到一个错误，指出 PDFCreator COM 对象创建失败。好吧，我认为这是有道理的，因为“区域设置服务”的权限比“区域设置系统”少。我通过更改 comexp.msc 下的访问权限并授予本地和远程 COM 和脚本访问的“区域设置服务”权限来解决此限制。瞧，一切正常。
我不明白的是：为什么“区域设置服务”帐户下的 Ghostscript 能够找到打印机，尽管该帐户的权限比“区域设置系统”少？
并且：我需要为“区域设置系统”或任何其他用户帐户设置哪种访问权限才能使其正常工作？
或者：是否有这些帐户之间详细差异的综合列表？
非常感谢你并问候， 甘德
I have a rather complicated toolchain so prepare for a lengthy post until getting to the problem:
I managed to get PDFCreator and a virtual PDF creating printer under Windows 7 running in server mode as a service. Next step in the process is PDFCreator calling a VBScript after the PDF is created. The script uploads the PDF to our server via WebService and polls the server for a resulting PDF. When the resulting PDF has been downloaded, the VBScript needs to print it to a confiured printer.
Now for printing I was using the integrated COM object of PDFCreator which gives access to GhostScript. This worked perfectly onder Windows XP for any account the PDFCreator service was started. For example as a domain user to have access to shared printers from the VBScript, as the user context is the same as the PDFCreator service.
Now I tried the same for Windows 7 and used the "local system" account as before, because my test printer is a local one (and works, i.e. TestPage). Effect is that the wscript stays in the task manager and never finishes. Next I activated Interactive mode for the service and a saw Ghostscript asking for the printer to print to. The Printer does exist as I checked before calling GS within the VBScript, but out of any reason GhostScript does not see the printer although in the dialog opened to select the printer, the printer is there.
After days long searching and unsuccessfully trying even a dedicted new administrator account for the servive with no success I finally came up with a way to get it working. Changing the user for the PDFCreator service to "locale service" I first got an error that the PDFCreator COM object creation failed. Okay I thought this makes sense, as "locale service" has less rights that "locale system". I got around this limit by changing the access right under comexp.msc and granted "locale service" rights for local and remote COM and Script access. Voilá, everything worked.
What I do not understand: Why is Ghostscript under the "locale service" account capable to find the printer although the account has less rights that "locale system"?
And: Which access right do I need to set for "locale system" or any other user account to make it work?
Or: Is there a comprehensive list of detailed differences between these accounts?
Thank you very much and greetz,
GHad
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
答案可以在这里找到： KB184291
这是关于在“本地系统”帐户下运行的 ASP/IIS并且无法打印，因为打印机在 .DEFAULT 用户下不可用。复制注册表项会有所帮助。
问候，
甘德
The answer can be found here: KB184291
It's about ASP/IIS running under "local system" account and cannot print because the printers are not available under the .DEFAULT user. Copying over registry entries helps.
Greetz,
GHad