Hope This Helps

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

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

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

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)

Problem:
Die Exchange-Konfigurations-Website (https://mailserver.domain.tld/ecp) ist ja sowohl extern als auch intern erreichbar, wenn man nicht den Luxus eines Reverse-Proxy besitzt. Ich habe immer ein etwas schlechtes Gefühl, wenn meine Exchange-Konfiguration von extern erreichbar ist. Vor allem, wenn z.B. ein IT-Kollege im Zorne ausscheidet und alle Passwörter hat und mir dadurch theoretisch die Datenbank einfach löschen könnte. Da ich keinen Reverse-Proxy besitze musste ich eine andere Lösung finden.

Überlegungen:
Es gibt ja die Möglichkeit die ECP-Admin-Webseite abzuschalten, was das Ganze zwar sicher macht, aber auch nicht mehr administrierbar!
Zuerst wollte ich einfach auf dem IIS die "Einschränkungen für IP-Adressen und Domänennamen" aktivieren. Das löst das Problem mit dem externen Zugriff, hat aber den Nachteil, dass die Benutzer über OWA auch nicht mehr Ihr Konto verwalten können um z.B. den Abwesenheitsassistenten zu aktivieren (Teil des ECP). Also...nur begrenzt gut.
Microsoft selbst sagt, dass man einen zusätzlichen CAS-Server aufsetzen soll, der nur intern erreichbar ist und auf dem externen den Admin-Zugang deaktivieren soll. Leider fehlen mir hierzu die Ressourcen und in kleinen und mittelständigen Unternehmen ist das "a little bit too much"

Lösung:
Die Lösung liegt darin, dass man eine neue ECP-Webseite anlegt und diese im IIS auf eine zweite Netzwerkkarte im Exchange bindet. Die IP-Adresse der neuen Netzwerkkarte ist nur intern erreichbar, wohingegen die "alte" Netzwerkkarten-IP extern erreichbar ist.

Folgende Vorgehensweise zur Lösung:
1.) Fügen Sie dem Exchange-Server eine zweite Netzwerkkarte hinzu.

2.) Vergeben Sie eine neue IP-Adresse für diese Karte und deaktivieren Sie "Diese Verbindung im DNS registrieren", damit der Exchange nicht über mehrere IP-Adresse im DNS erreichbar ist.

3.) Tragen Sie im DNS-Server den FQDN für die neue Webseite mit der neuen IP ein (z.B. ecp.demo.local) - das wird später Ihre URL für den Aufruf werden.

4.) Erstellen Sie auf dem Exchange-Server eine neues Verzeichnis "c:\inetpub\wwwroot2"

5.) Erstellen Sie im IIS eine neue Website und verweisen Sie auf den zuvor erstellten wwwroot2-Ordner und benennen Sie diese z.B. als "ECPIntern"

6.) Binden Sie die neu erstellte Webseite mit Port 80 (http) und Port 443 (https) an die neue, interne IP-Adresse

7.) Erstellen Sie ein neues ECP Virtual Directory mit dem folgenden Befehl (bitte entsprechend anpassen):

New-EcpVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/ecp"

8.) Jetzt benötigen wir noch ein neues OWA Virtual Directory (bitte entsprechend anpassen):

New-OwaVirtualDirectory -Server ServerName -WebSiteName "ECPIntern" -InternalUrl "https://eac.demo.local/owa"

9.) Jetzt müssen wir noch den Admin-Zugriff auf der "alten" IP-Adresse deaktivieren:

Set-ECPVirtualDirectory -Identity "ServerName\ecp (default web site)" -AdminEnabled $false

10.) Ich habe mir jetzt noch über den Exchange ein neues SSL-Zertifikat ausgestellt, dass den FQDN der neuen ECP-Webseite beinhaltet und dieses im IIS an die neue ECP-Webseite gebunden um SSL-Fehler im Browser zu unterdrücken (Zertifikat per GPO ausstreuen)

HINWEIS AM RANDE: Die neue Konfiguration kann bis zu 30 Minuten dauern, bevor der Admin-Zugriff auf die alte ECP-Webseite nicht mehr funktioniert. Also bitte Geduld haben oder Server neu starten!

Quellen für die Lösung:
anexinet: Disable External Access of the Exchange Admin Center

Problem:
Nachdem ich einen externen Benutzer von Exchange 2007 auf Exchange 2013 umgezogen hatte, hat dieser die Öffentlichen Ordner nicht mehr angezeigt bekommen. Der Zugriff erfolgt in der Migrations-Phase über die Discovery-Mailbox-Methode auf den Exchange 2007 (Erklärung siehe TechNet-Quelle unten). Von den intern Outlook-Clients funktioniert der Zugriff problemlos.
Nach einiger Recherche mittels Fiddler habe ich herausgefunden, dass bei dem Client ein zweiter Autodiscover läuft und hier auf die interne Domäen abgefragt wird (https:\\autodiscover.domäne.intern/autodiscover/autodiscover.xml).
Warum der zweite Autodiscover?

Lösung:
Des Rätsels Lösung ist ganz einfach. Dadurch, dass der Client auf die alten Öffentlichen Ordner auf dem Exchange 2007 über das Discovery-Postfach zugreift, läuft für dieses Postfach ebenfalls noch ein Autodiscover. Da ich dem Discovery-Postfach keine öffentliche Mail-Adresse zugewiesen habe (warum auch??), versucht der Client mittels Domäne der primärer Mail-Adresse (die ja intern ist) auf die Autodiscover-URL zuzugreifen (Erklärung wie der Client die Autodiscover-URL ermittelt finden Sie unten in den Quellen).

Die Lösung ist simpel:
Vergeben Sie der Public-Folder-Discovery-Mailbox eine öffentliche Mail-Adresse als Primäre Mail-Adresse und das Autodiscover wird vom externen Client erfolgreich sein.

Quellen/Hilfen:
Hope-This-Helps: Exchange Autodiscover: Wie wird die Autodiscover-URL ermittelt?

https://technet.microsoft.com/de-de/library/dn690134(v=exchg.150).aspx