Question 1er script, 1ers problèmes

Je suis de retour plus vite que prévu. Mes scripts semblent marcher sur mon ordinateur principal, mais lorsque j'ai voulu les mettre aussi sur l'autre ordinateur de la maison, j'ai une erreur incompréhensible.
D'abord le script
[code:1]$ServName=(get-wmiobject win32_service |where {$_.name -like \"*Cloud Station Backup*\"}).name
stop-service $ServName
[/code:1]
La première ligne marche parfaitement, puisque si je l'exécute à la console, j'obtiens
[code:1]PS C:\Users\Josette> $servname=(get-wmiobject win32_service |where {$_.name -like \"*Cloud Station Backup*\"}).name

PS C:\Users\Josette> $servname
Cloud Station Backup VSS Service x64[/code:1]
Mais si j'essaie d'exécuter la 2ème, voici le résultat pour moi incompréhensible
[code:1]PS C:\Users\Josette> stop-service $servname
stop-service : Le service «Cloud Station Backup VSS Service x64 (Cloud Station
Backup VSS Service x64)» ne peut pas être arrêté en raison de l'erreur suivante:
Impossible d'ouvrir le service Cloud Station Backup VSS Service x64 sur l'ordinateur
'.'.
Au caractère Ligne:1 : 1
+ stop-service $servname
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError : (System.ServiceProcess.ServiceController:
ServiceController) [Stop-Service], ServiceCommandException
+ FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Commands.Stop
ServiceCommand
[/code:1]
Pourquoi donc PS ne trouve-t-il pas le service dont le nom vient d'être donné par PS lui même???
Je vais essayer de contourner ce que pour l'instant j'interprète comme un bug, mais je n'aime pas penser que peut-être il y a une faute de ma part que je ne vois pas.
Est-ce le cas ?
gabier

Laurent, merci de ta téponse,
Le message d'erreur ne dit pas qu'il ne peut pas l'arrêter, mais qu'il ne peut pas \"l'ouvrir\". J'ai interprété \"ouvrir\" comme \"trouver\". Apparemment j'interprète mal ...
Je signale aussi que le start-service ne marche pas non plus, avec même message d'erreur.
Je vais désinstaller l'application et la réinstaller, parce que si ça marche sur un ordinateur et pas sur un autre, avec même windows 10, il y a des chances que l'appli et/ou son service, soit responsable.
A suivre ...

gabier écrit:
Pourquoi donc PS ne trouve-t-il pas le service dont le nom vient d'être donné par PS lui même???
Je vais essayer de contourner ce que pour l'instant j'interprète comme un bug, mais je n'aime pas penser que peut-être il y a une faute de ma part que je ne vois pas.
Est-ce le cas ?
gabier[/quote]

Bonjour gabier,

Je reproduis ton problème pour ce service.

Pour moi le bug est côté développement du service par Synology. Premier point étrange : Le 'name' ne devrait pas correspondre à la 'description' du service (devrrait être un nom court).

[code:1]
PS>Get-WMIObject -Query \"select * from win32_service where name='Cloud Station Backup VSS Service x64'\" | select
*


PSComputerName : xxxxxxxx
Name : Cloud Station Backup VSS Service x64
Status : OK
ExitCode : 0
DesktopInteract : False
ErrorControl : Normal
PathName : \"C:\Program Files (x86)\Synology\CloudStationBackup\bin\vss-service-x64.exe\"
ServiceType : Own Process
StartMode : Auto
__GENUS : 2
__CLASS : Win32_Service
__SUPERCLASS : Win32_BaseService
__DYNASTY : CIM_ManagedSystemElement
__RELPATH : Win32_Service.Name=\"Cloud Station Backup VSS Service x64\"
__PROPERTY_COUNT : 25
__DERIVATION : {Win32_BaseService, CIM_Service, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER : xxxxxxxx
__NAMESPACE : root\cimv2
__PATH : \\PWF79088\root\cimv2:Win32_Service.Name=\"Cloud Station Backup VSS Service x64\"
AcceptPause : False
AcceptStop : True
Caption : Cloud Station Backup VSS Service x64
CheckPoint : 0
CreationClassName : Win32_Service
Description : This service enables the Synology Cloud Station Backup to synchrnoize locked file using
Volume Shadow Copy service.
DisplayName : Cloud Station Backup VSS Service x64
InstallDate :
ProcessId : 456
ServiceSpecificExitCode : 0
Started : True
StartName : LocalSystem
State : Running
SystemCreationClassName : Win32_ComputerSystem
SystemName : xxxxxxxx
TagId : 0
WaitHint : 0
Scope : System.Management.ManagementScope
Path : \\xxxxxxxx\root\cimv2:Win32_Service.Name=\"Cloud Station Backup VSS Service x64\"
Options : System.Management.ObjectGetOptions
ClassPath : \\xxxxxxxx\root\cimv2:Win32_Service
Properties : {AcceptPause, AcceptStop, Caption, CheckPoint...}
SystemProperties : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers : {dynamic, Locale, provider, UUID}
Site :
Container :

[/code:1]

Un contournement :

[code:1]
PS>(Get-WMIObject -Query \"select * from win32_service where name='Cloud Station Backup VSS Service x64'\"«»).stopse
rvice()
[/code:1]

Pour le démarrer, même contournement possible en utilisant WMI et la méthode 'startservice()' du service :

[code:1]
PS>(Get-WMIObject -Query \"select * from win32_service where name='Cloud Station Backup VSS Service x64'\"«»).starts
ervice()
[/code:1]

@ +<br><br>Message édité par: MatthewBETTON, à: 8/01/18 12:13

Je confirme que le 'service name' ne doit pas contenir d'espace (+ limité à 256 caractères) lorsqu'on utilise 'Stop-Service'.

Dans le cas de ce service créé par le msi fourni par Synology : 'Service Name' = 'Service Displayname'

La commande 'sc' n'est pas impactée par ce problème dans le nom.

[code:1]
C:\WINDOWS\system32&gt;sc stop \&quot;Cloud Station Backup VSS Service x64\&quot;

SERVICE_NAME: Cloud Station Backup VSS Service x64
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x2
WAIT_HINT : 0xbb8

C:\WINDOWS\system32&gt;sc start \&quot;Cloud Station Backup VSS Service x64\&quot;

SERVICE_NAME: Cloud Station Backup VSS Service x64
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 3976
FLAGS :
[/code:1]

C'est d'ailleurs la raison pour laquelle le service a pu être créé : à première vue pas de restriction système sur ce point.

CreateService function

lpServiceName [in]
The name of the service to install. The maximum string length is 256 characters. The service control manager database preserves the case of the characters, but service name comparisons are always case insensitive. Forward-slash (/) and backslash (\) are not valid service name characters.

Si on liste tous les services (système et autre dont tiers), il n'y a jamais d'espace dans le nom du service et il s'agit d'un \&quot;nom court\&quot;.

Ce n'est pas un 'bug' powershell dans le sens où le nom du service ne devrait pas contenir d'espace. Mais le système n'envoie pas d'erreur lorsque l'on créé un service dont le nom contient des espaces

Je me sers de moins en moins des Cmdlets Start-Service, Stop-Service et Get-Service, qui n'ont pas évoluées depuis les premières versions de PowerShell. Le stop et le start ne prennent par exemple pas de paramétre '-ComputerName'.

Soit j'utilise WMI, soit j'utilise la classe 'System.Management'. Cette dernière permettant notamment d'utiliser un Timeout lors de l'énumération de services (cf. bug WMI qui avec certaines machines 'en pannes', ne redonne pas la main avec un message d'erreur mais reste indéfiniment connecté ; Et ça aussi, ça fait un moment que ça dur...).

Merci Matthew, pour la solution de contournement.
J'aurai déjà appris que les objets PowerShell ont des méthodes.
J'ai fait beaucoup d'essais je vais essayer d'expliquer ça.
1. Pour démarrer et tuer les processus, aucun problème.
2. Pour démarrer ou arrêter un service c'est moins net
a) A la console PS la solution de contournement marche à tous les coups, et sur mes deux ordinateurs.
b) une fois \&quot;compilés\&quot; avec ps2exe et packagés en tâche Windows, de nouveau les scripts marchent sur un ordinateur et pas sur l'autre.
Sur cet ordinateur récalcitrant, le script s'exécute et ne produit aucune erreur, mais le service n'est pas démarré pour startservice() ou pas arrêté pour stopservice().
Les deux ordinateurs sont sous Windows 10 Famille, je ne vois pas pour l'instant d'où peut venir la différence.
rectification : Après vérification sur l'ordinateur \&quot;bon élève\&quot;, celui-ci ne ferme (ouvre) pas non plus le service avec la tâche compilée et packagée, alors que c'est fait correctement à la console PS.
Donc maintenant j'ai le même comportement fautif sur les 2 ordinateurs, et on peut accuser la \&quot;compilation\&quot; de PS2exe.
Quelqu'un a-t-il un procédé pour mettre un script ps en tâche planifiée de Windows sans passer par la compilation PS2EXE ?
Je vais chercher de mon côté.


gabier<br><br>Message édité par: gabier, à: 8/01/18 19:16