This post is a contribution from Paul Chan, an engineer with the SharePoint Developer Support team

This blog article will list the popular tools that can be used when troubleshooting performance issues. Note that the tools being mentioned here are listed in random order.

NOTE: If you feel needed or press on time, feel free to contact Microsoft and create a support case to work with us, instead of dragging the resolution of the issue for too long until the last minute.

Task Manager: This is the first tool can be used to identify high memory and high CPU scenario; e.g. to check if it is the w3wp.exe process taking a lot of memory or CPU cycles. This tool is always available from the OS. However, it only gives a high level point of view with no specific details.

Performance Monitor: This is another tool to identify which process is taking high memory or CPU. It also provides a logging option that you can track the usages in a period of time. However, it still won’t give you the clear target where the issue comes from.

Custom Logging: This method is being mentioned in both the high CPU and slow issues (in Part 2 and Part 3). To be honest, it is more useful in slow issues than high CPU issues. This method could be the one that give you the clearest target where the slowness come from.

Code Review: Although code review is the method being mentioned in all 3 types of performance issues, it is not really troubleshooting but trouble-scanning; i.e. it’s not shooting at any specific target but more like shooting in the dark; especially when it’s up to high memory usage. This is the main tool to use that fits all 3 types of performance issues though.

NP .NET Profiler: I mentioned it in Part 1 and 3 before. This is a nice tool but it does have its limitation. I think it can also be used in small scale code tests as well. One of the good things about this tool (if it does apply) is it doesn’t need to modify any code that it attaches itself to the process to do the profiling. But the main drawback is it needs to terminate the process when attaching and detaching itself.

Microsoft SharePoint Development Support: What do we do in our support team? Do we have any secret scrolls or magic spells? Maybe someone in the team does, but not me. Basically, we troubleshoot performance issues using the similar tools I mentioned as the condition fits. Of course, we might also use some tools that only available internally in Microsoft. Personally, I also rely on memory hang dumps to troubleshoot performance issues. However, this specific topic is too much to cover that it is not suitable to discuss in a small blog article like this. Memory dump analysis is not an internal thing to Microsoft only, you can look it up over the internet and you will find people discuss about it.

DebugDiag: This is a tool that associated to the memory hang dumps mentioned above. This tool provides an Analysis feature that it does the memory dump analysis via a script. So it kind of sits between a memory hang dump analysis done by a human being, and the tools that only give a high level overview of the issue. However, everyone have an uncomfortable feeling about analyzing data automatically done by a script. On the other hand, understanding its analysis results could be challenging as well. However, it is better than nothing, and don’t get me wrong that it is in fact a good tool. I personally use this tool as a reference in addition to my own memory hang dump analysis. Talking about how to use this tool will take a long time, not to mention how to read its results. Obviously, I will not include such information in this blog article. Lookup the term DebugDiag over the internet and you will find a lot of references about it.

ULS Log: This tool has been overlooked from time to time that people usually open the logs when there is an error pops up along with a correlation Id. Performance issues usually don’t apply to this because they are not really errors or exceptions from the code, but a symptom caused by the environment (exposed by the code). However, sometimes the ULS logs will provide useful information; such as query time taken, that could help in slow issues. If you are using the SPMonitoredScope to do the logging in the code, the log also provides the timestamp and what activities are happening around that time. Looking into ULS log without correlation Id is painful and need patience, but sometimes this is what needs to do.

NOTE: For any performance issues that you don’t feel comfortable to handle, please feel free to create a support case and work with Microsoft support. We do not want the resolution of our customer issues being delayed.

This post is a contribution from Jaishree Thiyagrajan, an engineer with the SharePoint Developer Support team

When we add a files with name containing only symbols like "([{_$%]}).txt" as an attachment to a list, we will see the error "The file/folder name that contains characters that are not allowed" & the attachment will not be added. But the item will be added.

We need to create a ItemEventReceiver and use ItemAttachmentAdding method to achieve the required functionality  

We cannot use ItemAdding event for the above requirement as we would not able to get the attachment name because the ListItem is null.

This post is a contribution from Aravinda Devagari, an engineer with the SharePoint Developer Support team

When you are using a custom HTTP module with a SharePoint site, you will notice that if you go ahead and create a custom list view you will get an error: “Cannot complete this action.  Please try again.” This is primarily because the HTTP module reads the request body and there is no request body left for the OWSSVR.dll to read. We will find 404 error in IIS.

The only workaround available for this is:

Bypass the HTTP module when the URLs contain OWSSVR.dll, so a simple If statement on the HTTPModule’s Begin request event and check if the request URL contains  “OWSSVR”, if it does, do not read or process the request body. You could use the following snippet of code, to achieve this requirement:

public class CustomModule : IHttpModule
    {
        public void Init(HttpApplication application)
        {
            application.BeginRequest += new EventHandler(this.OnBeginRequest);
        }
        void OnBeginRequest(object sender, EventArgs e)
        {
            if (HttpContext.Current.Request.Url.AbsolutePath.ToLower().Contains("owssvr.dll"))
            {
                return;
            }
        }
    }

This post is a contribution from Pavan Kumar, an engineer with the SharePoint Developer Support team

I worked on a very interesting case where I had to execute powershell commands in web method of a web service. But while executing powershell command I get following error

"The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception."

When I try the same on Sharepoint 2010 it works fine but this fails only on Sharepoint 2013 environments

After a lot of digging I could find the resolution

In the web.config of my web application I changed the legacyCasModel to "false" in the below tag

<trust level="Full" originUrl="" legacyCasModel="true" />

To know more about “legacyCasModel” refer to this article

This post is a contribution from Pavan Kumar, an engineer with the SharePoint Developer Support team

I worked on a very interesting issue where in upgrade of Sharepoint App failed consistently on OnPremise Sharepoint 2013 installation. While I was reviewing the ULS logs I could find that there was an AppLifeCycleError_TimeOut. Portion of ULS is given below

<SPAppInstanceErrorDetails xmlns="http://schemas.datacontract.org/2004/07/Microsoft.SharePoint.Administration" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><CorrelationId>510b97ff-212d-45ec-ba23-20b13c68a243</CorrelationId><ErrorDetailToken>AppLifecycleError_Timeout</ErrorDetailToken><ErrorType>Transient</ErrorType><Source>Common</Source><exceptionDetailedMessage i:nil="true"/><exceptionMessage i:nil="true"/></SPAppInstanceErrorDetails>

Digging further I could find that the reason for this behavior was that the time taken for the App to get upgraded was exceeding the default limit as the number of files to be upgraded were huge.

To overcome this we will need to add a new property “ExtendedAppWebTimeout” to SPFarm object’s property collection.

Below are the steps which were followed to resolve the issue

To add this property, close all instances of PowerShell and SharePoint 2013 Management Shell and open a new instance of SharePoint 2013 Management Shell in admin mode. Then execute the following commands.

$farm = Get-SPFarm

$farm.Properties.Add("ExtendedAppWebTimeout",20)

$farm.Update()

Write-Host "ExtendedAppWebTimeout property added successfully"

To remove this property, close all instances of PowerShell and SharePoint 2013 Management Shell and open a new instance of SharePoint 2013 Management Shell in admin mode. Then execute the following

$farm = Get-SPFarm

$farm.Properties.Remove("ExtendedAppWebTimeout")

$farm.Update()

Write-Host "ExtendedAppWebTimeout property removed successfully"

NOTE : This is applicable only for Sharepoint 2013 OnPremise installation

This post is a contribution from Pavan Kumar, an engineer with the SharePoint Developer Support team 

Recently worked with a customer who had deployed a Provider hosted App to their Sharepoint O365 tenant and the remote web was an IIS website which was OnPremise. The App worked fine for a while and it started to fail after sometime with following error

Invalid issuer or signature.

at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.VerifySignature(String signingInput, String signature, String algorithm, SecurityToken signingToken)

at Microsoft.IdentityModel.S2S.Tokens.JsonWebSecurityTokenHandler.ReadTokenCore(String token, Boolean isActorToken)

at ECompliance.ApplicationForms.TokenHelper.ReadAndValidateContextToken(String contextTokenString, String appHostName)

at ECompliance.ApplicationForms.TokenHelper.GetClientContextWithContextToken(String targetUrl, String contextTokenString, String appHostUrl)

at ECompliance.ApplicationForms.Masters.AppInitiator.Page_Load(Object sender, EventArgs e)

By executing below command we identified that the Client Secret had expired

Get-MsolServicePrincipalCredential -AppPrincipalID "<ClientID> as outlined in this article.

We created a new Client Secret and used that in the web.config file of the Remote Web, but the issue persisted.

We used below command to remove all the client secrets which were already available including the expired one.

Remove-MsolServicePrinicipal -AppPrincipalId "<ClientID>" -KeyIds "<GUID>"

Refer to this article to get more information about this command.

We created a new client secret and added it to the web.config file. Refer to this article on how to create and update to use new client secret.

After creation and updating to new client secret we will have to wait for 8 hours for this to work.

Reason for this 8 hour wait is Sharepoint Online servers are in PST time zone and Azure is in UTC time zone. Time difference between PST and UTC is 8 hours.

We tested the App after 8 hours and issue resolved.

Hope this post helps if you happen to hit this issue at some point in time !!!

This post is a contribution from Jaishree Thiyagarajan, an engineer with the SharePoint Developer Support team   

This blog is applicable to both Sharepoint 2010 and 2013 environment.

Say you have a Sharepoint 2010 Designer “List workflow” associated to a List. Whenever an item is added to the list, the Workflow gets triggered. If you encounter the error /message “Workflow failed to start and it was cancelled by System Account” in the Workflow History List, then please try the following to resolve the issue.

1. Check whether the workflow files like *.xoml, *.wfconfig, *.rules etc, are in check out state.

a. Open site in the Sharepoint designer

b. Click All files and open the Workflow folder.

c. Navigate to your SPD workflow and you can see the below files.

d. If the above are in “checked-out” state, try to check them in.

2. If you encounter the error “Cannot perform this operation. The file is no longer checked out or has been deleted” when you check in, then Your Workflow Hidden library might contain some extra columns (that are in required state)

a. There will be a hidden “workflow library” associated to every site. To navigate to the hidden library, follow the KB http://support.microsoft.com/kb/2273439

i. Go to Properties of the Workflow library and get the List Id.

ii. Navigate to http://yourSite/_layouts/listedit.aspx?List=ListID

b. The only permitted columns are

i. Created By

ii. Modified By

iii. Checked Out To

c. If you have any other columns, then those should be “optional”. So make the other columns as optional.

3. Now try to check-in the Workflow files (as per Step 1).

Now your Workflow should run successfully.

This post is a contribution from Aravinda Devagari, an engineer with the SharePoint Developer Support team

· First convert the 2010 classic mode web application to claims web application by following the steps below.

$webapp = "http://sp:29616"

$wa = Get-SPWebApplication $webapp

$wa.UseClaimsAuthentication = $true

$wa.Update()

$account = "contoso\administrator"

$account = (New-SPClaimsPrincipal -Identity $account -IdentityType 1).ToEncodedString()

$wa = Get-SPWebApplication $webapp

$zp = $wa.ZonePolicies("Default")

$p = $zp.Add($account,"PSPolicy")

$fc = $wa.PolicyRoles.GetSpecialRole("FullControl")

$p.PolicyRoleBindings.Add($fc)

$wa.Update()

$wa.MigrateUsers($true)

$wa.ProvisionGlobally()

· OR follow http://technet.microsoft.com/en-us/library/gg251985(v=office.15).aspx to convert the web application afterwards in 2013 environment, but the above should be easier.

· Backup the database from 2010 and copy it over to 2013 SQL environment.

· Create a new web application on 2013 and delete the default content database created.

· Restore the backed up database to 2013 SQL instance.

· Import the 2010 solution to VS 2012 or 2013 and deploy it to 2013 environment as a farm solution.  Before deploying to 2013 environment, ensure that you change the template ID from 10000 to 11111[ You can take any other number greater than 10000]

· Copy the original webtemp*.xml and the site definition folder to the corresponding locations on the 2013 server but in 14 hive. [Note: this webtemp*.xml will have the template ID as 10000]

· Then create a UDF with a definition as shown in sample below.  In relation to your custom site definition, the highlighted statements below are the ones that are important.

· Save this UDF as “WssUpgrade_SiteDefinitionProject1.xml” to the following path C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\CONFIG\UPGRADE\WSSUpgrade_CustomSideDef.xml.

· Issue a Test-SPContentDatabase command through SharePoint 2013 Management Shell as shown below and ensure the output is what you see below.

· Then issue the Mount-SPContentDatabase command as shown below:

· This should upgrade the content database and attach it to the empty web application.

· Post this when you browse to the site, you will see it’s in 2010 mode as shown in below.

· But after you click the “Start now” link in the light red status bar above or navigate to Site Actions àSite Settings àSite collection upgrade and click on Upgrade this Site Collection and then click the “I’m ready” button, the site collection should be upgrade to 2013 look and feel.

· For the sites upgraded the Template ID would continue to be 10000, but the site that are going to be created with this custom site definition will have the new template id.

This post is a contribution from Aaron Miao, an engineer with the SharePoint Developer Support team

Like myself, many of you may like the SharePoint Online API GetSiteProperties that lists all site collections of a SharePoint Online tenant. Unfortunately, as you know, the method was only available to SharePoint Online, although the document does not explicitly remark this.

Now the good news is that SharePoint team has made the same method available to SharePoint Server 2016 on-premises! You can get this from SharePoint 2016 October PU.

Here’s the sample code you could find online out there.

using Microsoft.SharePoint.Client;
using Microsoft.Online.SharePoint.TenantAdministration;

using (ClientContext ctx = new ClientContext("http://siteurl"))
{
   ctx.Credentials = System.Net.CredentialCache.DefaultCredentials;
   SPOSitePropertiesEnumerable spp = null;
   Tenant tenant = new Tenant(ctx);
   int startIndex = 0;


   while (spp == null || spp.Count > 0)
   {
     spp = tenant.GetSiteProperties(startIndex, true);
     ctx.Load(spp);
     ctx.ExecuteQuery();
     foreach (SiteProperties sp in spp)
     {
         Console.WriteLine(string.Format("Site: {0} -> URL: {1}", sp.Title, sp.Url));
     }

     startIndex += spp.Count;
  }
}

For SharePoint Online, the code will just work. However, for SharePoint 2016 on-premises, you need to follow the steps below to set environment.

Please follow Provisioning site collections using SP App model in on-premises with just CSOM post for a more details.

Here’re the required steps:

1. Install October 2016 PU for SharePoint 2016 to your SharePoint 2016 farm.
2. Download SharePoint Server 2016 Client Components SDK that to your remote development environment where you write your CSOM code This contains 16 version of the objects which are also needed with SP2016 on-premises. These are located in the Online.SharePoint.Client.Tenant.dll assembly, which is by default installed to C:\Program Files\SharePoint Client Components\16.0\Assemblies folder.
3. Enable Tenant admin server stub using just CSOM by running PowerShell script below.

$WebApplicationUrl = "http://webappurl"
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}

if ($snapin -eq $null)
{
  Write-Host "Loading SharePoint Powershell Snapin"
  Add-PSSnapin "Microsoft.SharePoint.Powershell"
}

$webapp=Get-SPWebApplication $WebApplicationUrl
$newProxyLibrary = New-Object "Microsoft.SharePoint.Administration.SPClientCallableProxyLibrary"
$newProxyLibrary.AssemblyName = "Microsoft.Online.SharePoint.Dedicated.TenantAdmin.ServerStub, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
$newProxyLibrary.SupportAppAuthentication = $true
$webapp.ClientCallableSettings.ProxyLibraries.Add($newProxyLibrary)
$webapp.Update()

Write-Host "Successfully added TenantAdmin ServerStub to ClientCallableProxyLibrary."
# Reset the memory of the web application
Write-Host "IISReset..."
Restart-Service W3SVC,WAS -force
Write-Host "IISReset complete on this server, remember other servers in farm as well."

4. Enable AdministrationSiteType property from one site collection in your on-premises farm which will be acting like a admin site. This could be, for example, root site in the root site collection of the web application where you call the new API on it.

 $siteColUrl = "http://siteurl"
 $site = get-spsite -Identity $siteColUrl$site.AdministrationSiteType = [Microsoft.SharePoint.SPAdministrationSiteType]::TenantAdministration
 Write-Host "Enabling side-loading...."
 Enable-SPFeature e374875e-06b6-11e0-b0fa-57f5dfd72085 –url $url

Note:
Namespace Microsoft.Online.SharePoint.TenantAdministration (in Microsoft.Online.SharePoint.Client.Tenant.dll) introduces new set of client APIs to SharePoint 2016 on-premises. However, please note that it is not identical to SharePoint Online version.