Search This Blog

Sunday, November 30, 2014

How to create Managed Metadata column in SharePoint 2010


Managed metadata is a hierarchical collection of centrally managed terms that you can define, and then use as attributes for items in Microsoft SharePoint Server 2010. A column is a location in a list in which to store information about a SharePoint Server 2010 item. When you define a column, you provide a name for the column, specify the column's type, and provide additional information that depends on the column type. SharePoint Server 2010 introduces a new column type named managed metadata. When you create a managed metadata column, you specify the term set from which the column's values must come. When you want users to provide information for list items (including documents), and the valid values for the information are contained in a term set, use a managed metadata column. Here we will be seeing just how to create Group, Term sets and term, then how to use them in Managed Metadata column. To know more detailed view of Managed Metadata Service go to this link http://technet.microsoft.com/en-us/library/ee424402.aspx.   If we want to create Managed Metadata column we need to configure Managed Metadata Service in the Central Administration.

How to configure Managed Metadata Service Application:

The steps involved to configure Managed Metadata Service are given below.

Steps Involved:
  1. Go to the Central Administration->Application Management->Manage Service Applications.

    1.gif
  2. In the Ribbon click on New to create a new Metadata Service.

    2.gif
  3. Enter the Name, Database Name and Database Server Name. Now your metadata service is ready.
  4. Click OK.
  5. Now the Managed Metadata Service has been created.
Taxonomy Term Store:

SharePoint Server 2010 includes the Term Store Management Tool, which you use to create and manage term sets.

A term is a word or a phrase that can be associated with an item in SharePoint Server 2010. 

A term set is a collection of related terms. The following steps should be followed to create group, term set and term.

Steps Involved:
  1. Go to the Central Administration->Application Management->Manage Service Applications.

    3.gif
  2. Click on the Managed Metadata Service.
  3. You will enter into the Term Store Management Tool.
  4. On the left hand side you could see Taxonomy Term Store.
  5. First we will create a group for the Term Sets.

    4.gif
  6. Click on the Managed Metadata Service a  New Group  menu appears.
  7. Click on the New Group.
  8. Enter the name for the group as Sharepoint.
  9. Now click on the Sharepoint a menu will appear.

    5.gif
  10. Select  New Term set.
  11. Enter the name for the Term Set as Analysis.
  12. Now click on the Analysis a menu will appear.
  13. Select Create Term and enter the name.

    6.gif
  14. Now we have created Group, Term Set and Terms for the service.

    7.gif
Create Managed Metadata Column in SharePoint List:
  1. Go to the Custom List where you want to create Managed Metadata column.
  2. Go to List Tools => List => Create Column.

    8.gif
  3. Choose the name for the column as Category - Metadata and choose the type of information as Managed Metadata as shown in the below figure.

    9.gif
  4. Choose the term set that we have already created when configuring the Managed Metadata service and click ok.

    10.gif
  5. Thus Managed Metadata column is created.
  6. Add a new item and in the Managed Metadata column we have created you could see all the terms that we have created for Analysis and you could choose any one of them.
  7. This is similar to a choice field but you can't reuse the choices in the choice field whereas in Managed Metadata we can reuse the terms and it is centrally managed.
  8. If choices in the choice field will change frequently and the field will be reused in multiple locations use a Managed Metadata field.
Thus Managed Metadata column is created and we will see how to use this Managed Metadata across farm levels in the next article.

Taxonomy in SharePoint 2010

Taxonomy in SharePoint 2010 is realized through Managed metadata services (MMS). MMS is a hierarchical collection of centrally managed terms that you can define, and then use as attributes for items in SharePoint 2010.

The structure of Managed metadata affects many parts of your SharePoint Server solution, such as the following:
  • Valid values for columns and the way users enter these values.
  • The enterprise keywords that users can apply to SharePoint Server 2010 items.
  • The way that search results can be refined.
  • How documents are routed.
  • The workflows that are applied to SharePoint Server items.
  • The ways that users can sort and filter SharePoint Server items.
  • If you are using social tagging, the tags that users can apply to items that are not SharePoint Server items.
