SharePointChick.com

Site Definitions vs. WebTemplates

Mirjam — Tue, 15 Jun 2010 16:19:16 GMT

The site definition vs. webtemplate vs custom code discussion is a very old and ever returning discussions. There are at least four different approaches:

Creating full blown custom site definitions
Creating custom empty or blank site definitions and provisioning those with (stapled) features and code
Creating site templates
Using custom code

I think it is safe to say that the first option is a bit out of date. Creating full blown site definitions requires writing a lot of tedious XML in the onet.xml and schema.xml files. Microsoft has advised against this approach for some time now and that message has gotten a lot stronger with SharePoint 2010 and the new WebTemplate feature.

The second option is still a valid option. This option means you strip a site definition to its bear minimum. All list instances, modules and web parts will be removed from the onet.xml to make the onet.xml as small and readable as possible. The functionality can be added to the empty site by using features in the site definition, stapled features or code in a feature receiver. The best options are the stapled features and the code in the feature receiver. A combination of the two can also be a good solution.

When choosing between defining a feature in the onet.xml and stapling a feature to a site definition you might want to consider the provisioning order of a site definition:

Create the url for the site
Provision the GLOBAL onet.xml
When creating a new site collection - Activate site collection (SPSite) scoped features that are defined in the onet.xml, when creating a new sub site – verifying that all site collection scoped features are activated
Activate site collection scoped stapled features in random order
Activate sub site (SPWeb) scoped features that are defined in the onet.xml
Activate sub site scoped stapled features in random order
Create list instances defined in onet.xml
Create modules defined in onet.xml

The third option is using site templates. In SharePoint 2007 site templates could only be created by using the “save site as template” option from user interface of the site settings menu. Saving a site as a template would create a .stp file, which was called a site template. In SharePoint 2010 we can still save sites as templates, but now it will create a .wsp file. Yep, that’s right, saving a site as a template creates a real SharePoint solution. The generated .wsp solution can be imported into Visual Studio 2010 and edited from there, but unfortunately the imported solution will contain all content types, site columns and properties that were available within the site, even if they weren’t actually used. This creates a lot of clutter and a pretty unmanageable solution. The novelty that makes saving a site as a .wsp solution possible is the WebTemplate feature element.

The WebTemplate feature element can also be used to create your own web templates, without saving a site as a template. Just like site definitions, site templates in SharePoint 2010 require an onet.xml file. However, instead of the webtemp.xml file you will use a feature with the WebTemplate element. In the WebTemplate element you will define a BaseTemplateName, a BaseTemplateID and a BaseConfigurationID. In the example below the BaseTemplateName is STS, the BaseTemplateID is 1 and the BaseConfigurationID is 0. Die-hard SharePointeers will recognize the template name and configuration id and know that the basis for the site template we’re creating is the Team Site. The name and title of this site template will be My Fancy Web Template, so this is what will be displayed as the title of the template when you’re creating a new site. The category where you can find the site template in is Fancy Sites. A lot of the other properties can be left out if you’re creating your own site template, I just wanted to list them all in here for your reference.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <WebTemplate
    AdjustHijriDays="0"
    AlternateCssUrl =""
    AlternateHeader =""
    BaseConfigurationID ="0"
    BaseTemplateID ="1"
    BaseTemplateName ="STS"
    CalendarType ="1"
    Collation="25"
    ContainsDefaultLists ="TRUE"
    CustomizedCssFiles=""
    CustomJSUrl=""
    Description="Site with a lot of fancy features."
    DisplayCategory="Fancy Sites"
    ExcludeFromOfflineClient="FALSE"
    ImageUrl=""
    Locale="1033"
    Name="My Fancy Web Template"
    ParserEnabled="TRUE"
    PortalName="" 
    PortalUrl="" 
    PresenceEnabled="TRUE" 
    ProductVersion="" 
    QuickLaunchEnabled="TRUE" 
    Subweb="TRUE" 
    SyndicationEnabled="TRUE" 
    Time24="TRUE" 
    TimeZone="272" 
    Title="My Fancy Web Template" 
    TreeViewEnabled="FALSE" 
    UIVersionConfigurationEnabled="FALSE" >    
  </WebTemplate>
</Elements>

A web template feature can be site or farm scoped. If it is site scoped it can be deployed as a sandboxed solution. This way you can easily create sub sites based on the site template. If a site collection has to be based on the site template and you still want to deploy the site template as a sandboxed solution you can use the following steps:

You can first create the site collection without a template by selecting Select template later in the Custom template category
After creating the site, browsing to the site will redirect you to the template selection page
At the bottom of the settings page a link to the Solution Gallery is displayed
Click on the link and upload the sandboxed solution containing the site template
Activate the solution
The site template can now be selected and the site creation will be finished

The good thing about web templates is that they are based on one of the standard SharePoint site definitions and that they are stored in the database. This means that they will be easier to upgrade then a site definition would probably be. Another advantage of site templates is that they can be deployed as sandboxed solutions. These should be your main drivers for using site templates.

There are a couple of things that you can use in site definitions that aren’t available in site templates.

