Wer kennt es nicht? Die bestellten PC’s von letzter Woche sind endlich in der IT angekommen. Nun wir
[Mehr]
Am 15. Juli 2015 endet der Support für Windows Server 2003. Dies Betrifft alle Editionen von Windows Server 2003 und Windows Server 2003R2. Viele Unternehmen haben allerdings noch Domänencontroller (DCs) unter Windows Server 2003 laufen. Hier erfahren Sie, wie Sie Active Directory (AD) von 2003 auf 2012R2 migrieren. Vor Windows Server 2012 war es notwendig, wenn man einen DC mit einer neueren Betriebssystemversion hinzufügen wollte, das AD darauf vorzubereitet. Hierfür stellt Microsoft das Kommandozeilen-Tool adprep.exe zur Verfügung, dass sich auf jeder Installations-DVD von Windows Server befindet (man musste dann immer das adprep von der neuen Windows Server-Version verwenden). Das ist jetzt ab Windows Server 2012 nicht mehr notwendig – das erledigt jetzt der neue Konfigurations-Assistent, der einen Server zu einem DC herauf stuft, automatisch. Unter Windows Server 2012R2 kann zwar keine Domäne oder Gesamtstruktur mit einer Funktionsebene 2003 mehr eingerichtet werden (nur noch ab Funktionsebene 2008), man kann ihn jedoch als zusätzlichen Domänencontroller einer 2003-Domäne hinzufügen. Dies müssen wir auch als ersten Schritt erledigen: Im Server-Manager des Windows Server 2012R2-Servers die Serverrolle “Active Directory-Domänendienste” hinzufügen (“Verwalten” –> “Rollen und Features hinzufügen”). Wenn die Rolle erfolgreich installiert wurde, muss der “Konfigurations-Assistent für Active Directoy-Domänendienste” gestartet werden, in dem man auf den Link “Server zu einem Domänencontroller heraufstufen” klickt (dieser Assistent löst quasi DCPROMO, das bei früheren Windows Server Versionen noch explizit aufgerufen werden musste, ab). Hier wählt man den Bereitstellungsvorgang “Domänencontroller zu einer vorhandenen Domäne hinzufügen” aus, trägt die Domäne ein und hinterlegt noch entsprechende Anmeldeinformationen eines Domänen-Admins. Als nächstes müssen die Domänencontrollerfunktionen “DNS-Server” (nur wenn der DNS-Server bisher auch auf einem DC lief) und “Globaler Katalog” ausgewählt werden. Dann noch ein DSRM-Kennwort angeben. Die nächsten Punkte “DNS-Optionen”, “IFM-Optionen”und “Pfade” können in der Regel mit “Weiter” übersprungen oder (falls notwendig) angepasst werden. Es folgt ein Hinweis, dass die Gesamtstruktur, das Schema und die Domäne während dem Hochstufen zum DC vorbereitet werden müssen – dieser Automatismus löst die manuelle Vorbereitung via ADPREP ab. Nachdem Sie die Optionen geprüft haben, wird eine Voraussetzungsüberprüfung vorgenommen. Erscheint links oben ein grüner Haken, dann kann mit der Installation begonnen werden. Nach dem automatischen Neustart läuft der 2012R2-Server als weiterer DC in der Domäne. Damit jedoch der 2003-Server in “Rente” geschickt werden kann, müssen die FSMO-Rollen (Betriebsmasterrollen) auf den 2012R2-Server verschoben werden. Es gibt insgesamt 5 FSMO-Rollen: PDC-Emulator, RID-Master, Infrastruktur-Master, Domänennamen-Master und Schema-Master. Der Verschiebung der Rollen muss immer an dem DC angestoßen werden, der die Rollen erhalten soll. Auf dem 2012R2-Server muss das Verwaltungs-Snap-In “Active Directory-Benutzer und –Computer” gestartet werden. In diesem Snap-In lassen sich 3 von den 5 Rollen verschieben. Hierzu macht man einen Rechtsklick auf den Domänennamen und geht im Kontextmenü auf “Betriebsmaster…”. Hier stehen die 3 Betriebsmasterrollen “RID-Master”, “PDC-Emulator” und “Infrastruktur-Master” – erreichbar über Registrierkarten – zur Verfügung. Im ersten Eingabefeld wird angezeigt auf welchem DC die Rolle aktuell beheimatet ist. Im zweiten Eingabefeld erhält man die Information mit welchem DC man gerade verbunden ist – hier sollte der Name des 2012R2-Servers aufgeführt sein. Falls das nicht der Fall ist: Im Snap-In Rechtsklick auf “Active Directory-Benutzer und –Computer” (oberster Eintrag in der Ordnerstruktur) –> “Domänencontroller ändern” und dort den 2012R2-Server auswählen. Um die FSMO-Rolle zu verschieben, genügt ein Klick von den Button “Ändern…”. Danach steht im ersten Eingabefeld auch der neue Server drin. Diese Aktion führt man bei allen 3 Rollen durch. Die Betriebsmasterrolle “Domänennamen-Master” kann man im Snap-In “Active Directory-Domänen und -Vertrauensstellungen” verschieben. Statt einen Rechtsklick auf den Domänennamen muss man hier allerdings einen Rechtsklick auf den Namen des Snap-Ins (oberster Eintrag in der Ordnerstruktur) vornehmen, um zum Betriebsmaster zu gelangen. Die letzte Betriebsmasterrolle muss über das Snap-In “Active Directory-Schema” verschoben werden. Problem: Dieses Snap-In ist (aus Sicherheitsgründen) standardmäßig nicht installiert. Über die Eingabeaufforderung (cmd) geben wir “regsvr32 schmmgmt.dll” ein. Danach bekommen wir die erfolgreiche Durchführung bestätigt. Über die mmc haben wir nun Zugriff auf das Snap-In (in der mmc “Datei” –> “Snap-In hinzufügen” –> “Active Directory-Schema” hinzufügen). Da man standardmäßig in diesem Snap-In mit dem Schema-Master verbunden wird, müssen wir über einen Rechtsklick auf “Active Directory-Schema” über “Active Directory-Domänencontroller ändern…” den 2012R2-Server als aktuellen DC auswählen. Danach mit einem weiteren Rechtsklick auf den Snap-In-Namen über “Betriebsmaster…” die letzte Rolle verschieben. Damit wurden alle 5 FSMO-Rollen auf den neuen 2012R2-Server verschoben. Dies kann man sich auch schnell in der Eingabeaufforderung mit “netdom query fsmo” bestätigen lassen. Jetzt können wir den 2003-Server als DC in Rente schicke. Als erstes trägt man in der IP-Konfiguration auf dem 2003-Server als bevorzugten DNS-Server den neuen 2012R2-Server ein und startet danach über “Start” –> “Ausführen” DCPROMO. Nach dem ersten “Weiter” wird man gefragt, ob dieser Server der letzte DC in der Domäne ist. Die Checkbox darf hier NICHT aktiviert werden! Als nächstes vergibt man noch ein Kennwort für das neue lokale Administrator-Konto, dass während dem Herabstufen angelegt wird. Nach einem Neustart ist der Server zwar noch Mitglied in der Domäne, jedoch kein Domänencontroller mehr. Falls es noch weitere ältere DCs gibt, diese ebenfalls wie beschrieben als DC herabstufen. Abschließend muss noch die Domänen- wie auch Gesamtstrukturfunktionsebenen heraufgestuft werden, damit auch alle neuen AD-Funktionen, die nach Windows Server 2003 implementiert wurden, auch zur Verfügung stehen. Dies kann man komfortabel auf dem 2012R2-Server über das neue Verwaltungstool “Active Directoy-Verwaltungscenter” erledigen. Nach dem Start des Tools (im Server-Manager unter “Tools”) einfach in der linken Spalte auf den Domänennamen klicken, dann in der rechten Spalte (“Aufgaben”) auf “Gesamtstrukturfunktionsebene heraufstufen…”. Dort als Funktionsebene “Windows Server 2012R2” auswählen. Damit stehen alle neuen Funktionen zur Verfügung. Es lässt sich dann aber auch kein DC mit einer niedrigeren Betriebssystemversion mehr hinzufügen. Die Domänenfunktionsebene wird automatisch mit hochgesetzt – dies muss nicht manuell gemacht werden. Damit ist die Migration abgeschlossen.
Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.
Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!
Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!
Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).
Installation SCUP
Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:
https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx
bzw.
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940
Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:
Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:
Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!
Konfiguration WSUS-Berechtigungen
Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):
https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012
Folgende Schritte sind im Wesentlichen nötig:
Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):
Einrichtung SCUP
Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.
Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:
Als erstes sind die Optionen zu öffnen:
Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):
Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:
Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:
Zertifikat passend einbinden
Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:
Updates über SCUP an den WSUS veröffentlichen
Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:
Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:
Danach können die Updates aus diesem Katalog in den SCUP importiert werden:
Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:
Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.
Dabei sollten die Updates vom SCUP signiert werden:
Updates über SCCM verteilen
Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:
Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:
Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:
Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.
Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.
Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:
Viel Spaß damit!
Sie benötigen weitere Informationen zum SCCM und den Möglichkeiten, Updates zu verteilen? Dann schauen Sie sich unseren Kurs zum System Center Configuration Manager 2012 R2 an!
Wie mein Kollege Eik bereits vor geraumer Zeit festgestellt hat, gibt es ein Problem bei einer konkreten Konstellation in Bezug auf WDS: In den Windows Bereitstellungsdiensten gibt es die Möglichkeit, ein “Aufzeichnungsabbild” aus einem regulären “Startabbild” zu erzeugen. So natürlich auch beim aktuellen Windows Server 2012 R2: Häufig kommt es dann aber bei dieser Server-Version später beim Booten der aufzuzeichnenden Maschine zu einem Fehler: Dieser Fehler tritt dann auf, wenn man: auf einem Windows Server 2012 R2 (mit oder ohne Update1) im WDS ein Startabbild (Boot Image) auf Basis eines Windows Server 2012 R2 MIT Update1 oder Windows 8.1 MIT Update1 hinzufügt (dabei ist es dann später egal, auf welchem Startabbild das Aufzeichnungsabbild basiert) auf einem Windows Server 2012 (“R1”) im WDS ein Startabbild auf Basis eines Windows Server 2012 R2 mit Update1 oder Windows 8.1 mit Update1 erzeugt Der Fehler würde NICHT auftreten, wenn man vor dem Erzeugen des Aufzeichnungsabbildes noch nie ein Startabbild von Windows 8.1 Update1 oder Windows Server 2012 R2 Update1 importiert hatte. Natürlich kann man den Fehler aber auch anderweitig umgehen bzw. beheben: Dazu hinterlegt man zunächst das gewünschte Startabbild (dabei spielt es keine Rolle, ob bisher ein Update-1-Startabbild hinterlegt wurde oder nicht, das zu hinterlegende Abbild selbst darf auch von einer Update-1-Version stammen): Danach erzeugt man aus diesem ein Aufzeichnungsabbild: Dabei sollte man dass entstehende Abbild nicht direkt dem WDS Server hinzugefügt wird: Anschließend muss das entstandene WIM-File (in meinem Beispiel “C:\aufz.wim”) mittels DISM gemountet werden: Für das Mounten verwendet man einen Aufruf in dieser Form: dism /Mount-Wim /WimFile:C:\aufz.wim /index:1 /MountDir:C:\mount (Achtung: Keine Leerzeichen nach den Doppelpunkten!) Im Anschluss kann die Datei direkt wieder “unmounted” werden (ohne dass sie dabei inhaltlich wirklich verändert wurde): Hierzu wird folgender Aufruf verwendet: dism /Unmount-Wim /MountDir:C:\mount /commit Das nun neu erzeugte WIM-File kann jetzt als funktionsfähiges Aufzeichnunge-/Startabbild auf dem WDS-Server hinterlegt werden: Nun kann eine (Test-)Maschine per PXE gebootet werden, es sollte nun, da es mehrere Startabbilder gibt, eine Auswahl möglich sein: Wenn man das Aufzeichnungsabbild gewählt und die Maschine komplett gebootet hat sollte in etwa folgendes Menü zu sehen sein: Nun kann die Festplatte der (Test-)Maschine aufgezeichnet werden. Wichtig ist dabei allerdings, dass dies nur funktioniert, wenn man das dort laufende Betriebssystem vorher mit sysprep vorbereitet hat. Wie man mit dem WDS-Server den Alltag erleichtert und die Installation von Client- und Server-Betriebssystemen automatisieren kann erfahren Sie in unseren Kursen “Windows Server 2012 R2 Administration” und “Windows Server 2012 R2 Powerwoche”.
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
Mit der Zeit sammeln sich auf einem WSUS (Windows Server Update Service) einige Updates an. Da können auch schnell mehrere hundert Gigabyte an Daten zusammenkommen. Nicht jedes Update, welches auf dem WSUS gespeichert ist, wird aber noch benötigt. Daher ist es aus Gründen der Speicherplatzeffizienz sinnvoll, von Zeit zu Zeit etwas aufzuräumen. Dafür gibt es schon seit längerem einen passenden Assistenten in der WSUS-Konsole:
Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.
Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:
Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]
[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]
[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]
Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.
Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.
Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx
Sie haben Interesse, mehr über den WSUS Server zu erfahren? Dann besuchen Sie unsere Windows Server 2012 R2 Kurse! Oder vielleicht möchten Sie mehr über PowerShell lernen?
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:
Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln:
Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage:
Auch mit Hilfe der Windows PowerShell kann man dies sehen…
… und ändern!
Mit Hilfe des Aufrufs
Set-NetConnectionProfile –InterfaceInxe # –NetworkCategory Private
wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen:
Mit der Markteinführung von Windows Server 2012 und Windows 8 veröffentlichte Microsoft auch eine neue Version ihres Web-Servers. Sowohl beim Server - als auch beim Client-Betriebssystem ist der IIS 8.0 mit an Bord. Schaut man nur flüchtig auf die Oberfläche des IIS 8.0, wird man so gut wie keine Neuerungen finden – die meisten findet man nur als Konfigurationsparameter in den bereits bekannten Features. An der Bedienoberfläche selbst hat sich praktisch nichts verändert (nur, dass man jetzt die verschiedenen Kategorien auf den Konfigurationsseiten auf- und zuklappen kann). Damit gibt es auch bzgl. der Bedienung keine Probleme beim Umstieg von Version 7.5. Hier nun aber die Neuerungen des IIS 8.0, die hauptsächlich die Sicherheit und Performance des Web-Servers optimieren oder den administrativen Aufwand reduzieren sollen:
Zentralisierte Zertifikate Für Serverfarmen lässt sich nun ein zentraler Speicherort für SSL-Zertifikate einrichten. Hierdurch müssen SSL-Zertifikate nicht mehr in jedem einzelnen Web-Server hinterlegt werden, sondern alle Server greifen einfach auf den zentralen SSL-Zertifikatsspeicher zu.
Dynamische IP-Einschränkungen Der IIS kann nun so konfiguriert werden, dass der Zugriff für IP-Adressen kurzzeitig automatisch blockiert wird, durch die eine bestimmte Anzahl von Anforderungen innerhalb eines bestimmten Zeitraums oder von gleichzeitigen Anforderungen überschritten wird. Außerdem können Sie festlegen, welches Verhalten eintritt, wenn eine IP-Adresse blockiert ist.
Virtuelle Domänennamen bei SSL Mit der SNI-Unterstützung (Server Name Indication), die nun in den IIS integriert wurde, können virtuelle Hostnamen in Kombination von SSL-Verbindungen verwendet werden - wenn sich mehrere Websites dieselbe IP-Adresse teilen sollen. Bei SNI handelt es sich um eine Erweiterung bzw. Optimierung des SSL- und TSL-Protokolls. Nicht nur der Web-Server muss SNI unterstützen, sondern auch der Browser des Webseiten-Besuchers! Dies ist jedoch bei allen aktuellen Versionen gängiger Browser der Fall.
FTP-Anmeldeversuchsbeschränkungen Dieses neue Feature schränkt die Anzahl der fehlgeschlagenen Anmeldeversuche ein, die innerhalb eines bestimmten Zeitraums an ein FTP-Konto gerichtet werden.
Zusätzliche CPU-Beschränkung in Anwendungspools Wenn ein Anwendungspool über ein bestimmtes Zeitfenster ein Limit angeforderter CPU-Leistung erreicht hat, konnte bisher der betroffene Arbeitsprozess nur terminiert werden. Nun stehen weitere Aktionen zur Auswahl, so dass statt einer Terminierung einfach die CPU-Leistung für den Arbeitsprozess gedrosselt werden kann.
Anwendungsinitialisierung Jeder Administrator, der schon mal eine etwas größere Web-Anwendung auf dem IIS gehostet hat, kennt das Phänomen: Der erste Benutzer, der diese Anwendung aufruft, muss einen Moment warten, bis er diese angezeigt bekommt. Das liegt daran, dass zuerst ein Arbeitsprozess gestartet, das Framework geladen und die Datenbankverbindung aufgebaut werden muss. Mit Hilfe der Anwendungsinitialisierung kann dies jetzt optimiert werden, da man nun quasi den ersten Benutzeraufruf simulieren kann.
NUMA-basierte Skalierbarkeit Der IIS bietet jetzt Unterstützung für NUMA-Hardware, die den Einsatz von 32-128 CPU-Cores möglich macht. Durch diese Unterstützung gewährleistet die NUMA-Hardware von Anfang an nahezu optimale Leistung für den Web-Server.
In Windows 8 und 8.1 zeigt der Taskmanager standardmäßig neben der Last auf CPU und RAM auch die Disk-Performance an:
Dies ist sehr praktisch, weil man hier u.a. die Latenz sowie die Last in Prozenten und die tatsächlichen Raten sehen kann.
Bei einem Windows Server 2012 bzw. 2012 R2 wird das standardmäßig nicht angezeigt:
Wenn man nun auch hier die Disk-Performance sehen möchte, dann kann man dies aktivieren.
ACHTUNG: Das Aktivieren des Disk-Performance-Counters auf einem Server hat Auswirkungen auf die I/O-Performance der Festplatte (wie stark ist allerdings mit Sicherheit situationsabhängig)
Das Aktivieren ist recht einfach und funktioniert über einen simplen Aufruf in einer Kommandozeile mit Administratoren-Rechten:
Für Suchmaschinen und co.: Der Aufruf lautet
diskperf –Y
Sobald man das Kommando ausgeführt hat und den Taskmanager (neu)startet, sind auch auf dem Server die Disk-Daten zu sehen:
Das Abschalten ist nun eher trivial:
diskperf –N
Weitere Informationen zum Thema Windows Server 2012 R2 finden Sie auch unter http://www.ppedv.de/R2