Term Sets, Groups and Terms

Vocabulary can be built in SharePoint in the form of Term Sets and Terms, as in the following example:

Conference rooms (Group)
  • Auditoriums (Term Set)
    • Auditorium C (Term) [Term Properties - Available for tagging, Language, Description, Default Label and Synonyms]
    • Auditorium D
    • Auditorium E
     
  • Halls
    • Hall A
    • Hall B
     
  • Second floor
    • Room 256
    • Room 257
Process of Building a Taxonomy

The following diagram depicts the process to build taxonomy:

Process-to-build-taxonomy.jpg

Figure 1: Process to build taxonomy
  • You need to start by defining the subject area and listing the concepts. You will start with the broader level and then gradually lower the level of detail.
  • You can gather the metadata either from your relevant industry, internally from content in your organization, subject area experts, existing taxonomies etc. It may lead to certain overlap in term sets.
  • Next you need to organize these term sets using either a top down or bottom up approach. It will lead to gap identification.
  • Validate and then implement them.
  • A metadata governance board will keep check on the scope, timelines and validation of term sets.
Classification of data
  • Data is proprietary to the organization
  • May be based on LoBs
  • May be department based
  • May be function based
  • May be Regional
  • May be based on Products
  • May be Project based
The following diagram illustrates how various kinds of SharePoint-based solutions might require various approaches to taxonomy based on business need:

Taxonomy-approaches-based-on-business-needs.jpg

Figure 2: Taxonomy approaches based on business needs

Designing managed metadata services

An example of how to design the managed metadata services infrastructure is shown below:

Designing-managed-metadata-services.jpg

Figure 3: Ex. of Designing managed metadata services

Global Term Sets - The corporate taxonomy is represented by global term sets in the term store that is associated with the corporate managed metadata service. The content type hub that is associated with the corporate managed metadata service makes shared content types available to users of all site collections.

Every Web application has a connection to the corporate managed metadata service. The connections from the My Site Web application, the team sites Web application, and the legal sites Web application, numbered 2, 3, and 4 in the figure, all have restricted access to the corporate managed metadata service. Restricted access lets users of the sites in these Web applications use the shared content types and global term sets, add new enterprise keywords, and create local term sets, but it prohibits them from modifying global term sets.

The administrative Web application hosts the site collection from which authorized users manage the corporate taxonomy and the shared content types. The site collection's content type gallery contains the shared content types, such as the updated document content type that reflects the additional required properties. This content type gallery is the content type hub of the corporate managed metadata service. The connection from the administrative Web application, numbered 1 in the figure, has full access to the corporate managed metadata service.

Local Term Sets are created within the context of a site collection, and are available for use (and visible) only to users of that site collection. For example, the term store that is associated with the legal department's managed metadata service contains term sets that represent confidential information that the legal department uses. Only the legal sites Web application has a connection to legal's managed metadata service, so that users of the site collections in the legal sites Web application can manage their term sets.
Permissions
Application Pool Level

The following table summarizes the permission that each managed metadata service grants to the accounts that the connections use to access the service. Note that a local farm is explicitly given reduced permission. If you do not remove or reduce the permissions for a local farm, other local accounts will connect to the services using the permissions that are specified for the local farm.

Permissions-at-Application-Pool-Level.jpg

Figure 4: Ex. of Permissions at Application Pool Level

Group Level

Permissions can also be given at group level. Groups define security boundaries. A group is a set of term sets that all share common security requirements. Only users who are designated as Contributors to a specific group can manage term sets that belong to the group or create new term sets within it.

Capacity Planning for Term Store (database) 

The following table lists the recommended guidelines for the organization of managed metadata in a Term Store:

Capacity-Planning-for-Term-Store.jpg

You can create multiple managed metadata services, and share multiple term stores and content types from multiple site collections. However, each managed metadata service must specify a different term store. When you specify a nonexistent database for the term store, a new database is created.

Term Store Management Tool

