Outlook Suche: Onlineergebnisse sind auf 250 Elemente begrenzt! Es werden nicht alle Suchergebnisse angezeigt

Ich hatte folgenden Fehler bei Outlook-User, die eine größere Ordnerstruktur durchsucht haben


Die User bekommen tatsächlich nur 250 Suchergebnisse angezeigt, was jetzt nicht besonders viel ist, wenn man eine ältere Mail sucht!

Ich dachte erste, dass es was mit den MaxObjects zu tun hat und habe daher die MaxObjects für Folder, FolderView, Message und MessageView auf 2000 gesetzt. Heute besteht das Problem weiterhin. Nach etwas Recherche habe ich doch dann tatsächlich einen Eintrag gefunden, der das Problem schildert und löst.
Dieses Einstellung kann erst seit Exchange 2013 CU11 geändert werden und muss aber manuell angepasst werden.

1.) Öffnen Sie die Datei "%ExchangeInstallPath%/Bin/Microsoft.Exchange.Store.Worker.exe.config"
2.) Suchen Sie hier den Schlüssel /runtime
3.) Fügen Sie danach folgende Zeilen hinzu:



Hiermit werden die Sucheregbnisse auf 1.000 Elemente erweitert.
4.) Starten Sie den Informationsspeicher durch

Damit aber noch nicht genug, da wir hiermit die Beschränkung auf dem Server aufgehoben haben, aber NICHT am Client.
Hier gibt es noch eine Einstellung im Outlook, die die Suchergebnisse ebenfalls beschränkt:

Scheinbar gibt es aber in den Microsoft-GPOs keine Einstellungmöglichkeit und somit muss man einen RegKey per GPO ausstreuen. Diese Einstellung gibt es aber erst ab Outlook 2013. Hier die RegKeys dazu:
Office 2013: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Search
Office 2016: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search
REG_DWORD “SearchResultsCap” anlegen
Hier den Wert “0” vergeben (Hier kann auch der gleiche Wert wie auf dem Server eingetragen werden)

Ein scheinbar kleines Problem hat mich gut bechäftigt!

Quelle: somoit: Exchange 2013 – Solved the “Search results limited to 250” bug

Netzwerk: Umstellung der IP-Range in einem ActiveDirectory-Netzwerk

Ich musste die IP-Range eines Standortes komplett ändern, da dieser an unser Netzwerk gekoppelt werden sollte und hier die gleichen IP-Ranges vorlagen. Somit wäre ein Routing zwischen den Standorten nicht möglich gewesen.
Die nachfolgende Liste zeigt meine Gedanken und Vorgehensweisen bzw. Lösungen und ist wahrscheinlich nicht vollständig?!

Vorbereitung für IP-Bereichs-Änderung
- Reverse-Lookup-Zone für neuen Bereich im DNS anlegen
- Replikation der neuen Zone auf DNS-Server prüfen
- DCDIAG erstellt und gespeichert
- DC-Replikation geprüft
- Statische DNS-Einträge dokumentieren
- Eventuelle Skripte oder Dienste auf statische IP-Einträge prüfen (Backups, Netlogon, SMTP etc.)
- Wenn möglich statische IP-Einträge gegen DNS-Einträge tauschen und testen
- Geräte mit festen IPs dokumentieren (z.B. Drucker, Terminals etc.) -> manuelle Anpassung nötig
- DHCP-Optionen dokumentieren
- DHCP-Reservierungen dokumentieren
- Liste mit allen aktiven IP-Adressen und dazugehörigen Geräten erstellen
- Firewall-Regeln dokumentieren
- Routing in der Firewall dokumentieren
- Virenscanner oder anderen Dienste dokumentieren, die IP-Adressen zur Standort-Erkennung verwenden

Umstellung am ersten DC mit FSMO-Rollen
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS sich selbst eintragen
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon

Umstellung der anderen Domain Controller
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen (sich selbst als 2. Server eintragen)
- WINS- und DNS-Dienste starten um Dienstbindung durchzuführen
- ipconfig /flushdns (löscht DNS Cache)
- nbtstat –RR (löschte WINS Cache)
- ipconfig /registerdns (DNS neu registrieren)
- dcdiag /fix (Fixt Probleme im DC und schreibt einige Einträge neu)
- DNS-SRV-Einträge im DNS prüfen ggf. alte löschen (Wichtig sind _GC)
- Restart netlogon
- Replikation der DCs testen über "AD Standort und Dienste"
- dcdiag ausführen und speichern
- Ereignisanzeige prüfen

