PI Services

Le blog des collaborateurs de PI Services

WINDOWS : Erreur 0x80070002

 

Nous allons traiter l’erreur 0x80070002

A l’ouverture de session toujours le message d’erreur 0x80070002

clip_image001

 

Lorsque l’on éteint le PC reste bloqué sur « Fermeture de Sessions »

Donc obligé de l’éteindre en appuyant 3 secondes sur le bouton marche/arrêt.

La KB Microsoft https://support.microsoft.com/fr-fr/kb/910336

1- Explique l’erreur 0x80070002 est dû à un problème de mise à jour Windows

2- Donne une résolution a effectué qui n’est pas valide, car même après l’avoir appliqué cela ne fonctionne toujours pas

 

SOLUTION :

1- Exécuter en administrateur l’invite de commande CMD

clip_image003

2- Il y’a une suite de service à stopper :

a) Arrêtez le service BITS, le service de mise à jour de Windows et le service de chiffrement

b) Supprimez les fichiers qmgr*.dat

c) Renommez les copies de sauvegarde des dossiers de distribution du logiciel.

d) Réinitialisez le service BITS et le service Windows Update dans le descripteur de sécurité par défaut.

e) Réenregistrez les fichiers BITS et les fichiers de mise à jour de Windows.

f) Réinitialisez Winsock.

g) Configurer les paramètres proxy.

h) Redémarrez le service BITS, le service de mise à jour de Windows et le service de chiffrement.

i) Installez l'Agent de mise à jour de Windows le plus récent.

j) Redémarrez l'ordinateur.

 

La Partie A jusqu’à H sera scripté, pour cela un fichier bat est suffisant.

 

SCRIPT : REINIT composants Windows Update

 

REM ARRET DES SERVICES

net stop bits

net stop wuauserv

net stop appidsvc

net stop cryptsvc

REM Supprimez les fichiers qmgr*.dat.

DEL "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat"

REM Renommez les copies de sauvegarde des dossiers de distribution du logiciel.

Ren %systemroot%\SoftwareDistribution SoftwareDistribution.bak

Ren %systemroot%\system32\catroot2 catroot2.bak

REM Réinitialisez le service BITS et le service Windows Update dans le descripteur de sécurité par défaut.

sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

REM Se positionner sur le répertoire system32

CD /d %windir%\system32

REM Réenregistrez les fichiers BITS et les fichiers de mise à jour de Windows.

regsvr32.exe /s atl.dll

regsvr32.exe /s urlmon.dll

regsvr32.exe /s mshtml.dll

regsvr32.exe /s shdocvw.dll

regsvr32.exe /s browseui.dll

regsvr32.exe /s jscript.dll

regsvr32.exe /s vbscript.dll

regsvr32.exe /s scrrun.dll

regsvr32.exe /s msxml.dll

regsvr32.exe /s msxml3.dll

regsvr32.exe /s msxml6.dll

regsvr32.exe /s actxprxy.dll

regsvr32.exe /s softpub.dll

regsvr32.exe /s wintrust.dll

regsvr32.exe /s dssenh.dll

regsvr32.exe /s rsaenh.dll

regsvr32.exe /s gpkcsp.dll

regsvr32.exe /s sccbase.dll

regsvr32.exe /s slbcsp.dll

regsvr32.exe /s cryptdlg.dll

regsvr32.exe /s oleaut32.dll

regsvr32.exe /s ole32.dll

regsvr32.exe /s shell32.dll

regsvr32.exe /s initpki.dll

regsvr32.exe /s wuapi.dll

regsvr32.exe /s wuaueng.dll

regsvr32.exe /s wuaueng1.dll

regsvr32.exe /s wucltui.dll

regsvr32.exe /s wups.dll

regsvr32.exe /s wups2.dll

regsvr32.exe /s wuweb.dll

regsvr32.exe /s qmgr.dll

regsvr32.exe /s qmgrprxy.dll

regsvr32.exe /s wucltux.dll

regsvr32.exe /s muweb.dll

regsvr32.exe /s wuwebv.dll

REM Réinitialisez Winsock et le proxy

netsh winsock reset

netsh winhttp reset proxy

REM Redémarrez le service BITS, le service de mise à jour de Windows et le service de chiffrement

