Para consultar el estado de un servicio de Windows con PowerShell utiliza Get-Service -Name NombreDelServicio. Por ejemplo, Get-Service -Name Spooler muestra el estado de la cola de impresión. El resultado permite distinguir un servicio en ejecución de uno detenido, pero no demuestra por sí solo que la aplicación funcione correctamente.
Esta guía reúne consultas de lectura para el equipo local y explica qué cambia al trabajar a distancia o con PowerShell 7. Los ejemplos no arrancan ni detienen servicios. Sustituye los nombres de equipos y servicios por los de tu entorno y recoge primero el estado real antes de plantearte cualquier cambio.
Antes de empezar: comprueba la versión y el equipo
En Windows pueden convivir Windows PowerShell 5.1 y PowerShell 7. No todos los parámetros son iguales entre versiones: un ejemplo antiguo que utiliza Get-Service -ComputerName no se puede trasladar sin cambios a PowerShell 7. Además, la consola puede estar abierta dentro de una sesión remota; comprueba dónde estás consultando.
$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
$env:COMPUTERNAME
Get-Command Get-Service -SyntaxLa sintaxis que muestra tu propia consola es una referencia útil para detectar diferencias. Si el comando no está disponible, revisa el sistema operativo y el entorno que utilizas: la referencia actual de Get-Service para PowerShell 7 lo documenta como un cmdlet de Windows.
Consultar un servicio por nombre o nombre visible
Windows distingue el nombre interno del servicio de su nombre para mostrar. El nombre visible puede estar traducido y contener espacios; el nombre interno suele ser más apropiado para un script que deba funcionar en equipos con idiomas distintos. Consulta ambos antes de escribir un filtro definitivo.
Get-Service -Name Spooler |
Select-Object Status,Name,DisplayName
Get-Service -Name 'Win*' |
Select-Object Status,Name,DisplayNameEl primer ejemplo consulta un servicio concreto. El segundo utiliza un patrón sobre el nombre interno, por lo que puede devolver varios resultados. Si necesitas buscar por el texto que ves en la aplicación Servicios, utiliza -DisplayName con el texto correspondiente a tu idioma.
Un mensaje que indica que no se ha encontrado el servicio no significa que esté detenido. Puede haber un error en el nombre, una diferencia entre ediciones de Windows o una característica que no está instalada. Identifica primero el servicio y después interpreta su estado.
Filtrar servicios en ejecución y detenidos
Sin parámetros, Get-Service devuelve los servicios del equipo local. Puedes filtrar los objetos antes de elegir las columnas que vas a mostrar. Mantén el orden de la canalización: primero consulta, después filtra, selecciona los datos y deja el formato de presentación para el final.
Get-Service |
Where-Object { $_.Status -eq 'Running' } |
Select-Object Status,Name,DisplayName
Get-Service |
Where-Object { $_.Status -eq 'Stopped' } |
Select-Object Status,Name,DisplayNameUna lista de servicios detenidos no es automáticamente una lista de incidencias. Algunos se inician a petición, dependen de una característica opcional o permanecen inactivos por diseño. Para decidir si falta un servicio, necesitas saber qué función debe prestar ese equipo y cuál es su configuración prevista.
También existen estados transitorios. Si observas un estado de inicio o parada pendiente, recoge la hora y vuelve a consultar antes de concluir que el servicio está bloqueado. Una lectura aislada no describe toda su evolución ni sustituye la revisión de eventos del sistema.
Ver el tipo de inicio, la cuenta y la ruta con CIM
El estado de ejecución y el modo de inicio responden a preguntas distintas. Un servicio puede estar detenido y configurado como manual, o encontrarse iniciado aunque su arranque no sea automático. Para revisar más propiedades del servicio puedes consultar la clase Win32_Service.
Get-CimInstance -ClassName Win32_Service -Filter "Name='Spooler'" |
Select-Object Name,State,StartMode,StartName,PathNameEn esta salida, State indica el estado observado, StartMode el modo de inicio y StartName la cuenta configurada. PathName ayuda a identificar el ejecutable y sus argumentos. No cambies estos campos solo porque difieran de otro equipo: una aplicación puede requerir una cuenta o una configuración específica.
La referencia de Get-CimInstance describe cómo consultar clases y limitar los resultados. En el ejemplo se filtra por un único nombre para que el diagnóstico siga siendo manejable y puedas comparar la misma propiedad entre varias comprobaciones.
Cómo comprobar servicios en un equipo remoto
En Windows PowerShell 5.1 existe el parámetro -ComputerName de Get-Service. La referencia de esa versión lo incluye en su sintaxis. No está presente en la sintaxis de PowerShell 7; copiarlo en esa consola produce un error de parámetro antes de realizar la consulta.
Una opción para administrar equipos remotos consiste en ejecutar la consulta dentro de una sesión de PowerShell Remoting que ya esté habilitada y autorizada en tu organización. El siguiente ejemplo consulta Spooler en un servidor Windows de ejemplo. No habilita remoting ni modifica reglas de red.
Invoke-Command -ComputerName 'servidor01' -ScriptBlock {
Get-Service -Name Spooler |
Select-Object Status,Name,DisplayName
}Si la consulta remota falla, separa la disponibilidad del equipo, la resolución de su nombre, el transporte de administración y los permisos de la cuenta. Que una aplicación responda en Escritorio remoto no garantiza que PowerShell Remoting esté disponible, y una conexión de administración fallida no demuestra que Spooler esté detenido.
Para ampliar la comprobación con CIM puedes utilizar una sesión CIM permitida por tu entorno. No introduzcas nombres de usuario o contraseñas en texto dentro de un script compartido. Primero valida una consulta contra un único equipo y después diseña el alcance de un inventario mayor.
Revisar dependencias sin detener nada
Las dependencias explican parte del contexto de un servicio. Hay servicios que necesita para funcionar y otros que dependen de él. Confundir esas dos direcciones puede llevar a interpretar mal un fallo o a subestimar las consecuencias de una parada posterior.
Get-Service -Name Spooler -RequiredServices |
Select-Object Status,Name,DisplayName
Get-Service -Name Spooler -DependentServices |
Select-Object Status,Name,DisplayNameUtiliza los resultados como una lista de comprobación: identifica cada componente, consulta su estado y revisa los eventos relacionados con la hora del problema. Una dependencia satisfecha tampoco garantiza que la aplicación superior esté sana; puede haber errores de configuración, autenticación, colas o conexiones externas.
Guardar un inventario legible en CSV
Si necesitas comparar consultas o adjuntar un resultado a una incidencia, guarda columnas concretas en lugar de copiar una captura de pantalla. El siguiente ejemplo crea un CSV en la carpeta temporal del perfil y añade una marca de tiempo al nombre para distinguir los informes.
$rutaInforme = Join-Path $env:TEMP ('servicios-{0}.csv' -f (Get-Date -Format 'yyyyMMdd-HHmmss'))
Get-Service |
Select-Object Name,DisplayName,Status |
Export-Csv -LiteralPath $rutaInforme -NoTypeInformation -Encoding UTF8
$rutaInformeEste inventario no guarda los ejecutables ni la configuración completa y no sirve como copia de seguridad del sistema. Documenta junto al archivo el equipo consultado, la hora y la versión de PowerShell. Si cambias la carpeta de salida, comprueba que existe y que la cuenta tiene permiso para escribir en ella.
No coloques Format-Table antes de Export-Csv. El formato prepara objetos de presentación; para exportar datos útiles debes conservar las propiedades del servicio hasta la operación de escritura. Si necesitas una tabla visual, crea esa presentación por separado.
Qué hacer con los errores más habituales
| Resultado | Qué revisar primero |
|---|---|
| No se encuentra un servicio | Nombre interno, características instaladas y equipo consultado |
| No existe el parámetro ComputerName | Edición y versión de PowerShell |
| Acceso denegado | Permisos de la cuenta y alcance de la consulta |
| La consulta remota no conecta | Resolución, transporte de administración y políticas del entorno |
| El servicio está Running pero la aplicación falla | Eventos, configuración y una prueba de la función de la aplicación |
Algunas consultas o propiedades requieren permisos adicionales. Antes de abrir una consola elevada, comprueba si la operación lo necesita y si estás autorizado; la guía sobre ejecutar PowerShell como administrador explica ese contexto. Elevar la consola no corrige un nombre equivocado ni habilita automáticamente la administración remota.
Ejemplo de una comprobación ordenada
Imagina que una persona no puede imprimir desde una sesión remota. Empieza anotando en qué equipo aparece el problema y desde qué cuenta realizas la consulta. Comprueba Spooler en ese equipo concreto, conserva su estado y revisa si el fallo afecta a una impresora o a todas. No mezcles resultados del servidor con resultados del puesto del usuario sin identificarlos.
Si el servicio figura en ejecución, continúa con una prueba de la función que falla y con los eventos de la misma franja horaria. Si está detenido, consulta su modo de inicio y su contexto antes de decidir qué actuación corresponde. En ambos casos has reducido una pregunta general, «¿por qué no imprime?», a observaciones concretas que otra persona puede verificar.
Este mismo método sirve para otros servicios: elegir el equipo correcto, identificar el componente, consultar sin modificar y contrastar la función. Así evitas convertir una lista de estados en un conjunto de reinicios sin diagnóstico.
Aplicar el diagnóstico a una incidencia real
Si falla una consulta de Active Directory, revisar el servicio correcto es solo una parte del diagnóstico. Continúa con la guía del error de servidor predeterminado y ADWS para distinguir los problemas de servicio de los de localización del controlador de dominio.
En una incidencia de impresión, consulta el estado de Spooler junto con la configuración de la sesión y las impresoras. La guía de Remote Desktop Easy Print aborda el contexto de redirección en Escritorio remoto. No reinicies un servicio como primer paso si todavía no has recogido los datos que permiten entender el fallo.
Un procedimiento útil termina con un resultado reproducible: equipo, versión, comando utilizado, estado observado y siguiente comprobación. Con esa información puedes escalar una incidencia sin convertir un estado aislado en una explicación completa. Los comandos de consulta ayudan a reunir pruebas; cualquier cambio posterior debe responder a una causa identificada y a las necesidades del entorno.
