FBA för SharePoint Foundation 2010

SharePoint Foundation 2010

Uppsättningen av FBA för SPF 2010 påminner mycket om hur man gjorde i version 3. Skillnaden är att SP 2010 använder Claims Based Authentication där traditionell FBA, med en SQL-serverbaserad användardatabas, är ett sätt att autenticera användarna. Andra metoder kan vara Live ID, G-Mail eller federation med ett annat AD. Det som krävs för FBA med användarna i en egen SQL-databas är:

• Security Token Service (STS). Detta är en Web Service som finns inbyggd i SPF 2010.
• SQL Server (vanligtvis samma instans som man använder till övriga SP-databaser) där man skapar en databas som ska innehålla användarna.
• De inbyggda funktionerna för Membership och Roles Providers i .NET Framework.
• Modifiering av web.config tillhörande Central Administration, STS och andra webbapplikationer som ska använda FBA.
• En webbapplikation med en site för att hantera användare. Jag använder den tekniken för att undvika en del problem som kan uppkomma (workaround...).
• En webbapplikation med en site som konfigureras att använda Claims och de Roles och Membership Providers som vi sätter upp.

Installera SQL Server och SharePoint Foundation (detta förutsätter att servern är domänansluten. Om den inte är det så gör man en standardinstallation istället och hoppar över installationen av SQL Server 2008 R2 Express.)

1. Se till att de konton som ska köra SP-tjänster är lokala administratörer på servern.
2. Kör installationsprogrammet för SharePoint Foundation och välj att installera alla obligaoriska komponenter. Detta spar mycket tid.
3. Installera SQL Server 2008 R2 Express x64
   1. Inga speciella inställningar, jag kör helt default. Lägg görna till ett extra adminkonto för säkerhets skull.
   2. Se till att datadisken inte är för liten och helst inte är systemdisk.
   3. Öppna SQL Management Studio, lägg till de konton som ska köra SP-tjänster och ge dem rollerna dbcreator och securityadmin förutom public.
4. Installera SharePoint Foundation 2010
   1. Välj att installera en Server Farm.
   2. Vid Server Type, välj Complete eftersom vi redan har en annan, bättre version av SQL Server installerad.
   3. Kör konfigurationsguiden för SharePoint och ange:
      1. Namnet på SQL Serverinstansen.
      2. Namnet på konfigurationsdatabasen.
      3. Servicekontot för Central Administration vilket helst är ett AD-konto som inte används till något annat. Här används domain\sps2010_centraladmin
      4. Portnummer till Central Administration-siten (vi använder port 5000)
      5. Autenticiering, vanligen NTLM.

Skapa FBA-användardatabasen

1. Gå till mappen %systemdrive%\%windir%\Microsoft.NET\Framework64\v2.0.50727 och kör applikationen aspnet_regsql.exe

1. Ange vad SQL-instansen heter och ge databasen ett namn, här kallas den FBADB.
2. Öppna SQL management Studio och ge de konton som kör SP-tjänster och det konto som installationen körs med rollen db_owner på den nyligen skapade databasen FBADB.

Konfigurera Central Administration för FBA

1. Öppna IIS Manager och klicka på den site som tillhör Central Administration.
2. Dubbelklicka på Connection Strings och klicka på Add... i Actions-fältet. Skriv in databasserverns och databasens namn och ange Use Windows Integrated Security.

1. Skapa en Roles Provider. Klicka på Central Administration igen och dubbelklicka sedan på Providers. Se till att .NET Roles är vald vid Feature. Klicka sedan på Add..

1. Vid Type använder man SqlRoleProvider.
2. Namnet är FBARoles.
3. Vid ConnectionStringName väljs FBADB.

1. Skapa en Membership Provider. Klicka på Central Administration och dubbelklicka sedan på Providers. Välj .NET Users vid Feature och klicka sedan på Add...

1. Vid Type ange SqlMembershipProvider.
2. Namnet är FBAMembers.
3. Välj de egenskaper som ska gälla för Providern.
4. Välj FBADB vid ConnectionStringName.

Konfigurera Security Token Service (STS)

