Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

17Jul/140

WDS und SCCM oder 2x WDS parallel betreiben / Probleme mit PXE lösen

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:

pxe1

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

pxe5

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!

pxe2

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:

pxe3

Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:

pxe4

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!

1Okt/130

Problem bei der Installation des DHCP-Servers unter Windows Server 2012, Fehler 0x800f0922

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:

dhcp-error1

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”).

dhcp-error2

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:

dchp-error3

17Sep/130

Walk-Through: Bereitstellen einer IPAM-Umgebung unter Windows Server 2012

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:

  • Domänen-Controller
  • DHCP-Server
  • DNS-Server
  • NPS-Server

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

ipam1

ipam2

ipam3

ipam4

ipam5

ipam6

Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert:

ipam7

ipam8

ipam9

ipam10

ipam11

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:

ipam_rsat

Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind:

  1. Verbindung mit IPAM-Server herstellen
  2. IPAM-Server bereitstellen
  3. Serverermittlung konfigurieren
  4. Serverermittlung starten
  5. Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen
  6. Daten von verwalteten Servern abrufen

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.

ipam13

Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen:

ipam14

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:

ipam14-2

ipam15

ipam16

ipam17

ipam18

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:

ipam19

ipam20

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

ipam20a

ipam20b

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:

ipam21

Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss:

ipam22

ipam23

Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt.

ipam24

ipam25

ipam26

ipam27

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.

ipam-gpo

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.

ipam-serverzugriff

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”.

invoke-gpupdate

ipam28

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.

ipam29

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:

ipam30

Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen:

ipam31

ipam32

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:

ipam33

 

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:

ipam34ipam35

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.

28Aug/132

Walk-Through: DHCP-Failover mit Windows Server 2012

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:

dhcp1

Das Failover erfolgt immer Bereichs-weise und kann durch einen Rechtsklick auf den gewünschten Bereich eingerichtet werden:

dhcp2

Im ersten Schritt des sich nun öffnenden Assistenten werden nochmal die bzw. der DHCP-Bereich abgefragt, welcher im Failover-Betrieb verwendet werden soll:

dhcp3

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

dhcp4

Im nächsten Schritt sind die weiteren Parameter der Failover-Beziehung festzulegen:

dhcp5

Hierbei können festgelegt werden:

  • Der Name der Beziehung – ist eigentlich klar
  • Die “Maximale Clientvorlaufzeit” (Maximum Client Lead Time)
    • Dieser Wert gibt die vorübergehende Lease-Dauer an, die für Leases gilt, welche im Failover-Fall (“Partner down”) vom Partner-Server vergeben werden; nach dem diese Zeit verstrichen ist, übernimmt der Partnerserver den Bereich vollständig. Standardwert ist eine Stunde, kann aber z.B. auch auf 0 gesetzt werden
  • Modus
    • “Lastenausgleich” oder “Hot Standby” wie bereits oben beschrieben
    • Beim Lastenausgleich-Modus kann die Verteilung der Last auf die beiden Server festgelegt werden; Standard ist 50/50
    • Beim Modus “Hot Standby” ist hier stattdessen festzulegen, welche Rolle der Partnerserver übernimmt (“Aktiv” oder “Standby”) sowie der Anteil der für den Standby-Server reservierten Adressen (Standard: 5%). Dieser Anteil wird während der “Maximalen Clientvorlaufzeit” verwendet, bis der Standby-Server die volle Kontrolle übernommen hat
  • Intervall für Zustands-Switchover
    • Hier kann man festlegen, wie viel Zeit nach einem Wechsel in den Zustand “Communication interrupted” (Verbindung zwischen den beiden Partnern unterbrochen) vergehen soll, ehe zum Zustand “Partner down” übergegangen werden soll; standardmäßig ist dieser automatische Übergange abgeschalten, so dass der Administrator den Zustand “Partner down” händisch einleiten muss
  • Nachrichtenauthentifizierung aktivieren
    • Wenn diese Option eingeschalten ist, werden die Kommunikationen zwischen den beiden Partnern mit Hilfe von SHA-256 verschlüsselt. Zusätzlich wird eine Authentifizierung auf Basis von SHA-2 durchgeführt, um sicherzustellen, das kein unberechtigter Dritter Daten abfängt oder einschleust.
    • Wenn diese Option aktiviert ist, muss in der untersten Eingabezeile ein “Gemeinsamer geheimer Schlüssel” festgelegt werden, welcher vom Assistenten an beide Server gesendet wird und später nirgendwo erneut eingegeben werden muss

Als letzter Schritt folgt eine Zusammenfassung der gesetzten Einstellungen:

dhcp6

Nach einem Klick auf “Fertig stellen” wird die Failover-Beziehung eingerichtet und zum Schluss erscheint eine Erfolgs-Meldung:

dhcp7

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:

dhcp8

Die Eigenschaften der verschiedenen Failover-Beziehungen lassen sich nachträglich in den Eigenschaften des jeweiligen Protokolls (“IPv4” bzw. “IPv6”) einsehen und ändern:

dhcp9

dhcp10

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:

dhcp11

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:

dhcp12

Außerdem wird ein Eintrag im Ereignisprotokoll mit der ID 20252 angelegt:

dhcp13

In den Eigenschaften der Failover-Beziehung kann nun der Zustand von “Datenübertragung unterbrochen” auf “Partner nicht verfügbar” manuell geändert werden:

dhcp14

dhcp15

Ist der ausgefallene Server wieder verfügbar, geht die Verbindung in den Zustand “Wiederherstellen (warten)” über:

dhcp16