Hjälp! Kan inte hitta mina SharePoint Databaser i SQL Server Embedded Edition (Microsoft##SSEE)

Om du har installerat WSS 3.0 eller MOSS 2007 på en Windows 2008 kärra, så kanske du inte hittar dina databaser när du försöker att koppla upp dig via SQL Server Management Studio Express. Don’t Panic!
Så här går du tillväga:

1. Den fysiska sökvägen där Windows lagrar SharePoint databaserna är:
C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data

2. Se till att backa upp denna map

3. Öppna SQL Server Management Studio Express och i Server name, skriv texten nedan:
"\\.\pipe\mssql$microsoft##ssee\sql\query" utan citationstecken

Vola!

Unified Logging Service (ULS)

Unified Logging Service (ULS)

Unified Logging services är en lösning för MOSS 2007 som gör det möjligt för administratörer att granska loggarna från adminverktyget. Så här installera du det i SharePoint:

1. Ladda ner filen LogViewer.wsp (Log Viewer Feature) från Codeplex

2. Rulla ut filen med hjälp av stsadm
stsadm -o addsolution -filename "SÖKVÄG\logviewer.wsp"

3. Starta SharePoint 3.0 Central Administration, gå till fliken Operations, välj Solution Management. Då kommer du att kunna se din lösning. Rulla ut lösningen. När lösningen är utrullad kommer du att kunna se alla dina loggar under Operations, Utilities, View Unified Logging Service.








Det är bara att installera och njuta!

SharePoints Terminologi

Det är lördagskväll, sitter och njuter av en kopp varm kaffe, mina tankar tog mig till den begreppsförvirring som råder inom SharePoints terminologi . Tänkte skriva några rader om begreppen och sambanden för er som inte kan somna om nätterna utan att tänka på SharePoint :)

På toppen av en SharePoint hierarki har vi en så kallad ”Farm”. En farm är en samling servrar som tillsammans bildar vår SharePoint lösning. Det finns tre sorts farmar, en liten, mellan och stor. I en liten farm, finns endast en webbserver (Kallas Web Front End, WFE) och en Databasserver (SQL Express, Standard eller Enterprise). I en mellan farmlösning finns åtminstone två WFE, minst en index server och minst två databasservrar för högtillgänglighetens skull. I en stor farm delar man helst på WFE och Query tjänsten. Det är också bra ur prestanda synpunkter att inte direkt söka och indexera de WFE servrar som hostar våra siter, men istället sätta upp en extra WFE, ta ut den ur vår lastbalanserade webbfarm och indexera dess innehåll. Databaserna skyddas då med hjälp av klustring (Clustring), spegling (Mirroring) och kan kompletteras med log shipping.

I vår SharePoint farm har vi ett antal WFE. Varje WFE består i sin tur av ett antal webbapplikationer (Web applications). Tidigare kallades dessa ”Virtual Applications” eller ”Web Sites”. Exempel på dessa webbapplikationer är den Centrala administration siten, Content siten eller Shared Services Provider siten. För varje webb applikation i WFE så skapas en IIS site med egen applikationspool.
För varje av dessa webbapplikationer finns en eller flera databaser som hostas av våra databasservrar i farmen.

Okej, varje databas består av ett antal ”Site Collections”. På det sättet kan vi säga att varje Webbapplikation består av ett eller flera Site Collections (Exempel på Site Collection är intranätportalen, Internetportalen, Wikis, bloggar). En databas kan innehålla max 50,000 Site Collections. Det är på Site Collections nivå som administratörer kan sätta Quota, ändra Regional Settings, sätta statistiken och behörigheter. Alla inställningar som sätts på denna nivå ärvs ner till alla underliggande siter.

Så, ett Site Collection i sin tur består av ett antal siter. En Site Collection kan innehålla max 250,000 siter (Exempel på en site kan vara Marknad under vår Site Collection som heter Intranätportal). En site kan innehålla max 2000 subsiter. Våra subsiter kan då i sin tur bestå av en eller max 2,000 lister. En list är en samling av ett antal dokument eller artiklar (Items). En list kan innehålla max 5 miljoner sådana filer, dokument eller artiklar (Varje artikel kan vara en bild, en kalenderbokning eller en fil). En undersökningssida på intranätet är ett exempel på en list. Ett annat exempel är så kallad ”Document Library”, vårt dokumentbibliotek som kan innehålla max 5 miljoner dokument. Ett dokument i WSS 3.0 eller MOSS 2007 får max vara 2 GB stort.

Här nedan är en kort sammanfattning:
Varje SharePoint lösning består av en eller flera farmar
Varje Farm består av en eller flera WFE servrar
Varje WFE består av en eller flera Webbapplikationer
Varje webbapplikation består av en eller flera Site Collections
Varje Site Collections består av en eller flera Siter
Varje Site består av en eller flera subsiter
Varje Subsite består av en eller flera listor
Varje Lista består av en eller flera Artiklar, filer eller bilder