Net start bits

Net start wuauserv

Net start appidsvc

Net start cryptsvc

Il ne vous reste plus qu’à appliquer la partie I et J

expliquer ci-dessus

WMI : Reconstruction de la couche WMI

 

Nous allons traiter d’un sujet particulier , la reconstruction de la couche WMI sur Windows

 

RAPPEL :

 

WMI est un système de gestion interne de Windows qui prend en charge la surveillance et le contrôle de ressource système via un ensemble d’interfaces. Il fournit un modèle cohérent et organisé logiquement des états de Windows.

Il permet à des scripts PS1 (Powershell) par exemple de gérer Windows localement ou à distance. C'est grâce à WMI que le composant Propriétés système de Windows peut afficher les propriétés du système sur un ordinateur distant ou local.

WMI est préinstallé sur depuis Windows 2000 jusqu’à 2012 R2

 

PARTIE 1 : COMMANDE SOUS POWERSHELL

 

 

Il faut savoir qu’il se peut parfois qu’un objet de la classe de la couche WMI ne soit pas fonctionnel

 

Exemple sous Powershell :

image

Get-wmiobject –class win32_operatingsystem nous retourne les informations liés au system d’exploitation.

 

Mais lorsque le retour d’information de la classe Win32_operatingsystem retourne une erreur , cela veut dire que cette classe est manquante dans la couche WMI ce qui n’est pas normal car cette classe est par défaut intégré dans tout les systèmes d’exploitation Windows.

 

Pour cela nous pouvons taper la commande suivante sous powershell ou cmd

WBEMTEST

 

image

 image

image

image

 

 

PARTIE 2 : SOLUTION

1\ Recompiler les fichiers Microsoft Windows .MOF :

net stop winmgmt
c: 
cd %systemroot%\system32\wbem 
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll 
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof 
mofcomp cimwin32.mfl 
mofcomp rsop.mof 
mofcomp rsop.mfl 
for /f %s in ('dir /b /s *.dll') do regsvr32 /s %s 
for /f %s in ('dir /b *.mof') do mofcomp %s 
for /f %s in ('dir /b *.mfl') do mofcomp %s

 

N'oubliez pas de redémarrer le serveur ou le poste client sur lequel la couche WMI est défectueuse pour que les modifications soient pris en compte.

SMG : Mise à Jour Symantec Messaging Gateway 10.5.4-4 vers 10.6.0-3

 

Voici un retour d’expérience sur les mises à jour concernant les Appliances Symantec Messaging Gateway (ANTI-SPAM)

La mise à jour se décompose en 2 parties:

 

PARTIE 1 : Télécharger la mise à jour 10.6.0-3

 

image

PARTIE 2 : Mise à jour Version 10.5-4-4 vers 10.6.0-3

 

Conséquence lors du lancement de la mise à jour sur les services suivant:

Control Center => perte de la console envoie/réception de mail est ok

Scanner => perte envoie/réception de mail

ATTENTION pour la partie scanner il faut arrêter la réception de mails 30 minutes avant le passage de la mise à jour

clip_image001

Symantec indique entre 1 à 3 heures pour notre plateforme SMG a été entièrement mise à jour de la Version  10.5.4-4 vers la version 10.6.0-3 avec les temps ci-dessous:

Le Control center : Temps d’installation environ 45 minutes/1 heure

Le Scanner principal (MX1) : Temps d’installation environ 30 minutes

Le Scanner secondaire (MX10) : Temps d’installation environ 30 minutes

Notre PLATEFORME SMG est la suivante:

image

 

installation de la mise à jour mineure sur SMG (passage de la version 10.6.0-3 à la version 10.6.0-5). à pris environ 10 minutes par ApplianceAplliance

image

ERREUR 8024401F: Mise à Jour Windows 2012

 

Bonjour dans le cadre de la mise à jour des correctifs pour Windows 2012

il se peut que vous rencontriez une erreur 8024401F.

 

IMAGE DE L’ERREUR:

image

 

Etape 1 : Il faut arrêter le service de mise à jour en tapant la command ci-dessous , ATTENTION il faut être en mode Administrateur.

image

 

