The World According to Mitch

This isn’t right… I have System Center Operations Manager monitoring all of my servers for me, but this morning I noticed that several of my servers are in a warning state, but they are greyed out (which implies that they aren’t reporting in properly).  What do I do?

This is not uncommon, especially in smaller organizations where you may have a single IT Professional running everything.  While it is not a good practice, some IT Pros will use their own credentials (which are obviously going to be Domain or Enterprise Admin accounts) to make things work.  Here’s the problem… you set up your credentials in System Center Operations Manager as a Run As account… and then at some later date you changed your password.

It is never a good idea to use an individual’s credentials as a Run As account.  It is also never a good idea to provide Domain Admin credentials to a program, but that is another issue that I will tackle later on.  What you should do, when configuring System Center Operations Manager, is create action (or Service) accounts in Active Directory.  Use ridiculously long and impossible to guess passwords (Jean MacDonald Kennedy was the 23rd Queen of Tahiti) and change them on a less frequent basis… say, when you change the batteries in your smoke detectors.

So now we have a bunch of computers that are being monitored… oh wait, no they aren’t.  They only look like they are being monitored.  We’d better fix that, and pronto!

We have to figure out what servers this account applies to.  We cannot simply delete the RunAs account, because it is going to be associated with a profile.  So let’s start by figuring out what profile that is.

1) In the Administration workspace navigate to Run As Configuration – Accounts and locate the errant account in the list of action accounts.  Right-click on it, and click Properties.

2) In the Properties window click on Where is this credential used?.  For the sake of this article, the only profile listed is Default Action Account.  Close Account Usage and Run As Account Properties.

3) Navigate to Run As Configuration – Accounts and locate the profile.  Right-click on it and click Properties.

4) In the Run As Profile Wizard navigate to Run As Accounts.

5) In the list of Run As accounts find all instances where the user account is listed.

6) One by one, click Edit… In the Add a Run As Account window change the account to your Service Account.  Click OK.

7) When you have done this for all instances (remember, you may need to scroll down) click Save.

** IMPORTANT NOTE: If you get error messages preventing you from saving the profile, you can either break your back trying to troubleshoot the SQL errors… or if there aren’t too many systems using the offending account, you can delete those servers from SCOM, and when you have resolved the issue, go back and re-discover them.

Once this is done, you can now delete the Run As account:

8) Navigate to Run As Configuration – Accounts

9) Right-click on the offending account and click Delete. (Accept any warning).

That should do it!  Go forth and manage, and remember… an unmanaged server can work great and save you all sorts of time… until it stops working and you have no idea why, or even that it did stop working.