Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This morning I noticed my SQL Log was filling with the following message.

The activated proc '[dbo].[sp_syspolicy_events_reader]' running on queue 'msdb.dbo.syspolicy_event_queue' output the following: 'Cannot execute as the database principal because the principal "##MS_PolicyEventProcessingLogin##" does not exist, this type of principal cannot be impersonated, or you do not have permission.'

Running the following EXEC sp_change_users_login 'report' revealed that the login had in fact been orphaned.

I was able to fix it by running the following as recommended in this MSDN post.

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

But the question remains. What in the world would have caused this principal to have been orphaned in the first place? Googling and researching reveal that others have had this problem but I have yet to find a description of cause. Nothing of note that I am aware of occured the moment the error began appearing.

share|improve this question
Have you perhaps restored your msdb database recently? – Thomas Stringer Jun 26 '12 at 17:00
Negative... but good thought. We moved the whole server to a SAN storage model last summer, we restored everything during that move but that was months ago. – RThomas Jun 26 '12 at 17:21
@RThomas I believe that to be your problem. Could it be that you were just now in a place where you could "notice" the log issue? – swasheck Jun 26 '12 at 19:08
Hmmm, the issue wasn't appearing in the log until a couple weeks ago so if that was the cause... it was only something recent that made the symptom manifest as it doesn't appear in the log earlier than a couple weeks ago. – RThomas Jun 26 '12 at 21:04

Typical causes: someone drops the login (thinking they're cleaning up bad logins) or restores one of the system databases.

It's tough to guess what this was after the fact, though. In user databases, you can go through the transaction logs to reverse engineer it, but you can't do log backups for master, so you're out of luck.

share|improve this answer

We upgraded two servers (from SQL 2000) to SQL 2008R2 using in-place upgrade. We started getting these messages in SQL logs after upgrade. We did not change this or any other logins or users during the upgrade process.

My guess is upgrade process left two accounts (##MS_PolicyEventProcessingLogin## and ##MS_PolicyTsqlExecutionLogin##) orphaned.

EXEC sp_change_users_login 'Auto_Fix', '' fixed this issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.