Assuming you have a MSDN subscription or any other kind of Azure license and wanting to try out SharePoint 2016, here are the steps to follow to install a SharePoint 2016 IT Preview Virtual Machine in Azure.

It’s good to know there is a pre-baked SharePoint 2016 IT Preview Virtual Machine already in the Azure Virtual Machine gallery. This way you only have to install SQL server and configure SharePoint correctly. This can be done in an hour.

Log in to Azure

Log in to Azure and go straight to the old Azure portal (if you aren’t already there). This is because the Virtual Machine isn’t available with the new look and feel or they’ve done a good job in hiding it.

Go to the old Azure portal

Deploy a Virtual Machine from the gallery

Head to the Virtual Machine Gallery, select the SharePoint category on the left and select the SharePoint Server 2016 IT Preview image.

2015-10-21 11_20_22-Start

2015-10-21 11_23_48-Clipboard

Choose a unique name for the Virtual Machine name like sp2016paarhuis I’m using.

Which Tier and Size?

Now, if you wan’t to use this SharePoint machine on a regular basis and are stuck to an MSDN subscription the Basic Tier with an A3 is the best option. This is sufficient for such a machine and it will fit just in a MSDN Premium subscription without having to turn it off. But if you just want to try it out once or twice you can go with the Standard Tier and a D12, just for speed.

Choose a username and password and continue.

2015-10-21 11_32_24-Photos

On the next two pages change the Region to your zone and keep the rest as-is and finish the wizard.

2015-10-21 11_35_27-Photos

Wait for the machine to be provisioned and started, this might take a few minutes.

2015-10-21 11_41_20-Photos

Once the machine is up-and-running you can connect with the machine (using the Connect button in the Azure portal). You will see that there is no Active Directory yet (which is highly recommended) and no SQL Server which is also mandatory for the single server SharePoint farm. The only thing pre-installed is the SharePoint setup.

2015-10-21 11_52_57-Start

Configure Active Directory

On the Server Manager add an Active Directory server role. Select the Active Directory Domain Services role and accept installing the required features.

2015-10-21 11_54_06-Program Manager

 

2015-10-21 11_57_01-Clipboard

Installation doesn’t require the server to restart so you can choose whatever you want in the last step at the automatic restart.

2015-10-21 12_00_53-Start

Now wait for the installation to finish. I’m getting a coffee if you don’t mind.

Now promote the server to a domain controller.

2015-10-21 12_09_07-Xbox

Click Add a new forest and specify a root domain name like my dev.local.

2015-10-21 12_10_50-Start

On the next screen just fill in a DSRM password and continue the wizard leaving all default settings.

2015-10-21 12_12_14-Start

You can ignore the warnings, just click Install.

2015-10-21 12_15_16-Clipboard

The machine will reboot. You need to reconnect using the domain credentials, dev\jeffrey in my case, to connect as the domain admin.

The AD and DNS are now all finished, next step is SQL.

Installing SQL Server 2014

Find a way to get the the SQL Server 2014 with SP1 ISO on the Virtual Machine. I downloaded the Enterprise Edition ISO from MSDN. If you’re experiencing any issues downloading files in Internet Explorer, set the Internet zone Security settings to Default level.

Mount the ISO and start installing SQL Server 2014, choose to install a new SQL Server stand-alone installation.

2015-10-21 12_55_55-Photos

At Setup Role choose the SQL Server Feature Installation option.

2015-10-21 14_04_23-Photos

Install the Database Engine and the Full-Text Search and also the complete Management Tools.

2015-10-21 14_07_53-Start 2015-10-21 14_08_19-Start

Warning! At the Server Configuration select the Network Service (NT AUTHORITY\NETWORK SERVICE) for both the Agent and Database Engine. The default accounts cripple the installation.

2015-10-21 14_56_52-Photos

Continue the wizard, add the current user as admin and start the installation.

2015-10-21 14_18_14-Photos

If SQL is installed all and well, the final step is to configure SharePoint.

Configure SharePoint

Before starting the SharePoint configuration we need to create a SharePoint service account. Go to Active Directory Users and Computers and add a new user named spfarm.