SharePoint Server 2010 includes the Term Store Management Tool, which you use to create and manage term sets. If you have the appropriate permissions you can use the Term Store Management Tool to:
  • Create or delete a term set.
  • Add, modify, or delete terms.
  • Arrange managed terms within a term set into a hierarchy.
  • Define synonyms.
  • Import terms.
  • Make enterprise keywords into managed terms by moving them into a term set.
Managed Metadata Column Limitations in SharePoint 2010

Some of the limitations of Managed Metadata Columns are mentioned here:
  • No InfoPath support
  • No SharePoint Workspace support
  • No support in Office 2007
  • Cannot Edit Managed Metadata values in Datasheet Mode
  • You cannot use the "Begins With" or "Contains" operators for filters in views
  • Cannot be used in calculated fields
  • Maximum of 250 terms selected per Managed Metadata Column
  • Taxonomy feature is not activated on the Blank Site Template
  • Cannot add a Managed Metadata Column through SharePoint Designer


Sharepoint Web Application Zones

    Zones provide different logical paths (URL's) to access the same web application. Multiple zone usage allows implementing different access and policy conditions for users. Zones provide a way of using different authentication methods for the same site. In Sharepoint, each web application has 5 zones:


  • Default
  • Intranet
  • Internet
  • Custom
  • Extranet                                                                                                                                                                   
Zones provide a method to partition users by: 
  • Authentication type (Windows Authentication/Kerberos)
  • Network zone (Intranet/Internet/Extranet)
  • Policy permissions (Allow or Deny Read-Write access)


Hiding SharePoint Ribbon Control from users



Add this to the head section on master page.

<style type="text/css">
div#s4-ribbonrow {
display:none;
}
</style>

<Sharepoint:SPSecurityTrimmedControl runat="server"
Permissions="AddAndCustomizePages">
<style type="text/css">
div#s4-ribbonrow {
display:block;
}
</style>
</Sharepoint:SPSecurityTrimmedControl>



This should hide the ribbon control.


Manage Web Applications Error : Object reference not set to an instance of an object.


I tried to extend an existing web application by selecting it and I got the below error.




Error

Object reference not set to an instance of an object.

Troubleshoot issues with Microsoft SharePoint Foundation.

Correlation ID: 419ad46b-8c99-4424-8fba-7b9b2d575e80

Date and Time: 11/9/2012 4:59:30 PM



I am not too sure why this happened.

But this went off after I did an IISRESET.


SharePoint Host Named Site Collections

So to begin with......what is a Host Named Site Collection (HNSC)


Host Named Site Collection (going forward, I will be using HNSC) is the best option if you want to create multiple root-level site collections within a web application. (i.e. unique URL for your site collections. Cool……right? That is what I thought so)

In SharePoint, we have support for both path-based & HNSC.The basic difference is: 

All path-based site collections in a Web application share the same host name (DNS name), whereas each HNSC in a Web application is assigned with a unique DNS name.

In simple words:
HNSC allows you to create as many root-level host-named sites within a single Web application.
http://newsite.customer.com
http://www.testhnsc1.com

With path-based sites, you are limited to a single root-level site collection within a Web application
http://www.fahad.com/sites/site1
http://www.fahad.com/sites/site2

So....yeah...we can have HNSC. But with it come some advantages and disadvantages.

Advantage/Dis-advantages:

Host Named Site Collection (HNSC)

·         We can have fancy URLs for our site collections. We have more control over URLs.


·         Host headers cannot be applied at the Web application (IIS site) level, and doing so makes it impossible to access HNSC.


·         HNSC have a single (unique) URL. So they do not support alternate access mappings and are always considered to be in the Default zone.


·         Most importantly Alternate Access Mappings don’t work with HNSC. You can't use both HTTP and HTTPS together.


·         It can scale to thousands of site collections because they can all exist within a single Web application and still offer vanity naming capability.


·         This helps in hosting multiple tenants on the same farm(multi tenancy)

Path-Named

·         All 5 zones are available for Path based sites. 

    
     ·         Alternate Access Mappings is very much supported (supports SSL)

   
     ·         User is limited to a single root-level site collection within a Web application

