Migration Sharepoint Fondation 2010 auf 2013 inkl. Content

Migration SharePoint Fondation 2010 -> 2013

--- SHAREPOINT 2010 READONLY MODE ---

Ich habe als ersten Schritt den alten Sharepoint 2010 in den ReadOnly-Modus versetzt, damit während der Datenmigration keiner mehr Änderungen durchführt, aber die Daten noch erreichbar sind.

- Öffnen der Zentraladministration
- Im Menü links "Anwendungsverwaltung" auswählen
- In der Übersicht rechts den Unterpunkt "Kontingente und Sperren konfigurieren" bei "Webseitensammlungen" auswählen
- Die gewünschte Webseitensammlung auswählen und den Punkt "Schreibgeschützt" setzen.
- Fertig, jetzt können keine Änderungen mehr vorgenommen werden und die Migration kann beginnen.

--- Prerequisite-Installer ---

Powershell-Installation der nötigen Serverkomponenten, da es sonst zu Fehlermeldungen kommt.
Import-Module ServerManager

Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer

Jetzt den Sharepoint Prerequisite-Installer starten und durchlaufen lassen:

• Microsoft .NET Framework 4.5: gleichwertige Produkte waren bereits installiert (es ist keine Aktion erfolgt).
• Windows Management Framework 3.0: gleichwertige Produkte waren bereits installiert (es ist keine Aktion erfolgt).
• Anwendungsserverrolle, Webserverrolle (IIS): erfolgreich konfiguriert.
• Systemeigener Client von Microsoft SQL Server 2008 R2 SP1: erfolgreich installiert.
• Microsoft Sync Framework Runtime v1.0 SP1 (x64): erfolgreich installiert.
• Windows Server AppFabric: erfolgreich installiert.
• Microsoft Identity-Erweiterungen: erfolgreich installiert.
• Microsoft Information Protection and Control-Client: erfolgreich installiert.
• Microsoft WCF Data Services 5.0: erfolgreich installiert.
• Microsoft WCF Data Services 5.6: erfolgreich installiert.
• Kumulatives Updatepaket 1 für Microsoft AppFabric 1.1 für Windows Server (KB2671763): erfolgreich installiert.

Reboot

--- SQL EXPRESS INSTALLATION ---

Instanzname : Server=localhost\SQLEXPRESS;Database=master;Trusted_Connection=True;
Version : 14.0.1000.169 (SQL Express 2017)

SQL SERVER MANAGEMENT STUDIO INSTALLATION
Pfad : C:\Program Files (x86)\Microsoft SQL Server Management Studio 18
.NET-Version : 4.7.2

--- SHAREPOINT INSTALLATION ---
Um die Installation erfolgreich durchführen zu können muss die Datei wsssetup.dll getauscht werden, da sonst die .NET-Version nicht erkannt wird, wenn diese höher als 4.5 ist. Dazu müssen wir die Installation entpacken und die Datei austauschen.
Quelle: Setup error if the .NET Framework 4.6 is installed
Zur Installation werden ein Farmadmin-Konto und ein Serviceadmin-Konto benötigt. Bitte brachten, dass diese zwei Konten nur die nötigen Rechte bekommen und kein Domänen-Admin sind.

- sharepoint.exe /extract:C:\SharePointInstaller
- Austausch der wsssetup.dll
- Install Sharepoint (Installationstyp: Vollständig)

--- Sharepoint-Wizard ---

Konfig-Database : \SQLEXPRESS
Konfig-DB-Name : SharePoint_Config
Farmadmin :
Passphrase : xxxxxxxxx
Admin-Center : http://Sservername>:18073/
Auth. Setting : NTLM
Dienst-Konto :

--- Datenmigration ---

