Kerberos für SharePoint

By Henning Eiben in Infrastruktur, SharePoint 0 Comment
… oder willkommen an den Toren der Unterwelt.

Irgendwann führt kein Weg mehr vorbei an Kerberos. Spätestens wenn man z.B. aus SharePoint auf Drittsysteme mit den Anmelde-Daten des aktuellen Benutzers zugreifen will, dann muss man sich dieser Aufgabe stellen.

Ich will hier nicht auf die Funktionsweise von Kerberos eingehen, und auch nicht auf die tieferen Hintergründe von SharePoint 2010 und Kerberos. Das kann man am besten in dem Handbuch für SharePoint 2010 Administratoren nachlesen und ansonsten hat Microsoft auch eine super Dokumentation für die Konfiguration von SharePoint 2010 und Kerberos geschrieben.

Hier also nur die Ergebnisse, um Kerberos und SharePoint 2010 (und 2013) zum zusammenspielen zu bewegen. Im Wesentlichen sind drei Schritte durchzuführen:

  1. Service-Principle für den/die Application-Pool Accounts einrichten
  2. Web-Anwendung in SharePoint auf Kerberos umstellen
  3. Service-Principle für den SQL-Dienst einrichten

Vielleicht die einzelnen Schritte etwas genauer.

Szenario: Ich habe in meiner SharePoint Umgebung eine Web-Application für ein Extranet mit einem entsprechenden Application SP_AP_Extranet, welcher das Konto demo-he\spAppPool_Extranet verwendet. Hier soll nun also Kerberos verwendet werden. Zudem habe ich noch einen SQL-Server (sp2010he) der mit dem Konto demo-he\spSQLService läuft.

Service-Principles für die Application Pools einrichten

Für jeden Application-Pool Account (der Web-Anwendung die mit Kerberos verwendet werden soll) muss ein Service-Principle registriert werden. Das geht mit dem setspn.exe, das seit Windows 2008 zum Standard gehört. Bei Versionen vor Windows 2008 ist das setspn.exe im Ressource-Kit vorhanden.

setspn.exe -S http/extranet demo-he\spAppPool_Extranet
setspn.exe -S http/extranet.demo-he.local demo-he\spAppPool_Extranet

Der Schalter –S ist erst ab Windows 2008 verfügbar; bei früheren Versionen muss man –A verwenden, wobei dabei nicht geprüft wird ob der Service-Principle schon verwendet wird. Somit ist –S auf jeden Fall zu bevorzugen.

Anschließend muss man dem Konto spAppPool_Extranet noch für Delegierungszwecke vertrauen. Dazu kann man im Active Directory entweder dem Konto generell für Delegierungszwecke vertrauen (Basic Delegation) oder die Dienste einschränken, für die die Delegierung verwendet werden kann (Constrained Delegation). Für einige Dienste ist die Constrained Delegation notwendig (Excel-Services, Reporting-Services, …).

delegation_2

Das geht also offenbar von Hand – oder aber auch per Skript. Am einfachsten per PowerShell.

Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local"}

Abschließend sollte der IIS einmal neu gestartet werden, damit der Application-Pool auch die neuen Einstellungen aus dem Active Directory berücksichtigt.

Service-Principle für die Datenbank einrichten

Für die Datenbank funktioniert die Einrichtung im Wesentlichen identisch wie bei der Application-Pools. Also hier auch erst den Service-Principle per setspn.exe einrichten, und dann dem Account noch für Delegierungszwecke vertrauen.

setspn.exe -S mssqlsvc/sp2010he demo-he\spSQLService
setspn.exe -S mssqlsvc/sp2010he.demo-he.local demo-he\spSQLService

Get-ADUser spSQLService | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}

Anschließend auch hier den SQL-Server Dienst und ggf. auch den IIS neu starten, damit die neuen Einstellungen wirksam werden.

Wenn bei der Konfiguration ein SQL-Alias verwendet wurde (das sollte ja immer der Fall sein), dann spielt das hier keine Rolle. Beim Service-Principle wird immer der im DNS eingetragene Server-Name verwendet, nicht das SQL-Alias.