2015-10-21 15_54_02-Jump List for Remote Desktop Connection

Just like any other service account fill in a password and only select the Password never expires option and finish the user creation process.

2015-10-21 15_56_03-Jump List for Remote Desktop Connection

Now, open the SharePoint 2016 Products Configuration Wizard from the Windows start menu.

 

2015-10-21 15_47_30-Start

On the second screen of the wizard, choose to create a new server farm and click next.

2015-10-21 15_50_10-Photos

For the Database Access Account we use the newly created SharePoint farm user, the database server is localhost.

2015-10-21 16_00_35-Photos

Continue the wizard by filling in a passphrase. At the Specify Server Role screen you will have to select the Singe-Server Farm.

2015-10-21 16_04_23-Photos

Choose a central admin port (or not) and continue the wizard until the configuration of SharePoint begins.

When the setup is done you will be taken to the Central Administration site. SharePoint is now completely installed and you’re ready to create your web application and site collection. If you wan’t me to take you through the process of creating a site collection, please read on.

Create web application and site collection

In central admin, don’t follow the configuration wizard, but configure it yourself.

2015-10-21 22_05_22-Clipboard

Under Application Management go to Manage Web Applications. Click New to create a new web application. Use the default settings to create the main root web application.

2015-10-21 22_10_38-Jump List for Remote Desktop Connection 2015-10-21 22_10_56-Jump List for Remote Desktop Connection

Creating the web application can take a few minute, after a while the process will be done and you’re good to go to create the site collection. Go back to Application Management and go to Create site collections.

2015-10-21 22_21_54-Alarms & Clock.

Your new web application will be automatically selected. Here you will have to fill in a site title, select a template and add yourself as the primary site collection administrator.

2015-10-21 22_23_58-OneNote

Create the new site collection and when finished you’re left with the option to head to the newly created site directly by clicking the link displayed.

2015-10-21 22_27_06-OneNote

And finally we’re done.

2015-10-21 22_29_56-Clipboard

Automated deployment for SharePoint Online can be one hell of a job. Apps and sandboxed solutions are the designated methods for provisioning, but are very limited. How about PowerShell? Yes! But not the default flimsy SPO cmdlets library. No, we are using SharePoint PowerShell, a third party PowerShell API for SharePoint (Online and On-premise).

SharePoint PowerShell

SharePoint PowerShell in fact a bunch of PowerShell Modules talking to CSOM, created by a guy called Jeffrey Paarhuis 🙂  Very usefull for Office 365 and private clouds where you don’t have access to the physical server.

What can you do with it?

  • Site Collection
    • Test connection
  • Site
    • Manage subsites
    • Manage permissions
  • Lists and Document Libraries
    • Create list and document library
    • Manage fields
    • Manage list and list item permissions
    • Upload files to document library (including folders)
    • Add items to a list with CSV
    • Add and remove list items
    • File check-in and check-out
  • Master pages
    • Set system master page
    • Set custom master page
  • Features
    • Activate features
  • Web Parts
    • Add Web Parts to page
  • Users and Groups
    • Set site permissions
    • Set list permissions
    • Set document permissions
    • Create SharePoint groups
    • Add users and groups to SharePoint groups
  • Solutions
    • Upload sandboxed solutions
    • Activate sandboxed solutions

And yet more to come…

How does it work? Well, like this:

# Include SPPS
Import-Module .\spps.psm1

# Setup SPPS
Initialize-SPPS -siteURL "https://example.sharepoint.com/" -online $true -username "[email protected]" -password "password"

# Activate Publishing Site Feature
Activate-Feature -featureId "f6924d36-2fa8-4f0b-b16d-06b7250180fa" -force $false -featureDefinitionScope "Site"

#Activate Publishing Web Feature
Activate-Feature -featureId "94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb" -force $false -featureDefinitionScope "Web"

# Create a subsite
Add-Subsite -title "Subsite" -webTemplate "STS#0" -description "Description..." -url "subsite" -language 1033 -useSamePermissionsAsParentSite $true

