Veeam Endpoint Backup FREE: Wie setze ich die Veeam Datenbank und Konfiguration zurück

Problem:
Ich hatte das Problem, dass meine Backup-Platte defekt war und ich daher die Veeam-Sicherung neu einrichten musste. Dazu wollte ich aber nicht die ganze Software deinstallieren. Ich wollte nur die komplette Konfiguration löschen und neu einrichten.

Lösung:
Mit der nachfolgenden Prozedur wird die komplette Backup-Historie und -Konfiguration gelöscht!
Die Backup-Daten bleiben aber erhalten.

1.) Folgenden Registry-Key setzen:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Endpoint Backup
Value Name: RecreateDatabase
Value Type: DWORD
Value: 1 (= Reset Database)

2.) Neustart des Dienstes "Veeam Agent for Microsoft Windows"

3.) Neustart von Veeam Backup und es öffnet sich der Konfigurationsassistent! FERTIG!

Quelle:
tinkertry.com: How to manually reset your Veeam Endpoint Backup FREE database

Exchange 2013: Anleitung zur Migration der PublicFolder von Exchange 2007 nach Exchnage 2013

Problem:
Ablauf der PublicFolder-Migration von Exchange 2007 auf Exchange 2013

Lösung:
Hier stelle ich meine Skript-Sammlung und Ablauf-Prozedur für meine Migration da.
Ich habe hier meine öffentliche Ordner von einem Exchange 2007 auf einen Exchange 2013 CU16 erfolgreich migriert.
Dabei gibt es einige Ecken, die man wissen muss, sonst wunder man sich über das Verhalten und die Vorgehensweise.

Vorbereitung:
- Laden Sie sich die Public Folder Migration Scripts von Microsoft herunter (Link finden Sie unten bei den Quellen)
- Kopieren Sie die Skripte auf den alten und neuen Exchange-Server unter "C:\PFMigration\"
- Notieren Sie sich die FQDN des alten und neuen Exchange-Servers
- Sie benötigen einen Exchange-Administrator-Konto
- Alle Postfächer sind bereits auf dem Exchange 2013 migriert
- Es wird eine Downtime für die öffentlichen Ordner geben!
- Holen Sie sich eine Kanne Kaffee, das Szenario kann etwas dauern

Ablauf:

--- START AUF EXCHANGE 2007 ---

1.) Snapshot der "alten Public Folders"
Mit dem nachfolgendem Befehl wird ein Snapshot der PublicFolder-Struktur (Ordner, Struktur und Berechtigungen) angefertigt.
Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml


2.) Prüfen der Struktur

Mit diesem Befehl werden die Ordner-Namen nach "\" im Namen, da diese nicht migriert werden können und der Prozess hier dann abbricht. Vorher müssen alle entsprechenden Ordner in der alten Struktur umbenannt werden.
Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}

WICHTIG: Falls es hier zu Änderungen kommt, muss ein erneuter Snapshot (Punkt 1) erstellt werden!

3.) Migrations-Prüfung
Hiermit prüfen Sie, ob bereits eine Migration läuft und noch nicht abgeschlossen ist.
Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete

4.) CSV mit Ordernamen generieren
Hiermit wird eine CSV mit den Ordnernamen und Größen erstellt
.\Export-PublicFolderStatistics.ps1 PFStat.csv 

5.) PFStat.csv auf Exchange 2013 kopieren
Kopieren Sie die gerade erstellt PFStat.csv auf den Exchange 2013 in das Verzeichnis der Migrationsskripte "C:\PFMigration\"

--- WECHSEL AUF EXCHANGE 2013 ---

1.) Erstellen der nötigen PublicFolder.csv
Hier werden die Anzahl an PublicFolders berechnet und eine CSV für die Erstellung erzeugt.
.\PublicFolderToMailboxMapGenerator.ps1 10GB PFStat.csv FolderToMailbox.csv