Wird im SharePoint BCS verwendet, und soll hier auch mit Hilfe von Kerberos mit der Identität der Benutzers auf die Datenbank zugegriffen werden, dann ist noch ein weiterer Schritt notwendig. Dem Application-Pool Account muss auch ein Delegation-Constrained für die Datenbank zugewiesen werden.

Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}

Zusammenfassung

Ich habe hier die gleiche Reihenfolge gewählt, wie sie idR. in der Literatur auch zu finden ist: erst SPN für den Application-Pool setzen, dann SPN für die Datenbank setzen und dann die einzelnen Dienste konfigurieren. Das ist aber eigentlich unpraktisch. Wenn man die Schritte genauso abarbeitet, dann muss man den IIS einmal nach der Einrichtung des SPN für den Application-Pool neu starten, und dann noch einmal nachdem man den SPN für den SQL-Server eingerichtet hat. Auch muss man erst die Constrained Delegation für den Application-Pool anpassen und dann nachdem man den Service-Principle für den SQL-Server eingestellt hat noch einmal (um die Delegation für den BCS zu ermöglichen). Da sind ja Arbeitsschritte doppelt.

Besser wäre also: erst alle SPNs registrieren, dann die Constrained Delegation für alle SPNs einrichten und zum Schluss alle Dienste neu starten.

Also Skript sich das ganze dann so aus:

Import-Module ActiveDirectory

Write-Host "Registering Service Principles"
setspn.exe -S http/extranet demo-he\spAppPool_Extranet
setspn.exe -S http/extranet.demo-he.local demo-he\spAppPool_Extranet

setspn.exe -S mssqlsvc/sp2010he demo-he\spSQLService
setspn.exe -S mssqlsvc/sp2010he.demo-he.local demo-he\spSQLService

Write-Host "Validating Service Principles"
setspn.exe -L demo-he\spAppPool_Extranet
setspn.exe -L demo-he\spSQLService


Write-Host "Adding constrained delegation"
Get-ADUser spAppPool_Extranet | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local"}
# for BCS add constrained delegation also to the sql-service
#Get-ADUser spAppPool_Extranet | Set-ADObject add @{"msDS-AllowedToDelegateTo"="http/extranet", "http/extranet.demo-he.local", "mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}

Get-ADUser spSQLService | Set-ADObject -add @{"msDS-AllowedToDelegateTo"="mssqlsvc/sp2010he", "mssqlsvc/sp2010he.demo-he.local"}


Write-Host "Restarting SQL-Service"
net.exe stop MSSQLSERVER
net.exe start MSSQLSERVER

Write-Host "Restarting IIS"
iisreset.exe /noforce

Das ganze führt man also am besten direkt aus der PowerShell aus, da hier dann die PowerShell Befehle zur Verfügung stehen und die Kommandozeilen-Befehle wie setspn.exe natürlich auch.

ULSViewer selbst gemacht

By Henning Eiben in SharePoint 0 Comment

Auch wenn es inzwischen wieder eine neue Version des ULSViewer gibt – so hat man den vielleicht nicht immer zur Hand. Oder man hat ein deutsches OS mit einem englischen ULS Log, und der Parser im ULSViewer kann das Datum nicht anzeigen.

Kurz: es gibt auch immer mal Situationen, wo man einfach keinen ULSViewer zur Verfügung hat. Aber was macht man dann, wenn man ein 20 MB großes ULS Logfile hat? Wie heißt es so schön: “Don’t Panic!”

Natürlich kann man das ULS immer mit dem Notepad öffnen – aber viel bringen tut das eigentlich nicht. Wenn man schon eine Correlation-ID hat, dann ist es nicht gerade einfach im Notepad alle Requests zu dieser ID zu finden. Oder alle Log-Einträge vom Level “unexpected”.

Don’t Panic!

Voila: Excel, der neue ULSViewer!

Kaum ein Problem, welches man nicht mit Excel lösen kann. Mal eben ein 20 MB ULS Log mit Notepad öffnen, alles markieren, in die Zwischenablage kopieren und dann in Excel einfügen. Dann noch schnell als Tabelle in Excel formatieren – und fertig ist der ULSViewer “a la Excel”.