- Backup alte Datenbank "WSS_Content" mittels SQL Studio
- Backup-Datei auf neuen Sharepoint kopieren
- Bestehende Sharepoint - 80 Webapplikation löschen (inkl. ISS und Content-Database – NICHT die Central Administration).
- Da die alte WSS-Content-Database mit „windows classic“ Auth daherkommt und die Applikationen aber mit „Claims“ Auth erstellt werden, gibt es Probleme bei der Migration. Somit muss die Sharepoint - 80 Webapplikation manuell über die Powershell erstellt werden:
New-SPWebApplication -Name "Sharepoint Site - 80" -ApplicationPool "SPAppPool" -AuthenticationMethod "Kerberos" -ApplicationPoolAccount (Get-SPManagedAccount "") -Port 80 -URL http://

- Sharepoint-Dienste heruntergefahren und die WSS-Content-Database aus der Sicherungsdatei wiederhergestellen
- Dienste wieder hochgefahren und mit dem nachfolgenden Test die Konfiguration überprüft:
Test-SPContentDatabase -Name WSS_Content –WebApplication http://

Vorsichtshalber noch mal Upgrade der Content-Database durchführen:
Get-SPContentDatabase | Upgrade-SPContentDatabase 

100.00% : SPContentDatabase Name=WSS_Content
Upgrade-SPContentDatabase : Das Upgrade wurde mit Fehlern abgeschlossen. Überprüfen Sie die Upgradeprotokolldatei
unter 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\Upgrade-20190926-103708-855.log'.
Die Anzahl der Fehler und Warnungen ist am Ende der Updateprotokolldatei aufgeführt.
In Zeile:1 Zeichen:25
+ Get-SPContentDatabase | Upgrade-SPContentDatabase
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Share...ContentDatabase:SPCmdletUpgradeContentDatabase) [Upgrade
-SPContentDatabase], SPUpgradeException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletUpgradeContentDatabase


Hiermit noch das Upgrade alle anderen Sharepoint-Datenbanken durchführen um den obrige Fehlermeldung zu lösen
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

Die Konfiguration der SharePoint-Produkte wurde erfolgreich abgeschlossen.

Gesamtanzahl der ausgeführten Konfigurationseinstellungen: 8
Gesamtanzahl der erfolgreichen Konfigurationseinstellungen: 8
Gesamtanzahl der erfolglosen Konfigurationseinstellungen: 0
Die Konfiguration der SharePoint-Produkte wurde erfolgreich beendet.
Die Konfiguration der SharePoint-Produkte war erfolgreich.

Eigentlich fertig! Bei mir war noch das Problem, dass sich kein Benutzer am Intranet anmelden konnte – ich bekam immer ein Fenster zur Eingabe der Anmeldedaten angezeigt. Das hat mir viele graue Haare gekostet, aber am Ende war die Lösung mal wieder logisch und in den Basics versteckt – IIS Authentifizierung!
Hier war Kerberos als Standard gesetzt und ich habe NTLM eingetragen und schon hat alles funktioniert!

- IIS-Manager öffnen
- Sharepoint-Website suchen und Authentifizierung öffnen
- Hier bei „Windows Authentifizierung“ die „Provider“ auswählen
- Hier nur NTLM setzen
- iisreset durchführen – läuft!

Quellen für Hilfestellungen:
Install SharePoint Foundation 2013 on Windows Server 2016 Solution
SharePoint: Common NTLM Authentication Issues, aka: Consider Ditching NTLM
Live Migration of SharePoint 2010 to SharePoint 2013
SQL Server: Einzelbenutzermodus ausschalten
Change SharePoint Site To Read Only

Exchange 2016 DAG: Prüfung und Schwenk der DAG-Datenbanken auf den Master (ReBalance DAG)

Das nachfolgende Skript prüft, ob auf dem aktuellen Exchange DAG Server Datenbank laufen, für die er nicht der "Prefered ActiveServer" ist bzw. ob ihm selbst Datenbanken "fehlen", für die er selbst der "Prefered ActiveServer" ist.
Für jede gefundene Datenbank erfolgt eine gesonderte Abfrage, ob diese zurückgeschwenkt werden soll.
Für korrekte Datenbanken erfolgt nur eine Ausgabe. Zur optischen Prüfung werden die Ausgaben farblich mit rot und grün dargestellt:

# Das Skript überprüft den lokalen Server, ob Datenbanken auf dem System gemountet sind,
# welche primär auf einem anderen Server laufen sollten
# Werde solche Datenbanken gefunden, dann werden diese zurückverschoben und das DAG wieder
# in den ausbalancierten Zustand gebracht
#
# Ralf Entner

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Get-MailboxDatabase -server $env:COMPUTERNAME | Sort Name | ForEach{
    $db = $_.Name
    $ActivServer = $_.Server.Name
    $OriginServer = $_.ActivationPreference | ? {$_.Value -eq 1}


    If ($ActivServer -ne $OriginServer.Key)
    {
        Write-Host "$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen – FALSCH" -ForegroundColor Red
        Move-ActiveMailboxDatabase $db -ActivateOnServer $($OriginServer.Key) -Confirm:$Y
    }
    Else
    {
       Write-Host "$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen - OK" -ForegroundColor Green
    }
}

Exchange 2016 DAG: Server aus den Wartungsmodus (Maintenance) per Powershell nehmen

Problem:
Auch beim beenden des Maintenance-Modus wollte ich das ganze Skripten und standardisieren.

Lösung:
Im Endeffekt arbeitet das PowerShell alle vorherigen Befehle in umgekehrter Reihenfolge ab, um den Server wieder sauber online zu nehmen. Ich schwenke die Datenbanken NICHT automatisch zurück sondern überlasse es der automatischen PreferenceMoveFrequency die Datenbanken wieder zurückzuschwingen (Default: 1 Stunde).

Man kann die PreferenceMoveFrequency abfragen mit folgenden Befehl:
 Get-DatabaseAvailabilityGroup | Format-Table Name, Preference*

Theoretisch kann man diese auch anpassen oder mit einer Time von "00:00:00" deaktivieren.
Hier mein Skript zum Beenden des Wartungs-Modus (Maintenance). Am Ende des Skripts gebe ich noch einige Prüfroutinen aus, um zu sehen, dass alle Dienste und Komponenten wieder korrekt laufen - das ist aber noch ausbaufähig.

Write-Host "Server-Komponeten werden aktiv gesetzt"
Set-ServerComponentState $env:ComputerName –Component ServerWideOffline –State Active –Requester Maintenance

# ClusterNode wieder UP setzen
Write-Host "ClusterNode wird online genommen"
Resume-ClusterNode –Name $env:ComputerName

# Mailbox-Datenbank wier online setzen und für Rückschwenk aktivieren
# KEIN aktives zurückschwenken
Write-Host "Mailboxdatenbanken werden wieder aktiv genommen"
Write-Host "Es wird keine Datenbank aktiv zurückgenommen"
Set-MailboxServer $env:ComputerName –DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer $env:ComputerName –DatabaseCopyActivationDisabledAndMoveNow $false

# Hub-Transport wieder ACTIVE setzen - MAils werden wieder angenommen
Write-Host "Hub-Transport wird online genommen - Mails werden wieder angenommen"
Set-ServerComponentState $env:ComputerName –Component HubTransport –State Active –Requester Maintenance

# Aktivierung Defender und PS-Restriction-Policy
Write-Host "Defender und PS-Policy werden wieder aktiviert"
Set-MpPreference -DisableRealtimeMonitoring $false
Set-ExecutionPolicy RemoteSigned -force

# Prüfen ob immer noch imWartungsmodus
if ((Get-ClusterNode -Name $env:Computername).state -eq "Up")
	{
	  Write-Host "Server $env:ComputerName befindet sich im NORMALMODUS" -ForegroundColor Green
	}

	Else

	{
	  Write-Host "Server $env:ComputerName befindet sich immer noch im WARTUNGSMODUS" -ForegroundColor Red
 	  Write-Host "Bitte prüfen Sie die Dienste und Eventlogs auf Fehler" -ForegroundColor Red
	}