# Create document library
Add-DocumentLibrary -listTitle "Testdoclib"

# Copy testfiles to this document library
Copy-Folder "C:\example\Testdoclib" "Testdoclib" $false

Try it yourself: example application 

And let me know what you think of it and how it can be improved!

Just for my reference, or anyone else interested, a link to the perfect guide on creating a custom filter section in the refinement panel.

http://www.domorewithsearch.com/customizing-the-refinement-panel-for-sharepoint-2010-search/

This is a nasty SharePoint bug which caused some trouble in one of the SharePoint Online environments I was working on.

I created a Site Template using the “Save site as template” feature of SharePoint. Now when I created a new site from the template it resulted in the web parts all mixed up in the Left web part zone. Remarkably it was only the Left zone, the others were keeping their correct web part sequence.

When I took a look in the Onet.xml of the Site Template the web parts were nicely divided into seperate AllUsersWebPart’s and having correct WebPartZoneId’s. And although the web parts were also mixed up in the XML, the WebPartOrder properties were set correctly, 1 for the first, 2 for the second and so on. I still tried to rearrange the XML so the web parts would also have the right sequence in the syntax, but with no success, the web parts were still mixed up.

The final thing to do was to create a Web Part Zone for each Web Part. I did this by opening the page in SharePoint Designer and edit in the Advanced Mode (button on the ribbon).

This way the order is hardcoded on the page. I admit, it’s not very neat, but it does the trick.

In an earlier post I’ve explained that it’s possible to use PowerShell for SharePoint Online. In this post I want to explain what the difficulties of SharePoint Online are and how we did manage to overcome that.

So, what’s the problem?

When you use the Client Object Model directly from PowerShell, it might seem to work, up to the point that you’re executing a query. Then you will receive a 403 – forbidden error.

Off course, when you don’t provide any credentials you will not get access. You could try to provide a username, password and domain programmatically, but you won’t find any way to authenticate. This is because the authentication method of SharePoint Online differs from the ones that Client Object Model supports.

What’s the solution?

The only thing we have to do is get an authenticated ClientContext and we’re ready to script. Fortunately, Microsoft has done all the hard work, because they have published a sample project for authentication with SharePoint Online.

We are going to pimp this project with our own code and make it possible to retrieve and use an authenticated ClientContext in PowerShell.

Go ahead, download sample project and open the ClaimsAuth solution file in Visual Studio. You will see that it also loads a project called Sp_Ctx; you can remove or just ignore it, we won’t use it.

Now, in the ClaimsAuth project add a new class called “SPOContext” and use the following code:

using System.Net;
using Microsoft.SharePoint.Client;
using MSDN.Samples.ClaimsAuth;

public class SPOContext : ClientContext
{

  public SPOContext(string siteUrl) : base(siteUrl)
  {
    // this method gives a popup asking for credentials
    CookieCollection cookies = ClaimClientContext.GetAuthenticatedCookies(siteUrl, 0, 0);

    this.ExecutingWebRequest += delegate(object sender, WebRequestEventArgs e)
    {
      e.WebRequestExecutor.WebRequest.CookieContainer = new CookieContainer();
      foreach (Cookie cookie in cookies)
      {
        e.WebRequestExecutor.WebRequest.CookieContainer.Add(cookie);
      }
    };
  }

  // need a plain Load method here, the base method is some
  // kind of dynamic method which isn't supported in PowerShell.
  public void Load(ClientObject objectToLoad)
  {
    base.Load(objectToLoad);
  }
}

As you can see, we made an object that inherits from the ClientContext. The magic happens in the constructor; a pop-up will be shown where the user can login with his credentials. It then receives a few cookies which are stored and sent with each request. The cookies are the fairy dust in all of this, the cookies make it possible to authenticate with each request.

You also see a Load method. Why do we need this? The base class already has a Load method! Yes, but that method is some kind of dynamic method which isn’t supported in PowerShell. This custom Load method now acts as a wrapper for the real Load method.

This is it! Build the project and test the ClaimsAuth.dll according to my previous post.

