Desplegar scripts que modifiquen el sistema en varios equipos requiere automatización fiable y privilegios elevados. A continuación encontrarás una guía completa —con ejemplos listos para copiar— que explica por qué tu script sigue ejecutándose sin elevación, cómo corregir la llamada a Start‑Process y qué buenas prácticas aplicar para que la distribución masiva sea segura, reversible y alineada con las políticas de tu organización.
Por qué es imprescindible elevar la sesión
PowerShell se ejecuta, por defecto, con los permisos del usuario que lo lanza. Cuando el script (MyScript.ps1):
- cambia claves de Registro,
- instala software o parches,
- gestiona servicios, certificados o controladores,
necesita pertenecer al contexto «Administrators». Si no lo elevas, el sistema generará errores de acceso denegado o, peor aún, fallos silenciosos que dejan el entorno a medias.
El error más frecuente: pasar los argumentos sin escaparlos
La llamada inicial suele ser:
$CommandLine = "-file 'C:\temp\MyScript.ps1'"
Start-Process -FilePath powershell.exe -Verb RunAs -ArgumentList $CommandLineEl script se invoca, sí, pero en la misma consola actual porque la cadena transmitida a -ArgumentList no se parsea como esperas. Dos puntos críticos:
- Comillas simples externas. Evitan que PowerShell vuelva a dividir la cadena donde encuentre espacios.
- Comillas dobles internas. Aíslan la ruta exacta del script, sobre todo si contiene espacios.
Versión corregida y comentada
$CommandLine = '-ExecutionPolicy RemoteSigned -File "C:\temp\MyScript.ps1"'
Start-Process -FilePath 'powershell.exe' -Verb RunAs -ArgumentList $CommandLineCon esta sintaxis el proceso secundario—ya elevado gracias a -Verb RunAs—recibe los interruptores adecuados y ejecuta el archivo indicado.
Entendiendo -ExecutionPolicy
La política por defecto en la mayoría de estaciones Windows sigue siendo Restricted, que bloquea cualquier script local o remoto. Para evitar escaladas accidentales, las organizaciones suelen elegir:
| Valor | Descripción resumida | Cuándo usarlo |
|---|---|---|
| Restricted | No permite scripts. | Equipos de usuario final sin automatizaciones. |
| AllSigned | Solo scripts firmados digitalmente. | Entornos regulados (PCI, HIPAA). |
| RemoteSigned | Scripts locales sin firma; remotos, firmados. | Servidores internos o laboratorios. |
| Bypass | Sin comprobaciones. | Contenedores efímeros, CI/CD controlado. |
Para la mayoría de despliegues corporativos —donde los scripts se copian previamente a la máquina— RemoteSigned aporta el mejor equilibrio.
Parámetros opcionales que mejoran la estabilidad
-NoProfile: evita cargas lentas o variables inesperadas procedentes del perfil del usuario.-WindowStyle Hidden: oculta la ventana para que la ejecución sea transparente al usuario.-Wait: si necesitas que el script llamador espere la finalización antes de continuar.
$CommandLine = '-NoProfile -ExecutionPolicy RemoteSigned -File "C:\temp\MyScript.ps1"'
Start-Process -FilePath 'powershell.exe' -Verb RunAs -WindowStyle Hidden -ArgumentList $CommandLine -WaitPaso a paso: validación previa a la ejecución
- Verificar la ruta
if (-not (Test-Path 'C:\temp\MyScript.ps1')) { throw "Script no encontrado" } - Confirmar conectividad (si usa recursos remotos)
Test-NetConnection -ComputerName 'intranet' -Port 443 - Registrar en el visor de eventos personalizado para auditoría.
Métodos de distribución masiva
Cuando necesitas desplegar a decenas o cientos de equipos, replicar manual mente el comando no escala. Estas son las opciones más comunes, con sus ventajas y limitaciones:
| Método | Ventajas | Consideraciones |
|---|---|---|
| GPO Startup Script | Ejecuta antes del inicio de sesión. | Requiere reinicio; diagnóstico complejo. |
| Scheduled Task «Run with highest privileges» | Flexibilidad de horario; se reintenta si falla. | Hay que distribuir el .xml o registrarla vía script. |
| Microsoft Intune (Win32 App) | Control de resultados y remediación. | Licenciamiento M365 E3/E5; curva de aprendizaje. |
| Software de despliegue (SCCM, PDQ) | Informes nativos y grupos dinámicos. | Infraestructura existente. |
| Invoke‑Command + PSRemoting | Ejecución simultánea y ad‑hoc. | Requiere Puertos 5985/5986 abiertos y WinRM configurado. |
Cómo comprobar que el script se ejecuta elevado
En la primera línea de MyScript.ps1 añade:
#region ElevationCheck
if (-not ([Security.Principal.WindowsPrincipal] `
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {
Write-Error 'El script no se está ejecutando como Administrador.'
Exit 1
}
#endregionAsí obtienes una salida inequívoca en el registro o la consola de que la elevación ha tenido éxito.
Buenas prácticas de seguridad y mantenimiento
- Firmar digitalmente todos los scripts con un certificado de tu PKI interna.
- Control de versiones Git para rastrear cambios y revertir regresiones.
- Logging centralizado: redirige la salida a una carpeta compartida usando
Start-TranscriptoWrite‑EventLog. - Rollback: incluye un bloque
Try / Catch / Finallyque restaure configuraciones si algo falla. - Inventario previo: ejecuta una consulta WMI para asegurarte de que el equipo cumple los prerequisitos antes de tocarlo.
Troubleshooting: errores comunes y soluciones rápidas
“File cannot be loaded because running scripts is disabled”
Causa: ExecutionPolicy en Restricted. Solución: añadir -ExecutionPolicy RemoteSigned o firmar el script.
La consola elevación aparece y cierra sin mensaje
Añade -NoExit al final de $CommandLine para mantenerla abierta y ver la traza.
PID duplicado en los registros
Cada invocación crea un nuevo proceso. Incluye la fecha y hora en el nombre del log para evitar colisiones.
FAQ
¿Puedo evitar la ventana del UAC?
Sí, creando primero una tarea en el Programador de tareas marcada como «Run with highest privileges» y lanzándola con Schtasks.exe /Run /TN NombreDeTarea. El UAC se eleva en el momento del registro, no en cada ejecución.
¿Cómo pasar parámetros dinámicos al script?
Concatena el resto de argumentos en $CommandLine y usa -- como separador:
$CommandLine = '-ExecutionPolicy RemoteSigned -File "C:\temp\MyScript.ps1" -- -User "' + $env:USERNAME + '"'¿Funciona igual en Windows Server Core?
Sí. Start‑Process no depende de la shell gráfica. Solo asegúrate de que powershell.exe (o pwsh.exe si usas PowerShell 7) está disponible en el PATH.
Conclusión
Escapar correctamente la cadena de argumentos y delegar la elevación a -Verb RunAs soluciona el 90 % de problemas al lanzar scripts con permisos administrativos. Aplica las buenas prácticas descritas—firma digital, logging, ejecución por tareas programadas—y lograrás ciclos de despliegue repetibles, auditables y seguros.