SharePoint solution to deploy InfoPath Form template as administrator approved form template

An InfoPath form template can be published into SharePoint in many ways. Below are the options available to you when you try to publish an InfoPath Form from Microsoft Office InfoPath application.

• Form Library: You can publish the info path form template as a template in a form library.
• Site Content type: You can publish this form template into a library in a site collection which will then be accessible by a content type. This content type can be used by multiple libraries.
• Administrator approved form template: Administrator can upload the form template in central admin form template gallery which can then be enabled into a specific site collection. When a template has been activated in a Site Collection, a copy of the template is stored in Site Collection “Form Templates” library which can be used by multiple sites, libraries within that site collection.

There might be times when you would want to be able to deploy/activate these form templates automatically via a SharePoint solution eliminating the manual processes. In this post, I will show you how you can package an InfoPath Form template into a WSP solution file and deploy it as administrator approved template. This will automatically, upload the template into the Central Admin Form Template gallery and also activate that form template to a Site Collection.

Tools: Microsoft Office InfoPath Designer 2010, Visual Studio 2010 Professional, SharePoint Server 2010

1) Create a new blank form using InfoPath Designer 2010 and add some controls to it. Mine looks like this.

2) Go to form options and in the security section, set the security level to “Domain”. Read more about the security level here.

3) Then you need to publish the form template. Mind you that we are not going to publish this form template directly into SharePoint server. This form template will be automatically published into SharePoint by our solution. So, we will publish this form template into a network location and include it in our SharePoint Solution.

Go to Publish section in InfoPath Designer and choose “Network Location”.

Select the published path with filename. Then go to next step.

Leave the input textbox blank and select next. You will receive a warning but you can ignore it for now.

After publish, you will get a screen like this.

4) You can now verify if this template can be uploaded into SharePoint server using “Upload form template” in central admin site.

select the published form template and then click verify. You should receive a message stating that the template is ready to be uploaded to the server.

5) Create a SharePoint 2010 project in Visual Studio 2010 and select “Module” to be added.

6) Opt to deploy as a farm solution

7) I’ve changed the name of the feature to “InfoPathDeploymentFeature”, “Module1” to “InfoPathFormModule” and also removed the default sample.txt file from the module.

 Add the published InfoPathForm.xsn file, one we created earlier, under the “InfoPathFormModule” element. Select the xsn file and in the properties windows, under “Deployment Location” property, clear the path value. The Elements.xml file now looks like this.

9) Change the scope of the feature to “Site”. 

10) Double click the feature and in the properties window, set the values for “Receiver assembly” and “Receiver class” as below.

Receiver Assembly: Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

Receiver Class: Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver

11) Check the SharePoint url where you are deploying this feature. Make sure that the feature “SharePoint Server Enterprise Site collection features” is already activated in that site. You can add feature activation dependency also.

12) Then in the packaging explorer, select the module “InfoPathFormModule”. Then you can add features properties from the properties window. These are very important, if you do not add them, the form will not be uploaded in central admin form templates gallery. The manifest will then look like this.

13) Buid and deploy the project.

Check the form templates in the central admin at this locaiton: Central Admin->General Application Settings->Manage form templates. you will see that the template has been uploaded.

You will also notice this form template has already been activated to the site collection where we deployed the feature.

Go to Site Settings->Site Content Type, you’ll see that a content type by the name “InfoPathForm” has been automatically created. This means that now, we can just add this content type into a form library which we can use to fill out our info path form through browser.

So create a new form library, change it to allow management of content types, and add the “InfoPathForm” content type to that library. The settings of content type will now look like this.

You will now see a new content type option available when we create new document which will open our infopath form in browser. But to enable the infopath forms to be displayed in browser, you need to configure the form library which you can do by setting the value of “Openinig document in browser” to “Open in browser” in settings of the library.

14) Lastly, click on the new content type in form library, which will open the info path form in a web page.

I have also uploaded the Visual Studio 2010 Project which you can downloaded. Also, I will follow up on this post with other enhancements like feature receiver that will automatically add InfoPath content type to form library, promoting InfoPath Form fields into form library columns etc.

Reference: http://sandeepnakarmi.com.np/2011/03/sharepoint-solution-to-deploy-infopath-form-template-as-administrator-approved-form-template/

Customizing the user experience: Overview of the default interface

Refer:
http://sharepointmagazine.net/series/sp-userexperience