2.) Umbenennen der PublicFolder-Mailbox (OPTIONAL)
In der gerade erstellten FolderToMailbox.csv heißt die neue PublicFolder-Mailbox Mailbox1, Mailbox2 etc.
WICHTIG: Man kann diese hier anpassen und muss aber dann auch die nachfolgenden Skripte ebenfalls anpassen!
Bitte beachten: Ich habe diese hier zu "PublicFolder01" umbenannte und meine Skripte daran angepasst.

3.) Neue PublicFolder-Datenbank erstellen
Hiermit wird die neue PublicFolder-Datenbank erstellt und für die Migration reserviert.
New-Mailbox -PublicFolder PublicFolder01 –HoldForMigration: $true

4.) Migration starten
Jetzt den Migrations-Prozess starten
New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server ) -CSVData (Get-Content FolderToMailbox.csv -Encoding Byte)

5.) Migrationsstatus prüfen
Hiermit kann man den Migrationsstatus prüfen und eventuelle Fehler analysieren.
Minimale Ausgabe des Status:
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics

Status-Ausgabe mit Details
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List


ACHTUNG - WICHTIG: MIGRATION LÄUFT NUR BIS 95% UND STOPPT DANN - DAS IST GEWOLLT!
Solange der Parameter PreventCompletion = true ist, wird die Migration nicht vollständig abschließen

ACHTUNG - AB JETZT GIB ES DOWNTIME DER PUBLIC FOLDERS!
NACH DEM NACHFOLGENDEM SCHRITT GIBT ES KEIN ZUGRIFF MEHR AUF LEGACY PUBLIC FOLDER!


6.) Alte Public Folders sperren für endgültige Migration
Mit dem nachfolgendem Befehl werden die alten öffentlichen Ordner für den Zugriff und die endgültige Migration gesperrt.
Set-OrganizationConfig -PublicFoldersLockedForMigration:$true


7.) Freigabe für finale Migration (letzten 5% der Migration)
Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false 


8.) Migration wieder starten
Hiermit wird die zuvor gestoppte Migration wieder gestartet um die letzten 5% abzuschließen.
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration


9.) Prüfen des Migrationsstatus mit Details
Nun müssen Sie die finale Migration überwachen:
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

Sollte die Migration nicht abschließen, dann prüfen Sie die Fehlermeldungen in der Detailausgabe. Wenn hier etwas mit „StalledDueToMailboxLock“ oder „Relinquishing job because the mailbox is locked“ zu lesen ist, dann müssen Sie den Informationstore auf dem alten Exchange 2007 einfach durchstarten. Danach können Sie die Migration erneut starten mittels:
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

Nun sollte alles bis 100% durchlaufen!

10.) Zugriff mit einzelnem Benutzer testen
Um den Zugriff zu testen und nicht gleich alle Benutzer umzustellen verwenden Sie den nachfolgenden Befehl:
Set-Mailbox -Identity TESTUSER -DefaultPublicFolderMailbox mailbox1


11.) Finaler Abschluß der Migration
Erst geben wir den neuen Public Folder für alle frei
Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false 

Nun schließen wir noch die Migrationsbatch ab
Set-OrganizationConfig -PublicFolderMigrationComplete:$true

Jetzt setzen wir den neuen Public Folder für ALLE Postfächer
Set-OrganizationConfig -PublicFoldersEnabled Local


12.) Prüfen der Migration
Nun prüfen wir noch, ob die Migrationsbatch auch als abgeschlossen angezeigt wird
Get-OrganizationConfig | FL PublicFolderMigrationComplete

Außerdem prüfen wir noch, ob der Public Folder für andere Benutzer als Default angezeigt wird
Get-Mailbox SOMERANDOMUSER | FL DefaultPublicFolderMailbox


13.) Aufräumarbeiten
Jetzt müssen wir noch den RemotePublicFolder-Eintrag wieder löschen
Set-OrganizationConfig -RemotePublicFolderMailboxes $null

Set-OrganizationConfig -PublicFoldersEnabled Local


