There are not a lot of differences with configuring FBA for SharePoint 2010 compared to 2007, but there are a few.  For instance, SharePoint 2010 no longer supports “classic FBA”, rather forms based authentication is provided through Claims Authentication.  There is also the introduction of the Secure Store Service which is the next-gen of the Single Sign On service of old.

Both of these come into play when configuring Forms Based Authentication.

1 . Configure SQL for membership store

The membership store is still created using the ASP.NET SQL Server Setup Wizard.  This is launched from the .NET 2.0 Framework folder on the server at:


This wizard will take you thorough the steps and will build out the SQL database for you.

2. Configure Central Admin Web Site to use SQL Membership Provider

SharePoint web sites out of the box are configured to use Active Directory.  So you may be wondering why we’re configuring Central Admin to use FBA when we don’t really want to login in as an FBA user.  Well, we actually don’t want to configure it to to login as a forms user, but we do need to be able to add users from out membership database when configuring site collection admins, and the like.

So all we want to do is tell the Central Admin web application to use our SQL membership provider as well as AD, so when you use the people picker to select users, it will provide results from our membership database.

Open IIS Manager and locate central administration site

Open the Connection Strings Page.  Under Actions menu on the right, select Add… to create a new connection string.  Provide the details for the membership database for the new connection string.

Add Role Provider

Go back to the Web Application page and open up Providers page.  Here we will create a provider for Roles and Users.  Set feature to .NET Roles and click Add… in the Actions pane to add a new role provider.  I called it FBARoleProvider and selected the right type and connection string.

Add Membership Provider

Now set feature to .NET Users and click Add… from the actions pane to add a membership provider.

Select the correct type and connection string, and whatever behaviors you choose.

That’s it for the providers for Central Admin.

To verify that all looks ok, we can check the web.config of the web application.  To get to the right web.config, right-click on the web application under sites, and select Explore.

3 . Configure Secure Store Web Service to use SQL Membership Provider

Everything we did for Central Admin site, we are going to do for theSecurityTokenServiceAppliaation which is in the SharePoint Web Services application.

4. Create Extranet Web Application

Ok, finally we are ready to create our web application (called SharePoint – FBA) that will use FBA authentication.

In Central Admin, Select the Application Management page, and select Manage web applications.  Select New from the ribbon to create a new web application.

Select Claims Based Mode Authentication as Authentication Type. Allow anonymous access and select values for all the other options until you get to the “Enable Forms Based Authentication“.

Add the values we created earlier in the section “Enable Forms Based Authentication” for role and membership provider.

You can specify your custom login page, I will do in later posts.

Click ok and application will be created.

So now our application has been created but we need to configure the same roles and membership providers for this application too, previously we did for only central administration.

So our new web application is here in IIS manager, I will configure it with roles and members

Add a new connection string

Open the .NET Roles page for our web application.  You will receive a warning that the default role provider is not trusted.  There is a pre-configured SharePoint related role and membership is available, so we don’t need to create our own.

Now create some new roles and user for our web application

When u try to open new roles you will see following error message, simple ignore it

We do not have any roles in our database at this point, so let’s create two (StandardUser, SuperUser) by clicking Add… in the actions pane.

Now we need to do the same for .NET Users.  Open the .NET Users page.  You will get a similar warning saying the default is not trusted.  Assuming you don’t let’s add some.  Click Add… from the Actions pane to add users, and assign them roles.

Now create and open the site collection

After creating a new site collection when u open it you will see the following screen

As we have created a user in sql server database and that user is site collection administrator, so use for based authentication.

So you have been logged in with sql server user. That’s it.



today i am going to setup Form based authentication, i have already completed that but now i will do this in IIS 7.5, so i will be skipping some steps. if you want to have a look at that, please

first of all create new database using aspnet_regiis tool

i am naming it “FBA”

open IIS and open the settings if Central Administration Web Application.

first of all set the connection string

now move to “Providers”  select “.Net Users” from the feature drop-down, name it “FBAUserProvider” and select your preferred settings.

once done then select  “.Net Roles” from the feature drop-down and configure the role provider,  i am naming it “FBARoleProvider”

that’ s it for the central admin application now move to new web application that u have created for Forms Based Authentication if u have not created yet then create it now.

create new connection string, user provider and role provider and this time set them as default and enable them.

now move to central admin site and select the application and move to Authentication Providers.

select form based authentication and provide the name of membership  and role provider and save settings.

now create a new user using IIS and add this user to site collection administrator.

now enable form authentication for new web application using IIS

now open new web application

click at the top right corner then u will be navigated to the login page

i will come with another page on how to customize the login page and add own custom application pages. Leave ur comments.

Hi all
today i was trying to deploy my application on windows 7, 1st step completed successfully but after making some updates in my web.config file i got some deployment errors, after goggling i found there have a lot of modification in new IIS 7+ which a developer must know before deploying the application, i have listed them for your assistance.

Migration errors

These errors occur due to changes in how some ASP.NET configuration is applied in Integrated mode.  IIS will automatically detect this configuration and issue an error asking you to migrate your application, or move it to classic mode if migration is not acceptable (See breaking change #3 below).


1) ASP.NET applications require migration when specifying configuration in <httpModules> or <httpHandlers>.

You will receive a 500 – Internal Server Error.  This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

It occurs because ASP.NET modules and handlers should be specified in the IIS <handlers> and <modules> configuration sections in Integrated mode.


1) You must migrate the application configuration to work properly in Integrated mode.  You can migrate the application configuration with AppCmd:

> %windir%\system32\inetsrv\Appcmd migrate config “<ApplicationPath>”

2) You can migrate manually by moving the custom entries in in the <system.web>/<httpModules> and <system.web>/<httpHandlers> configuration manually to the <system.webServer>/<handlers> and <system.webServer>/<modules> configuration sections, and either removing the <httpHandlers> and <httpModules> configuration OR adding the following to your application’s web.config:


<validation validateIntegratedModeConfiguration=”false” />



2) ASP.NET applications produce a warning when the application enables request impersonation by specifying <identity impersonate=”true”> in configuration

You will receive a 500 – Internal Server Error. This is HTTP Error 500.24: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

It occurs because ASP.NET Integrated mode is unable to impersonate the request identity in the BeginRequest and AuthenticateRequest pipeline stages.


1) If your application does not rely on impersonating the requesting user in the BeginRequest and AuthenticateRequest stages (the only stages where impersonation is not possible in Integrated mode), ignore this error by adding the following to your application’s web.config:

<validation validateIntegratedModeConfiguration=”false” />


2) If your application does rely on impersonation in BeginRequest and AuthenticateRequest, or you are not sure, move to classic mode.


3) You receive a configuration error when your application configuration includes an encrypted <identity> section.

You will receive a 500 – Internal Server Error.  This is HTTP Error 500.19: The requested page cannot be accessed because the related configuration data for the page is invalid.
The detailed error information indicates that “Configuration section encryption is not supported”.

It occurs because IIS attempts to validate the <identity> section and fails to read section-level encryption.


1) If your application does not have the problem with request impersonation per breaking change #2, migrate your application configuration by using AppCmd as described in breaking change #1:

> %windir%\system32\inetsrv\Appcmd migrate config “<ApplicationPath>”

This will insure that the rest of application configuration is migrated, and automatically add the following to your application’s web.config to ignore the <identity> section:


<validation validateIntegratedModeConfiguration=”false” />


2) If your application does have the problem with request impersonation, move to classic mode.


Authentication, Authorization, and Impersonation

In Integrated mode, both IIS and ASP.NET authentication stages have been unified.  Because of this, the results of IIS authentication are not available until the PostAuthenticateRequest stage, when both ASP.NET and IIS authentication methods have completed.  This causes the following changes:



4) Applications cannot simultaneously use FormsAuthentication and WindowsAuthentication

Unlike Classic mode, it is not possible to use Forms Authentication in ASP.NET and still require users to authenticate with an IIS authentication method including Windows Authentication, Basic Authentication, etc.  If Forms Authentication is enabled, all other IIS authentication methods except for Anonymous Authentication should be disabled.
In addition, when using Forms Authentication, the following changes are in effect:

–       The LOGON_USER server variable will be set to the name of the Forms Authentication user.

–       It will not be possible to impersonate the authenticated client.  To impersonate the authenticated client, you must use an authentication method that produces a Windows user instead of Forms Authentication.


1) Change your application to use the pattern explained in Implementing a two level authentication scheme using Forms Authentication and another IIS authentication method in IIS 7.0.



5) Windows Authentication is performed in the kernel by default.  This may cause HTTP clients that send credentials on the initial request to fail.

IIS 7.0 Kernel-mode authentication is enabled by default in IIS 7.0.  This improves the performance of Windows Authentication, and simplifies the deployment of Kerberos authentication protocol.  However, it may cause some clients that send the windows credentials on the initial request to fail due to a design limitation in kernel-mode authentication.  Normal browser clients are not affected because they always send the initial request anonymously.

NOTE: This breaking change applies to both Classic and Integrated modes.


1) Disable kernel-mode authentication by setting the userKernelMode to “false” in the system.webServer/security/authentication/windowsAuthentication section.  You can also do it by AppCmd as follows:

> %windir%\system32\inetsrv\appcmd set config /section:windowsAuthentication /useKernelMode:false


6) Passport authentication is not supported.

You will receive an ASP.NET 500 – Server Error: The PassportManager object could not be initialized. Please ensure that Microsoft Passport is correctly installed on the server.

Passport authentication is no longer supported on Windows Vista and Windows Server 2008.  NOTE: This breaking change applies to both Classic and Integrated modes.



7) HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed in a module before PostAuthenticateRequest

You will receive an ASP.NET 500 – Server Error: This method can only be called after the authentication event.

HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed before PostAuthenticateRequest, because the value of this property is unknown until after the client has been authenticated.


1) Change the code to not access HttpRequest.LogonUserIdentity until at least PostAuthenticateRequest



8) Client impersonation is not applied in a module in the BeginRequest and AuthenticateRequest stages.

The authenticated user is not known until the PostAuthenticateRequest stage.  Therefore, ASP.NET does not impersonate the authenticated user for ASP.NET modules that run in BeginRequest and AuthenticateRequest stages.  This can affect your application if you have custom modules that rely on the impersonating the client for validating access to or accessing resources in these stages.


1) Change your application to not require client impersonation in BeginRequest and AuthenticateRequest stages.


9) Defining an DefaultAuthentication_OnAuthenticate method in global.asax throws PlatformNotSupportedException

You will receive an ASP.NET 500 – Server Error: The DefaultAuthentication.Authenticate method is not supported by IIS integrated pipeline mode.

In Integrated mode, the DefaultAuthenticationModule.Authenticate event in not implemented and hence no longer raises. In Classic mode, this event is raised when no authentication has occurred.


1) Change application to not rely on the DefaultAuthentication_OnAuthenticate event.  Instead, write an IHttpModule that inspects whether HttpContext.User is null to determine whether an authenticated user is present.



10) Applications that implement WindowsAuthentication_OnAuthenticate in global.asax will not be notified when the request is anonymous[M2]

If you define the WindowsAuthentication_OnAuthenticate method in global.asax, it will not be invoked for anonymous requests.  This is because anonymous authentication occurs after the WindowsAuthentication module can raise the OnAuthenticate event.



1) Change your application to not use the WindowsAuthentication_OnAuthenticate method.  Instead, implement an IHttpModule that runs in PostAuthenticateRequest, and inspects HttpContext.User.


Request limits and URL processing

The following changes result due to additional restrictions on how IIS processes incoming requests and their URLs.


11) Request URLs containing unencoded “+” characters in the path (not querystring) is rejected by default

You will receive HTTP Error 404.11 – Not Found: The request filtering module is configured to deny a request that contains a double escape sequence.

This error occurs because IIS is by default configured to reject attempts to doubly-encode a URL, which commonly represent an attempt to execute a canonicalization attack.

1) Applications that require the use of the “+” character in the URL path can disable this validation by setting the allowDoubleEscaping attribute in the system.webServer/security/requestFiltering configuration section in the application’s web.config.  However, this may make your application more vulnerable to malicious URLs:



<requestFiltering allowDoubleEscaping=”true” />




12) Requests with querystrings larger then 2048 bytes will be rejected by default

You will receive an HTTP Error 404.15 – Not Found: The request filtering module is configured to deny a request where the query string is too long.

IIS by default is configured to reject querystrings longer than 2048 bytes.  This may affect your application if it uses large querystrings or uses cookieless ASP.NET features like Forms Authentication and others that cumulatively exceed the configured limit on the querystring size.

NOTE: This breaking change applies to both Classic and Integrated modes.


1) Increase the maximum querystring size by setting the maxQueryString attribute on the requestLimits element in the system.webServer/security/requestFiltering configuration section in your application’s web.config:




<requestLimits maxQueryString=”NEW_VALUE_IN_BYTES” />




Changes in response header processing

These changes affect how response headers are generated by the application.


13) IIS always rejects new lines in response headers (even if ASP.NET enableHeaderChecking is set to false)

If your application writes headers with line breaks (any combination of \r, or \n), you will receive an ASP.NET 500 – Server Error: Value does not fall within the expected range.

IIS will always reject any attempt to produce response headers with line breaks, even if ASP.NET’s enableHeaderChecking behavior is disabled.  This is done to prevent header splitting attacks.

NOTE: This breaking change applies to both Classic and Integrated modes.


14) When the response is empty, the Content-Type header is not suppressed

If the application sets a Content-Type header, it will remain present even if the response is cleared.  Requests to ASP.NET content types will typically have the “Content-Type: text/html” present on responses unless overridden by the application.
1) While this should not typically have a breaking effect, you can remove the Content-Type header by explicitly setting the HttpResponse.ContentType property to null when clearing the response.


15) When the response headers are cleared with HttpResponse.ClearHeaders, default ASP.NET headers are not generated.  This may result in the lack of Cache-Control: private header that prevents the caching of the response on the client

HttpResponse.ClearHeaders does not re-generate default ASP.NET response headers, including “Content-Type: text/html” and “Cache-Control: private”, as it does in Classic mode.  This is because ASP.NET modules may call this API for requests to any resource type, and therefore generating ASP.NET-specific headers is not appropriate.  The lack of the “Cache-Control” header may cause some downstream network devices to cache the response.
1) Change application to manually generate the Cache-Control: private header when clearing the response, if it is desired to prevent caching in downstream network devices.


Changes in application and module event processing

These changes affect how the application and module event processing takes place.


16) It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax

If your application accesses the current request context in the Application_Start method in global.asax as part of application initialization, you will receive an ASP.NET 500 – Server Error: Request is not available in this context.

This error occurs because ASP.NET application initialization has been decoupled from the request that triggers it.  In Classic mode, it was possible to indirectly access the request context by accessing the HttpContext.Current property.  In Integrated mode, this context no longer represents the actual request and therefore attempts to access the Request and Response objects will generate an exception.


1) See Request is not available in this context exception in Application_Start for a detailed description of this problem and available workarounds.


17) The order in which module event handlers execute may be different then in Classic mode

The following differences exist:

–       For each event, event handlers for each module are executed in the order in which modules are configured in the <modules> configuration section.  Global.asax event handlers are executed last.

–       Modules that register for the PreSendRequestHeaders and PreSendRequestContent events are notified in the reverse of the order in which they appear in the <modules> configuration section

–       For each event, synchronous event handlers for each module are executed before asynchronous handlers.  Otherwise, event handlers are executed in the order in which they are registered.

Applications that have multiple modules configured to run in either of these events may be affected by these change if they share a dependency on event ordering.  This is not likely for most applications.  The order in which modules execute can be obtained from a Failed Request Tracing log.
1) Change the order of the modules experiencing an ordering problem in the system.webServer/modules configuration section.


18) ASP.NET modules in early request processing stages will see requests that previously may have been rejected by IIS prior to entering ASP.NET.  This includes modules running in BeginRequest seeing anonymous requests for resources that require authentication.

ASP.NET modules can run in any pipeline stages that are available to native IIS modules.  Because of this, requests that previously may have been rejected in the authentication stage (such as anonymous requests for resources that require authentication) or other stages prior to entering ASP.NET may run ASP.NET modules.

This behavior is by design in order to enable ASP.NET modules to extend IIS in all request processing stages.



1) Change application code to avoid any application-specific problems that arise from seeing requests that may be rejected later on during request processing.  This may involve changing modules to subscribe to pipeline events that are raised later during request processing.



Other application changes

Other changes in the behavior of ASP.NET applications and APIs.



19) DefaultHttpHandler is not supported.  Applications relying on sub-classes of DefaultHttpHandler will not be able to serve requests.[M3]

If your application uses DefaultHttpHandler or handlers that derive from DefaultHttpHandler, it will not function correctly.  In Integrated mode, handlers derived from DefaultHttpHandler will not be able to pass the request back to IIS for processing, and instead serve the requested resource as a static file.  Integrated mode allows ASP.NET modules to run for all requests without requiring the use of DefaultHttpHandler.



1) Change your application to use modules to perform request processing for all requests, instead of using wildcard mapping to map ASP.NET to all requests and then using DefaultHttpHandler derived handlers to pass the request back to IIS.



20) It is possible to write to the response after an exception has occurred.

In Integrated mode, it is possible to write to and display an additional response written after an exception has occurred, typically in modules that subscribe to the LogRequest and EndRequest events. This does not occur in Classic mode. If an error occurs during the request, and the application writes to the response in EndRequest after the exception has occurred, the response information written in EndRequest will be shown. This only affects requests that include unhandled exceptions. To avoid writing to the response after an exception, an application should check HttpContext.Error or HttpResponse.StatusCode before writing to the response.



21) It is not possible to use the ClearError API to prevent an exception from being written to the response if the exception has occurred in a prior pipeline stage

Calling Server.ClearError during the EndRequest event does not clear the exception if it occurred during an earlier event within the pipeline.  This is because the exception is formatted to the response at the end of each event that raises an exception.


1) Change your application to call Server.ClearError from the Application_OnError event handler, which is raised whenever an exception is thrown.



22) HttpResponse.AppendToLog does not automatically prepend the querystring to the URL.[M4]

When using HttpResponse.AppendToLog to append a custom string to the URL logged in the request log file, you will manually need to prepend the querystring to the string you pass to this API.  This may result in existing code losing the querystring from the logged URL when this API is used.

1) Change your application to manually prepend HttpResponse.QueryString.ToString() to the string passed to HttpResponse.AppendToLog.


Other changes

Other changes.


23) ASP.NET threading settings are not used to control the request concurrency in Integrated mode

The minFreeThreads, minLocalRequestFreeThreads settings in the system.web/httpRuntime configuration section and the maxWorkerThreads setting in the processModel configuration section no longer control the threading mechanism used by ASP.NET.  Instead, ASP.NET relies on the IIS thread pool and allows you to control the maximum number of concurrently executing requests by setting the MaxConcurrentRequestsPerCPU DWORD value (default is 12) located in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 key.  This setting is global and cannot be changed for individual application pools or applications.



1) To control the concurrency of your application, set the MaxConcurrentRequestsPerCPU setting.


24) ASP.NET application queues are not used in Integrated mode.  Therefore, the “ASP.NET Applications\Requests in Application Queue” performance counter will always have a value of 0

ASP.NET does not use application queues in Integrated mode.


25) IIS 7.0 always restarts ASP.NET applications when changes are made to the application’s root web.config file.  Because of this, waitChangeNotification and maxWaitChangeNotification attributes have no effect.

IIS 7.0 monitors changes to the web.config files as well, and cause the ASP.NET application corresponding to this file to be restarted without regard to the ASP.NET change notification settings including the waitChangeNotification and maxWaitChangeNotification attributes in the system.web/httpRuntime configuration sections.



26) ASP.NET deadlock detection is not supported in Integrated mode.

ASP.NET 2.0 Classic mode supports a deadlock detection mechanism which monitors ASP.NET responses and considers the process deadlocked if no responses have been received in more then the amount of time specified in the <processModel responseDeadlockInterval> setting, and there are more than a certain number of requests outstanding.  In this case, the process is marked unhealthy and a new process is eventually started.  In Integrated mode, this feature is not supported.  If your application is prone to deadlocks, it may lead to deadlock conditions being undetected, however it should have no effect on healthy applications that do not exhibit deadlocks.


Hi all

Today I installed Windows SharePoint Services 3.0 on Windows 7, everything went fine but when I opened SharePoint Central Administration I was surprised to see that “Create/Extend Web Application link was not visible and even “OK” button of “Create new Site Collection” was also disabled, after goggling I found following solution, this helped me and I hope this will help you as well. Let me know your comments on this.

Even if I was logged in as administrator of my machine and the account was showing system account, hence I should get an option for that, however that was not there.

Well, this is the first time I have faced such problem.

Well, time to find some information in internet. And guess what I found 5 different solutions for that. For most of the people second trick (mentioned below) out of five solutions did the magic.

Well let me tell you all solutions that I found, so that you can try each one of them one by one.

Tell you what I wasted my 3 hours to figure out and installing service packs and all. Well in my case it was not needed.

My suggestion, go one by one in order that I have mentioned here. Chances are more that problem will be resolved.

1) Open the central administrator from Start menu with run as administrator option.

2) Your central administration site should be on intranet mode not on internet mode. This is the key area and most likely problem will be solved with this. Go to Tools-Internet option-Local intranet-Sites-Advanced and then add your central administration URL.
3) If first two combined step cannot solve this problem, then open IE as administrator from start menu to open central administration.

4) Download WSS service pack 2 and SharePoint service pack 2 and then check.


Step 1: Start Server Manager

To start Server Manager, click: Start Menu -> All Programs -> Administrative Tools -> Server Manager. The Server Manager window opens.

Figure 2: Server Manager

Step 2: Adding a Server Role

  • In the Server Manager, select Roles.
  • The Role Summary View is displayed.

Figure 3: Start Add Roles Wizard

Step 3: Start the Add Roles Wizard

  • Click Add Roles.
  • The Add Roles Wizard opens.
  • Click Next to select roles to install.

Figure 4: Add Roles Wizard Introduction

Step 4: Choose Web Server (IIS) Role to Install

  • Check Web Server (IIS).

Figure 5: Check Web Server (IIS) in Add Roles Wizard

Step 5: Web Server Role depends on WAS

The Add Roles Wizard notifies you on any required dependencies; since IIS depends on the Windows Process Activation Service (WAS) feature, the following informational dialog displays.

  • Click Add Required Role Services to continue.


Figure 6: Add Dependencies

Web Server is now selected for install. The Select Server Roles dialog box opens.


Figure 7: Selected Web Server (IIS)

  • Click Next to continue.

Step 6: Additional Information

The following dialog box and information displays.


Figure 8: Introduction to Web Server Dialog

  • Click Next to continue

Step 7: View IIS 7.0 Features

The Add Roles Wizard displays a list of all IIS 7.0 features available to install as shown below. Note that features comprising the default install are pre- selected.


Figure 9: Web Server Features Listed

Note: To install just the IIS 7.0 default features, click the Install button and then proceed to Step 10 below. If you need to install additional features, proceed to Step 8.

Step 8: Select Additional IIS Features to Install

For this example, we install additional IIS features:

  • Start by checking the box for ASP.NET. The following dialog displays.
  • The Wizards warns if adding an IIS feature will also cause other features to be installed.


Figure 10: Dependency Information

  • Click Add Required Role Services to continue.

Step 9: Select Additional IIS Features to Install

Continue selecting additional IIS Role Services features to Install:

  • Check the features you require.


Figure 11: Add Features For Web Server

  • When you have selected all the features you require, click Next to continue.

Step 10: Summary of Features to Install

  • The Wizard provides a summary of what will be installed, as shown below


Figure 12: Summary of Features

  • Click Install to continue.

Step 11: Install Progress

After clicking Install, the install progress dialog opens.


Figure 13: Install Progress

Step 12: Install Complete

When IIS 7.0 install is complete, the following dialog opens. Click Close to return to the Server Manager.


Figure 14: Installation Summary

Step 13: Check IIS 7.0 install

You can now perform a quick check to verify that IIS 7.0 is installed.

  • Start Internet Explorer web browser and enter the address http://localhost.
  • You should see the default IIS “Welcome” page.

if it is helpful, plese dont forget to leave a comment.