Customizing search
http://sharepointmagazine.net/series/customizing-sharepoint-search

Introduction to SharePoint Feature Stapling

Features allow you to add new functionality to SharePoint or make simple site customizations in an easy and consistent way. Features can be scoped to the Farm, Web Application, Site, and Web level depending on the purpose of the feature. The basis of a feature is implemented using a feature.xml file, but may also contain other supporting files. More information on Features can be found on the Microsoft MSDN site at http://msdn.microsoft.com/en-us/library/ms460318.aspx.
The focus of this article is going to be on a concept called Feature Stapling. Most, if not all, SharePoint developers know that Microsoft frowns on modifications to the “Microsoft” owned files that support SharePoint. If you modify these files you run the risk of your changes being broken with the installation of a service pack or hot fix. Sometimes this was your only option when attempting to customize SharePoint back in the WSS 2.0 days. The following KB article that outlines the supported / unsupported scenarios when it comes to modifying the default site definition files (http://support.microsoft.com/kb/898631).
Feature Stapling allows you to create a feature and then associate it with any site definition without ever touching the site definition files themselves. Your feature will be executed when the site is being provisioned.
As you read this series of articles I hope to explain how Feature Stapling works through the creation of a working feature and feature stapling example. I will also touch on some important points and considerations you need to be aware of about when in the life cycle of a site being provisioned your feature will be executed.

Feature Stapling

Feature Stapling is achieved through the creation of another feature that defines the association of your regular Feature and the site definition you want to “staple” it too. In other words, you need to create two Features to achieve a complete Feature Stapling implementation.

Creating Feature

There are many different recommendations on how to go about creating SharePoint Features within Visual Studio from the layout to the deployment. In this article, I am going to use the method that works best for me. I use Visual Studio 2008, a class library, and WSP Builder (http://www.codeplex.com/wspbuilder). WSP Builder is what I ultimately use to generate my solution file; however, it does have some features such as Copy to 12 Hive, and Recycle Application Pools that I used while creating my Feature.
In this scenario, I want to capture the Title and URL of any site that was created using the Team Site template in a central location.
Step 1: Create the 12 hive folder structure down to my actual Feature, created a strong named key, and added a reference to the Microsoft.SharePoint.dll assembly.
The following is a screen capture of my project in Visual Studio:

Step 2: Add a new class file in the root of the project folder called SampleFeatureReceiver.cs and use the following code:

using System;
using Microsoft.SharePoint;
 
namespace Liebrand.Sample
{
    public class SampleFeatureReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            using (SPWeb web = (SPWeb)properties.Feature.Parent)
            {
                if (web.IsRootWeb)
                    return;
 
                using (SPSite site = web.Site)
                {
                    using (SPWeb rootWeb = site.RootWeb)
                    {
                        SPList createdSites = GetProvisionedSitesListId(rootWeb);
                        SPListItem newItem = createdSites.Items.Add();
 
                        newItem["Title"] = web.Title;
                        newItem["Url"] = web.Url;
                        newItem.Update();
                    }
                }
             }
        }
 
        private SPList GetProvisionedSitesListId(SPWeb rootWeb)
        {
            try
            {
                SPList list = rootWeb.Lists["Provisioned Sites"];
                return list;
            }
            catch (ArgumentException)
            {
                Guid listId = rootWeb.Lists.Add("Provisioned Sites",
                    "This list contains all the sites that have been provisioned.",
                    SPListTemplateType.GenericList);
 
                SPList list = rootWeb.Lists[listId];
 
                list.Fields.Add("Url", SPFieldType.URL, false);
                SPField field = list.Fields["Url"];
 
                SPView view = list.DefaultView;
                view.ViewFields.Add(field);
                view.Update();
 
                list.Update();
 
                return list;
            }
        }
 
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

This code basically adds the URL of the site being provision to a listed called Provisioned Sites that is located in the root site. If the list is not found, the list is created.
Step 3: Add a new XML file called feature.xml to the feature folder and paste the following contents:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/"
         Id="2B3451F0-BC93-41A4-9FAD-3A81861D651A"
         Title="Liebrand Feature Sample"
         Description="This is a feature that will be used to demonstrate feature stapling."
         Scope="Web"
         Hidden="False"
         Version="1.0.0.0"
         ReceiverAssembly="Liebrand.Sample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=057a20dd10f3b267"
         ReceiverClass="Liebrand.Sample.SampleFeatureReceiver">

Note: The Id attribute value was generated using the Create GUID menu item from the Tools menu in Visual Studio.

Creating the Stapling Feature feature

At this point, our primary Feature is ready to go. The last step is to simply create another Feature that will associate my LiebrandSample Feature with the Team Site site definition.
Step 1: Add another folder under the FEATURES folder called LiebrandSampleStapler and add a file called feature.xml then paste the following contents into it:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/"
         Id="C384D136-79A8-48BD-AF73-C630547F4D8E"
         Title="Liebrand Sample Stapler"
         Description="This feature staples the LiebrandSample feature to the Team Site site definition."
         Scope="Farm"
         Hidden="False"
         Version="1.0.0.0">

  
    "elements.xml" />
  

Step 2: Add a XML file called elements.xml to the LiebrandSampleStapler folder and paste the following:

"1.0" encoding="utf-8" ?>
"http://schemas.microsoft.com/sharepoint/">
  "2B3451F0-BC93-41A4-9FAD-3A81861D651A"
                                  TemplateName="STS#0"/>

The ID attribute in the FeatureSiteTemplateAssociation element should match the ID of the Feature we created at the beginning of this article. The TemplateName attribute should match the site definition name and configuration ID found in the webtemp.xml file located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML. Since we want to associate our new Feature to all Team Site sites we specify STS#0. STS is the name of the Template and 0 is the configuration ID for the Team Site.
At this point we are ready to deploy our new features and test it out.

Deployment

First build your project to insure you have no build errors and to generate the assembly Liebrand.Sample.dll.
To deploy these new Features using WSP Builder simply,

• Right-click on the project name and select WSPBuilder, then click Copy to GAC. This will copy the assembly into the Global Assembly Cache.
• Right-click on the project name and select WSPBuilder, then click Copy to 12 hive. This will copy the 12 hive folder structure in your project to the SharePoint 12 hive folder

• Install and activate the Features by running the following commands:

stsadm -o installfeature -name LiebrandSample
stsadm -o installfeature -name LiebrandSampleStapler

Test

At this point you can create a new sub-site using the Team Site template and you should see a new list called Provisioned Sites get created at the root site with a new entry added that will point back to the site you created.
After creating 3 team sites, this is what the Provisioned Sites list looked like:

Welcome to part 2 of my Introduction to SharePoint Feature Stapling. In part 1 I explained the process of creating a feature stapler and associating it with a site definition. In this small post, I’ll be providing some insight into the feature stapling lifecycle and also providing some potential solutions to some of the downsides of the feature stapling process.
Feature Stapling Lifecycle
The actual lifecycle of the feature stapling process is not documented actually documented anywhere. The following information has been solely gathered based on my testing and experimenting with the process.
If we step back and look at a site definition file we know that the GLOBAL#0 site template is applied to all site definitions. Many of the Microsoft provided site definitions enable functionality through the use of the feature system. If you open up the STS site definition ONET.XML file, you will see two sections near the bottom called SiteFeatures and WebFeatures:

You will notice that in many of the Windows SharePoint Services site definition files the ListTemplates section is not populated with anything; they use list definition features instead. As you can see, the Team Site site definition points to a feature called TeamCollab. This feature makes list definitions available to the web that is being created.
So what does this all mean when it comes to feature association? The important thing to remember here is that any feature receivers you develop and associate to a site definition will get executed before any of the lists on that site have been provisioned. However, anything provisioned via the Global Site Definition will be available to your feature receiver.
This is not a problem if you simply want to create new lists, libraries, etc. However, if you are attempting to manipulate any lists that are part of the site definition you are associating with you will find yourself looking at a System.ArgumentException stating “Value does not fall within the expected ranged.”
The following image shows what happens when I create a Team Site that has my custom feature receiver associated to it:

Solution
We have already determined that feature receivers make it extremely easy for a developer to extend and customize out of the box site definitions without touching the files. But we run into a road block when we attempt to customize the lists and libraries that are part of that site definition.
One way I have used to get around this is to simply delay the customizations until after the site has completely provisioned.
The following is an example using the ThreadPool.QueueUserWorkItem method:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    using (SPWeb web = (SPWeb)properties.Feature.Parent)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(RunProcess), web.Url);
    }
}
 