14.) Clients testen
Nun ist es Zeit die Clients zu testen. Das kann etwas dauern, bis die neuen PublicFolders angezeigt werden - AD-Replikation!
Bei mir hat es teilweise bis zu 30 Minuten gedauert, bis auch die letzten Clients die öffentlichen Ordner angezeigt bekommen haben!

LETZTER HINWEIS: Sollte der Benutzer öffentliche Ordner als Favoriten eingetragen haben, dann muss er diese wieder neu setzen...leider!

Quellen:
ENOW: Legacy Public Folder Migration – Notes from the Field
MSExchangeGuru.com: Public Folders Migration from Exchange 2007/2010 to Exchange 2013
Microsoft: Download Public Folders Migration Scripts

Windows 10 / Server 2016: Client bezieht seine Updates direkt von WU und nicht mehr vom WSUS (Dual Scan)

Problem:
Alle Windows 10 Clients und Windows 2016 Server haben sich plötzlich Ihre Updates nicht vom WSUS sondern direkt von Microsoft geholt. Da ich die Kontrolle über meine Updates haben wollte, habe ich mich mit dem Problem beschäftigt und fand auch die Ursache "Dual Scan". Hierbei handelt es sich um einen Update-Mechanismus von Microsoft, der mit Windows 10 1607 bzw. dem Cumulative Update KB4034658 vom August 2017 eingeführt wurde. Wie kann ich jetzt meine Updates wieder selbst kontrollieren?

Lösung:
Dualscan wird immer dann aktiviert, wenn man per GPO einen WSUS-Server den Clients zuweist und gleichzeitig Qualitäts- oder Feature-Updates zurückstellt.
Um das "Problem" zu kontrollieren benötigen Sie die GPOs von Windows 10 1607 und das obengenannte Update KB4034658 für Windows 10 und Server 2016. Wenn Sie die Updates und GPOs (zentrale GPOs bei einer AD) eingespielt haben
Danach finden Sie in den GPOs unter
"Computerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows Update" den Punkt ""Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" Diesen aktivieren Sie und danach wird der Client wieder seine Updates vom WSUS beziehen.
Sollte eine GPO nicht möglich sein, dann können Sie das Ganze auch über die Registry steuern:
Registry Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
Value Name: DisableDualScan
Value Type: REG_DWORD
Values: 1 (Enabled) oder 0 (Disabled)

Quelle: Tchnet: Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed



Check_MK Agent über SSH Verbindung

Wenn man das Check_MK Monitoring nicht über den Standardport (xinet) laufen lassen möchte / kann besteht dich Möglichkeit dies über eine SSH Verbindung zu realisieren. Hierfür muss nur einiges an Vorarbeit erledigt werden.

Auf jedem Host der zu monitoren ist legt man einen User für den Check_Mk Agents an.
useradd -d /home/monitor -c 'CHECK_MK User' -g monitor -m -s /bin/bash monitor
Auf dem Monitoring-Server einen SSH Key für das monitoring erstellen. Dazu logt ihr euch über ssh auf dem Server ein und wechselt mit su - sitename auf die Check_MK Site (User). Dort legt ihr ein SSH-Keypair an.
ssh-keygen -t monitor
dann zeigt ihr euch den schlüssel über cat an und pflegt diesen auf den zu monitorenden Hostsystemen unter dem User monitor ein ( /home/monitor/.ssh/authorized_keys )
cat ~/.ssh/id_monitor.pub
Eintrag auf den Hostsystemen :
command="sudo /usr/bin/check_mk_agent" ssh-rsa [SSH KEY DES SERVERS]
Jetzt muss noch die sudoers Config angepasst werden.
vi /etc/sudoers
Dort fügt man die folgenden Zeilen ein, trägt man den User monitor ein
# Allow User monitor to run check_mk_agent
monitor ALL=NOPASSWD: /usr/bin/check_mk_agent
Jetzt kann man das bis jetzt mal testen.Wenn ihr euch über ssh auf dem Host als User monitor anmeldet, oder den check_mk_agent lokal auf dem Host als User monitor ausführt, muss der selbe output zu sehen sein.