Powershell script for creating a HNSC 

Well, before executing the below powershell script, we would have to create a web application without Host header.

New-SPSite http://www.testhnsc1.com -OwnerAlias Domain\username -HostHeaderWebApplication <Web-App-URL>

Sharepoint Multi Tenancy and Host Name Site Collection

     Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multi-tenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multi-tenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance. Multi-tenancy is also regarded as one of the essential attributes of cloud computing.

The term multi-tenancy in SharePoint comes up if we are planning to host Sharepoint for different clients. Creating a large number for web applications causes resource problems. In such a scenario the best approach for companies hosting Sharepoint would be to opt for Host Named Site Collection (HNSC). I have already posted in detail on Host Named Site Collection (HNSC).

Hosting a Sharepoint environment for multiple tenants was a challenge before HNSC.This was because on the limitations on the number of web applications, managing site collections, data isolation problems and URL name space issues.
With HNSC it is now possible to have "vanity URLs" for site collections. For example ,we could havewww.fahad.com for one site collection and www.sharepoint.com on another - all in the same Web application.

But at the same time there are few things we need to be aware of. HNSC do not support alternate access mappings and are therefore always considered to be in the default zone. Moreover, host headers cannot be applied at the Web application (IIS site) level, and doing so makes it impossible to access host-named site collections (IIS tends to ignore requests that does not match host binding).
This creates a HNSC with the URL http://www.testhnsc1.com  in the SharePoint 2010 Web Application with the URL <Web-App-URL>


Configuring Sharepoint BLOB cache settings for a web application


To improve the end user response time a good approach is to configure the BLOB Cache on the SharePoint 2010 Web Front End (WFE) servers. The BLOB cache caches files on the WFEs disk to make it faster for IIS to retrieve the files and return them to the browser. It can also send some HTTP headers telling the browser to cache the file for a certain amount of time. By default, the disk-based BLOB cache is off and must be enabled on the front-end Web server if you want to use it. Use the following procedure to configure disk-based cache settings for a Web application.


1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

2. In Internet Information Services (IIS) Manager, in the Connections pane, click the plus sign (+) next to the server name that contains the Web application, and then click the plus sign next to Sites to view the Web application or applications that have been created.

3. Right-click the name of the Web application for which you want to configure the disk-based cache, and then click Explore. Windows Explorer opens, with the directories for the selected Web application listed.

4. Right-click web.config, and then click Open.

5. If the Windows dialog box appears, select Select a program from a list of installed programs, and then click OK.

6. In the Open With dialog box, click Notepad, and then click OK.

7. In the web.config Notepad file, find the following line: 
<BlobCache location="" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />

8. In this line, change the location attribute to specify a directory that has enough space to accommodate the cache size.To change the size of the cache, type a new number for maxSize. The size is expressed in gigabytes (GB), and 10 GB is the default. To enable the BLOB cache, change the enabled attribute, from "false" to "true".Save the Notepad file, and then close it.


Important 

- Before you make changes to the web.config file, make a copy of it by using a different name, so that if a mistake is made in the file, you can restore the original file.
- Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer to configure the BLOB cache settings.
- When you save a change to the web.config file, the Web application in Internet Information Services (IIS) 7.0 automatically recycles. This recycling can cause a brief interruption in service to sites contained in that Web application, and users can lose session state.
- It is strongly recommend that you specify a directory that is not on the same drive as where either the server operating system swap files or server log files are stored.
- To add or remove file types from the list of file types to be cached, for the path attribute, modify the regular expression to include or remove the appropriate file extension. If you add file extensions, make sure to separate each file type with a pipe (|), as shown in this line of code. 
- It is recommended that you not set the cache size smaller than 10 GB. When you set the cache size, make sure to specify a number large enough to provide a buffer at least 20 percent bigger than the estimated size of the content that will be stored in the cache.


How to display detailed Sharepoint errors for faster troubleshooting


