Alternate Access Mappings: another URL to your site

Scenario: How to assign a different internet URL to SharePoint 2010 site ?


Alternate access mappings enable a Web application that receives a request for an internal URL, in one of the five authentication zones, to return pages that contain links to the public URL for the zone. You can associate a Web application with a collection of mappings between internal and public URLs. Internal refers to the URL of a Web request as it is received by Office SharePoint Server 2007. Public refers to the URL of an externally accessible Web site. The public URL is the base URL that Office SharePoint Server 2007 uses in the pages that it returns. If the internal URL has been modified by a reverse proxy device, it can differ from the public URL.

Perform the following steps to configure alternate access URL for a SharePoint site

  1. You must have a SP site configured and working fine and having URL looks like http://<site Url>.
  2. Go to Central Admin > Application Management > Alternate Access Mappings.
  3. Click on “Edit Public URLs” and then choose the appropriate Alternate Access Mapping Collection.
  4. Now enter the desired alternate URL under the Internet section. for eg.

To make it work on server please perform the following actions:

Option 1:

  1. Click Start, click Run, type regedit, and then click OK
  2. In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    Right-click Lsa, point to New, and then click DWORD Value. (In Win 2008, its DWORD 32bit)
  3. Type DisableLoopbackCheck, and then press ENTER.
  4. Right-click DisableLoopbackCheck, and then click Modify.
  5. In the Value data box, type 1 and then click OK.
  6. Quit Registry Editor.
  7. Do not forget to restart your server.

Option 2:  Add this registry entry by PowerShell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -value “1” -PropertyType dword

Happy Sharepointing 🙂

SharePoint Feature Upgrade: Update all Sharepoint modules


In my previous post, I have explain basics overview of feature upgrade. But in some specific scenarios, like update xslt, masterpage, css files which are already deployed to libraries, it is required to write a custom code which will iterate through file content and replace it with new one. This post is not a reference for those who can easily perform actions like adding new fields to content type, adding new columns but can be referenced for those who want to replace the existing one and one does not sure about the fact that whether the file is ghostable or not.

All those files which are ghostable in library, i.e. those are deployed in library and not modified using SPD or any other SP tool, can be easily modified by feature upgrade without writing the custom code. But for other files which are present in library but moved to content database, we have to write some code to update those files.

Requirements: CKSDev tool, SharePoint Feature Upgrade Kit

Development Steps:

    1. Open the project to update to visual studio tool.
    2. In project properties change Active Deployment Configuration to Upgrade Solution (CKSDev)

    3. Save the UpgradeHelper_cs
    4. Next step is to add file (as link) UpgradeHelper.cs to the project.In Solution Explorer right click on Project -> Add -> Existing Item ->  Navigate to <Solution Folder>/CommonClasses  -> Select file UpgradeHelper.cs -> Click Add
    5. Change Feature Manifest file to update the version of the feature:                        <?xml version=”1.0″ encoding=”utf-8″ ?><Feature xmlns=”; ImageUrl=”REC.Direct\rec-direct-feature.png” Version=”″><UpgradeActions><VersionRange BeginVersion=”″ EndVersion=”″><CustomUpgradeAction Name=”UpdateAllModules”></CustomUpgradeAction></VersionRange></UpgradeActions></Feature>
    6. Last step is to override FeatureUpgrading method in Feature Receiver class

public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionaryparameters)
var definitions = properties.Definition.GetElementDefinitions(CultureInfo.CurrentCulture);
using (var site = (SPSite)properties.Feature.Parent)
if (upgradeActionName == "UpdateAllModules")
UpdateAllModules(definitions, site);
private static void UpdateAllModules(SPElementDefinitionCollection elementDefinitions, SPSite site)
foreach (SPElementDefinition elementDefinition in elementDefinitions)
if (elementDefinition.ElementType == "Module")
UpgradeHelper.UpdateFilesInModule(elementDefinition, site.RootWeb);

Deployment Steps:

Perform the following steps in order to deploy the upgraded features to the server:

1)      Add solution “COB.SharePoint.Utilities.FeatureUpgradeKit.wsp” to SharePoint by executing given PowerShell command.

Add-SPSolution –LiteralPath <folder path>/COB.SharePoint.Utilities.FeatureUpgradeKit.wsp

2)      Deploy COB.SharePoint.Utilities.FeatureUpgradeKit.wsp package globally by navigating to

“Central Administration> System Settings> Manage farm solutions” then click on the solution name and then click on Deploy Solution.