# Prüfroutinen für Dienste und Komponenten - jeweils mit Pause für Prüfung
Write-Host "###########################################################" -ForegroundColor Yellow
Write-Host "####### Ausgabe aller wichtigen Dienste zur Prüfung #######" -ForegroundColor Yellow
Write-Host "###########################################################" -ForegroundColor Yellow
write-host "`n"
Write-Host "--- ClusterNode muss UP sein ---" -ForegroundColor Yellow
Get-ClusterNode –Name $env:ComputerName
Pause
Write-Host "--- Test-ServiceHealth ---" -ForegroundColor Yellow
Write-Host "Alle Rollen müssen RequiredServicesRunning auf TRUE stehen" -ForegroundColor Yellow
write-host "`n"
Test-ServiceHealth | ft -AutoSize
Pause
Write-Host "--- Überprüfen aller Server-Komponenten ---" -ForegroundColor Yellow
Write-Host "Alle Komponenten ACTIVE bis auf ForwardSyncDaemon und ProvisioningRps" -ForegroundColor Yellow
write-host "`n"
Get-ServerComponentState $env:ComputerName | where {$_.State -ne "Active"} | ft
PAuse
Write-Host "Anzeigen aller Datenbanken" -ForegroundColor Yellow
write-host "`n"
Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | ft
Write-Host "Fertig!" -ForegroundColor Green

Exchange DAG: Server in Wartungsmodus (Maintenance) setzen per Powershell

Problem:
Aktuell musste ich viele Server in einem DAG patchen (CU22, SU etc.) und ich wollte das ganze sauber skripten um Zeit zu sparen und das ganze auch zu standardisieren.

Lösung:
Hier mein Skript, das ich geschrieben habe um den Server sauber in den Wartungsmodus zu setzen. Hier habe ich auch berücksichtigt, dass ich eventuell Mails in den Mail-Queues auf einen anderen Server verschiebe. Das Skript wartet auch, bis alle Datenbanken unmounted sind. Am Ende wird auch nochmal überprüft, ob sich der Server wirklich im Wartungsmodus befindet (Database- und ClusterNode-Checkup)

WICHTIG: Beim "Redirect-Message" MUSS der Target-Server als FQDN angegeben werden und darf selbst nicht in Wartung sein!


# Exchange Module laden
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

