Sistema local
Máximos privilegios dentro de la máquina, y ninguna identidad fuera de ella.
Por eso un servicio con esta cuenta no puede llegar a una carpeta de red: en la red no es nadie.
Servicios: lo mismo, con otros nombres
Un servicio de Windows es exactamente lo que un servicio en Linux: un programa que corre de fondo, sin ventana, arrancado por el sistema. Cambian las herramientas, no la idea.
Los comandos del día a día
# Como esta un servicio
Get-Service -Name W3SVC
# Todo lo que esta corriendo
Get-Service | Where-Object Status -eq 'Running'
# Manejarlo
Restart-Service -Name W3SVC
Stop-Service -Name W3SVC
Start-Service -Name W3SVC
# Que arranque solo al encender el servidor
Set-Service -Name W3SVC -StartupType AutomaticEse -StartupType Automatic es el equivalente exacto del
habilitar de Linux, y esconde la misma trampa: un servicio arrancado a mano
funciona perfectamente hasta el primer reinicio. Si el tipo de inicio
es Manual, no vuelve solo.
La cuenta con la que corre un servicio
Esto no tiene equivalente directo en Linux y es la causa número uno de un problema desconcertante: «el script funciona cuando lo ejecuto yo, pero como servicio falla».
Un servicio no corre con tu usuario. Corre con una cuenta propia -Sistema local, Servicio de red, o una cuenta de servicio-, y esa cuenta tiene otros permisos y otro entorno.
Con qué cuenta corre, y qué implica
Servicio de red
Pocos privilegios locales, pero sí se presenta en la red como la cuenta del equipo.
Es la adecuada cuando el servicio necesita alcanzar otro servidor.
Cuenta de servicio propia
Una cuenta creada para eso, con exactamente los permisos que necesita y ninguno más.
Es lo correcto para aplicaciones importantes, aunque haya que mantener su contraseña.
De aquí sale también el fallo de las unidades de red. Una unidad mapeada -la Z: que ves tú- pertenece a tu sesión. Un servicio corriendo con otra cuenta no la ve, y el error dice «ruta no encontrada», que despista completamente.
La solución no es mapear la unidad para el servicio: es usar la ruta de red completa y darle permisos a la cuenta con la que corre.
Ver con qué cuenta corre cada servicio
Get-CimInstance Win32_Service |
Select-Object Name, StartName, State, StartMode |
Where-Object State -eq 'Running' | Format-Table -AutoSizeResultado
Name StartName State StartMode ---- --------- ----- --------- W3SVC LocalSystem Running Auto MSSQLSERVER NT Service\MSSQLSERVER Running Auto Spooler LocalSystem Running Auto
Tareas programadas
Es el equivalente de las tareas programadas de Linux: ejecutar algo a una hora fija. Y trae su propia trampa, tan silenciosa como la de la zona horaria del otro curso.
Crear una tarea que sí se ejecute
$accion = New-ScheduledTaskAction -Execute "PowerShell.exe" `
-Argument "-File C:\Scripts\respaldo.ps1"
$disparador = New-ScheduledTaskTrigger -Daily -At 3:15AM
# Con esta cuenta corre AUNQUE NADIE haya iniciado sesion
$cuenta = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
Register-ScheduledTask -TaskName "Respaldo diario" `
-Action $accion -Trigger $disparador -Principal $cuenta
# Comprobar si de verdad se ejecuto
Get-ScheduledTaskInfo -TaskName "Respaldo diario"Resultado
LastRunTime : 2026-09-07 3:15:02 LastTaskResult : 0 NextRunTime : 2026-09-08 3:15:00
La trampa: una tarea configurada para «ejecutar solo si el usuario inició sesión» no se ejecuta nunca en un servidor, porque en un servidor nadie tiene sesión abierta a las tres de la mañana.
Y no da error: sencillamente no pasa nada. Se descubre meses después, cuando hace
falta el respaldo que nunca se hizo. Por eso la tarea se registra con una cuenta que
corre sin sesión -como en el ejemplo- y por eso se comprueba
LastRunTime.
Ese LastTaskResult : 0 significa que terminó bien. Cualquier
otro número es un fallo, y LastRunTime vacío significa que
nunca se ha ejecutado. Son los dos datos que hay que mirar para saber
si una tarea está viva.
El Visor de eventos
Es el registro central de Windows, el equivalente del diario del sistema en Linux. Todo lo importante queda escrito ahí: arranques, fallos de servicios, intentos de inicio de sesión, errores de aplicaciones.
Está dividido en registros, y tres concentran casi todo lo que se consulta.
Consultarlo con PowerShell
# Errores del sistema en las ultimas 24 horas
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 2 # 2 = Error
StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Id, ProviderName, Message -First 20
# Intentos de inicio de sesion FALLIDOS
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625 } -MaxEvents 20Los tres registros y lo que cuentan
Sistema
El sistema operativo y sus servicios: arranques, apagados, controladores, servicios que fallaron.
Es donde se mira cuando «el servidor se reinició solo».
Aplicación
Lo que escriben los programas instalados: bases de datos, servidor web, aplicaciones del proveedor.
Cuando una aplicación falla, el detalle está aquí.
Seguridad
Inicios de sesión, correctos y fallidos, y cambios en cuentas y permisos.
Es el registro que demuestra quién hizo qué, y el que hay que conservar.
Identificadores de evento que conviene conocer
Adivina qué significa cada uno antes de voltear.
Un servicio no arranca: el mismo procedimiento
1. Ver su estado y su tipo de inicio
Get-Service -Name X | Select-Object Status, StartTypeSi el tipo es Manual o Disabled, ahí está la respuesta al «no arrancó tras el reinicio».
2. Buscar su rastro en el registro
Filtrar el registro Sistema por errores de la última hora, o el de Aplicación si es un programa.
Se busca el primer error, no el último: los siguientes suelen ser consecuencia.
3. Comprobar con qué cuenta corre
Si el fallo es de permisos o de acceso a una ruta de red, casi siempre es la cuenta del servicio.
4. Arreglar, reiniciar y verificar
Restart-Servicey volver a mirar el estado.Terminar sin verificar es no haber terminado: el servicio puede arrancar y caerse tres segundos después.
Compruébalo tú mismo
Un script funciona cuando lo ejecutas tú, pero como servicio falla al leer una carpeta de red. ¿Por qué?
Un servicio con Sistema local no es nadie fuera de la máquina, y
las unidades mapeadas pertenecen a tu sesión. Se usa la ruta de red completa y
se dan permisos a la cuenta del servicio.
Una tarea de respaldo lleva meses sin ejecutarse y no aparece ningún error. ¿Qué revisas?
En un servidor nadie tiene sesión abierta de madrugada, así que
la tarea no se lanza nunca y no da error. Se comprueba con
LastRunTime.En el registro de seguridad ves miles de eventos 4625 desde una misma dirección. ¿Qué significa?
El 4625 es un inicio de sesión fallido. Unos pocos son normales;
miles seguidos desde la misma dirección son un ataque en curso.
Lo que sigue
Acabas de ver los intentos de entrada en el registro. La última lección va justo ahí: copias que restauran, el ciclo de actualizaciones, el firewall, y por qué un escritorio remoto abierto a internet es el error más caro que se puede cometer con un servidor Windows.
Siguiente: Copias, actualizaciones y endurecimiento
Continuar ← Active Directory, en corto