¿Qué causaría un ## MS_PolicyEventProcessingLogin ## huérfano?

Esta mañana noté que mi registro SQL se estaba llenando con el siguiente mensaje:

El proceso activado '[dbo]. [Sp_syspolicy_events_reader]' ejecutándose en la cola 'msdb.dbo.syspolicy_event_queue' genera lo siguiente:
'No se puede ejecutar como el principal de la base de datos porque el principal "## MS_PolicyEventProcessingLogin ##" no existe, este tipo de el director no puede ser suplantado, o no tiene permiso.

Ejecutar lo siguiente EXEC sp_change_users_login 'report'reveló que el inicio de sesión había quedado huérfano.

Pude solucionarlo ejecutando lo siguiente como se recomienda en esta publicación de MSDN .

EXEC sp_change_users_login 
    'Auto_Fix', '##MS_PolicyEventProcessingLogin##', 
    NULL, 'fakepassword'

Pero la pregunta sigue siendo: ¿qué demonios habría causado que este director quedara huérfano en primer lugar? Buscar en Google e investigar revela que otros han tenido este problema, pero aún no he encontrado una descripción de la causa. Nada de lo que tenga conocimiento de lo que tengo conocimiento ocurrió en el momento en que comenzó a aparecer el error.

Movimos todo el servidor a un modelo de almacenamiento SAN el verano pasado, restauramos todo (incluido msdb) durante ese movimiento, pero eso fue hace meses. Fue solo algo reciente que hizo que el síntoma se manifestara, ya que no aparece en el registro antes de hace un par de semanas.

Actualizamos dos servidores (de SQL 2000) a SQL 2008R2 mediante la actualización en contexto. Comenzamos a recibir estos mensajes en los registros de SQL después de la actualización. No cambiamos este u otros inicios de sesión o usuarios durante el proceso de actualización.

Supongo que el proceso de actualización dejó dos cuentas ( ##MS_PolicyEventProcessingLogin##y ##MS_PolicyTsqlExecutionLogin##) huérfanas.

EXEC sp_change_users_login 'Auto_Fix', '<User Name>' solucionó este problema.

Causas típicas: alguien abandona el inicio de sesión (pensando que está limpiando inicios de sesión incorrectos) o restaura una de las bases de datos del sistema.

Sin embargo, es difícil adivinar qué fue esto después del hecho. En las bases de datos de usuarios, puede pasar por los registros de transacciones para realizar ingeniería inversa, pero no puede hacer copias de seguridad de registros para master, por lo que no tiene suerte.

Creo que ha restaurado msdb, pero tenía una nueva base de datos maestra.