# Prüfen ob bereits im Wartungsmodus (ClusterNode not UP und keine Datenbank aktiv gemountet)
if ((Get-ClusterNode -Name $env:Computername).state -ne "Up" -and (Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -eq 0)
	{
	  Write-Host "Server $env:ComputerName befindet sich bereits im WARTUNGSMODUS" -ForegroundColor Green
	  Write-Host "Keine Änderung vorgenommen..." -ForegroundColor Green
Exit
	}

# Sicherheitsfunktionen abschalten (PS-Execution-Policy und Defender)
Write-Host "Server $env:ComputerName wir in den Wartungsmodus versetzt..."
Write-Host "PS-Policy und Defender werden deaktiviert"
Set-ExecutionPolicy Unrestricted -force
Set-MpPreference -DisableRealtimeMonitoring $true
Sleep -Seconds 3
Write-Host "PS-Policy unrestriced und Defender deaktiviert"

# Hub-Transport abschalten
# Es werden keine Mails mehr angenommen
Write-Host "Hub-Transport wird deaktiviert und Mail-Queues verschoben..."
Set-ServerComponentState $env:ComputerName –Component HubTransport –State Draining –Requester Maintenance
Sleep -Seconds 5

# Bestehende Mails werden aus der Queue auf einen anderen Server verschoben
Redirect-Message -Server $env:ComputerName -Target  -Confirm:$false
Write-Host "Hub-Transport deaktiviert"

# ClusterNode in Suspend-Mode
Write-Host "ClusterNode $env:ComputerName wird angehalten"
Suspend-ClusterNode –Name $env:ComputerName
Sleep -Seconds 3
Write-Host "ClusterNode $env:ComputerName angehalten"

# Mailbox-Datenbanken verschieben und 
Write-Host "Aktive Mailboxdatenbanken werden evakuiert"
Set-MailboxServer $env:ComputerName –DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer $env:ComputerName –DatabaseCopyAutoActivationPolicy Blocked
Write-Host "Skript wartet, bis Datenbanken evakuiert wurden - Prüfintervall: 30 Sekunden"
While ((Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -ne 0) 
{
Sleep -Seconds 30
}
Write-Host "Datenbanken wurden alle evakuiert - keine aktive Datenbankkopie mehr auf $env:ComputerName aktiv"

# Server-Komponenten deaktivieren
Set-ServerComponentState $env:ComputerName –Component ServerWideOffline –State InActive –Requester Maintenance
Write-Host "Alle Server-Komponenten deaktiviert"

# Prüfen ob im Wartungsmodus (keine aktiven Datenbanken und ClusterNode not UP)
if ((Get-ClusterNode -Name $env:Computername).state -ne "Up" -and (Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -eq 0)
	{
	  Write-Host "Server $env:ComputerName befindet sich im WARTUNGSMODUS" -ForegroundColor Green
	}

	Else

	{
	  Write-Host "Server $env:ComputerName befindet sich NICHT im WARTUNGSMODUS" -ForegroundColor Red
	  Write-Host "Bitte prüfen Sie die Dienste und Befehle auf Meldungen" -ForegroundColor Red
	}



Exchange DAG: Prüfen ob alle Datenbanken auf den originalen Servern gemountet sind

Ich arbeite aktuell an einem DAG welches aus acht Servern mit vielen Datenbanken besteht. Um, zu prüfen, ob alle Datenbanken auf ihren originalen Servern gemountet sind, habe ich mir folgendes kleines Skript geschrieben:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Get-MailboxDatabase | Sort Name | ForEach{
    $db = $_.Name
    $ActivServer = $_.Server.Name
    $OriginServer = $_.ActivationPreference | ? {$_.Value -eq 1}


    If ($ActivServer -ne $OriginServer.Key)
    {
        Write-Host “$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen – FALSCH” -ForegroundColor Red
  
    }
    Else
    {
        Write-Host “$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen - OK” -ForegroundColor Green
    }
}

Das Skript gibt aus, ob eine Datenbank auf einem "falschen" Server läuft und wo sie gemountet werden sollte.
Zur optischen Unterstützung werden die Einträge rot und grün eingefärbt.

Exchange Powershell: Prüfen der Exchange Schema Version

Problem:
Bei der Installation eines kumulativen Updates der Exchange Server ist meistens nicht ganz klar, ob ein Schema Update nötig ist oder nicht. Microsoft gibt meistens die nötige Schema Version an.

Lösung:
Um zu prüfen, ob ich die richtige Version bereits verwende, habe ich mir ein PowerShell-Skript geschrieben, das die Exchange Schema Version ausgibt:

# Exchange Schema Version

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
$ru = "RangeUpper: $((Get-ADObject $ob -pr rangeUpper).rangeUpper)"

$dc = (Get-ADRootDSE).DefaultNamingContext
$ob = "CN=Microsoft Exchange System Objects," + $dc
$ovd = "ObjectVersion (Default): $((Get-ADObject $ob -pr objectVersion).objectVersion)"

$cc = (Get-ADRootDSE).ConfigurationNamingContext
$fl = "(objectClass=msExchOrganizationContainer)"
$ovc = "ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc -pr objectVersion).objectVersion)"

Write-Output $ru $ovd $ovc


Eine schöne Übersicht der jeweiligen Schema Version findet ihr bei Ali:
Ali Tajran: Exchange schema versions (up to date list)
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)