Nik Patel's SharePoint World

Best Practices to Change App Pool Account for SharePoint Web Application

nikspatel — Wed, 25 Jan 2012 04:21:56 +0000

Updating SharePoint Web Application Pool is one of the most common actions for SharePoint administration. I have repeatedly seen many SharePoint administrators and my fellow colleagues updating their SharePoint web application pool in the IIS and later realizing that their SharePoint content application is inaccessible and throws “Cannot connect to the configuration database” error.

The real reason behind this is when you create web application either through PowerShell or central admin, SharePoint configures application pool information at many different locations including machine level permissions, IIS, and database permissions. If you ever want to manually change the application pool, you must be aware of what really happens under the hood and visit all the different locations to change application pool manually. As you may think, manually changing all these machine level settings is tedious, error-prone, and requires better option. Luckily Microsoft has provided better option as manage service accounts page on the central administration site. It is best practice to change content web application pool or even service web application pool from the central administration to ensure SharePoint Content Web application runs smoothly.

You can use following step by step guide to change application pool for the given SharePoint web application. Additionally, it would walk you through what really happens under the hood and where SharePoint makes necessary changes to ensure Application Pool is configured properly.

Pre-requisites

New AppPool account must be Domain User Account (e.g. Niks\SPAppPool)
New AppPool account must register as SharePoint Managed Account

Changing Application Pool from the Central Administration

Visit Manage Service Accounts page on the central administration to change the application pool.

Run the IISReset after updating application pool to ensure all the configuration settings has been updated to access SharePoint Web Application correctly.

What really happens under the hood?

After you change the application pool through central administration, SharePoint automates various configuration settings changes at the machine level, IIS, and SQL Server.

SharePoint Web Application App Pool in IIS

Machine-level Permissions
- New AppPool account added as Member in the WSS_WPG, AD Group
- New AppPool account added as Member in the built-in IIS_IUSRS, AD Group

SQL Server and database permissions
- SharePoint will create new SQL Server Login for AppPool Account in the Database if it doesn’t exists
- New AppPool account is assigned to the db_owner role for the Web application content databases.
- New AppPool account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the farm configuration database.
- New AppPool account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the SharePoint_Admin content database.
- New AppPool account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the StateService database.
- New AppPool account will be assigned to the db_owner role for the associated user profile service application databases (e.g. Profile DB, Social DB, and Sync DB)

There you go. Hopefully this will help. !!!!!

Filed under: Admin General

Custom SharePoint Pages – Site Pages vs Application Pages

nikspatel — Fri, 20 Jan 2012 04:12:59 +0000

Although I have been building custom applications on SharePoint Platform since MOSS 2007 days, when it comes to making decision on whether to use application page or site page features for specific scenario, I typically have to go through basics and try to weight pros and cons of each characteristics especially on coding complexity, runtime performance, future upgrade maintenance, deployment and retraction.

In past, I have time and time again relied on the Ted Pattison’s Chapter 2 and Chapter 3 of “Inside Microsoft Windows SharePoint Services 3.0” for decision making process on application vs. site pages. Typically it required me to go through both chapters and perform additional home work to review every aspect of application vs. site pages functionality. As you may understand, it has been tiring process. Over the time, I end up building my own list of major differences between site pages and application pages to help me making decision faster if it’s needed.

Generally my rule of thumb is to go for custom application pages for administrative tasks like maintenance or system pages and go for custom site pages for end-user business functionalities to promote end-user customizations if needed. Here are major characteristics and differences between site pages and application pages categorized by major areas of architectural decisions.

Characteristics
- An Application page is an ASP.NET content page hosted in the LAYOUTs directory on the WFEs and inherits from Microsoft.SharePoint.WebControls.LayoutsPageBase. Site Pages are stored in the virtual file system in the Content databases. SPFile and SPFolder objects represents Site Pages in WSS object model.
- As Name Suggest, An Application Page is application or farm scoped and A site page is site/web scoped.
- Site Pages consists of two compoents => Site Page Templates vs Site Page Instances
  - Site Page Templates are .aspx pages stored in the file system in the FEATURES directory.
  - Site Page Instances are provisioned through Module and File elements and resides in content database. They are created inside the context of the particular site. WSS treats Un-customized Site Page Instances as a reference pointer to the Site Page Template. You can use SharePoint Designer to customize or view site page instances. Both customized or un-customized site pages exposed through the virtual file system.
Coding
- An application page can have code behind and inline code but site page can’t have code behind or inline code. Using PageParserPaths for site pages is not best practice. Workaround for this problem is to create the site pages with web part pages and add web parts which has codebehind during feature activation.
- An application page doesn’t support web parts or web part zones (they are ghosted pages) but Site Pages supports web parts. It means application pages would support only server controls or user controls and cannot be personalized by end-users.
Customization
- An application page typically requires Visual Studio to customize the page, while Site Page can be easily customized through SharePoint Designer. First time you change the site page template or site page instance through SharePoint designer, it creates a customized copy and stores in the virtual file system. Use “Reset to Site Definition” to reset customized site page to the non-customized site page.
- An application page doesn’t support customization per site by site basis but site page supports different Site Pages per Site
Deploy
- An application page is available to all the sites, while site page can be deployed only specific sites
- An application page is deployed in LAYOUTS directory when solution is deployed to the web application or farm, while site pages are deployed to content database when feature is activated for specific web. Site page templates gets deployed in FEATURES directory same way as application page when solution is deployed.
- An application page must requires a farm solution, while SitePage can be deployed using a sandbox solution. It means, application pages requires farm administrative privileges to deploy the changes while site pages can be deployed by site collection administrators/end-users.
Runtime
- URL – An application page stored in the _layouts directory on each WFEs which would add “_layouts” in URL, while site page URLs can have fully customized business URLs. This can be go-no go decision with application pages in most cases.
- Performance – Because application pages are parsed and compiled as classic ASP.NET pages, they run faster than site pages. SPPageParserFilter parses and compiles the page into DLL. Customized Site Pages impact performance and scalability since they are rendered, runs in no-compile mode, and retrieved from the virtual file system.
Upgrade
- Maintaining or deploying updated Application page is much faster than maintaining Site Page because deployment method requires retracting/re-deploying site page on each site compare to application page on each application. This can be go-no go decision with site pages in thousands of sites deployment.
Cleanup
- Application pages are removed from the file system from the LAYOUTs folder when the solution is retracted but Site Pages requires Feature Receiver to delete the folder containing site pages in the content database during feature deactivation process. Site page templates gets retracted from FEATURES directory same way as application pages when solution is retracted.

Additional References:

Chapter 2 and Chapter 3, Inside Microsoft Windows SharePoint Services 3.0, MS Press, Ted Pattison. This is still one of the best books on SharePoint and applicable to SharePoint 2010.
Sahil Malik’s Apress Book – Microsoft SharePoint 2010 Building Solutions for SharePoint 2010, Jun 2010, Page 95. Sahil has demonstrated design pattern of how to build Site Pages with Web Parts to support code-behind in his book.
Brilliant resource, Most complete I have found so far, App page vs Site pages => http://srisharepointdevelopment.blogspot.com/2011/07/app-page-vs-site-pages.html

Filed under: Dev General

Prescriptive Guidance – InfoPath List Forms Implementation Lifecycle for SharePoint 2010

nikspatel — Fri, 23 Dec 2011 19:41:17 +0000

Have you ever wondered how to use InfoPath List Forms for the SharePoint 2010 and what really happens behind the screen? Have you ever wondered how would you retract customized SharePoint List form and cleanup the form completely from your SharePoint systems? Have you ever wished you had end to end guidance to design, deploy, and maintain InfoPath List forms for the SharePoint 2010? To me, these are the real questions asked by SharePoint/InfoPath developers while designing forms in the real world scenarios. With this article, hopefully you have a reference material which will provide all these answers.

Ever since I have presented “Real Word InfoPath 2010 List vs. Library Forms”, I had promised attendees that I will write detailed blog articles on real world best practices to design, develop, and maintain InfoPath 2010 List and Library forms with SharePoint 2010. Although everyone likes benefits of quick rapid forms design and development using InfoPath 2010 for SharePoint 2010, I have seen more often or not they would get frustrated quickly. In most cases, their frustration is not because of the InfoPath product itself, but because of the developer or development process itself. It is important to remember that InfoPath 2010 development with SharePoint 2010 requires discipline and it must follow specific pattern or guidelines. Based on my experience, one of the biggest things we are lacking in SharePoint 2010 is prescriptive guidance on how to use any feature from end to end in real world scenarios. This article would try to fill the gap between most of the books written on InfoPath 2010 with SharePoint 2010 and real world scenarios.

Although late is better than never, here is the blog article on Prescriptive Guidance for InfoPath List Forms Implementation Lifecycle. Please note that this article discusses InfoPath List Forms, not Library Forms. If you want to read the differences between List and Library Forms and when to use which one, please read this article. Additionally, please note that this is not detailed step by step guide to demonstrate end to end example using lots of screenshots. It will take reader to typical real-world situations during InfoPath forms lifecycle in SharePoint 2010 – Prepare the Environment, Design the InfoPath 2010 Form, Deploy InfoPath 2010 forms to SharePoint 2010, Upgrade/Maintain InfoPath 2010 forms to SharePoint 2010, and Retract/Cleanup InfoPath 2010 forms to SharePoint 2010.

Here is prescriptive guidance on how to create and maintain sample “Project Request Form” by walking through end of end example and what really happens behind the screen.

Step 1 => Prepare the SharePoint and InfoPath Environment

First step of the SharePoint and InfoPath 2010 development is to make sure you have all the tools installed for InfoPath form design and all the SharePoint services configured. Follow this step to ensure your environment is prepared for the SharePoint and InfoPath development.

Prepare SharePoint 2010 Environment

Have SharePoint Server Enterprise CAL Installed. Browser based InfoPath Forms available in SharePoint Enterprise CAL as InfoPath Form Services.
InfoPath Form Services enabled on SharePoint 2010 Enterprise by default. You can Configure InfoPath Form Services Settings on the Central Administration -> General Application Settings -> InfoPath Forms Services -> Configure InfoPath Form Services -> Enable/Disable User Browser Enabled Form Templates

Prepare Development Environment

Install InfoPath 2010 using Office Professional Plus 2010 – InfoPath Designer 2010 and InfoPath Filler 2010

Step 2 => Design the InfoPath List Forms and SharePoint Application

This step will create sample SharePoint List (e.g. Projects) to host InfoPath List Form (e.g. Project Requests Form) and customize the form using InfoPath Form Designer 2010.

Create the Custom List (Projects List) to hold the Project Requests

Add List Columns. In real world, I like to standardize the lists or library metadata with Site Content Type. For this example, create list columns directly on the list.

Basic Info

Fiscal Year – 2011-2015 – Required – Choice

Project Name – Required (Rename Title Column)

Project Description – Single Line of Text

Department – IT, HR, Finance, Legal, Sales, Marketing, Other – Required – Choice

Project Requester – Required – Person & Group

Project Sponsor – Single Line of Text

Project Priority – High, Medium, Low – Choice

Project Type – New Implementation, Modifications, Enhancements, Replacement – Choice

Business Case

Problem Statements – Multiple lines of Text – Rich Text Field

Project Mission (including Project Scope) – Multiple lines of Text – Rich Text Field

Project Benefits – Multiple lines of Text – Rich Text Field

Business Dependencies – Multiple lines of Text – Rich Text Field

IT Dependencies – Multiple lines of Text – Rich Text Field

Configure Advanced List Properties as needed

Enable the Versioning (Version Settings)

If you have created content types for Project Request Item, Enable the Content Type (Advance Settings) and Add Projects Content Type and Delete the Default Item Content Type
Configure Default View – Remove unnecessary column

In the Out of box SharePoint Lists, If you add new item without customizing the forms, item view form would look like this as Standard UI.

Behind the screen – What really happens?
- Three out of box List Form Web Parts available on the List Ribbon UI.
- You can open the site collection in SharePoint Designer and navigate to the All Files -> Lists -> -> folder. Folder should be empty and there won’t be any custom InfoPath templates and forms.

Customize the InfoPath Lists Forms

Use “Customize Form” from the Projects List Ribbon bar and it should open the InfoPath 2010 Designer to customize the Lists Forms.

Projects Request InfoPath Form will be automatically configured in the InfoPath Form Designer

InfoPath Form Fields are linked to the Underlying SharePoint List
InfoPath Form Publishing Location is already configured as Underlying SharePoint List

Design Projects Request Data Entry InfoPath Form

Configure Views (UI and Branding), Rules, and Data Sources.
Configure Forms Options – Toolbar options, default display view

Review Data Connections – Main Data Connection would be configure to retrieve and submit data to the underlying SharePoint List. You can notice from the following screenshot, publishing location is already configured to underlying List URL.

Step 3 => Deploy InfoPath List Forms

Publish the InfoPath Forms to the SharePoint List

Publish the Form using Quick Publish from InfoPath Designer.

Behind the screen – What really happens?

As you soon as you publish the form first time, Newly publish form will be deployed to the Site Collection Content Database along with the List contents.

Three additional Form Web Parts Customization Menu Items will be added to the List Ribbon UI.

You can open the site collection in SharePoint Designer and navigate to the All Files -> Lists -> -> folder. Folder should contain InfoPath template (template.xsn) and three additional default Edit, Add, and Display forms (newifs.aspx, editifs.aspx, and displayifs.aspx). All your forms and form template gets stored in the content database.

Three new Edit, Add, and Display forms contains the newly introduced web part in SharePoint 2010 “InfoPath web part” and configured by adding InfoPath Form Template with default

Display Form Markup – location – list infopath from, content type id, list form mode – Readonly

Edit Form Markup – location – list infopath from, content type id, list form mode – Editable

New Form Markup – location – list infopath from, content type id, list form mode – Editable

Best Practices – Do not customize the InfoPath Form Web Part properties on the Add, Edit, and Display InfoPath forms from the SharePoint Designer. Instead customize web part propreties from the browser UI. Form the List Ribbon, customize the form web parts from the content types section.
With the Customized InfoPath List Form, SharePoint List item view form would look like this.

Step 4 => Upgrade InfoPath List Forms

Modify/Enhance/Upgrade the InfoPath List Form

Any list schema changes requires updating the InfoPath form. Any major schema changes in the SharePoint List would make associated InfoPath Form Invalid. Use “Customize Form” from the Projects List Ribbon bar.

Update/Redesign the List Form and republish it to sync the List changes to the InfoPath Form Schema

Step 5 => Retract InfoPath List Forms

Clean up the InfoPath List Form

From List Settings -> Form Options, you have option to revert back to the out of the box ASP.NET forms and option to permanently delete the associated list form or preserve the InfoPath forms

Hopefully this will be helpful designing your next InfoPath List Form for SharePoint 2010.

Filed under: SP2010 & InfoPath

InfoPath 2010 and SharePoint 2010 – List Forms vs Library Forms

nikspatel — Fri, 23 Dec 2011 18:06:48 +0000

Not many aware of two different kinds of InfoPath forms available in SharePoint 2010 – List Forms and Library Forms. Having understanding of both kind of InfoPath forms is one of the most fundamental knowledge one need to have to be better InfoPath Developer for SharePoint 2010. Since you can’t switch from List forms to library forms or vice-a-versa (Yes, you read it right, you can’t switch or migrate forms from one to another), deciding on List vs Library form becomes one of the most fundamental architectural decisions part of InfoPath-SharePoint solution.

This article highlights high level differences between SharePoint 2010 List and Library forms and guidance on when to use which kind of forms. Microsoft has published wonderful article on this topic and my article is extension of what’s been published on InfoPath blog with some additional notes I have taking over the last two years.

InfoPath Team Blog Reference – http://blogs.msdn.com/b/infopath/archive/2010/04/22/comparing-list-and-form-library-forms.aspx

List Forms – Tied to the List – New in SharePoint 2010

Key Characteristics

InfoPath Form Tied to specific SharePoint list, Not reusable
InfoPath Form Schema tied to SharePoint List Schema
InfoPath Form data stored in the SharePoint List.

Each control (e.g. text box) in the InfoPath Form is bound to a column in the SharePoint List.

Supported on Simple SharePoint Lists like Custom List, Tasks, Announcements, Links, Contacts from Browser Interface

Not supported in Document Libraries and advanced SharePoint Lists like Calendar

You can customize or edit the published form template by clicking the “Customize Form” on the List Ribbon Bar

Requires SharePoint Designer to customize the External Lists Forms

Limitations

Tied to only 1 list and data stored directly in list
No Custom Code Support
No Digital Signatures
Because it’s tied to specific list, No Custom Submit or Publish Behavior
No Repeating and Nested Data
No Print Support – No Print Button
Not available to the Document Library

Use cases

To customize the out of the box List New Form, List Edit Form, and List Display Forms
Ideal for Prototypes or quickly get started building InfoPath forms on SharePoint
Ideal for No-code solutions using SharePoint Designer and Browser Customization for Pre-Packaged Departmental SharePoint Sites designed on production farm.
To use forms offline with SharePoint Workspace

Important Note => Do not use List InfoPath Forms in formal code management and deployment scenarios from development to staging to production.

Library Forms – Tied to the form libraries – Same as SharePoint 2007

Key Characteristics

Form data stored as the XML document in SharePoint Form Library
More complex and requires more disciplined/structured approach
Can be deployed as Sandbox or Farm Level Solutions
Unlike list forms, Form library forms can be deployed as a template to associate the forms to multiple form libraries across multiple sites or site collections or multiple web applications within farm

Publishing Mechanism

Single Library

Deploy/Publish to specific form library

Not reusable in another library
Only one form template per form library, Same benefits as list InfoPath forms. If Form is directly published to form library, another form can’t be published or used in the form library.

Reusability across Site Collection – Multiple libraries or sites within Site Collection

Deploy/Publish as a Form Content Type and Later use Content Type in the Form Library
Enables deployment to multiple document libraries
Supports multiple content type per library. It means, multiple types of Form Templates can be tied to the Form Library using multiple Form Content Types

Reusability across Farm – Multiple Site Collections or Web Applications

Deploy/Publish as a Administrator Approved Form Templates
Once deployed and activated on the site collection, Administrator-Approved Form Templates behaves same as Content Type Form
Deploy as features and solutions framework, PowerShell, or manual upload

Use cases

Form Templates with Code
Form Templates with Tabular Structure (Nested or Repeated Data) or Complex Schema
Form Templates with Printing Support from Ribbon Bar
Form Templates with Custom Submit Behavior
From Templates needs to be digitally signed
Great fit for Enterprise Level Form Solutions with Advanced and Reusable Functionality
Admin Approved forms eases future enhancements, upgrade, maintenance, and deployment
Fits perfectly in formal deployment process of moving features from development to staging to production.
Form is not hosted in SharePoint or you need to store results as an XML document

Filed under: SP2010 & InfoPath

Step by Step Guide to Configure SharePoint 2010 Forms Based Authentication with SQL

nikspatel — Thu, 22 Dec 2011 23:29:03 +0000

It is very common to use SQL Server database to store external users and roles in extranet environments for physical separation of the internal and external users. Typically external identity systems require specific schema changes and AD administrators don’t allow applications to store their users in the main organization domain directory for security concerns.

I have recently wrote an article on step by step guide to configure SharePoint 2010 FBA with ADLDS. This article follows same pattern to configure SharePoint FBA with SQL Server. As you may notice, most of the steps are same and web configuration file changes are similar. This article describes 5-Steps guide to configure SQL Users and Roles in Single-Server SharePoint 2010 environment on Windows 2008 R2 server for Forms Based Authentication.

Note: If you are looking for detailed step by step guide with lots of screenshots, you can download 35-pages step by step PDF guide demonstrating same steps discussed in this article.

Step 1 – Create SQL Server Database to host FBA Accounts

Run C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe to create the SQL DB – aspnetdb
Verify that Niks\Administrator is running Application Pools for the Content and Central Admin Web Application and it’s added as dbowner role on the aspnetdb database.

Step 2 – Add SQL Users and Roles for FBA

Download the MembershipSeeder to load users for form-based authentication – http://cks.codeplex.com/releases/view/7450
How to use MembershipSeeder tool?

Open the \Bin\Release\MembershipSeeder.exe and Update the SQL Server Name by clicking “Configure” button and close the tool
Reopen the tool and use following guidelines to add users.

Add 1 user at a time from membership section using “create” button
Add 1 role at a time from roles section using “create” button
Add 1 user to the role at a time from roles section using “Add to Role” button

Add SQL Roles and Users as following

Roles – sqlowners, sqlcontributors, sqlreaders
Users – sqlowner, sqlcontributor, sqlreader and add them to specific groups

Step 3 – Create New Web Application with Forms Based Authentication

Add DNS entries for the host headers – sqlportal.niks.local
Create New Web Application with Claims Based Authentication

Specify Port-80 and Host Header – sqlportal.niks.local
Select Windows Authentication and Forms Based Authentication

Specify Membership Provider – SqlMember and Role Provider – SqlRole

Specify proper content database name and leave everything else as it is
Create New Site Collection and specify Niks\Administrator as Site Collection Admin
Verify the Windows Authentication by logging to http:\\sqlportal.niks.local as Using Niks\Administrator

Step 4 – Update the Web Config Files for FBA – Content Web App, Central Admin Web App, and STS

Update the Web Config Files for FBA, Please make sure to have a copy of all the original web.config files before making changes.

Follow Mirjam’s blog, it works – http://www.sharepointchick.com/archive/2010/05/07/configuring-claims-and-forms-based-authentication-for-use-with-a.aspx

Content Web App Configuration

Update sqlportal.niks.local web application web.config – C:\inetpub\wwwroot\wss\VirtualDirectories\sqlportal.niks.local80\web.config
Find the entry and add following XML directly below i

Replace the entry with following XML

Locate the entry and Replace everything from to with the following XML

Locate the entry and Replace everything from to with the following XML

Central Admin Web Application
- Update Central Admin Web Application web.config file (to find central admin web.config – go to the IIS, select central admin, and click Explore to find contents)
- Find the entry and add following XML directly below it
```
     
     
  
```

Replace the entry with following XML

Find the entry and add the following XML directly below it. By default, there should be 1 blank Membership or RoleManager entry. Double check whether the and entries only exist ones. Delete any double entries.

Modify STS web.config file
- From the IIS, select the SecurityTokenServiceApplication under SharePoint Web Services and click Explore – it should take you to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken
- Find the entry and add the following XML directly below it

Step 5 – Configure the SharePoint Authorization and Verify the Access for the both AD (Windows) and SQL(Forms Based) Users

Verify AD Groups and Users are available to test
- Sample Global Security Groups – adowners,adcontributors,adreaders
- Sample Users – adowner,adcontributor,adreader
- Add AD Groups and SQL Roles as SharePoint Security Groups – Readers, Contributors, and Owners
Verify that central admin and content web application people picker finds both AD groups/users and SQL roles/users – Please note that SQL Roles can be searched with the full role name while SQL user names can be searched via wildcard

Add AD users and SQL users into SharePoint Security Groups via AD Groups/SQL Roles and verify proper access – read-only, contribute, full control

Following screenshot demonstrate that I was able to successfully login as SQL User – SQLOwner

More Resources

Forms Based Authentication in SharePoint 2010 using Sql Membership Providers – http://sharepoint-2010-world.blogspot.com/2011/03/forms-based-authentication-in.html
Andy’s Blog
- UAG – How to Authenticate users against SQL Server – http://microsoft-iag.blogspot.com/2010/10/uag-how-to-authenticate-users-against.html
- UAG–Enable SSO by passing user credentials to formula based Web Applications – http://microsoft-iag.blogspot.com/2010/10/uagenable-sso-by-passing-user.html
Great Article – It Woks – Mirjam van Olst
- Configuring claims and forms based authentication for use with a SQL provider in SharePoint 2010 – http://www.sharepointchick.com/archive/2010/05/07/configuring-claims-and-forms-based-authentication-for-use-with-a.aspx
Jeremy Jameson – CBA and SQL Server
- http://blogs.msdn.com/b/jjameson/archive/2011/02/19/configuring-claims-based-authentication-in-sharepoint-server-2010.aspx
- http://blogs.msdn.com/b/jjameson/archive/2011/02/25/claims-login-web-part-for-sharepoint-server-2010.aspx

Filed under: Admin General

Code Snippet – Programmatically Access Root Site Collection in Multi-Site Collection Heirarchy

nikspatel — Wed, 21 Dec 2011 22:27:34 +0000

It’s fairly common need in multi-site collection environment to access root site collection programmatically from the current sub site collection or sub site. It’s kind of ironic that one of my colleagues asked me same question while working on our multi-site collection environment this week.

To access the root site collection from the sub site or sub site collections in given web application, you have to somehow access the SPWebApplication object. It’s easy to access SPWebApplication object using SPSite object’s WebApplication property. Once you have access to the SPWebApplication object, you can access first site collection from SPWebApplication.Sites collection to get the handle of the root site collection.

From the sub site, use the following line of code to access root site collection and its URL.

string rootSiteCollectionURL = SPContext.Current.Web.Site.WebApplication.Sites[0].Url;

Filed under: Code Snippets

Step by Step Guide to Configure SharePoint 2010 Forms Based Authentication with ADLDS

nikspatel — Mon, 12 Dec 2011 03:35:44 +0000

It is very common to use Active Directory Lightweight Directory Services – ADLDS in Windows 2008 environments (ADAM in Windows 2003 environments) to store external users in extranet environments for physical separation of the internal and external users. Typically external identity systems require specific schema changes and AD administrators don’t allow applications to store their users in the main organization domain directory for security concerns.

Recently I was able to successfully configure SharePoint 2010 Claims based authentication for the ADLDS using Forms based authentication. This article describes 5-Steps guide to configure ADLDS in Single-Server SharePoint 2010 environment on Windows 2008 R2 server for Forms Based Authentication in non-SSL environment. You can easily adopt this guide to use in SSL environment.

Note: If you are looking for detailed step by step guide with lots of screenshots, you can download 55-pages step by step PDF guide demonstrating same steps discussed in this article.

Step 1 – Configure ADLDS Environment

Install ADLDS Server Role (http://technet.microsoft.com/en-us/library/cc754486(WS.10).aspx)
Create ADLDS Instance (e.g. SP2010VM.niks.local:52983) and Partition (e.g. O=NIKSADLDS,C=LOCAL) (http://technet.microsoft.com/en-us/library/cc725619(WS.10).aspx)
Connect to ADLDS Instance from ADSI EDIT Tool (http://technet.microsoft.com/en-us/library/cc732675(WS.10).aspx)
Create Container – CN for Groups and Users (http://technet.microsoft.com/en-us/library/cc730701(WS.10).aspx)

Create CN (e.g. WPSCN)
Create Users (e.g. WPSCNAdminUser, WPSCNMemberUser, WPSCNReaderUser)

Reset Passwords of all Users
Enable Users

Set ms-DS-UserAccountDisabled = FALSE
Set ms-DS-UserDontExpirePassword = FALSE
Set ms-DS-UserPasswordNotRequired = FALSE

Make Sure User’s cn, distinguishedName, and userPrincipalName is filled out
Make Sure userPrincipalName has no spaces.

Create Groups (e.g. WPSCN Admin Users, WPSCN Member Users, WPSCN Reader Users)

Make Sure Group’s cn, distinguishedName is filled out

Add Users to the Groups – Use Group’s Member Property

Step 2 – Create New Web Application with Forms Based Authentication

Add DNS entries for the host headers (e.g. adldsportal.niks.local)
Create New Web Application with Claims Based Authentication

Specify Port-80 and Host Header (e.g. adldsportal.niks.local)
Select Windows Authentication and Forms Based Authentication

Specify Membership Provider – LdapMember and Role Provider – LdapRole

Specify proper content database name and leave everything else as it is
Create New Site Collection and specify Niks\Administrator as Site Collection Admin
Verify the Windows Authentication by logging to http:\\adldsportal.niks.local as Using Niks\Administrator

Step 3 – Grant “Application Pool” accounts READ Permission on ADLDS instance

Add Content SharePoint Web Application “Application Pool”, Central Administration Web Application “Application Pool”, and Security Token Service “Application Pool” accounts READERS Roles on ADLDS instance. This would allow SharePoint to browse ADLDS store in least privileged scenario.
In My Sandbox, both ADLDS Administrators and SharePoint Application Pool accounts are same so, there is no need for explicit setting of permissions but in real world least privileged environment, these application pool accounts will be different and must be granted permission on the ADLDS. Failure of granting permissions for STS application Pool account may cause login failure issues. Failure of granting permissions for Web Application Pool accounts may cause people picker failure.

Step 4 – Update the Web Config Files for FBA – Content Web App, Central Admin Web App, and STS

Follow Mirjam’s blog, it works – http://sharepointchick.com/archive/2010/05/06/configuring-claims-and-forms-based-authentication-for-use-with-an.aspx
Before you make any changes, Please make sure to have a copy of all the original web.config files before making changes.
Please note that these web.config entries would work for ADLDS Containers, ADLDS Group Objects, and ADLDS Users Objects. If you are using either OUs, Persons, or other ADLDS objects, please modify the LDAP membership and roles providers entries as needed.
Content Web App Configuration

Update adldsportal.niks.local web application web.config – C:\inetpub\wwwroot\wss\VirtualDirectories\adldsportal.niks.local80\web.config
Replace the entry with following XML

Locate the entry and Replace everything from to with the following XML

Locate the entry and Replace everything from to with the following XML

Central Admin Web Application

Update Central Admin Web Application web.config file (to find central admin web.config – go to the IIS, select central admin, and click Explore to find contents)
Replace the entry with following XML

Find the entry and add the following XML directly below it. By default, there should be 1 blank Membership or RoleManager entry. Double check whether the and entries only exist ones. Delete any double entries.

Modify STS web.config file

From the IIS, select the SecurityTokenServiceApplication under SharePoint Web Services and click Explore – it should take you to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken
Find the entry and add the following XML directly below it

Step 5 – Configure the SharePoint Authorization and Verify the Access for the both AD (Windows) and ADLDS (Forms Based) Users

Verify ADLDS Users and Groups are available to test

Sample Roles – adldsowners, adldscontributors,adldsreaders

Sample Users – adldsowner,adldscontributor,adldsreader and add them to specific groups

Verify AD Groups and Users are available to test

Sample Global Security Groups – adowners,adcontributors,adreaders

Sample Users – adowner,adcontributor,adreader

Verify that central admin people picker finds for both AD groups/users and ADLDS roles/users – Please note that ADLDS roles can be searched with the full role name while ADLDS user names can be searched via wildcard
Configure AD Groups/Users and ADLDS Roles/Users Membership to the SharePoint Security Groups – Readers, Contributors, and Owners
Verify that AD users and ADLDS users added in SharePoint Security Groups via AD Groups/ADLDS Roles have proper access – read-only, contribute, full control

Following screenshot demonstrate that I was able to successfully login as ADLDS User – WPSCNAdminUser

More Resources

SharePoint 2010 and ASP.NET Form Authentication with ADAM

ADAM-Forms Based Authentication in SharePoint 2010 – http://sharepoint-2010-world.blogspot.com/2011/03/adam-forms-based-authentication-in.html

SharePoint 2010 and ASP.NET Form Based Authentication with ADLDS

Installing the Active Directory Lightweight Directory Services [AD-LDS] – http://sharepoint-2010-world.blogspot.com/2011/03/installing-active-directory-lightweight.html

AD LDS Getting Started Step-by-Step Guide – http://technet.microsoft.com/en-us/library/cc770639(WS.10).aspx

ADLDS Forms Based Authentication in SharePoint 2010

http://sharepoint-2010-world.blogspot.com/2011/03/adlds-forms-based-authentication-in.html

ADLDS Forms Based Authentication in SharePoint 2007

http://sharepointgeorge.com/2009/ad-lds-sharepoint-and-forms-based-authentication/

http://www.gk.id.au/2009/05/ad-lds-sharepoint-and-forms-based.html

http://leedale.wordpress.com/2008/09/11/moss-2007-forms-based-authentication-using-ad-lds-and-windows-server-2008/

Filed under: Admin General

What really happens during SharePoint 2010 Solution Deployment/Retraction and Feature Activation/Deactivation Process?

nikspatel — Mon, 05 Dec 2011 04:59:37 +0000

Have you ever wondered what really happens when you deploy/retract SharePoint WSPs and Activate/Deactivate site collection or sub site level features at the farm level? As you execute different PowerShell commands or activate/deactivate features from browser interface, SharePoint 2010 makes several changes at the different places on the servers and databases.

This article provides high level overview of what really happens when you execute different farm level PowerShell commands. Hopefully it will be helpful.

	Central Admin	Site/Web Level Features	GAC	Web.Config	14-Root Features	SharePoint Config DB, Objects Table – Solutions	SharePoint Config DB, Objects Table – Features	Web App Content DB, Features Table
Add-SPSolution	Solution Added but Not Deployed	N/A	N/A	N/A	N/A	Yes – Solution Definition Added	N/A	N/A
Install-SPSolution	Deployed to Web App	Installed Feature	Yes – DLLs Added	Yes – Safe Control Entries Added	Yes – Features Added	Yes – Solution Definition Still Exists	Yes – Feature Definition Added	N/A
Enable-SPFeature	Solution Still Deployed	Activated feature to Site/Web	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	Yes – Feature Definition Still Exists	YES – Feature Activation Link Added
Disable-SPFeature	Solution Still Deployed	Deactivated feature from Site/Web	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	Yes – Feature Definition Still Exists	NO – Feature Activation Link Deleted
UnInstall-SPFeature	Solution Still Deployed	Uninstalled feature	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	No – Feature Definition Deleted	N/A
UnInstall-SPSolution	Retracted from Web App	Uninstalled feature	No – DLLs Deleted	No – Safe Control Entries Deleted	No – Features Deleted	Yes – Solution Definition Still Exists	No – Feature Definition Deleted	N/A
Remove-SPSolution	Solution Deleted	N/A	N/A	N/A	N/A	Yes – Solution Definition Deleted	N/A	N/A

Filed under: Dev General, Dev PowerShell

Code Snippet – Programmatically Create Web Application Managed Paths in SharePoint 2010

nikspatel — Mon, 05 Dec 2011 00:17:13 +0000

While creating site collections, it is fairly common to create site collections at the more user friendly URLs. By default, each web application has two managed paths – Explicitly named single site collection managed path “(root)” which would allow only 1 site collection at the root path, http:/// and Wildcard managed path “sites” to host multiple site collections which would allow users to create multiple site collections at the http:///sites/ path.

To automate hundreds or thousands of site collections creation process for a given web application, you can create either explicit or wildcard managed path programmatically. Following code snippets shows two different ways to create managed paths. Both ways shows different ways to access the SPWebApplication application object – using URI or SPSite to create managed path.


using System;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace CodeSnippets
{
    class Program
    {
        static void Main(string[] args)
        {
            //Retrieve the Input Arguments
            string url = string.Empty;
             if (args.Length > 0)
            {
                Console.WriteLine("Input Web App URL: " + args[0].ToString());
                url = args[0].ToString();
            }
            else
            {
                url = "http://sp2010vm:1000";
            }

            //Create Managed Path
            CreateManagedPathUsingWebAppURI(url, "teamsUri", true);
            CreateManagedPathUsingWebAppURI(url, "salesUri", false);
            CreateManagedPathUsingSPSite(url, "teamsSpSite", true);
            CreateManagedPathUsingSPSite(url, "salesSpSite", false);
        }

        ////Method 1 - Create Web App object using URI
        private static void CreateManagedPathUsingWebAppURI(string webAppURL, string NewSiteCollectionName, bool isWildCardInclusion)
        {
            SPWebApplication spWebApp = SPWebApplication.Lookup(new Uri(webAppURL));
            SPPrefixCollection prefixColl = spWebApp.Prefixes;
            if (prefixColl.Contains(NewSiteCollectionName) == false)
            {
                if (isWildCardInclusion)
                {
                    SPPrefix prefix = spWebApp.Prefixes.Add(NewSiteCollectionName, SPPrefixType.WildcardInclusion);
                }
                else
                {
                    SPPrefix prefix = spWebApp.Prefixes.Add(NewSiteCollectionName, SPPrefixType.ExplicitInclusion);
                }
            }
        }

        //Method 2 - Reference Web App Object from SPSite
        private static void CreateManagedPathUsingSPSite(string webAppURL, string NewSiteCollectionName, bool isWildCardInclusion)
        {
            using (SPSite spSite = new SPSite(webAppURL))
            {
                SPWebApplication spWebApp = spSite.WebApplication;
                SPPrefixCollection prefixColl = spWebApp.Prefixes;
                if (prefixColl.Contains(NewSiteCollectionName) == false)
                {
                    if (isWildCardInclusion)
                    {
                        SPPrefix prefix = spWebApp.Prefixes.Add(NewSiteCollectionName, SPPrefixType.WildcardInclusion);
                    }
                    else
                    {
                        SPPrefix prefix = spWebApp.Prefixes.Add(NewSiteCollectionName, SPPrefixType.ExplicitInclusion);
                    }
                    spWebApp.Update(true);
                }
            }
        }
    }
}

Filed under: Code Snippets

SharePoint 2010 Recycle Bin Capabilities – Do you know how it really works?

nikspatel — Sun, 04 Dec 2011 18:08:36 +0000

Do you really know how 2-stage SharePoint Recycle bin works? If your answer is yes, please beware and ensure you are aware of what’s in this article. Recently one of my clients asked me question regarding how 2-stage SharePoint Recycle bin works and its impact on the database sizing. It was interesting because recycle bin and its impact on database sizing is one of the most overlooked topic in the SharePoint world. Not many people know that by default, SharePoint 2nd stage recycle bin would increase site collection storage quota to 50% of originally specified during site collection creation process. For the small site collection, it may not matter but for the larger site collections, this would make huge impact on overall architectural decisions.

I had been taking notes on how 2-stage SharePoint recycle bin works since MOSS 2007 days but never blogged about it because of its trivial nature. Knowing how 2-stage recycle bin really works is one of the most important weapons in SharePoint architect armory. Thanks to Todd Klindt and Shane Young’s SharePoint 2010 Administration book, I was able to refine my notes and here are hopefully all the information you need to know how 2-stage SharePoint recycle bin really works and how it can help you to make intelligent decisions around this most overlooked functionality.

First-Stage/Site Level/End-User Recycle Bin

Accessible from the “Recycle Bin” link on the Quick Launch bar at the top level or sub site level
Available to the users with Contribute, Design, or Full Control Permissions
When user deletes the item in the list/library, items are moved to the first level recycle bin. It stays there until it remains purged by either the user or automatically deleted after number of days based on central admin recycle bin retention settings.
Users can restore the item from the recycle bin or permanently delete the item from the recycle bin
If second-stage recycle bin is not enabled, items deleted or automatically purged from this recycle bin will be permanently deleted from the content database.
Items located in this stage counts towards the Site Collection Quota.

Second-Stage/Site Collection Level Recycle Bin

Accessible from the Site Collection Administration section from the Site Settings page
Available to the users with Site Collection Administrators Role
When end-user deletes the items from their site recycle bin, it will be moved to the Site Collection recycle bin. It stays there until site collection administrators flush them or automatically deleted after number of days defined in central admin recycle bin retention settings or until the second stage recycle bin has reached its allocated size limit defined in the central admin second stage quota settings, in which case the oldest items are permanently deleted.
Items located in this stage doesn’t count towards the Site Collection Quota. Second-Stage Recycle Bin quota separately defined in the Central Administration per application basis.
Site Collection Administrator can manage both recycle bin

Rollup View of All First-Level/End-User Recycle Bin – Site Collection Admin can restore one or many items, delete one or many items or empty end-user recycle bin. This is rollup view of all the site level recycle bin at the Site Collection level.

Site Collection Second-Stage Recycle Bin – All the items deleted from site level/first-level recycle bin gets moved to the second-stage recycle bin. Site Collection Admin can restore one or many items or permanently delete the items from the 2nd stage recycle bin and content database. Items deleted from this recycle bin is not recoverable.

Recycle bin settings are managed at the Web Application Level.

By default, Recycle bin is ON.
You can enable/disable recycle bin at the web application from the Central Admin -> Application Management -> Manage Web Applications -> Select Web Application -> Select General Settings from the Ribbon

Disabling Recycle in at the web application level will still show the “Recycle Bin” link on all the pages but it wouldn’t hold any information to restore at the site or site collection level.

Please note. This is very Important Info => Disabling Recycle bin even for a minute will immediately flush all the data from both recycle bins and those contents are unrecoverable.

Configure the recycle bin retention period – define when items in the recycle bin will automatically purged – by default is after 30 days.

You can configure to never purge from the recycle bin.

Note that this retention period reflects the total time after the item was initially deleted. In other words, total time spent by the item in both recycle bins.
Example: With the default value of 30 days, if item never deleted by the user in the first recycle bin, it will be automatically deleted permanently from the first and second recycle bin after 30 days. If item is deleted from the first recycle bin after 10 days, item will be permanently deleted from the second stage recycle bin after 20 days.

Configure the second-stage recycle bin – You can define the second stage recycle bin storage quota. by default, it’s a 50% of site quota. Maximum is 100% of site quota.

You can completely turn off the second-stage recycle bin which will disable the second-stage recycle bin.

Keep in mind that first stage of the recycle bin counts towards your site collection quota but Second stage of recycle bin has its own quota defined by these settings.

Example: If you define 100 GB site quota per site collection in the web application and allocate 50% quota for the second stage recycle bin, SharePoint will allocate 50 GB storage quota to the second-stage recycle bin making it 150 GB storage quota per site collection on the web application in the content database. This may have large implication of content database sizing and SQL Server storage requirements.
Here is most important and potentially scary nature of 2nd stage recycle bin => If site quota is not configured at the site collection level then recycle bin quota is unlimited.

Filed under: Architecture