Anschließend können die Einträge anhand der Auto-Filter gefiltert werden. So können z.B. schnell alle Einträge für eine Correlation-ID gesucht werden.

excel_uls

SQL-Server von der Kommandozeile

By Henning Eiben in Infrastruktur 0 Comment

Wenn man z.B. im Rahmen einer SharePoint Installation auf dem SQL-Server ein paar Einstellung vornehmen muss, braucht man nicht immer das komplette SQL-Management-Studio. Insbesondere wenn man die notwendigen Schritte sowieso schon als SQL-Script vorliegen hat. Da reicht auch eine Kommandozeile – zumal sich die ja auch optimal z.B. in eine Batch-Datei einbinden lässt um die Konfiguration zu automatisieren. Da ist es ja praktisch, dass es für den MS-SQL Server auch eine Kommandozeile gibt – manchmal gibt es einfach solche Zufälle. SQLCMD.EXE heißt hier das Zauberwort. Zu finden ist das z.B. unter C:\Program Files\Microsoft SQL Server\110\Tools\Binn (bei SQL Server 2012). Praktischerweise gibt es das Tool sowohl bei dem SQL-Server als auch bei dem kleinen Bruder dem SQLExpress (der ja typischerweise ohne Management-Studio kommt). Gerade also beim SQLExpress ist dies hilfreich, wenn man nicht das Management-Studio nachinstallieren will. Die Verwendung ist ganz einfach SQLCMD –S localhost\sqlexpress –E öffnet einen Prompt auf dem SQL-Server. Durch den Schalter –E melde ich mich mit meinen aktuellen Windows-Credentials an. Weitere Parameter kann man im MSDN finden. Für SharePoint kann ich dann z.B.

-- Create Login and assign permissions
USE [master]
GO
CREATE LOGIN [acme\spSetup] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
EXEC master..sp_addsrvrolemember @loginame = N'acme\spSetup', @rolename = N'dbcreator'
GO
EXEC master..sp_addsrvrolemember @loginame = N'acme\spSetup', @rolename = N'securityadmin'
GO

-- set MAXDOP to 1, as recommended
EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max degree of parallelism', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE

GO

-- for dev-env only!! Set recovery-model to simple!!
USE [master]
GO
ALTER DATABASE [model] SET RECOVERY SIMPLE WITH NO_WAIT
GO

-- for dev-env only!! Set max-ram to 1,5 GB!!
USE [master]
GO
EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'min server memory (MB)', N'512'
GO
EXEC sys.sp_configure N'max server memory (MB)', N'1536'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE
GO

ausführen. Und schon ist mein SQL-Server optimal für die Installation von SharePoint vorbereitet.

Untersuchung im Netzwerk

By Henning Eiben in Infrastruktur 0 Comment

Manchmal muss man einfach genauer hinsehen was so alles im Netzwerk passiert. Gerade auch im SharePoint Umfeld gibt es bestimmte Situationen, wo man einfach einmal genau wissen muss, was für Daten gerade über die Leitung gehen. Das spätestens ist immer dann der Fall, wenn man mit Authentifizierung zu tun hat. Solche Situationen sind immer schwer zu diagnostizieren.

Klassisch würde man also hingehen und auf dem Server ein Traffic Capture Tool installieren – z.B. Microsoft Network Monitor. Anschließend kann man dann mit dem Netmon den gesamten Netzwerk-Traffic aufzeichnen und später analysieren. Dazu kann man das Capture durchaus auf einen anderen Rechner übertragen um die gesammelten Daten ganz in Ruhe im Büro zu untersuchen.

Aber man muss zunächst ein entsprechendes Capture-Tool haben.

Aber das geht inzwischen auch “eleganter”. Mit dem Event-Tracing in Windows gibt es einen Mechanismus mit dem man mit Windows Bordmitteln auch solche Daten aufzeichnen kann. Voraussetzung dafür ist Windows 2008 R2 oder neuer.

Mit folgenden Befehl wird der komplette Netzwerkverkehr auf einem Server aufgezeichnet:

netsh trace start persistent=yes capture=yes tracefile=c:\temp\mytrace.etl

Nun kann man alles das machen, was man aufzeichnen will. Anschließen kann man die Aufzeichnung mit

