Restoring SharePoint WebApp

I have seen all kinds of issues while moving sites, webapps  from one environment to other. If your restoring a webapp on the same farm then you might get away with minimum trouble shooting but if its a different farm then you are at the mercy of google.

You can start with below trouble shooting steps.  I am assuming that you are restoring a webapp from Farm A to Farm B running with different service accounts.

  1. Backup the DB on Farm A and Restore it to SQL server of Farm B.
  2. Add all the service accounts from Farm A to Farm B and assign these accounts same permissions like that of Farm A, including local server admin permissions. DO NOT CHANGE ANY EXISTING SERVICE ACCOUNTS ON FARM B.
  3. Create a new webapp
  4. Dismount the DB on of this new webapp using Powershell  Dismount-SPContentDatabase. 
  5. Mount the restored DB using powershell  Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename

Now You should be able to open the webapp on FarmB.

You can also create the new webapp on Farm B using the restored DB instead of new DB but I have seen issues some times with this process. So I would like to create new site and then mount the existing DB.

Permissions of service accounts is the KEY here. As the DB was built on a different farm with a different account it will still look for that account during the initialization. One way to move all the service accounts which are on the sql server is below

On SSMS click View->object explorer details.  Now click on security->logins which will display all the logins on object explorer details window. Select all the logins here->right click and script to new query window. You can run this query on Farm B SQL server to duplicate the accounts. Again do not forget to verify any local admin permissions if has on Farm A and replicate it on Farm B.


Cannot Delete SP WebApp

Getting right the first time is the Key for successful SharePoint implementation. Now when I say first time I am talking about production environment implementation. You practice on a sandbox, make all mistakes you can, get the steps right eventually and then implement on production. If not, then sometimes simple things like adding a webapp or deleting a  webapp can cause issues. For instance, orphaned webapp issue which might occur while you are deleting a webapp using

Remove-SPWebApplication -Identity http://webapp -Confirm

Below is the error

Remove-SPWebApplication : An object in the SharePoint administrative framework, “SPWebApplication Name=WebappTest”, could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and
retry this operation. The dependant objects are as follows:
At line:1 char:1
+ Remove-SPWebApplication -Identity https://portalsb -Confirm
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Share…PWebApplication:SPCmdletRemoveSPWebApplication) [Remove-SPWebApplication], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletRemoveSPWebApplication

Error is self explanatory but you would think ,,yes of course there are objects associated with this webapp because they are part of the webapp itself and are created during the creation of webapp or adding stuff to the webapp and Remove-SPWebApplication should identify all the ties to the webapp and delete it. The answer is yes ideally Remove-SPWebApplication should take care it but situation here is that of orphaned objects or orphaned web app. Adding and deleting content DB’s or  removing webapp doesn’t go right first time or for some other reason  you are here  facing this error then below steps might help you.

  1. Identify webAPP ID by  select * from Objects (nolock) where Name like ‘%Webappname%’ . Run this against config DB
  2. Use this WebAppID you got from step #1 and run select * from SiteMap (nolock) where ApplicationId = ‘WebAPPID’ . Run this against config DB
  3. Delete Content Database ID from Configuration database, using following command STSADM -O deleteconfigurationobject -id <DatabaseID from previous query> . You can use powershell to run this.
  4. Now delete the application using Remove-SPWebApplication -Identity http://webapp -Confirm

WARNING: Messing with SharePoint databases is not supported by Microsoft and might negatively effect warranties and stuff . Its a BIG no no from Microsoft support. So do not use this method on production environment but contact Microsoft support


“Cannot generate SSPI context” error message

If you deal with MS SQL Server should have seen this error message. I faced this issue few times under different scenarios. When I fixed this recently I thought I should write it down  so it could help someone.

One classic scenario  you get this error is if you change the SQL server service account and suddenly you cannot connect to the server from a different machine using SSMS. Meaning using TCP over the network. Mind you, service account needs to be a domain account. The issue here is that there is no valid SPN and server is not able to authenticate the user.

The authentication from a different computer is delegated by using one of the following

  • NTLM over Named Pipes (not using Security Support Provider Interface [SSPI])
  • NTLM over TCP/IP sockets with SSPI
  • Kerberos authentication over TCP/IP sockets with SSPI

“Cannot generate SSPI context” error is generated when SSPI uses Kerberos authentication to delegate over TCP/IP and Kerberos authentication cannot complete the necessary operations to successfully delegate the user security token to the destination computer that is running SQL Server” The newly added service account is not able to create SPN’s which is required for kerberos authentication.

You can assign proper permissions to the service account on the active directory directory service so it can generate SPN’s dynamically by following below steps

To grant the appropriate permissions and user rights to the SQL Server startup account, you must be logged on as a domain administrator, or you must ask your domain administrator to do this task.

To configure the SQL Server service to create SPNs dynamically, follow these steps:

  1. Click Start, click Run, type Adsiedit.msc, and then click OK.
  2. In the ADSI Edit snap-in, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN=AccountName, and then click Properties.


    • DomainName is a placeholder for the name of the domain.
    • RootDomainName is a placeholder for the name of the root domain.
    • AccountName is a placeholder for the account that you specify to start the SQL Server service.
    • If you specify the Local System account to start the SQL Server service, AccountName is a placeholder for the account that you use to log on to Microsoft Windows.
    • If you specify a domain user account to start the SQL Server service, AccountName is a placeholder for the domain user account.
  3. In the CN= AccountName Properties dialog box, click the Security tab.
  4. On the Security tab, click Advanced.
  5. In the Advanced Security Settings dialog box, make sure that SELF is listed under Permission entries.

    If SELF is not listed, click Add, and then add SELF.

  6. Under Permission entries, click SELF, and then click Edit.
  7. In the Permission Entry dialog box, click the Properties tab.
  8. On the Properties tab, click This object only in the Apply onto list, and then make sure that the check boxes for the following permissions are selected under Permissions:
    • Read servicePrincipalName
    • Write servicePrincipalName
  9. Click OK three times, and then exit the ADSI Edit snap-in.

 If the above steps does not fix the issue

  1. Verify if the service account under which SQL service was running before has any SPN’s by using setspn -L serviceaccountname.
  2. Delete the SPN using setspn -d MSSQLSvc/server name:port

An SPN for SQL Server is composed of the following elements:

  • ServiceClass: This identifies the general class of service. This is always MSSQLSvc for SQL Server.
  • Host: This is the fully qualified domain name DNS of the computer that is running SQL Server.
  • Port: This is the port number that the service is listening on.

For example, a typical SPN for a computer that is running SQL Server is as follows: MSSQLSvc/

3. Add new SPN for the new service account using setspn -s MSSQLSvc/ serviceaccountname . This is SPN is with fully qualified domain . You also need to add one for netbios name MSSQLSvc/SQLSERVERNAME  ServiceAccountName.

Now you should be able to connect to SQL server from a different machine. Meaning using TCP over the network.


Authentication in SharePoint 2013

Before a user can get to content, authentication and authorization happens. Authentication which happens before authorization is a process where user credentials are verified to get to the SharePoint server. After a user is authenticated then he/she can view the content for which they have permissions and this is Authorization.

There are two kinds of authentication Claims and Classic.

In Classic based Authentication SharePoint  directly uses windows identity for authentication. But in claims a security token is passed on to the required service for authentication. Meaning you can overcome the double hop limitation using claims while using NTLM (discussed below). Also if you want to use Web Apps server, outlook then you have to use claims.

So we have established that claims is the way to go in SP 2013. Now lets discuss more types in claims.

While creating a new web app using claims you can select different types of claims

  1. Windows authentication : You can using NTLM or Kerberos, basic authentication, digest authentication.
  2. Forms based authentication: This type is usually used for out side user login. It is configured using ASP.NET membership provider. Meaning user with out active directory accounts should be able to authenticate.
  3. SAML token based authentication :  Any service which can issue SAML based tokens can be used to authentication.

SharePoint is a ASP.NET application and it uses Windows Identity Foundation and .NET Framework to implement claims infrastructure. This is accomplished using security token service application which  can validate claims and also acts as identity provider. This service is configured by the SharePoint itself and user has no control to create or configure.

If you choose Windows Authentication while creating a web app then you have to select one of the options below

Integrated windows : NTLM or Kerberos

NTLM is most used authentication here as it is secure and easy to configure. User is a uthenticated in a challenge response fashion and the password in never sent over the network but hash of the password generated using one way hashing algorithm is used.

Kerberos: It is the default authentication used my Microsoft for windows login. This process involves generating encrypted ticket and authenticating using these Ticket granting server session keys. Passwords in any form are never sent across the network and the life time of the tickets is 10 hours by default so user no longer need to be authenticated during this time. This type of authentication would help over come the double hop issue. I would like to talk more about how kerberos works as it helps me understand the process better every time I think about it but there are some really well documented articles already available and I can not present the information any better. Please check out Kerberos explained or MIT, where it was created. Out of all available methods kerberos is the most secured form of authentication but it needs extra configuration steps.

Kerberos can be configured as basic or constrained delegation depending on your domain architecture.  Basic will allow web apps to pass on the kerberos tickets to different domains with in the same AD forest but not across multiple forest boundaries.  You can over come this with constrained delegation provided you have Windows server 2012.

Constrained delegation is not mandatory for SharePoint 2013 but it is highly recommended as the access to different service applications can be controlled.  The following service application do need constrained delegation if you use Kerberos.

Excel services, PerformancePoint Services, InfoPath Forms, Visio Services.

Check out configure Kerberos to know the detailed steps involved in the set up process.

Basic Authentication

Old method where credentials are sent in plain text over the network.

Digest Authentication 

Credentials are hashed and sent to the server for validation

Anonymous Authentication

Anonymous users can access the site. This type is usually used for internet facing sites which disseminates information

Federated Authentication 

It is used to configure a web app to authenticate users using third party credentials. For example you can authenticate clients, partners, etc using their organization credentials by using ADFS. Windows live ID or face book account can also be used to authenticate. As we discussed above SharePoint 2103 primary authentication is claims or you can say it is the only recommended authentication method, It supports multiple authentication methods on a single web application. So you reduce the over head of multiple zones or web applications in some cases.

Anonymous access Site

I want to talk a little bit about accessing a SharePoint website anonymously. Just to keep it simple lets say our website just disseminates content. This might seem simple but majority of the websites in the world just does that. One good  example is Ferrari website which is aesthetically pleasing and does the job well.

  1. Create a new web application and enable anonymous access – Central admin->Application management ->New . Select Allow Anonymous “yes”. If you miss to select this now then you can always come back to this location select the web app and then Authentication provider on the ribbon -> click default and select Allow anonymous access.

2. Create root site collection – Application management – Create Site Collection . Do not forget to select  template as publishing site.

3. Launch the site as administrator (you could use the same account with which you created the web app above) . Go to Settings -> Site permissions -> anonymous access->Entire website.

You should be able to launch the website from the internet. Of course do not forget the DNS settings to resolve the website.

SharePoint Accounts

While there are many articles explaining accounts needed to install and maintain SharePoint, this is my two cents.

I think below accounts are must no matter what kind of model you are looking to install. Technically you can always use a single account with admin rights everywhere but  it will end up with some issues later on. For instance, what if that account gets locked up for some reason then your entire farm will go down.

  1. Setup User Account: Account with which you will install SharePoint. Meaning you login to your server with this account and run the set up. It must be a securityadmin and dbcreator on the SQL Server, and it must be a member of the local Administrators group. I call it SPadmin. 
  2. Farm Account : You will use this account during the installation where it asks you for the credential to create content database. It is also the identity used by the Central Administration site’s application pool, and the identity used by the Timer service. It should be dbcreater, dbowner and security admin. I call this SPfarm
  3. Application pool account. Depending on how you want to maintain webapplications and service applications you can create these accounts. Usually they are least privileged accounts.

SharePoint 2013 Installation

  1. Install on a single server with built in DB : This installation is a good platform for learning and testing. It installs SQL Server 2008 R2 with SP1 Express edition. Which means you cannot go beyond 10 GB for database size. You can download SharePoint Foundation which is a free edition and use this model to install it on a personal computer.
  2. Install on a single server with SQL server : Using this model you can install all the components of SharePoint on one machine. Advantage here is that this model is scalable and you can use full version of SQL where is no 10 GB restriction on DB size. Microsoft do recommends not to go beyond 200 GB for one content DB. I will talk about this in a different article.
  3. Multi-tear installation: This model usually consists of web, application and database layers. There could be multiple servers on each layer sharing the requests and load. Web tier consists of WFE servers which directly respond to customer requests. Application layer consists of search and service applications. DB layer consists of SQL server hosting config, content ,etc databases.
  4. Hosted solution from Microsoft : I have not personally used this model. More information about this can be found at SharePoint Online.