5 Best SEO Practices for SharePoint sites

Getting your sites ranked in Google would mean tons of traffic, tons of leads. It is only how you convert them. SEO has always been hot getting sites climb up in Google. But what about SharePoint sites? Does it support SEO Features ?


You may have a stunning website, but if that doesn’t rank for competitive keywords your business simply doesn’t exist. Optimizing your website for Search Engines is a skill every company should own.
SEO features supported by HTML, WordPress etc. has a long history. How about ranking SharePoint sites? Does SharePoint offer SEO friendly features? How to rank SharePoint sites? This is a post to answer that.
SharePoint has now a lot of inbuilt features that help with SEO. With the new enhanced SEO-friendly features of SharePoint, optimizing SharePoint sites is now easy. Here is a list of best SEO practices for SharePoint sites.
Specify SEO properties on all publishing pages
Here is how you set it up.
1. Click PAGE tab -> Edit Properties -> Edit SEO Properties
2. Specify a Browser Title (equivalent to the TITLE tag in case of a HTML site)
3. Meta Description
4. Meta Keywords
5. Specify if you would like to exclude the page from search results (something similar to what you do with ROBOTS.TXT)


Make effective use of ‘Canonical’ URLs
If the same webpage is indexed under different URLs (this happens with dynamic pages) that may harm your SEO efforts. Google and other search engines will not feel great about ranking such pages. Every single page should be indexed under one unique URL only. The solution? Canonical URLs.
SharePoint Server 2013 and upwards will automatically generate canonical URLs. Just activate the Search Engine Optimization Site Collection Feature on the SEO Settings page. Once you do that the meta tag rel= ‘canonical’ will be rendered in the HTML of your page automatically as shown below.

Configuring XML Sitemaps
XML sitemaps are by which Search Engines know about your webpages. So, it is better to keep your XML sitemaps updated always. With SharePoint, you no longer have to worry about manually updating your sitemaps. That is indeed a tedious and time consuming process. Thanks to SharePoint Server 2013 and above where automatic XML sitemap creation works like a breeze.
Activate the Search Engine Sitemap Site Collection Feature. The Search Engine sitemap job by default runs once daily and updates XML sitemap with all new pages you have put in your site. You can of course customize the schedule to fit your requirements closely.
Robots.Txt File
If you have a lot of pages, you can specify to exclude few pages that are not required to be ranked. For example, a payment gateway page or your product delivery page should not be indexed or ranked. Specify such pages in Robots.Txt file for exclusion and any search engine would never crawl those pages.
It also helps in optimizing the ‘crawling time’ search engine robots spent with your site. Search Engines don’t have much time to spend on your site either. So, keep it clean with Robots.txt file exclusion settings.

Friendly URLs
If there is control over the URLs to optimize them for search engines will it not look wonderful? SharePoint Server 2013 brings that awesomeness. URLs definitely have a huge influence in getting your pages ranked in search results. SharePoint comes with a Friendly URLs that are really friendly (at least on a SEO perspective)
By using the Managed Navigation method, you can use the SharePoint Managed Metadata Service to model the navigation hierarchy of your website through taxonomy terms. For each term, you can specify a search engines optimized title and URL.


Follow these 5 best practices and you will have a SEO friendly SharePoint site ready to rank and dominate the search engines

SharePoint 2013 site Slowness issue

I was about to give up on one of my labb SharePoint 2013 Environments because it was so extremely slow all the time.
Warmup scripts, reloads, more memory, more CPU, stopping services, stopping search…nothing helped.

I had a constant loadtime of all aspx pages of 6+ seconds, 6.10-6.20 something. Even when the page was just loaded and I pressed F5 to reload, it still took 6.10 seconds.
This was an environment that gave you sensitive nerves…

So, after looking for any solution or more like looking for the little issue that caused this all day, I gave up more or less.
– CPU was at a maximum 40% on SQL, SharePoint cranked it up to 18%…
– Memory consumtion was at 25% of the 12GB SharePoint had…
– SQL was Lightning fast to all other SharePoint farms…
– Network utilization showed about 100Kbps at the most…

I scavenged the internet as usual and found nothing but the standard: add more memeory, add more CPU, stop services, stop search…
None of that helped and I had tried it all…

Then…when all hope was lost, I got on a call with my excellent SharePoint buddy Mattias Gutke, we talked about the issue, his server on a laptop with SSD disks showed 50-100ms loadtime of all pages, reload did nopt even produce a flicker…
Then as often happens, we came to discuss the Distributed cache service, what it did and why it was there and so on…I had already had a look at it but could not find any reason why a default cache would give me this lousy performance. Then, I had a look at the timestamp in the F12 Developer dashbord – Network tab – Start capturing. I saw the home.aspx load and it took the usual 6.10 seconds.
The timestamp could be found in the detailed view and on the response header.
I memorized the timestamp (that was in GMT timezone) and opened up my ULS log. In the log at the exact time of the response header, I saw errors from the distributed cache.

I decided that t-shooting the distributed cache would have to wait, it was getting late…but, before disconnecting the Lync call with Mattias, we decided to try and see just what would happen if I stopped the distributed cache service and loaded the page.
Said and done:

Now, loaded the same site:

Whit the Distributed cache service running:

Notice any difference? Now my SharePoint farm is Lightning fast!!! From 6.10 seconds down to 79 ms!

Why is this so then you ask? No idea, something misconfigured or perhaps this is standard when using a single SharePoint server…anyway, today I don’t care.
Stop the service and the performance is great!

Hope this may help you as it did me!

Resolve SharePoint/ IIS Site Slow Initial Load Issue

There are two ways you can improve the initial load time of a SharePoint/ IIS site:

• Setting application pool's start mode to AlwaysRunning from OnDemand. 
  Open IIS, select application pool of your site, go to Advanced Settings and then set start mode to AlwaysRunning).
  
  
  
  By setting the above option, your site/application loads fast all the time except the very first load after IIS Reset.
  
• Every Application's/ Site's application pool recycling is set at a specific time or regular intervals. To overcome the issue of first load, IIS 8.0 has Application Initialization feature,
  
  

  Version	Notes
  IIS 8.0	Application Initialization was built-in for IIS 8.0.
  IIS 7.5	Application Initialization was released as an out-of-band module for IIS 7.5.
  IIS 7.0	Application Initialization was not supported for IIS 7.0.

  
  
  For further steps to configure this application initialization, please visit Configuration.

If you find the above solution is tedious or not working, you can go ahead with below simple steps.

• Open notepad, add the below code with site(s) you wanted to load automatically

               $client = New-Object System.Net.Webclient
               $client.UseDefaultCredentials = $true
               $webpage = $client.DownloadString($url)

• Save the file with name scriptsload.ps1 under C:\Scripts

• Create a Window Task Scheduler with name to it and schedule it to run on daily morning with below parameters.

• Action:

• Program / Scripts: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

• Add arguements: -ExecutionPolicy Bypass -file "C:\scripts\scriptsload.ps1" \r

SharePoint Tricks and Tips

http://www.sharepointpitstop.com/search/label/Sharepoint%20Tricks%20and%20Tips

Step by Step SharePoint 2013 Installation and Configuration

http://stevegoodyear.wordpress.com/sharepoint-2013-build-guide/
http://stevegoodyear.wordpress.com/sharepoint-2013-build-guide/prerequisites/

by
Steve Goodyear's

Step by Step Kerberos Authentication for SharePoint 2010

Introduction

Kerberos authentication, created at MIT and named after Hades’ three-headed guard dog Cerberus (according to Wikipedia), has been around for decades.  The latest version 5, implemented currently by Active Directory, was released in 1993.  The protocol is designed to provide rapid, secure authentication to users on a multi-system network, or “farm” as we like to call them.

Advantages over Traditional Windows Authentication

The main advantage of Kerberos over NTLM or forms-based authentication is the ability for a user’s identity to securely traverse multiple servers without requiring a re-key of the user’s credentials.  This concept is referred to as single sign-on: login once to access everything.

A secondary advantage is speed.  Authenticating connections with Kerberos tokens is considerably faster than other methods.

Platform Uniformity

Another advantage is platform uniformity.  Any application, that you wrote, or Microsoft wrote, or anyone wrote, which uses Windows Authentication can automatically use Kerberos.  It’s built in to Windows and Active Directory.  It doesn’t require custom code like a forms-based or claims-aware provider.  Enabling it is as simple as telling the web.config to use it.

Necessity

Many farm scenarios do not warrant Kerberos authentication.  How can you tell if yours does?  There is a simple test: the double-hop.  Draw a quick diagram of your farm topology.  If you have any servers which are more than two degrees of separation away from your client, you will need Kerberos authentication only if you need to delegate access to those resources.  The figure below shows the double-hop scenario.

Figure 1: The Double-Hop

Each connection, or “hop,” must be authenticated.  Thus, the SharePoint server must establish a secure, authenticated connection to SQL in order to return data for the user.  If the data connections above need to impersonate the user, the connections must use delegation.  Kerberos authentication allows SharePoint and SQL Server to implement delegation.

Real-World Examples

The most common example of Kerberos in practice involves Reporting Services.  A user browses to a SharePoint document library to run a Report with data in a SQL Server database.  SharePoint and SQL Server both implement Kerberos authentication to allow the user to view the Report using the user’s own credentials.  No login prompts, no proxy accounts, no stored credentials.

Setup

Setting up Kerberos authentication for SharePoint and SQL Server takes only a few minutes.  Follow the steps below to get it running in your farm.  We will assume that SharePoint requires classic mode authentication for the Web Application.  (Obviously, you will need to change CONTOSO to your Domain name and use your actual service accounts.)

1. Configure SQL Server

Configuring SQL Server to use Kerberos is easy.  Create a Service Principal Name for your SQL Server by running the setspn.exe utility from the command-line.  NOTE: you will need to be a Domain Administrator to do this:

Figure 2: setspn.exe Syntax

Service Principal Names

You will need to become familiar with Service Principal Names to setup Kerberos.  They are composed of the following pieces:

Service			Principal
Service Class	Endpoint	Port	Domain	User
MSSQLSvc	DB-SRV-01	1433	CONTOSO	SqlServer
This is the unique class name of the service. It differs between different types of services.	This is the DNS address where the service is accessed. In this case, it’s the server name, but it can also be the fully-qualified domain name like: db-srv-01.contoso.local - or an alias like - database.contoso.local	The port is needed if it is not a standard port for the Service Class.	This is the NetBIOS domain name of the Active Directory where the service account resides.	This is the login name for the service account itself.

As far as I know, the Service Class is case-sensitive.

For good measure, Microsoft recommends creating multiple Service Principal Names.  The reason why: the client application creates the Service Principal Name when it sends it to the server.  If the client application choses to include the port number, or not include the port number, you should be ready.  The solution: create all of the following SPNs for SQL Server:

·         MSSQLSvc/DB-SRV-01 CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01:1433 CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01.contoso.local CONTOSO\SqlServer

·         MSSQLSvc/DB-SRV-01.contoso.local:1433 CONTOSO\SqlServer

Note the variation in the Endpoint and Port.  We do this to ensure that we cover all the possible combinations that a client application could throw at SQL Server.  This is the best practice.

2. Create a Web Application

Create a new Web Application in SharePoint 2010 to use with Kerberos authentication.  Pick Classic Mode Authentication and make sure NTLM is used.  This Web Application will be created as the Default Zone.  We want to put this on a non-standard port and use NTLM authentication to ensure that we can always access it from the SharePoint server itself.

Note: you must use a Domain Account for the application pool identity.

Figure 3: New Web Application

3. Extend the Web Application to use Kerberos Authentication

Extend the Web Application you just created.  Set the Zone to Intranet and put the site on Port 80.  Use the host header intranet.contoso.local:

Figure 4: Web Application Extension

When you click OK you will get a warning about Kerberos.  Don’t worry: the Service Principal Name can be created before or after the Web Application Extension.

6. Create the DNS Record

Your server needs a static IP address and a DNS record to be accessed by users.  When Kerberos is involved, you must be sure that you create an A (for address) record and not a CNAME (canonical name, or alias) record for the SharePoint Web Application Extension:

Figure 5: New DNS Record

Enter the IP address of the SharePoint server and hostname of the Web Application Extension into the box and click Add Host to save the new DNS record.  The automatically generated FQDN should read intranet.contoso.local.

4. Create a Service Principal Name

Just like we did for SQL Server, create a Service Principal Name for the SharePoint Web Application Extension:

Figure 6: SharePoint SPN

The SharePoint Service Principal Name breakdown is as follows:

Service			Principal
Service Class	Endpoint	Port	Domain	User
HTTP	intranet.contoso.local		CONTOSO	SP_WebApp
HTTP works for http and https connections.	This is the DNS address where SharePoint is accessed. In this case, it’s the URL of the Web Application Extension	80 is a standard port, therefore we don’t need to include it.	This is the NetBIOS domain name of the Active Directory where the service account resides.	This is the login name for the SharePoint Application Pool account.

5. Enable Constrained Delegation

If this were SharePoint 2007, we’d be done.  But SharePoint 2010 requires Constrained Delegation.  In order to enable constrained delegation you have to connect to the Domain Controller and enable Delegation on the account used to host the SharePoint Web Application Pool.

Remote Desktop into the Domain Controller, open Active Directory Users and Computers, then locate the SharePoint Web Application Pool account.  Double-click on the account and locate the Delegation tab:

Figure 7: Delegation

Pick Trust this user for delegation to any service and click OK.  SharePoint will now authenticate clients using Kerberos authentication to http://intranet.contoso.local

Workarounds

A common work-around to the Real-World Scenario above, when Kerberos authentication is not involved, is a proxy account: hard-code the Report Server credentials into the Report itself.  When the user accesses the Report, SharePoint connects to SQL using the stored credentials.  This is also what the Secure Store service does.  This is also a form a delegation, but does not pass the user’s actual credentials to the data store: it uses a proxy account.  Thus, all users get the same rights on the data store and the password is saved in clear-text in the Report’s connection string.  If this doesn’t meet your requirements, you need to call in Kerberos to handle the connection.

Looking Ahead

Even though Kerberos is not always needed, or possible like with extranets, the introduction of External Content Types in SharePoint 2010 as a reporting tool will greatly increase the need for it.  The increased maturity and new features in PerformancePoint, PowerPivot, and Reporting Services in SharePoint mode, if your data is not on the SharePoint server itself you will need to use delegation.  The best choice which provides the lowest maintenance overhead, the highest level of security, and the lowest processor overhead, is Kerberos authentication.  Try it out in a VM farm on your local computer.  It’s a great tool to have in your SharePoint architect’s toolbox.

Testing Kerberos

There are tools available for testing Kerberos but it’s quite easy to determine if it is running properly. 
When it’s enabled but not working the following symptoms may be present

1. Login prompts may appear when the previously did not under NTLM Authentication
2. Login Errors appear in the Windows Security Event Log typically stating that Kerberos authentication failed
3. Users are required to login using Office applications when their machines are domain members and the logged in user should have rights.

When Kerberos is first configured for the application pool account a message will appear in the Windows Security Logs stating that a ticket was requested.
Open SharePoint in a browser using the URL where Kerberos is now configured and then refresh the security log.  If Kerberos is running properly messages similar to the one below will appear in the logs on a regular basis. 
For particular users logged in, events will appear similar to the one below

In addition, many messages similar to the one below will appear in the event log.

By: Saravanan.J

Integrating Sharepoint 2010 and SQL Reporting Services 2008 in 6 easy steps

There are only 6 main steps to achieve this task assuming you already have an instance of SQL Server Reporting Services and SharePoint 2010.
I had created this starting from a clean installation of SQL Reporting Services so this guide will discuss the steps on configuring your SQL Reporting Services 2008 for integration with SharePoint 2010.

Step 1: Configuring SQL Reporting Services – Web Service URL

Simply go to Reporting Services Configuration Manager and choose Web Service URL and populate the following needed information. The fields are named properly so I guess there is no need for further explanation. What this does is that it configures the IIS for you depending on what Virtual Directory names you had declared.

Step 2: Configuring SQL Reporting Services – Create a Report Database

Same here, fields need no further explanation except for one which is Native Mode and SharePoint Integrated mode which I will explain below.
Choose create a database or if you already have one choose an existing one. For this example, we will create a new one:

Connect to the database where you want your Report Data to be stored:

Give it a Name and a Report Server Mode.
With SharePoint Integrated Mode the report RDLs are stored on SharePoint and not in the Report Database. For this instance, we will use the SharePoint Integrated Mode:

Specify the credentials that the report server will use to connect to the database.

Review your configuration.

Then wait while it's configured.

Step 3: Configuring SQL Reporting Services – Create a Report Manager URL

What this does is that it configures the IIS for you depending on what Virtual Directory names you had declared.

That’s it. At this point, your report server is configured for SharePoint Integration 2010.

Step 4: SharePoint Integration Configuration – Reporting Services Integration

Simply go to SharePoint 2010 Central Administration, then General Application Settings, then choose Reporting Services Integration.

Now populate the fields using the Web Service URL you had configured a while ago on Step 2 of this guide.

Once done, you will see the Activation State message.

Step 5: SharePoint Integration Configuration – Add a Report Server to the Integration

Now add the report server by putting the Server Name and the Server instance.

At this point it's all done, all you have to do now is try it out.

Step 6: Verify by Checking the Server and Uploading a Report

To verify if it's now integrated, go to Site Settings on your SharePoint Site, then Site Collection Features.


Check if the Report Server Integration Feature is Active, if not just click activate:

Now try to use the SQL Server Reporting Services Webpart:


Or you can also upload a report from a library.

That's it, so simple!