SharePoint på ren svenska

Installation/konfiguration

SQL Server Express 2010 – begränsningar

Tänkte bara passa på att dela med mig av en länk angående begränsningar i SQL Express 2012

http://en.wikipedia.org/wiki/SQL_Server_Express

Kortfattat:

  • Max 10 GB per databas (exklusive log)
  • Ingen SQL Server Agent service
  • En CPU, men flera kärnor
  • 1 GB of RAM (d.v.s. SQL-tjänsten använder max 1GB, du kan ha mer på maskinen i övrigt)

Trevlig sommar på er! 🙂

Annonser

Konfigurera ”Publicering av Innehållstyper”

Jag gillar innehållstyper, ja sån är jag. Men ärligt tog det mig ett bra tag att verkligen förstå vad det var och vad man skulle ha dem till. Jajaja det är något man har för att t.ex. kategorisera dokument i SharePoint och utifrån det kan man koppla till webbplatskolumner, arbetsflöden m.m. Skitbra, men vad ska man ha dem till, egentligen?

Som vanligt när jag stöter på något som kan kännas lite luddigt att förstå och även förklara för andra så försöker jag hitta liknelser i vanliga livet. Det gör att man lättare känner igen sig och slipper tänka ”data” vilket oftast underlättar, att få en ny vinkling. Den största anledningen till att innehållstyper inte används eller slutar att användas i dokumenthanteringen i SharePoint tror jag helt enkelt beror på att ingen förklarat för dem hur smidigt det faktiskt är att använda dem.

Nåja, nu tänkte jag inte förklara begreppet Innehållstyper idag, det tar jag för givet att du redan har greppat när du väl kommit så långt att du är intresserad av att faktiskt börja publicera dem mellan webplatssamlingar. Jag delar här upp jobbet i två delar där vi först i CA bestämmer vilken webbplatssamling som ska vara värd för innehållstyperna och sen bestämmer vilka innehållstyper som ska publiceras i den webbplatssamlingen vi valt. Det är exakt samma steg att göra detta i 2013 som i 2010.

1. Ange värd för publicering

Gå in i Central admin och Service Applications

Markera tjänsteapplikationen för Managed Metadata Service och klicka på Properties.

Scrolla ner lite och fyll i adressen för webbplatssamling t.ex. http://intranet/ ni tänkt använda som hub för innehållstyperna.

Om inte ni här får ett felmeddelande får man gå in på den webbplatssamling man angett ovan och slå på funktionen manuellt under site settings – site collection features.

Välj Managed Metadata Service Connection och Properties och kryssa i Consumes content types from the Content Type Gallery at http://intranet/.

Slå på publiceringen av innehållstyper

Gå till Webbplatsinställnigar i den webbplatssamling ni valt som hub, exempelvis http://intranet/  klicka på länken för Innehållstyper. Välj innehållstyperna ni vill publicera och klicka på länken Hantera publicering för den här innehållstypen och välj Publicera.

Gå till Central admin – Monitoring – Job definition – Content Type Subscriber och klicka på länken som går till de övriga webbplatssamlingar dit publiceringen ska ske t.ex. http://projekt/ . Här kan ni ändra hur ofta detta jobb ska ske eller som nu när vi slår på funktionen kan vi köra jobbet manuellt istället för att vänta en hel timme på att kontrollera om publiceringen faktiskt fungerar.

Kontrollera att publiceringen faktiskt fungerar genom att gå till den webbplatssamling ni körde jobbet på manuellt här ovan, i detta exempel http://projekt/ gå in på Webbplatsinställningar och Innehållstyper så bör ni nu se de innehållstyper ni valt att publicera, med medföljande kolumner.

Ändra hub för publicerade innehållstyper

Nu kanske ni varit igång ett tag och jobbat med publicering av innehållstyper och insett att ni vill ändra värden för publiceringen av innehållstyper. Glad i hågen kommer ni ihåg att det ställde man in i Central Admin och går in där, markerar tjänsteapplikationen för Managed Metadata och trycker Properties och scrollar ner. Men va sjutton!? Det är ju utgråat och går inte att ändra :-/ Nåja, jag har räddningen.

Starta powershell för SharePoint som administrator och skriv:

Set-SPMetadataServiceApplication -Identity "Managed Metadata Service" 
–HubURI http://NyContentTypeHub/

Gå nu tillbaka t. Central Admin igen, markera tjänsteapplikationen för Managed Metadata och klicka på Properties så ser ni att URL för huben ändrats.

Lätt som en plätt!


Event id 7043

Har ni också en server med en eventlogg där det då och då dyker upp event id 7043. Visst är det retsamt med Warnings och Errors även fast servern och SharePoint i sig fungerar bra.

Såhär ser meddelandet ut:

Log Name:      Application
Source:        Microsoft-SharePoint Products-SharePoint Foundation
Date:          2012-08-20 05:55:44
Event ID:      7043
Task Category: Web Controls
Level:         Error
Keywords:     
User:          DOMÄN\Sökkonto
Computer:      Server.domän.se
Description:
Det gick inte att läsa in kontrollmallfilen /_controltemplates/TaxonomyPicker.ascx: Could not load type 'Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker' from assembly 'Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.

I de flesta fall går detta att lösa genom att leta upp filen TaxonomyPicker.ascx öppna den i Notepad, sök och ersätt texten , med ett enkelt komma-tecken ”,” eller att döpa om filen till TaxonomyPicker_broken.ascx (eller liknande). Men jag stötte på ett fall där ingen av dessa lösningar fungerade och hittade istället denna lösning:

ersätt texten på första raden:

Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal,

med texten

Inherits="Microsoft.SharePoint.Taxonomy.TaxonomyFieldEditor,Microsoft.SharePoint.Taxonomy,

Voila!


fortsättning profilsynkroniseringskonto – behörighet för export

För ett bra tag sen skrev jag om hur man skulle får fart på profilsynkroniseringen i SharePoint2010 och det fungerar fint så länge man inte ska slå igång exportfunktionen som är alldeles ny i denna version av SharePoint. För att denna funktion ska fungera måste man ge profilsynkroniseringskontot ytterligare behörighet till ad’t. Det kan vara bra att testa denna behörighet på ett OU innan man låter behörigheten ärvas ner på alla OU’n som ska synkroniseras.

Öppna ADSIEdit.msc igen , välj properties på just det OU du ska synkronisera (och testa detta på), lägg till behörigheten Create Child
Objects
och Write permissions på profilsynkroniseringskontot.

Som ni kan se så finns nu redan kontot med (det la ni till tidigare när ni skulle lägga till behörighet för profilsynkroniseringskontot att importera från AD’t, nu ska vi alltså ge samma konto behörighet att exportera till AD’t. Skulle vi här bara trycka OK skulle dessa behörigheter enbart slå genom på just detta OU, inga underliggande.

Så, innan vi trycker OK går vi istället in under Advanced och letar upp den andra upplagan av samma konto, den utan något värde under ”Inherited From”. Markera kontot och klicka Edit, se till att kryssrutan ”This object and all dependant objects” är ikryssad och lägg till Write all Properties and Create Child Objects.

Klick OK så du kommer tillbaka hela vägen.


Excel services – ”kan inte öppna arbetsboken”

Härrom dagen stötte jag på ett nytt problem hos en kund som ville titta på sina filer i Excel Services. De har en 2-server farm med en Sharepoint2010-server och en SQL2008-server, båda med OS 2008 R2. Inget special i huvud taget utan en ren standarduppsättning. Problemet var att när de ville titta på sina xlsx-filer fick de upp följande felmeddelande:

Först trodde jag att det berodde på att Excel Services helt enkelt inte var igång, men det var den. Sen tänkte jag att det kanske berodde på behörighet av filen, men så var det inte heller. Efter en stunds letande på internet hittade jag några ledtrådar då jag läste att tjänstekontot för Excel Services måste vara samma som för den webbapplikation man ska köra Excel Services, i mitt fall intranätet.

Så jag gjorde helt enkelt så att jag tog bort Service Application för Excel Services och skapade om den med att köra under samma konto som intranätet, sen fungerade det hur bra som helst.

Så här gjorde jag:

1. Ta bort SA för Excel Services gör jag genom att markera den (utan att klicka på själva länken)

markera SA för Excel Services

2. gå upp i menyfliksystemet och klicka på tabort.

3. Konfirmera att ta bort SA’n.

klicka på "OK"

4. Gå på menyfliksystemet och välja ”New” och välja ”Excel Services”.

menyn för ny Service Application, markera Excel Services

5. Fyll i informationen i dialogrutan som kommer upp. T.ex. enligt följande bild:

Tadaa, nu borde xlsx-filerna visas som de ska i webbläsaren!


Problem med SQLdb som inte vill gå offline

Hur ofta har man inte suttit och väntat och väntat och väntat på att en SQL-databas ska gå offline!?

Här har ni ett bra knep som fungerar för mig, skriv in texten nedan i script-fönstret i SQL:

ALTER DATABASE Din_innehållsdatabas SET OFFLINE WITH
 ROLLBACK IMMEDIATE
 GO

SharePoint 2010 med Kerberos

Visst är det så att det går en rysning genom kroppen när man nämner kombinationen SharePoint och Kerberos, inte av välbehag utan mer av den sorten ”kalla kårar”. Om inte, då har man  nog inte satt upp en sådan lösning än ;o). Lite kuriosa, vet ni var namnet Kerberos kommer ifrån? Jo det är namnet på den trehövdade hund som vaktar vid dödsriket i den grekiska mytologin.

Lugn jag har lite tips och råd hur man gör och vad man bör tänka på. Det står idag en hel del om detta men ofta är beskrivningarna långa och krångliga, jag ska göra mitt bästa med att göra denna kort och lätt att förstå.