private void RunProcess(object state)
{
    Thread.Sleep(5000);
 
    string url = (string)state;
    using (SPSite site = new SPSite(url))
    {
        using (SPWeb web = site.OpenWeb())
        {
            // at this point, the site should be provisioned
            // and we will now have access to all lists on it
            SPList list = web.Lists["Shared Documents"];
            list.Description = "Updated from Feature Receiver";
            list.Update();
 
        }
    }
}

Why are we running on a different thread? Well, this allows the site provisioning process to complete and then we come back in a few seconds later to customize it as needed. Of course, the sample above is not 100% perfect. What happens if it takes 10 seconds to provision a site – well the method above would fail out.
A more elegant way would probably be to check the SPWeb.Provisioned property which is False until after the provisioning process has completed; but you get the general idea

Summary

Features Stapling offers a great way for developers to extend, change, or customize the out-of-the-box site definitions without ever touching them. Hopefully this article gives you an idea of where you can utilize Feature Stapling. In the next article of this series, I am going to cover when Feature Stapling occurs in the creation of a site and some key points you need to be aware of when it comes to what elements are available to you when your feature is executed.

Silverlight in SharePoint – Basics of Hello World!

I’m going to build a Silverlight application that can be hosted from within a SharePoint web part. We will use Visual Studio 2010 to build a simple “Hello World” type application, but add a few touches to make our application configurable.
In SharePoint 2010, we have an out of the box Silverlight web part that can host almost any Silverlight application. For now, we will utilize this built-in web part and later in the series, we will create our own web part to host our applications.
The Silverlight application in this example asks the user to enter 3 words. The words can also be configured through the Properties of the web part. These words will be passed to the Silverlight application, which will render these words in an animated way.

Developing a Simple Silverlight application

You can create a simple Silverlight 4 application using Visual Studio 2010. If you need more complex design you will need tools like Microsoft Expression Blend, but the sample Silverlight application for this article can easily be build in Visual Studio 2010 using the Silverlight Application template.
When creating a Silverlight application with Visual Studio 2010, you will be asked which version of Silverlight application you want to design. For this sample I selected Silverlight 4. You can also indicate whether you want to create a test web site or not. As the sample needs to communicate with SharePoint, it cannot be easily tested running outside the SharePoint context, so I choose not to host the Silverlight application in a web site.

When a Silverlight application is created, the following parts are automatically added to the project:

App.xaml	The App.xaml file is typically used to declare resources that can be used throughout the application. These resources consist of brushes, styles and animations.
App.xaml.cs	The App.xaml.cs file is the code behind file for the App.xaml and can be used to handle application level events. There is already a method stub for the Application_Startup, Application_Exit and Application_UnhandledException events available. When the Silverlight application initializes the Application_Startup event is triggered. I typically use this event handler to retrieve the incoming parameters.
MainPage.xaml	The MainPage.xaml file is by default the initial UI control. Within this UI control you can start defining the user interface.
MainPage.xaml.cs	The MainPage.xaml.cs file is the code behind for the MainPage.xaml. The events generated in the UI control are handled here. You can also dynamically load controls in code behind and consume WCF services, or communicate with SharePoint using the Silverlight Client object model.

Besides these parts a Silverlight application can also contain other user controls, other classes and interfaces.
The point of entry of the Silverlight application is the Application_Startup method. The StartupEventArgs argument contains information on how to initialize the Silverlight application. One of these elements is the InitParams dictionary. It can be used to pass information from SharePoint to Silverlight.
The Silverlight application in this sample accepts 3 words that will be rendered using storyboards. The values are stored in static variables that can be accessed form within the different controls that make up the Silverlight application .

public static string Word1 = null;
    public static string Word2 = null;
    public static string Word3 = null;

The Application_Startup method looks as follows:

private void Application_Startup(object sender, StartupEventArgs e)
    {
        if (e.InitParams != null)
        {
            Word1 = GetParam(e.InitParams, "word1");
            Word2 = GetParam(e.InitParams, "word2");
            Word3 = GetParam(e.InitParams, "word3");
        }
        this.RootVisual = new MainPage();
    }
    private string GetParam(IDictionary<string, string> initParameters,
        string paramName)
    {
        if (initParameters.ContainsKey(paramName)&&         
            ! string.IsNullOrEmpty(initParameters[paramName]))
        {
            return initParameters[paramName];
        }
        else return null;
    }

The last statement in the Application_Startup method shown above initializes the main user control of the Silverlight application. The XAML of this control is very simple and contains the following elements:

• a Canvas: this is the root control of the user control.
• 3 TextBox controls: these will be populated with the words passed in
• 3 Storyboard elements: these element are responsible for making the words mover over the screen from bottom to top.
• a Circle which represents the dot of the sentence.
• a fourth Storyboard that will move the dot over the screen as flying comet.

The code behind of the MainPage user control is stored in the MainPage.xaml.cs file and starts storyboard after storyboard: when the first storyboard finishes, the second is started and so on. The following code snippet demonstrates this technique:

private void StartAnimation()
{
   Word1TextBlock.Visibility = Visibility.Visible;
   Storyboard sb = (Storyboard)this.FindName("MoveWord1");
   if (sb != null)
      sb.Begin();
}
private void MoveWord1_Completed(object sender, EventArgs e)
{
   Word2TextBlock.Visibility = Visibility.Visible;
   Storyboard sb = (Storyboard)this.FindName("MoveWord2");
   if (sb != null)
      sb.Begin();
}

That’s it for the code in the Silverlight application.

The Silverlight Web Part

Now it is time to deploy the Silverlight application to SharePoint. The easiest way is to upload the .xap file to a document library. In this demo I’ll upload it to a document library with the name XAPS. SharePoint 2010 comes with an out of the box Silverlight web part. You can add this web part to any SharePoint page and host your Silverlight application from within it. You can add this web part to for example the home page. When in the Web Part Gallery, you can find the Silverlight web part in the Media and Content category.

When you choose to add a Silverlight web part to your page, a dialog pops up asking you to enter the location of your Silverlight application.

In the editor part of the web part you can enter the initParams string requested by your Silverlight application. In this sample you have to pass the name of the list where the service offerings are stored. Scroll down in the editor part and expand the Other Settings section. There you can enter your initialization parameters. If you have a parameter to pass, you have to specify the name of the parameter followed by an equal sign and the value:

param1=value1

If you have more than one parameter to pass, you’ll have to separate them with a comma:

param1=value1,param2=value2

Pay attention not to add spaces in between. The maximum length of this string is 255 characters. If you need to pass more data, you’ll have to use a workaround. These workarounds will be explained in further articles of this series.
Our parameter string exists of 3 words:

The initialization parameters are passed to the Silverlight application as a comma separated string but inside the Silverlight application it comes in as a dictionary as a property of the StartupEventArgs argument of the Application_Startup method.

Once you set the initialization parameters you can click the OK button of the web part. The Silverlight application will rendered on the page.

If your Silverlight application doesn’t show on the page, it is possible you have typed an error in the path to the Silverlight application, you can always correct by editing the web part and clicking the Configure button in the Properties pane.

SharePoint 2010 Site Templates

 list of the templates you get with SharePoint Server 2010. For SharePoint Foundation 2010, you’ll only find a subset of what you see here (but there’s nothing Foundation has that Server doesn’t). Also there are some templates that will only appear after activating certain site or site collection features. I’ll cover some of those in a bonus post later. Clear as mud?Creating Sites
When you create a new site you’ll see the new create dialog like the one below (there’s a regular HTML version but you really want to install Silverlight on your client to get the rich UI experience).

Each category along the site lets you filter down the template selections and selecting any template gives a brief description to give you an idea of what the template is about.
Here’s the rundown on what’s available out of the box (and what is covered in what blog post):

• Blank & Custom
• Blank Site (This Post)
• Personalization Site (Part II)
• Collaboration
• Team Site (This Post)
• Document Workspace (This Post)
• Group Work Site (This Post)
• Enterprise Wiki (This Post)
• Content
• Document Workspace (This Post)
• Blog (This Post)
• Document Center (Part II)
• Publishing Site (Part II)
• Publishing Site with Workflow (Part II)
• Enterprise Wiki (This Post)
• Visio Process Repository (Part II)
• Data
• Records Center (Part II)
• Meetings
• Basic Meeting Workspace (Part IV)
• Blank Meeting Workspace (Part IV)
• Decision Workspace (Part IV)
• Social Meeting Workspace (Part IV)
• Multipage Meeting Workspace (Part IV)
• Search
• Basic Search Center (Part II)
• Web Databases
• Assets Web Database (Part III)
• Charitable Contributions Web (Part III)
• Contacts Web Database (Part III)
• Issues Web Database (Part III)
• Projects Web Database (Part III)

