Compartir a través de


Error invalidShellID en RPS en Microsoft 365

Número de KB original: 3090768

Síntomas

Cuando un script se ejecuta durante mucho tiempo o cuando ejecuta un cmdlet administrativo en PowerShell remoto (RPS) en Microsoft 365, recibe intermitentemente un mensaje de error similar al siguiente:

Error al procesar datos para un comando remoto con el siguiente mensaje de error:
[ClientAccessServer=Server1,BackEndServer=Server2,RequestId=<>,TimeStamp=DateTime] [FailureCategory=WSMan-InvalidShellID] Error en la solicitud del Shell remoto de Windows con ShellId <> porque no se encontró el shell en el servidor. Las posibles causas son: el ShellId especificado es incorrecto o el shell ya no existe en el servidor. Proporcione el ShellId correcto o cree un nuevo Shell y vuelva a intentar la operación. Para obtener más información, consulte el tema about_Remote_Troubleshooting Ayuda.

+ CategoryInfo : OperationStopped: (mail.contoso.com:String) [], PSRemotingTransportException

+ FullyQualifiedErrorId : JobFailure

+ PSComputerName : mail. contoso.com

Causa

Este problema ocurre si se cumplen las siguientes condiciones:

  • Usa una cuenta asociada a un usuario habilitado para correo (MEU) en un entorno de varias regiones.
  • Connections se enrutan a través de una región que difiere de la región del usuario.

Este error puede producirse cuando se quita un servidor back-end de la rotación que se va a actualizar. Además, este problema se produce con poca frecuencia.

Solución

Escenario 1: cuando un script se ejecuta durante mucho tiempo o cuando se detiene el flujo de trabajo automatizado

En este escenario, es posible que tenga que cambiar el script para volver a conectarse automáticamente si se quita un servidor de la rotación mientras está en curso. Para ello, use el control de errores adecuado en el script para detectar errores. A continuación, vuelva a conectar y reinicie los procesos.

Escenario 2: al ejecutar un cmdlet administrativo en RPS

En este escenario, debe volver a ejecutar el cmdlet . Se debe ponerse en contacto con un servidor back-end diferente y, a continuación, el cmdlet debe ejecutarse correctamente.

Nota:

En una implementación de Exchange Online de varias regiones, se recomienda usar cuentas administrativas habilitadas para buzones. Esto garantiza que las conexiones RPS se realicen a través del entorno actual. Si la cuenta administrativa está asociada a un MEU, las conexiones se pueden enrutar a través de la otra región. Este comportamiento puede retrasar la conexión o desencadenar errores.

Microsoft puede requerir un seguimiento de Fiddler para investigar este problema. Si es necesario, un ingeniero de soporte técnico enviará un paquete de diagnósticos de soporte técnico para capturar y cargar esta información de forma segura. Para capturar esta información en el seguimiento de Fiddler, debe agregar una opción de sesión de PowerShell con el ProxyAccessType parámetro establecido en IEConfig. Por ejemplo:

Import-PSSession (New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.contoso.com/powershell -Credential (Get-Credential) -Authentication Basic -AllowRedirection -SessionOption (New-PSSessionOption -ProxyAccessType IEConfig))

Más información

Para obtener más información sobre el control de errores, vea Weekend Scripter: Using Try, Catch, Finally blocks for PowerShell error handling (Scripter de fin de semana: uso de bloques Try, Catch y Finally para el control de errores de PowerShell).