netsh trace stop

beenden.

trace_01

Die Aufgezeichneten Daten kann man sowohl mit Netmon als auch mit dem neuen Tool Microsoft Message Analyzer untersuchen. Dazu lässt sich der Trace ganz einfach öffnen.

trace_02

Der Vorteil bei diesem Vorgehen ist, dass man auf dem Server, dessen Traffic man untersuchen möchte, keinerlei Komponenten installieren muss. Das macht es einfacher auch bei einem Kundensystem etwas tiefer ins System zu schauen und Fehler zu untersuchen.

Wenn man z.B. nur Kerberos-Traffic sehen will, weil es Probleme mit der Authentifizierung gibt, so kann man die Einträge auf Kerberos Filtern und die Datenpakete gezielt untersuchen.

trace_03

Script-Deployment ganz einfach

By Henning Eiben in Development, SharePoint 1 Comment

Das schöne am JavaScripting ist ja, dass man eigentlich ganz ohne große IDE auskommt. Eigentlich reicht ein Notepad und ein Browser (zum testen). Damit kann man schon so einiges machen.

Wenn man für SharePoint JavaScripted, dann liegen die JavaScript-Dateien typischerweise in einer Dokumentbibliothek im SharePoint. Nun ist das mit dem Editieren auf einmal doch nicht mehr so ganz einfach. Denn wie kann man am besten JavaScript Dateien in einer Dokumentbibliothek bearbeiten?

Folgende Möglichkeiten stehen dort zur Verfügung:

  • Bearbeiten des JavaScript mit dem SharePoint-Designer. Der SharePoint-Designer hat den Vorteil, dass man halt direkt in der Dokumentbibliothek arbeiten kann. So kann man das JavaScript bearbeiten und direkt speichern und ausprobieren.
  • Öffnen der Dokumentbibliothek im Windows-Explorer. Entweder direkt oder durch mappen des UNC-Pfades auf einen Laufwerksbuchstaben. Leider ist der WebDAV-Zugriff nicht immer ganz schnell, so dass z.B. Notepad++ schon mal pausen einlegt, wenn man zwischen dem Browser und dem Editor wechselt (weil Notepad++ regelmäßig prüft ob sich die Datei im Dateisystem geändert hat).
  • Bearbeiten auf dem lokalen Rechner und anschließendes Hochladen in die Dokumentbibliothek.

Die letzte Möglich ist die naiveste – und auch die nervigste. Denn nach dem Bearbeiten und Speichern muss man immer wieder in die Dokumentbibliothek gehen und die Datei explizit hochladen. Das ist einfach unnötig. Wenn man das doch automatisieren könnte …

Zumindest das manuelle Hochladen von Dateien kann man sich ganz einfach sparen. Mit dem guten alten curl kann man von der Kommandozeile aus HTTP-Zugriffe machen. Das schöne ist – damit kann man z.B. auch HTTP-POSTs durchführen.

curl.exe -T c:\temp\foo.txt --url "http://sp2010.acme.local/Documents/" -u ":" --ntlm

Kann man eine Datei unter den aktuelle Windows-Credentials nach in die Dokumentbibliothek “Documents” SharePoint laden.

Wenn man das nun noch mit dem NppExec-Plugin von Notepad++ kombiniert, dann kann man sich ein folgendes Kommando anlegen:

NPP_SAVE
c:\tools\curl.exe -T "$(FULL_CURRENT_PATH)" --url "http://sp2010.acme.local/Documents/" -u ":" --ntlm

In Notepad++ kann man dann mit F6 den Execute-Dialog aufrufen und das zuletzt verwendete Kommando wird angezeigt und kann direkt ausgeführt werden. Somit wird die aktuelle Datei zuerst gespeichert und dann nach SharePoint geladen.

npp

Schnell mal ActiveDirectory

By Henning Eiben in Infrastruktur 0 Comment

Gerade in Verbindung mit SharePoint braucht man ja auch häufig ein Active Directory. Also gehört es zur Pflicht-Übung für ein Demo-System auch schnell mal ein AD aufzusetzen.

Das ist im Kern nicht so wirklich schwer – besonders wenn es ja nur zu Demo-Zwecken ist. Aber irgendwie lästig ist es ja doch.

