Error 7557: The Secure Store Service application Secure Store Service is not accessible.

Problem

You attempt to generate a new Secure Store key, but when you go to the Manage page for the Secure Store application, you see this error message:

You then check the server's Application event log and see the following error corresponding to each of your attempts to access the Secure Store Application:

Log Name:      Application
Source:        Microsoft-SharePoint Products-Secure Store Service
Date:          [date/time]
Event ID:      7557
Task Category: Secure Store
Level:         Error
Keywords:   
User:          [user]
Computer:      [servername]
Description:
The Secure Store Service application Secure Store Service is not accessible. The full exception text is: There

are no addresses available for this application.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-SharePoint Products-Secure Store Service" Guid="{...}" />
    <EventID>7557</EventID>
    <Version>14</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="[date/time]" />
    <EventRecordID>11014</EventRecordID>
    <Correlation ActivityID="{...}" />
    <Execution ProcessID="6648" ThreadID="4000" />
    <Channel>Application</Channel>
    <Computer>[servername]</Computer>
    <Security UserID="..." />
  </System>
  <EventData>
    <Data Name="string0">Secure Store Service</Data>
    <Data Name="string1">There are no addresses available for this application.</Data>
  </EventData>
</Event>

Solution

 

This is frequently a permissions issue.  To resolve, perform these checks and procedures:

1. Check the Secure Store service
1. Start it if it is stopped
2. Try accessing the Manage page again.
2. Check the user account you are currently logged in as:
1. If it is NOT the farm configuration account, login using the farm configuration account, and then try accessing the Manage page again.  Or,
2. If it is NOT the farm configuration account, add your administration account to the farm configuration database: Add-SPShellAdmin -UserName [your admin account] -Confirm -WhatIf.  Then try accessing the Manage page again.
3. If it IS the farm configuration account, stop and restart the Secure Store service, and then try accessing the Manage page again.

Notes

• Search engine text: Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator.

Health Analyzer: Database has large amounts of unused space

Problem

You find the following entry in the SharePoint 2010 Central Administration Review problems and solutions All Reports listing:

Title	Database has large amounts of unused space.
Severity	3 - Information
Category	Availability
Explanation	Following databases have large amounts of space allocated on the disk but not in use. This may be due to recent deletion of data form the database, or because the database has been pre-grown to a larger size. This database will take up a larger amount of space on the file system unless it is shrunk down to a smaller size. [databasename] on [machinename]
Remedy	The database can be shrunk in size using the DBCC ShrinkDatabase command or the Shrink Database wizard in SQL Server Management Studio. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=167144".
Failing Servers
Failing Services	SPTimerService (SPTimerV4)
Rule Settings	View

 
Solution

Depending on the size of the database, run the Shrink Database task in Microsoft SQL Server Management Studio.

1. Right-click on the database
2. Go: Tasks > Shrink > Database. 

References

• SharePoint Health Analyzer rules reference (SharePoint Foundation 2010)
• Database has large amounts of unused space (SharePoint Foundation 2010)
• Database maintenance for SharePoint 2010 Products
• Databases How-to Topics (SQL 2008 R2)
• How to: Shrink a Database (SQL Server Management Studio)
• Optimizing Indexes (SQL 2008 R2)
• Reorganizing and Rebuilding Indexes

InfoPath Forms Services forms cannot be filled out in a Web browser because no State Service connection is configured

Problem

You find the following entry in the SharePoint 2010 Central Administration Review problems and solutions All Reports listing:

Title	InfoPath Forms Services forms cannot be filled out in a Web browser because no State Service connection is configured.
Severity	2 - Warning
Category	Configuration
Explanation	InfoPath Forms Services is not functional on the following Web applications because there is no service connection configured for the State Service: [servicename]
Remedy	If a State Service application doesn't exist, create one by using the new-SPStateServiceApplication Powershell commandlet. For more information on configuring the State Service, see Help. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=142645".
Failing Servers	[servername]
Failing Services	SPTimerService (SPTimerV4)
Rule Settings	View

 
Solution

Create the State Service application and proxy using the following PowerShell script:

$mysa = New-SPStateServiceApplication -Name "State Service"
New-SPStateServiceDatabase -Name "DB_StateService" –ServiceApplication $mysa
New-SPStateServiceApplicationProxy -Name "State Service Proxy" -ServiceApplication $mysa –DefaultProxyGroup

Summary

This posting has presented a PowerShell method for resolving the SharePoint 2010 Health Analyzer warning.  Using the PowerShell method avoids creating a database having a long name that includes a GUID string.  For additional detail on the topics discussed in this posting, see the references below.

References

• SharePoint Health Analyzer rules reference (SharePoint Server 2010)
• InfoPath Forms Services forms cannot be filled out in a Web browser (SharePoint Server 2010)
• InfoPath Forms Services forms cannot be filled out in a Web browser because no State Service connection is configured (SharePoint Server 2010)
• SharePoint Health Analyzer rules reference (SharePoint Foundation 2010)
• State service and session state cmdlets (SharePoint Server 2010)
• New-SPStateServiceApplication
• Warning: InfoPath Forms Services forms cannot be filled out in a Web browser

Error 5161: Site 2 has no root application defined, so the site will be ignored.

Problem

You see the following error appear irregularly in the SharePoint 2010 server Application log:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          [date/time]
Event ID:      5161
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      [SharePoint 2010 server host machine name]
Description:
Site 2 has no root application defined, so the site will be ignored.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-WAS" Guid="{524B5D04-133C-4A62-8362-64E8EDB9CE40}" EventSourceName="WAS" />
    <EventID Qualifiers="49152">5161</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="..." />
    <EventRecordID>9077</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>[SharePoint 2010 server host machine name]</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SiteID">2</Data>
    <Binary>0D000780</Binary>
  </EventData>
</Event>

Discussion

The SharePoint Server 2010 installation creates an additional site, SITE_2.  This site can be seen in IIS Manager.  It will create further such sites on removing SharePoint 2010 and subsequently installing it again without removing the SITE_2 website. Thus, you may see a SITE_2, SITE_3, etc.

Solution

These sites can be safely removed using IIS Manager.  Restart IIS after removing these sites.

References

• Event ID 5161 — IIS Web Site Availability
• Site 2 has no root application defined, so the site will be ignored. ????
• IIS SITE_2 and SharePoint 2010

Notes

• This site seems to be a placeholder for prospective web services deployment.  You can see this by reviewing the ApplicationHosts.Config file at C:\Windows\System32\inetsrv\config.  Scroll down to the <Sites> node to see the Site 2 entry.

Warning 1015: Failed to connect to server. Error: 0x80070005

Problem

On a daily basis, you see the following warning appear in the SharePoint server 2010 host's Application log:

Log Name:      Application
Source:        MsiInstaller
Date:          [date]
Event ID:      1015
Task Category: None
Level:         Warning
Keywords:      Classic
User:          [SharePoint farm account]
Computer:      [a SharePoint Server 2010 host]
Description:
Failed to connect to server. Error: 0x80070005
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="MsiInstaller" />
    <EventID Qualifiers="0">1015</EventID>
    <Level>3</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="..." />
    <EventRecordID>8607</EventRecordID>
    <Channel>Application</Channel>
    <Computer>[a SharePoint Server 2010 host]</Computer>
    <Security UserID="..." />
  </System>
  <EventData>
    <Data>0x80070005</Data>
    <Data>(NULL)</Data>
    <Data>(NULL)</Data>
    <Data>(NULL)</Data>
    <Data>(NULL)</Data>
    <Data>(NULL)</Data>
    <Data>
    </Data>
  </EventData>
</Event>

You may see a 100 or so similar warnings appear daily, each one accompanied by a corresponding Information event, such as the following:

Log Name:      Application
Source:        MsiInstaller
Date:          [date]
Event ID:      1035
Task Category: None
Level:         Information
Keywords:      Classic
User:          [SharePoint farm account]
Computer:      [a SharePoint Server 2010 host]
Description:
Windows Installer reconfigured the product. Product Name: Microsoft InfoPath Form Services English Language Pack. Product Version: 14.0.7015.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="MsiInstaller" />
    <EventID Qualifiers="0">1035</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="..." />
    <EventRecordID>8608</EventRecordID>
    <Channel>Application</Channel>
    <Computer>[a SharePoint Server 2010 host]</Computer>
    <Security UserID="..." />
  </System>
  <EventData>
    <Data>Microsoft InfoPath Form Services English Language Pack</Data>
    <Data>14.0.7015.1000</Data>
    <Data>1033</Data>
    <Data>0</Data>
    <Data>Microsoft Corporation</Data>
    <Data>(NULL)</Data>
    <Data>
    </Data>
    <Binary>...</Binary>
  </EventData>
</Event>

Each of these pairs corresponds to a different component that can be configured for the farm.

Discussion

These are associated with the farm's Product Version Job, which by default runs daily at 12:45 AM.  Compare the times of these warnings with the time that your farm's Product Version Job runs, and you'll see the association.

Solution

1. Add the farm account to the host's local administrator group.
2. Restart the SharePoint 2010 Timer service.
3. Remove the farm account from the host's local administrator group.
4. Run the farm's product Version Job.
5. Check the host's Application Log.

References

• Multiple errors from MsiInstaller with event id 1015 and text "Failed to connect to server. Error: 0x80070005"
• MsiInstaller Warnings and DistributedCOM Errors in the Event Log after configuring User Profile
• Product Version Job: DCOM 10016 strikes again
• Event ID 1015 — Windows Installer Service Availability
• a Sharepoint Timer Job called “Product Version Job

Notes

• Thanks to SP-Jim for finding this solution (scroll down near the bottom).

Error: The feature failed to activate because a list at 'PublishingImages' already exists in this site

Problem

You attempt to activate the Publishing feature for a SharePoint 2010 site,

but experience the following error:

The feature failed to activate because a list at 'PublishingImages' already exists in this site.  Delete or rename the list and try activating the feature again.

You then check All Content for the site and do not find any images library named PublishingImages, but only a standard Images library,

Solution

This experience is by design.  To resolve this problem, follow the guidance suggested in the error message.  Rename the existing Images folder:

Then try activating the site's Publishing feature again.

After the feature has been activated, you will see a new Images library for the site

References

• The feature failed to activate because a list at PublishingImages already exists in this site
• Error message when you try to enable the Publishing feature on a SharePoint Server 2007 site: "The feature failed to activate because a list at 'Pages' already exists in this site"

Error 8193: Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW... Access is denied

Problem

The following error appears in a SharePoint Server 2010 farm server:

Log Name:      Application
Source:        VSS
Date:          [date]
Event ID:      8193
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      [computername]
Description:
Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...).  hr = 0x80070005, Access is denied.
Operation:
   Initializing Writer
Context:
   Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
   Writer Name: OSearch14 VSS Writer
   Writer Instance ID: {ec5611b9-3477-4ae9-8cea-778025228ec5}
.
.
.

Discussion

The error involves a permissions issue, but it isn't immediately obvious what account is being denied access.  The account needs to be determined in order to grant it the appropriate permissions to the service. 

The VSS writer name being OSearch14 VSS Writer indicates that the account is related to the SharePoint Server 2010 (ie, "2010" =  "14") account used to run SharePoint Server 2010 server search.  To correlate this with a specific AD account, review the Services listing to find the service SharePoint Server Search 14, and the logon for this service will be the account in question.  One  can also go to the error Event Properties dialog Details tab in Friendly View mode, and then scrolling down to the In Bytes section: the path to the executable and the account that is running the executable will  be shown to the right.

Solution

1. Logon to the server as an administrator.
2. Open Registry Editor on the server.
3. Navigate to the key HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag.
4. Right-click, and then select Permissions.
5. Add the farm search account.
6. Set the farm search account to (Allow) Full Control.
7. Click Apply
8. Click OK.

References

• Windows Server 2008 R2 Event 8193 – Volume Shadow Copy Service error. Unexpected error calling routine RegOpenKeyExW (-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag 0×80070005, Access is denied
• Event 8193 – Volume Shadow Copy Service error

Error 10016: The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {000C101C-0000-0000-C000-000000000046}

Problem

The following error appears in a SharePoint Server 2010 farm server system log:

Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: [date]
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: [domain]\[FarmAccount]
Computer: [FarmServerName]
Description:
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user [domain]\[FarmAccount] SID... from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Discussion
This error is being logged to the System event log due to the farm account not having permission to access the DCOM component at 000C101C-0000-0000-C000-000000000046.

Solution

1. Grant Farm Account Permissions to Component
1. Open the Component Services tool on the server.
2. Look for the DCOM component 000C101C-0000-0000-C000-000000000046.
3. Right-click this component and select Properties.
4. Select the Security tab.
5. If all options are disabled, complete the steps in section Change Component Owner, and then return; and then close and launch Component Services. 

   If after changing the key ownership, you find that these options are still disabled, close Component Services and then re-open it.
    

6. In the Launch and Activation Permissions section, select Customize.
7. Click the Edit button.
8. Add the farm account. 

   When initially added, the account will only have (Allow) Local Launch checked.
    

9. Check (Allow) Local Activation.
10. Click OK.
11. Click Apply, and then click OK.
12. Reset IIS.
13. Stop and then start SharePoint 2010 Timer.
2. Change Component Owner
1. Start Registry Editor in Administrator mode on the server.
2. Find key HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{000C101C-0000-0000-C000-000000000046} .
3. Right-click this key, and then select Permissions. The Permissions dialog appears.

   You may see your administrator group here and think that you can set Full Control for your group. However, if you try this, you will get an Access is denied error prompt
    

4. Click the Advanced button.  The Advanced Security Settings dialog appears.
5. Select the Owner tab. 

   By default, the Current Owner will be the TrustedInstaller account.
    

6. Select your administrator account or group, and check Replace owner on subcontainers and objects, and then click Apply.
7. Click OK.  The Advanced Security Settings dialog closes, and the focus returns to the Permissions dialog.
8. Select your administrator account of group, and then check Full Control.
9. Click OK.  The Permissions dialog closes.
10. Exit Registry Editor.

References

• The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {000C101C-0000-0000-C000-000000000046} – SharePoint 2010
• Event ID 10016, KB 920783, and the WSS_WPG Group: outstanding article on this very issue by jeremy jameson.
• Event ID error messages 10016 and 10017 are logged in the System log after you install Windows SharePoint Services 3.0: its for 2007, but provides helpful information for 2010.

Notes

• UPDATE 1/8/15: I added two references to this posting that provide helpful insight and guidance on resolving this issue.  Also applicable to 2013 since the same groups are used.

SharePoint 2010: The operation that you are attempting to perform cannot be completed succesfully

Problem

Your web application has a single content database.  You have previously created a granular backup of a site collection in the web application.  You attempt to perform a site collection restore,

Restore-SPSite [site collection URL] -Path [filename] -Force

but then experience the following error:

Restore-SPSite : The operation that you are attempting to perform cannot be completed succesfully.  No content databases in the web application were available to store your site collection.  The existing content databases may have readhed the maximum number of site collections, or be set to read-only, or be offline, or may already contain a copy of this site collection.  Create another content database for the Web application and then try the operation again...

Solution

This can be related to an orphaned site in the database or a database upgrade needed.  But before engaging more complex testing, be sure to check the content database properties:

• Database status: should be set to Ready.
• Number of sites  before a warning is generated: should be set to 2 or greater.
• Maximum number of sites that can be created in this database: set to 3 or greater.

References

• Restore a farm (SharePoint Foundation 2010)
• SharePoint 2010 Restore-SPSite problems
• Orphaned site issue when attempting to backup/restore a SharePoint site collection

 

Build a Custom Search Results Page with Facets in SharePoint 2010

Introduction

This article shows you how to create a custom site collection search results page, with search facets, in five easy steps.  You will be shown how to do this using nothing more than the standard web front end tools (page edit mode) and the out-of-the-box web parts that come with SharePoint Server 2010.  Site Collection Administrator privileges will be needed to actually point site collection search to the new search results page, but the rest can be done with no more than standard Contributor permissions.  Creating a custom search results page is remarkably easy, and this article shows you how.

There are a few assumptions to keep in mind, as you work through this article.  The first is that the SharePoint Server Publishing Infrastructure feature has been activated for the target site collection. Second, it assumes that you have added content to your site collection, such as Office documents.  Third, it assumes that  Search has been successfully configured and that content has been indexed.  Lastly, it assumes that a Search center has not been configured and that site collection search results are still being presented in the default search results page.  One more thing: in developing this article, I performed the testing against a special corpus of content that I created that has been seeded with keywords designed to return known results.

Step 1: Add a new page

1. Navigate to the top site of the site collection.
2. From the Site Actions dropdown, select More Options.
3. Select Page, from the Filter By group, at left, and then select Web Part Page.
   
4. Click Create.
5. Enter a name for the new page.  For this article, MyCustomSearchResults was used.
6. Select the Layout Template.  For this article, the Header, Left Column, Body template was used.
7. Then select the document library where you want to page to be stored.  For this article, the Site Pages library was used.  You could also use the Site Collection Documents library.
   
8. Click Create.  The new web part page is created, and your browser is navigated to the page in edit mode.
9. On the Page ribbon, click the Stop Editing button.  The page is refreshed, and now appears in normal mode.
   

Step 2: Add basic search results capability

1. In the Body web part zone, click Add a Web Part.  A new section appears on the web page, from which you can select web parts.
2. In the Categories section, scroll down and select Search; then, in the Web Parts section, use the arrow links to browse the search web parts for Search Core Results, and then select this web part.
   
3. Click the Add button.  The page is refreshed to show the new web part in the Body web part zone.
   
4. On the Page ribbon, click the Stop Editing button.  The page is refreshed, and now appears in normal mode.
   

Step 3: Configure the Site Collection Search to use the custom page

1. From the Site Actions dropdown, select Site Settings.
   
2. In the Site Collection Administration group, click Search Settings.  The browser is navigated to the Search Settings page.
3. In the Site Collection Search Results Page field, enter the path and filename to your new custom search results page.  For this article, the path and filename would be: /SitePages/MyCustomSearchresults.aspx. Leave all other settings at their default values.
   
4. Click OK.  Now to test the results against the test content.
5. The first test will use the keyword document010, which should return just three results: one each of Word, PowerPoint and Excel documents.
   
   Performing the search returns the expected results. 
   
   So far so good.
6. The second test will use the keyword Global010, which should return 30 results: 10 each of Word, PowerPoint and Excel documents.  Performing the search does not return the expected results.
   
7.  
   

Step 4: Add Paging Capability

1. With your browser still connected to the new custom search results page, on the ribbon, select the Page tab, and then click the Edit Page button.  The page is refreshed to display it in edit mode.
2. In the Body web part zone, click Add a Web Part.  A new section appears on the web page, from which you can select web parts.
3. In the Categories section, scroll down and select Search; then, in the Web Parts section, use the arrow links to browse the search web parts for Search Paging, and then select this web part.
   
4. Click the Add button.  The page is refreshed to show the new web part in the Body web part zone.
   
5. Optional: by default, the new web part appears above the existing one.  However, you can easily move it below, by simple drag-and-dropping methods.  For this article, the Search Paging web part is moved to below the Search Core Results web part.
   
6. On the Page ribbon, click the Stop Editing button.  The page is refreshed, and now appears in normal mode.  Now to test the results against the test content.
7. The test will again use the keyword Global010, which should return 30 results: 10 each of Word, PowerPoint and Excel documents.  Performing the search returns a list of 10 results, and paging tools now appear.
   
8. The next step is to implement search facets.

Step 5: Add search facets

1. With your browser still connected to the new custom search results page, on the ribbon, select the Page tab, and then click the Edit Page button.  The page is refreshed to display it in edit mode.
2. In the Left Column web part zone, click Add a Web Part.  A new section appears on the web page, from which you can select web parts.
3. In the Categories section, scroll down and select Search; then, in the Web Parts section, use the arrow links to browse the search web parts for Refinement Panel, and then select this web part.
   
4. Click the Add button.  The page is refreshed to show the new web part in the Left Column web part zone.
   
5. While were at it, let's add one more useful search web part: the Search Statistics web part, which displays the number of results returned and how many you are currently viewing (given search paging).  Add the web part using the same method as previously. 
   
   After you finish, you'll see two web parts displayed at left.
   
6. On the Page ribbon, click the Stop Editing button.  The page is refreshed, and now appears in normal mode.  Now to test.
7. The test will again use the keyword Global010, which should return 30 results: 10 each of Word, PowerPoint and Excel documents.  Performing the search returns a list of 10 results, as expected. 
   
   The search facets display the default facets.  Note that the Search Statistics web part discretely displays the number of currently viewed search results. 

Summary

This article has shown you how to implement a custom site collection search results page in just five easy steps, and all without writing any code, nor even using SharePoint Designer for that matter.  For additional details on the topics discussed in this article, consult the references below.

References

• Publishing features overview (SharePoint Server 2010)
• Change how search results appear in the Search Core Results Web Part (SharePoint Server 2010)
• Plan the end-user search experience (Office SharePoint Server)

Health Analyzer: Built-in accounts are used as application pool or service identities

Problem

You see the following warning appear in the Review problems and solutions list in SharePoint 2010 Central Administration:

Built-in accounts are used as application pool or service identities

Solution

1. Click on the warning title.  The warning description dialog appears:
   
2. The error description dialog identifies the cause of the problem: the DCLoadBalancer14, SPSearch4 and DCLauncher14 services are being run by a built-in account of the machine hosting the services.

   In this case, all of the services are running on a single application server, part of a small two-tier farm.  In multi-server farms where services may be running on other machines, you will need to perform this check on each server.

3. In Central Administration, go: Security > General Security > Configure service accounts.
4. From the service dropdown (upper one), select Windows Service - Document Conversions Load Balancer Service.  This is what is referred to in the warning as "DCLoadBalancer14(Windows Service). The page is updated to show the service components and the account running the service:
   
5. From the Select an Account for this component dropdown, select a managed account.  For this posting, the Contoso\sp_app account was used.
6. Click OK.
7. Navigate back to the Review problems and solutions page in Central Administration.
8. Click on the warning title, Built-in accounts are used as application pool or service identities:
   
9. Click Reanalyze Now.
10. Wait a minute or two, and then click on the warning title again.
11. Verify that DCLoadBalancer14(Windows Service) is no longer included in the warning:
    
12. Repeat the above steps, this time choosing Windows Service - Document Conversions Launcher Service.  This is what is referred to in the warning as "DCLauncher14(Windows Service)."
13. Verify that DCLauncher14(Windows Service) is no longer included in the warning:
    
14. Repeat the above steps, this time choosing Windows Service - SharePoint Foundation Search.  This is what is referred to in the warning as "SPSearch4(Windows Service)."
15. Verify that the warning, Built-in accounts are used as application pool or service identities, is no longer listed:
    
16. This concludes this procedure.

Summary

This posting presented steps for resolving the Health Analyzer warning, Built-in accounts are used as application pool or service identities.  For additional detail on this topic, see the references below.

References

• Built-in accounts are used as application pool or service identities (SharePoint Foundation 2010)
• Account permissions and security settings (SharePoint Server 2010)
• Plan administrative tasks in a least-privilege environment (SharePoint Server 2010)
• Initial deployment administrative and service accounts (SharePoint Server 2010)
• Service Account Suggestions for SharePoint 2010
• Health Analyzer – SharePoint 2010 Tracing (SPTraceV4)

Health Analyzer: Accounts used by application pools or service identities are in the local machine Administrators group

Problem

You see the following warning appear in the Review problems and solutions list in SharePoint 2010 Central Administration:

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

Solution

1. Click on the warning title.  The warning description dialog appears:
   
2. The error description dialog identifies the cause of the problem: the farm administration and timer service accounts are members of the local machine Administrators group. 

   During initial deployment, the farm account is provisioned as a domain user account with local machine administrator privileges.  The farm account only needs local administrator privileges during SharePoint farm provisioning.  Once farm provisioning is completed, this account can be removed from the local administrators group.  You will need to add this back to the local Administrators group during subsequent provisioning tasks, such as User Profile Provisioning.

3. In Central Administration, go: Security > General Security > Configure service accounts.
4. From the service dropdown (upper one), select Farm Account.  This refers to the Central Administration service.  The page is updated to show the service components and the account running the service.
5. Verify that the farm account (in this case, Contoso\sp_farm) is running the Central Administration service:
   
6. Login to the machine hosting your SharePoint 2010 farm Central Administration.
7. Go: Start > Administrative Tools > Services.
8. Scroll down to the SharePoint 2010 Timer service.
9. Double-click this service, and then select the Log On tab.
10. Verify that the farm account is entered:
    
11. On the local machine, go: Start > Administrative Tools > Computer Management
12. In the tree console at left, expand Local Users and Groups, and then select Groups.  The results panel in the middle updates to list local machine groups.
13. Double-click the Administrators group.  This is the local machine administrators group.
14. Verify that the farm account appears:
    
15. In the Members pane, select the farm account, and then click Remove.  The account no longer appears.
16. Click OK, and then logout of the local machine hosting Central Administration.
17. In Central Administration, in the message bar, click View these issues.
18. On the Review problems and solutions page, click the warning message link, Accounts used by application pools or service identities are in the local machine Administrators group.  The warning description dialog appears:
    
19. Click the Reanalyze Now button, and then click Close.
20. Wait a minute of two, and then refresh the page.  The warning message no longer appears:
    
21. This concludes this procedure.

Troubleshooting

If, after performing the steps above, the warning message remains, try the following:

1. Re-run Rule Definition:
1. In Central Administration, go: Monitoring > Health Analyzer > Review rule definitions.
2. On the Health Analyzer Rule Definitions page, in the Category: Security group, click the rule definition link, Accounts used by application pools or service identities are in the local machine Administrators group.
   
3. Click the Run Now button, then click Close.
4. Wait a minute or two, and then return to Review problems and solutions page.
5. Verify that the warning no longer appears.
2. Reset Farm Service
1. Login to the local machine hosting the farm Central Administration application.
2. Go: Start > Administrative Tools > Services.
3. Scroll down to the SharePoint 2010 Administration service.
4. Double-click this service.  The services properties dialog appears.
5. Select the Log On tab.
6. If not selected, select  the This account option.
7. Enter or re-enter the farm account.  For this posting, the farm account is Contoso\sp_farm
   
8. At the warning prompt, "The new login name will not take effect until you stop and restart the service," click OK.
9. Stop and restart the service, and then click OK.
10. Wait a minute or two, and then return to Review problems and solutions page.
11. Verify that the warning no longer appears.
3. Reset the Farm Timer Service
1. Login to the local machine hosting the farm Central Administration application.
2. Go: Start > Administrative Tools > Services.
3. Scroll down to the SharePoint 2010 Timer service.
4. Double-click this service.  The services properties dialog appears.
5. Select the Log On tab.
6. If not selected, select  the This account option.
7. Enter or re-enter the farm account. For this posting, the farm account is Contoso\sp_farm:
   
8. At the warning prompt, "The new login name will not take effect until you stop and restart the service," click OK.
9. Stop and restart the service, and then click OK.
10. Wait a minute or two, and then return to Review problems and solutions page.
11. Verify that the warning no longer appears.

Summary

This posting presented steps for resolving the Health Analyzer warning, Accounts used by application pools or service identities are in the local machine Administrators group.  It has also presented troubleshooting steps for resolving this warning, if the usual approach appears to fail.  For additional detail on this topic, see the references below.

References

• Accounts used by application pools or service identities are in the local machine Administrators group (SharePoint Server 2010)
• Account permissions and security settings (SharePoint Server 2010)
• Plan administrative tasks in a least-privilege environment (SharePoint Server 2010)
• Initial deployment administrative and service accounts (SharePoint Server 2010)
• Service Account Suggestions for SharePoint 2010
• Configure profile synchronization (SharePoint Server 2010)
• Should my farm account be in the local admins group?

Notes

• If you have not previously modified the services directly, through the Windows Services control applet, you will likely see the account entered as "[domain]\[account name]."  This is how it looks after a fresh install.  Once you edit the account, it will change to "[account name]@[domain]."  This is one way to tell if you need to restart the service.