Better Windows Servicessc.exe, Get-Service, et cet outil
Les deux sont déjà sur la machine, et les deux resteront utiles. Cette page parle de l'endroit où ils s'arrêtent - et elle dit franchement où ils restent la meilleure réponse.
Où chacun s'arrête
sc.exe
Il atteint presque tout ce que sait le gestionnaire de contrôle des services, et ne vous dit rien sur la façon de le demander. La syntaxe date des années quatre-vingt-dix - sc config X start= auto, où l'espace après le signe égal est obligatoire et son absence est un échec silencieux à faire ce que vous vouliez.
Il répond sur une entrée à la fois. Pas de filtrage, pas de sortie qu'un script peut analyser sans écrire un analyseur, et pas d'aperçu : sc stop marche ou renvoie un nombre.
Get-Service et les cmdlets *-Service
De vrais objets, un pipeline, et une vue superficielle. Dans Windows PowerShell 5.1, celui livré avec Windows, Get-Service n'affiche ni le compte sous lequel un service s'exécute ni sa description. PowerShell 7 affiche les deux, et le chemin de lancement aussi, et s'installe séparément.
Stop-Service -Force veut dire « même si quelque chose en dépend » - il arrête les dépendants, et vous le dit après plutôt qu'avant.
Les mêmes questions, de trois façons
| Question | Avec ce qui est sur la machine | Ici |
|---|---|---|
| Ce qui devrait tourner et ne tourne pas | Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } |
bws list --query "start:auto !status:running" |
| Quels services ont un exécutable non signé | Lire chaque chemin de lancement, le résoudre, appeler Get-AuthenticodeSignature sur chacun - un script, pas une commande |
bws list --query "signed:no" |
| Ce que l'arrêt de celui-ci entraînerait | sc enumdepend X, puis lire la liste et décider soi-même |
bws stop X --dry-run --dependents, qui est le plan qui s'exécuterait |
| Ce qui a changé depuis la semaine dernière | Rien, sauf si vous avez écrit vous-même le collecteur | bws snapshot diff before.json --live |
| Qui a changé le type de démarrage, et quand | Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7040 }, puis lire le message de chaque événement |
bws history Spooler, dont la première ligne dit jusqu'où remonte le journal |
| Sortie lisible par une machine | Des objets avec PowerShell, du texte avec sc.exe |
--json sur chaque commande, sur la sortie standard, avec les avertissements sur l'erreur standard |
Quand cet outil n'est pas d'accord avec sc.exe sur un service, c'est un bogue ici. Une partie de la suite de tests exécute les deux contre la machine sur laquelle elle tourne et les compare entrée par entrée, et une différence entre les deux est la chose la plus utile à mettre dans un ticket.
Quand continuer à utiliser ce que vous avez
- Vous êtes sur une machine que vous ne toucherez qu'une fois. Les deux sont déjà là et rien n'a à passer une politique.
- Vous devez changer le compte, le chemin de lancement ou les actions de récupération.
sc.exefait les trois. Cet outil affiche le compte et le chemin de lancement et ne change ni l'un ni l'autre, et ne lit les actions de récupération que pour avertir avant de terminer un processus. - Vous devez créer ou supprimer un service.
sc createetsc delete. Pas ici, volontairement. - Vous êtes déjà plongé dans un pipeline PowerShell.
bws list --jsonrevient sous forme d'objets viaConvertFrom-Json, il rejoint donc le pipeline plutôt que de le remplacer.
Ensemble, plutôt qu'à la place
L'outil qui répond à qu'est-ce qui ne va pas sur cette machine et les outils qui changent un réglage ne sont pas le même outil. Posez la question ici, lisez le plan ici, et utilisez ce que vous voulez pour l'exécuter - le plan imprime la ligne de commande qui demande la même chose, et cette ligne est faite pour être copiée.