EDIT: THIS PROJECT IS CONTINUED ON CODEPLEX!

Due to the success of this post I continued this as a project on CodePlex: https://sharepointpowershell.codeplex.com

 

But if you still want to continue reading this post, go ahead.

How it works

Download this file and extract the DLL to an easy location to reach from PowerShell. Because this assembly uses the Client Object Model you need to install the COM Redistributable as well.

These are the PowerShell commands to run:

You need to run PowerShell in single-threaded mode (the authentication requires it).

powershell -STA

Import the DLL.

[Reflection.Assembly]::LoadFile("D:\ClaimsAuth.dll")

Instantiate a new SPOContext providing your SharePoint Online site URL. (Don’t forget the https)

$spoContext = new-object SPOContext("https://jeffreypaarhuis.sharepoint.com")

Now, let’s test it:

$spoContext = new-object SPOContext("https://jeffreypaarhuis.sharepoint.com")
$web = $spoContext.Web
$spoContext.Load($web)
$spoContext.ExecuteQuery()
Write-Host $web.Title

As you already might understand, this solution is based on the SharePoint Client Object Model. This means that everything that’s possible with the COM is possible to script. This post explains how to work with Sites, Permissions, Documents, etc. with the COM. It is written in C# but it’s fairly easy to translate to PowerShell.

Samples

-------------------
Init spoContext
-------------------

powershell -sta
[Reflection.Assembly]::LoadFile("D:\ClaimsAuth.dll")
$spoContext = New-Object SPOContext("https://mysharepointonline.sharepoint.com")

-------------------
Print sitename
-------------------

$web = $spoContext.Web
$spoContext.Load($web)
$spoContext.ExecuteQuery()
$web.Title

-------------------
Add property to bag
-------------------

$web.AllProperties.FieldValues.Add("propA","Property A")
$spoContext.ExecuteQuery()

$web.AllProperties.Item("propA")
-------------------
Show features
-------------------

$site = $spoContext.Site
$spoContext.Load($site)
$spoContext.ExecuteQuery()
$features = $site.Features
$spoContext.Load($features)
$spoContext.ExecuteQuery()

$features
-------------------
Permissions stuff
-------------------

Function GetWeb
{
 $ctx.ExecuteQuery()
 Return $ctx.Web
}

Function GetList ($name)
{
 $web = GetWeb
 if ($web -ne $null)
 {
 $lists = $web.Lists
 $ctx.Load($lists)
 $ctx.ExecuteQuery()
 $list = $lists | where {$_.Title -eq $name}
 return $list
 }
 return $null
}

Function GetRole ($rType)
{
 $web = GetWeb
 if ($web -ne $null)
 {
 $roleDefs = $web.RoleDefinitions
 $ctx.Load($roleDefs)
 $ctx.ExecuteQuery()
 $roleDef = $roleDefs | where {$_.RoleTypeKind -eq $rType}
 return $roleDef
 }
 return $null
}

Function GetPrincipal ($name)
{
 $web = GetWeb
 if ($web -ne $null)
 {
 $principal = $web.EnsureUser($name)
 $ctx.Load($principal)
 $ctx.ExecuteQuery()
 return $principal
 }
 return $null
}

Function GetGroup ($name)
{
 $web = GetWeb
 if ($web -ne $null)
 {
 $groups = $web.SiteGroups
 $ctx.Load($groups)
 $ctx.ExecuteQuery()
 $group = $groups | where {$_.Title -eq $name}

 return $group
 }
 return $null
}

Function GetDocumentLibrary ($name)
{
 $web = GetWeb
 if ($web -ne $null)
 {
 $docLibs = $web.Lists
 $ctx.Load($docLibs)
 $ctx.ExecuteQuery()
 $docLib = $docLibs | where {$_.Title -eq $name}
 return $docLib
 }
 return $null
}

$web = GetWeb

$web.BreakRoleInheritance($true, $false);
$principal = GetGroup "MyGroup"
$roleType = [Microsoft.SharePoint.Client.RoleType]"Contributor"
$role = GetRole $roleType

