First step to using AJAX in MOSS 2007

The scenario :Using AJAX in SharePoint esp. MOSS 2007 is quite exciting.At the same time developers are unaware of the pain to configure your SharePoint site to be able to use AJAX. I hope this article will give you some space to breathe.

The problem: There are awful lot of blogs over internet ,that very well describe the process to use AJAX in SharePoint 2007.So what is the PROBLEM we're talking about. If, before arriving to this blog you've read any other blogs, many of them ask to perform a handful of changes at specific locations in the web.config of the SharePoint site you wish to enable AJAX. As you know, a slight error in web.config will take your entire site down. I'll try to explain a much easier and moreover a safer approach to make changes in web.config.
Before diving in , lets look at the prerequisites for ASP.NET AJAX.

• .NET Framework 3.5 - its recommended to have 3.5 ,but if not possible only a dll of Systems.Web.Extensions with version 3.5.0.0 inside GAC will do.
• Extend web.config of IIS website with ASP.NET extensions.(This is what we'll cover as we go further) 

Visual Studio 2008 comes with AJAX support and a rich AJAX control kit-just in case you want to develop something in AJAX for your SharePoint

The solution: To make changes in web.config so that it supports AJAX functionality perform the following steps:

• Go to Visual Studio 2008, and create an ASP.NET web site

• Make sure you have selected .Net Framework 2.0
• Open the web.config file of the SharePoint site ,you wish to enable AJAX feature
• Copy its entire content .(I would recommend ,you take a copy of the web.config file before making any changes)
• Now replace the web.config file contents which came with the ASP.NET web site ,with the copied content from the previous step
• So now you have the default web.config file for the SharePoint site inside your newly created web site.Save it.
• Right Click the solution in visual studio , and select property pages at the bottom.
• Go to Build section and change the Target framework to .Net Framework 3.5

• Click OK.This will not replace the contents of the web.config ,but will modify it to accommodate all the changes required to support AJAX. 
• Indirectly it will configure the web.config file as per .Net Framework 3.5
• Now open the web.config of you ASP.NET web site from the solution explorer and copy all its content.
• Go to the virtual directory inside inetpub where your web site resides and replace all its content with the just copied ones.
  And thats it..!!!
  You now have AJAX integrated with your SharePoint site.

SharePoint Timer Job demystified

This article talks about some facts about SharePoint Timer Jobs.For those who are not familiar with timer jobs, its a way through which SharePoint related tasks can be scheduled to run in background.

Myth 1: Timer job runs through the Central Administration web application.

Fact: Running your Timer Jobs is completely independent of your Central Administration(CA) web application in the farm. CA is just another web application and it only states Timer job status and its definitions. It is the Windows SharePoint Timer Service(OWSTIMER.EXE) that controls the Timer Job.

Conclusion: So, even if your CA web application goes down(either CA web site or corresponding application pool ), the Timer Job remains unaffected.

Myth 2: Timer Job runs under the security context of Farm Administrator account

Fact: Well, it seems in most of the scenarios that Timer Job runs under the privileges of a Farm Admin account. But the truth is, Timer Job runs the account which is specified as the Log On account for Windows SharePoint Services Timer.

Open Run command  > services.msc  > go to Windows  SharePoint Services Timer > Right Click , select Properties >  Switch to ‘Log On ’ tab.

The account specified in the above figure is responsible to run Timer job. And in most of the production/dev environments the account specified in above figure is also a Farm Admin account, hence we assume that Farm Admin account is responsible to run Timer Job.

Myth 3: RunWithElevatedPriveliges() inside a custom Timer Job executes the block of code under the context of Application pool identity account of targeted web application.

Fact :  The above statement is true when RunWithElevatedPrivileges() is not used inside a Timer Job. When used in a Timer Job it runs under the context of the same account used for running Timer Job i.e. the Windows SharePoint Services Timer account(discussed in Myth 2). The sole intention of using RunWithElevatedPriveleges() is to perform some actions that are otherwise not permitted to. Therefore, in order that our code inside RunWithElevatedPrivileges() block runs successfully , it is necessary that the account under which timer job  runs is also a Site Collection Administrator of targeted web application.

 

Hope this piece of information makes our life easy in SharePoint..;)