Blog von Haiko Hertes zu allen Themen rund um Microsoft, Cloud und Datacenter
Auf Anregung einiger Teilnehmer habe ich heute ein Video erstellt, das zeigt, wie man die OSD-Komponenten des System Center Configuration Manager 2012 R2 nutzt, um Betriebssysteme zu verteilen. Das Operating System Deployment stützt sich dabei auf WDS/PXE und DHCP.
Das Video könnt ihr hier finden:
Die Folien dazu sind hier zu finden:
Viel Spaß dabei!
Schreibe einen Kommentar...Wenn man einen DHCP-Server betreibt, dann sollte dies bevorzugter Weise in einer Domäne geschehen – also mit dem DHCP-Server als Mitglied des Active Directory. Dort benötigt dieser eine Autorisierung, welche dafür sorgt, dass dieser Server dann auf eingehende Anfragen (DHCP Request) reagiert. Solange er nicht autorisiert ist, vergibt er auch keine Adressen. Soweit so gut.
Wenn man einen DHCP-Server NICHT in Active Directory integriert, kann man ihn auch nicht autorisieren, er verrichtet dennoch seine Dienste – bis er auf einen autorisierten Server trifft!
Dann nämlich wird der nicht autorisierte Server (der nicht Mitglied der Domäne ist) seinen Dienst einstellen und selbst wenn man ihn wieder manuell aktiviert sich sofort wieder abschalten.
Damit ist es also nicht so ohne Weiteres möglich, zwei DHCP-Server im selben Netz zu betreiben. Nun kann es aber sein, dass genau das gewünscht ist – weil die Server z.B. Adressen für unterschiedliche MAC-Adressen verteilen. Hier muss man also eingreifen und den nicht-autorisierten DHCP Server daran hindern, sich abzuschalten.
Das “Zauberwort” hier heißt “Rogue Detection” – und genau die muss deaktiviert werden.
Dies geht nicht über eine GUI, sondern muss über eine Registrierungswert geändert werden. Dieser heisst
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
\DisableRogueDetection
Mittels des folgenden Aufrufs lässt sich der Eintrag recht schnell anlegen:
reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DHCPServer\Parameters /v DisableRogueDetection /t REG_DWORD /d 1
Dieser Schlüssel ist sehr oberflächlich in folgendem KB-Artikel bei Microsoft beschrieben:
https://support.microsoft.com/kb/949530
Schreibe einen Kommentar...Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:
Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.
Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).
Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:
Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):
Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!
Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:
Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:
Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.
Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!
Schreibe einen Kommentar...Ein Kollege bat mich, mir ein Problem bei einem DHCP-Server anzusehen. Dieser ließ sich nicht mehr starten und auch ein Entfernen der Rolle brachte insofern keine Abhilfe, da sich die Rolle nicht mehr neu installieren ließ. Es wurde immer der Fehler 0x800f0922 gemeldet:
Der Fehler ließ sich auch nicht durch eine Reparatur des Komponentenspeichers mittels “dism /Online /Cleanup-Image /RestoreHealth” beheben.
Eine genauere Analyse zeigte schließlich, dass der Ordner “C:\Windows\System32\DHCP” einen Teil seiner NTFS-ACLs verloren hatte (Vollzugriff bestand nur für eine unbekannte SID statt für “DHCPServer”).
Nachdem dies korrigiert war, konnte der Ordner gelöscht werden und schlussendlich ließ sich dann auch die DHCP-Rolle wieder sauber installieren!
So sollten dann die ACLs für den DHCP-Folder aussehen:
Mit dem Windows Server 2012 hält auch ein neues Werkzeug Einzug in den Administrations-Alltag: Der IP-Adress-Verwaltungsserver, kurz IPAM. Dieses Werkzeug ist in der Lage, die gewachsenen IP-Address-Strukturen zu verwalten, zu analysieren und auch abzufragen. Dabei greift er auf folgende Quellen zu:
Damit bietet er die Möglichkeit, die IP-Address-Verwaltung per Excel-Tabelle durch ein modernes, leistungsfähiges Werkzeug zu ersetzen.
Leider ist die Installation bzw. Einrichtung nicht ganz trivial, daher möchte ich diese hier Schritt für Schritt erläutern.
Bereits vorbereitet für dieses “Walk-through” ist eine kleine Demo-Umgebung bestehend aus einem Domänencontroller samt DNS (DC.hertes.lab), ein DHCP-Server samt Scope (DHCP.hertes.lab) sowie ein Member-Server für die künftig Aufgabe als IPAM (IPAM.hertes.lab).
WICHTIG: IPAM darf nicht auf einem Domänencontroller installiert werden. Das TechNet liefert hierfür zwar keine Erklärung, ich vermute aber, dass dies an der nötigen Datenbank (hier: Windows Internal Database, WID) liegt. Ab Server 2012 R2 ist auch ein “richtiger” SQL-Server möglich.
Als erstes muss der IPAM als Feature auf dem entsprechenden Server installiert werden. Dies geschieht über den Servermanager (alternativ per PowerShell):
Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert:
Ein Neustart nach der Installation ist im Allgemeinen nicht erforderlich. Selbst wenn man den Haken für den automatischen Reboot gesetzt hat, wird nur neugestartet, wenn dies nötig ist.
Nach der Installation erfolgt die Einrichtung des IPAMs durch den entsprechenden Bereich im Servermanager (ein eigenständiges Werkzeug oder MMC-SnapIn existiert nicht). Die Administration inkl. Einrichtung kann auch remote erfolgen. Dazu ist über die Remoteserververwaltungstools (Feature) der IP-Adressverwaltungsclient zu installieren:
Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind:
Nach dem Schritt 3 ist ein weiterer Schritt nötig, der hier nicht aufgeführt wird und nur per PowerShell erledigt werden kann. Darauf gehe ich später gesondert ein.
Die GUI zeigt die 6 Schritte. Der erste Schritt wird automatisch ausgeführt, wenn die IPAM-Konsole auf dem IPAM-Server selber gestartet wird.
Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen:
Als nächstes wird der IPAM-Server bereitgestellt. Dies kann manuell (nicht zu empfehlen) oder per GPO (sehr komfortabel) erfolgen. Bei der GPO-Variante ist nur ein Präfix anzugeben, der den künftigen drei GPOs namentlich vorangestellt wird:
Nach diesem Schritt existieren die GPOs nur auf dem IPAM-Server, noch nicht auf dem Domänencontroller. Dazu kommen wir gleich…
In Schritt 3 werden die zu verwaltenden Domänen und Server ausgewählt:
Hier findet sich auch – etwas unglücklich platziert – der Hinweis auf den (zwingend nötigen) “siebten Schritt”: Das Schreiben der GPOs auf den DC mittels PowerShell-Cmdlet “Invoke-IpamGpoProvisioning”:
Schickt man den Befehl ohne Parameter ab, werden diese danach automatisch abgefragt.
Wichtig: Das Ausführen dieses Cmdlets muss (interaktiv) auf dem IPAM-Server erfolgen. Es funktioniert weder per Enter-PSSession noch per Invoke-Command!
Im Schritt 4 werden nun die Server der ausgewählten Umgebung ermittelt:
Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss:
Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt.
Dies muss für jeden Server separat erfolgen. Ist dies abgeschlossen, stehen die Server auf “Blockiert”. Die Blockierung wird aufgehoben, sobald die erzeugten und nun auch per Sicherheitsfilterung für die jeweiligen Server geltenden GPOs wirken. Am einfachsten kann man dies durch ein GPUpdate forcieren.
Sobald die GPOs wirken, kann man durch einen Rechtsklick den “Status des Serverzugriffs aktualisieren”. Dies muss wieder für alle Server einzeln und nacheinander erfolgen.
Wenn diese Aufgabe erledigt ist, kann man die Ansicht aktualisieren (Kringel / Kreisel oben rechts). Nun sollten alle Server “grün” sein:
Falls nicht, hilft etwas warten bzw. müssen die jeweiligen Server evtl. noch einmal mit GPUpdate aktualisiert werden. Alternativ hilft “Invoke-GPUpdate SRVNAME –RandomDelayInMinutes 0 –Force”.
Nun darf man den Schritt 6 nicht vergessen! Dieser ruft schließlich (einmalig manuell, später automatisch) die jeweiligen Daten von den verwalteten Servern ab.
Auch hier muss man wieder auf Fertigstellung der IP-Adressverwaltungsaufgabe warten.
Ist der Schritt 6 fertiggestellt, kann man sich nun den verschiedenen Möglichkeiten im Baum auf der linken Seite widmen.
Unter IP-ADRESSRAUM / IP-Adressblöcke kann man z.B. den/die DHCP-Scope(s) sehen:
Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen:
Hier kann man beispielsweise einen Eintrag in DNS oder auch eine DHCP-Reservierung vornehmen. Allerdings werden diese Daten vorerst nur am IPAM-Server gespeichert. Möchte man die Informationen auch auf die jeweiligen Server übertragen, so ist dies unter “IP-Adressbestand” möglich:
In der Rubrik “Überwachen und Verwalten” kann man u.a. den Zustand der involvierten Server und DHCP-Scopes sehen.
Im Ereigniskatalog werden einerseits Konfigurationsereignisse angezeigt, andererseits kann man gezielt nach IP-Adressen, MAC-Adressen, Hostnamen und Benutzernamen suchen, um damit verbundene Vorgänge (DHCP-Lese-Generation, –Renewal, DC-Authentifizierung, …) zu finden:
Da der IPAM seine Daten in einer Datenbank ablegt, kann man hier auch Daten der Vergangenheit abrufen. Die Daten werden 3 Jahre lang in der Datenbank vorgehalten.
Schreibe einen Kommentar...Der Windows Server 2012 bringt eine Funktion mit sich, auf die man bisher nur über die Umwege eines Clusters und den damit verbundenen höheren Anforderungen (Server 2008 Enterprise-Edition, shared Storage, …) nutzen konnte. Die Rede ist von DHCP-Failover, welches im Windows Server unabhängig von der verwendeten Edition und vollkommen ohne Cluster genutzt werden kann. Notwendig sind lediglich zwei Windows Server 2012 mit aktivierter DHCP-Server-Rolle. Auf einem der beiden Server sollte bereits ein Bereich (“Scope”) eingerichtet sein, beide Server müssen im AD autorisiert sein.
Im Folgenden möchte ich die Einrichtung des Failovers im Modus “Load-Sharing” erläutern und Schritt für Schritt mit Bildern darstellen. Neben diesem Modus, welcher sich insbesondere dann eignet, wenn die beiden Server in der selben physischen Lokation stehen, steht als zweite Option die Variante “Hot Standby” zur Verfügung. Dieser Modus eignet sich z.B. dann, wenn im Fehlerfall ein DHCP-Server von einem anderen Standort den Standort des ausgefallenen DHCP-Servers versorgen soll.
Eine potentielle Fehlerquelle beim Einrichten der Failover-Beziehung ist die Zeit. Diese muss auf beiden Partnern synchron sein. Eine Abweichung von mehr als 60 Sekunden sorgt beim Einrichten für einen kritischen Fehler. Diese Tolleranz darf auch im täglichen Betrieb nicht überschritten werden.
Nun zur eigentlichen Anleitung:
Bereits vorbereitet sind hier zwei installierte DHCP-Server “SRV1” und “SRV2”, welche beide bereits im AD autorisiert sind. Auf dem ersten Server “SRV1” wurde bereits ein Bereich für das Subnetz 192.168.200.0/24 angelegt:
Das Failover erfolgt immer Bereichs-weise und kann durch einen Rechtsklick auf den gewünschten Bereich eingerichtet werden:
Im ersten Schritt des sich nun öffnenden Assistenten werden nochmal die bzw. der DHCP-Bereich abgefragt, welcher im Failover-Betrieb verwendet werden soll:
Im zweiten Schritte muss der Partnerserver bestimmt werden. Dabei fällt auf, dass pro Bereich nur ein Partner-Server zulässig ist. Wenn es bereits früher eine Failover-Beziehung zwischen den beiden gewählten Servern gab, so könnte man diese wieder “reaktivieren”:
Im nächsten Schritt sind die weiteren Parameter der Failover-Beziehung festzulegen:
Hierbei können festgelegt werden:
Als letzter Schritt folgt eine Zusammenfassung der gesetzten Einstellungen:
Nach einem Klick auf “Fertig stellen” wird die Failover-Beziehung eingerichtet und zum Schluss erscheint eine Erfolgs-Meldung:
Wenn man nun die GUI des DHCP-Tools aktualisiert, kann man beim SRV2 ebenso den bereits auf dem SRV1 eingerichteten Bereich sehen, in dem auch alle bereits vergebenen Leases und Reservierungen vorhanden sind:
Die Eigenschaften der verschiedenen Failover-Beziehungen lassen sich nachträglich in den Eigenschaften des jeweiligen Protokolls (“IPv4” bzw. “IPv6”) einsehen und ändern:
Für die Failover-Konfiguration ist im DHCP-Standard ein Austausch der Leases vorgesehen – nicht aber eine stetige Synchronisierung der Konfigurationen. Da aber beide Server einer Failover-Beziehung identisch konfiguriert sein sollten, ist nach einer Konfigurationsänderung ein Abgleich nötig:
Dabei kann entweder nur der gewählte Bereich abgeglichen werden (“Bereich replizieren…”) oder aber alle Bereiche, die in dieser Failover-Beziehung existieren (“Beziehung replizieren…”)
Wenn nun einer der beiden Kommunikationspartner ausgefallen ist, so wird dies durch Symbolik im DHCP-Manager angezeigt und ist auch in den Eigenschaften des Protokolles zu sehen:
Außerdem wird ein Eintrag im Ereignisprotokoll mit der ID 20252 angelegt:
In den Eigenschaften der Failover-Beziehung kann nun der Zustand von “Datenübertragung unterbrochen” auf “Partner nicht verfügbar” manuell geändert werden:
Ist der ausgefallene Server wieder verfügbar, geht die Verbindung in den Zustand “Wiederherstellen (warten)” über:
