孤立した## MS_PolicyEventProcessingLogin ##の原因は何ですか？

今朝、SQLログが次のメッセージでいっぱいになっていることに気付きました。

アクティブにprocの「[dboは] [sp_syspolicy_events_reader]。」は次のキュー「msdb.dbo.syspolicy_event_queue」出力で実行されている：
「校長『## MS_PolicyEventProcessingLogin ##』、このタイプの存在しないため、データベースプリンシパルとして実行できませんプリンシパルを偽装することはできません、またはあなたには許可がありません。

以下を実行するEXEC sp_change_users_login 'report'と、ログインが実際に孤立していることがわかりました。

このMSDNの投稿で推奨されているように、以下を実行することで修正できました。

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

しかし、問題は残っています：このプリンシパルがそもそも孤児になった原因は何でしょうか？グーグルで調べて調べたところ、他の人がこの問題を抱えていることがわかりましたが、原因の説明はまだわかりません。エラーが発生し始めた瞬間、私が気づいていることは何も起こりませんでした。

昨年の夏にサーバー全体をSANストレージモデルに移動しました。その移動中にすべて（msdbを含む）を復元しましたが、それは数か月前でした。数週間前よりも早くログに表示されないため、症状が現れたのは最近のことでした。

インプレースアップグレードを使用して、2つのサーバーを（SQL 2000から）SQL 2008R2にアップグレードしました。アップグレード後、SQLログでこれらのメッセージを取得し始めました。アップグレードプロセス中に、これやその他のログインやユーザーを変更しませんでした。

私の推測では、アップグレードプロセスで2つのアカウント（##MS_PolicyEventProcessingLogin##および##MS_PolicyTsqlExecutionLogin##）が孤立しました。

EXEC sp_change_users_login 'Auto_Fix', '<User Name>' この問題を修正しました。

典型的な原因：誰かがログインを落とした（悪いログインをクリーンアップしていると考えている）か、システムデータベースの1つを復元します。

しかし、これが事後に何であったかを推測するのは難しいです。ユーザーデータベースでは、トランザクションログを調べてリバースエンジニアリングを行うことができますが、マスターのログバックアップを実行できないため、運が悪かったです。

msdbを復元したと思いますが、新しいマスターデータベースがありました。