Ist das der Fall muss jetzt noch in der WATO eine Regel erstellt werden.
Unter Host & Service ParametersDatasource ProgramsIndividual program call instead of agent access eine Regel für die Umgebung erstellen
	ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no monitor@$HOSTADDRESS$
dann sollten nach einem TabulaRasa alle Services zu sehen sein.
check_mk_agent über ssh
check_mk_agent über ssh


Mehr Info : Check_MK - Anleitung zu diesem Thema

InfluxDB - Aufbewahrung der Daten managen

Wenn eine Datenbank in Influx erstellt wird gibt es eine default RETENTION POLICY (Aufbewahrungsrichtlinie) mit den Namen "autogen" die DURATION ist dort auf Unendlich und die shardGroupDuration auf 7 Tage konfiguriert . Dies kann man auch bei der Erstellung einer Datenbank mitgeben (allerdings darf man das nicht vergessen ;-)) DATABASE MANAGMENT
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        true
lässt man eine größere Umgebung mit diesen default Werten monitoren ist die Datenbank recht schnell voll und wächst und wächst .......

Um realistische Aufbewahrungsfristen zu realisieren kann man eine neue Policy schreiben, es kommt natürlich immer auf den jeweiligen Anwendungsfall an !
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd" DURATION 12w SHARD DURATION 1d DEFAULT
nun sieht die Retention Policy schon anders aus
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        false
twelve_weeks_only 2016h0m0s 24h0m0s            2        true
die Werte müssen natürlich je nach Anwendungsfall angepasst werden.

Zur Erklärung :

Erstellt eine neue RETENTION POLICY in der Datenbank collectd mit den Namen twelve_weeks_only
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd"
Die Aufbewahrungsfrist der Daten beträgt hier 12 Wochen -> Duration units
DURATION 12w
In einer einzelnen Shard-Group können mehrere Shards vorhanden sein. Jeder Shard enthält eine bestimmte Reihe von Serien. Alle Punkte, die auf eine bestimmte Serie in einer bestimmten Shard-Gruppe fallen, werden im selben Shard (TSM-Datei) auf der Festplatte gespeichert.(auszug InfluxDB Doku)
SHARD / SHARD Groups / SHARD Duration
SHARD DURATION 1d
Setzt die neue Policy als DEFAULT für die Datenbank collectd
DEFAULT
Um mir wieder Platz zu schaffen habe ich danach die Policy "autogen" aus der InfluxDB gelöscht
DROP RETENTION POLICY "autogen" ON "collectd"

Nach der Erstellung der neuen RETENTION POLICY begann die Aufzeichnung der Messwerte wieder bei Null, sollte das nicht gewünscht werden kann man auch die RETENTION POLICY ändern. Der Weg ist aber ungetestet !!
ALTER RETENTION POLICY "autogen" ON "collectd" DURATION 12w SHARD DURATION 7d DEFAULT

VSS Writer: Wie behebe ich VSS Writer Fehler ohne Serverneustart

Problem:
Wer kennt das nicht...ein VSS Writer steht nach dem Backup mit einem Fehler im System und Sie können den Server nicht neu starten, da dieser in Verwendung ist!

Lösung:

1.) Überprüfen Sie mit folgendem Befehl, welcher Writer im Fehler-Status ist:
vssadmin list writers

2.) Hier finden Sie alle VSS Writer und unter Status sollte "Stabil" stehen, ansonsten hat dieser einen Fehler
3.) Folgenden Dienst müssen Sie neu starten um den entsprechenden Writer wieder in den Status "Stabil" zu bekommen
(Achtung: Die Dienste sind in Englisch und könnten von Ihren Namen abweichen)


Quelle: datto: How to resolve VSS writer errors without rebooting (VShadow)
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)