J'ai un toolchain assez compliqué donc se préparer à un poste long jusqu'à arriver au problème:Windows 7 différences de service entre le système local et le service local
Je réussi à obtenir PDFCreator et un PDF virtuel créant imprimante sous Windows 7 cours d'exécution en mode serveur en tant que service. La prochaine étape du processus est PDFCreator appelant un VBScript après la création du PDF. Le script télécharge le fichier PDF sur notre serveur via WebService et interroge le serveur pour obtenir un fichier PDF résultant. Lorsque le PDF résultant a été téléchargé, le VBScript doit l'imprimer sur une imprimante confiured.
Maintenant, pour l'impression, j'utilisais l'objet COM intégré de PDFCreator qui donne accès à GhostScript. Cela a fonctionné parfaitement sur Windows XP pour n'importe quel compte le service PDFCreator a été démarré. Par exemple, en tant qu'utilisateur de domaine, avoir accès à des imprimantes partagées à partir de VBScript, car le contexte utilisateur est le même que le service PDFCreator.
Maintenant, j'ai essayé la même chose pour Windows 7 et utilisé le compte "système local" comme avant, parce que mon imprimante de test est une locale (et fonctionne, c'est-à-dire TestPage). L'effet est que le wscript reste dans le gestionnaire de tâches et ne finit jamais. Ensuite, j'ai activé le mode interactif pour le service et une scie Ghostscript demandant à l'imprimante d'imprimer. L'imprimante existe quand j'ai vérifié avant d'appeler GS dans le VBScript, mais pour une raison quelconque, GhostScript ne voit pas l'imprimante bien que dans la boîte de dialogue ouverte pour sélectionner l'imprimante, l'imprimante est là. Après plusieurs jours de recherche et d'essais infructueux, même un nouveau compte d'administrateur pour le service sans succès, j'ai finalement trouvé un moyen de le faire fonctionner. Changement de l'utilisateur pour le service PDFCreator en "service de locale" J'ai d'abord eu une erreur que la création de l'objet COM PDFCreator a échoué. D'accord, je pensais que cela avait du sens, car "locale service" a moins de droits que "système de localisation". J'ai contourné cette limite en modifiant le droit d'accès sous comexp.msc et accordé des droits de "locale service" pour l'accès COM et Script local et distant. Voila, tout a fonctionné. Ce que je ne comprends pas: Pourquoi Ghostscript est-il sous le compte "locale service" capable de trouver l'imprimante bien que le compte ait moins de droits que "locale"?
Et: Quel droit d'accès dois-je définir pour "système de localisation" ou tout autre compte d'utilisateur pour le faire fonctionner?
Ou: Existe-t-il une liste complète des différences détaillées entre ces comptes?
Merci beaucoup et greetz, Ghad