Det allra första man kan anamma är, SATA, som är bra om man känner att paniken kommer krypande. Här pratar jag inte om SATA-diskar utan en förkortning som används inom dykningen om något händer under ett dyk. Stanna Andas Tänk Agera! Det är inte så svårt egentligen.

Så, nu kör vi!

1. Vi börjar med att ta reda på vilka webbapplikationer som ska köra Kerberos. Skriv upp URL och vilket domänkonto den körs på.

2. Sen loggar vi in på en DC i domänet och öppnar kommandoprompten.

Skriv:

setspn -a HTTP/<DNS HOSTname> Domän\webbappkonto

och sen oxå

setspn -a HTTP/<DNS FQDN> Domän\webbappkonto

Exempel:

setspn -a HTTP/intranet contoso\sp_webbapp
setspn -a HTTP/intranet.contoso.local contoso\sp_webbapp

För de webbapplikationer som inte körs på standardportarna 80 och 443 får man registrera även portnummer:

HTTP/<DNS Host Name>:<port>
HTTP/<DNS FQDN>:<port>

Exempel:

setspn -a HTTP/test:3333 contoso\sp_testwebbapp
setspn -a HTTP/test.contoso.local:3333 contoso\sp_testwebbapp

3. Nu ska vi in i AD User & Computers och högerklicka på varje webbapplikationskonto och välj ”Properties”. Klicka på fliken ”Delegation” som nu dykt upp där bland flikarna.

4. Välj ”Trust this user for delegation to specified services only” och sen även ”Use any authentication protocol”.

5. Klicka på knappen ”Add”.

6. Lägg nu till de tjänster som detta konto får använda. T.ex. HTTP/test:3333  och HTTP/test.contoso.local:3333 för konto contoso\sp_testwebbapp.

7. Nu kan ni gå in på dessa webbapplikationer i Central administration och markera den webbapplikation ni ska ändra till Kerberos på och klicka sen på ”Authentication providers” uppe i Menyfliksystemet.

8. Klicka på länken ”Default” och scrolla ner till avsnittet ”IIS Authentication Settings” där ni nu väljer ”Negotiate (Kerberos)”.

9. Nu ska det vara klart, prova nu att surfa till de webbplatssamlingar ni ställt om till Kerberos och testa detta från en annan dator än SharePoint-servern.


Profilsynkroniseringskontot

Profilsynkroniseringskonto är ett långt ord.

En av de frågor jag brukar stöta på när jag ska ut och installera och konfigurera upp en ny Sharepointmiljö är hur behörigheterna för tjänstekontona i AD’t för SharePoint ska se ut. I mångt och mycket räcker det med att de är vanliga användare och SharePoint själv fixar iordning behörigheterna, men för Farm-kontot och Profilsynk-kontot är det lite annat. Vad gäller farm-kontot är det inte så komplicerat och det ser ut som i tidigare versioner, däremot vad gäller Profilsynk-kontot ser det nu lite annorlunda ut iom att vi nu fått en tvåvägs kommunikation till AD’t (alla AD-konsulter hoppar av glädje ;o)…).

Det man bör tänka på innan man kör igång tjänsten för profilsynkroniseringen är att farm-kontot, som tjänsten ska faktiskt ska köras på, måste ligga med som lokal administratör på den SharePoint-server där synkroniseringen ska köras.

Men detta ska nu handla om hur själva profilsynkroniseringskontot sätts upp, i exemplet använder jag kontot Domän\sp_profilsynk

Så, kommer ni, som SharePoint-konsult, inte in i AD’t och kan göra dessa förändringar som krävs kan ni bara skicka denna beskrivning till AD-konsulterna:

  1. I AD Users & computers, högerklicka på domänet, välj ”Delegate Control” och tryck ”Next”.
  2. Lägg till kontot du valt för profilsynkroniseringen (exempel Domän\sp_profilsynk) och tryck ”Next”.
  3. Välj ”Create a Custom Task to Delegate” och tryck ”Next”.
  4. Tryck ”Next”.
  5. Välj ”Replicating Directory Changes permission” och tryck ”Next”.
  6. Tryck ”Next”.

I många fall räcker det gott med dessa steg, men om det är så att Netbios-namnet inte är samma som FQDN så måste även dessa instruktioner följas:

  1. Starta ADSI Edit (Run: ADSIEdit.msc ).
  2. Koppla upp mot sökvägen till konfigurationen, se exempel nedan:
  3. Högerklicka på konfigen du precis kopplat upp dig mot och välj ”Properties”.
  4. Välj fliken ”Security” och lägg till kontot för synkroniseringen (exempel Domän\sp_profilsyn) och ge kontot rättigheten ”Replicating Directory Changes”.

För att läsa fortsättningen om hur man får SharePoint att exportera till AD’t, läs vidare här https://sharepointdiver.wordpress.com/2012/07/02/fortsattning-profilsynkroniseringskonto-behorighet-for-export/