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

10Feb/150

Windows Server Technical Preview / vNext: “Soft Restart” funktioniert (noch) nicht

Die aktuelle Build 9841 des kommenden Windows Server (aktuell als “vNext” bezeichnet, vermutlich später “Windows Server 2016”, da erst Mitte 2016 erscheinen wird) bringt neben einigen anderen neuen Funktionen auch ein Feature “Soft Restart” mit:

soft01

Unabhängig davon, ob es installiert ist oder nicht, stehen sowohl in der CMD via shutdown.exe als auch in der PowerShell passende Optionen zur Verfügung:

soft02

soft03

Von den Funktionen erwarte ich mir, dass sie den Server neustarten, ohne die gesamte Hardware neu starten zu müssen (verbunden mit den ganzen POST-Checks und co., RAID-Controller und alles was beim Booten eben so auf einem Server Zeit kostet). Dadurch sollte der Reboot auch deutlich schneller sein, was auch Downtimes nach Updates deutlich verkürzen würde.

Leider haben beide Schalter (“shutdown.exe /soft” und “Restart-Computer –Soft”) in der aktuellsten freien Build (9841) noch keine Auswirkung und zeigen auch keinerlei Verkürzung der Boot-Zeit.

Auch nach der Installation des Features und dem dadurch notwendigen Reboot ändert sich nichts. Schade. Also abwarten…

19Jan/150

Stand-alone DHCP-Server plus DHCP-Server in Domäne gleich Problem?!

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.

dhcp_rogue_2

dhcp_rogue_1

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

dhcp_rogue_3

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

18Jan/150

Microsoft DNS-Server: Einträge massenweise “umziehen”

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
<#
.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!

13Okt/140

Einige Neuerungen im Windows Server 2015 (Technical Preview) bezüglich Hyper-V

In der aktuell verfügbaren Technical Preview vom 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.

Checkpoints1

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:

Checkpoints2

Für den Production Snapshot muss die Windows Server Sicherung im Gast-System NICHT installiert sein:

Checkpoints3

Laufende Anwendungen werden bei dieser Snapshot-Technik nicht berücksichtigt. Nach einem Revert (Zurücksetzen au 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:

Checkpoints4

Hyper-V Manager Remote Management

Bereits frühere Versionen vom Hyper-V Manager 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:

HyperV1

Damit wird es möglich, Maschinen in fremden Domänen, in Workgroups oder in der DMZ anzusprechen.

12Okt/140

Erste offensichtliche Änderungen am neuen Windows Server (Technical Preview)

Der neue Windows Server (aktuell noch als “Technical Preview” bezeichnet) bringt auf den ersten Blick nicht so viele Neuerungen (zumindest optisch). 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:

Rollen

Hier ist der “MultiPoint Server” als neue Rolle zu finden. Bisher war dies ein eigenständiges Produkt, welches separat heruntergeladen und installiert werden musste.

Features1

Features2

Features3

Bei den Features gefällt mir vor allem die Möglichkeit, Windows selber 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.

9Okt/140

Änderung bei Microsoft’s Update-Strategie

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.

Was Bestand haben wird ist, das Sicherheitsupdates und andere kritische Updates monatlich veröffentlicht werden. Vermutlich wie bekannt zum “Patch-Tuesday”.

Nun bleibt also abzuwarten, wie sich das alles entwickelt und wie Microsoft diese Ankündigungen umsetzt.

4Okt/140

Windows Server und System Center Technical Previews stehen bereit

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:

technicalpreviews

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.

5Aug/140

PowerShell: Anmelde-Konto der Windows-Dienste überprüfen

Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:

pwservices1

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:

pwservices2

Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:

pwservices3

Was bleibt nun also? Eine Abfrage mittels WMI!

pwservices4

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:

pwservices5

Will man statt den “internen” (teil 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

pwservices45

Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

pwservices7

15Mai/140

SCOM 2012 R2 – Auto-Defragmentierung

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 Monitor dafür sorgt, dass der Test immer Samstag 03:00 Uhr läuft).

Defrag1

Nun hat man im Wesentlichen 3 Optionen:

  1. Meldung hinnehmen und von Hand auflösen - bedeutet u.U. sehr viel Aufwand
  2. Meldung ignorieren oder gar mittels Override deaktivieren - löst aber nicht die Ursache auf
  3. 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 Wissensdantenbank-Artikel des Monitors erwähnt:

Defrag2

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.

2Mrz/140

Windows Server 2012 R2: iSCSI Target und Initiator einrichten

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:

iscsi0

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:

iscsi1

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:

iscsi2

Auf der nächsten Seite ist einfach nur der Name der künftigen Disk festzulegen:

iscsi3

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:

iscsi4

In den nächsten Beiden Schritten kann nun gewählt werden, ob ein vorhandenes iSCSI-Target verwendet oder ein neues angelegt werden soll:

iscsi5 iscsi6

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

iscsi7

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:

iscsi8

Ich werde hier von einem anderen WS2012R2 zugreifen, daher kann ich die obere Variante wählen:

iscsi9

iscsi11

Wenn das iSCSI-Target später für einen Failover-Cluster genutzt werden soll, dann müssen alle künftigen Knoten eingetragen werden:

iscsi12

Optional kann nun noch CHAP, das “Challenging Handshake Protocol” aktiviert werden, um etwas mehr Sicherheit zu bekommen:

iscsi13

Zum Schluss gibt es noch eine Zusammenfassung:

iscsi14

Sind die Targets eingerichtet, so tauchen diese dann künftig im Servermanager auf:

iscsi15

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:

iscsi1_0

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:

iscsi2

Wenn das Zielsystem sauber kontaktiert werden konnte, dann sollte man nun die eingerichteten Targets sehen können:

iscsi3

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:

iscsi4

Wenn man nun eines auswählt und auf “Verbinden” klickt, kann die Verbindung (unter Nutzung von Multipfad) hergestellt werden:

iscsi5

Am Ende sollten die Targets so im Initiator auftauchen:

iscsi6

Nun kann über [WIN]+[X] die Datenträgerverwaltung geöffnet werden:

iscsi7

Dort tauchen die Laufwerke nun auf und können partitioniert und formatiert werden. Das wäre es dann auch schon gewesen…

iscsi8

iscsi9