$collRdb = new-object Microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
$collRdb.Add($role)
$collRoleAssign = $web.RoleAssignments
$collRoleAssign.Add($principal, $collRdb)

$ctx.ExecuteQuery()

$list = GetList "Shared Documents"

$list.BreakRoleInheritance($false, $false);
$roleType = [Microsoft.SharePoint.Client.RoleType]"Reader"
$role = GetRole $roleType

$collRdb = new-object Microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
$collRdb.Add($role)
$collRoleAssign = $list.RoleAssignments
$collRoleAssign.Add($principal, $collRdb)

$ctx.ExecuteQuery()

Errors?

You might see the following errors from time to time, which aren’t a big deal:

– “The requested site does not appear to have claims enabled or the Login Url has not been set.”.
Problem: This usually means that no session can be instantiated (SharePoint Online bug).
Solution: Navigate to your site in Internet Explorer, when your site doesn’t show, refresh it a few times until it shows, or go to https://portal.microsoftonline.com. When you get a login page, go back to your script.

– “The remote name could not be resolved: ‘mysp.sharepoint.com'”
Problem: During scripting, the context timed out.
Solution: Re-instantiate the $spoContext object. When running a script in one go, this error shouldn’t pop because the Context will not prematurely expire.

Under the hood

How does it work under the hood? What’s in the DLL? What makes SharePoint Online so difficult?

In line with this one I’ve written a post that explains what the problem with SharePoint Online is and how to build your own DLL. Read it here.

UPDATE (11-7-2012):

Forgot to mention you need to install the COM Redistributable.

UPDATE (3-9-2012):

Added samples.

My Story

By default, it’s only possible to sort on relevance and modified date in the Core Results Web Part. And it also isn’t possible to give a sorting direction, it’s always descending.

Now a client wanted to show the last created discussions on the homepage of it’s SharePoint, off course sorted by creation date. Out of the box this isn’t possible, but luckily somebody else had the same problem and came with a neat solution: http://www.insidesharepoint.net/post/2011/02/16/Creating-a-sortable-CoreResultsWebPart-in-SharePoint-2010.aspx

I played around a bit with that code, but couldn’t get it to work. The most common error I got was Property doesn’t exist or is used in a manner inconsistent with schema settings.

At this time of writing my expertise in the SharePoint Search maze isn’t that great, but I read something about a Managed Metadata Properties in the blog post. After playing around with custom managed properties for a while I finally got it to work. The trick is to create a custom Managed Property with mappings to, in my case, Basic:15;ows_start_x0020_Date,Office:12;creationdate and do a full crawl. Important! Do not do an incremental crawl! That will definitely not work! I cracked my head on that one already!

And then it works!

You could also forget the story above and follow the instructions beneath

These are the steps I took to work out my case, which is sorting Team Discussions by Creation Date.

First I created a scope named Discussions with a rule contentclass = STS_ListItem_DiscussionBoard.

Then I created a Managed Metadata Property named Created with a few mappings and settings like below.

Next thing to do is to start a full crawl. No incremental, that won’t work!

Now we can create our own Web Part. Create a new Visual Studio 2010 project, call it SortableCoreResultsWebPart. Add a reference to Microsoft.Office.Server.Search and add a new Web Part to the project, no Visual Web Part, just a regular. Name it SortableCoreResultsWebPart.

Open the SortableCoreResults.cs and overwrite the code with the following code.

    public class SortableCoreResultsWebPart : CoreResultsWebPart
    {
        [Personalizable(PersonalizationScope.Shared)]
        [WebBrowsable(true)]
        [WebDescription("Sort by this managed property")]
        [Category("MyProperties")]
        public string OrderByProperty { get; set; }

        [Personalizable(PersonalizationScope.Shared)]
        [WebBrowsable(true)]
        [WebDescription("Sort direction")]
        [Category("MyProperties")]
        public Microsoft.Office.Server.Search.Query.SortDirection SortDirection { get; set; }

        /// <summary>
        /// Override. First runs the base code, than collects the CoreResultsDatasource and
        /// sets the SortOrder property.
        /// </summary>
        protected override void ConfigureDataSourceProperties()
        {
            // only do stuff when search results are visible
            if (this.ShowSearchResults)
            {
                // run the base code
                base.ConfigureDataSourceProperties();
                try
                {
                    // if OrderByProperty is not set, use default behaviour
                    if (!string.IsNullOrEmpty(OrderByProperty))
                    {
                        // get the datasource and change the sortorder
                        CoreResultsDatasource dataSource = this.DataSource as CoreResultsDatasource;
                        dataSource.SortOrder.Clear();
                        dataSource.SortOrder.Add(OrderByProperty, SortDirection);
                    }
                }
                catch (Exception)
                {
                    // handle this error! and show a friendly error message
                }
            }
        }
    }