Zuerst muss man das entsprechende Feature in Windows hinzufügen:

Import-Module servermanager
Add-WindowsFeature adds-domain-controller

Anschließend muss dann noch die Domäne angelegt werden. Also hier mal eben die Anlage eines neue AD per Kommandozeile. Einfach auf einem Windows 2008 Server (oder neuer) ausführen:

# Windows Server 2008
 $unattend = "c:\unattend.txt"
if(!(test-path $unattend)) { new-item $unattend -type file }
$content = @(
    "[DCInstall]"
    "ReplicaOrNewDomain=Domain"
    "NewDomain=Forest"
    "NewDomainDNSName=acme.local"
    "ForestLevel=4"
    "DomainNetbiosName=ACME"
    "DomainLevel=4"
    "InstallDNS=Yes"
    "ConfirmGc=Yes"
    "CreateDNSDelegation=No"
    'DatabasePath="C:\Windows\NTDS"'
    'LogPath="C:\Windows\NTDS"'
    'SYSVOLPath="C:\Windows\SYSVOL"'
    'SafeModeAdminPassword="P@ssw0rd1"'
    "RebootOnCompletion=Yes"
    )
$content | out-file $unattend
$dcpromo = "dcpromo /unattend:$unattend"
invoke-expression -command $dcpromo

ggf. müssen die Angaben zur Domäne noch angepasst werden.

Unter Windows Server 2012 geht das etwas kürzer, hier gibt es ein entsprechendes PowerShell cmdlet.

Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'acme.local' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Default-First-Site-Name' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$true -Force:$true

Autovervollständigung beim PeoplePicker

By Henning Eiben in SharePoint 1 Comment

Wenn man in einer SharePoint-Liste ein Feld vom Typ “Personenauswahl” hinzufügt, dann bekommt man automatisch in den Formularen einen sogenannten PeoplePicker. Das ist ein Feld, in dem man einen Namen, ein Benutzerkonto oder eine eMail-Adresse eingeben kann. Wird der Benutzer erkannt, wird der Name unterstrichen dargestellt, ansonsten wird er mit einer roten Schlangenlinie versehen.

people_picker_01

Über das Adressbuch kann ich einen Suchdialog öffnen um nach Personen zu suchen, wenn ich z.B. nur einen Teil des Namens kenne.

people_picker_02

Das ist aber irgendwie lästig auf diese Art und Weise zu suchen, weil man immer diesen Dialog öffnen muss, dann auf Suchen klicken muss und den gefundenen Treffer auch noch übernehmen muss. Besser wäre es also, wenn man in dem eigentlichen Feld direkt einen Teil des Namens eingeben könnte und man würde eine kleine Liste mit Vorschlägen bekommen.

people_picker_03

Praktischerweise gibt es da auch schon was … mit JavaScript! Alexander Bautz hat vor ein paar Jahren auf seinem Blog beschrieben, wie man so einen People-Picker um Autovervollständigung ergänzen kann.

Ich will die notwendigen Schritte hier nicht wiederholen, stattdessen sei auf den Blogpost verwiesen. Die Einbindung ist eigentlich ganz einfach, erfordert lediglich einen Kniff – die GUID der Benutzerliste.

Um an die GUID zu kommen ruft man einfach die Benutzerliste auf. Jede Websitesammlung hat eine solche Liste, die man über /path-to-my-sitecollection/_catalogs/users erreichen kann. Anschließend die Quellcode-Ansicht für die Seite öffnen und nach ctx.ListName suchen. Voila, schon hat man die GUID.

Kleiner Hinweis noch: die Autovervollständigung kann nur Benutzer vorschlagen, die sich auch schon mal auf der Site angemeldet hatten, denn nur diese Benutzer sind in der Benutzerliste vorhanden.

Wie groß ist mein SharePoint?

By Henning Eiben in SharePoint 0 Comment

Jetzt hatte ich doch gerade die Frage: wie groß ist eigentlich meine ContentDatenbank meiner aktuellen Site-Collection? Und weil ich Herausforderungen mag: SharePoint 2007 bzw. Windows Services 3.0.

