Wednesday 26 February 2014

Site Policies in SharePoint 2013


SharePoint 2013 has a new feature called Site Policies that helps us control the growth of SharePoint sites. In many SharePoint implementations sites are created as required and are not deleted even long after their purpose has been solved. These unwanted sites occupy storage space and cause compliance issues. To automatically close and delete sites after their use SharePoint 2013 provides Site Policies.

Creating Site Policies

Site policies are created at the root site collection and are assigned to sites. Below are the steps for creating a SharePoint 2013 Site Policy

1.      Go to site settings page of root site collection and click Site Policies under Site Collection Administration section

 

2.      From the site policies page click Create to open Site Policies creation page.
 

3.      The following 4 options will be available for site closure and deletion

Do not close or delete the site automatically - If this option is selected, then the site has to be deleted manually.

Delete the site automatically – This option implies that the site having this policy will be deleted automatically based on the specified rule. The rule will have below options

    1. What action  will cause the site to be deleted automatically
    2. Whether an email notification to be sent the site owner a specified amount of time before the site is scheduled to be deleted.
    3. Whether site owners can postpone site deletion.

Close the site automatically and delete the site automatically. This option has  the same choices as delete the site automatically, and additionally  requires to specify the site closure date.
Run a flow to close the site, and delete the site automatically.This option has the same choices as delete the site automatically, and additionally  requires to specify a  to process to be run when site is closed.
Applying Site Policies to Site
After creating site policies they can be applied to sharepoint site in the site collection.
1.      Go to the Site Settings page and click Site Closure and Deletion under Site Administration
 
2.      On the site closure and deletion page select the site Site Policy you want to apply to the site.
 
3.      Selected policy will be applied to the Site.
When the site deletion\closure date approaches a notification message will be displayed on top



 
 
 

Thursday 20 February 2014

Image Renditions in SharePoint 2013


SharePoint 2013 has a new feature called Image Renditions that allows us to optimize images for different devices. Image Rendition allows us to have bigger images stored within SharePoint 2013 site and have different sized variants of the images to be used.

Below are the steps for setting up Image Renditions in SharePoint 2013

1.      From the Site Settings page  click Image Renditions option under Look and Feel section





2.      Default set of 4 Image Renditions with different width and height will be available. You can add a new Image Rendition by specifying a name, width and height.

3.      After definining Image Renditions you can edit the renditions for images by navigating to the Image Library and choosing Edit Rendition option from the menu.



4.      Edit rendition page displays the image in different renditions and also allows to edit specific rendition.



5.      Once you have configured Image Rendition you can use the image in any page in SharePoint site. After inserting the image in to a page you can select Image Rendition you want from the Pick Rendition ribbon



Note:
1.      Image Rendition depends upon blob cache and it has to be enabled for the web application.
2.      Image Rendition is available only for Publishing Portals or when the Publishing Feature is enabled.

 

Monday 17 February 2014

Load Balancer Sticky sessions not required in SharePoint 2013


In SharePoint 2010 the user login token is stored in the memory of each web front-end servers (WFE). If load balancer is configured to route requests to the WFEs and if a user request goes to a different WFE than his earlier request then the user will have to authenticate again. In order to avoid this multiple authentication and delay, sticky session (server affinity) is configured with load balancer.

In SharePoint 2013 the user login tokens are stored in the new Distributed Cache Service and are available to all WFEs, so it is not required to configure sticky session.  This solution is more scalable and reduces memory utilization in WFE.

Friday 14 February 2014

SharePoint BLOB caching and max-age attribute


SharePoint provides BLOB caching feature which when enabled will improve the performance of SharePoint sites by caching frequently used files in physical storage and using it for subsequent requests for the files.

Though the SharePoint BLOB caching feature is handy, care must be taken when using this feature as sometimes the changes made to the cached files will not be reflected in users browsers. This happens primarily because when the SharePoint BLOB caching feature is enabled in web.config without any additional settings it takes the default max-age property of 86400 which is one day. The caveat here is contrary to what most people think max-age property is not the duration is not the expiration period for the files stored in BLOB cache. Max-age is specifies the duration that the client browsers should cache the files. Examining the SharePoint file requests using fiddler tool you would notice the difference in max-age value as shown in the images below

Cache max-age when SharePoint BLOB cache is disabled


 
Cache max-age when SharePoint BLOB cache is enabled
 
If files in your SharePoint site will be changed more frequently than a day then you need to set appropriate value for max-age attribute for BLOB cache as shown below


<BlobCache location="<Cache folder location>" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" max-age=”3600” />
 
Sean has a great article that details the request and response flow when SharePoint BLOB cache is enabled.

Monday 10 February 2014

Disabling SharePoint 2010 mobile redirection


SharePoint 2010 has a mobile redirection feature that automatically redirects users accessing the SharePoint site from a mobile browser to the mobile view. While this redirection is useful for intranet sites it is not desirable for public internet sites with custom branding. There is no setting available in the site settings or central admin site to turn off the mobile redirection. To turn off the mobile redirection we need to modify the web.config to include browsercaps section with isMobileDevice flag to false.  The browser caps section should be added within the system.web element.

<browserCaps>

<result type="System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

<filter>isMobileDevice=false</filter>

</browserCaps>

Tuesday 4 February 2014

Rename SharePoint 2010 Central Admin Content Database


When a SharePoint farm is setup it creates a content database for the central admin site with a default name SharePoint_AdminContent_<GUID>. There would be situations where the database has to be renamed to adhere to company naming policies or for better manageability using automated scripts. The process of renaming SharePoint 2010 content database can be achieved with few lines of PowerShell Script

Create a new content database for SharePoint central admin site

First step is to create a new content database for the SharePoint 2010 central admin site using the New-SPContentDatabase cmdlet

New-SPContentDatabase -Name <DatabaseName>     -WebApplication <URL of SharePoint central admin site>

Get GUID of the content database for SharePoint central admin site

Get-SPContentDatabase PowerShell cmdlet will give the name  and id of the content database.

The syntax is

Get-SPContentDatabase –WebApplication  <URL of Central admin site along with port number>

This will list the old content database and the new content database.Copy the GUIDs of the databases in notepad or similar application.

Move the sites from old content database to new

Get-SPSite cmdlet will give the sites in a content database and Move-SPSite cmdlet will move sites to a particular content database. We can use combination of these cmdlets to move the SharePoint 2010 central admin content database.

Get-SPSite –ContentDatabase {GUID of old content database} |

    Move-SPSite -DestinationDatabase {GUID of new content database}