Question Script ne fonctionne pas en tâche planifiée

Plus d'informations
il y a 3 ans 5 mois - il y a 3 ans 5 mois #30121 par Toper
Merci.
La seule différence entre le lancement ISE et par tâche planifiée est cette ligne (rajoutée si lancement manuel ISE):
C:\Users\<username>\AppData\Roaming\Composer\vendor\bin

Powershell: la vie est belle :)
Dernière édition: il y a 3 ans 5 mois par Toper.

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

Plus d'informations
il y a 3 ans 5 mois #30122 par Laurent Dardenne
Dans ce cas il va falloir vérifier le chargement de dll avec cet outil : docs.microsoft.com/fr-fr/dotnet/framewor...y-binding-log-viewer
Si toutefois cela vient de là.

Ton code n'a pas de référence explicite sur ce type [System.Runtime.Loader.AssemblyLoadContext] ?

Tutoriels PowerShell

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

Plus d'informations
il y a 3 ans 5 mois - il y a 3 ans 5 mois #30124 par Toper
Bon...
j'ai tout simplement ajouté dans mon script cette ligne:
$env:path +=";C:\Users\<username>\AppData\Roaming\Composer\vendor\bin"
Mais la tâche planifiée restait "En cours" indéfiniment ...
Alors j'ai modifié la tâche planifiée pour mettre comme argument:
-command & "chemin_vers_le_script.ps1"
Et là tout fonctionne.
Sauf que:
quand je lance le script par ISE il ne me met aucune erreur. Mais si je le lance par la tâche, il me met une erreur vide:
function Load-Module
{
    param (
        [parameter(Mandatory = $true)][string] $name
    )

    $retVal = $true

    if (!(Get-Module -Name $name))
    {
        $retVal = Get-Module -ListAvailable | where { $_.Name -eq $name }

        if ($retVal)
        {
            try
            {
                Import-Module $name -ErrorAction SilentlyContinue
            }

            catch
            {
                $retVal = $false
            }
        }
    }

    return $retVal
}
Try {
$name = "ActiveDirectory"
} catch {
Write-Output "Une erreur s'est produite : $($Error.exception.message)" | Out-File C:\Users\buenadg\Desktop\Load_AD_Module_Error.txt
}
$env:path +=";C:\Users\<username>\AppData\Roaming\Composer\vendor\bin"

Try {
$SearchBase = "OU=mon_OU,DC=domain,DC=lan" 
$users = Get-ADUser -SearchBase $SearchBase -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False -and PasswordLastSet -gt 0 } `
 -Properties "SamAccountName", "EmailAddress", "msDS-UserPasswordExpiryTimeComputed" | Select-Object -Property "SamAccountName", "EmailAddress", `
 @{Name = "PasswordExpiry"; Expression = {[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed").tolongdatestring() }} -ErrorAction Continue
 } catch {
 } Write-Output "Une erreur s'est produite : $($Error.exception.message)" | Out-File C:\Users\<username>\Desktop\get-aduser_Error.txt

Il me créé le fichier "get-aduser_Error.txt", mais vide....

Pourquoi donc ?

Powershell: la vie est belle :)
Dernière édition: il y a 3 ans 5 mois par Toper.

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

Plus d'informations
il y a 3 ans 5 mois #30125 par Laurent Dardenne
Ici :
Try {
$name = "ActiveDirectory"
} catch {
Write-Output "Une erreur s'est produite : $($Error.exception.message)" | Out-File C:\Users\name\Desktop\Load_AD_Module_Error.txt
}
le try me semble inutile à moins que $Name ait une conception particulière.
Write-Output est redondant, l'émission d'une chaine dans le pipeline suffit.

gregmurf écrit: Il me créé le fichier "get-aduser_Error.txt", mais vide....
Pourquoi donc ?

Parce que le vendredi on n'a pas les yeux en face des trous ;-)
D'une part, dans un bloc catch on référence l'erreur avec $_ et d'autre part write-output est en dehors du bloc catch.
Le message "Une erreur s'est produite" est faux car tu enregistres tous les erreurs et enfin avec -ErrorAction Continue pas besoin de try/catch car tu ne tiens pas comptes des erreurs.
Allez une dernière pour la route pour :
Import-Module $name -ErrorAction SilentlyContinue
Ton module peut exister mais provoquer une erreur, il est préférable de laisser les exceptions remonter vers l'appelant, lui seul peut décider quoi faire dans ce cas.
La présence de -ErrorAction SilentlyContinue dans un bloc try catch me laisse dubitatif. Sache qu'un import-module d'un module chargé ne fait rien, sauf si on précise -Force pour le recharger.

Après si tu as codé de cette manière cela il y a peut être une raison ou des raisons mais je ne les connais pas. Il m'est donc difficile de répondre à ta question 'Pourquoi donc'.
Le principale est que tu ais pu avancer sur le sujet :-)