Etape 2 : Il faut renommer le répertoire C:\Windows\Softwaredistribution en Softwaredistribution–old.

image

Etape 3 : Il faut redémarrer le service de mise à jour en tapant la command ci-dessous , ATTENTION il faut être en mode Administrateur.

image

Etape 4 : Il faut relance la mise à jour

image

RESTAURATION D’UNE SAUVEGARDE SYMANTEC MESSAGING GATEWAY VERSION 10.5.3

image

Bonjour,

Dans ce blog, nous allons voir comment, restaurer un Anti-SPAM Symantec Messaging Gateway à partir d’une sauvegarde d’un autre Anti-SPAM

ETAPE 1 : SAUVEGARDER LA VM APPLIANCE Symantec Messaging Gateway ACTUELLE qui fonctionne

image

image

ETAPE 2 : RESTAURER SUR LA NOUVELLE VM APPLIANCE Symantec Messaging Gateway à partir de la dernière sauvegarde effectué.

Prendre la main sur PUTTY en SSH port 22 avec login et mot de passe

Login : admin

Mot de passe : symantec (par défaut)

clip_image002

Quelques paramètres peuvent ne pas avoir été restaurés, mot de passe à changer et surtout les liaisons de distribution SMTP à vérifier

image

image

INSTALLATION SYMANTEC MESSAGING GATEWAY VERSION 10.5.3

image

Aujourd’hui nous allons aborder l’installation de Symantec Messaging Gateway, son rôle principale est le filtrage de mails (Anti-Spam) mais il a notamment d’autres rôles comme une protection contre les attaques ciblées ainsi que des fonctions de filtrage de contenu avancé, de prévention des pertes de données et de chiffrement des messages électroniques.

Donc voici ci-dessous les prérequis de la Machine Virtuelle que nous allons installer sur un HYPERVISEUR WINDOWS 2012 R2

PREREQUIS DE LA VM :

image[7]

CONFIGURATION DE LA VM :

image

ETAPE 1 : boot avec le cd se trouvant sur le serveur HYPERV dans D :

image

ETAPE 2 : Lié l’image ISO se trouvant sur le serveur HYPERV dans D, et l’installation commence automatiquement :

image

ETAPE 3 : Entrer le login par défaut : admin et mot de passe par défaut :

1- Taper votre nouveau mot de passe   

2- Taper le FQDN de la VM SMG

image

ETAPE 4 : Taper 32 cela correspond au fuseau horaire paris

imageimage

ETAPE 5 : Taper ci-dessous les paramètres suivant :

1- IP de la 1ère Interface réseau 

2- Masque sous réseau  

3- IP de la Seconde interface réseau       

4- Masque sous réseau 

5- Route Static (NON par défaut)

6- Entrer l’IP du 1er Serveur DNS et du 2ème Serveur DNS s’il existe.

image

imageimage

ETAPE 6 : Taper ci-dessous le type de Fonction du SMG:

1- Scanner    

2- Control Center Only    

3- Scanner and Control CENTER

image

Si la configuration vous parait correct, taper YES puis appuyer sur Entrer

Ensuite vous pouvez connecter par interface WEB comme par exemple

https://smg.domaine.com

image

WINRM : Error 2147749890

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2147749890                    que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces serveurs.

Voici la commande du script powershell qui permet de vérifier si le service MSDTC commun à tout les serveurs de Windows 2003 SP2 à Windows 2012 R2.

MON SCRIPT DE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $NULL                                                                                $StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination 

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"    

} else {

"error : " + $error[0]

}

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService

RESULTAT: malgré winrm activer et enable-psremoting + port 5985 ok

clip_image001[11]

-SessionOption (New-PSSessionOption -NoMachineProfile) qui a permis de résoudre le problème

 

MON SCRIPT CORRIGE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $null

$StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination -SessionOption (New-PSSessionOption -NoMachineProfile)

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"

                                    } else {

"error : " + $error[0]

                                    }

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService

WINRM : Résolution de l'erreur -2144108526 0x80338012

 

Aujourd’hui mon 2ème blog va porter sur l’erreur WINRM : -2144108528 0x80338012 que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Là aussi pour trouver une solution sur internet est introuvable.

PERIMETRE: Dans le cadre de l’organisation des reboot de 400 serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces 400 serveurs.

Voici la commande du script powershell qui permet de vérifier si le service MSDTC qui est commun au serveur 2000 à 2012 R2 ,  l’exemple ci-dessous porte sur 1 serveur le but étant de démontrer l’erreur winrm.

Nous allons utiliser le script powershell ci-dessous depuis le serveur source, pour rappel $computerdestination est la variable qui contient le nom du serveur distant.

######SERVEURS A TESTER################

$Computerdestination = "SRVxxx"

######SERVICES A VERIFER################

$Servicesname = "MSDTC"

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination

Ce qu’il faut effectuer AVANT de lancer le script,ouvrir la console powershell

Taper sur le serveur de destination : WINRM QUICKCONFIG

clip_image001

1er message d’erreur : sur le serveur de destination

Le service Windows Remote Management (WS-management) WINRM n’est pas démarrer automatiquement  et il refuse de démarrer automatiquement

1ère Résolution : Démarrer le service d’administration IIS (demarré –automatique) , puis relance sous powershell de winrm quickconfig , Set-WSManQuickConfig et Enabled-psremoting

clip_image001[6]

2ème message d’erreur : serveur destination

clip_image002

2ème  Résolution : Taper GPEDIT.MSC puis activé : autoriser l’acces au environnement  distant (voir ci-dessous)

clip_image003

Puis le relancer  le script depuis le serveur source  sous powershell

######SERVEURS A TESTER################

$Computerdestination = "SRVxxx"

######SERVICES A VERIFER################

$Servicesname = "MSDTC"

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination

RESULTAT : CONCLUANT

clip_image004

WINRM : Erreur-2144108387 0x8033809D

 

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2144108387 0x8033809D que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de 400 serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces 400 serveurs.

Voici la commande du script powershell qui permet de vérifier la date les derniers redémarrage des serveurs, bien sûr l’exemple ci-dessous porte sur 1 serveur le but étant de démontrer l’erreur winrm.

SCRIPT:

$computer = "SRV01"   
$LastBootUpTime = ([Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime)).ToString("dd'/'MM'/'yyyy-HH'h'mm")

Invoke-Command -ScriptBlock { $LastBootUpTime }  -ComputerName $computer

RESULTAT:

image

ACTIVATION WINRM:

Bien évidement tout ceci est conditionné par le fait qu’il faille activer winrm sur tout les serveurs et que le port 5985 doit être ouvert lui aussi (invoke-command est utilisé, il lance la commande à distance .

sur certains serveurs, j’ai rencontré des problèmes lié à l’activation de WINRM dont l’un des serveurs SRV01.

ERREUR :

clip_image001

IDENTIFICATION DE L’ERREUR :  Apparemment lorsque le rôle serveur WEB est mis en place sur un serveur, il se peut que le TRANSPORT HTTP soit lié à un compte de service web exemple : SVC- WEB

Comment déterminer si un  compte de service est  attribué au service HTTP avec la commande exemple :                                                                       

setspn –q */srv01 

                                                                                                                                Une liste s’affiche ci-dessous : nous voyons clairement en violet que le service http est lié au compte de service web :  SVC- WEB

Checking domain DC=domaine,DC=com

CN= SVC- WEB,OU=Utilisateur,OU=Ordinateurs,DC=domaine,DC=com

      HTTP/SRV01

       HTTP/SRV01.domaine.com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

RESOLUTION : 

à savoir que cela puisse ne pas être une solution car il faut déterminer si les SITES WEB s’appuie sur un compte de service web et si ce compte ne gère pas d’autre site web qui s’appuie dessus , alors la solution appliquer ne permettra plus d’effectuer sous IE une requête sur:

 http://SRV01:80 ou http://SRV01:443                                                                                                                                                            Par contre si avez mis en place un cluster NLB site web exemple : http/clustersrv01-02.domaine.com, alors la solution peut être envisager

La commande permettant de ne plus lier le service http au compte de service WEB (SVC-WEB) est la suivante :

- Setspn   –D  http://srv01  SVC-WEB

- Setspn   –D  http://srv01.domaine.com SVC-WEB

Lorsque vous effectuer de nouveau la commande query :  setspn -q */srv01 nous voyons de nouveau  qui est lié au compte d’ordinateur  et plus au compte de service WEB si vous effectuer de nouveau  WINRM QC cela fonctionnera.

Checking domain DC=domaine,DC=com

CN= SRV01,OU=server,OU=Ordinateurs,DC=domaine,DC=com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

 

 

Powershell: Gestion des erreurs sur Cmdlet

 

Dans mon précédent blog, je vous est montré comment on pouvait mettre en place la gestion d’erreur sur des commandes sous powershell qui ne sont pas des CMDLET, cette fois-ci nous allons voir comment appliquer la gestion d’erreur sur une CMDLET

PERIMETRE: Dans le cadre de l’amélioration des script powershell concernant la vérification des services après le redémarrage des serveurs en production chez un de nos client, celui-ci à laisser le soin au service architecture de trouver une solution.

 

Mon script d’origine:

######SERVEURS A REDEMARRER################

$Computerstring = "orches1"
$Computerdestination = $Computerstring.Split(",")

######SERVICES A ARRETER ET REDEMARRER################

$Servicesstring = "wudfsvc"
$Servicesname = $Servicesstring.Split(",")

######LOG CREER POUR LA VERIFICATION AVANT L'ARRET DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR SUR SYNTAXE Command###
$StatusService = foreach ($vm in $Computerdestination){
         get-Service -ComputerName $vm -name $Servicesname | select status,name,machinename }
       

#GESTION ERREUR DES SERVICES

$ExitCodeService = foreach ($SRVservices in $StatusService) {
if ($($SRVservices.status) -eq "Running"){
"Success : Service(s) Running" + $SRVservices
}else{
"Error : Service(s)" + $SRVservices
}
}

$ErrorStatusSVC = if ($StatusService -eq $null){
"Error : Service(s) "
}else{
"Success : Service(s)"
}  

Voici le résultat pour les sortie erreurs:

$ExitCodeService

image

$ErrorStatusSVC

image

Vous voyez au dessus $ExitCodeService prend en compte que le service wudfsvc étant arrêté comme SUCCESS condition voulu ceci est normal et que $ErrorStatusSVC à été mise en place pour anticipé les erreurs $ExitCodeService si aucune valeur ne ressort ($ExitCodeService = VIDE) cela peut être une erreur de syntaxe, de service ou de serveurs inaccessible ou inexistant

Par contre aucune erreur détailler il faut effectuer une recherche supplémentaire.

 

Mon script amélioré:

######SERVEURS A REDEMARRER################

$Computerstring = "orches1"
$Computerdestination = $Computerstring.Split(",")

######SERVICES A ARRETER ET REDEMARRER################

$Servicesstring = "wudfsvc"
$Servicesname = $Servicesstring.Split(",")

######LOG CREER POUR LA VERIFICATION AVANT L'ARRET DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR SUR SYNTAXE Command###

$StatusService =
Try {
foreach ($vm in $Computerdestination){
         get-Service -ComputerName $vm -name $Servicesname -ErrorAction stop | select status,name,machinename
        }
}catch{
   "$vm => " + $Error[0]
   }

#GESTION ERREUR DES SERVICES

$ExitCodeService =                                                                                         foreach ($SRVservices in $StatusService) {
            if ($($SRVservices.status) -eq "stopped"){
                    "Success:" + $SRVservices
            }else{
                   "Error:" + $SRVservices
            } 
    }

Voici le résultat pour la sortie d’erreur:

La correction se base sur la gestion d’erreur avec les commandes Try et Catch

Dans la partie Try  entre crochets, la commande get-service doit obligatoirement avoir l’option qui permet la sortie d’erreur qui se nomme        –ErrorAction stop cela permettra d’avoir dans la partie catch les messages d’erreur le déroulement du processus $Error[0] . 

Message des erreurs qui sont géré dans : $StatusService

image

Erreur sur le compte d’ordinateur inexistant ou inaccessible:

image

Erreur sur le service inexistant ou inaccessible:

image

Erreur sur la syntaxe commande get-service:

image

Les messages de sortie sont aussi retransmis dans la variable  $ExitCodeService à l’aide des conditions if et else