SharePoint 2013 TIP: how to remove a user from a site

You have a user that has been directly assigned permissions to a particular site in the site collection. You see this user listed when you go Site Settings > Site permissions. The user has been assigned permission to the site directly and not through membership in any site group.  You want to remove the user from the site but not from the site collection itself.  You don't really want to "remove" the user from the entire site collection.  You need this user to remain a part of the site collection so that when other users click on that username (e.g., associated with a document), they will still see the user properties and not an error page.  So, you don't really want to remove the user from the site using $web.SiteUsers.Remove($user).  What to do?

Solution

1. Note down the URL of the site you want to remove the user from.
2. Note down the permission level that the user is (e.g., Read, Contribute, Full Control, etc)
3. Open an elevated SharePoint Management Shell.
4. Execute the following:

   Set-SPUser -Identity "[username]" -Web "[URL to the site]" -RemovePermissionLevel "[Permission level]"

5. That's it.

References

• Set-SPUser

SharePoint 2013: attempting to share a file returns an error

Problem

A user attempts to share a file using the usual process (click on the ellipsis, and the click Share) and experiences the Sorry, something went wrong error message

You connect to the list while logged in using your standard account and verify the user experience. You then check Web Front End (WFE) ULS logs and find a block of messages, one of which includes:

Application error when access /_layouts/15/aclinv.aspx, Error=Only a limited set of people are allowed to share this content. at Microsoft.SharePoint.ApplicationPages.AclInv.InitPage() at Microsoft.SharePoint.ApplicationPages.AclInv.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

While logged into a WFE using a farm administrator account, you again attempt to share the file using the usual process and this time do not experience the error message.  You then check the list's Access Request Setting and find it disabled:

The error messages and your findings indicate that the problem involves permissions and configuration.

Solution

1. Connect to the list using a farm administrator account.
2. Go: Settings > Users and Permissions > Site permissions.
3. Select the PERMISSIONS ribbon.
4. In the Manage group, click the Access Request Settings button
   
5. Enable Allow access requests, enter the appropriate email address for the person who will handle these requests, and then click OK.

References

• Share a document using SharePoint or OneDrive
• Set up and manage access requests
• Sharing Content in SharePoint 2013

Notes

• Site Collection Administrators and Site Owners have the permissions necessary to configure the Allow Access Requests setting.

SharePoint 2013: Workflow 2013: Sorry, something went wrong

Problem

Your users report that, when they launch a 2013 workflow, nothing happens for a minute or two, and then they are presented with the Sorry, something went wrong, page (below).  Workflow foundation is installed to a SharePoint application server.  Your farm is patched through June 2015.

Troubleshooting

1. Tested all 2013 workflows available from the web application and found that all 2013 workflows failed.  
2. Testing 2010 workflows and found that they continued to function as expected. 
3. Checked that the following services were started on the server hosting Workflow Foundation:
1. Service Bus Gateway
2. Service Bus Message Broker
3. Windows Fabric Host Service
4. Workflow Manager Backend
4. Checked the Unified Logging System (ULS) logs and found a block of messages associated with the correlation ID.  Some examples:

   A runtime exception was detected. Details follow.  Message: Thread was being aborted.  Technical Details: System.Threading.ThreadAbortException: Thread was being aborted.    
    at System.Threading.WaitHandle.WaitOneNative(SafeHandle waitableSafeHandle, UInt32 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)    
    at System.Threading.WaitHandle.InternalWaitOne(SafeHandle waitableSafeHandle, Int64 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)    
    at Microsoft.Workflow.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)    
    at Microsoft.Workflow.Client.HttpGetResponseAsyncResult`1.End(IAsyncResult result)    
    at Microsoft.Workflow.Client.ClientHelpers.SendRequest[T](HttpWebRequest request, T content)    
    at Microsoft.Workflow.Client.HttpWorkflowNotificationPublisher.OnPublishNotification(String address, WorkflowNotification notification, ICredentials credentials, String userCulture, Guid traceActivityId, TimeSpan requestTimeout)    
    at Microsoft.Workflow.Client.WorkflowNotificationPublisher.PublishNotification(String address, WorkflowNotification notification, ICredentials credentials, String userCulture, Guid traceActivityId, TimeSpan requestTimeout)    
    at Microsoft.Workflow.Client.WorkflowManagementClient.PublishNotification(WorkflowNotification notification, IDictionary`2 activationMetadata, Int64 expectedScopeRevision)    
    at Microsoft.SharePoint.WorkflowServices.WorkflowProxy.PublishEvent(String eventSource, String eventType, IDictionary`2 payload, SPUserToken userToken)

   and

   Leaving Monitored Scope (Event Receiver (Microsoft.SharePoint.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, Microsoft.SharePoint.WorkflowServices.ContentSubscriptionEventReceiver)). Execution Time=118831.7039
   

   and others
   
   This block of messages recurred whenever a 2013 workflow was initiated.
5. Launched elevated SharePoint Management Shell, and then executed the following to check on Workflow and Service Bus configuration status:

   Get-WFFarm
   Get-WFFarmStatus
   Get-SBFarm
   Get-SBFarmStatus

6. Opened a browser, and then connected to:

   https://[FQDN]:12290 or http://[FQDN]:12291

   where FQDN is the fully qualified domain name of the server hosting the farm's workflow foundation.
7. Check installed versions
1. Workflow Manager 1.0: 2.0.20922.0
2. Workflow Manager client 1.0: 2.0.40131.0
3. Service Bus 1.0: 2.0.20922.0
4. Windows Fabric: 1.0.960.0

After performing these steps, you find that everything checks out as you would expect if everything was running normally; and no immediately obvious issue is found. Yet, the fact remains that when a 2013 workflow is triggered, it eventually returns an error.

Solution

1. Perform upgrade using: Psconfig.exe -cmd upgrade -inplace b2b -wait -force.

References

• SharePoint logging and troubleshooting using ULSViewer
• Troubleshooting Workflow Manager 1.0 Management and Execution
• Workflow Manager
• Getting started with SharePoint Server 2013 workflow
• SharePoint 2013 workflow fundamentals
• Debugging SharePoint Server 2013 workflows
• Psconfig command-line reference (SharePoint Server 2010)
• SharePoint PSConfig

Notes

• I discovered this solution accidentally: after installing the July 2015 patches, which requires you to execute psconfig in order to do the upgrade, and then doing the usual regression testing, I found that, as a bonus, the workflow problem was resolved. Later, I was informed by Microsoft Support that psconfig was one of the options they were considering to resolve our workflow problem (I had previously opened a support ticket with them).

SQL Server 2012: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {FDC3723D-1588-4BA3-92D4-42C430735D7D}

Problem

You review the server's Application log on the server hosting your SharePoint 2013 farm's SQL Server backend, and you see the following application error occuring at 2-hour intervals:

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          [time/date stamp]
Event ID:      10016
Task Category: None
Level:         Error
Keywords:      Classic
User:          [DOMAIN\spSQL]
Computer:      [server name]
Description:
The application-specific permission settings do not grant Local Activation 
permission for the COM Server application with CLSID 
{FDC3723D-1588-4BA3-92D4-42C430735D7D}
 and APPID 
{83B33982-693D-4824-B42E-7196AE61BB05}
 to the user DOMAIN\spSQL SID (S-1-5-21-1258338518-4216542334-3912338986-3766) 
from address LocalHost (Using LRPC) running in the application container 
Unavailable SID (Unavailable). This security permission can be modified using 
the Component Services administrative tool.
Event Xml:
...

Solution

1. Launch RegEdit and perform a search on the APPID presented in the error message.  You will find this APPID associated with the Microsoft SQL Server Integration Services 11.0 service.
   
   Resolving this error follows pretty much the same steps undertaken to resolve other DCOM errors.  Namely, you need to enable the local launch and local activation permission.
2. Launch the Component Services applet, navigate to Console Root > Component Services > Computers > My Computer > DCOM Config.
3. Scroll down to Microsoft SQL Server Integration Services 11.0.
4. Right-click and choose Properties.  A dialog appears.
   
   .
5. In the Launch and Activation Permissions group, click the Edit button.  
6. Add the SQL Server service account (eg, spSQL), allow it both the Local Launch and Local Activation permissions,
   
   and then click OK.

   If you experience an error after clicking OK, to the affect that you don't have permissions to do this, you will need to return to the registry key you looked at earlier, take ownership of it, and then grant full control over this key to the SQL Server service account identified in the error message.  Don't worry: this is a common problem.  

7. The resolution is implemented immediately.

References

• Event 10016
• DistributedCOM Event 10016
• SQL server getting Event ID 10016 every hour
• The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

Notes

• I continued to monitor for this event for up to one week afterwards and did not observe this error to return.

SharePoint 2013 TIP: how to get list of all documents in all document libraries using PowerShell

This is a re-post of a script developed by Gary LaPointe.

Script

function Get-DocInventory() 
{
    [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
    $farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
    foreach ($spService in $farm.Services) {
        if (!($spService -is [Microsoft.SharePoint.Administration.SPWebService])) {
            continue;
        }
        foreach ($webApp in $spService.WebApplications) {
            if ($webApp -is [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]) { continue }
            foreach ($site in $webApp.Sites) {
                foreach ($web in $site.AllWebs) {
                    foreach ($list in $web.Lists) {
                        if ($list.BaseType -ne "DocumentLibrary") {
                            continue
                        }
                        foreach ($item in $list.Items) {
                            $data = @{
                                "Web Application" = $webApp.ToString()
                                "Site" = $site.Url
                                "Web" = $web.Url
                                "list" = $list.Title
                                "Item ID" = $item.ID
                                "Item URL" = $item.Url
                                "Item Title" = $item.Title
                                "Item Created" = $item["Created"]
                                "Item Modified" = $item["Modified"]
                                "File Size" = $item.File.Length/1KB
                            }
                            New-Object PSObject -Property $data
                        }
                    }
                    $web.Dispose();
                }
                $site.Dispose()
            }
        }
    }
}
Get-DocInventory | Out-GridView
#Get-DocInventory | Export-Csv -NoTypeInformation -Path c:\inventory.csv

References

• Getting an Inventory of All SharePoint Documents Using Windows PowerShell
• Export-Csv
• Out-GridView

Notes

• Many thanks to Gary for making available this remarkably simple script for interrogating SharePoint for all documents.

SharePoint 2013: Get-SPWeb : Cannot find an SPSite object that contains the following Id or Url

Problem

You are attempting to execute a Get-SPWeb, Get-SPSite or similar commandlet in an elevated SharePoint Management shell, but each time experience an error of type,

Get-SPWeb : Cannot find an SPSite object that contains the following Id or Url: htp://[yoursite]

One possible cause for this error is the SecurityTokenService.

Solution

• In IIS, stop and start the SecurityTokenServiceApplicationPool.

References

• None