In letzter Zeit gewinnt die Versorgung und Verwaltung von Systemen in einer demilitarisierten Zone (DMZ) oder sogar über vollständig öffentliche Netze über DSM immer mehr an Bedeutung. Mobile Mitarbeiter, Heimarbeitsplätze und das Arbeiten von den unterschiedlichsten Orten sowie die steigende Anzahl von neuartigen Geräten wie beispielsweise den Windows Surface Tablets erzeugen den Bedarf, diese Systeme unabhängig von ihrem aktuellen Standort erfassen und verwalten zu können.

Die Implementierung einer solchen Infrastruktur ist alles andere als trivial. Während die meisten Systemadministratoren im Umgang mit (SMB-)Shares, NTFS-Berechtigungen und Active Directory Benutzerkonten erfahren und sicher sind, sind die für eine DMZ-unterstützende Konfiguration erforderlichen Technologien oftmals noch recht unbekannt beziehungsweise besteht wenig Erfahrung mit deren Umgang.

Es sind Themen wie die Internet-Protokolle http und https, Begriffe wie SSL und TLS, die Microsoft Internet Information Services (IIS), Zertifikate und Public Key Infrastrukturen (PKIs) oder auch Netzwerk-Infrastruktur Aspekte wie Firewalls oder TCP/IP-Ports relevant, um die Admins bisher oft einen großen Bogen gemacht haben oder für deren Beherrschung es einfach keine Notwendigkeit gab.

Wenn eine solche DSM-Struktur implementiert werden soll, trifft man häufig auf die Situation, dass "irgendetwas nicht funktioniert". Sei es dass die Distribution von Paketen in die DMZ nicht erfolgt, dass sich neue Clients, die in der DMZ über PXE booten, nicht in der DSM-Datenbank registrieren oder dass ein Client-Sync nicht erfolgreich abgeschlossen werden kann. Es stellt sich natürlich die Frage, wo das Problem liegt oder was geändert werden muss, damit die Kommunikation funktioniert?

In solchen Umgebungen sind eigentlich so gut wie immer Firewalls im Spiel. Da es die ureigenste Aufgabe einer Firewall ist, nicht-autorisierten Netzwerkverkehr zu unterbinden, blockieren diese System häufig praktisch jeden "halbwegs unbekannten Traffic". Auch wenn die zuständigen Administratoren felsenfest behaupten, dass die benötigten Ports an den Firewalls geöffnet wurden, so ist es uns in unseren Projekten doch schon häufig passiert, dass sich eine Firewall als "Übeltäter" herausgestellt hat und diese die notwendige Kommunikation zwischen den beteiligten Komponenten unterbunden hat.

Daher ist in solch einer Situation eigentlich die erste Maßnahme zu testen, ob die erforderlichen Ports denn wirklich offen und erreichbar sind. Für den DSM Transport Layer - der in solchen DMZ-Umgebungen eine zentrale Rolle spielt - handelt es sich dabei standardmäßig zum Beispiel um den Port 5052. Kann der Management Point, der versucht, über den Transport Layer eine Verbindung zu einem anderen Management Point herzustellen, diesen nicht erreichen, ist mit hoher Wahrscheinlichkeit eben der Port 5052 blockiert.

Eine einfache Methode zu testen, ob die benötigten Ports erreichbar sind, besteht in dem Windows Tool "Telnet". Diesem Kommandozeilen-Werkzeug übergibt man einen Zielhost in Form eines Rechnernamens oder einer IP-Adresse und optional einen Port, auf dem die Verbindung hergestellt werden soll. Ist der Port erreichbar, so erscheint kurz nach dem Absetzen des Befehls ein leeres Shell-Fenster, das darauf wartet, Telnet-Kommandos entgegenzunehmen. In diesem Fall wurde die Verbindung also hergestellt und der Port-Test erfolgreich abgeschlossen. Sie können die Verbindung durch Eingabe des Kommandos "quit" wieder trennen.

Ist der Zielport nicht erreichbar, so kann auch über Telnet keine Verbindung hergestellt werden. Der Versuch des Verbindungsaufbaus läuft dann in einen Fehler.

In diesem Fall brauchen Sie also zunächst garnicht weiter auf DSM-Seite nach einem eventuellen Konfigurationsproblem zu suchen. Wenden Sie sich stattdessen an Ihre Kollegen vom Netzwerk- oder Firewall-Team und bitten Sie diese, den entsprechenden Port auf der Firewall zu öffnen.

Übrigens ist unter Windows 7 beziehungsweise Windows Server 2008 R2 und höher der Telnet-Client nicht mehr im Standard-Umfang der Windows-Installation enthalten. Wenn Sie versuchen, diesen zu starten, erhalten Sie die folgende Fehlermeldung:

Bevor die oben beschriebene Troubleshooting-Methode angewandt werden kann, muss diese Komponente also nachinstalliert werden. Dies können Sie über die grafische Oberfläche der Funktion "Windows-Funktionen aktivieren oder deaktivieren" in der Systemsteuerung (unter "Programme") erreichen:

Alternativ ist dasselbe Ergebnis mit einer einzigen Kommandozeile in einem administrativen Shell-Fenster mit dem "Deployment Image Servicing and Maintenance"-Tool DISM erzielbar:

dism /online /enable-feature /featurename:TelnetClient

Hinweis: die Groß- / Kleinschreibung des Featurenamens ist relevant.