Browse to the location where the web.config file is located for your web application.UsuallyC:\inetpub\wwwroot\wss\VirtualDirectories\80  (port number depend on where you have your web application)

Change these values from
<customErrors mode="On" />
And
CallStack="false"

to

<customErrors mode="Off" />
and
CallStack="true"

Save your web.config file. You will get detailed errors from now on.

SharePoint Managed Paths

SharePoint Managed Paths

“A managed path is a location within a web application in which you can have site collections.”

 1.    Managed paths are used to define the location of every site collection inside of SharePoint.
2.    Managed paths follow the same concept as a virtual directory in IIS however they are handled directly by SharePoint.
3.    A managed path defines a sub-directory in your application which you can use as a url for a site collection.
4.    By default SharePoint 2010 creates 2 managed paths when you make a new web application and sites. 
5.   

The dialogue below allows you to create managed paths and can be found in the ribbon menu for web applications in central admin.


There are 2 types of managed paths you can create:

Explicit Paths
These are used if you want to place a site collection directly at the sub-directory you specify. For example if you want a site collection at http://site/bob you would use an explicit path.

However explicit paths may only contain a single site collection.

Wildcard Paths
A wildcard path is used if you want to have multiple site collections under a path. For example http://site/projects/project1 andhttp://site/projects/project2.

Wildcard paths can only have site collections below the path (ie no site collection at http://site/projects)
Few Key points
1.   Managed Paths allow SharePoint to determine what portion of a given URL corresponds to the "site collection URL".
2.   Managed Paths can be defined per web application (and cannot be defined for host headersite collections)
3.   Managed Paths can be "Explicit" or "Wildcard"
4.   Explicit Managed Paths allow a single spsite to be created at exactly the given url
5.   Wildcard Manage Paths allow unlimited spsites to be created under the given url – no spsite can be created at exactly that URL.
6.   Limit your managed paths to <20 per web application 

What is a managed path in SharePoint?

Answer

“A managed path is a location within a web application in which you can have site collections.”

There are two types of managed paths:
1.     An explicit inclusion managed path defines an exact path to which a site collection can be directly attached.
2.     A wildcard inclusion managed path defines a path that cannot have a site collection attached at its root but can have multiple site collections assigned beneath it.

Question

Why use a managed path in SharePoint?

Answer

“You would use a managed path in SharePoint to categorize, organize or group together site collections.”

First, if you are an organization with only one site collection, you can pretty much skip this entire post. Although even if you have only one site collection you are still ‘technically’ using a Managed Path, understanding managed paths in SharePoint 2010 are useful for farms that will have at least a few or many site collections and want to keep them in some type of structured or organized placement.
SharePoint uses the managed path to determine which content database the URL a user entered is in. Every URL request that comes into your server actually looks at the URL structure, looks up the managed paths listed in Central Admin, then routes the request to the proper database to retrieve the content. Knowing this, the more managed paths you add, the slower the performance so try to keep the number at a minimum (>20).
Another reason to use managed paths is to keep structure and organization in where you place your site collections. For example, if your IT department has several divisions, and each division wants their own site collection for security and “power hungry control freakish” reasons, you would want to make a managed path called IT. You can then create a site collection under this for each division, such as:
http://ourIntranet.com/IT/Infrastructure
http://ourIntranet.com/IT/SharePointTeam
http://ourIntranet.com/IT/OracleTeam
This organizes the site collections for each IT division into a sensible manner.
Understanding Managed Paths in SharePoint 2010 isn’t so easy at first look, hopefully this gives you a clearer understanding of their purpose and if your organization will have the need to utilize them. True that.

 Understanding Sharepoint Managed Paths


When we create Site Collections in Sharepoint web applications, they are created with URL as 

http://servername:port/site/

To have a specific URL other than /site we would have to create a Managed Path.

When we create a Managed Path, we have two options:   Explicit Inclusion
                                                                                    Wildcard Inclusion

So what is the difference? I am going to guide you on what exactly is a managed path. Be with me. 

1) Browse to Central Administration -> Applications Management -> Manage Web Application