There’s some duplication above in the categories but out-of-the-box you get 23 templates (3 new site templates, 5 new site templates based on Access databases). For more details about what’s been added, removed, and updated as far as templates go please see Todd’s original post.
Select a template, enter a title and a url, and click Create and you’re off to the races. If that’s all you need you can be creating sites in no time. Each template has it’s share of not only a look and feel, but also what content is pre-loaded on the site and in some cases, what features are activated as a result of creating that site which light up the site and offer the user some options. For the most part any feature on the system can be applied to any site so it almost doesn’t matter what template you start with, but there are some exceptions and we’ll note them as we go along.
If you want a little more control when you create your site, clicking on More Options brings up a second dialog that lets you enter, well, more options:

The options are the same no matter what template you choose and I couldn’t find any way to build something that would you let amend options here. Would be nice in the future. The only real advantage here is that you can break permissions on the site before it gets created and use the top link bar from the parent site (which is turned off by default for new sites). Any of these can be done after the site is created anyways.
Note that these dialogs appear in a popup when you select Create Site from the Site Actions menu. If you go the route of Site Settings > Site Administration > Sites and Workspaces then click Create you’ll see this screen in the browser (not a popup):

This is the more traditional screen you might be used to from 2007. The templates and choices are all the same and this screen offers changing all options, much like the More Options dialog from above. How you create your sites is up to you, typical SharePoint there are just several routes to get to the same path.
Alright, let’s get down and dirty with each template.
Blank Site
“A blank site for you to customize based on your requirements.”

The core of any SharePoint site, the blank site. So simple and elegant yet devoid of any content. Basically a site you can turn into anything by lighting it up with features. Personally when we build “applications” in SharePoint this is the template we start with. The big difference from the “Blank” site template you got in 2007 is that this one really is blank and doesn’t come pre-loaded with a SharePoint logo dropped on your “blank” site like 2007 did.
Team Site
“A site for teams to quickly organize, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks, and discussions.”

This template is perhaps one of the most used since SharePoint started using templates. Most everyone uses SharePoint for collaboration so this is one of the original collaboration tools out there. In 2010 many things are the same as they were in the 2007 Team Site template. You still have a Shared Documents library, a Calendar has been created, a Task list and a Team Discussion discussion board is here. With 2010 there are some major changes though that make it arguably a better collaborative environment it ever was.
First off everything is a wiki. Keep remembering that. Everything is editable. Remember when you created that first Team Site in 2007 and you wanted to start editing the page but found out you had to drop a content editor web part on the page, open up the right text editor, type something in, then click a few buttons to see what it all looked like? That’s not collaboration. That’s just plain painful.
The Team Site template, along with others, treats any page as a content page. Just click edit and start typing content. Want a picture on your site? Drop a media web part on it and upload it to the automatically created Site Assets library while you edit. Collaboration has never been as simple as this.
Getting back to the template itself, you’ll notice a few new libraries created. There’s a new Site Assets library which allows you to upload media (pictures, video, audio) to the site and use it on pages via the Media Web Part. There’s a Site Pages library that contains all your pages (including the home page) so as you create new content, just drop it in here. The Announcements, Calendar, Links, Tasks, and Discussions you got in 2007 are still created, they’re just not visible on any page so you’ll have to either add them yourself or use the Quick Launch to access them.
Note that the Getting Started section that’s added to the site is just content. It’s not a list behind it, it’s just HTML content that you can edit, delete, or use.
Document Workspace
“A site for colleagues to work together on a document. It provides a document library for storing the primary document and supporting files, a tasks list for assigning to-do items, and a links list for resources related to the document.”

The document workspace is pretty cheesy and basically a carry-over from 2007. It was always intended to be a site where you would collaborate around a single document (aggressively) and I always thought it would well in a publishing environment. Create the document, everyone works on it, there are discussions around it and tasks assigned to take care of parts of it.
There were even facilities in Word to attach the document to a workspace (or create the workspace) when you saved the document. However say in the last 5 years I have yet to create a site with this template, other than demos (and this blog post). Perhaps it could still work for say a manuscript with multiple authors or a manual or training guide but I think 2010 has more to offer with Document Sets than to use this aging template.
At least they got the Announcements web part on the home page.
Group Work Site
“This template provides a groupware solution that enables teams to create, organize, and share information quickly and easily. It includes Group Calendar, Circulation, Phone-Call Memo, the Document Library and the other basic lists.”

