SharePoint Online Management Shell – Remote PowerShell

Mittels einer PowerShell Shell kann Remote auf die Office 365 Infrastruktur zugegriffen werden. Hier ein Beispiel für die Verbindung auf SharePoint Online.

Voraussetzungen
Software: Installation der SharePoint Online Management Shell –> Link
Berechtigungen Cloud: Global Administrator im Office 365 Tenant –> Link
Berechtigungen Lokal: PowerShell Shell als Administrator öffnen

# Connect with Tenant Admin
$User = "xy@domainname.com"
# Specify Tenant Admin URL
$TenantURL = "https://domainname-admin.sharepoint.com"
# Import PowerShell Module
Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
# Connect to Tenant
Connect-SPOService -Url $TenantURL -Credential $User
# Connected

Beispiel

# Auslesen von Basis Informationen über jede Site Collection (ohne My Sites)
Get-SPOSite -Detailed | Export-CSV -LiteralPath C:\temp\SiteOverview.csv -NoTypeInformation

SQL Abfragen in SharePoint Content Datenbanken

Grundsätzlich ist es aus Sicht von Microsoft nicht erlaubt direkt Abfragen in den SQL Datenbanken von SharePoint Content Datenbanken durchzuführen. Dies unter anderem wegen der Gefahr von Deadlocks. Diese Gefahr kann aber mit dem Zusatz “With (NoLock)” umgangen werden.

Hier ein Beispiel einer Abfrage mit dieser Ergänzung:

Select * from dbo.AllDocs With (NoLock)

Überprüfung Workflow Manager Status

Mit Hilfe der untenstehenden PowerShell Befehle kann der Status der Workflow Manager Dienste überprüft werden.

Wichtig: Diese Befehle funktionieren nur auf einen Server, der Bestandteil einer Workflow Manager Farm ist.

Import-Module WorkflowManager
Get-WFFarmStatus

Beispiel:

HostName : Hostname.domain
ServiceName : WorkflowServiceBackend
ServiceStatus : Running

HostName : Hostname.domain
ServiceName : WorkflowServiceFrontEnd
ServiceStatus : Running

SharePoint 2007 Hyperlinks auslesen

Die Hyperlinks der SharePoint Anwender befinden sich unter SharePoint 2007 in der User Profile Datenbank. Mit Hilfe eines SQL-Statements können die gespeicherten Hyperlinks für alle Benutzer in der Farm einfach ausgelesen werden.

use SSP1_DB

SELECT [NTName], [PreferredName], [Title], [GroupType], [GroupTitle], [Url]
FROM [SP_SSP1_DB].[dbo].[UserLinks]
LEFT OUTER JOIN [UserProfile_Full] ON UserLinks.RecordId = UserProfile_Full.RecordID
ORDER BY PreferredName, Title

SharePoint Datenbanken auflisten

Mit dem folgenden PowerShell Befehl (ausgeführt auf dem SharePoint Server) werden alle Datenbanken aufgelistet, die von der entsprechenden SharePoint Farm genutzt werden. Dies ist dann hiflreich, wenn diverse SharePoint Farmen einen gemeinsamen SQL Server nutzen.

Get-SPDatabase -ServerInstance "SQLServerHostname" | Out-File C:\temp\ListofSPSQLDBs.txt

SharePoint Zertifikats Fehler – “The root of the certificate chain is not a trusted root authority”

Dieser Eintrag erläutert die Vorgehensweise bei der Analyse von Zertifikats Fehlern im SharePoint Umfeld. Eine fehlerhafte Konfiguration kann dazu führen, dass es Performance-Probleme und/oder Timeouts beim Anzeigen von Seiten gibt.

Um allfällige Fehler in einem ersten Schritt überhaupt zu lokalisieren stellt Windows out of the Box ein sehr gute Logfunktionalität zur Verfügung (CAPI2). Diese muss aber zuerst aktiviert (und gefunden) werden. Dabei muss folgendermassen vorgegangen werden:

Im Event Viewer unter Application and Services Logs > Microsoft > CAPI2 > Operational mittels Linksklick das Logging aktivieren (“Enable Log”).

CAPI 2 Logging

Nach Aktivierung des Logs erscheinen die Servermeldungen bezüglich Zertifikate. Mit Klick auf das Register Details (in der jeweiligen Meldung) findet man dann die “Übeltäter”.

Weitere hilfreiche Tipps zu diesem Problem bzw. das Vorgehen zur Fehlerbehebung gibt es hier zu finden:

http://www.sharepointblues.com/2012/01/09/sharepoint-certificate-errors/
http://sharepointlark.wordpress.com/2012/03/12/another-ssl-issue/ 
Site slowness due to SharePoint STS Certificate CRL checking
Certificate Revocation List Check and SharePoint 2010 without an Internet Connection

SharePoint 2010: Some or all identity references could not be translated

Wenn die Meldung “Some or all identity references could not be translated” beim Zuweisen eines Managed Accounts in SharePoint 2010 erscheint (innerhalb der Central Administration oder mittels Code [PowerShell]) ist die Ursache meistens ein zu langer Names des Servicaccounts.

SharePoint 2010: Some or all identity references could not be translated

SharePoint 2010: Some or all identity references could not be translated

Hintergrund dabei ist die AD Kompatibilität zu Pre-Windows 2000, wo ein Benutzername nicht länger als 20 Zeichen lang sein darf.

Konfiguration SharePoint Claim Mappings

Die nachfolgende Übersicht zeigt die Schritte innerhalb SharePoint 2010, die notwendig sind um eine SharePoint Applikation Claims-Based fähig zu machen.

1. Erstellen SharePoint Trusted Root Authority
Mit dem folgenden PowerShell Code (SharePoint 2010 Management Shell Konsole) wird das Signing Zertifikat des Partners innerhalb SharePoint als Trusted Root Authority definiert. Damit wird der Trust zwischen SharePoint und dem Partner (Identity Provider (IdP), ADFS etc.) aufgebaut.

$certPath = "c:\contosotokensign.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")
New-SPTrustedRootAuthority -Name "Contoso ADFS Token Signing Root Authority" -Certificate $cert

2. Zuweisung Claims
Anschliessend erfolgt die Zuweisung der einzelnen Claims. Dafür müssen innerhalb der SharePoint 2010 Management Shell Konsole die Claims (in diesem Beispiel sind es deren zwei: Emailadresse und Rolle) den entsprechenden Variablen zugewiesen werden. Diese Variablen $map1 und $map2 werden dann in Schritt 4 für die Erstellung des Providers benötigt:

$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -
IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -
IncomingClaimTypeDisplayName "Role" -SameAsIncoming

3. Definition Realm und Sign-In URL
In diesem Schritt wird der Applikations-Realm und die Sign-In URL (für die Login-Seite) definiert.

$realm = "urn:contoso:sharepoint:portal"
$signinurl = "https://contosoadfs2.contoso.com/adfs/ls"
$certPath = "c:\contosotokensign.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")

4. Erstellen des Trusted Identity Token Issuers (Claims Provider)
Mit dem nächsten Befehl wird der eigentliche Claims Provider erstellt. Wichtig in diesem Zusammenhang ist die Definition des IdentifierClaim Attributes. Dieses definiert welches der Attribute zur Identifikation von Benutzern verwendet wird.

$ap = New-SPTrustedIdentityTokenIssuer -Name "Contoso ADFS 2.0" -Description "Contoso ADFSv2 Token Issuer" -realm $realm -ImportTrustCertificate $cert -
ClaimsMappings $map1,$map2 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

http://blogs.msdn.com/b/spidentity/archive/2010/01/23/claims-based-authentication-cheat-sheet-part-2.aspx

5. Erstellen/Konfiguration der SharePoint Webapplikation
Damit eine Webapplikation Claims-fähig ist muss diese über die “Claims Based” Authentication Option verfügen.

Das Erstellen kann entweder per GUI (mit Hilfe der Central Administration) oder mittels PowerShell Script vorgenommen werden.