Question Creation fichier excel avec tache planifier

Plus d'informations
il y a 1 an 4 mois #28291 par T800
Pour ce paramètre de la tâche planifié:
C'est ce que j'ai pensé des le départ mais non, au contraire je perd l’accès au répertoire que je mesure et le problème reste.
C'est forcément un soucis avec la tache planifier mais lequel. En dehors de ceux qui ont eu la chance d'arriver a résoudre e problème avec les fameux répertoire desktop je n'ai pas la moindre autre solution.
Je ne vois pas !! Un problème de profil dans ce cas comme je l'ai vue pour d'autre chose ? vue le message ont ne dirait t'on pas un problème de droits d’accès? mais ou ?

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 1 an 4 mois #28307 par Arnaud
Hello !

De mémoire, une tâche qui peut interagir avec le bureau ne peut pas avoir accès au réseau. C'est l'un ou l'autre.

Essaie peut-être de modifier ton script dans ce sens pour tester ?

Arnaud

Créateur du forum de la communauté PowerShell Francophone

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 1 an 4 mois #28317 par hichammadd
Slt T800, slt Arbaud,

essaie l'une de ces solutions:

1- Boutton de droite sur ton fichier ==> general ==> unblock (debloquer, c'est ou bien un boutton ou une option à cocher)

2- cmd => dcomcnfg ==> Component services >Computer >My Computer>Dcom config> selectione microsoft Excel Application
Boutton de droite ==> general ==> identité (utilise le compte que tu veux)

3- sinon jette un coup d'oeil ici

http://troyvssharepoint.blogspot.com/2012/07/stumbled-upon-interesting-one-today.html <br><br>Message édité par: hichammadd, à: 23/02/19 03:28

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 1 an 4 mois #28330 par T800
Hello tous le monde et merci pour ses réponses.

J'ai testé la solution de Arnaud sans succès. Je vais la re tester et testé les solutions de hichammadd mais justement il me semble ne pas avoir trouver \&quot;microsoft Excel Application\&quot; dans cette interface , étrange non ? Excel y est forcément puisque sans la tache planifié ça fonctionne. Je passerai voir aussi le lien.

Dans tous les cas je vous tiens au courant.

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 1 an 4 mois #28339 par Arnaud
Hello ! :)

...il me semble ne pas avoir trouver \&quot;microsoft Excel Application\&quot; dans cette interface , étrange non ?


Je me suis fait avoir une fois dans un cas assez similaire et c'était un problème de version 32 ou 64 bits d'Office. En effet, en fonction de la version 32 ou 64 bits de l'outil qui te permet de visualiser/modifier les objets DCOM, tu ne verras que les DLL de la version correspondante.

Donc vérifie bien ce point.

Par exemple, à partir d'une console PowerShell 32 bits, tu ne peux instancier un objet COM 64 bits.

Arnaud

Créateur du forum de la communauté PowerShell Francophone

Connexion ou Créer un compte pour participer à la conversation.

Plus d'informations
il y a 1 an 4 mois #28385 par T800
Hello
Merci il faudra que j'essaie ça mais il me semble avoir déjà essayé en changeant la partie de l'appel de powershell \&quot;system32\&quot; dans la tache planifiè par l'autre au nom plus étrange.

Par contre j'ai une solution qui fonctionne même si elle n'est pas aussi propre que ce que j'aurai aimé.
[code:1]

Start-Transcript \&quot;D:\Scripts\IISlogsReports\logx.txt\&quot;

if (test-path \&quot;D:\Scripts\IISlogsReports\fintest.xlsx\&quot;«») {Remove-Item -Force \&quot;D:\Scripts\IISlogsReports\fintest.xlsx\&quot;}

$objexcel = New-Object -ComObject excel.application
$objexcel.visible = $false
$objexcel.DisplayAlerts = $false

# Add workbook
$FilePAth = \&quot;D:\Scripts\IISlogsReports\&quot;
$file = \&quot;D:\Scripts\IISlogsReports\xlsdetest.xlsx\&quot;

$finalworkbook = $objexcel.workbooks.open($file)
$finalexcelrow = 1

$finalworksheet = $finalworkbook.worksheets.item(1)
$finalworkbook.worksheets.item(1).name = \&quot;IIs log size\&quot; # nommer onglet
$datess = get-date
$finalexcelrow = 1
$finalworksheet.cells.item($finalexcelrow,1)=\&quot;datocol1\&quot;
$finalworksheet.cells.item($finalexcelrow,2)=\&quot;$datess\&quot;

$ur = $finalworksheet.UsedRange
$null = $ur.entirecolumn.autofit()
Write-Verbose \&quot;END Create tab for report\&quot; -Verbose

$finalWorkBook.SaveAs(\&quot;D:\Scripts\IISlogsReports\fintest.xlsx\&quot;«»)

get-process -name excel | Stop-Process

Stop-Transcript

[/code:1]

Pour résumer, au lieu de créer un xlsx de 0 avec powershell, j'en ouvre un existant (créé à la main avec excel) vide, pour le modifier et le sauvegarder sous un autre nom ensuite. Ça fonctionne même en tache planifié.
Donc au lieu de:
[code:1]$finalworkbook = $objexcel.workbooks.add()[/code:1]
Cela donne:
[code:1]$finalworkbook = $objexcel.workbooks.open($file)[/code:1]
La ou $file est le chemin du fichier excel vide existant.
Pourquoi la première solution marche pour certains et pas pour d'autre ? J'ai l'impression qu'il n'y aurai un soucis de chemin voir de chemin complet avec ou sans le nom du fichier dans le cas d'un add(). J'ai rapidement essayé en y mettant un chemin, sans résultat mais je vais re tenter. Sinon, tan pis, je garde ma solution.
Le script complet créé un fichier excel avec les données brutes et un graphique de leurs variations journalières.

Connexion ou Créer un compte pour participer à la conversation.

Temps de génération de la page : 0.183 secondes
Propulsé par Kunena