If you remember 2007, there was an after-market release called Group Workspace Board. It was a Microsoft template and offered the ability to essentially create an in/out board site. Trouble is that it didn’t work very well, service packs sometimes broke it (or the server) and it was never upgraded. Well, it’s back (although I’m sure they rebuilt it from scratch so pay no attention to the comments above). Basically the Group Work Site is a uber-enhanced blank site with some content added (after all, isn’t that what *all* sites are?).
The Group Board is a pretty slick template and centers around a group calendar, which is really just a normal calendar but the regular Event content type has been removed and replaced with two new content types for 2010, Schedule and Reservations and Reservations. Basically if you’re looking to use SharePoint for a reservation system (reserving fleet vehicles, meeting rooms, books, or anything you want to track) then this template might work for you. At the very least, create one to see how the Group Calendar is setup and you can rebuild your own in your own site. It’s a nice Content Type that probably deserves its own post as there are a lot of great features you can get out of it.
Note that because the Group Calendar is really just a Calendar, you can connect it to Outlook but if you’re looking to use SharePoint as a meeting reservation system tied into the resources available in Outlook (like you might today) you’ll be out of luck. The two are not connected but they use the same terms so you might get confused over using them for the same purpose.
Enterprise Wiki
“A site for publishing knowledge that you capture and want to share across the enterprise. It provides an easy content editing experience in a single location for co-authoring content, discussions, and project management”

Remember everything is a wiki? Good. You’re still reading. Well, everything is a wiki but there’s still a template with the name Enterprise Wiki. I guess sticking “Enterprise” in front of something makes it that much more important?
The Enterprise Wiki is pretty much what you got in 2007 when you created a Wiki site. The old Wiki site template is gone and this stands in it’s place. Even though you can edit any page on a site, this template is specifically setup for building a wiki. While it can’t compete with Wikipedia, Confluence, or any of the *real* enterprise wiki’s out there it’s a nice place for putting together group notes about a subject. You could put together a blank site and just keep creating pages but then there’s the navigation element and having to deal with inserting hyperlinks onto pages, etc. The Wiki template stays true to the (albeit weird non-standard) Wiki mark-up SharePoint established in 2007 and lets you cheerfully link pages together with a simple [[My New Page]] mark-up.
In addition to what we already had in 2007, there are some new features that light up the Enterprise Wiki template. Namely ratings and categories. The rating system is the same that’s built into 2010 but it’s embedded on each page template along with a category picker. This allows you, after adding content to a larger site, be able to navigate content by popularity or categories (configured through the managed metadata services).
While the mark-up hasn’t changed much, a wiki page is just like any other page in SharePoint so you can embed pictures, video, tables, web parts, and SharePoint lists right onto the page. This makes the experience of building out a knowledge base using the Enterprise Wiki a more palatable experience and lets you be a little more creative without being overly constrained.
Blog
“A site for a person or team to post ideas, observations, and expertise that site visitors can comment on.”

Blogs are like wikis in SharePoint. They’re just OK and better than editing content editor web parts, but still fall short of a full blown blogging engine like dasBlog or WordPress. However in 2010 things have got a little better (don’t get too excited, I said a “little” better).
Overall the presentation is cleaner, looking more like a blog like we traditionally know it. Permalinks are native now and overall the blog template sucks a little less than 2007. Instead of editing the blog page right on the site, you’re forced to edit in a popup window with a diminished rich text editor. You can still insert images and video but it’s a little less seamless when you edit blog posts this way. Still the basics are there, categories and comments, RSS feeds and the ability to edit your blog from a blogging tool like Windows Live Writer or even Microsoft Word (and publishing from Word while giving an uneasy odd feeling, sucks a little less than it did).
While things are better than their 2007 counterparts you might still want to look at the Community Kit for SharePoint – Enhanced Blog Edition or customize the existing blog template if you want to focus on blogs in your organization. There are a lot of features in SharePoint 2010 that are native that really should be stock with the blog template. Why can’t I rate blog entries? Where are the tagging features? These things can all be done relatively easy even from the browser with no coding required. Just remember to save the template and make it available to your users (time for an Enterprise Blog template anyone?).
Wrap-up
Well, that’s it for now to get the ball rolling. Let me know your thoughts. Hope that gets things going and helps out. More templates to come later! Enjoy.

Configuring My Site in SharePoint 2010

