Hope This Helps

Problem
Ich habe einen KMS Server aufgesetzt und das Volume Activation Management Tool (VAMT) installiert um die Produkt Keys zu aktivieren. Dabei konnte ich die Server 2019 Keys nicht hinzufügen. Server 2016 und Server 2022 haben problemlos funktioniert. Beim Server 2019 habe ich immer die folgende Fehlermeldung erhalten:

The specified product key is invalid or is unspported by this version of VAMT.
An update to support additional products may be available online.

Ursache
Nach einiger Internetsuche bin ich auf ähnliche Einträge mit anderen Windows Versionen gestoßen. Scheinbar kann das VAMT den Schlüssel nicht korrekt identifizieren. Die Identifikation erfolgt über die pkconfig Files im Ordner
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\VAMT3\pkconfig
auf dem VAMT Server.

Lösung
Nach etwas Recherche hat sich gezeigt, dass diese Dateien auch auf den jeweiligen Server-/Client-Betriebssystemen existieren. Diese findet man unter C:\Windows\System32\spp\tokens\pkeyconfig
Hier geht es um die dort befindliche Datei pkeyconfig-csvlk.xrm-ms
Diese ist auf dem VAMT-Server auch bereits vorhanden. Die Lösung sieht nun wie folgt aus:
- Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server umbenennen
- Datei vom zu aktivierenden OS in das Verzeichnis kopieren (in meinem Fall von einem Server 2019)
- VAMT starten und Produkt Key eintragen
- VAMT schließen und originale Datei pkeyconfig-csvlk.xrm-ms auf dem VAMT-Server wieder umbenennen

Ich habe das Problem nicht bei Mircrosoft identifizieren können. Es gab scheinbar beim Server 2012 R2 schon mal das Problem. Dieser Artikel hat mich zumindest auf die richtige Spur gebracht.

Quelle: Microsoft Learn: VAMT known issues

Auslesen der vorhanden E-Mail Aliase eines Users. SamAccountName muss natürlich duch einen echten ersetzt werden

Get-AdUser -Identity 'SamAccountName' -Properties ProxyAddresses | select Name -ExpandProperty ProxyAddresses

Setzen eines zusätzlichen E-Mail Alias. SamAccountName muss natürlich duch einen echten ersetzt werden

Set-ADUser -Identity 'SamAccountName' -add @{ProxyAddresses="smtp:alias1@domain,smtp:alias2@domain" -split ","}

Problem:
Sobald ein Client der Domäne joined sind die Biometrie-Einstellugnen deaktiviert, außer man arbeitet mit Microsoft-Konto und Hello for Business! Der Benutzer kann keinen Fingerabdruck oder Gesichtserkennung zur Anmeldung aktivieren - Es kommt immer die Meldung: "Da hat etwas nicht geklappt" und der Button "Einrichten" ist ausgegraut.

Lösung:
Um die Biometrie-Anmeldung zu aktiviern muss man folgende vier Gruppenrichtlinien setze UND es darf keine "Hello for Business"-Richtlinei aktiv sein bze. aktiv gesetz werden:

1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Verwendung von Biometrie zulassen > aktivieren
2. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Benutzeranmeldung mithilfe von Biometrie zulassen > aktivieren
3. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Biometrie > Domänenbenutzeranmeldung mithilfe von Biometrie zulassen > aktivieren
4. Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Anmelden > Komfortable PIN-Anmeldung aktivieren > aktivieren

Nach Aktivierung dieser GPOs und einem Reboot konnte der Fingerabdruckssensor verwendet werden.
Quelle der Lösung:
Windows 10 Anmeldung mit Fingerabdruck in Active-Directory Domäne via GPO erlauben

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?

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:
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