3)      Update existing deployed solution using PowerShell. In order to upgrade first

  1. Open the management PowerShell (Start> All Programs>Microsoft Sharepoint 2010 Products> SharePoint 2010 Management Shell)
  2. Run the following command:

Update-SPSolution –LiteralPath <folder path>/SPSolution <Solution name>

4)      Feature Upgrade: Once solution was updated on the SharePoint farm next is to upgrade the features which were modified during the development. Perform following steps to upgrade the feature:

  1. Navigate to feature upgrade page: Central Administration -> System Settings -> Manage Feature upgrades
  2. Appropriately select an option in Select Feature scope to query for Web-application/Site/Web (not required for farm solutions)
  3. Select Only Features requiring upgrade
  4. Click Search
  5. Select the appropriate features to upgrade and click Upgrade Feature


Happy Sharepointing 🙂

SharePoint Feature Upgrade:Introduction


Every SharePoint Feature has a version number(by default ““) that is specified in the corresponding Feature.xml file. When a Feature is activated at a specified scope, a Feature instance is created that is associated with that version of the Feature. Feature versioning in SharePoint Foundation allows Features and their associated instances to be easily tracked. Then, when you deploy a new version of a Feature, SharePoint Foundation detects that the associated Feature instance also needs an upgrade because the instance version number is lower than the new version number specified in the current Feature.xml file.

SharePoint Foundation uses new QueryFeatures methods that can be applied to top-level objects, such as SPWebApplication and SPSite, to determine what Feature instances need to be upgraded, based on their version numbers. The upgrade infrastructure queries for the set of Feature instances that need upgrade and then upgrades each of those Feature instances. The order in which the up-gradation happens is as follows:

  1. Server farm level,
  2. Web application level
  3. Site collection
  4. Web sites level(starting from root web level to child level webs)

We can perform the following kinds of modular upgrades to Features in SharePoint Foundation:

  • Define upgrade definitions for new Feature versions.
  • Provision a list instance as part of a Feature upgrade
  • Create separate upgrade action sets, based on the Feature version, that  remove different sets of files.
  • Apply settings to site collections where a particular Feature is activated.

FeatureUpgrading Event:

Feature receivers (SPFeatureReceiver) can now be used to handle FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary(Of String, String)) events. You can implement your own custom Feature receiver to upgrade Feature instances.

FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary(Of String, String)) parameters include properties of the current executing context, the name of the custom upgrade action to execute, and a dictionary of custom upgrade action parameters.

Feature.xml Changes

In order to perform the custom action we must add a feature <UpgradeActions> section in a Feature.xml file. Below is the example of this tag

      <!-- Here you specify other upgrade actions to apply to Feature instances whose versions are within the range to -->
  • <CustomUpgradeAction> — This is used to execute custom code while feature is being upgraded.
  • <VersionRange> — Specifies a version range to which specified upgrade actions apply.
  • <ApplyElementManifests> — Adds a new element to an existing Feature.
  • <AddContentTypeField> — Adds a new field to an existing provisioned content type.
  • <MapFile> — Allows you to map an uncustomized file to a different location on the front-end Web server. You can use the FromPath and ToPath attributes to rename a file in a Feature (for example, <MapFile FromPath=”oldname.gif” ToPath=”newname.gif” />, but you can also use MapFile to move a file. In this case, the FromPath and ToPath attributes specify paths that are relative to the TEMPLATE directory. For example, if a Feature named “MyFeature” has .gif files installed in a “Gifs” directory (such as, %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\MyFeature\Gifs\basketball.gif), and in version 2 you want to rename the directory from “Gifs” to “Images”, then <MapFile FromPath=”Gifs\ball.gif” ToPath=”Images\basketball.gif” /> can be used to move the files.

Things to be remembered:

  1. Increase the version number when you update a Feature.
  2. Keep version numbers of your Feature independent from Microsoft product versions
  3. Increment a major version number to the current major product version the first time you create or change a Feature during a new development cycle
  4. Increment the build version for subsequent changes during a development cycle.
  5. For an initial service pack change, increment the minor version.

Adding new elements to an existing Feature:

  1. Add a Version attribute
  2. Add an <UpgradeActions> section
  3. Create a new Elements.xml file that contains all the new elements
  4. Reference the Elements2.xml file in both the main <ElementManifests> section and the <ApplyElementManifests> section within the <UpgradeActions> section.
    ReceiverAssembly="MyFeatureReceiver, Version=, Culture=neutral, PublicKeyToken=3ef91b1292056a22" 
    <VersionRange EndVersion="">
      <CustomUpgradeAction Name=”ActivateFeature”/>
        <ElementManifest Location="Elements2.xml"/>

Error Handling: When an error occurs during upgrade, the upgrade stops for the specified Feature instance and the error is recorded, both in ULS logs and also in an Upgrade.log file.

There is very good tool you can use to upgrade the feature created by Chris O’Brien. You can download and deploy this tool from codeplex

For more reference: feature upgrade



Integrating ADFS with Sharepoint


I found a very useful and working like for those SharePoint Devs who really want to integrate ADFS with SharePoint. Below is the link of that post:

I have tried implementing all those steps mentioned in that blog and it really worked for me.

Thanks for time:)

Hide Quick Launch, Top bar and Ribbon from SharePoint 2010


I found many ways to hide various out of box controls like quick launch, ribbon, top bar etc on SharePoint page. But not all the solutions feasible in all the scenarios. Most of you experts are aware to implement this using the CSS styles. I am just collating the possible solutions at one place which I hope will be beneficial to make the choice of adopting suitable solution.

1)  Make it Dialog page:

SharePoint will hide these elements when It gets IsDlg Parameter on URL[ ?IsDlg=1 ].

2) Update the Masterpage:

Simple Just add the below css Code in Application Page under PlaceHolderMain section.

<style type=”text/css”>

/*–Hide Quick Launch –*/
display:none !important;
margin-left:0px !important;

/*–Hide Top bar and Ribbon –*/

#s4-ribbonrow, .ms-cui-topBar2, .s4-notdlg, .s4-pr s4-ribbonrowhidetitle, .s4-notdlg noindex, #ms-cui-ribbonTopBars, #s4-titlerow, #s4-pr s4-notdlg s4-titlerowhidetitle {display:none !important;}


3) For Non-Publishing sites: Create content query webpart that now has the name Content Editor and add the following text in the HTML Source mode:

/*--Hide Quick Launch --*/

Note : If you use code to hide toolbars in SharePoint Site Pages with Content Editor Webpart then you can’t check in the page since the toolbar goes hidden.

If you still want to use this code on Site Pages then add Content Editor Webpart and paste the above code. When you want to make other changes then open the page in browser with parameters [ ?Contents=1 ] which opens the page in WebPart maintenance mode. Remove the content editor webpart and re-open the page. Make the changes and add content editor webpart at last along the CSS Code. To check in the page use Site Pages Library.

4) Publishing sites: If you are using a publishing site for your homepage simply add the same styles specified above to a custom page layout. That way if you have a need for other pages that do not need the left side navigation you can re-use the page layout.


Thanks for your Time…:)

SharePoint 2010 directories


I am listing down the various folders structures which are created by SharePoint 2010 installation. First have a look on those folders which are created by installation and configuration:

C:\Inetpub\wwwroot\wss – Hope most of you are aware of this directory which is usded by IIS server as a default location is used as the default location for to host IIS Web sites.

C:\ProgramFiles\Microsoft Office Servers\14.0 –  When SharePoint is installed on any server then all some of the dlls, few SQL commands and some tools like certmgr are copied to this folder. The directory is configurable while doing the installation.

C:\ProgramFiles\Microsoft Office Servers\14.0\WebServices – To host the back end web services this folder is used. Few common hosted web services are: Excel, Search, Word, Lotus notes etc.

C:\ProgramFiles\Microsoft Office Servers\14.0\Data – Data storage while using the services is required by SharePoint so this directory is the root location where local data is stored, including search indexes, office applications data etc.

C:\ProgramFiles\Microsoft Office Servers\14.0\Logs – Run-time diagnostic logs are generated under this directory.

Now have a look on those directories which are placed under 14 hive

C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14 –

This directory is the installation directory for core SharePoint Server files.

C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14\ADMISAPI –

This directory contains the soap services for Central Administration. If this directory is altered, remote site creation and other methods exposed in the service will not function correctly.

C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14\CONFIG – This directory contains files used to extend IIS Web sites with SharePoint Server. If this directory or its contents are altered, Web application provisioning will not function correctly.

New Folder introduced:

C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14\LOGS –
This directory contains setup and run-time tracing logs.

C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\Policy –

Program Files\Common files\Microsoft Shared\Web Server Extensions\UserCode –
This directory contains files used to support your sandboxed solutions.

Program Files\Common files\Microsoft Shared\Web Server Extensions\WebClients –
This directory contains files related to the new Client Object Model.

Program Files\Common files\Microsoft Shared\Web Server Extensions\WebServices –
This directory contains new wcf or .svc related files.

Thanks 🙂