Don’t forget to add an using for Microsoft.Office.Server.Search.WebControls.

Run the thing and add the Web Part to the page. An error will pop up saying SrhdcNoKeywordException was unhandled, skip it by pressing F5 or clicking continue a couple of times.

Edit the Web Part, open the Location Properties and modify the scope to Discussions. Open Result Query Options and modify Fixed Keyword Query to contentclass:STS_ListItem_DiscussionBoard. Finally fill the OrderByProperty with Created and set a SortDirection.

 Save and refresh the page. Watch your web part sort like Dustin Hoffman in Rain Man!

You ever wanted to show external data in SharePoint? Do Arabs fart in the desert? Does Apple charge 200 dollars extra for a different color macbook?

Of course you want to show external data in SharePoint. But it isn’t as easy as it seems to achieve this. There are a few methods and every methods has it’s pro’s and con’s.

According to Microsoft the best method, and every SharePoint guru will agree, is Business Connectivity Services. This method is great for creating a seamless connection between SharePoint and your external data. It however has the big disadvantage that BCS can only be used in conjuction with the external list, and external lists cannot have additional columns. This means that a calculated column needs to be custom developed in the BCS model, which in turn means that it needs to be compiled, tested, deployed, etc. And this is pretty stupid because SharePoint has calculated columns out of the box with a custom list. Now, I´ve tried to get that BCS data into a custom list, but with no success. So then I started looking for a way without BCS and use SQL Server Integration Services(SSIS) instead. After googling for a while I found exactly what I was looking for.

http://fsugeiger.blogspot.com/2010/01/synchronise-sql-table-with-sharepoint.html

This solution can synchronize a database with a custom list. It however is one-way, so customized data in the list doesn’t get back into the database. But because it’s a custom list we can use calculated and other additional columns.

Prerequisites for this SSIS solution.
You need to have SQL Server Standard or higher with Integration Services enabled and Business Intelligence Studio installed.
Then you need the following plugin for the SharePoint list source and destination.
http://msdn.microsoft.com/en-us/library/dd365137(v=sql.100).aspx

I know, Sharepoint 2007 is pretty old. However, this week a client wanted FBA for his WSS 3 environment, so no problemo for the Sharepoint pro. I haven’t done a FBA config for Sharepoint 2007 before, so I did a bit of googling and couldn’t find a very explaining article that covers the whole configuration. There were a few handy sites, including the MSDN, which helped me out getting what I needed.

Further on it will be explained in detail, but here is a summary already:

  • ASP.NET membership database (aspnet_regsql.exe)
  • Extended web application with zone internet
  • Edit web.config of the default web application and the extended web application
  • Install http://fba.codeplex.com/ wsp

Install ASP.NET membership database

Run the tool aspnet_regsql.exe at C:WindowsMicrosoft.NETFrameworkv2.0.50727

Choose the option to configure SQL Server for application services.

Choose the name of the database server in the server field. Choose Windows authentication and type a database name in the Database dropdown field. In this case we creat a database with the name fbadb.

Click next and Finish to complete the creation of the membership database.

Set the right SQL permissions

Because we wan´t to use integrated security with the connection we need to give the application pool identity the appropriate permissions on the membership database. First of all we need to know what the application pool identity is. For that you can go to the IIS Manager and select the Sharepoint site.

Click Advanced Settings… and note the Application Pool

Then click on Application Pools and select the noted application pool

Click Advanced Settings … and note the identity, in our case this is the Network Service

Now, go to SQL management studio and give that user the db_owner permissions on the FBA database we just created.

Extended web application with zone internet

Open Central Administration. Go to Create or extend web application in Application Management and click Extend an existing web application. In web application select the web application you wish to create FBA for.

However we are extending a web application, we need to create a new IIS web site so leave that option on.
I want to  create a subsite for the FBA authentication, so I did set the port back to port 80 and set the host header to extranet.mydomain.com

Allow anonymous authentication and here you can also choose to use SSL or not. I choose not to use SSL. The last thing to do is to set the zone to Internet.

You can go to the url of the extended web application to check if the configuration works.

Last thing to do is to enable FBA on the extended web application. Go back to Central Administration and then click Authentication providers under Application Security. Then click on the Internet zone.

In this screen select the Forms authentication type. Two new fields appear: Membership provider name and Role manager name. This are the names of the membership and role provider we are going to configure in the next step. I’m using FBA for Membership provider name and FBARole for the role manager name.

Click Save and all central admin settings are set.

Edit web.config of the default web application and the extended web application

Next thing to do is to add a few items to the web.config of the web application and the extended web application:

  • Peoplepicker wilcard for FBA
  • Connectionstring for the FBA Database
  • Membership provider for FBA Users
  • Role manager for FBA Roles

Go to the web.config of the web application (not the extended web application) and search for the </sharepoint> closing tag and the <system.web> starting tag; they should be next to eachother.

Just above </SharePoint> you find the following piece of code:

<PeoplePickerWildcards>      
  <clear />      
  <add key="AspNetSqlMembershipProvider" value="%" />      
</PeoplePickerWildcards>
replace this with the next code:
<PeoplePickerWildcards>      
  <clear />      
  <add key="AspNetSqlMembershipProvider" value="%" />      
  <add key="FBA" value="%" />    
</PeoplePickerWildcards>

Now add a new ConnectionString section between the </sharepoint> and <system.web> tags:

<connectionStrings>    
  <add name="fbaSQL" connectionString="server=localhost;database=fbadb;Trusted_Connection=true" />  
</connectionStrings>

Because I run the database and Sharepoint on the same server I’m using localhost. If you are using a different database server you need to replace localhost with the database server name or ip here, pretty obvious.

Last thing to do is to add a membership and role section in the <system.web> tag. Add the following piece of code just below <system.web> and above <securityPolicy>:

<membership defaultProvider="FBA">      
  <providers>        
    <add connectionStringName="fbaSQL" applicationName="/" name="FBA" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"            
      enablePasswordRetrieval="false"            
      enablePasswordReset="true"            
      requiresQuestionAndAnswer="false"            
      requiresUniqueEmail="true"            
      minRequiredPasswordLength="5"            
      minRequiredNonalphanumericCharacters="0"            
      passwordFormat="Hashed" />      
  </providers>    
</membership>    
<roleManager enabled="true" defaultProvider="FBARole">      
  <providers>        
    <add connectionStringName="fbaSQL" applicationName="/" name="FBARole" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>      
  </providers>    
</roleManager>

This web.config is done. Now do the same for the web.config of the extended web application.

Install http://fba.codeplex.com/ wsp

Download FBAManagement.wsp and Deploy.cmd from http://fba.codeplex.com/releases/view/2986 and save both files into the same folder. We need to edit some values in the Deploy.cmd so once downloaded go to the folder and rightclick Deploy.cmd and click edit. Now replace both http://aspnet with http://<yoursharepointsite>. Also remove the bin from “stsadm -o addsolution -filename binFBAManagement.wsp” so it reads only “stsadm -o addsolution -filename FBAManagement.wsp”. The code should look like this:

@echo Deploying FBAManagement solution

@set PATH=C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN;%PATH%

stsadm -o deactivatefeature -name FBAUserRoleManagement -url http://mysharepoint -force
stsadm -o deactivatefeature -name FBAConfigurationManagement -force

