Home > MS Technologies, SCOM > “The Health Service cannot verify the future validity of the RunAs account” Error in SCOM

“The Health Service cannot verify the future validity of the RunAs account” Error in SCOM


If you are encountering this error in warning state, please check the change state of the monitor generating this error in the Health Explorer to get more details like the following description:

Date and Time: 9/7/2013 3:15:00 PM
Log Name: Operations Manager
Source: HealthService
Event Number: 7016
Level: 1
Logging Computer: Computer.DNS-Suffix
User: N/A
The Health Service cannot verify the future validity of the RunAs account “DOMAIN\Account” for management group “YOUR-MG” due to an error retrieving information from Active Directory (for Domain Accounts) or the local security authority (for Local Accounts). The error is 0x8000500D(0x8000500D).

Event Data:

< DataItem type =” System.XmlData ” time =” 2012-07-22T09:47:41.3597333-07:00 ” sourceHealthServiceId =” 70509BD2-367F-A3D4-C20D-AC0BEB4234C7 ” >
< EventData >
< Data > “DOMAIN” </ Data >
< Data > “Account” </ Data >
< Data > 0x8000500D </ Data >
< Data > 0x8000500D </ Data >
< Data > “MG” </ Data >
</ EventData >
</ DataItem >

Unfortunately, in the Knowledge Base of the Monitor, there is an obvious missing cause : Checking the state of your account in Active Directory. In some cases, this error is generated when the “Password never expires” is not defined.

In my case, it occurred for the domain administrator account which was defined as the default Run As Account in SCOM (It isn’t a good practice in SCOM; I know!). As the default GPO defines a maximum duration of the password life (45 days by default), “Password never expires” is not checked. To avoid the password expiration headaches, I set the maximum age of passwords to unlimited. But I forgot to check “Password never expires” option. For this reason, I got this error.

So check your account status or try to change it using another account. After that, Reset the Health of the monitor to see if it is fixed.