WSS 3.0 i Windows Server 2008

Microsoft har i Windows Server 2008 RC0 valt att ha WSS 3.0 inbakat i operativsystemet, som en roll vilken administratörer kan välja att installera. Detta kommer att försvinna i RC1 av Windows Server 2008. WSS 3.0 kommer att vara tillgängligt för nerladdning via Microsofts hemsida och fortsätta att vara kostnadsfritt. samma CALS (Client Access Licens) som används för Windows kan användas för WSS.

Första anledningen till borttagningen är att Microsoft vill särskilja på Operativsystemet och WSS. En annan anledning är att MOSS 2007 går ej att installera direkt på en Windows Server 2008 utan att först WSS 3.0 installeras. Väljer man att installera WSS 3.0 i vanligt läge, så installeras Windows Interna Databas, vilket är en SQL Express 2005. Detta innebär att även när vi sedan lägger på MOSS 2007, är vi fortfarande tvungna att fortsätta använda den databasen. SQL Express 2005 är känd för sin databasbegränsning på 4 GB och ungefär 30 samtida användare.

Microsoft rekommendation till sina kunder är att avvakta med att installera WSS 3.0 på RC1, och invänta på RTM:en istället. I dagsläget går det ej att installera MOSS 2007 utan att först ha installerat WSS 3.0, men med SP1 inbakat i MOSS 2007 (slipstream), kommer det att fungera.
Styrkan med Windows Server 2008 som plattform för WSS 3.0 eller MOSS 2007
• Ökad säkerhet med Windows brandvägg, SCW 2.0 och URL Scan
• Ökad prestanda med 64 bitars stöd (Windows 2008 är sista operativsystem med 32 bitars stöd)
• IIS 7.0 (enklare och säkrare hantering av webbfarmen och bättre isolering av applikationer)
• Windows PowerShell för bättre hantering och automatisering av skript för underhåll av WSS
• Windows Remote Shell (WinRS)
• MMC 3.0 och Task Scheduler 2.0
• Optimerad TCP/IP stack (automatisk anpassning av TCP Windows Size, snabbare kommunikation över WAN länkar, reducerad paketförluster)
Nyheterna i WSS 3.0 SP1 och MOSS 2007 SP1
• AJAX Support (KB 941955)
• Remote Blob Storage API in WSS (KB 937901)
• Nya STSAdm kommandorader i WSS
Mergecontentdbs – (KB 939035)
Rename Host Named Site Collections (KB 939535)
• Mer än 60 Hotfixar och patchar (för både WSS och MOSS)

Att uppgradera från RC0 till RC1 eller RTM
• Ta en säkerhetskopia på alla dina databaser
• Avinstallera WSS 3.0 från din server
(Erfarenhetsmässigt föreslår jag att du avinstallera WSS 3.0, Windows Interna Databas, .Net framework 3.0, Windows Process Activation Service och IIS:en. Detta eftersom avinstallation av WSS 3.0 lämnar efter sig vissa register värden.)
• Uppgradera till Windows server 2008 RC1
• Installera sedan WSS 3.0 SP1
• Återläs det data som du har tagit en säkerhetskopia på

Mina rekommendationer inför installation/ominstallation av WSS 3.0 på Windows RC0

• Installera en riktig SQL 2005 Standard eller Enterprise version, eller använd dig av en befintlig databas
• Välj avancerad installation och lägg dina databaser på den SQL server som du installerat ovan eller en befintlig databas
• Om du har planer på att installera MOSS 2007, gör detta innan du ens skapat några Siter.
• Vid ominstallation av WSS 3.0 backa upp alla dina databaser, installationsprogrammet varnar inte för något.
• Döp om 12 hives, sökvägen är:
%Program Files%\Common Files\Microsoft Shared\Web Server Extensions\12
Tyvärr rensar inte programmet denna sökväg.

Codeplex

Codeplex för SharePoint
Klicka på länken nedan och njut av open source projekt för SharePoint
http://www.codeplex.com/Project/ProjectDirectory.aspx?TagName=Sharepoint

Microsoft Office Groove 2007 vs. SharePoint

Jag hade äran att tillsammans med 15 andra nördar tillbringa en heldag i den soliga Barcelona för att låsa in oss i ett rum och lyssna på Matt Shannon, Senior Product Manager för Microsoft Office Groove 2007. I denna blogg försöker jag belysa Microsoft Office Groove 2007 (hädanefter kallas Groove), dess användningsområde och hur det hänger ihop med Microsoft SharePoint Portal Server 2007 (MOSS 2007) och Windows SharePoint Services 3.0 (WSS 3.0).

I en organisation där information är av vital betydelse, är det ytterst viktigt att information är alltid uppdaterad och aktuell. Organisationer och företag försöker även att strukturera information och göra de tillgängligt för beslutfattare, projektmedlemmar och kunder. Medan det gamla sättet att dela av sig av dokument, dvs. genom skapandet av filstruktur och rättigheter skapar en del icke önskvärd och statisk tillvaro, erbjuder Groove på ett helt dynamiskt och välstrukturerat sätt att jobba.

Groove är inkluderat i Microsoft Office 2007 Enterprise Edition och går även att skaffa separat. Microsoft rekommenderar mellan 2 till 30 samtidiga användare för varje arbetsyta (Workspace) i Groove. Okej låt mig belysa detta med ett litet scenario:

Företag X startar ett projekt för att driftsätta en ny produktionsmiljö för en påhittad kund. I projektet utses Kalle som projektledare. Kalle Skapar en arbetsyta för projektet och bjuder in alla projektmedlemmar till Groove genom att skicka inbjudan via Outlook. Kalle blir då ägare (manager) av arbetsytan och kommer således vara enda individen som kan ta bort den. Alla övriga dödliga projektmedlemmar blir då antingen deltagare (participan) eller gäst (Guest).

Alla filer sparas lokalt på varje klient och all innehåll krypteras och dekrypteras med en kryptonyckel på 2048 bitar. På detta sätt har företaget säkrat upp information, snabbt kopplat ihop alla projektmedlemmar till samma arbetsyta och gjort information tillgängligt både ”Offline” och ”Online”. Kalle kan även då bjuda in externa kunder att ta del av information, utan att för den delen behöva registrera de på nätverket som användare och utan att ge de NTFS-rättigheter eller VPN-access. Känsliga dokument slipper bli utväxlade via mail.

Grooves begränsningar, SharePointsstyrka

Groove har begränsade möjligheter vid konflikthantering, då två personer modifierar samma dokument samtidigt. Det finns inget sätt att checka ut och checka in dokument. Vid ett sådant scenario sparas två kopior av samma dokument märkta med användarnas alias. Groove saknar även möjligheter att publicera dokumenten för större skara av individer eller avdelningar inom organisationen. Långtidslagring och flödeskontrollen är ej tillgängliga i Groove, det är här som WSS 3.o eller MOSS 2007 kommer in i bilden. Med ett inbyggt verktyg som heter SharePoint Files, kan användare publicera delar eller hela arbetsytan till MOSS eller WSS dokument bibliotek. Innehållet kommer då att vara sökbart och lättillgängligt för alla på intranätet eller extranätet.

För mer information om Groove kolla länkarna nedan:
Microsoft Office Groove 2007
http://office.microsoft.com/groove

www.microsoft.com/office/groove11

Groove 2007 Developer Portal på MSDN
http://msdn.microsoft.com/groove

Microsoft Office Groove Server TechCenter
http://www.microsoft.com/technet/prodtechnol/office/grooveserver

Grooves Blog
http://blogs.technet.com/groove

SharePoints white papers
http://go.microsoft.com/fwlink/?LinkID=82555&clcid=0x409

Sharepoint och SQL Server 2005 Mirroring - Möjligheter och begränsningar

Målgrupp: Sharepoint Administratörer och SQL DBA
Nivå: 200
Kräver kännedom om: SQL Server 2005 Mirroring, WSS3.0 och MOSS 2007

Microsoft introducerade med SQL server 2005 en ny lösning för högtillgänglighet av databaser, så kallad ”database mirroring”. Jag kommer i fortsättningen att kalla det DBM för enkelhetens skull. DBM blev inte supporterad förrän SP1 för SQL server 2005. Innan DBM fanns det ett antal andra lösningar för högtillgänglighet, bland annat "Database Clustring" och "Log shipping". Styrkan i DBM är att den sätts på databasnivå och inte servernivå och kräver därmed inte likadan hårvara på noderna. Bland nackdelarna kan räknas att DBM kräver en tredje server, ett så kallad vittne, detta om lösningen ska köras i högtillgänglighetsläge. DBM stöds endast i SQL server 2005 standard-, developer- och Enterprise edition, medan vittnestjänsten kan exekveras i alla versioner. En annan förutsättning för DBM är att applikationen stödjer ADO 2.0. DBM fungerar endast för de databaser som är i ”Full Recovery Model” och antal databaser som speglas bör ligga strax under 10 databaser för varje server, annars kommer prestandan att bli lidande. För mer information om DBM surfa till länken nedan:
http://go.microsoft.com/fwlink/?LinkId=83566&clcid=0x409

Innan jag går in på hur Sharepoint kan dra nytta av DBM, låt oss ta en titt på de databaser som finns i respektive version av Sharepoint.