Natürlich gibt es nur einen Weg um dies herauszufinden:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = New-Object Microsoft.SharePoint.SPSite("http://portal.acme.local")
$diskMethod = [Microsoft.Sharepoint.Administration.SPContentDatabase].getMethod("get_DiskSizeRequired")
$diskMethod.Invoke($site.ContentDatabase, "instance,public", $null, $null, $null)

Das Ergebnis zeigt die Größe der Datenbank in Bytes an.

Geht doch!

Doppelte Treffer bei der Personensuche

By Henning Eiben in SharePoint 0 Comment

Die Tage hatte ich die Anfrage eines Kunden:

auf unserer Startseite werden alle Ansprechpartner doppelt angezeigt.

Hintergrund ist, dass für die Anzeige der Ansprechpartner ein Such-WebPart verwendet wird, welches eine Personensuche nach einer bestimmten Abteilung anzeigt.

Wie auch immer – auch bei der “normalen” Suche nach einem Mitarbeiter wird dieser doppelt in der Suche nagezeigt. Komisch.

Die Lösung ist dann recht einfach – aber dennoch interessant. In den Inhaltsquellen waren zwei Einträge mit dem Protokoll SPS3:// vorhanden. Daraufhin wurden alle Personen doppelt in den Index gecrawlt.

search_sps3

Was ich dabei interessant finde ist die Tatsache, dass SharePoint bei der Anzeige der Ergebnisse Duplikate nicht aussortiert – ich hätte auch erwartet, dass er Duplikate vielleicht gar nicht in den Index aufnimmt.

Wie auch immer – den doppelten Eintrag entfernt und einen Full-Crawl später war dann alles wieder wie gehabt.

Es geht nicht ohne: PowerShell und SharePoint

By Henning Eiben in SharePoint 0 Comment

Es geht doch nichts über Rituale. Ich bin also gerade auf einem SharePoint-Server als Farm-Admin eingeloggt und wollte ein wenig powershellen. Und da kommt die Meldung:

Auf die lokale Farm kann nicht zugegriffen werden. Cmdlets mit `FeatureDependencyId`sind nicht registriet.

Wer kennt die Meldung nicht. Und warum ist die da: Sicherheit. Nur Farm-Admin reicht halt für die PowerShell nicht (Ach so: natürlich habe ich meine PowerShell schon mit erhöhten Rechten gestartet, das ist doch klar).

Was ist nun also das Problem? Der Benutzer ist zwar Farm-Admin, kann aber von der Shell nicht direkt auf die Datenbanken von SharePoint zugreifen. Somit kann ich die meisten PowerShell Befehle (für SharePoint) nicht durchführen. Wenn ich nun also doch mal ein Get-SPWebApplication “foo” mache, dann bekomme ich die Meldung

Auf die lokale Farm kann nicht zugegriffen werden. Vergewissern Sie sich,. dass die lokale Farm ordnungsgemäß konfiguriert sowie aktuell verfügbar ist und Sie über ausreichende Berechtigungen verfügen, um auf die Datenbank zugreifen zu können, bevor Sie es erneut versuchen.

Aha – das steht’s ja schon. Ich kann nicht auf die Datenbank zugreifen. Um das Zu ändern gibt es den Befehl Add-SPShellAdmin. Nur dumm, dass ich den als jemand ausführen muss, der über entsprechende Berechtigungen verfügt (also der schon Shell-Admin ist).

Na gut, dann muss dafür mal eben kurz der spFarm herhalten. Also eben eine CMD als spFarm gestartet mit

runas /user:spFarm cmd

und dann eine PowerShell starten. Hierbei muss diese aber elevated gestartet werden, und dass vom Prompt aus. Das geht eigentlich auch ganz einfach

@powershell Start-Process -Verb "runas" powershell

So, nun habe ich also eine PowerShell als spFarm mit erhöhten Rechten. Der Rest ist einfach

Add-PSSnapin Microsoft.SharePoint.PowerShell
Add-SPShellAdmin busitec\eiben

Wenn ich nun wieder hingehe und eine SharePoint Verwaltungsshell (mit erhöhten Rechten) starte, dann kann ich auch per PowerShell auf die Farm zugreifen.

Voila!