Take the 2-minute tour ×
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. It's 100% free, no registration required.

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
1  
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

3 Answers 3

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

The error itself says issue is with

1.login "##MS_PolicyEventProcessingLogin##" 2.On MSDB database 3.Issue is permission impersonation

Please refer : 'Cannot execute as the database principal because the principal "##MS_PolicyEventProcessingLogin##" does not exist

share|improve this answer
    
If the fix is a 2 line script, please don't link to your blog and just put the answer in there. Link only answers are not really permitted. –  JNK Feb 24 at 13:14

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

 
discard

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.