stsadm -o retractsolution -name FBAManagement.wsp -immediate
stsadm -o execadmsvcjobs
stsadm -o deletesolution -name FBAManagement.wsp -override
stsadm -o execadmsvcjobs

stsadm -o addsolution -filename FBAManagement.wsp
stsadm -o execadmsvcjobs

stsadm -o deploysolution -name FBAManagement.wsp -immediate -allowgacdeployment
stsadm -o execadmsvcjobs

stsadm -o activatefeature -name FBAConfigurationManagement
stsadm -o activatefeature -name FBAUserRoleManagement -url http://mysharepoint
stsadm -o execadmsvcjobs

Save the file and execute it as administrator. Don’t be scared with the file not found and solution not found messages for the first few lines, because thats entirely normal.

Result

All configuration is done. Go to the site settings of the sitecollection. Under site collection administration you find two new links. With Manage FBA Users you can add and edit users and with Manage FBA Roles you can add and edit roles, which is pretty straightforward.

To test FBA you can add a user and give the user some permissions by adding it to the Team Site Members group. Now, login with the user on the extended web application and see the result.

I have done a few years of sharepoint developing now. When I began to write small webparts in Sharepoint I was very enthusiastic about the features of the Sharepoint framework and thought it was as easy and solid as writing ASP.NET. Now I know better, developing Sharepoint masterpages, webparts, workflows, etc. is not all beer and skitties. Also when you haven’t encountered any troubles yet, you will get to it! So don’t waste your effort on developing the wrong way.

Here are some points of what I consider “Sharepoint 2007 developing and designing: Best practices”

Developing

  • Sharepoint Designer is crap. It´s instable and unfinished. So, try to avoid it where possible. Try to use Visual Studio instead.
  • Use Microsofts Visual Studio extensions for WSS. Always use the latest version: CTP, Beta or RC? It all did work for me, so just use it. Here’s a link to the latest version: http://www.microsoft.com/downloads/details.aspx?familyid=FB9D4B85-DA2A-432E-91FB-D505199C49F6&displaylang=en
  • Always use embedded resources, never copy your images, css or javascripts to a folder in the 12 hive. An article on how to use embedded resources can be found here: http://aspalliance.com/726
  • Important! Before developing get you’re Functional Requirements straightened out. It is very important to know if you are going to create an application that is going to be updated (frequently) AND/OR needs to work in other environments, for example an ASP.NET environment AND/OR if it needs to be compatible with other/future versions of sharepoint. If it does, and the most cases will be, then mind the following points
    • Try to use the Sharepoint controls in the Microsoft.SharePoint.WebControls namespace as less as possible. Some controls contain some bugs and off course this way you can easily use the same application in an ASP.NET webpage or implement it in another version of Sharepoint.
    • Create a tiered application. Create for every tier a new project. Create a SharepointData project which handles all data between your project and sharepoint, like users, groups, properties, lists, libraries
    • Try to avoid the use of the IWebEditable interface and the EditorPart class. Handle configurations in a second webpart where only an admin can touch it.

Designing (Master pages)

  • Again. SharePoint Designer is crap, but with designing a master page we cannot evade the piece of beta-software Microsoft has shipped with SharePoint. So, good luck with the frustrations.
  • A disadvantage of Sharepoint is that you cannot deploy a masterpage centralized, you have to do a copy-paste job to create the same look on all sites. Fortunately I have a feature for globally deploying masterpages. In a few steps you can build your own feature, it’s very easy. Here is the article: http://www.dontpapanic.com/blog/?p=36
  • WARNING! NEVER EVER overwrite the default masterpage located at 12TEMPLATEGLOBAL but use it only to copy, it would be wise to make a backup of it.
  • I discourage the use of a minimalistic masterpage.  Use the default sharepoint masterpage located at <%System Drive%>Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEGLOBAL as you’re base masterpage. Generally implementing a new design will take less effort when tweaking the default masterpage, than creating a new one based on a minimalistic base masterpage.

These are the important points that have been in my head for a while, finally they got stored in HTML and are they readable for others. Did I miss something or do you have any tips yourself? I ‘ll be glad to know.