SharePoint My Sites are commonly referred to as “Facebook for the enterprise” and are personal site collections providing each user with the ability to store private and public information such as documents, pictures, status updates, etc easily and efficiently.  My Sites in SharePoint 2010 takes social enterprise computing to the next level and builds upon what we have come to love in previous versions.  Microsoft saw the need to continue to invest and enhance SharePoint’s social networking capabilities, and as web 2.0 technologies continue to sprawl all over the world wide web, Microsoft have again successfully set the bench mark in the enterprise by introducing an array of social computing features to enhance end user collaboration in SharePoint 2010.
In my last article I introduced and configured our first service application for our SharePoint 2010 deployment, User Profiles, which provided us with a central location for storing user details that will later be imported from a content source such as Active Directory.  Today we will continue our journey to plan and configure User’s My Sites in SharePoint 2010.
Prerequisites
This article is the 5th in my series on deploying SharePoint 2010 for the enterprise, so if you have missed the first 4, you can easily catch-up via the links below;

1. Installing SharePoint 2010 using Least Privilege Service Accounts
2. Configuring incoming email in SharePoint 2010 with Exchange 2010
3. Configuring outgoing email in SharePoint 2010 with Exchange 2010
4. Configuring the User Profile Service in SharePoint 2010

Create the My Site Web Application
We begin by first creating a Web Application that will eventually house our My Site Host and subsequent site collections.
Navigate to Central Administration / Application Management / Web Applications
Click New

Authentication: Select either Claims or Classic depending on your requirements.  I will select “Classic”
IIS Web Site: Create a new IIS web site (enter your details as per your requirements)

Authentication Provider: Select your preferred provider based on your requirements.
Public URL: Specify the URL that users will type to access their My Sites.

Application Pool: Create a new application pool and give it a descriptive name
As we have been utilizing the least privilege model whilst configuring our SharePoint farm in this series, we will click on Register a new managed account and enter the details for our My Site Application Pool Identity.  Note: This account will be required to be provisioned in Active Directory before you can proceed. e.g. In my example I have created an account called DOMAIN\sp_mysite.

Click OK

Database Name and Authentication: Specify your Database server and Database name.
Failover Server: Specify your failover server if you are utilising SQL Server database mirroring.

Click OK
You should receive the below confirmation that the Web Application has been successfully created.

Click on our newly created “SharePoint – My Site” Web Application and click on General Settings.  Proceed to fill out your Web Application specific settings such as the Default Time Zone etc.

Create the My Site Host Site Collection
Now that we have successfully created our My Site Web Application, we can now proceed to create our My Site Host Site Collection.  This will be the top level site that will house our individual user’s site collections.
Navigate to Central Administration / Application Management / Create site collections.
Ensure that the recently created My Site Web Application is selected, enter in a Title and click select the My Site Host Template located under the Enterprise Tab.  Lastly, specify your site collection administrators and click OK.

You should then receive confirmation that the top level My Site Host has been successfully created.

Setup My Sites
Now that we have successfully provisioned our My Site Web Application and Top Level Site Collection that will host our My Sites, we can continue to configure our My Site Settings.
Navigate to Central Administration / Application Management / Manage service applications.
Click on User Profiles.
Click on Setup My Sites located under My Site Settings.

Enter the details of your Preferred Search Center if you have one setup already.
Enter the URL of your My Site Host that we have just created in the previous step and the personal site location.

Finally, select your Site Naming format, configure your Language Options, Permissions and My Site Email Notifications.

Click OK.
Add our Managed Path
Because we have specified “personal” as our Personal Site Location, we will need to define our managed path against our My Site Web Application.
Navigate to Central Administration / Application Management / Manage Web Applications.
Click on your My Site Web Application and click on Managed Paths from the Ribbon.

Add “personal” as a Wildcard inclusion, click Add Path and click OK

Enable Self-Service Creation
Our last configuration step provides our users with the privilege to provision their own My Site’s by enabling the Self-Service Creation.
Navigate back to Central Administration / Application Management / Manage Web Applications.
Click on your My Site Web Application and click on Self-Service Site Creation.

Select On and click OK.

If I now browse to my My Site URL I will be presented with the following “What’s New” Page.

It is only until I click on “My Content”, that SharePoint will proceed to create my personal site as per SharePoint 2007.

My Content

As you can see, we have now successfully completed our setup of a My Site Host which will house our user’s My Sites.
There is a whole bunch of new exciting features within SharePoint 2010 and its latest iteration of My Site in which I will deep dive in future articles.

Share|