Module elements
* This means you can’t provision aspx pages by using the modules element in the onet.xml. Instead you can use features and feature receivers to provision your aspx pages and place web parts on them. This is a best practice anyway. Using features for you modules gives you more flexibility and also enables you to control the provisioning better. It will for instance enable you to make sure that adding the default.aspx page to the site isn’t the last step in the site creation process. Since using features is a great alternate approach for the modules in the site definition not being able to use modules in site templates is not a big deal.
Components elements. The components element can contain two child elements that are both optional and cannot appear more than once. Both elements are rarely used, so not being able to use them in site templates won’t be a problem for most people.
* FileDialogPostProcessor – this is a class that is used to modify the file open and save dialogs on a document library. If you save a file directly from Office to a document library you will get a web interface and in the FileDialogPostProcessor you can declare a class that modifies that interface.
* ExternalSecurityProvider – represents an interface that returns custom information about the security used in Microsoft SharePoint Foundation for indexing by a search crawler on a portal.
ServerEmailFooter
* This element can be used to define a footer section for email sent from the server. This element is also rarely used, so not being able to use it won’t be a big disturbance.
Stapled features
* Now this one is a bit nasty. When creating site definitions the advice is to use stapled features for adding features and functionality to sites that are created based on the site definition. The nice thing about this is that you don’t have to add the features to the onet.xml, you can simply create a stapling feature and link the site definition and the features in there. You can’t do this in site templates. I really hope this will be made possible later on, but for now we will have to add the features directly to the onet.xml of the site template.

Because of these limitations the provisioning order of a site template will be:

Create the url for the site
Provision the GLOBAL onet.xml
When creating a new site collection - Activate site collection (SPSite) scoped features that are defined in the onet.xml, when creating a new sub site – verifying that all site collection scoped features are activated
Activate sub site (SPWeb) scoped features that are defined in the onet.xml
Create list instances defined in onet.xml

The fourth option is to not create any custom site definitions and site templates and provision the whole site by using code. The nice thing about this is that it means not having to write any XML. Of course it does mean that you have to write a lot of custom code. You also need a way to trigger the code that will provision your site. This can be done in a feature receiver of a feature that is for instance added to the blank site definition (keep in mind that you can’t staple to the out of the box site definition). You can also create a custom site creation page that users will use to create their sites and that will fire of your code.
The all custom code approach is often used when sites are created by an automated process like a workflow, or for instance by a trigger from an external application. At Macaw we see a lot of use cases where the site creation process is triggered by a button or a change in Microsoft CRM.

Conclusion

Creating full blown site definitions and writing a lot of XML for the onet.xml file is not the best option. One of the reasons for this is of course that writing a lot XML is no fun, difficult to debug and very error prone. Another, perhaps even better reason, is that site definitions like this will almost certainly give you a headache when you want to upgrade to the next SharePoint version. Microsoft has been warning people for a while that eventually they will stop supporting site definitions. And it definitely looks like with the WebTemplate feature, they made the first step in that direction.

Using minimal site definitions with features and feature receivers is still an option that can be used. A reason for choosing this approach over the site templates approach could be if you need to use a lot of stapled features.

With the new WebTemplate feature in SharePoint 2010, the use of site templates will dramatically increase. If you are not bothered too much by the limitations of the site template this is a better bet than using site definitions. Mainly because it will make a future upgrade easier. The fact that you can deploy a site template as a sandboxed solution and thus only make a template available within a certain site collection can also be a benefit.

The custom code solution is also a valid approach. I would personally mainly use this when sites are created using automated processes. Of course approach two and three can also use custom code in feature receivers to add functionality to a site. A good reason to use this would be if you need to create list instances and add content types to them. I feel it is way easier to do this in code than to write that out using XML.

So..still not a clear and definitive answer, but I hope I was able to clarify the considerations for the different options in this post.

SharePoint Community Stuff Updates

Mirjam — Mon, 07 Jun 2010 14:25:12 GMT

It has been a bit quiet over the last few weeks here, while I was in Redmond, undertaking the SharePoint 2010 Microsoft Certified Master training.
I’m back now, so I hope you enjoyed the silence while it lasted…

DIWUG eMagazine
While I was hiding in Redmond, Marianne finished the work on the second DIWUG eMagazine. A big heads-up for Marianne for taking on a lot of the work on her own for this one. The magazine has turned out great again, with a lot of very cool SharePoint articles:

Web Content Management the SharePoint Server 2010 way - Waldek Mastykarz
Themes in SharePoint 2010 - Wictor Wilen
Suggestions for Social and Search in SharePoint 2010 - Andries den Haan
Community Kit for SharePoint Development Tools Edition - Wes Hackett
How to manage your Feature Lifecycle using Feature Versioning - Anders Rask
Architecting Service Applications - Octavie van Haaften
Incorporating External Data in SharePoint 2010 using WCF - Raghavan Ramadurai

Be sure the download the new magazine here.

We are already working on the next magazine, which will be released at the end of September. If you want to sponsor the magazine or write an article for it, please let us know.

SharePoint Featured MVPs on TechNet
I’m one of the 9 MVPs featured on TechNet at the moment. Very cool!
The page can be found here. Each MVP’s page contains a bio, links to blogs and articles, SharePoint forum posts and tweets.

