Wenn man mit einem Webserver zu einem anderen Provider wechselt oder aus sonstigen Gründen neue (öffentliche) IP Adressen zugewiesen bekommt, dann müssen natürlich auch die entsprechenden DNS-Einträge geändert werden. Wenn es sich hierbei nur um eine Hand voll handelt, könnte man dies auch manuell machen. Ab einer gewissen Menge ist das einfach nicht mehr praktikabel, da es a) zu lange dauert und b) auch sehr fehleranfällig wäre.
Als sinnvolle Lösung bietet sich hier die PowerShell an – vorausgesetzt, man hat einen Microsoft Windows Server als DNS-Server und auf diesem das entsprechende DNSServer Modul für die PowerShell verfügbar.
Das Skript, welches am Ende des Beitrages zum Download angeboten wird, sieht so aus:
<#
.Synopsis
This script changes DNS A Records according to a CSV file - use at your own risk!
.DESCRIPTION
This script changes DNS A Records according to a CSV file.
The csv file should look like this:
"OldIP","NewIP"
"1.2.3.4","5.6.7.8"
"2.4.6.8","1.3.5.7"
to change all DNS records with "1.2.3.4" as value for "5.6.7.8" and "2.4.6.8" for "1.3.5.7"
.EXAMPLE
Replace-DNSServerRecords.ps1 -CSVFile H:\OldAndNewIps.txt
Replaces the DNS A records on the localhost DNS server according to the CSV-File H:\OldAndNewIps.txt
.EXAMPLE
Replace-DNSServerRecords.ps1 -CSVFile H:\OldAndNewIps.txt -DNSServer mydns.domain.local -Verbose
Replaces the DNS A records on the DNS server "mydns.domain.local" according to the CSV-File H:\OldAndNewIps.txt and writes verbose output
#>
Param(
[Parameter(Mandatory=$True)]
[ValidateScript({Test-Path $_ -PathType 'Leaf'})]
[string]$CSVFile,
[string]$DNSServer = "localhost"
)
Write-Warning "This script will possibly change a lot of DNS records. If you wish to cancel, press [CTRL]+[C], otherwise press [Enter]!"
Read-Host
# just in case of old PowerShell
Import-Module DNSServer
$CSVData = Import-CSV $CSVFile
$OldDNSRecordData = $CSVData.OldIP
$NewDNSRecordData = $CSVData.NewIP
$AllDNSZones = (Get-DnsServerZone -ComputerName $DNSServer | Where-Object IsReverseLookupZone -eq $False).ZoneName
$TotalChanges = 0
ForEach($CurrentDNSZone in $AllDNSZones)
{
Write-Verbose "Processing current zone $CurrentDNSZone..."
$AllDNSARecordsInZone = Get-DnsServerResourceRecord -ZoneName $CurrentDNSZone -RRType A -ComputerName $DNSServer
Write-Verbose "Found $(($AllDNSARecordsInZone | Measure-Object).Count) DNS Records in current Zone"
ForEach ($CurrentRecord in $AllDNSARecordsInZone) {
for($i=0; $i -lt $OldDNSRecordData.Length; $i++){
If($CurrentRecord.RecordData.IPv4Address -eq $OldDNSRecordData[$i]) {
Write-Verbose "Found an old DNS Record:"
Write-Verbose "$($CurrentRecord.HostName) with $($CurrentRecord.RecordData.IPv4Address) in Zone $CurrentDNSZone"
$NewRecord = $CurrentRecord.Clone()
$NewRecord.RecordData.IPv4Address = $NewDNSRecordData[$i]
Set-DnsServerResourceRecord -OldInputObject $CurrentRecord `
-NewInputObject $NewRecord `
-ZoneName $CurrentDNSZone `
-ComputerName $DNSServer
$TotalChanges++
}
}
}
}
Write-Host "Changed Records: $TotalChanges"
Das Skript durchläuft alle Forward-DNS-Zonen und prüft dabei nacheinander alle vorhandene A-Records gegen die Liste der zu ändernden Einträge. Wenn ein entsprechender Eintrag gefunden wird, wird für diesen die IP-Adresse gegen die neue ausgetauscht. Am Ende gibt das Skript aus, wieviele Einträge insgesamt geändert wurden. Aus Sicherheitsgründen ist nach dem Start noch einmal zu bestätigen, dass das Skript seine Arbeit verrichten soll.
Das fertige Skript kann hier heruntergeladen werden:
Replace-DNSServerRecords.zip
Die Benutzung geschieht auf eigene Gefahr!
Sie wollen lernen, wie dieses Script im Detail funktioniert oder derartige Scripte selber schreiben? Dann besuchen Sie unseren PowerShell-Kurs!
In der aktuell verfügbaren Technical Preview auf den künftigen Windows Server (aktuell unter verschiedenen Namen bekannt, Windows Server 10, Windows Server 2015, Threshold, …) sind bereits einige Neuerungen in Hyper-V erkennbar. Einige davon möchte ich hier kurz ansprechen:
Production Checkpoints vs. Standard Checkpoints
Neben den bisherigen “regulären” Snapshots/Checkpoints (Im Windows Server 2015 als “Standard Checkpoints” bezeichnet) gibt es nun “Production Checkpoints”, die explizit für Maschinen im Produktiv-Betrieb gedacht sind.
Hierbei wird mit Hilfe der Datensicherungstechniken des Gastbetriebssystems (bei Windows via VSS, bei Linux über den Systempuffer) ein Snapshot erzeugt, der auf Konsistenz ausgelegt ist. Sollte ein solcher Snapshot nicht möglich sein, wird auf einen regulären Snapshot ausgewichen (bei dem eben keine Konsistenz aller Daten gegeben ist). Wurde der Production Snapshot erfolgreich erzeugt, wird eine entsprechende Meldung ausgegeben:
Für den Production Snapshot muss die Windows Server-Sicherung im Gast-System NICHT installiert sein:
Laufende Anwendungen werden bei dieser Snapshot-Technik nicht berücksichtigt. Nach einem Revert (Zurücksetzen auf einen Snapshot) muss die VM neu gestartet werden, Anwendungen, die zum Zeitpunkt des Snapshots liefen, gehen dadurch verloren. Allerdings verhält sich das Gast-Betriebssystem so wie nach einem regulären, sauberen Shutdown:
Hyper-V Manager Remote Management
Bereits frühere Versionen des Hyper-V Managers haben es ermöglicht, von einem System aus mehrere Hosts unter einer GUI zu verwalten. Dabei fand das Login auf den Remote-Servern immer mit den Credentials des interaktiv angemeldeten Benutzers statt. Der neue Hyper-V-Manager macht es jetzt möglich, alternative Login-Daten anzugeben:
Damit wird es möglich, Maschinen in fremden Domänen, in Workgroups oder in der DMZ anzusprechen.
Der neue Windows Server, der aktuell noch als “Technical Preview” bezeichnet wird, bringt zumindest optisch nicht viele Neuerungen mit. Wenn man aber einfach mal via Servermanager neue Rollen und Features hinzufügt, fällt einem schnell auf, dass es hier doch viel Neues gibt:
Hier ist der “MultiPoint Server” als neue Rolle zu finden. Bisher war dies ein eigenständiges Produkt, welches separat heruntergeladen und installiert werden musste.
Bei den Features gefällt mir vor allem die Möglichkeit, Windows selbst neu zu starten (“Soft Restart”), ohne die Hardware (incl. POST und allem was dazugehört) neu starten zu müssen. Dies bringt vor allem bei Updates deutlich kürzere Downtimes.
Die Funktionen werde ich demnächst im Detail testen und darüber berichten.
Wie Jim Alkove, Windows Enterprise Program Manager, in einem Blog-Artikel vor wenigen Tagen bekannt gegeben hat, wird es bei künftigen Betriebssystemen eine Änderung bezüglich Updates geben.
Enterprise-Kunden können dann aus einem von drei Pfaden wählen, der bestimmt, wie Updates verteilt werden. Ein Pfad sieht vor, alle Updates so schnell wie möglich zu bekommen und zu verteilen, um immer up-to-date zu sein. Ein weiterer Pfad sieht vor, nur die kritischen und Sicherheits-Updates zu bekommen. Der dritte Pfad wird ein Mittelweg zwischen den beiden Extremen sein.
Dabei soll auch die Möglichkeit bestehen, die eigenen Benutzer aufzuteilen und gruppenabhängig die Zuweisung zu einem dieser Pfade vorzunehmen.
Sicherheitsupdates und andere kritische Updates erscheinen weiterhin monatlich. Vermutlich wie bisher zum “Patch-Tuesday”.
Nun bleibt also abzuwarten, wie sich das alles entwickelt und wie Microsoft diese Ankündigungen umsetzt.
Seit dem 01. Oktober stehen nun neben der Technical Preview von Windows 10 auch die Previews für den kommenden Windows Server sowie für System Center bereit:
In 5 großen Bereichen soll es Änderungen beim Windows Server geben:
Infrastructure Upgrades
Networking
Storage
Remote Desktop
Identity and Access Management
Dies ist einem Blog-Artikel vom “Microsoft Server and Cloud Plattform Team” zu entnehmen.
Ein finaler Name für den neuen Windows Server steht noch nicht fest, aber ich vermute, dass er “Windows Server 2015” heißen wird. Über Details werde ich zeitnah berichten.
Den Download der Preview erhält man über die MSDN oder das Evaluation Center.
Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:
Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.
Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.
Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:
Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:
Was bleibt nun also? Eine Abfrage mittels WMI!
Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:
Will man statt den “internen” (teils kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:
Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName
Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:
Wenn man den Operations Manager 2012 nutzt, dann wird man vermutlich auch schon einmal über eine Meldung gestolpert sein, die darauf hinweist, dass ein logisches Laufwerk zu stark fragmentiert ist ("Fragmentierungsgrad des logischen Datenträgers ist hoch" / "Logical Disk Fragmentation Level is High"). Wenn man viele Server überwacht, dann wird man diese Meldung auch sehr oft sehen - ganz speziell am Montag Morgen (das liegt daran, dass die Standardeinstellung dieses Monitors dafür sorgt, dass der Test immer Samstag 03:00 Uhr läuft).
Nun hat man im Wesentlichen 3 Optionen:
Meldung hinnehmen und von Hand auflösen - bedeutet u.U. sehr viel Aufwand
Meldung ignorieren oder gar mittels Override deaktivieren - löst aber nicht die Ursache auf
Meldung nutzen, um nicht nur die Meldung selbst (=Wirkung), sondern auch den Zustand (=Ursache) selbst aufzulösen
Die Möglichkeit, die Defragmentierung zu automatisieren ist auch im Wissensdatenbank-Artikel des Monitors erwähnt:
Wie das genau geht, hat Cameron Fuller, MVP für SCOM, in seinem Blogartikel beschrieben:
http://tinyurl.com/OMAutodefrag
Ein großartiger Artikel!
Update: Es gibt auch einen etwas einfacheren Weg - man kann das selbe Ziel auch mit einem einfachen Override erreichen, somit ist auch kein weiteres MP nötig... Wie genau das funktioniert, werde ich zeitnah nachreichen.
Seit dem Windows Server 2012 ist ein Software iSCSI Target mit an Board, welches früher separat beschafft und nachinstalliert werden musst. Dieses kann z.B. wunderbar für die Einrichtung eines Failover-Clusters verwendet werden, oder auch für Datensicherung “off-site”. Die Einrichtung des Targets und eines Initiators möchte ich hier beschreiben:
Das iSCSI-Target
Zu erst einmal muss das iSCSI Target auf einem Windows Server installiert werden. Dies geschieht am besten über den Server-Manager und dort über “Verwalten” / “Rollen und Features hinzufügen”. Dort ist dann in der Liste der Features der “iSCSI-Zielserver” auszuwählen:
Ist dies erledigt, können (ebenfalls über den Servermanager) iSCSI-Disks und –Targets eingerichtet werden. Dies geschieht im Bereich “Datei-/Speicherdienste”. Dort kann man einfach “Starten Sie den Assistenten für neue virtuelle iSCSI-Datenträger…” auswählen:
Auf der ersten Seite des Assistenten ist zu wählen, wo die für die iSCSI-Disk verwendete VHDX-Datei abgelegt werden soll. Man kann entweder nur das Laufwerk wählen, dann wird dort ein neuer Ordner “iSCSIVirtualDisk” angelegt, oder man wählt einen eigenen Pfad:
Auf der nächsten Seite ist einfach nur der Name der künftigen Disk festzulegen:
Im dritten Schritt kann man wählen, ob die iSCSI-VHDX eine Datei “Fester Größe”, eine “Dynamisch erweiterbare” oder eine “Differenzierende” ist. Dynamisch erweiterbar spart dabei erstmal Speicherplatz, da die Datei mit den darin abgelegten Daten mit wächst. Dafür ist hier ein kleines Delay “vorprogrammiert”, weil eben immer wieder neu Speicherplatz angefordert werden muss, wenn die Datei wachsen soll. Für Testumgebungen oder wenn der Speicherplatz sehr knapp ist kann man das aber dennoch verwenden:
In den nächsten Beiden Schritten kann nun gewählt werden, ob ein vorhandenes iSCSI-Target verwendet oder ein neues angelegt werden soll:
In meinem Fall habe ich ein neues Target erstellt.
Nun müssen zulässige Server für den Zugriff ausgewählt werden, die so genannten “Initiatoren”. Dies geschieht durch einen Klick auf “Hinzufügen”:
Die Initiatoren werden für gewöhnlich über einen sogenannten IQN identifiziert. Dieser kann ab Windows 8 und Server 2012 direkt vom Server abgefragt werden (obere Option). Hat man bereits einen IQN abgefragt, so steht dieser dann bei der mittleren Option für weitere Targets zur Verfügung. Als dritte Option kann man das Ziel über DNS, IP oder durch händische Eingabe des IQN bestimmen:
Ich werde hier von einem anderen WS2012R2 zugreifen, daher kann ich die obere Variante wählen:
Wenn das iSCSI-Target später für einen Failover-Cluster genutzt werden soll, dann müssen alle künftigen Knoten eingetragen werden:
Optional kann nun noch CHAP, das “Challenging Handshake Protocol” aktiviert werden, um etwas mehr Sicherheit zu bekommen:
Zum Schluss gibt es noch eine Zusammenfassung:
Sind die Targets eingerichtet, so tauchen diese dann künftig im Servermanager auf:
Der iSCSI-Initiator
Für den Server- oder Clientseitigen Zugriff auf das eingerichtete iSCSI-Target wird der iSCSI-Initiator verwendet, welcher standardmäßig bei den moderneren Client- und Serverbetriebssystemen dabei ist:
Beim ersten Start kommt eine Abfrage bezüglich des Dienstes. Diese muss mit “Ja” beantwortet werden. Danach können Ziele eingerichtet werden, in dem die Adresse oder der Hostname des Target-Servers in das oberste Feld eingetragen wird und dann auf “Schnell verbinden” geklickt wird:
Wenn das Zielsystem sauber kontaktiert werden konnte, dann sollte man nun die eingerichteten Targets sehen können:
Entweder man klickt hier direkt auf “Verbinden” oder erst einmal auf “Fertig” (dann kann man später noch Multipath aktivieren).
Nun sollten die Ziele in etwa so aufgelistet sein:
Wenn man nun eines auswählt und auf “Verbinden” klickt, kann die Verbindung (unter Nutzung von Multipfad) hergestellt werden:
Am Ende sollten die Targets so im Initiator auftauchen:
Nun kann über [WIN]+[X] die Datenträgerverwaltung geöffnet werden:
Dort tauchen die Laufwerke nun auf und können partitioniert und formatiert werden. Das wäre es dann auch schon gewesen…
Weitere Informationen zum Thema Windows Server 2012 R2 finden Sie auch unter http://www.ppedv.de/R2
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): 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: Verbindung mit IPAM-Server herstellen IPAM-Server bereitstellen Serverermittlung konfigurieren Serverermittlung starten Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen 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. 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.