Categories: MS Technologies, SCOM Tags:
  1. Matt A
    September 26, 2012 at 4:09 pm

    Same problem! Anyone know the solution?

  2. September 26, 2012 at 6:56 pm

    Have you tried to create an other account having the same privileges ?
    but make sure that Password never expires option is checked and reset the health of the monitor.

    • Matt A
      September 26, 2012 at 7:27 pm

      I did go in and create a second account from scratch with password never expires. Same result. However, I only have SCOM monitoring 8 servers right now, and suddenly today one of them is back to Healthy with no RunAs warning. The others still have it. When I first started having this issue all the RunAs accounts were set to Local System for agents, since then I’ve troubleshooted by making Domain Accounts……. any ideas?

  3. September 27, 2012 at 5:10 am

    It seems that the cache agent on the servers is not updated by the new policy. In this case two options are proposed:
    1- Try to stop the health service on a server, clear the cache and restart the service (http://www.systemcentercentral.com/tabid/143/indexid/91488/default.aspx)
    You can do that also by exploring Diagnostic and Recovery options from the SCOM console.
    2- Uninstall the agent, make sure that all related files are deleted and reinstall your agent.

    I hope it helps.

  4. Matt A
    September 28, 2012 at 1:28 pm

    That worked for the whole day yesterday until it ran some over night management pack. They are back to warning level this morning:
    The Health Service cannot verify the future validity of the RunAs account %user% for management group %management_group% due to an error retrieving information from Active Directory (for Domain Accounts) or the local security authority (for Local Accounts). The error is 0x8000500D(0x8000500D).

    I’m at a loss…

  5. September 28, 2012 at 6:20 pm

    If you have changed the Run As Account, in this case we can understand that the health service cannot verify the password attributes in Active Directory for privileges reasons I suppose. I don’t know if this error is related to the SCOM health service or the agent health service. So, try to add your SCOM service action account into domain administrators group. Do the same thing with a deployed agent on a machine. if the agent is a local system, try to reinstall it with a domain account (this account is a domain administrator just for test).
    If this solution works fine, we can solve easily the problem.

  6. Matt A
    October 2, 2012 at 2:14 pm

    Hey thanks for your responses. I’ve made the account a Domain Admin as a test, let the scheduled tasks run and still can’t verify the Run As account. 😦

    • October 3, 2012 at 5:45 am

      Hi, what a pity!
      Have you tried to reboot your SCOM Server?
      I can suggest you another solution: Delete the Run As Account from SCOM, please wait for the generated errors or warnings related to that action. After that, create a new Run As Account with a domain administrator account.
      I hope it works.

  7. Matt A
    October 5, 2012 at 1:17 pm

    So I discovered after reviewing the logs on the server where the SCOM Agent is installed and no matter what I do it is attempting to verify my personal domain account for RunAs rather than the service account I’ve created. During the agent install process I used the service account to discover AND install the SCOM agent. The Default Action Account profile also has the SCOM service mapped to the servers I’ve been testing. Where is it choosing the RunAs account from?

  8. October 7, 2012 at 6:46 pm

    The Run as accounts are generally generated when you install custom Management Packs to monitor a certain business application or service. This Run As account is mapped generally by default to the Action Account (the account used to execute the agent on the target machine). When you install an agent, you can use the Service Action Account if it has sufficient privileges on the target machines. Now if the Action Account of the agent is unable to execute some scripts, tasks, etc on the application you are monitoring so in this case you configure the Run As account to use a Run As Profile user.
    In which management pack are you using this Run As Account?

  9. Matt A
    October 8, 2012 at 1:27 pm

    only the Default Action Account profile in Run As Configuration > Profiles. I’m not sure if that answers your question, I don’t see where you set Run As Accounts for specific management packs. perhaps this is where the misunderstanding is.

  10. Matt A
    October 10, 2012 at 1:02 pm

    Resolved. The problem with this error was not the Action Account but rather the Type: Windows account in the Run As Configuration space > Accounts

    Thank you for your responses.

    • ramzibot
      October 10, 2012 at 3:48 pm

      Obviously !!!
      Happy for you.

    • Daniel
      December 17, 2012 at 1:00 am

      Hi, I’m having the same issue. can you please give more detail on the resolution?
      I’m not sure what this means:
      “the Type: Windows account in the Run As Configuration space > Accounts”

  11. December 26, 2012 at 7:23 pm

    Hi Daniel,

    Please, just take a look on the change state of the generated error event. You will have the concerned account in its description. After that, you have just to configure the validity of this account in Active Directory.

  12. Ted
    August 4, 2013 at 3:30 pm

    Hi ramzibot. I’ve got the same issue. My account settings: 1. password never expires, 2. account expires -> never. And this problems occuress. Any suggestions?

  13. July 2, 2015 at 4:36 pm

    Hey Ramzibot I’m having the same error. My Accounts are set to never expire and password is set to never expire. I check the issue Mark was referring to but my action account , db reader, and db writer account will not verify. all accounts are set to not expire or password to expire. the action account is under action accounts db reader/writer or windows account. Is there anything else I can check.

    • October 16, 2015 at 9:45 pm

      Hi Michael, Sorry to be late. Yes, sometimes, even, everything is well done, you still have this error. It s not critical and you can disable the alert just for the concerned object.

  14. March 29, 2017 at 10:16 am

    Thanks for this post.

    However, in my case, I moved the service accounts to different OU. “Password never expires” was already set. I just unchecked and checked this option and applied settings for all accounts. Same way I updated the Run As accounts in SCOM (no change, just add and remove a character) and then it resolved the issue.

    • April 7, 2017 at 1:09 am

      Hi Dinesh,
      Thanx a lot for your contribution.
      For this reason, sometimes, if everything is ok related to the passwords that never expire, we have just to ignore this alert!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: