Friday, August 28, 2015

Add users as SharePoint Shell Admin for specific site collection or content database

Recently we received a concern from one of our team members that they are not able to run PowerShell scripts against a specific web application or site collection. They were trying to Backup the site collection and using Backup-SPSite cmdlet.

However they were not able to do so and got the following error:

Backup-SPSite : Cannot open database "<database_name>" requested by the login.
The login failed.
Login failed for the user '<domain\username>'.
At line:1 char:14

We ran the following command to add the user as PS Shell Admin

Add-SPShellAdmin -UserName domain\username

However, even after doing so they were getting login failed error when trying to run PowerShell commands. The problem was occurring because as the error stated, the user's login did not have SharePoint_Shell_Access rights on the database. You can easily check this by checking the database security properties (from SQL management studio) and check the permissions of the account. If the account is not listed under Database -> Security -> Users, then it is obvious that the account does not have any permission on that content database.

When we run "Add-SPShellAdmin -UserName domain\username", it only added the user account under SharePoint Config database with SharePoint_Shell_Access rights. User's account was not added on any of the content databases with the Shell rights. That’s why when the user tried to backup a site collection, they were getting login failed error. For more details on what the Add-SPShellAdmin cmdlet, please refer to this article - https://technet.microsoft.com/en-us/library/ff607596.aspx

So what we had to do was to specifically grant SharePoint_Shell_Access rights by passing on the content database name like in the example below:

 Get-SPDatabase | ?{$_.Name -eq "WSS_Content"} | Add-SPShellAdmin -Username DOMAIN\Username


This solved the problem. Also, in case the user again complains for login failed error, you need to take a look at the site where he is trying to run the command and make sure that the account does have SharePoint_Shell_Access permissions on that database that is holding that site collection. If not, run Add-SPShellAdmin cmdlet by specifying the database. As always, its best practice to have the least permissions and review the SharePoint Shell Access rights using the command - Get-SPShellAdmin and remove any user accounts that are not supposed to be there.

Tuesday, November 29, 2011

A specified logon session does not exist. It may already have been terminated.

Issue:
On a Windows 2008 R2 or Windows 7 machine, you open Task Scheduler. You create a new task and the following conditions are used in the task.
  • The account used to run the task is another service account (i.e. author or the user who is trying to save the task) is different from the user who will be running the task
  • Option of “Run whether user is logged on or not” is selected.
  • Option of “Do not store password. The task will only have access to local computer resources.” is not selected.
When you try to save the task with the above general settings, we receive error.

Error Message:
An error has occurred for task <TaskName>. Error message: The following error was reported: A specified logon session does not exist. It may already have been terminated.

Cause:
This occurs because the local security policy has the following setting:
Network access: Do not allow storage of passwords and credentials for network authentication - Enabled.

Resolution:
To verify whether the security policy is causing the issue. Log on to the machine where you are facing the problem.
  • Start -> Administrative Tools -> Local Security Policy
  • Security Settings -> Local Policies -> Security Options
  • Network access: Do not allow storage of passwords and credentials for network authentication setting should be Enabled.
Just FYI, the corresponding registry key for this setting can be found here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Key Name: disabledomaincreds
Current Key Value: 1
The value of “1” means that the policy is enabled. It must be “0”.

NOTE: If you change the registry value to “0”, you should be able to save the task. Do not make registry changes unless you are absolutely sure. Only use it for checking it this resolves the issue or not on a test machine. Actual resolution is to update the group policy and disable the security policy mentioned above. It will take care of this registry.
Disable the policy from domain controller and run a group policy update.

Monday, November 7, 2011

SharePoint 2010 - Crawling stuck, crawl component in "Recovering" state


From past few days we started this issue out of now where. The crawler is stuck. When we browse to the Search Administration page, we see that the Crawler component is stuck in "Recovering" state and due to that Query component also reported a status as "Not Responding". Propogation status was shown as "Query server not responding"

We checked the SharePoint logs and found errors as below

file copy failed (error 0x80070005: Access is denied.   0x80070005, source c:\program files\microsoft office servers\14.0\data\office server\applications\GUID-crawl-0\projects\portal_content\indexer\cifiles\0001001A.ci, destination \\machinename\GUID-query-0\GUID-query-0\Projects\Portal_Content\Indexer\CiFiles\0000.0001001A.ci.cp)  [indexpropagator.cxx:403]  d:\office\source\search\native\ytrip\tripoli\propagation\indexpropagator.cxx

Exception thrown (0x80070005: [needs message] info 0)                           [indexpropagator.cxx:409]  d:\office\source\search\native\ytrip\tripoli\propagation\indexpropagator.cxx

In Event Viewer, we found Event ID: 2587 with the description that "The following conditions are currently affecting index propogation to this server for search service application "Service Application Name": 1. Query 0 has been disabled so that crawls can continue. It may be recovered via the Restart-SPEnterpriseSearchQueryComponent command in PowerShell

The code - 0x80070005 states that the access was denied and the account accessing the folder did not have permissions.

I granted permissions for the service and crawler account on c:\program files\microsoft office servers\14.0\data\office server\applications\
But this did not resolve the issue. This meant that apart from the location mentioned in the logs, the permission issue was somewhere else too. In such cases, process monitor does help. I took a process monitor and found that there were errors related to permissions on C:\ProgramData and few of its SharePoint subfolders. After granting the service and crawler account permission (Full Control) over the C:\ProgramData folder, the status of the components was not showing as "Online".

In case you face such errors, try giving permissions for the search service and crawler account (in case they are different) over the C:\ProgramData folder and check. If not, take help from Process Monitor to find out where the permission issue is.

Do not remove, add or restart any component unless you are absolutely sure that permissions or any of the below mentioned causes is not an issue.

Few other things to verify:

Update: Recently we noticed that restarting the server running the component would get the component back to "Online" state. Before restarting any services or running PowerShell cmdlet, try rebooting the server.

Wednesday, October 12, 2011

SharePoint 2010: User Profile Service not starting, remains in Stopped state

Issue:Not able to start User Profile Synchronization Service from “Services on Servers” page in Central Administration.

Symptoms:You have created a User Profile Service Application and now would like the User profile synchronization service to start only on specific servers. So, you go to Central Administration –> Application Management –> Services on Server.
On this page, you try to start the “User Profile Synchronization Service”. It stalls on “Starting” state for a minute or two and then reverts back to “Stopped” state.

Error Messages(s):When the status of the service returns to “Stopped” state following errors are logged in event viewer.

Log Name:      Application
Source:        Microsoft Resource Management Service
Date:          xx/xx/xxxx x:xx:xx xx
Event ID:      0
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer: xxxxxxxx
Description:
Service cannot be started. System.Data.SqlClient.SqlException: Could not find stored procedure 'RegisterService'.
   at Microsoft.ResourceManagement.WindowsHostService.OnStart(String[] args)
   at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)


Log Name:      Application
Source:        Forefront Identity Manager
Date:          xx/xx/xxxx x:xx:xx xx
Event ID:      3
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      xxxxxxxx
Description:
.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: Could not find stored procedure 'RegisterService'.
   at Microsoft.ResourceManagement.Utilities.ExceptionManager.ThrowException(Exception exception)
   at Microsoft.ResourceManagement.Data.Exception.DataAccessExceptionManager.ThrowException(SqlException innerException)
   at Microsoft.ResourceManagement.Data.DataAccess.RegisterService(String hostName)
   at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.RegisterService(String hostName)
   at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.Initialize()
   at Microsoft.ResourceManagement.WebServices.ResourceManagementServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses)
   at Microsoft.ResourceManagement.WindowsHostService.OnStart(String[] args)


Log Name:      Application
Source:        Microsoft.ResourceManagement.ServiceHealthSource
Date:          xx/xx/xxxx x:xx:xx xx
Event ID:      2
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      xxxxxxxx
Description:
The Forefront Identity Manager Service could not bind to its endpoints.  This failure prevents clients from communicating with the Web services.

A most likely cause for the failure is another service, possibly another instance of Forefront Identity Manager Service, has already bound to the endpoint.  Another, less likely cause, is that the account under which the service runs does not have permission to bind to endpoints.

Ensure that no other processes have bound to that endpoint and that the service account has permission to bind endpoints.  Further, check the application configuration file to ensure the Forefront Identity Manager Service is binding to the correct endpoints.


Log Name:      Application
Source:        Microsoft.ResourceManagement.ServiceHealthSource
Date:          xx/xx/xxxx x:xx:xx xx
Event ID:      26
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      xxxxxxxx
Description:
The Forefront Identity Manager Service was not able to initialize a timer necessary for supporting the execution of workflows.

Upon startup, the Forefront Identity Manager Service must initialize and set a timer to support workflow execution.  If this timer fails to get created, workflows will not run successfully and there is no recovery other than to stop and start the Forefront Identity Manager Service. Restart the Forefront Identity Manager Service.


Cause:Incorrect permissions and configuration of the account that is used to run the Profile Synchronization Service.

Resolution:
  1. Add the account to local administrator’s group on the server where you are trying to start the service
  2. Restart the “SharePoint 2010 Timer Service” on the server.
  3. Ensure that you do not start the “Forefront Identity Manager” service manually. Although, if you want, you can change the service start up type to “Automatic (Delayed)”.
  4. Now, try to start the service from Central Administration –> Application Management –> Services on Server.

Monday, October 10, 2011

SharePoint Health Analyzer - Common Issues

I have seen in many SharePoint Farm installations where these messages usually show up in Health Analyzer page. Following are some basic steps that can be taken to get rid of the error/warning messages.

1- The server farm account should not be used for other services.
In the error description, you will see the names of the web application or windows services that is using the service account. Go to Central Administration -> Security -> Configure Service Accounts, Select the proper web application nor windows service and change the service account to an account which is not the system account. If there is no other domain account other than system account, use the Configure managed account page to register a new managed account.

2- Web.config files are not identical on all machines in the farm
Use a file utility like ExamDiff to check for differences in the web.config files. If the web.config files do not match up, make sure that the web.config files are similar across all the servers in the farm. Ensure you take a backup of the web.config files before replacing any files.
Then, you need to turn “off” automatic repair in “Web.config files are not identical on all machines in the farm” rule. This rule can be found in Central Administration -> Monitoring -> Health Analyzer Rule Definition -> under configuration category.




3- InfoPath Forms Services forms cannot be filled out in a Web browser because no State Service connection is configured
You will need to configure the State Service by running the configuration wizard. Detailed information can be found here - http://technet.microsoft.com/en-us/library/ff805084.aspx


4- Drives are running out of free space. 
Hard disk space is low on SP servers mentioned in the warning message. The available disk space should be at least or more than twice the amount of RAM installed on the machine.

Solution 1:  Free disk space on the server computer
1.     Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.
2.     Run the Disk Cleanup tool to free disk space on the server computer.
Solution 2:   Decrease the number of days to store log files
1.     Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
2.     On the Central Administration Home page, click Monitoring.
3.     On the Monitoring page, in the Reporting section, click Configure diagnostic logging.
4.     On the Diagnostic Logging page, in the Trace Log section, in the Number of days to store log files box, type a smaller number.
5.     Click OK.
Solution 3: Add more disk space on the server

5- Database has large amounts of unused space.
Database files are defragmented or have more storage allocated on disk than actually required.
Follow http://support.microsoft.com/kb/307487/en-us to defragment the databases.

You might find these articles useful