Sind mehr als nur ein Browser auf einem System installiert, so konkurrieren diese ständig miteinander um die Vorherrschaft des Standard-Browsers. Diese schlechte Eigenschaft lässt sich aber zum Glück mit Hilfe der Gruppenrichtlinien und den Gruppenrichtlinienerweiterungen für Windows Server 2008 R2 relativ einfach und schnell abstellen.

Firefox

Jeder Benutzer wird dem Administrator dankbar sein, wenn er nicht von allen installierten Browsern regelmäßig um ein “Voting” für die Einstellung des Standard-Browsers “gebeten” wird. Auch beim Firefox sollte deshalb diese Nachfrage (egal, ob dieser der Standard-Browser werden soll oder nicht) deaktiviert werden.

Leider gibt es für diese Option keine einfache zentrale Lösung, weshalb ich hier auf die folgenden zwei Varianten verweisen möchte.

Variante 1: FrontMotion Firefox CE

Leider ist der Mozilla Firefox von Hause aus nicht über Gruppenrichtlinien konfigurier- und steuerbar. Dazu gehört auch, dass er nicht als MSI-Paket automatisch verteilt und installiert werden kann. Diese Schwachstelle wird durch den Software  Hersteller FrontMotion beseitigt. Diese Firma bietet mit dem FrontMotion Firefox Community Edition nicht nur sprach-basierte MSI-Pakete für die automatische Verteilung des Firefox innerhalb von Windows Domänen, sondern auch ein Firefox Richtlinien Template (ADM und ADMX) für die Verwaltung über eine Gruppenrichtlinie.

Variante 2: ADMX-Vorlage und VBS-Skript

Einen anderen Weg verfolgt n8felton mit seiner Kombination aus ADMX Vorlage und auszuführenden VBS-Skript, welches die vorgenommenen Registry-Änderungen auf dem jeweiligen System in Konfigurationsdateien umsetzt. Dadurch wird auch der Einsatz des originalen Firefox möglich – der sich allerdings nicht automatisch aktualisieren lässt. Die jeweils aktuelle Version der Dateien (inkl. deutscher ADML Datei) findet man bei GitHub unter https://github.com/n8felton/Firefox-ADMX.

Standard-Browser

Für die Einstellung als Standard-Browser müssen in der entsprechenden Gruppenrichtlinie im Benutzer-Teil folgende zwei Registry-Einträge aktualisiert werden:

HKEY_CURRENT_USER\Software\Classes\http\shell\open\command

HKEY_CURRENT_USER\Software\Classes\https\shell\open\command

Hier muss jeweils der (Standard) Eintrag vom Typ REG_SZ den folgenden Wert erhalten:

“%ProgramFiles(x86)%\Mozilla Firefox\firefox.exe” -osint -url “%1″

Danach werden alle Links automatisch mit dem Firefox geöffnet.

Internet Explorer

Beim dem Internet Explorer ist die zentrale Konfiguration wesentlich einfacher, da hier bereits die entsprechenden Gruppenrichtlinien-Einstellungen “von Haus aus” mitgeliefert werden.

Die Meldungen, die der Internet Explorer bei der Überprüfung des Standard-Browser liefert, lassen sich so einfach mit der folgenden Einstellung abstellen (Benutzerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Internet Explorer: Änderung der “Überprüfung des Standardbrowsers” deaktivieren):

Es bietet sich allerdings an, diese Einstellung im Abschnitt Benutzerkonfiguration, Windows-Einstellungen, Internet Explorer-Wartung, Programme aus einer bestehenden Konfiguration zu importieren.

Diese Einstellung überschreibt nämlich die obere Gruppenrichtlinie in jedem Fall.

Fazit

Der Kampf der Browser um die “Vorherrschaft” beim Anwender wird – wie andere Dinge – auf dem Rücken der IT-Administration ausgetragen. Denn der Benutzer bzw. Anwender gibt vor, welchen Browser er wann, wie oft und wo verwenden möchte. Dabei sollte möglichst alles funktionieren und kein Browser ständig nachfragen, ob er denn nun der gültige Standard-Browser ist. Zur Dokumentation für die zukünftige Wiederverwendung deshalb dieser Artikel.

Für Verbesserungsvorschläge, Kritik oder Fragen bin ich immer offen und freue mich über jederzeit über einen Kommentar.

Die Installation des WSUS Servers hatte ich zuvor auf einem frisch aufgesetzten, virtualisierten Windows Server 2008 R2 Standard Edition inkl. SP 1 mit Hilfe des Servermanagers durchgeführt.

Bei der Ausführung des Assistenten für die Konfiguration des WSUS erhielt ich dann den beschriebenen Fehler.

 Bei meiner Suche im Internet fand ich relativ schnell den hilfreichen Hinweis im Technet Forum von Microsoft. Nach der Installation des WSUS müssen – zumindest bei Auftreten des oben beschriebenen Fehlers – die beiden folgenden Updates eingespielt werden:

• Update für Windows Server Update Services 3.0 SP2 (KB2720211)
• Update für Windows Server Update Services 3.0 SP2 (KB2734608)

Die zwei aufgeführten Updates sind für 64 Bit Systeme gedacht – ggf. muss die 32 Bit Version auf der Download-Seite ausgewählt werden. Nach der Installation und einem Neustart synchronisiert nun der WSUS ohne Fehler.

Fazit

Kleineres Problem – schnelle und einfache Lösung, wenn selbige dokumentiert wurde. Nach wie vor gilt: Für Verbesserungsvorschläge, Kritik oder Fragen bin ich immer offen und freue mich über jederzeit über einen Kommentar.

Das Angebot von SIOS (ehemals SteelEye) richtet sich an Microsoft MVPs, die – nach einer Anfrage über datakeeper-mvp@us.sios.com - eine kostenfreie NFR-Version erhalten. Der originale Artikel ist unter dem folgenden Link erreichbar.

Bei Fragen zum DataKeeper – welcher auch über das Unternehmen bezogen werden kann, für das ich regulär arbeite – hinterlasst eine kurzen Kommentar. MVP Anfragen für die NFR-Version richtet bitte direkt an obige E-Mail-Adresse.

Die Installation unter Windows Server 2012 bietet zwar einige kleine Unterschiede, kann aber so auch unter Windows Server 2008 R2 durchgeführt werden – die Version des WSUS ist nämlich nach wie vor 3.0 Service Pack 2.

Voraussetzungen

Neben dem Betriebssystem und der Wahl, ob der Server physisch oder als virtuelle Maschine betrieben werden soll, benötigt man genügend Speicherplatz für die Bereitstellung der Windows Updates in der eigenen Umgebung. Dieser Speicherplatz hängt von der

1. Anzahl der verschiedenen Sprachen,
2. der Anzahl unterschiedlicher eingesetzter Anwendungen und Betriebssystemen (Server und Clients) und
3. der später definierten Klassifizierungen ab.

Der WSUS benötigt für die Speicherung der eine Microsoft SQL Server Datenbank. Wer bereits einen SQL Server in seiner eigenen Umgebung betreibt, kann während der Installation des WSUS selbigen als Datenbankserver auswählen – oder aber die Windows Interne Datenbank installieren.

Wer die grafische Verwaltungskonsole SQL Management Studio für die interne Datenbank einsetzen möchte, kann bei der Auswahl der zu installierenden Rollen im Server-Manager gleich das Feature .Net Framework 3.5 auswählen und mitinstallieren.

Installation

Die Installation der Windows Server Updates Services (WSUS) geschieht über den Server-Manager als Rolle. Dabei wird automatisch die benötigte Webserver (IIS) Rolle mitinstalliert. Wer keinen SQL Server einsetzt, sollte die WID Database mitinstallieren:

Während der Installation des WSUS fragt dieser nach dem Ort an dem die Windows Updates zukünftig gespeichert werden sollen. Es ist sinnvoll, dafür ein eigenes Volume zu bereitzustellen und die Updates nicht auf dem Systemvolume abzulegen.

Während unter Windows Server 2008 R2 die Dateien der internen Datenbank SUSDB in einem Unterordner neben den Windows Updates liegen (UpdateServiceDBFiles), befinden sich die Datendateien bei Windows Server 2012 unter C:\Windows\WID\Data.

Die Änderung der Ports ist für die Gruppenrichtlinien interessant, über die der WSUS innerhalb der Domäne bekannt gemacht wird. So muss eine bestehende Richtlinie Internen Pfad für den Microsoft Updatedienst angeben unter dem Pfad Computerkonfiguration, Richtlinien, Administrative Vorlagen, Windows-Komponenten, Windows Update wie folgt aktualisiert werden:

Danach kommunizieren die Clients erst korrekt mit dem neuen WSUS, die neuen Ports werden automatisch als eingehende Regeln in der Firewall des Windows Server 2012 hinzugefügt.

Windows Internal Database

Bei Windows Server 2008 R2 befindet sich der Installationsordner unter dem Pfad:

C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\

Wie unschwer zu erkennen ist, verbirgt sich eine speziell angepasste SQL Server 2005 Express Edition hinter dieser Version. Der Dienst-Anzeigename lautet Windows Internal Database (MICROSOFT##SSEE) und intern MSSQL$MICROSOFT##SSEE. Der Servername für die Anmeldung im SQL Management Studio lautet:

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

Für die grafische Verwaltung empfehle ich das SQL Management Studio 2008 Express. Zusätzlich benötigt man für die Ausführung der WSUS-Cleanup-Skripte das SQL Commandline Utlility SqlCmdLnUtils.msi aus dem Microsoft SQL Server 2008 SP3 Feature Pack.

Bei Windows Server 2012 befindet sich der Installationsordner unter dem Pfad:

C:\Windows\WID\

Hier verbirgt sich hinter der Datenbank ein angepasster SQL Server 2012 (Version 110). Der Dienst-Anzeigename lautet Interne Windows-Datenbank und intern MSSQL$MICROSOFT##WID. Der Servername für die Anmeldung im SQL Management Studio lautet:

np:\\.\pipe\MICROSOFT##WID\tsql\query

Für die grafische Verwaltung benötigt man das SQL Management Studio für SQL Server 2012 Express. Weiterhin benötigt man für die Ausführung der WSUS-Cleanup-Skripte das SQL Commandline Utlility SqlCmdLnUtils.msi aus dem Microsoft SQL Server 2012 SP1 Feature Pack.

Automatische Bereinigung der Datenbank

Wie schon in meinem früheren Beitrag, kommen wieder meine Skripte aus dem Package WSUS-Cleanup.zip zum Einsatz. Der ZIP-Container enthält die folgenden drei Dateien, die in einen beliebigen Ordner auf den Server kopiert werden können – in meinem Beispiel nach D:\WSUS:

D:\WSUS\WSUS-Serverbereinigung.cmd
D:\WSUS\WSUS-Serverbereinigung.ps1
D:\WSUS\WsusDBMaintenance.sql

Wurde das Paket mit Hilfe des Internet-Explorers heruntergeladen, sollte zunächst die Powershell-Datei WSUS-Serverbereinigung.ps1 im Bezug auf die vom Internet Explorer hinterlegte Download-Quelle zugelassen werden. Dafür lässt man sich einmalig die Eigenschaften der Datei anzeigen und bestätigt im Abschnitt Sicherheit mit dem Button Zulassen deren Vertrauenswürdigkeit:

Die Anpassung an die eigene Umgebung erfolgt lediglich im Skript WSUS-Serverbereinigung.cmd. Hier müssen die Zeilen 2 bis 8 entsprechend geändert werden:

@echo off
set WSUSPATH=<Pfad zu den Skripten>
set WSUS-SERVER=<Servername>
set PORT-NUMBER=<Portnummer>
REM set DATABASECONNECT=np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
REM set DATABASECONNECT=np:\\.\pipe\MICROSOFT##WID\tsql\query 
REM set SQLCMD="%ProgramFiles%\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe"
...

In Zeile 2 muss der Pfad zu den restlichen Skripten angegeben werden, in meinem Beispiel in (bitte ohne abschließenden Backslash):

set WSUSPATH=D:\WSUS

In Zeile 3 muss der Servername eingetragen – in Zeile 4 die richtige Port-Nummer konfiguriert werden – bei Windows Server 2012 und einem Small Business Server also in (unter Windows Server 2008 R2 bitte Port 80 verwenden):

set PORT-NUMBER=8530

Im Anschluss muss in Zeile 5 und 6 nur noch der richtige Datenbank-Servername – abhängig von der Version – ausgewählt und aktiviert werden. Bis einschließlich Windows Server 2008 R2 muss die Zeile 5 durch Entfernung der Kommentarfunktion REM aktiviert werden –  für eine WID Datenbank unter Windows Server 2012 muss in Zeile 6 der Befehl REM entfernt werden.

Die Einstellung des SQL Kommandozeilen Tools sqlcmd.exe in Zeile 7 ist gleich von mehreren Komponenten abhängig. Das Unterverzeichnis 90 ist bei der Nutzung des SQL Server 2005 Express Edition gültig, kommt der SQL Server 2012 (Express) zum Einsatz muss an dieser Stelle eine 110 eingetragen werden:

set SQLCMD=”%ProgramFiles%\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe”

Außerdem entscheidet noch die Wahl der Softwareversion über eine Änderung des Pfades für SQLCMD. Bei einer 64 Bit Version bleibt der Pfad bestehen, bei einer 32 Bit Version (x86) muss der Beginn des Pfades %ProgramFiles% mit %ProgramFiles(x86)% ersetzt werden.

Ausführung und Verwendung

Für die Ausführung des PowerShell-Skriptes WSUS-Serverbereinigung.ps1 muss – abhängig von der Konfiguration des Servers – noch die Ausführungsrichtlinie für nicht digital signierte Skripte angepasst werden. Mit dem Powershell-Befehl

Get-ExecutionPolicy -List

erhält man zunächst die Liste der gültigen Einstellungen. Für die Ausführung des Skriptes muss in einer administrativen PowerShell-Konsole der Befehl

Set-ExecutionPolicy RemoteSigned

ausgeführt werden. Dieser bewirkt, dass auch nicht signierte Skripte für die Ausführung erlaubt sind.

Der Start der Bereinigung beginnt mit der Ausführung der Batch-Datei WSUS-Serverbereinigung.cmd. Selbige lässt sich für eine unbeaufsichtigte Ausführung einfach als neuen Task innerhalb der Aufgabenplanung konfigurieren.

Während der Ausführung des Skriptes werden zunächst (durch den Aufruf des Powershell Skriptes WSUS-Serverbereinigung.ps1  in Zeile 18) die WSUS-Dateien bereinigt, im Anschluss wird (in Zeile 24) das SQL Skript WsusDBMaintenance.sql von Microsoft Technet gestartet, welches die WSUS-Datenbank reindiziert und reorganisiert. Die darauf folgenden Aktionen (Zeile 25 bis 27) verkleinern zum Schluss die Datenbank sowie die Datenbankdateien.

Update vom 13. März 2013

Das SQL Skript WsusDBMaintenance.sql habe ich auf Wunsch einiger Leser meines Blogs (siehe ursprünglicher Artikel) angepasst und die folgenden vier Zeilen am Dateiende hinzugefügt:

--Delete sync history
PRINT 'Delete sync history.' + convert(nvarchar, getdate(), 121)
DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')
GO

Der Befehl bewirkt, dass aus der WSUS-Datenbank alle alten Synchronisierungseinträge entfernt werden. Dadurch war eine Anpassung oder Änderung des Aufruf-Skriptes (WSUS-Serverbereinigung.cmd) nicht notwendig. Weitere Informationen zum Löschen der Synchronisierungseinträge findet man bei wsus.de.

Während jeder Ausführung werden sämtliche Ausgaben im Ordner der Skripte in der Datei WSUS-Cleanup.log protokolliert.

Fazit

Wenngleich sich an der Funktionsweise des Windows Software Update Service nichts verändert hat, so unterscheidet sich die Installation unter Windows Server 2012 leicht zum Vorgänger Windows Server 2008 R2. Die Portänderungen und der Einsatz einer neuen internen Windows Datenbank machte kleinere Anpassungen in meinen eigenen Skripten für die automatische Bereinigung der Datenbank notwendig. Wie immer, für Verbesserungsvorschläge, Kritik oder Fragen bin ich immer offen und freue mich über jederzeit über einen Kommentar.

Der angegebene Link empfiehlt lediglich die Aktivierung der Windows Installer-Protokollierung. Leider fand ich hier keiner weiteren Hinweise. Dieser Fehler trat aber ebenfalls für die folgenden, weiteren Rollups auf:

• Update Rollup 7-v2 for Exchange Server 2010 Service Pack 1 (KB2756496)
• Update Rollup 5-v2 for Exchange Server 2010 Service Pack 2 (KB2785908)

Bei meiner Recherche im Internet fand ich leider erst jetzt den entscheidenden Hinweis.

Ursache und Lösung

Der Grund für das Fehlschlagen der Installation der Update Rollups ist die Unverträglichkeit des Windows Management Framework 3.0 (PowerShell 3.0) mit dem Exchange Server 2010 (nicht 2013). Microsoft hat dieses Framework als Windows Update KB2506143 bzw. KB2506146 verteilt, um Systeme mit Windows Server 2008 R2 auf dem dieses Update installiert wurde, nun ebenfalls mit dem Server-Manager unter Windows Server 2012 verwalten zu können.

Leider prüfen die Installations-Routinen der Update Rollups für Exchange Server 2010 nicht das Vorhandensein des Management Framework 3.0 und warnen evtl. davor – die Installation bricht einfach mit der folgenden Fehlermeldung ab (Event-ID 20, WindowsUpdateClient):

Letztlich fand ich die Erklärung und Lösung auf dem Exchange Team Blog. Nach der Deinstallation des Windows Management Framework 3.0 lassen sich alle Update Rollups für den Exchange Server 2010 ohne Probleme installieren.

Dies gilt allgemein für Windows Server 2008 R2 und neben dem Exchange Server 2010 ebenfalls für den Exchange Server 2007.

Fazit

Wie unschwer zu erkennen, habe ich die Ursache leider erst sehr spät erkannt – ich hatte die Update Rollups seit Dezember 2012 einfach ausgelassen. Warum die Installer von Microsoft die oben beschriebene Konstellation nicht abprüfen und so ggf. Warnungen oder Hinweise geben zu können, ist mir schleierhaft. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Inzwischen wurde unser Server migriert: Ein neuer Windows Server 2012 mit dem Network Policy Server (NPS, dt. Netzwerkrichtlinienserver) hat nun die Aufgabe der Authentifizierung unserer W-LAN-Clients übernommen. Da sich an der Technologie des Protected Extensible Authentication Protocol (PEAP) mit EAP-MSCHAPv2 nichts geändert hat, beziehe ich mich deshalb auf meinen vorangegangenen Artikel und möchte hier nur die Neuerungen und Änderungen im Bezug auf den NPS unter Windows Server 2012 skizzieren.

Ich empfehle daher Lesern mit geringen Vorkenntnissen zuerst den älteren Beitrag zu studieren, um im Anschluss hier fortzufahren.

Voraussetzungen

Hardware

Für eine Verbindung über Funk (Wireless-LAN) wird nach wie vor ein Zugangspunkt (Access Point) benötigt. Dieser muss den Sicherheitsmodus WPA2-Enterprise beherrschen. Der Access Point wird über das RADIUS-Protokoll später mit unserem Authentifizierungsserver kommunizieren. Ob dieser neue Authentifizierungsserver im Windows 2012-Gewand rein physisch oder als virtuelle Maschine betrieben werden soll, liegt im Ermessen des Administrators.

Windows Server Softwarekomponenten

Wie bisher wird für die Umsetzung des Themas eine Grundkonfiguration an Windows-Komponenten benötigt:

• eine Domäne mit mindestens Windows Server 2003, Standard Edition
• eine eingerichtete Microsoft Stammzertifizierungsstelle (Root Certificate Authority)
• einen Microsoft DHCP Server
• einen Microsoft Network Policy Server (NPS), der RADIUS bzw. Netzwerkrichtlinienserver

Die letztere Komponente wurde in unserem Beispiel auf einem neuen Windows Server 2012 als Rolle installiert:

Die Rolleninstallation ist mit der unter Windows Server 2008 R2 vergleichbar und funktioniert dort gleichermaßen.

Einrichtung

Access Point

Bei der Einrichtung des Zugangspunktes für die W-LAN-Clients mit via PEAP-gesicherter Authentifizierung sind die folgenden Einstellungen wichtig:

• Sicherheitsmodus: hier ist WPA2-Enterprise auszuwählen (auch WPA2-802.1X oder WPA2-1X genannt)
• RADIUS Server: IP Adresse oder DNS-Name des Netzwerkrichtlinienservers (NPS)
• RADIUS Server Port: im Standard 1812, bei Änderung auch im NPS einzustellen
• Verschlüsselung: sollte bei WPA2 automatisch auf AES eingestellt sein
• Shared Secret: Passwort für die verschlüsselte Kommunikation zwischen Access Point und NPS

Auf die Länge und die verwendeten Zeichen eines als hinreichend sicher geltenden Passworts gehe ich bewusst nicht ein – Administratoren, die sich des beschriebenen Themas annehmen, sollten hier ausreichend sensibilisiert sein.

Zertifikat durch eine interne Zertifizierungsstelle

Nach wie vor benötigt der Netzwerkrichtlinienserver (NPS) bei dem verwendeten Verfahren PEAP mit EAP-MSCHAPv2 für die verschlüsselte Verbindung zwischen Server und W-LAN-Client ein Computerzertifikat (Zweck: Serverauthentifizierung).

Die Prüfung des Zertifikates erfolgt nach wie vor über die Konsole Zertifikate (Lokaler Computer):

Die Verwendung des Zertifikates wird später für die Eigenschaften des geschützten EAP im Abschnitt der Netzwerkrichtlinie erläutert.

Netzwerkrichtlinienserver (NPS) – RADIUS Server

Der Windows Server 2012 auf dem die Rolle des Netzwerkrichtlinienserver (NPS) installiert werden soll, muss zuvor bereits Mitglied einer Domäne sein. Nach der Rolleninstallation kann die Verwaltungskonsole des NPS über den Server-Manger im Menüpunkt Tools aufgerufen werden:

Im Anschluss öffnet sich die Verwaltungskonsole, über die zunächst der neue Netzwerkrichtlinienserver (NPS) im Active Directory registriert werden kann (Rechtsklick auf NPS (lokal)):

Wurde der NPS in einer Gesamtstruktur mit mehreren Domänen installiert und soll auch Benutzer anderer (Sub-)Domänen authentifizieren, so muss der NPS für diese Domänen ebenfalls registriert werden. Dies geschieht auf Kommandozeilenebene auf dem NPS mit Hilfe des Befehls netsh:

netsh ras add registeredserver Subdomäne-FQDN NPS-Servername

In den Eigenschaften des NPS (Rechtsklick auf NPS (lokal)) lassen sich die Ports für die Authentifizierung und Kontoführung einstellen. Dies ist im Standard der RADIUS Port 1812 für die Authentifizierung und 1813 für die Kontoführung:

 Ändert man die RADIUS Ports des Netzwerkrichtlinienservers, müssen diese von Hand auch in der Firewall des Servers als Ausnahmen definiert werden.

Sollen neben Fehlern auch abgelehnte und erfolgreiche Authentifizierungen im Ereignisprotokoll des NPS gespeichert werden, kann das auf der Registerkarte Allgemein eingestellt werden.

Im Vergleich zum IAS unter Windows Server 2003 werden die abgelehnten oder erfolgreichen Authentifizierungsversuche der Clients nicht mehr im System-Ereignisprotokoll sondern im Sicherheits-Protokoll gespeichert.

Im ersten Schritt der Konfiguration des NPS wird der Access Point (oder ggf. mehrere) als neuer RADIUS Client hinzugefügt:

Damit ist bereits die Kommunikation zwischen Access Point und NPS über RADIUS (AES-verschlüsselt über Shared Secret) sichergestellt. Im Anschluss kann nun die neue Verbindungsanforderungsrichtlinie erstellt werden. Dabei sind die Bedingungen für die Definition der Anforderungen verantwortlich:

Über die Bedingungen wird eingeschränkt, ob, auf Grund der vom RADIUS Client übergebenen Eigenschaften der Client-Anfrage, der Benutzer auch authentifiziert wird. Es lassen sich hier noch – abhängig von den Anforderungen im eigenen Unternehmen – sehr viele weitere Bedingungen setzen. Außerdem kann und sollte der Authentifizierungsanbieter eingestellt werden (Lokaler Computer):

Dadurch wird der NPS angewiesen, die Benutzer lokal (in der Domäne) zu authentifizieren. Alternativ könnten Anfragen auch an dritte Systeme oder wiederum andere RADIUS Server weitergeleitet werden.

Im Anschluss kann nun eine neue Netzwerkrichtlinie für den NPS erstellt werden:

Die Option Benutzerkonto-Eigenschaften ignorieren gibt an, ob der NPS Rücksicht auf die Einwähl-Einstellungen des Benutzers im Active Directory nehmen soll oder nicht. In der Registerkarte Bedingungen lassen sich nun Einschränkungen für die Autorisierung einer Verbindungsanforderung treffen:

Im obigen Beispiel wurden die Tages- und Uhrzeiteinschränkungen sowie die Mitgliedschaft einer Domänengruppe des für die Authentifizierung verwendeten Benutzerkontos konfiguriert. Unter der Registerkarte Einschränkungen wird nun als EAP Variante Geschütztes EAP (PEAP) eingestellt:

In den Eigenschaften des PEAP wird das von der internen Zertifizierungsstelle ausgestellte Zertifikat für die Serverauthentifizierung ausgewählt und als EAP-Typ das Gesicherte Kennwort (EAP-MSCHAPv2) eingestellt.

Zu guter Letzt müssen noch einige Einstellungen für den authentifizierenden Client getroffen werden. Dies betrifft zum Einen die Verschlüsselung:

Außerdem muss noch definiert werden, wie der Client eine gültige IP Adresse im Netzwerk erhält (in meinem Beispiel über einen DHCP Server im gleichen Netzwerk):

Als Besonderheit des NPS beherrscht dieser seit Windows Server 2008 R2 die Funktion Network Access Protection (NAP). Diese Funktion dient dazu, einen erfolgreich authentifizierten Client vor dem Zugriff auf das Produktiv-Netzwerk, temporär mit einem Quarantäne-Netzwerk zu verbinden. Dort werden Eigenschaften wie Windows Updates oder installierte Virenscanner und gültige Signaturen geprüft und im Anschluss der Zugriff auf das Produktiv-Netz gewährt. Da es sich bei unseren W-LAN-Clients nicht ausschließlich um Windows-Clients handelt, verwenden wir die NAP-Funktion nicht und gewähren somit nach erfolgreicher Authentifizierung dem Client Vollzugriff:

Damit ist die Grundkonfiguration des Netzwerkrichtlinienserver (NPS) unter Windows Server 2012 abgeschlossen. Die konfigurierten Clients sollten somit in der Lage sein, sich bereits erfolgreich zu Authentifizieren und so eine Verbindung mit dem W-LAN herzustellen.

Konfiguration der Clientgeräte

Auch an dieser Stelle hat sich an der Konfiguration der W-LAN-Clients nichts geändert – unter Windows 7 besitzt die Beschreibung meines älteren Artikels Gültigkeit. Auch die Liste der erfolgreich getesteten Geräte hat sich kaum geändert:

• Smartphones (Android 2.2 bis 4.2.1)
• Apple iPhone
• Apple iPad
• Windows XP (ab Service Pack 2)
• Windows 7
• Windows 7 Phone

Die Einstellung ist – gerade bei den mobilen Endgeräten – wie bspw. Smartphones denkbar einfach und schnell erledigt. Das zeigt exemplarisch die Einrichtung des neuen W-LAN an einem Android-Gerät aktueller Version. Bei der Suche nach Verbindungen wird hier der Sicherungstyp bereits als 802.1x angezeigt:

Beim Öffnen der Einstellungen für diese Verbindung muss zunächst die EAP-Methode gewählt werden (in unserem Fall PEAP):

Nun muss nur noch als Phase 2-Authentifizierung MSCHAPv2 ausgewählt werden:

Im Anschluss ist lediglich der Anmeldename in der Form DOMÄNE\Anmeldename oder Anmeldename@FQDN und das zugehörige Passwort zu hinterlegen. Die anonyme Identität kann frei bleiben:

Mit einem Druck auf Verbinden wir danach eine Verbindung mit dem W-LAN hergestellt. Einen eventuellen Misserfolg bzw. die erfolgreiche Authentifizierung findet man im Sicherheit-Ereignisprotokoll des Netzwerkrichtlinienservers.

Protokollierung der Verbindungen

Wie bereits erwähnt, dokumentiert der Netzwerkrichtlinienserver alle abgelehnten und erfolgreichen Verbindungsversuche (sofern aktiviert)  im Ereignisprotokoll Sicherheit. Bei einer erfolgreichen Verbindung finden sich pro Benutzer 2 Meldungen mit den Event-IDs 6272 und 6278 der Aufgabenkategorie Netzwerkrichtlinienserver:

Zusätzlich bietet der NPS aber – auch wie bisher der ISA unter Windows Server 2003 – die Möglichkeit der detaillierten Protokollierung der Kontoführung. Dabei lassen sich sowohl Textdateien (XML) als auch eine SQL Server Datenbank für die Protokollierung nutzen:

Für die Beschreibung der XML-Daten und die benötigten Datenbankfelder bei SQL Server-Nutzung empfehle ich folgenden Microsoft Technet Artikel.

Weitere Informationen zum NPS und 802.1X findet man bei Microsoft Technet.

Fazit

Wenn auch nicht mehr völlig neu, so soll die Aktualisierung des behandelten Themas in Bezug auf die genutzten aktuellen Windows Produkte eine Hilfestellung für Dritte als auch als Gedankenstütze für mich dienen. Ich hoffe, der Beitrag zeigt dennoch, mit welchem relativ geringen Aufwand die Umsetzung einer mit PEAP 802.1x gesicherten W-LAN-Authentifizierung unter Windows Server 2012 möglich ist. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Wenig später erhielt ich – über die eingerichtete Weiterleitung von Warnungen und Fehlermeldungen - die folgende Meldung via E-Mail von dem Domänencontroller, auf dem ich die Gruppenrichtlinien aktualisiert hatte:

Die Meldung vom Typ Warnung aus der Quelle Software Installation mit der Event-ID 119 wird im Anwendungsereignisprotokoll gespeichert – natürlich separat für jedes einzelne MSI-Paket.  Wie ich finde, eine zur Karnevalszeit passende Meldung aus der Serie Fehlermeldungen, die die Welt nicht braucht.

Problem

Da wir – bedingt durch verschiedene Notwendigkeiten der Systempflege – auf vielen Systemen automatische Reboots konfigurieren, starten die meisten der Server in unterschiedlichen Rhythmen während der Nacht neu. Typischerweise nutzen wir dafür die Aufgabenplanung und das seit Windows Server 2003 integrierte Systemprogramm shutdown.exe.

Als Parameter für den Aufruf von shutdown verwenden wir typischerweise

%SystemRoot%\System32\shutdown.exe -r -f -t 0

welche für einen sofortigen, forcierten Reboot erwirken. Bisher funktionierte diese Lösung reibungsfrei – erst seit einigen Tagen beobachteten wir bei einigen der virtualisierten Maschinen, dass diese beim Neustart die Systemwiederherstellung starteten.

Dies ist extrem ärgerlich, da so sämtliche Funktionen des Servers natürlich nicht zur Verfügung stehen. Bricht man den Dialog über die verbundene Konsole ab, so startet das System das Betriebssystem im Anschluss anstandslos neu.

Lösung

Da wir die Ursache für dieses Verhalten konnten wir bisher noch nicht finden, allerdings lässt sich selbiges mit einer Konfigurationsänderung (Workaround) des Windows-Start-Managers umgehen. Über den Kommandozeilenbefehl

bcdedit /set {default} bootstatuspolicy ignoreallfailures

wird die Neustart-Policy für den Standard-Boot-Eintrag auf IgnoreAllFailures gesetzt. Mit dem Befehl bcdedit kann man im Anschluss die geänderte Einstellung kontrollieren:

Windows-Startladeprogramm
-------------------------
Bezeichner {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows Server 2008 R2
locale de-DE
inherit {bootloadersettings}
recoverysequence {fabb4230-3ae7-11e2-a422-c35845ecfe8e}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {fabb422e-3ae7-11e2-a422-c35845ecfe8e}
nx OptOut
bootstatuspolicy IgnoreAllFailures

Nach dieser Einstellung trat das beschriebene Verhalten bei keiner der betroffenen virtuellen Maschinen mehr auf.

Fazit

Das hier dokumentierte Verhalten lässt sich bisher nicht erklären – Fehler an den virtuellen Maschinen konnten wir bisher ausschließen. Ob die Ursache bei neuen Windows Updates zu suchen ist, lässt sich leider nur vermuten. Wer hier Näheres weis, den bitte ich um einen kurzen Kommentar. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Problem

Von den drei virtuellen Remote Desktop Servern (Windows Server 2008 R2), die in einer Farm betrieben werden, funktionierte auf dem zuletzt installierten Server die Zwischenablage nicht. Obwohl alle Remotedesktop-Server via zentraler Gruppenrichtlinie konfiguriert wurden, zeigte ein Test, dass auf dem neu eingerichteten Server die Copy & Paste Funktion der Zwischenablage augenscheinlich nicht funktionierte.

Durch die Deaktivierung der Einstellung “Zwischenablageumleitung nicht zulassen” im Computer-abhängigen Teil der Gruppenrichtlinie im Pfad Richtlinien/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Geräte- und Ressourcenumleitung wird die Zwischenablageumleitung immer zugelassen. Die Kontrolle in der Konfiguration des Remotedesktop-Sitzungshosts zeigte auf allen Terminalservern das gleiche Bild: Die Umleitung der Zwischenablage war zugelassen:

Trotzdem funktionierte das Kopieren und Einfügen von Objekten über die Zwischenablage vom Client zum Server nach wie vor nicht.

Ursache und Lösung

Bei meiner Suche nach der Ursache verglich ich unterschiedliche Bereich der Remotedesktop-Server miteinander. Dabei fiel mir im ProcessExplorer von Sysinternals auf, dass auf den funktionierenden Systemen für jede Benutzersitzung der Prozess rdpclip.exe gestartet war. Auf dem fehlerhaften System fehlte dieser Prozess aber gänzlich.

Deshalb untersuchte ich die Registry aller System und verglich die Einträge auf der Suche nach unterschiedlichen Einstellungen für rdpclip.exe. Relativ schnell fand ich schließlich die entsprechende Stelle – im Pfad

HKLM\System\CurrentControlSet\Control\Terminal Server\Wds\rdpwd

fehlte der folgende Eintrag vom Typ REG_SZ:

“StartupPrograms”=”rdpclip”

Nachdem ich den fehlenden Eintrag ergänzt hatte, wurde für alle neuen Benutzersitzungen der Prozess rdpclip.exe wieder gestartet – die Umleitung der Zwischenablage funktionierte problemlos.

Fazit

Wie so oft, gilt bei der Suche und Fehlerbehebung von IT-Problemen: kleine Ursache, große Wirkung. Warum der Eintrag auf dem betroffenen Server nicht mehr existierte, kann ich (mir) leider nicht erklären – ich erinnerte mich, auf allen Servern mit dem Sysinternals Tool Autoruns überflüssige Starteinträge bereinigt zu haben – eine wiederholte Kontrolle zeigte mir aber, dass hier der Start von rdpclip nirgends auftaucht und somit auch nicht möglicherweise unbewusst gelöscht wurde. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.