Windows SharePoint Services 3.0 (WSS 3.0)använder sig av följande databaser:
• En konfiguration databas (CONFDB)
• En innehållsdatabas för Central Administration (CACDB)
• En eller flera innehålls databaser (CONTDB)
• En sökdatabas (Search) - (SDB)

Microsoft Office SharePoint Server 2007 (MOSS 2007) använder sig av följande databaser:
• En konfiguration databas (CONFDB)
• En innehållsdatabas för Central Administration (CACDB)
• En eller flera innehålls databaser (CONTDB)
• En eller flera databaser för delade tjänster, så kallade "Shared Services Provider" (SSPDB)
• En sökdatabas (Search) - (SDB)

Alla databaser ska speglas individuellt. CONTDB och SSPDB är de två databastyper som drar störst nytta av DBM. CONFDB och CACDB innehåller specifika referenser om platser och konfigurationer, vilket gör de mindre attraktiva för DBM. Microsoft rekommenderar inte i dagsläget att man speglar SDB. Detta för att vid en svängning till andra noden och vid omkoppling av SDB, söker sökmotorn genom hela databasen på nytt (Recrawl), vilket är samma som att bygga sökdatabasen från början, dvs. man vinner inget på att svänga SDB. Microsoft rekommenderar administratörer att använda sig av de inbyggda verktygen i Sharepoint för att backa och återläsa SDB.

Det andra som man ska tänka på är att CONFDB och CACDB är så tätt integrerade med varandra. Därför skall dessa databaser ligga på samma fysiska nod och svängas samtidigt vid en manuell förfarande.
databas spegling är endast användbart i ett MOSS 2007 farm, med en front-end server och en eller flera back-end databaser.
Okej, låt oss anta att vår första nod i DBM, dvs. den så kallade Principal har gått ner och andra noden det så kallade Mirror har tagit över databaserna och blivit aktivt. I denna stund då jag sammanställer detta dokument, finns ingen inbyggd funktion i varken WSS 3.0 eller MOSS 2007 som automatisk känner av att databasen har svängt. Därför behövs lite handpåläggning för att få det att fungera. Detta kan göras antingen manuellt eller automatiskt. För att skripta detta kolla länken nedan, vilken visar hur olika händelser i DBM kan fångas och automatiseras:
http://go.microsoft.com/fwlink/?LinkId=83691&clcid=0x409

CONFDB och CACDB
För att uppmärksamma WSS eller MOSS att CONFDB och CACDB har svängt till andra noden följ följande steg PÅ ALLA FRONT-END WEBBSERVRAR:
1. Se till att alla SQL logins finns i båda noderna. För att kopiera dessa mellan noderna kolla länken nedan:
http://go.microsoft.com/fwlink/?LinkId=93747&clcid=0x409
Om inte dessa logins finns i alla noder, kommer du inte att kunna komma åt CACDB.

2. Kör följande rad av kod på varje Fron-End webbserver:
stsadm.exe -o renameserver -oldservername -newservername
För en detaljerad beskrivning av Stsadm kommandot surfa till länken nedan:
http://technet2.microsoft.com/Office/en-us/library/188f006d-aa66-4784-a65b-a31822aa13f71033.mspx?mfr=true

3. Starta om alla Front-End webbservrar.

CONTDB
För att uppmärksamma WSS eller MOSS att en eller flera CONTDB har svängt till andra noden, medan CONFDB och CACDB ligger kvar på samma nod, följ följande steg ENDAST PÅ EN FRONT-END WEBBSERVER:
Klicka på Start  Programs  Administrative Tools  SharePoint 3.0 Central Administration.
1. I Central Administration site, Klicka på Application Management.

2. I Application Management sidan, I avsnittet för SharePoint Web Application Management delen, klicka på Content databases.

3. I Manage Content Databases sidan, klicka på den CONTDB som har svängt.

4. I Manage Content Database Settings page, i Remove Content Database delen, bocka i Remove content database och klicka sedan på OK.

5. I Manage Content Databases sidan, klicka på Add a content database.

6. Ange information om den CONTDB som du nyss tog bort, men ersätt Database Server med den nya databasnoden, dvs. Den som aktiv för stunden.

7. Repetera stegen 4-7 för varje CONTDB som har svängt till en ny nod.

Du kan även använda dig av följande kommando:

1. För att ta bort fallerade CONTDB:

stsadm -o deletecontentdb -url "" -databasename "" -databaseserver ""

2. För att lägga tillbaks CONFDB:

stsadm -o addcontentdb -url "" -databasename " " -databaseserver ""

SSPDB
För att uppmärksamma MOSS att SSPDB har svängt till andra noden, följ följande steg ENDAST PÅ EN FRONT-END WEBBSERVER MEN FÖR VARJE DATABAS SOM HAR SVÄNGT:

stsadm –o editssp –title –ssplogin –ssppassword - sspadminsite

OBS! Username kan skrivas I följande format: Domain\Username