Umstellung DHCP-Server
- Alten DHCP-Scope löschen
- Neuen DHCP-Scope eintragen und Optionen festlegen
- Vorherige DHCP-Reservierungen wiederherstellen
TIPP: Zum Umzug des DHCP-Servers habe ich eine gute Anleitung geschrieben, in der man auch die IP-Range anpassen kann:
DHCP: Einfacher Umzug DHCP-Dienst auf neuen Server mit Anpassung Scope, allen bestehenden Leases und Reservierungen

Umstellung der Memberserver, Clients und sonstiger Geräte
- Neue IP, Subnet und Gateway eintragen
- WINS und DNS korrekt eintragen
- ipconfig /flushdns (falls möglich)
- nbtstat –RR (falls möglich)
- ipconfig /registerdns (Falls möglich/nötig)
- Prüfen der DNS-Einträge auf den DNS-Servern
- eventuellen Restart der Maschinen, Dienste oder Geräten

Sonstige Anpassungen
- Statische DNS-Einträge auf neue IPs ändern
- Dienste und Geräte ggf. anpassen, die nicht auf DNS-Einträge geändert werden konnten
- Firewall-Regeln anpassen
- Routing in Firewall und Netzwerk anpassen
- Virenscanner und andere Dienste anpassen für Standort-Erkennung

Abschlusstests Active Directory
- DCDIAG prüfen
- Eventlogs prüfen
- Alle wichtigen Dienste prüfen (Mail, Fileshares, Datenbanken etc.)
- externe Zugriffe (z.B. VPN) prüfen
- Backup prüfen
- Wichtige Geräte prüfen auf Erreichbarkeit (USV, Switche etc.)

Hier einige Quellen, die mir bei der Lösung geholfen haben:
Microsoft: Change the static IP address of a domain controller
Yusuf: Die IP – Adresse eines Domänencontrollers ändern
ACE FEKAY: So you want to change your IP range?

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



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)

DHCP: Einfacher Umzug DHCP-Dienst auf neuen Server mit Anpassung Scope, allen bestehenden Leases und Reservierungen

Problem:
Ich wollte meinen DHCP-Dienst von meinem Server 2008 R2 auf den neuen DC unter 2016 migrieren.
Dabei habe ich nach einer Möglichkeit gesucht nicht alles neu einzutippen, vor allem die Reservierungen wären sehr mühsam gewesen. Wenn man hier für den 2008R2 sucht, wird man nicht fündig - weder über GUI, noch über Powershell. Man muss das ganze vom 2016er-Server angehen. Seit Server 2012 gibt es einen Powershell-Befehl für den Export bzw. Import der DHCP-Konfiguration.

Lösung:
Um die DHCP-Konfiguration vollständig zu exportieren, anzupassen und auf dem neuen Server zu importieren, gehen Sie wie folgt vor.
WICHTIG: FÜHREN SIE ALLE BEFEHLE AUF DEM NEUEN SERVER UNTER 2012R2 ODER 2016 DURCH!!

1.) Installieren Sie auf dem neuen DHCP-Server die DHCP-Rolle, damit die Powershell-Befehle vorhanden sind - überspringen Sie die Konfiguration des Dienstes

2.) Erstellen Sie das Export-Verzeichnis "C:\export" für die Konfiguration an

3.) Führen Sie folgenden Powershell-Befehl für den EXPORT aus (Computernamen anpassen!) :
Export-DhcpServer –ComputerName ALTER_DHCP_SERVER.domain.tld -Leases -File C:\export\dhcpexp.xml -verbose

4.) Jetzt können Sie z.B. die DHCP-Scope in der dhcpexp.xml anpassen. Einfach im Text-Editor öffnen und nach Scope suchen um dann die START- und END-Scope anpassen.

5.) Führen Sie folgenden Powershell-Befehl aus um die Konfiguration in den neuen DCHP-Server zu importieren (Computernamen anpassen):
Import-DhcpServer –ComputerName NEUER_DHCP_SERVER.domain.tld -Leases –File C:\export\dhcpexp.xml -BackupPath C:\dhcp\ -Verbose

6.) FERTIG - Eventuell startet der Install-Wizard beim Öffnen nochmal, diesen einfach abschließen!

Somit ist ein Umzug des DHCP-Servers ohne großen Aufwand und Verlust möglich. Zeitgleich kann ich die SCOPE anpassen, ohne die ganze Konfiguration neu einzugeben.

Kleiner TIPP am Rand: Seit Server 2012 gibt es die Funktion "DHCP-Failover", die man im Modus "Loadbalancer" und "Fail-over" betreiben kann. Sehr schönes Feature, wenn man es braucht!

Quelle:
spiffy.sg: Migrate Existing DHCP Server to Windows Server 2012 easily with PowerShell
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz