Why we are using warm-up scripts

SharePoint is built upon the Microsoft .NET Framework and ASP.NET, specially the 2.0 releases of those technologies. ASP.NET is architected so that its pages are not compiled until the first time a server request .As you know when an IIS worker process has coming up for the first time , It makes lots of jobs in the background. The big portion of this time used by compiling assemblies, and reading configurations  . For a standard ASP.Net application it takes very small time but for a SharePoint Application we have tons of assemblies and configurations and more than one WCF services which is need to be activated . So it will usually takes more time over 1 minutes. The warm up duration also depends on your configuration , hardware and assembly counts and changes for every system.

The issue happens when application pool recycle, iisreset or a worker process crashes.  And for SharePoint sites every application pool has a configuration that force the recycle itself . You can check from IIS -> Application Pools -> (For example Select “SharePoint Central Administration v4”) and right click   Select Recycling option And you can see the recycle time.

We have also an Idle Time Out property defined in Application Pool settings that make free worker processes resources which are in idle state for defined time period . Configure Idle Time-out Settings for an Application Pool (IIS 7) http://technet.microsoft.com/en-us/library/cc771956(v=WS.10).aspx

However even it is disabled by setting “Idle Time Out” value to 0 still IIS requires and also suggested way that recycle application pools daily manner. The default IIS behavior of naturally cycling an app pool somewhere between 1am and 3am or off hours if there is such a thing is healthy to clean out the memory space in IIS. Also same consideration is valid for SharePoint Timer service , there is a Timer job in SharePoint for responsible to restart timer service in daily manner. It is a good and suggested thing http://blogs.msdn.com/b/besidethepoint/archive/2012/01/10/the-timer-recycle-job-job-timer-recycle.aspx

But sometime in the midnight a recycle occurs and assume that no one send a request a server until morning and when a user open his browser and try to connect SharePoint site He/She should wait more, because the worker process is only getting up until the first time a server get the request. Warm up scripts send a requests to your server for a scheduled time  that forces IIS to worker process up and running .when a user’s request a page through a browser, preventing your users from seeing a delay when making that first request. That’s pretty much all they do, and the only purpose most of them serve is to “warm up” your server by having precompile your site’s ASP.NET pages ahead of an actual user request. You can use warm up scripts .

For the warm up scripts which is described in fallowing article http://blogs.technet.com/b/rgullick/archive/2011/12/02/minimalist-sharepoint-warmup-script.aspx have very common usage on this kind of issues.

 

Advertisements

SharePoint 2010 Form based authentication problem Event ID:1315 and Event ID:8306

Assume that you have a SharePoint 2010 site with configured as Claim Based Authentiction with custom SQL Membership . You have move your site and membership database to another server and you have facing with connection problems on existing SQL MemberShip users by getting this fallowing errors

In ULS Logs:

11.13.2012 15:40:18.20 w3wp.exe (0x18C8) 0x17C8 SharePoint Foundation Claims Authentication 0000 Unexpected Password check on ‘user@mail.com’ generated exception: ‘System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).’.

11.13.2012 15:40:18.20 w3wp.exe (0x18C8) 0x17C8 SharePoint Foundation Claims Authentication fo1t Monitorable SPSecurityTokenService.Issue() failed: System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).

and In Event logs
Presence of Event ID 8306 in the Application Event Log
11/08/2012 03:29:11 PM Error SERVERA 8306 Microsoft-SharePoint Products-SharePoint Foundation Claims Authentication DOMAIN\User An exception occurred when trying to issue security token: The security token username and password could not be validated..

Presence of Event ID 1315 in the Application Event Log with Event code: 4006
Event message: Membership credential verification failed.

The problem is here if you try to login site with one of existing FBA user even password is correct , cound not able to validate password . If you create a new FBA user , there is no problem on login.
The main cause of this issue could be changes of the Machine Key.

Why ?

The Password information is stored in the aspnet_Membership table in Asp.Net Membership database . The   SqlMembershipProvider allows for passwords to be stored in the database    using one of the following three techniques:

  • Clear – the password is stored in the database as plain-text. I strongly        discourage using this option. If the database is compromised – be it by a hacker        who finds a back door or a disgruntled employee who has database access – every        single user’s credentials are there for the taking.
  • Hashed – passwords are hashed using a one-way hash algorithm and a randomly        generated salt value. This hashed value (along with the salt) is stored in the database.
  • Encrypted – an encrypted version of the password is stored in the database

The password storage technique used depends on the SqlMembershipProvider    settings specified in Web.configThe default behavior is to    store the hash of the password.
the particular encryption or hashing algorithm used by the SqlMembershipProvider is determined by the settings in the <machineKey> element.

for more information:
http://www.asp.net/web-forms/tutorials/security/membership/creating-the-membership-schema-in-sql-server-vb
http://www.asp.net/web-forms/tutorials/security/introduction/forms-authentication-configuration-and-advanced-topics-vb

So if you have move your site to another server you may consider that the MachineKey if anyhow is changed , the existing users’ passwords can not be validated.

1) First Check for the MachineKey values in web.config for related your FBA SharePoint site. If you have any difference on target site make them equalize.
2) Also don’t forget to check other servers in your farm for the same site should be same MachineKey. If any difference in MachineKeys may cause integrity problems.

Somehow If the data integrity has broken , recreating users or forcing the users reset their password will help about the issue.

 

Unrecognized attribute “targetFramework” when deploying asp.net 4.0

Ok you start developement with .net framework 4.0 and possibly try to deploy your site to iis first time and getting this error :Unrecognized attribute “targetFramework” when deploying asp.net 4.0 Because you did not configure your iis run with .net framework 4.0.

For do it you have to change your path to

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

that execute command of

aspnet_regiis.exe -iru

if you already do this and getting this error you should better to check your site application pool for correct .NET framework version chosen.

Application Pools->Select yours -> Basic Settings -> And change .NET framework version

Thats it folks.

 

when CacheItemRemovedCallback is raised HttpContext.Current is null

CacheItemRemovedCallback shows users the value assigned to an item in the cache and then notifies them when the item is removed from the cache. It creates a RemovedCallback method, which uses the signature of the CacheItemRemovedCallback delegate, to notify users when the cache item is removed and uses theCacheItemRemovedReason enumeration to tell them why it was removed.But when you try to use cache with HttpContext.Current it encounter an object not set reference error.

Here is the solution.

Use :HttpRuntime.Cache instead of HttpContext.Current.Cache object

Example::

 public static void DropUser(string key, object value, CacheItemRemovedReason reason)
        {
            List<string> OnlineUserAccounts = null;
            if (HttpRuntime.Cache[CACHE_KEY] != null)
            {
                OnlineUserAccounts = (List<string>)HttpRuntime.Cache[CACHE_KEY];
                if (OnlineUserAccounts.Contains(key))
                {
                    OnlineUserAccounts.Remove(key);
 
                    HttpRuntime.Cache[CACHE_KEY] = OnlineUserAccounts;
                }
            }
        }
 
Happy Codding.