The Virtual Machine Manager 2012 MP may cause floods of alerts of the type Run As Account Cannot Log On Locally..
Here's why and how you can avoid it.

When you configure the VMM 2012 and SCOM connection you do that from VMM.
What happens is that the MP's are installed and a RunAs profile and a RunAs account (Virtual Machine Manager Connection Account) are set up.
The RunAs stuff are not included in the documentation (to my findings at least) and are the cause for the alert floods.

The RunAs account is defined with the credentials that you specified during the SCOM / VMM integration process from the VMM console, which could for example be your Management Server Action Account (MSAA) or an Agent Action Account (AAA).
This account is what may appear on every agent-managed client out there with a Run As Account Cannot Log On Locally-alert with the description The Run As account needs to have the "Log On Locally " right.

The reason for this is that the VMM RunAs account is defined to use the "Less Secure" security option, which makes it's credentials become distributed to all agents (even if no MP will ever use them on these clients).
What happens next is that the first thing the agents will to after starting and getting contact with the Management Servers it will get the initial configuration (before retrieving any MP's).
This includes the RunAs accounts, which will be tested if they can be logged on.
Here's where it'll fail..

To solve the matter, edit the Virtual Machine Manager Connection Account RunAs-account and choose more secure instead, select the VMM servers, the SCOM Management Servers, click apply and watch the alerts go away.. :)

.

For more info, see Kevin Holman's excellent post on the subject:
http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx
"If you create a Run As account, and choose Less Secure you will immediately get a flood of alerts from all your Domain Controllers, Exchange servers, and any other servers that restrict the Log on Locally right.  In enterprise server environments, this is very typical to remove Domain Users or the local Users group from this user right via group policy or to deny Log on Locally for service accounts.  This essentially makes Less Secure unusable for any practical purpose."

.

Hope this gets fixed in future releases of the MP's.

• Edited by JonRunheim Monday, May 14, 2012 7:06 AM

Hi Jon

This won't be fixed and it isn't recognised as an error ;-( 

I raised feedback on connect on 18th January and got the response that "we need this for PROTip to work (only the remediation part). If PROTip remediation is not intended, then the user can change it to more secure. "

I can confirm that you can change this to More Secure and distribute to SCOM MS and VMM MS to stop the error - you just lose the PRO Tip remediation.

Cheers

Graham

So.. For the VMM2012 MP to work fully, it requires it's connection account to be distributed with log on locally privileges to all agent managed servers.

In a normal environment that has some high security definitions that's out of the question..

Let's change my final line then.. I hope they fix this in a better way in a future release that enables the More Secure option.. :)
As Kevin Holman stated - Less Secure is Unusable.

Regards!

/Jon

• Marked as answer by JonRunheim Monday, May 14, 2012 7:19 AM

That response makes no sense.

There should be no requirement for less secure... only to distribute the run-as account where it is needed.  If it is needed on ALL systems, then they need to re-architect the design.

Hi Kevin

"If it is needed on ALL systems, then they need to re-architect the design." - I agree but my understanding is that there are no plans to change this.

I can provide the feedback id if you feel it is worth escalating?

Cheers

Graham

Hi Guys,

sorry for hijacking this thread, but my question aims in the same direction (at least bing moved me over here).

What is the recommended practise when using a scenario with OpsMgr Gateway and non-trusted domains? Just switching to "more secure" works, but is there a way to get it work so that PROTips are still working?

Especially in a hosting/cloud environment this can be a showstopper imho.

Thanks,

Florian 

Hi,

I have same problem as schmey.

Is there any way to run PROTips along with "more secure"?

Regards

Jure

• Edited by Jure Labrovic Monday, January 20, 2014 10:31 AM

Has anyone found a useable workaround for this? Jure Labraovic... any luck?

Nope.

I am using "More secure" with PRO Tips remediation turned off

Regards

Jure