Bei der Installation von SharePoint 2016 kam mir erstmalig diese Meldung während der Ersteinrichtung entgegen:
There is insufficient system memory in resource pool ‘internal’ to run this query.
Ursache: die SQL-Server Instanz war zu sparsam mit RAM ausgestattet! Einfach ein paar MB mehr, und schon geht’s auch mit SharePoint wieder.
Nintex Workflow für SharePoint 2010 und SharePoint 2013 hat im Januar eine sehr interessante neue Funktion erhalten: Workflow Inventory.
Diese Funktion ist für SharePoint 2013 ab der Version 3.1.7.0 und für SharePoint ab der Version 2.4.7.0 verfügbar.
Damit ist es nun möglich aus der Zentraladministration heraus sich einen Überblick über alle vorhandenen Workflows zu verschaffen. Die Übersicht ermöglicht es einem die Site-Collection, die Site die Liste und den Workflow direkt aus der Übersicht heraus aufzurufen.
Zudem ist erkennbar wann ein Workflow zum letzten mal bearbeitet wurde und ob es bereits eine neuer, noch nicht veröffentlichte Version des Workflows gibt. Darüber hinaus kann man auch sehen, wann der Workflow zuletzt ausgeführt wurde. Somit lassen sich z.B. alte und verwaiste Workflows recht leicht identifizieren.
Bei sehr vielen Workflows ist diese Ansicht womöglich nicht sehr übersichtlich – dazu kann die Liste auch als CSV-Datei exportiert werden um dann z.B. in Excel weiter ausgewertet zu werden.
So, es gab mal wieder einen richtigen Patch-Day … so mit allem was dazu gehört: Updates, die über den WSUS kommen, Updates die man herunterladen muss (SP 2010 & SP2013), Pre-Requisits für Updates und Updates, die sich nicht installieren lassen.
Somit dürfte als IT-Pro keinerlei Langeweile aufkommen.
Neue Woche – neue Features 
Dieses mal: Delve.
Es gibt ein paar neue Features in Delve, zum einen gibt es einen schöner gestalteten Kopfbereich, mit Hintergrund (kann man den auch ändern?) von wo aus ich direkt Lync (Chat und Phone) ansprechen kann. Ebenfalls neu ist, dass ich direkt Dokumente in Yammer kommentieren kann.
Auch die Profilseite ist neu gestaltet, wobei sich mir noch die Frage stellt, warum es zwei Profil-Seiten gibt, die sich vom Design ähnlich sind, aber dann doch wieder verschieden.
Eigentlich sollte mit Vista, Windows 7, Windows 8.x alles besser sein – aber ganz so gut ist dann doch nicht alles. Wenn man unter Vista, Windows 7, Windows 8.x aus dem Sharepoint (egal ob 2003, 2007, 2010 oder 2013) ein Office-Dokument öffnet, wird man mindestens einmal beim Öffnen nach seinen Credentials gefragt; das nervt!
Das Problem: Dokumente im Sharepoint werden via WebDAV geöffnet. Nun denkt der IE, dass es sich bei einer URL in der Form servername.busitec.de um eine Internet-Adresse handelt und übermittelt die Login-Credentials nicht (warum auch immer, ist aber in KB 941853 entsprechend dokumentiert). Interessanterweise tritt das Problem nicht auf, wenn man auf die Adresse nur mit der Servernamen zugreift – also ohne Domain-Suffix (siehe KB 941890).
Wer nach dem studieren der beiden KB-Einträge auf die Idee kommt, dass man ja einfach die Automatische Proxy-Suche aktiviert – ätsch, das bringt nix außer extra Wartezeiten beim Öffnen der Dokumente. Der Credential-Dialog kommt auch weiterhin.
Ein wenig weitergesucht – und siehe da, es gibt einen Blogeintrag vom Sharepoint Team, der sich mit dem Problem recht ausführlich beschäftigt. Die Lösung:
In komplexeren Systemumgebungen kann es schon mal vorkommen, dass es mehr als eine Active Directory Domäne gibt.
In meinem Fall gibt es neben der Produktiven Domäne acme.local noch eine Domäne für den Entwicklungsbereich dev-acme.local. Zwischen den beiden Domänen gibt es eine einseitige Vertrauensstellung, so dass man sich mit seinem Account eiben@acme.local auch an dev-acme.local anmelden kann, nicht aber mit deinem dev-acme Account an der acme Domäne. Soweit alles klar.
Was aber, wenn ich in der dev-acme.local Domäne einen SharePoint stehen habe, auf den ich auch mit den acme.local Accounts zugreifen will? Wenn in SharePoint Berechtigungen vergeben werden, dann schlägt SharePoint den Account in der Domäne nach. In diesem Fall ist der SharePoint in der dev-acme.local Domäne installiert und läuft natürlich auch mit entsprechenden Service-Accounts (wie dev-acme\spAppPool). Dieser kann aber aufgrund der Vertrauensstellung keine Accounts aus acme.local nachschlagen, da dieses nachschlagen ja unter der Identität des Application-Pools der Web-Anwendung stattfindet (und die Domäne acme.local kann aus Sicherheitsgründen nur von Authentifizierten Benutzern abgefragt werden).
Zum Glück kann man SharePoint zu genau diesem Zweck sagen, dass für den Zugriff auf eine bestimmte Domäne ein anderer Account verwendet werden soll. Somit kann ich also auch auf andere Domänen zugreifen.
Zunächst brauche ich einen Account in der acme.local Domäne, mit dem ich Benutzerkonten nachschlagen kann. Dafür reicht ein normaler Benutzer, der eigentlich keine besondere Rechte benötigt (außer dass er halt auf das AD zugreifen können muss). Ich habe den mal devlookup genannt.
Bevor ich SharePoint diesen Account für die Lookups beibringen kann, muss ich noch einen Verschlüsselungsschlüssel erstellen.
STSADMstsadm.exe -o setapppassword -password MeinGeheimerSchluessel
Nun kann ich SharePoint mitteilen, dass für die Web-Application mit der URL sp2013.dev-acme.local beim Zugriff auf die Domäne acme.local das Konto acme\devlookup verwendet werden soll:
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "domain:acme.local,acme\devlookup,MeinPasswort" -url http://sp2013.dev-acme.local
Unglaublich, dass diese Einstellung nur mit dem guten alten STSADM geht. Aber so ist es halt nun mal – auch in Zeiten von PowerShell.
Auch wenn in vielen Unternehmen der Internet-Explorer quasi Standard ist, so ist der Interner-Explorer schon lange nicht mehr die Voraussetzung dafür, dass man sich an SharePoint ohne weitere Anmeldung mit seinen Windows-Credentials anmelden kann. Eigentlich hat das nichts mit SharePoint direkt zu tun, sondern betrifft Web-Anwendungen im allgemeinen.
Um sich automatisch bei SharePoint anzumelden (ich bleibe mal bei SharePoint), muss auf der Server-Seite die Windows Integrierte Anmeldung verwendet werden. Dabei werden die Windows-Credentials vom Client an den Server gesendet und zur Authentifizierung verwendet. Früher beherrschte lediglich der Internet Explorer die Weitergabe von Credentials, das hat sich (schon vor längerer Zeit) geändert. In zwischen beherrschen auch Firefox, Chrome und Safari die Windows Integrierte Anmeldung.
Beim Firefox muss dazu angegeben werden, für welche Domänen Firefox Authentifizierungsinformationen weitergibt. Das entspricht quasi den Zonen-Einstellungen des Internet-Explorers. Dazu muss im Firefox zunächst mit about:config die erweiterten Einstellungen geöffnet werden. Anschließend kann man mit den beiden Einstellungen network.negotiate-auth.trusted-uris (für Kerberos Authentifizierung) und network.automatic-ntlm-auth.trusted-uris (für NTLM Authentifizierung) die Domänen angeben, für die die Authentifizierung erlaubt sein soll. Bei mehreren Domänen kann man die mit Komma trennen.
Chrome bedarf keinen weiteren Einstellungen, hier funktionieren NTLM und Kerberos direkt. Beim Safari funktioniert nur Kerberos, wenn man bereits über ein Kerberos-Ticket verfügt.
Damit steht also der großen Browser-Vielfalt nicht mehr im Wege.
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:
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.
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, …).
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.
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"}
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.
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.
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.
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.
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.