Tutoriels PowerShell

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

Plus d'informations
il y a 3 ans 5 mois #30139 par Toper

le try me semble inutile à moins que $Name ait une conception particulière.

J'ai du zapper un bout...:
Try {
$name = "ActiveDirectory"
Load-Module $name
} catch {
Write-Output "Une erreur s'est produite1 : $($Error.exception.message)" #| Out-File C:\Users\buenadg\Desktop\Load_AD_Module_Error.txt
}
En fait j'ai fait un try là-dessus car au début car je pensais qu'il y avait une erreur dans le chargement du module.
Mais un module ne s'installe qu'une fois et ensuite on fait appel à lui, donc ce bloc ne sert à rien si je te comprends bien.

Write-Output est redondant, l'émission d'une chaine dans le pipeline suffit.

Je n'ai pas tout compris (je suis novice tu l'auras compris :) )

Parce que le vendredi on n'a pas les yeux en face des trous ;-)

C'est clair....

D'une part, dans un bloc catch on référence l'erreur avec $_

Comme ceci et rien d'autre ?
try {
blabla
} catch {
$_ 
}

et d'autre part write-output est en dehors du bloc catch.

OMG... oui ça crève les yeux le lundi matin...

La présence de -ErrorAction SilentlyContinue dans un bloc try catch me laisse dubitatif

Oui ça n'a rien à faire là ...

Ton module peut exister mais provoquer une erreur, il est préférable de laisser les exceptions remonter vers l'appelant, lui seul peut décider quoi faire dans ce cas.

Donc supprimer -ErrorAction SilentlyContinue (et faire un try / catch ?)

Sache qu'un import-module d'un module chargé ne fait rien, sauf si on précise -Force pour le recharger.

Ok.
Donc à partir du moment où je l'ai installé une première fois, la partie Load-module ne sert plus à rien. Le get-aduser se chargera d'y faire appel.

Merci pour ton aide en tout cas !

Powershell: la vie est belle :)

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

Plus d'informations
il y a 3 ans 5 mois - il y a 3 ans 5 mois #30143 par Laurent Dardenne

gregmurf écrit: Mais un module ne s'installe qu'une fois et ensuite on fait appel à lui, donc ce bloc ne sert à rien si je te comprends bien.

Vu de ma fenêtre non, mais on se pose tjr des questions lorsqu'on lit ce type de code.

gregmurf écrit: Je n'ai pas tout compris (je suis novice tu l'auras compris :) )

Write-Output 'Test'|% {$_}
est identique à
'Test'|% {$_}
On peut préciser l'intention avec Write-Output mais ici on comprend (pour ceux/celles qui ont les bases).

gregmurf écrit: Comme ceci et rien d'autre ?

Pas tout à fait, écrit comme ça tu émets un objet dans le pipeline, selon les besoins( log, analyse, redéclenchement) il faut coder autour de $_ qui est l'exception courante dans un bloc catch.

gregmurf écrit: Donc supprimer -ErrorAction SilentlyContinue (et faire un try / catch ?)

Oui et le try catch est dans l'appelant.

gregmurf écrit: Donc à partir du moment où je l'ai installé une première fois, la partie Load-module ne sert plus à rien. Le get-aduser se chargera d'y faire appel.

Load-module sert à initialiser explicitement les prérequis de ton traitement.Pour la fin de ta phrase, oui, mais sache que si le chargement automatique des modules est configuré, il l'est par défaut, le premier appel à Get-User va charger le module. Je te conseille de tjr préciser les chargement.

Tutoriels PowerShell
Dernière édition: il y a 3 ans 5 mois par Laurent Dardenne.

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

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