2) Choose the web application where you want to implement managed paths.

3) Select Managed Paths from the ribbon



4) I am adding two new paths      - fahadexplicit (for type Explicit inclusion)
                                                 - fahadwildcard (for type Wildcard inclusion)


5) Now browse back to Application Management -> Create Site Collections.

6) You would see your custom Managed paths there.

Explicit Inclusion:

When we are not planning to create further site collections under a specified managed path, then we use this option. Explicit Inclusion Managed paths allows in creation of only one site collection at the exact given URL.
In our case fahadexplicit would be the only site collection that can be created. SharePoint will allow creating only one site collection within this Managed Path.

The URL would be: http://servername:port/fahadexplicit



Wildcard Inclusion:

When we want to create more than one site collection under a specific managed path, we use this option. Wildcard Inclusion Managed Paths allow unlimited site collection to be created under a given URL.
In our case under fahadwildcard, we can create any number of site collections.

The URL of these site collections would be as below:

http://servername:port/fahadwildcard/sitecolelction1
http://servername:port/fahadwildcard/sitecolelction2
http://servername:port/fahadwildcard/sitecolelction3
http://servername:port/fahadwildcard/sitecolelction4



and so on.

Programmatically create Managed Paths in SharePoint 2010

Introduction:
Managed Paths - We can specify which paths in the URL namespace of a Web application are used for site collections. We can also specify that one or more site collections exists at a specified path.
 
Types of Managed Paths:
  • Explicit inclusion.
  • Wildcard inclusion.
Explicit inclusion:
An explicitly named path is used for a single site collection.

Example: http://server/sites/team.

Wildcard inclusion:
A wildcard path of "sites" indicates that child URLs of the path are site collections. An wildcard named path is used for a multiple site collections.

Example: http://server/sites/

In this article we will be seeing the following
  • Programmatically create managed paths
  • Programmatically get all the managed paths for a web application
Programmatically create managed paths:
  • Open Visual Studio 2010.
  • Go to File => New => Project.
  • Select the console application template.
  • Add the following references.
    • Microsoft.SharePoint
  • Add the following namespaces.
    • using Microsoft.SharePoint;
    • using Microsoft.SharePoint.Administration;
  • Replace Program.cs with the following code.
using System;using System.Collections.Generic;using System.Linq;using System.Text;using Microsoft.SharePoint;using Microsoft.SharePoint.Administration; namespace ManagedPath
{
    class Program    {
        static void Main(string[] args)
        {
            string path = "Bangalore";
            SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://serverName:1111/"));
            SPPrefixCollection prefixColl = webApp.Prefixes;
            if (prefixColl.Contains(path) == false)
            {
                SPPrefix newPrefix = webApp.Prefixes.Add(path, SPPrefixType.ExplicitInclusion);
                Console.WriteLine(path+" is successfully added to the web application");
            }
            else            {
                Console.WriteLine(path + " already existe in the web application");
            }
            Console.ReadLine();
        }
    }
}
  • Build the solution.
  • Hit F5.
Output:
  • Go to Central Administration => Application Management => Manage Web Applications.
  • Select the web application, click on Managed Paths available in the ribbon interface.

    Untitled-2.gif
  • "Bangalore" managed path is created successfully.
Programmatically get all the managed paths for a web application:
Code:
using System;using System.Collections.Generic;using System.Linq;using System.Text;using Microsoft.SharePoint;using Microsoft.SharePoint.Administration; namespace ManagedPath
{
    class Program    {
        static void Main(string[] args)
        {
            SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://serverName:1111/"));
            SPPrefixCollection prefixColl = webApp.Prefixes;
            foreach (SPPrefix prefix in prefixColl)
            {
                Console.WriteLine("Managed Path :{0}, Prefix Type :{1}", prefix.Name, prefix.PrefixType);
            }
            Console.ReadLine();
        }
    }
}

Output:

Untitled-3.gif

To create, get and delete the managed paths for a web application using PowerShell refer 

http://www.c-sharpcorner.com/uploadfile/anavijai/5355/.