SharePoint Best Practices Conference
From August 24 till August 27 the SharePoint Best Practices Conference will be held again in Washington DC.
This year the keynote will be different. It won’t be a cool story by a SharePoint celebrity, it will be 6 MCMs (Microsoft Certified Masters) sharing what they think it the coolest new thing in SharePoint 2010. I’m very excited to be one of the MCMs presenting on the keynote!
Of course I’m not just flying to Washington for the keynote, I’ll also be presenting and I’ll be on the Ask the Experts panel.
The topics I’ll be presenting on in Washington are:
Scaling SharePoint from small libraries to massive distributed archives
SharePoint 2010 Developer’s Mythbusters

For more information on other speakers, presentations and registration take a look at the Best Practices Conference website.

That’s it for now, but without a doubt there will be new events added to the list. Just stay tuned if you want to know how you can find or avoid me.

SharePoint Evolution Conference 2010 wrap up and slide decks

Mirjam — Fri, 07 May 2010 01:03:37 GMT

I had the honour of speaking at the SharePoint Evolution Conference this year. The original plan was to fly to London on Saturday afternoon and to present on “Using SharePoint search to develop custom solutions” on Wednesday. Because of the infamous volcanic ash cloud that Iceland so kindly send in our (or basically in every) direction things worked out a little bit differently.
On the Saturday afternoon I took the train from Rotterdam Central Station to Brussels Midi and from Brussels Midi I took the Eurostar train to London St. Pancras. I must say that this wasn’t an unpleasant experience at all. It was a bit more expensive than my plane tickets were and it’s a bit of pain to carry around your bags across the train station, but other than that it was quite pleasant and smooth.

Since there’s not train from the US to London and not one from Norway to London either unfortunately several speakers and friends couldn’t make it. Luckily a lot of great speakers did make it and stepped up to fill in for those who couldn’t make it. Thanks to great work in rearranging schedules and getting as many people as possible to the conference in London from the whole Combined Knowledge crew and in particular Steve and Zoe the conference was a great success, ash cloud or no ash cloud.

Here are the slides from my presentations at the SharePoint Evolution Conference:

DEV105 - Using SharePoint search to develop custom solutions

ITPRO106 - What, Why, When and How? Sandboxed Solutions

IW109 - What’s new in SharePoint Search 2010 for end users

DD113 - Growing SharePoint from small libraries to large scale repositories and massive archives

Thanks to all the attendees that made the extra effort to get to London and made this conference an incredible and unforgettable event. I really hope to be there again next year and to see all of you there again as well of course.

Also again, thanks to Steve and Zoe and the rest of the Combined Knowledge crew. You all did a great and very impressive job at making this show a great success again. I hugely enjoyed it.

Configuring claims and forms based authentication for use with a SQL provider in SharePoint 2010

Mirjam — Thu, 06 May 2010 23:36:13 GMT

Today I worked on configuring forms based authentication for SharePoint 2010. Using forms based authentication automatically means using claims based authentication in Sharepoint 2010.
I tried using both an LDAP provider and a SQL provider. My initial goal was to get them both working in the same environment, but after a lot of hours of staring at XML in web.config files I gave up on that one. Instead I created separate environments for using LDAP and SQL providers. Because of this I will also write two separate blog posts. This one will explain how to set up forms based authentication while using a SQL provider.
If you want to configure forms based authentication for use with an LDAP provider check out my other post here.

Using a SQL provider with forms based authentication means that users will use usernames and passwords that are stored in SQL Server Database. They will use a sign-in page to fill in their credentials and log in.

You can of course create your own database for storing credentials, but if you want one to be set up for you very quickly you can create the ASPNETDB by performing these steps:

Go to the SQL Server database server
On the database server, open Windows Explorer.
Navigate to the path %System Drive%\Windows\Microsoft.NET\Framework\v2.0.50727.
To start the ASP.NET SQL Server Setup Wizard, double-click aspnet_regsql.exe.
Complete the wizard
Make sure the Application Pool accounts of the web application(s) and the Central Administration web site have access to the database

In order to load up your database with test data you can use the membership seeder tool from CodePlex

Download the MembershipSeeder tool from http://www.codeplex.com/CKS/Release/ProjectReleases.aspx?ReleaseId=7450
To run the MembershipSeeder tool
     * Start the MembershipSeeder tool.
     * Click Configure.
     * In the dialog box that opens, type the name of the computer running SQL Server that hosts your SQL membership database.
     * Save your changes, and then restart MembershipSeeder so that it will use the new server name.
To create users for testing purposes
     * In the User Prefix field, type a value.
     * In the Password field, type the password you want each user to have.
     * In the # of Users field, select the number of users to create.
     * Click Create to create users where the user name is the value of the User Prefix field with an incrementing number added to the end

These are the steps you will need to take to set up the forms based authentication:

Create a new web application

Go to Central Administration
Go to Application Management
Click on Manage Web Applications
Click New
Select Claims Based Authentication
Identity Providers
     * Check the Enable Windows Authentication box or you won’t be able to crawl the site
     * Check the Enable ASP.NET Membership and Role Provider checkbox
          * In the Membership provider name edit box, type SqlMember
          * In the Role provider name edit box, type SqlRole

