Automatisation à l'aide de VBScript Windows 7 (x64)

Bonjour,

J'ai une application distribuée écrite C# 2.0, elle se compose d'un service windows qui tourne sur un server, il reçoit des jobs à exécuter et les envoies à des services windows (d'exécution) qui tournent sur des machine de calcul (avec les droits admin)

Le job en question est une classe C# serialisable qui lance Process.Start() avec un .bat en paramètre, le batch est tout simplement la commande
"csript file.vbs [arguments]"

Le fichier vbs exécute grosso-modo les lignes suivantes :

Code:

---

1 2 3 4 5 6 7 8 9 10

Set xlobj = WScript.CreateObject("Excel.Application") Set workbooks = xlobj.WorkBooks Set objWorkbook = workbooks .Open(excelFile,updateLinks,readonly) Set InputSheet = objWorkbook.Sheets(InputSheetName) //… Set some variables values in a InputSheet Xlobj.Calculate() Set outputSheet = objWorkbook.Sheets(outputSheetName) outPutSheet.saveAs outputFileNameFull, 6 //as .cvs file.

---

Sur une machine windows 7 (x64) il n'y a aucun pb à exécuter le batch directement, cependant, quand il est lancé via l'appli (ç-à-d par le service windows d'exécution). On a l'erreur suivante :

Error (1004) description : Impossible de lire la propriété Open de la classe Workbooks.

Une version C# du VBS s'exécute elle aussi sans soucis directement sur la machine mais plante via l'appli avec l'erreur :

Exception de HRESULT : 0x800A03EC

Par ailleurs, tout se passe bien sur une grille de machines XP SP2 à l'exception d'une seule qui présente les même symptômes que la "Windows 7"

Est-ce un problème de droits sur le poste Windows 7 ? un problème d'activation des objets COM ?...

Merci d'avance pour votre aide.

Bonjour à tous,

J'ai trouvé une fausse solution qui a un lien avec la sécurité DCOM, fausse parce que ça marche tant qu'on n'utlise pas Excel sur les postes (windows 7 et l'XP qui ne fonctionne pas).

cette solution consiste mettre l'utilisateur à "utilisateur interactif":
Dans Services de composants => Ordinateurs => Poste de travail chercher "Application Microsoft Excel" puis appuyer sur Propriétés et aller dans l'onglet Identité puis cocher "L'utilisateur interactif".

avec ce paramétrage je n'ai plus les erreurs citées ci-dessous mais malheureusement dès qu'on ouvre l'application Excel sur le poste, les autres Excel qui sont censés s'exécuter en tache de fond apparaissent et empechent une utilisation normale d'Excel. Je pense que ça vient du mot "Interactif".

Sur les autres postes où cela fonctionne, l'utilisateur est mis à "utilisateur exécutant" et on peut utliser Excel sans qu'il interagisse avec ceux créés par le script VB.

J'ai essayé aussi de spécifier un utilisateur dans le même onglet "Identité" => Cet utilisateur en mettant un login/mot de passe administrateur, résultat, je n'ai plus l'erreur et l'automatisation d'Excel se passe bien, cependant, quand j'ouvre Excel j'ai des erreurs du type :
- "impossible d'utiliser des objets liés et incorporés"
- "Une erreur s'est produite au cours de l'initialisation des bibliothèques VBA(14)".

Je ne sais pas comment les autorisations/droits sont transmis du service windows à cscript et Excel. pour rappel, le schéma est le suivant: le service windows reçoit un flux binaire, le désérialise sous forme de DLL et appel une fonction Start de la DLL qui lance un process avec la commande "cscript "file.vbs" [args]. J'insiste sur le fait que le script fonctionne quand je le lance directement sur les deux machines, comme si l'appel via la DLL est considéré comme un appel distant qui va utiliser les settings de sécurité DCOM.

Il est clair que quelque chose a sauté sur ces deux postes qui fait que "L'utilisateur exécutant" ne permet pas d'interagir avec des fonctions VB d'Excel. Quelqu'un aurait une idée de ce que ça peut être ?

Merci d'avance!