How to deploy timer job in SharePoint 2010

Timer jobs are Microsoft.SharePoint.Administration.SPJobDefinition objects. To create a timer job, one should create a new class that inherits from SPJobDefinition. Timer jobs can be deployed by using Features, custom applications, Power Shell, or custom STSADM commands.

Debugging Types:
Debugging Timer Service: User needs to attach debugger with OWSTIMER.exe process. This is the “Windows SharePoint Services Timer" service.
Debugging Event Receiver: User can attach Visual Studio to the w3wp.exe process and simply put a breakpoint in the event handler code. Alternatively, use System.Diagnostics.Trace to write out information to a log.

Databases created at the time of installing SharePoint 2010

Secure Store database: The Secure Store service application database stores and maps credentials, such as account names and passwords. Prefixed with "Secure_Store_Service_DB_".
State database: The State service application database stores temporary state information for InfoPath Forms Services, the chart Web Part, and Visio Services. Prefixed with "StateService".
Web Analytics Staging database: The Staging database temporarily stores un-aggregated fact data, asset metadata, and queued batch data for the Web Analytics service application. Prefixed with "WebAnalyticsServiceApplication_StagingDB_"
Web Analytics Reporting database: The Reporting database stores aggregated standard report tables, fact data aggregated by groups of sites, date and asset metadata, and diagnostics information for the Web Analytics service application. Prefixed with "WebAnalyticsServiceApplication_ReportingDB_"
Search service application Administration database: The Administration database hosts the Search service application configuration and access control list (ACL), and best bets for the crawl component. This database is accessed for every user and administrative action. Prefixed with "Search_Service_Application_DB_".
Search service application Crawl database: The Crawl database stores the state of the crawled data and the crawl history. Prefixed with "Search_Service_Application_CrawlStoreDB_'.
Search service application Property database: The Property database stores information that is associated with the crawled data, including properties, history, and crawl queues. Prefixed with "Search_Service_Application_PropertyStoreDB_"
User Profile service application Profile database: The Profile database stores and manages users and associated information. It also stores information about a user's social network in addition to memberships in distribution lists and sites. Prefixed with "User Profile Service Application_ProfileDB_".
User Profile service application Synchronization database: The Synchronization database stores configuration and staging data for use when profile data is being synchronized with directory services such as Active Directory Prefixed with "User Profile Service Application_SyncDB_".
User Profile service application Social Tagging database: The Social Tagging database stores social tags and notes created by users, along with their respective URLs. Prefixed with "User Profile Service Application_SocialDB_".
Managed Metadata database: The Managed Metadata service application database stores managed metadata and syndicated content types. Prefixed with " Managed Metadata Service_".
Enterprise edition installation adds two more databases:
Performance Point service application database: The Performance Point service application database stores temporary objects, persisted filter values, and user comments. Name Prefix "PerformancePointServiceApplication_.”
Word Automation Services database: The Word Automation Services database stores information about pending and completed document conversions.Name Prefix "WordAutomationServices_..."

Appeal Soft SharePoint Interview Questions for 1 year experience

• What is SharePoint Pillars ?
• Difference between SharePoint 2010 and MOSS 2007 ?
• What is Sandbox Solutions ? 
• Variations in SharePoint 2010 ?
• Explain the SharePoint 2010 services ? and how we can use in applications ?
• SharePoint features ?
• SharePoint Architecture ?
• What is Object Model  in  SharePoint 2010 ?
• Web-part deployment steps in SharePoint 2010 ? 
• What is workflow ? 
• How can we use different services in workflows ?
• What are the SharePoint 2010 default workflows ?
• Explain the different types of authentication and authorization in SharePoint 2010 ?
• How to create Claim based authentication ?
• How many types of databases in SharePoint 2010 ?
• What is SPWeb and SPSite ? Where we can use ? How ?
• What is Alternate Access Mapping in SharePoint 2010 ?
• What is Threshold ?
• What is List Size ? Maximum no of rows in a List ? 
• Where SharePoint .dll's will saved in machine ?

How to Insert notepad data into CustomList In SharePoint 2010

            SPWeb web = new SPSite("http://demo:500/").OpenWeb();
            SPList empList = web.Lists["Dept"];
            SPListItem item;
            StreamReader sr = new StreamReader("C:\\a.txt");
            while (sr.Peek() != -1)
            {
                string record = sr.ReadLine();
                string[] data=record.Split(' ');
                item=empList.Items.Add();
                item["Title"]=data[0];
                item["DeptName"]=data[1];
                item["DeptId"]=data[2];
                item.Update();
            }
In Notepad:
1    IT     10
2   Gov   20
 

View Site Groups In SharePoint 2010