Create a new site collection

Go to Central Administration
Go to Application Management
Click Create site collections
Select the newly created web application
Fill in a name and select a template

Adjust the web.config of the Central Administration site

Open the Central Administration site's web.config file
Find the </configSections> entry
Paste the following XML directly below it

<connectionStrings>
   <clear />
   <add name="AspNetSqlMembershipProvider"
 connectionString="data source=sql.sharepoint.com;Integrated Security=SSPI;Initial Catalog=aspnetdb" 
 providerName="System.Data.SqlClient" />
</connectionStrings>

Find the <system.web> entry
Paste the following XML directly below it

<roleManager enabled="true" 
   cacheRolesInCookie="false" 
   cookieName=".ASPXROLES" 
   cookieTimeout="30" 
   cookiePath="/" 
   cookieRequireSSL="false" 
   cookieSlidingExpiration="true" 
   cookieProtection="All" 
   defaultProvider="AspNetWindowsTokenRoleProvider" 
   createPersistentCookie="false" 
   maxCachedResults="25">
   <providers>
      <clear />
      <add connectionStringName="AspNetSqlMembershipProvider" 
         applicationName="/" 
         name="SqlRole" 
         type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0,
 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      <add applicationName="/" 
         name="AspNetWindowsTokenRoleProvider" 
         type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0,
 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</roleManager>

<membership defaultProvider="SqlMember" 
   userIsOnlineTimeWindow="15" hashAlgorithmType="">
   <providers>
      <clear />
      <add connectionStringName="AspNetSqlMembershipProvider" 
         enablePasswordRetrieval="false" 
         enablePasswordReset="true" 
         requiresQuestionAndAnswer="true" 
         passwordAttemptWindow="10" 
         applicationName="/" 
         requiresUniqueEmail="false" 
         passwordFormat="Hashed" 
         name="SqlMember" 
         type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0,
 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</membership>

Double check whether the <membership> and <rolemanager> entries only exist ones. Delete any double entries.
Paste the following XML below the <PeoplePickerWildcards> entry

<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="SqlMember" value="%"/>
<add key="SqlRole" value="%"/>

Adjust the web.config of the Security Token Service (STS) virtual directory

NB: you will need to make the changes to the Security Token Service virtual directory on each server hosting either Central Administration or the claims based web application

Open the Security Token Service (STS) virtual directory's web.config file
Find the </system.net> entry
Paste the following XML directly below it

<connectionStrings>
   <clear />
   <add name="AspNetSqlMembershipProvider"
 connectionString="data source=sql.sharepoint.com;Integrated Security=SSPI;Initial Catalog=aspnetdb" 
 providerName="System.Data.SqlClient" />
</connectionStrings>

Add a <system.web> entry directly below the </connectionStrings>
Paste the following XML directly below the <system.web> entry

<membership>
   <providers>
     <add connectionStringName="AspNetSqlMembershipProvider" 
        enablePasswordRetrieval="false" 
        enablePasswordReset="true" 
        requiresQuestionAndAnswer="true" 
        passwordAttemptWindow="10" 
        applicationName="/" 
        requiresUniqueEmail="false" 
        passwordFormat="Hashed" 
        name="SqlMember" 
        type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</membership>

<roleManager enabled="true">
   <providers>
      <add connectionStringName="AspNetSqlMembershipProvider"
         applicationName="/" 
         name="SqlRole" 
         type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</roleManager>

Add a </system.web> entry directly below it

Adjust the web.config of the claims based web application

Open the claims based web application's web.config file
Find the </configSections> entry
Paste the following XML directly below it

<connectionStrings>
   <clear />
   <add name="AspNetSqlMembershipProvider"
 connectionString="data source=sql.sharepoint.com;Integrated Security=SSPI;Initial Catalog=aspnetdb" 
 providerName="System.Data.SqlClient" />
</connectionStrings>

Locate the <membership> entry
Replace everything from <membership> to </membership> with the following XML

<membership defaultProvider="i" 
   userIsOnlineTimeWindow="15" 
   hashAlgorithmType=""> 
   <providers> 
      <clear /> 
      <add connectionStringName="AspNetSqlMemberShipProvider" 
         enablePasswordRetrieval="false" 
         enablePasswordReset="true" 
         requiresQuestionAndAnswer="true" 
         passwordAttemptWindow="10" 
         applicationName="/" 
         requiresUniqueEmail="false" 
         passwordFormat="Hashed" 
         name="SqlMember" 
         type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
     <add name="i" 
        type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, 
Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
   </providers> 
</membership>

Locate the <roleManager> entry
Replace everything from <roleManager> to </roleManager> with the following XML:

<roleManager enabled="true" 
   cacheRolesInCookie="false" 
   cookieName=".ASPXROLES" 
   cookieTimeout="30" 
   cookiePath="/" 
   cookieRequireSSL="false" 
   cookieSlidingExpiration="true" 
   cookieProtection="All" 
   defaultProvider="c" 
   createPersistentCookie="false" 
   maxCachedResults="25"> 
      <providers> 
         <clear /> 
         <add connectionStringName="AspNetSqlMemberShipProvider" 
            applicationName="/" 
            name="AspNetSqlRoleProvider" 
            type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
         <add applicationName="/" 
            name="SqlRole" 
            type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
         <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, 
Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
   </providers> 
