This project has moved and is read-only. For the latest updates, please go here.

Health monitor error after installing with AutoSP

Jan 7, 2012 at 9:03 AM


I get this error message in the health monitor after using the AutoSP script:

Accounts used by application pools or service identities are in the local machine Administrators group.

Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute. The following services are currently running as accounts in the machine Administrators group: MySites (Application Pool)
SharePoint - 80 (Application Pool)
SharePoint Central Administration v4 (Application Pool)
FIMSynchronizationService(Windows Service)
SPUserCodeV4(Windows Service)
SPTraceV4(Windows Service)
OSearch14(Windows Service)
SPTimerV4(Windows Service)
SPSearch4(Windows Service)
c2wts(Windows Service)
WebAnalyticsService(Windows Service)

But the accounts that I use are not in the machine Administrator group.

Does anyone know the reason for this?




Jan 13, 2012 at 4:50 PM

It could be that the health analyzer rule was run, and since then those accounts have been removed from local admins?

Try using the 'reanalyze now' option, then check again in a few moments?

Jan 17, 2012 at 11:36 AM

Thank you for answer.

I have already done this and a hole lot of other stuff, but what ever I can think of it still reports that my SPServices account is in the Administrator group.

Jan 18, 2012 at 4:27 AM

I just witnessed this today at a client site; turns out their local Administrators group had Active Directory groups inside them, which in turn contained the service accounts. So although the service accounts didn't explicitly appear in the Administrators group, they were effectively members.

So I would check if there are any other AD groups in your Administrators that may contain your service account(s).


Jan 18, 2012 at 10:54 AM

Funny you should mention that. I figured out this problem yesterday, and some "nice" guy had done even worse... The Domain Users group was inside the Domain Admin Group. So the local admin group seemed clean, and I really did not think that anyone would actually do such a stupid thing....