1. Gör på samma sätt som för Central Administration och konfigurera Connection string, Role Provider och Membership Provider.

1. Öppna Central Administration och skapa en webbapplikation som ska användas för att administrera FBA-användarna. Använd en port bland administrationssiterna, t.ex. 5001
2. Öppna IIS Manager och konfigurera denna på samma sätt som de båda tidigare. Connection string, Role Provider och Membership Provider.
3. Dubbelklicka på .NET Roles, det kommer en varning som säger att providern inte är betrodd. Ignorera den och klicka på Set Default Provider... vid Actions.

1. Ange FBARoles som Default Provider.

1. Gör sedan samma sak för .NET Users. Ange då FBAMembers som Default Provider.
2. Lägg till en roll och en användare genom att klicka på Add... vid Actions.

1. Öppna Central Administration och skapa en ny webbapplikation som användarna ska komma åt. Använd Claims Based Autentication och ange FBAMembers och FBARoles i respektive fält i formuläret.

1. Skapa en Site Collection och lägg till en AD- och en FBA-användare som Site Collection Administrators.

1. Navigera till den nya siten, välj autenticiering och logga in.

1. Den nya siten kommer att vara tillgänglig för både externa (FBA) och interna (AD) användare när de fått behörighet att komma åt den.

FBA for SharePoint Foundation 2010

Here is a great post on the basic configuration of FBA for SharePoint Foundation using the IIS manager. I've done this a couple of times and encountered an issue when changing back to the default membership and role provider on the site that should support FBA. Therefore I use this little workaround with a web application only used to manage roles and users in the IIS manager.

I usually put the Central Administration site on port 5000 so I went ahead and put the user admin site on port 5001. That site is then only used to manage roles and users inside the membership database via the IIS manager. It should be set to use the FBA providers you set up when following the steps outlined in the post above. That will enable you to manage roles and users in the membership database via this site, but it will not be available to log in to. That makes it an admin-only site.

Now you can create a new web application which will host your FBA enabled sites. When you configure those to support FBA you should not change the default role and membership providers to your FBA providers. Just skip that step and you'll be fine logging on to the sites using FBA or Windows integrated authentication.

This is of course only necessary if you plan to use the IIS manager for role and user management. If you use something else, like the MembershipSeeder or maybe your own web part, you'll be fine with just the standard setup.

Office 2010 x64 Beta and SharePoint Designer 2007

For whatever reason the Office 2010 x64 Beta release will not install if it detects another Office product in 32-bit that has been installed on the computer before the 2010 suite.

This becomes a problem if you would like to use for example SharePoint Designer 2007, witch only is avaliable as a 32-bit installation.

The solution is to install the Office 2010 x64 suite before installing your 32-bit program and all should be fine.

Installation av MOSS med svenskt språkpaket på Windows 2008 Server x64

Att installera språkpaket för SharePoint ska inte vara någon stor utmaning i vanliga fall men om det rör sig om MOSS 2007 SP1, Windows 2008 Server och det svenska språkpaketet så blev det lite trassel innan det ville sig. Jag hittade inte någon info om detta så jag skriver några rader om det.

Installationen av språkpaketet för WSS gick som det skulle men för MOSS fungerade det inte. Inga felmeddelanden eller händelser i loggen uppträdde. I en virtuell testmiljö gjorde jag följande test:

1. Installera MOSS 2007 enligt konstens alla regler och kör config-guiden men stanna när CA kommer igång för första gången.

2. Installera språkpaketet för WSS, MOSS och de resp. servicepacken.

3. Kör vidare med konfig i CA (starta tjänster, konf SSP mm).

Det löste mitt problem

Installing SharePoint solutions using a batch file

I'm currently comparing some different reporting and statistics applications for MOSS and WSS and thought I would share some thoughts on that. I'm going to start off with a product from MAPILab called MAPILab Statistics which is available as a 30-day trial from the MAPILab website: http://www.mapilab.com/download/crm/?MAPILabSharePointStatistics

This post covers the installation of the solution package and some tips on how to use batch files to simplify deployment and activation of SharePoint solutions.

Included in the download from MAPILab are the MAPILab solution package called MAPILabSharePointStatistics.wsp, some deployment guides and licensing documents. The install guide is a PDF file which describes how to add, deploy and activate the solution using the stsadm.exe tool. These steps are very easy to follow from the command prompt, and if you know for sure that you're going to install the solution one time only, there's not really much to gain from using the batch file technique outlined below. For the rest of us, that plan on trying this solution in a few different virtual farms and hopefully deploy it to a lot of customer sites, this might be a good idea.

Create a batch file with the following stsadm commands:

1^st row - stsadm -o addsolution -filename MAPILabSharePointStatistics.wsp

2^nd row - stsadm -o deploysolution -name MAPILabSharePointStatistics.wsp –allowgacdeployment –immediate

3^rd row - stsadm -o displaysolution -name MAPILabSharePointStatistics.wsp

4^th row - add a PAUSE to have the process paused and make sure that the solution has been deployed properly. Hit any key to continue.

5^th row -stsadm –o copyappbincontent (This row copies some files to the Config folder in the 12-Hive.)

6^th row - stsadm -o activatefeature -name MLSiteActions –url http://moss01 (change the URL to match your environment)

When combined the batch file should look like this:

More on the MAPILab Statistics application is coming to this blog soon.

Crawl issues in MOSS 2007

Server settings:

Windows Server 2003 standard edition SP1
SQL Server 2005 standard edition
MOSS 2007 standard edition SP1 (12.0.0.6219, find your version here http://www.mindsharpblogs.com/penny/articles/481.aspx)

 The SharePoint server logged lots of event id 537 which is an audit failure. In this case it means that something is fishy in the connection between the crawl engine (run by the service account) and the site colletion.

Event ID 2436 and along with it this error message was logged:

http://intranet

Access is denied. Check that the Default Access Account has access to this content, or add a crawl rule to crawl this content.

(The item was deleted because it was either not found or the crawler was denied access to it)

In this case access is denied because the URL http://intranet is mapped to the loopback adapter of the SharePoint server and not because permissions are missing in the context. This means that the crawl engine is trying to connect to the loopback address (127.0.0.1) which isn’t allowed.

This a security feature in Windows Server 2003 SP1. If some of you run your Central Administration site and the crawl on separate servers you probably don’t get these issues.

The solution to this is to apply the registry fix described in MS KB896861 (http://support.microsoft.com/kb/896861)

Remember to back up the registry before making any changes. In this case, right-click the Lsa-folder and Export it to a location on the server or the network.

These are the steps outlined as method 2 in the KB article:
Disable the loopback check

1.       Click Start, click Run, type regedit, and then click OK.

2.       In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3.       Right-click Lsa, point to New, and then click DWORD Value.

4.       Type DisableLoopbackCheck, and then press ENTER.

5.       -click DisableLoopbackCheck, and then click Modify.

6.       In the Value data box, type 1, and then click OK.

7.       Quit Registry Editor, and then restart your computer.

Att dela upp en site-kollektion på två olika content databaser…

Jag fick ett uppdrag som gick ut på att skapa en form av redundans i en farm som hade servrar utspridda på tre olika kontor med ganska stort geografiskt avstånd. Spontant tycker man ju att om det finns en farm så finns det en config-databas, alltså ingen redundans…men det går att komma runt med ganska enkla medel. Man behöver faktiskt inget stort SQL-kluster som ingen egentligen förstår sig på. Nu ska vi tillägga att funktionen som detta ger inte är testad skarpt ännu, den ordinarie SQL-servern har inte varit offline på riktigt. Kör inte detta på en live miljö, prova gärna med livrem och hängslen och hör av dig med resultatet ;)

Vi gjorde så här:

1. Installerade MOSS på de båda WFE:erna och konfigurerade en ny farm på den ena med Central Administration, SSP och My Site. Den andra kopplades till den nya farmen och kommer delta i Crawlning. Två servrar med MOSS 2007 alltså.
   
   
2. Intranätet som fanns hade en tydlig uppdelning mellan de båda kontoren och det gick enkelt att identifiera vilka siter som var viktiga för vilket kontor. De som var aktuella på kontor A exporterades och importerades till en egen site kollektion med en egen content-databas. De övriga fick vara kvar i sin ursprungliga struktur vilken kopplades in som content-databas i den site-kollektionen.
   
   
3. Databaserna ligger på alltså på två SQL-servrar som båda har SQL 2008 Standard installerat. Det gör att man kan använda Microsofts nya teknik för spegling av databaser direkt med SQL Man Studio. Det har gått i tidigare versioner men är nu dramatiskt förbättrat. Dessa servrar står på varsin sida om det stora avståndet och hostar varsin content-databas med respektive kontors egna content. De innehåller också varsin version av config-databasen som alltså spelglas från den ena (Master) till den andra (Mirror).
   
4. En femte server står på ett tredje kontor med uppkoppling mot de båda SQL-servrarna och agerar som Witness vilket betyder att den har som uppgift att hålla koll på vilken av SQL-servrarna som är Master. Om den ordinarie inte går att nå så kommer vittnet utse den andra som master. Det fina med det är att användarna inte kommer att märka det här lilla glappet eftersom båda SQL-servrarna är uppdaterade hela tiden. När den ordinarie Master-SQL-servern kommer tillbaka online så kommer den att vara Mirror åt den andra och ta ikapp det som den missat under tiden som den var offline.

Vad ger då detta? Man får faktiskt feltolerans på alla databaserna i farmen. Men det finns ett problem, nämligen vittnet. Den punkten är inte redundant i det här exemplet. Det kan den naturligtvis också vara men någonstans ska man ju dra gränsen. Den får stå i en väl övervakad serverhall med support 24/7.

Nu kommer säkert alla SQL-experter säga att detta inte kommer fungera så bra i praktiken som på papret och jag kan inte säga emot faktiskt. Tanken med feltolerans är i grunden bra men om man har så kritiska datafunktioner i sin SharePoint-farm så kanske man hellre lägger en massa kraft och möda på att säkra sin uppkoppling mellan kontoren och få en hög grad av tillgänglighet den vägen.

Gratis SharePoint med SQL Express

Det finns en annan aspekt hos den här tanken vilken inte rör MOSS 2007-installationer i första hand utan de som har WSS på SQL-Express. De har inte någon licenkostnad på den interna SharePoint farmen men en gräns på 4 GB på sina SQL-databaser som de inte kan gå runt utan att uppgradera till en riktig SQL-version för dyra pengar.

WSS och SQL-EE är ju helt gratis om man har en Windowsserver med CAL:ar i sitt nätverk. Med lite planering och trixande kan man med denna teknik bygga väldigt stora WSS-miljöer utan att betala någon SQL-licens genom att dela upp sina content-databaser i bitar som inte blir större än 4 GB. Man får mer administration, det är svårare att göra backuper, man kommer att behöva ha mer övervakning och allt blir lite jobbigare... Men det är gratis, Microsoft-teknologi på högsta nivå helt lagligt gratis. Släng in MS Search Server Express i den mixen så har man en riktigt kraftfull farm som inte kostar mer än lite extra svett och kanske tårar, av lycka alltså!

Go have fun now!

Word-mall med fält kopplade till metadata

Med en Word-mall i ett dokumentbibliotek kan man koppla metadata till fält i dokumenten på ett tidsbesparande sätt. Exempelvis om man ofta skapar dokument som är uppbyggda på samma sätt.

För att det här exemplet ska fungera krävs att man har SharePoint Services 3.0 eller MOSS 2007 och Microsoft Office Word 2007 installerat.

Lägga till en ny mall

1. Skapa en Word-mall och spara den.
2. Öppna dokumentbiblioteket som ska ha den nya mallen.
3. Klicka på Actions – Open with Windows Explorer.
4. Öppna mappen Forms och kopiera din Word-mall dit.
5. Klicka på Settings – Document library Settings – Advanced Settings.
6. Vid Document Template, skriv in den relativa URL:en till den nya mallen och klicka på OK.

Gå tillbaka till dokumentbiblioteket och klicka på New för att se att den nya mallen öppnas i Word.

Skapa kopplingar mellan fält i mallen och metadata i dokumentbiblioteket

Skapa kolumner med de metadata som ska ingå i mallen. I det här fallet är det Namn, Adress, Telefon och E-Post.

1. Öppna Word och klicka på Office-knappen.
2. Klicka på Word-alternativ och sedan på Anpassa.
3. I listan Välj kommandon från, Välj Alla kommandon och lägg till Dokumentegenskap. Den knappen kommer att dyka upp i verktygsfältet längst upp, precis till höger om Office-knappen.

1. Öppna ett nytt dokument från dokumentbiblioteket vilket bygger på din mall som du just lagt till.
2. En list med dokument egenskaper kommer att dyka upp och spegla de kolumner med metadata som du lagt till i dokumentbiblioteket.
3. Med hjälp av knappen Dokumentegenskap kan du nu placera fält i dokumentet på de ställen där dessa ska visas.

Spara detta dokument som en Word-mall lokalt på datorn. Kopiera det till mappen forms i dokumentbiblioteket på samma sätt som i punkt 3 och 4.

Testa nu att öppna ett nytt dokument från biblioteket, ange namn och spara det.

Klicka på Edit Properties och fyll i Adress, Telefon och E-post. Öppna sedan dokumentet i Word och se att rätt metadata fyllts i på rätt ställe i dokumentet.

Create Site Collection with 3 Sub Sites using STSADM

This set of stsadm commands lets you create a site collection with a document workspace and 3 different sub sites with some other site templates. I always save work like this in a bat-file so that I can reuse it later. That's really useful you if you're performing similar operations frequently.

Create a bat-file with the following commands (the bold parts are where you put your specifics):

stsadm -o createsite -url http://toursrv:20000/ -owneremail admin@tour.org -ownerlogin

tour\administrator -ownername Administrator -lcid 1033 -sitetemplate STS#2 -title "Site Collection"

-description "Site Collection for the Nordic divisions"


stsadm -o createweb -url http://toursrv:20000/Sweden -title "Sweden" -sitetemplate MPS#0 -description

"Meeting Workspace for the Swedish division"


stsadm -o createweb -url http://toursrv:20000/Norway -title "Norway" -sitetemplate STS#0 -description

"Team Site for the Norwegian sales team"


stsadm -o createweb -url http://toursrv:20000/Finland -title "Finland" -sitetemplate MPS#0

-description "Meeting Workspace for the Finnish team leaders"

Pause

When reviewing All Site Content you'll see the following sites:

Note. When you create a site collection you need to submit more info than when you create a single site. In this example I've added the owner e-mail, owner login and owner name. I've also added the locale (lcid 1033) which is English. In all the of the createweb commands I've added url, title, site template and description. All of those are not mandatory, you'll be fine with just the url, but it's a bit more neat this way, right!?

Create Sites with STSADM

Creating sites is something administrators usually do from the Site Actions menu in SharePoint. This is easy and intuitive and for creating a few sites now and then it works very well. However, if you're setting up many sites or site collections frequently you know that it takes some time to do this with the GUI in SharePoint. If you're one of those people that don't do any work that you don't absolutely have to (like myself…), this post might be useful for you.

Create multiple Sites

First, let's create a few sites using the createweb command. I use a bat-file for this to make the work reusable.

1. Create a bat-file with the following commands:

stsadm -o createweb -url http://toursrv/SalesTeamSite -sitetemplate STS#0 -title "Sales Team Site" -description "This is the Team Site for the Sales Team"

From here it's easy to just copy the first command and change the properties.

stsadm -o createweb -url http://toursrv/FinanceTeamSite -sitetemplate STS#0 -title "Finance Team Site" -description "This is the Team Site for the Sales Team"

stsadm -o createweb -url http://toursrv/HRTeamSite -sitetemplate STS#0 -title "HR Team Site" -description "This is the Team Site for the Sales Team"

stsadm -o createweb -url http://toursrv/ITTeamSite -sitetemplate STS#0 -title "IT Team Site" -description "This is the Team Site for the Sales Team"

stsadm -o createweb -url http://toursrv/SupportTeamSite -sitetemplate STS#0 -title "Support Team Site" -description "This is the Team Site for the Sales Team"

pause

Some clarifications

-sitetemplate STS#0 is the Team Site template. The other default site templates are:

• STS#1: Blank Site
• STS#2: Document Workspace
• MPS#0: Basic Meeting Workspace
• MPS#1: Blank Meeting Workspace
• MPS#2: Decision Meeting Workspace
• MPS#3: Social Meeting Workspace
• MPS#4: Multipage Meeting Workspace
• BLOG#0: Blog
• WIKI#0: Wiki Site

(You can use custom templates such as those from the Fantastic 40 bundle as well. These are just the built-in templates)

When it's finished, click view All Site Content and review your sites.

Simple STSADM backup and restore operation

Using stsadm.exe for backup purposes is convenient and provides more granularity than the backup tool found in the SharePoint Central Administration console. You can create a full fidelity backup for entire site collections or chose to export individual sites. The latter is something that CA can't do. In this post both the backup and export option is covered and combined to create a powerful backup/restore procedure.

stsadm comes as a command line tool as you install SharePoint and (If you installed SharePoint on the C drive) resides in this directory: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN. You need to add that path to your environment variables to get these examples to work.

backup / restore

My server has a site on port 20000 that needs to be backed up.

1. Create a folder where your backup files will be stored.
2. Create a bat-file with the below stsadm command. (Makes it easy to reuse or schedule your backup.)

stsadm -o backup -url http://toursrv:20000 –backupmethod full -filename c:\backup\20000\complete.bak
pause

I use the pause command to keep any error messages in view if something should go wrong.

1. Run the bat-file and your site is backed up.

When disaster strikes you want to be able to restore your site. Let's create a bat-file for that purpose as well.

1. Create a bat-file with the following stsadm command.

stsadm -o restore -url http://toursrv:20000 -filename c:\backup\20000\complete.bak –overwrite
pause

1. Run the bat-file and your site is restored.

export / import

Now it's time to export individual sites from one site collection and import them into another one. This is a scenario that may arise when you develop a site in your testing environment and want to transfer it to the production environment.

1. Create a bat-file with the following stsadm command.

Stsadm –o export –url http://toursrv:20000/finance -filename c:\backup\20000\finance.bak
Pause

1. Now it's time to import this site into the production environment. Create a bat-file with the following commands.

Stsadm –o import –url http://toursrv/finance -filename c:\backup\20000\finance.bak
Pause

Note that the production site is located on port 80 and the developing site on port 20000. The sub site 'Finance' is now created in the production environment.

Combining these operations

The backup option provides a full backup of top level sites and the export option can backup individual sub sites. To create a powerful backup solution you could combine the two. Let the backup bat-file run every night at 23:30 and have the export bat-file run more often even during business hours on the more frequently updated sites. Use the Windows Scheduler to get your bats running at times of your choice.

Branding SharePoint by overriding Core.css classes

Branded SharePoint sites sometimes don't really benefit much from the native SharePoint design. If you apply a custom CSS-file for your own content you might as well redesign some of the built-in stuff.

EditForm.aspx is the page for editing metadata on items in lists and libraries.

First I changed the font of the labels Name, Title and Process from Verdana (default) to Calibri at 12px.

.ms-formlabel{
font-family:calibri;
font-size:12px;

(As you can see I'm not adding all properties from this class in Core.css to my css-file,  only those I want to change.)

_______________________________________________________________________________

Next, the text in the top tool bar to Calibri at 8pt.

.ms-toolbar,.ms-viewtoolbar,.ms-formtoolbar,.ms-toolbarContainer{
font-family:calibri;
font-size:8pt;

_______________________________________________________________________________

Last I want to change the font for the description text and the footer where you see the created modified details.

.ms-descriptiontext{
font-family:calibri;
font-size:8pt;

_______________________________________________________________________________

There is one more element on this page that's been altered. Take a closer look at the small star indicating a required field. The color is changed from red to blue.

.ms-formvalidation{
color:#0000ff;

SharePoint Database Migration