</roleManager>

Paste the following XML below the PeoplePickerWildcards entry

<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="SqlMember" value="%"/>
<add key="SqlRole" value="%"/>

Add a user policy to the web application

Go to Central Administration
Go to Application Management
Click on Manage Web Applications
Select the claims based web application
Click on User Policy
Click on the Add Users link
Click the Next button.
Click the Address Book icon.
Type in the NT login name or account name and click the search button. If it’s working correctly you should see at least two entries for the account – one that is for the user’s Active Directory account, and one that is for that same account but which was found using the LDAP provider.
Select the account in the User section and click the Add button
Click the OK button
Check the Full Control checkbox, then click the Finish button

You can now browse to the web application and log in using forms based authentication.

Select Forms Authentication

And fill in the username and password

I used the following blog posts to get things working, so I would like to thank Ali for his post:
http://blogs.msdn.com/alimaz/archive/2009/10/30/configuring-fba-in-sharepoint-server-2010-beta-2.aspx

I also want to thank Spence for his help and advice.

Configuring claims and forms based authentication for use with an LDAP provider in SharePoint 2010

Mirjam — Thu, 06 May 2010 19:31:42 GMT

Today I worked on configuring forms based authentication for SharePoint 2010. Using forms based authentication automatically means using claims based authentication in Sharepoint 2010.
I tried using both an LDAP provider and a SQL provider. My initial goal was to get them both working in the same environment, but after a lot of hours of staring at XML in web.config files I gave up on that one. Instead I created separate environments for using LDAP and SQL providers. Because of this I will also write two separate blog posts. This one will explain how to set up forms based authentication while using an LDAP provider.
If you want to configure forms based authentication for use with a SQL provider check out my other post here.

Using an LDAP provider with forms based authentication means that users will use their Windows or AD account to log in. However, because forms based authentication will be used they don’t get the usual popup, but they will use a sign-in page to log in.

These are the steps you will need to take to set it up:

Create a new web application

Go to Central Administration
Go to Application Management
Click on Manage Web Applications
Click New
Select Claims Based Authentication
Identity Providers
     * Check the Enable Windows Authentication box or you won’t be able to crawl the site
     * Check the Enable ASP.NET Membership and Role Provider checkbox
          * In the Membership provider name edit box, type LdapMember
          * In the Role provider name edit box, type LdapRole

Create a new site collection

Go to Central Administration
Go to Application Management
Click Create site collections
Select the newly created web application
Fill in a name and select a template

Adjust the web.config of the Central Administration site

Open the Central Administration site's web.config file
Find the <system.web> entry
Paste the following XML directly below it

<membership>
   <providers>
      <add name="LdapMember" 
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
 Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c" 
         server="dc.sharepoint.com" 
         port="389" 
         useSSL="false" 
         userDNAttribute="distinguishedName" 
         userNameAttribute="sAMAccountName" 
         userContainer="OU=SPUsers,DC=sharepoint,DC=com" 
         userObjectClass="person" 
         userFilter="(ObjectClass=person)" 
         scope="Subtree" 
         otherRequiredUserAttributes="sn,givenname,cn" />
   </providers>
</membership>

<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" > 
   <providers>
      <add name="LdapRole"
         type="Microsoft.Office.Server.Security.LdapRoleProvider, 
Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c"
         server="dc.sharepoint.com" 
         port="389"
         useSSL="false"
         groupContainer="OU=SPUsers,DC=sharepoint,DC=com"
         groupNameAttribute="cn"
         groupNameAlternateSearchAttribute="samAccountName"
         groupMemberAttribute="member"
         userNameAttribute="sAMAccountName"
         dnAttribute="distinguishedName"
         groupFilter="(ObjectClass=group)"
         userFilter="(ObjectClass=person)"
         scope="Subtree" />
   </providers>
</roleManager>

In the above XML the server tag is the server name of the domain controller. The user and group containers are the containers in AD where the users and groups you want to use for authentication reside. If you don’t know what the path to your container is, but you do have access to AD you can find out what the container is.
- Go to the domain controller
- Open Active Directory Users and Computers
- Select a user or a group in the container
- Right click and select All Tasks => Resultant Set Of Policy (Planning)
- Click the browse button next to Container and select the container
- This will give you the path to the container
Double check whether the <membership> and <rolemanager> entries only exist ones. Delete any double entries.
Paste the following XML below the <PeoplePickerWildcards> entry

<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="LdapMember" value="*"/>
<add key="LdapRole" value="*"/>

Adjust the web.config of the Security Token Service (STS) virtual directory

NB: you will need to make the changes to the Security Token Service virtual directory on each server hosting either Central Administration or the claims based web application

Open the Security Token Service (STS) virtual directory's web.config file
Find the </system.net> entry
Add a <system.web> entry directly below it
Paste the following XML directly below the <system.web> entry

