Wednesday, August 19, 2015

Create a common visual studio project to develop different versions of SharePoint solutions


The following sample is to illustrate how to create a common visual studio project to develop different versions of SharePoint solutions. In some case we may need to develop a solution that would to be deployed in different versions of SharePoint. In this article we discuss about developing a common solution using Visual studio that can run for both SharePoint 2010 and 2013.


1.      Launch Visual Studio 2012 from a machine where SharePoint 2010 is installed
2.      Click New project
3.      Select .NET Framework 3.5 and select SharePoint 2010 – Empty Project
4.      Provide the name, solution name and click Ok
5.      In SharePoint Customization Wizard, provide the local SharePoint web application URL and deploy as farm solution
6.      Click Solutions Configuration drop down and select Configuration Manager
7.      Make sure the Solution has 4 configurations Debug_SP2010, Release_SP2010, Debug_SP2013 and Release_SP2013. Copy settings from respective modes.
All added configurations
8.      Right click the Project and Select properties.
9.      Select Build section, select “Debug_SP2010” from Configuration.
10.   Enter the value as “SP2010” for “Conditional Compilation Symbols” field. Give the same value for “Release_SP2010” also. Similarly provide “SP2013” for “Debug_SP2013” and “Release_SP2013” configurations.
11.   Right click the project and create a folders to store the assembly files of both the versions in respective folders.
12.   Right click the project and click unload project
13.   Right click the project again and click Edit project file
14.   Add <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> under <PropertyGroup></PropertyGroup> for both Debug_2010 and Release_2010 configurations. Also add
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion> for both Debug_2013 and Release_2013 configurations
15.   Add Reference to the appropriate assemblies to load from respective folders during compilation.
16.   Add all required artifacts to the project and compile/build by setting the configuration manager to appropriate build version to get respective SharePoint solutions.

Tuesday, August 4, 2015

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel


Using SAML Authentication in SharePoint 2013 and was trying to access a service application from SSL enabled Portal.
Exported the service application security certificate and imported into SharePoint Trusted Root Certificate authority


Following is the error message when trying to connect to service application from SharePoint.


The imported certificate is having some validation error. The problem was incorrect host name used in certificates.
We were accessing the URL using the IP and the certificate is using the server name as ip-AC1F08ED. Either we should have service application URL with fully qualified domain name or the certificate issue should point to the server IP.

Following error in event viewer.

Tuesday, July 14, 2015

Close Modal Dailog on submit/cancel in application page

Assumption: The model dialog is opened using SP.UI.ModalDialog.showModalDialog().

Add the following line of code under script tag.

    SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.OK, 'SP.UI.DialogResult.OK');

Friday, July 10, 2015

Users are not resolved in the people picker when SAML is enabled for the web application

Users are not resolved in the people picker when SAML is enabled for the web application

When a user authenticates to the SharePoint Portal, Azure AD does not include his group membership in the SAML token received by SharePoint, so SharePoint does not know to which groups the user belongs to, and hence it cannot make authorizations based on groups. The federation services are authentication systems only.

As per Microsoft, “When a web application is configured to use claims-based authentication, People Picker uses claims providers to resolve and display users, groups, and claims in the user or group text box. The information that SharePoint displays depends on the claims provider that is used by the authentication method that was configured for the web application. “. 

See Also:  

Create a custom claims provider. Claims provider queries Active Directory or any LDAP to add search capabilities to the people picker in SAML authentication mode (typically ADFS).
When we are searching for a user, we cannot go directly to ADFS because there is no search function.  Instead, we use a custom claim provider to query directly to some authentication store or directory such as Active Directory to retrieve information about a list of users in order to provide name resolution.

Thursday, July 9, 2015

Cannot login to SharePoint site enabled with SAML based authentication using WAAD

Environment: SharePoint 2013, Windows Azure AD service as Identity Provider.

Issue: Cannot login to SharePoint Portal working and getting Session has timed out error. Steps to reproduce
  1. Open SharePoint Portal
  2. Portal navigates to Azure login page
  3. After proving credentials, the page redirects to Azure login page

Cause: There is no SAMLResponse cookie available to validate the credentials and that is the reason why the login is failing. The FedAuth cookie that the SharePoint STS is setting before redirecting to SharePoint application is expiring. This is occurring because the cookie lifetime has exceeded the lifetime of the token issued by ACS, so it's redirecting to get a new SAML token from ACS immediately.

The login page keeps looping because because the default LogonTokenCacheExpirationWindow for the SharePoint STS is 10 minutes. The relying party by default it sets the token lifetime in ADFS to be 2 minutes, so as soon as it authenticated it knew the cookie was good for less time than the LogonTokenCacheExpirationWindow value. Therefore it goes back to ADFS to authenticate again. And so it goes , back and forth. So I needed to change the LogonTokenCacheExpirationWindow to be less than the SAML TokenLifetime.

Findings: The first time that you navigate to a SharePoint Portal that is secured with SAML claims, it redirects you to get authenticated and get your claims. Your SAML identity provider, also known as identity provider security token service (IP-STS), does all that and then redirects you to SharePoint. When you come back into SharePoint, SharePoint creates a FedAuth cookie; that is how SharePoint knows that you have been authenticated. To make a smoother end-user experience, SharePoint writes the FedAuth cookie value to the local cookies folder. On subsequent requests for that site, if SharePoint finds a valid FedAuth cookie for the site, SharePoint reads the cookie and takes you directly to the SharePoint content, without reauthenticating.
The token lifetime is determined by the Relying Party Trust in ADFS, and is stamped with the local time of that server before being sent to SharePoint. SharePoint is in charge of determining when it feels that the token has expired (based on the LogonTokenCacheExpirationWindow property). Both of these properties can be changed but unless you have a very specific scenario, there is likely no need. Default values work fine.


The default lifetime for the SharePoint Relying Party in ACS and the STS token cache lifetime is 10 minutes.  You can increase the SAML token lifetime in ACS on the SharePoint Relying Party trust to something higher that 600 seconds (10 minutes) so that the FedAuth cookie cache is lower than the SAML token lifetime.

See Also:

Monday, July 6, 2015

Convert SharePoint web application from HTTP to HTTPS

Requirement: Convert an existing web application from http to https site.

Associate an SSL certificate with the IIS website

1.       In IIS Manager, Select the IIS site that is running the SharePoint intranet application and click on the “Bindings” link on the right

2.       To enable SSL click “Add”, select “https” and select a SSL certificate.

3.       Click OK.

4.       Click on SSL settings and check Require SSL.

5.       Launch the Central Administration. 

6.       Go to Application Management → Alternate Access Mappings → Edit Public URLs

7.       Change the Default to the SSL site URL

8       Perform IISReset.

SharePoint 2013 Upgrade matrix

This article describes how the deployed solution packages can be upgraded. The upgrade approach depends on the kinds of changes done in the newer version of the solution. Following table show the supported upgrade options available based on the changes in the new solution

WSP Upgrade
Feature Upgrade
Using SOM / PowerShell
Code level changes (DLL changes)
JS, Html related changes
SharePoint Mapped folder file changes
(Control Templates, Layouts, Images)
Master file changes
Feature event Receiver code changes
New features addition
Remove existing feature
Modify existing features
Add new Site Column
Remove existing Site Column
Modify existing Site Column
Add Content Type
Remove Content Type
Modify Content Type
Changes in files uploaded in Document library using Modules (only for change in file properties, new files addition)
Remove files from Document Library
Add new list
Remove existing list
Modify existing List
Add new list items
Remove existing list items
Modify existing List items