Q. What is Enterprise Metadata Management?

Introduction to Enterprise Metadata Management

Enterprise metadata management (EMM) is a set of features introduced in Microsoft SharePoint Server 2010 that enable taxonomists, librarians, and administrators to create and manage terms and sets of terms across the enterprise.

The managed metadata service: is a service application that enables the use of managed metadata and

allows you to share content types across site collections and across Web applications. The service publishes a term store and content types, and the metadata is consumed via the managed metadata connection. A managed metadata service and connection are created when the metadata service application is created.

Managed Metadata Service Application Creating the service application requires the administrator to specify the database to be used as the term store. When you create new managed terms, or when users add managed keywords, these terms are stored in the database. Like other service applications, the managed metadata service can be published to provide access to other Web applications.
When a service application is published, a URL to the service is created.
 The administrator of another Web application can create a connection to your service by using this URL.
In addition to sharing metadata, you can also use the managed metadata service to share content types. By creating a new managed metadata service and specifying a site collection as the content type hub, you can share all content types in the site collection’s content type gallery.

You can create multiple managed metadata service applications. This provides the capability to share multiple term stores and content types from multiple site collections. Each service must specify a different term store during the creation process, and a new database will be created if it does not exist.

Managed Metadata Service ConnectionThe connection provides access to the service. When you create a managed metadata service, a connection to the service is automatically created in the same Web application as the service. Web applications can have connections to multiple services. Several properties are specified as part of the connection. Values for each of these properties must be specified as part of configuring the service connection.

Default keyword location Specifies that the term store will be used to store new managed keywords. This provides the capability for sharing and managing a common set of keywords across site collections.

Default term set location Specifies where to store term sets when new site columns are created. This provides the capability for sharing and managing a common set of terms across site collections.

Use content types Makes content types associated with this managed metadata service available to users of sites in this Web application.Push-down content type publishing updates from the content type gallery to subsites and lists by using the content type whether to update existing instances of the changed content types in subsites and libraries.

Adding your Web Part to the Safe Controls List

why we want to add webpart as safe control in SharePoint?

A fundamental assumption of the Windows SharePoint Services technology is that "untrusted users" can upload and create ASPX pages within the system on which Windows SharePoint Services is running. These users should be prevented from adding server-side code within ASPX pages, but there should be a list of approved controls that those untrusted users can use. One way to provide these controls is to create a Safe Controls list.

The Safe Controls list is a list of controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. You store this list in the web.config file in your Web application root.

How to add as safe control

1. Open the web.config file in the application root.
2. Add a safe control entry for your custom assembly to the web.config file as follows:
   
   
   

   <SafeControl Assembly="MyWebPartLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="MyWebPartLibrary" TypeName="*" Safe="True" AllowRemoteDesigner="True"/>

Shared Services in SharePoint 2010

Shared Services in SharePoint 2010

Shared Service Provider (SSP) in SharePoint 2007 has been replaced by Shared Services in SharePoint 2010. SSP in SharePoint 2007 was confusing and had its share of limitations which SharePoint 2010 seems to solve by introducing Shared Services.

Key differences between SSP and Shared Services

SSP in 2007	Shared Services in 2010
MOSS only	Available in WSS
Different services shared the same db	Services can have its own db
Internal to MOSS	Public APIs to create own Shared Services
Only one application of service	Multiple instances of service allowed
Restricted to the farm	Cross farm support

SharePoint 2010 provides the following Shared Services ( not an exhaustive list )

Access Services : Allows viewing, editing, and interacting with Access databases in a browser.
Business Connectivity Service : Provides read/write access to external data from line-of-business (LOB) systems, Web services, databases, and other external systems. Also available in SharePoint Foundation.
Managed Metadata Service : Provides access to managed taxonomy hierarchies, keywords, social tags and Content Type publishing across site collections.
Secure Store Service : Provides capability to store data (e.g. credential set) securely and associate it to a specific identity or group of identities.
State Service : Provides temporary storage of user session data for Office SharePoint Server components.
Usage and Health data collection : This service collects farm wide usage and health data and provides the ability to view various usage and health reports.
Visio Graphics Service : Enables viewing and refreshing of published Visio diagrams in a web browser.
Web Analytics Service Application : Enable rich insights into web usage patterns by processing and analyzing web analytics data .
Word Conversion Service Application : Provides a framework for performing automated document conversions

Deploying an ASP.NET HttpHandler to SharePoint 2010

 How to deploy an HttpHandler to SharePoint 2010 that uses code-behind.  The answer is that you don’t really use code-behind like you would in an ASP.NET application where the code and assembly are in the same folder.  With SharePoint, you need to deploy your code to the Global Assembly Cache (GAC).
You can create the code for an HttpHandler very easily in Visual Studio.  I am going to steal borrow some code from Ted Pattison’s walkthrough, “Creating a Custom HttpHandler in Windows SharePoint Services 3.0” on MSDN (includes a video as well).

using System;
using System.Web;
using Microsoft.SharePoint;

namespace ASHXHandlerDemo
{
    public class HelloHttpHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get { return false; }
        }
 
        
        public void ProcessRequest(HttpContext context)
        {
            SPSite siteColl = SPContext.Current.Site;
            SPWeb site = SPContext.Current.Web;
            context.Response.ContentType = "text/plain";
            context.Response.Write("Hello HttpHandler from the site " +
                                   site.Title +
                                   " at " +
                                   site.Url);
        }
    }
}

The question is how to call that code?  When an HTTP request comes in, how do you map that request to this code? 
The easiest way is to create a .ASHX file and deploy it to the LAYOUTS directory in the SharePoint root (aka “14 hive”).  To do this, right-click your SharePoint project in Visual Studio 2010 and choose “Add SharePoint Layouts Mapped Folder”. 

In that newly created folder, add a new file with a .ASHX extension with the following contents.  The .ASHX file just points to the code in the GAC using the fully-qualified assembly name.

<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="ASHXHandlerDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=684a624f7b7a49ae" %>
<%@ WebHandler Language="C#"  Class="ASHXHandlerDemo.HelloHttpHandler" %>

The solution looks like this in Visual Studio 2010.

When you build and deploy your solution from Visual Studio, the code is compiled into an assembly (a .DLL) and registered in the Global Assembly Cache.  The output is:

Difference between Farm and Sandbox solutions in SharePoint

Farm Solutions:

Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm. When you debug a SharePoint project whose Sandboxed Solution property is set to "farm solution," the system's IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project's site URL is recycled.

Sandbox Solutions:

Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.

How to add WFE(Web Front Servers) in SharePoint 2010

Solution:

You need to join the new server to the farm, then go to Services on Server (in Central Administration) and enable Microsoft SharePoint Foundation Web Application Service. Then you'll see that in IIS your websites and application pools appeared

Managed Accounts in SharePoint 2010

Microsoft SharePoint Server 2010 provides a number of compelling improvements designed especially for the system administrator, of these, commonly overlooked, are Managed Accounts.  A Managed Account is effectively an Active Directory user account whose credentials are managed by and contained within SharePoint.  In addition to storing the credentials of the object, Microsoft SharePoint Server 2010 can also leverage Active Directory Domain Policies to  automatically reset passwords while meeting the requirements established by policy.
How credentials are stored…
Managed Account credentials are encrypted using a farm encryption key that is specified when you run PSConfig[ui].exe at farm creation based on the passphrase.  The passphrase is stored in a secure registry location so that it can only be accessed by the farm account and encrypted so that only the farm account has access (we won’t get into the encryption specifics here). The farm encryption key subsequently, is stored in the Configuration Database.   This scenario is what enables farm administrators to join machines to the farm without specifying the credentials as had to be done in previous versions of the product.
The last sentence of the paragraph above illustrates one of immediate benefits of using Managed Accounts, for example, suppose an administrator would like to create a new Web application using Windows PowerShell and/or SharePoint Central Administration – the administrator only needs to specify the Application Pool account (Windows PowerShell) or select the account in the SharePoint Central Administration user interface as opposed to both having to know the domain\username and associated password.
Example (Windows PowerShell)
$provider = New-SPAuthenticationProvider -ASPNETMembershipProvider "LdapMember" -ASPNETRoleProviderName "LdapRole"
$webApp = New-SPWebApplication -Name "Claims" -ApplicationPool "Claims Application Pool" -ApplicationPoolAccount "CONTOSO\administrator"
  -Url http://claims.contoso.com -Port 80 -AuthenticationProvider $provider
Get Managed Accounts (SharePoint Central Administration)

1. To view existing Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. The Managed Accounts page will list all Managed Accounts registered in SharePoint.

Register Managed Accounts (SharePoint Central Administration)

1. To register new Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. On the Managed Accounts page select Register Managed Account.
4. On the Register Managed Account page (see illustration below) specify the credentials and select the password change policies as desired.

Get Managed Accounts (Windows PowerShell)

1. To view existing Managed Accounts using Windows PowerShell, open the SharePoint 2010 Management Shell and enter Get-SPManagedAccount at the prompt.  For additional information on using the Get-SPManagedAccount CmdLet enter Get-Help Get-SPManagedAccount at the prompt.

Register Managed Accounts (Windows PowerShell)

1. To register Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).

Syntax
New-SPManagedAccount [-Credential] <PSCredential> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Configure Managed Accounts (Windows PowerShell)

1. To configure Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).

Syntax
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotif
ication <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<S
witchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-AutoGeneratePassword <SwitchParameter>] [
-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays
<Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]] [<CommonParamet
ers>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ConfirmPassword
<SecureString> -NewPassword <SecureString> [-AssignmentCollection <SPAssign
mentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>
] [-PreExpireDays <Int32>] [-Schedule <String>] [-SetNewPassword <SwitchPar
ameter>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ExistingPassword
<SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm
[<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>]
[-Schedule <String>] [-UseExistingPassword <SwitchParameter>] [-WhatIf [<Sw
itchParameter>]] [<CommonParameters>]
For additional information on using the Set-SPManagedAccount CmdLet enter Get-Help Set-SPManagedAccount at the prompt.

SharePoint2010:Deploying a solution STSADM vs. PowerShell

http://www.hersheytech.com/Blog/SharePoint/tabid/197/entryid/11/Default.aspx