<membership>
   <providers>
      <add name="LdapMember" 
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
 Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c" 
         server="dc.sharepoint.com" 
         port="389" 
         useSSL="false" 
         userDNAttribute="distinguishedName" 
         userNameAttribute="sAMAccountName" 
         userContainer="OU=SPUsers,DC=sharepoint,DC=com" 
         userObjectClass="person" 
         userFilter="(ObjectClass=person)" 
         scope="Subtree" 
         otherRequiredUserAttributes="sn,givenname,cn" />
   </providers>
</membership>

<roleManager enabled="true"> 
   <providers>
      <add name="LdapRole"
         type="Microsoft.Office.Server.Security.LdapRoleProvider,
 Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c"
         server="dc.sharepoint.com" 
         port="389"
         useSSL="false"
         groupContainer="OU=SPUsers,DC=sharepoint,DC=com"
         groupNameAttribute="cn"
         groupNameAlternateSearchAttribute="samAccountName"
         groupMemberAttribute="member"
         userNameAttribute="sAMAccountName"
         dnAttribute="distinguishedName"
         groupFilter="(ObjectClass=group)"
         userFilter="(ObjectClass=person)"
         scope="Subtree" />
   </providers>
</roleManager>

Add a </system.web> entry directly below it

Adjust the web.config of the claims based web application

Open the claims based web application's web.config file
Locate the <membership> entry
Paste the following XML directly below the <Providers> entry

<add name="LdapMember" 
   type="Microsoft.Office.Server.Security.LdapMembershipProvider, 
Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c" 
   server="dc.sharepoint.com" 
   port="389" 
   useSSL="false" 
   userDNAttribute="distinguishedName" 
   userNameAttribute="sAMAccountName" 
   userContainer="OU=SPUsers,DC=sharepoint,DC=com" 
   userObjectClass="person" 
   userFilter="(ObjectClass=person)" 
   scope="Subtree" 
   otherRequiredUserAttributes="sn,givenname,cn" />

Locate the <roleManager> entry
Paste the following XML directly below the <Providers> entry

<add name="LdapRole"
   type="Microsoft.Office.Server.Security.LdapRoleProvider, 
Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c"
   server="dc.sharepoint.com" 
   port="389"
   useSSL="false"
   groupContainer="OU=SPUsers,DC=sharepoint,DC=com"
   groupNameAttribute="cn"
   groupNameAlternateSearchAttribute="samAccountName"
   groupMemberAttribute="member"
   userNameAttribute="sAMAccountName"
   dnAttribute="distinguishedName"
   groupFilter="(ObjectClass=group)"
   userFilter="(ObjectClass=person)"
   scope="Subtree" />

Paste the following XML below the PeoplePickerWildcards entry

<clear />
<add key="AspNetSqlMembershipProvider" value="%" />
<add key="LdapMember" value="*"/>
<add key="LdapRole" value="*"/>

Add a user policy to the web application

Go to Central Administration
Go to Application Management
Click on Manage Web Applications
Select the claims based web application
Click on User Policy
Click on the Add Users link
Click the Next button.
Click the Address Book icon.
Type in the NT login name or account name and click the search button. If it’s working correctly you should see at least two entries for the account – one that is for the user’s Active Directory account, and one that is for that same account but which was found using the LDAP provider.
Select the account in the User section and click the Add button
Click the OK button
Check the Full Control checkbox, then click the Finish button

You can now browse to the web application and log in using forms based authentication.

Select Forms Authentication in the dropdown

And fill in the appropriate user name and password.

I used the following blog posts to get things working, so I would like to thank Steve, Ali and TechNet :-):

http://blogs.technet.com/speschka/archive/2009/11/05/configuring-forms-based-authentication-in-sharepoint-2010.aspx
http://blogs.msdn.com/alimaz/archive/2009/10/30/configuring-fba-in-sharepoint-server-2010-beta-2.aspx
http://technet.microsoft.com/en-us/library/ee806890(office.14).aspx

Wrap up: DIWUG event at VX Company

Mirjam — Mon, 26 Apr 2010 21:25:38 GMT

Last Tuesday (April 13th) we had another DIWUG evening. This one was sponsored by and hosted at VX Company in Baarn.

We started out with a nice dinner with fancy sandwiches and a great sateh. After that Immanuel Kranendonk introduced us to VX Company and announced a business card draw to win one of five “Microsoft SharePoint 2010: Building Solutions for SharePoint 2010” books.

After that I had the honour of presenting the first session on “Using SharePoint search to develop custom solutions” myself. I talked about extending the out of the box web part by inheriting from the public out-of-the-box web parts, using the Federation Object Model and the SharedQueryManager. I showed a demo where I customized both the select statement and the way the results were displayed for a query on a SQL database that was crawled by the SharePoint search using the Business Connectivity Services. After that we dived into a completely custom search solution: the birthday web part. I talked about the query and administration object models and about the FullTextSqlQuery class. The slides from this presentation can be downloaded here.

The second presentation from Roel Hans Bethlehem was on PowerShell. PowerShell is the new shell language that can be used to manage all Microsoft server products. With the release of SharePoint 2010, SharePoint is the next Microsoft server product that includes support for PowerShell. The PowerShell cmdlets for SharePoint can be used to manage every aspect of SharePoint, as the PowerShell cmdlets expose a superset of the Central Administration options. Roel Hans started out by explaining why in when PowerShell should/could be used with SharePoint 2010. He also talked about two different PowerShell Editors, the PowerShell Integrated Scripting Environment that is a feature of Windows Server 2008 R2 and Quest’s PowerGui. After that he showed a lot of examples and explained and dissected them. The slides for this great intro into PowerShell can be found here.

After the presentation Immanuel gave away the books and announced the SharePint sponsored by VX Company in the next room.
It was another very successful DIWUG evening.
Of course we would like to thanks VX Company for sponsoring and Roel Hans Bethlehem for presenting. And all the attendees for showing up, because without them a DIWUG evening would be no fun at all!

Deploying a custom master page in SharePoint 2010

Mirjam — Fri, 26 Mar 2010 00:33:50 GMT

Lately I’ve been playing around with Visual Studio 2010 tools for SharePoint. I’ve been trying to come up with examples on how to use each of the available item templates.
Today I created a Module. A module can be used to deploy files to your SharePoint environment and the scenario I came up with was to use a module to deploy a master page.

I started out by creating an Empty SharePoint project. This can have any name you like and it can be both a farm and a sandboxed solution
Next add an new item to the project and choose a module
You can rename the module if you want to, I will leave the name at Module1
After the module is created it contains an elements.xml file and a sample.txt file. The sample.txt file can be renamed to sample.master.

Project structure after adding a module and renaming the sample file to sample.master

I’m not a designer, so I wasn’t interested in creating a brilliant new design (good job, because I wouldn’t be able to do that!).
For the purpose of this example I just took the standard SharePoint 2010 master page contents.

Open up SharePoint Designer and open the site you are working on
Choose Master Pages on the left side
Open v4.master

Don’t let SharePoint fool you. There is a default.master, but this is the old SharePoint 2007 master page that is used if you perform a visual upgrade. When creating a site in SharePoint 2010 the master page that will be used by default is v4.master. I know it’s a bit confusing, but if you have been working with SharePoint for a while you won’t be surprised by this.

Copy the contents of v4.master and past them in your sample.master file in Visual Studio. Make the changes you want to.
Note how the elements.xml file has changed to reference the sample.master rather than the sample.txt

The contents of the elements.xml file

Make sure the module is added to a feature in your project that is scoped at the site (= site collection) level

You could stop here and this solution will deploy your sample.master master page to the master page gallery of your site collection.
This will not apply the master page to the site collection when the feature gets activated though. It will only make it available for selection.

If you the master page to be applied when the feature gets activated you right click on the Feature1 and you add an event receiver. This will add a feature receiver file to the feature.
In this file we will add some code that will apply the sample.master master page when the feature gets activated and it will apply the v4.master when the feature gets deactivated.

Code used in the feature receiver

Now if you activate the feature the code in the feature receiver will run and will apply sample.master to the site. As you can see we change both the MasterUrl and the CustomMasterUrl. The MasterUrl is used on all pages that are not publishing pages. This means it is used on the pages in the sitepages library and on the pages in the _layouts directory like the settings page for instance. The CustomMasterUrl is only used on pages that are stored in the Pages library. This library is created when the SharePoint Server Publishing Infrastructure features is activated on the site collection and the SharePoint Server Publishing feature is activated on the site.

You can also use the SharePoint user interface to apply a new master page. The Site Master Page is the equivalent of the CustomMasterUrl and the System Master Page is what the object model calls the MasterUrl.

Changing the master page using the SharePoint user interface

Custom Search Solutions for SharePoint 2010 - FullTextSqlQuery

Mirjam — Sun, 21 Mar 2010 12:46:43 GMT

If you are building a custom search solution based on SharePoint 2010 you might want to build your own custom query to query the SharePoint index. If you do you probably need to use the FullTextSqlQuery class, just like I am for my custom Birthday web part. While building that web part I ran into a couple of things that I might be able to spare others.

First thing to note is that the FullTextSqlQuery is available in two different namespaces. There is Microsoft.SharePoint.Search.Query.FullTextSqlQuery for SharePoint Foundation and there is Microsoft.Office.Server.Search.Query.FullTextSqlQuery for SharePoint Server. Be aware of which version of SharePoint you are running and use the right one, or your query won’t return the results you expect. So if you are running SharePoint Server you need to use Microsoft.Office.Server.Search.Query.FullTextSqlQuery.

Apart from this there don’t seem to be too many changes in the FullTextSqlQuery class. The SharePoint Search SQL Syntax for SharePoint2010 isn’t documented yet, but from what I saw I think Microsoft can just copy the documentation from the SharePoint 2007 version. I was particularly interested in the DATEADD clause. The DATEADD clause in SharePoint was developed to retrieve last modified documents within an environment. You could for example use WHERE LastModifiedTime <= DATEADD (DAY, -5, GETGMTDATE()), which would get you the documents modified within the last 5 days.

My use for the DATEADD clause in my birthday web part would be to retrieve the birthdays in the next few days. So I would want to use the DATEADD clause with a positive value, for instance 7 for the birthdays in the next week. Unfortunately the SharePoint Search SQL Syntax still doesn’t support using positive values in the DATEADD clause.
Luckily for me at least I can use LINQ now to run this query on the resultset I get back after running my FullTextSqlQuery. :-)

Wrap up: DIWUG event at Wortell

Mirjam — Mon, 15 Mar 2010 14:25:05 GMT

With over 90 visitors the first DIWUG event of 2010 was a huge success. The event was hosted in Lijnden in the Wortell office. The evening started out very well with proper Dutch food, various “stamppotten” were served!

The first session of the evening was “Social Computing in SharePoint 2010” by Daniel McPherson, Mark van Lunenburg and Robin Meuré. Social Computing is one of the new buzz words and a lot of sites that are considered social are hugely popular. Think about sites like YouTube, Flickr, Facebook and of course Twitter. However most of these sites are not used within the company. Some because they are not secure enough and others because they are not suitable for other reasons.
Daniel, Mark en Robin showed how SharePoint’s social features can help bring social computing to the enterprise. The slides from this presentation can be downloaded here.
If you missed the session you watch it on Channel 9.

After the break Donald Hessing presented on “Rich Media in SharePoint 2010”. In his session he showed how you can manage videos, images and other digital assets centrally in SharePoint 2010. Donald explained in which use cases which SharePoint 2010 features could best be used. He also did a demo on how to set up Remote Blob Storage (RBS) to off load large files from the SharePoint database to another storage system. For an end user it will seem as if the file is still stored in SharePoint, so RBS is purely a server and database management feature.
If you want to watch this session online it is posted here on Channel 9.

Next it was time for drinks, snacks and networking.

Of course we would like to thank Wortell for sponsoring the location, the food, the drinks and the book all DIWUG attendees got, “SharePoint 2010 op management niveau” written by one of the Wortell’s founders Danny Burlage. It was a great evening and everything was very well taken care off!

We hope to see all of you again at one of the following events:

DevDays on March 30th and 31st in Den Haag. You can find us at the Ask the Experts booth.
The next SDN event with Visual Studio 2010 theme that will be held on April 12th.
The next DIWUG event that will probably be on April 15th. This date isn’t confirmed yet though, so watch the DIWUG site closely!

Until next time!

Using the SharePoint 2010 WebTemplate Feature Element for creating Site Templates

Mirjam — Thu, 11 Mar 2010 23:43:15 GMT

In SharePoint 2007 it was possible to save a site as a site template with a .stp extension. Saving a site as a template can be done from the site settings user interface. The .stp file is, like most SharePoint specific file extensions, a .cab file. The .stp file contains a link to the original site definition that the saved site depended on and the delta between that site definition and the saved site.

In SharePoint 2010 we can still save sites as templates in much the same way. However, saving a site as a template won’t create a .stp file, but a .wsp SharePoint Solution file! The .wsp file doesn’t just contain the delta, but it contains the onet.xml of the original site definition and all features and elements and optionally also content. What’s new in SharePoint 2010 that makes this possible is the WebTemplate Feature Element. There isn’t a lot of documentation on the WebTemplate element yet. Basically all I could find was documentation related to Sandboxed Solutions, as you can use the WebTemplate Feature Element in Sandboxed Solutions. The most elaborate description can be found here: http://msdn.microsoft.com/en-gb/library/ee539417(office.14).aspx.

In short the story is that you can use the WebTemplate element to create a site template instead of the WebTemp.xml file that you would use to create a site definition. You can create site templates by either saving an existing site as a template, or you can create a site template using Visual Studio. If you create a site template by saving a site you can import the resulting .wsp package into Visual Studio. Note that if you do this that a lot of elements, like content types, site columns and properties from the property bag get imported into Visual Studio. Fortunately you can easily adjust the contents of the imported site template. You can clean up the template, but you can also make additional adjustments to it. Another benefit of importing the site template into Visual Studio is that it’s easy to put it under source control.

The image above shows an example of what the WebTemplate element could look like. The most important thing to note from the image is that the WebTemplate has to reference the Template and the Configuration of the site definition the template is based on.

The debate about whether to use a site template or a site definition that was a lively one in SharePoint 2007 will probably continue to exist in SharePoint 2010. However with the introduction of .wsp site templates and the WebTemplate element site templates are now a whole lot more flexible and robust. One definite advantages of using site templates is that a site template can be deployed as a sandboxed solution. This means that the .wsp file can be deployed to the solutions gallery at site collection level. Anyone with site collection administrator rights can do this, so no access to the server is required. Only users within a site collection where the site template is deployed to can create sites based on the site template.
It’s also possible to deploy the same .wsp package as a farm solution to the farm’s Central Administration site. In order to do this a farm administrator that has access to the SharePoint server needs to add and deploy the solution to the farm. In this scenario the feature with the site template in it can activated on all site collections. Once the feature has been activated on a site collection users within that site collection can create sites using the template.

In the near future a lot more information on the new WebTemplate feature element will probably be published, but this is at least a short primer on what the element is and how to use it.
Have fun!