using (SPSite siteCollection = new SPSite("http://hrweb"))
 {
   using (SPWeb site = siteCollection.OpenWeb())
     {
       // Print all groups name of site
       foreach (SPGroup group in site.Groups)
       {
          Console.WriteLine(group.Name);
        }
      Console.WriteLine("View All Site Groups");
 }
}

Second highest Salary

Select MAX(Salary) from Emp where Salary <(Select MAX(Salary) from Emp)

Different Types of Authentication Architecture In SharePoint 2010

SharePoint 2010 web application in claims mode, different authentication options are available. These options determine the flow of the authentication process.

The steps in the authentication process. It explains, in order, the different routes that the authentication process flow can have, based on the authentication options that are available in SharePoint 2010.
Architecture of the Claims-Based Authentication:

Steps in the Claims-Based Authentication Process:

• The client requests a SharePoint resource.
• As part of the request pipeline, if the request is not authenticated, the authentication components route the request based on the authentication settings for that zone.
• The request is then processed by the authentication components. When more than one authentication method is configured for the given zone, the authentication selection page enables the user to choose the authentication method. If only one authentication method is specified, the request is processed directly by the specified authentication method.
• The user is authenticated by the identity provider.
• If authentication succeeds, the SharePoint security token service (STS) generates a claims-based token for the user with the information provided by the identity provider. If additional claims providers are configured, the STS augments the user's token with the claims given by the claims provider. 
• The claims-based token of the user is sent back to the authentication components.
• The authentication components redirect the request back to the resource address, with the claims-based token issued for the user.
• The rest of the request pipeline is executed and a response is sent back to the requestor (client). As part of the request pipeline, the authorization is completed.

The flow of the authentication process is defined by the options that you select during the configuration of the zone.
Architecture of the Windows authentication:
The user selects the option that uses Windows authentication, the user request is redirected to the Windows authentication page, which is silent (no other UI is displayed to the user to indicate that the user is being redirected, unless basic authentication is configured). On the Windows authentication page, when the user is authenticated, a claims-based token is requested and the user is sent back to the requested resource. Because the request contains a claims-based token that was issued by SharePoint STS, a claims identity is created and the request process continues.

Steps in the Windows Authentication Process:

• The user requests a SharePoint 2010 resource.
• User authentication (NTLM challenge/Kerberos negotiation) occurs.
• The claims-based token request is sent to the SharePoint 2010 STS.
• SharePoint STS gets the user's security groups from the Windows token and adds them as user claims in the token.
• The claims-based token is issued.
• The request is processed by the rest of the components in the pipeline.
• The response is sent back to the user.

Architecture of the Forms-based Authentication:

The SharePoint forms-based login page collects the credentials of the user, which are then sent to the SharePoint 2010 STS. The STS calls the membership provider that is associated with that web application, to validate the user's credentials. If this succeeds, the STS retrieves the roles that the user belongs to and adds these as claims in the claims-based token that is sent back to the login page. From the login page, after the claims-based token is issued, the user is sent back to the request resource and the process continues in the same way as in Windows authentication.

Steps in the Forms-based  Authentication Process:

• The user requests a SharePoint 2010 resource.
• SharePoint redirects the user to the forms-based authentication login page.
• The username and password are collected from the user and sent to the SharePoint 2010 STS.
• STS validates the user's credentials with the membership provider and, if validation succeeds, STS requests all the roles that the user belongs to and adds those claims to the user's token.
• The SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application/zone).
• The claims-based token is issued to the user.
• The request is processed by the rest of the components in the pipeline.
• The response is sent back to the user.

Architecture of the SAML Token-Based Authentication:

Out-of-the box, with the default implementation of Active Directory Federation Services (AD FS), when SAML token-based authentication is enabled in the zone settings, users are redirected to a "silent" authentication page, which then redirects the user to the login page, as specified in the SAML-based authentication provider. After the user is authenticated by the authentication provider, a SAML token is issued, and the user is redirected back to the SharePoint 2010 SAML token–based authentication page. The SAML token is then included in the request with the redirect. This process is known as "passive profiles".

Steps in the  SAML Token-Based Authentication Process:

• The user requests a SharePoint 2010 resource.
• SharePoint redirects the user to the SAML authentication page.
• Based on the configuration of the trusted login provider, the request is redirected to the enterprise STS login page or to the federated STS login page.
• The user provides credentials and STS issues a SAML claims-based token.
• The external STS issues the user claims-based token.
• A claims-based token for the user is requested from the SharePoint STS, and the token from the external STS is used as the authentication proof.
• SharePoint STS gets additional claims for the user (if an additional claims provider is registered for that web application or zone).
• SharePoint STS issues the claims-based token.
• The request is processed by the rest of the components in the pipeline.
• The response is sent back to the user.