Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

BLOG

BLOGGING CONSULTANTS

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

Feststellen des Online Status

Die Setups einiger Hersteller führen während der Installation eine Prüfung verschiedener Informationen (meistens die Gültigkeit der Lizenzdaten) durch. Grundsätzlich sollte es das Ziel sein, eine solche Onlineprüfung abzuschalten, sei es durch eine spezielle Enterprise-Version der Software oder mittels einer Aufzeichnung der Installation via Snapshot.

In einigen Fällen erweist sich dies aber als unpraktikabel oder sogar undurchführbar. Einige Hersteller verwenden Daten, die pro Installation eindeutig / unique sind, andere bringen zu häufig neue Updates heraus, um die Software via Snapshot-Verfahren aktuell zu halten. In solchen Fällen führt kein Weg daran vorbei, die Onlineprüfung zuzulassen.

Nun stellt sich die Frage, ab welchem Zeitpunkt ein Client "online" (also in der Lage ist, beliebige Webseiten zu erreichen) ist. Oft ist dies im Rahmen der Installation noch nicht der Fall, sodass die Verbindungsaufnahme fehlschlägt.

Die Gründe dafür sind vielfältig - Beispiele sind:

  • Der Proxy-Server wird per GPO im Userteil eingetragen und es ist kein Benutzer während der Installation angemeldet
  • Der Client befindet sich während der Installation in einem gesonderten Subnet, in dem kein Internet Zugang möglich ist
  • Ein Zertifikat für den Internetzugang ist noch nicht auf das System verteilt

Da Windows selbst in der Lage ist, den Online-Status zu überprüfen, bietet es sich an, das von Microsoft verwendete Verfahren einmal genauer zu analysieren. Es wird dabei eine Komponente des Dienstes "Network Awareness" dazu genutzt, die Online-Konnectivität zu testen. Genauer gesagt ist dafür eine Subkomponente, der "Network Connectivity Status Indicator" (kurz: NCIS) verantwortlich.

Dieser Dienst versucht im ersten Schritt, die Datei "http://www.msftncsi.com/ncsi.txt" herunterzuladen. Gelingt der Download, besteht eine ungehinderte Verbindung. Gelingt dies nicht, wird im nächsten Schritt versucht, die IP-Adresse der Domain "msftncsi.com" zur IP-Adresse 131.107.255.255 aufzulösen. Dabei wird über die Namensauflösung geprüft, ob eine fehlende Netzwerkauthentifizierung (z.B. public WLAN) die Ursache für die fehlgeschlagende Verbindung ist.

Laut Microsoft Technet werden die Zugriffe auf den Webservern von msftncsi.com zwar in klassischen IIS Logs mitprotokolliert, aber nach Aussagen von Microsoft nicht ausgewertet. Folgend der entsprechende Auszug aus der Technet (http://technet.microsoft.com/de-de/library/cc766017(v=ws.10).aspx):

NCSI does not use encryption (both the requests it sends and the responses it receives are standardized, as shown in the table earlier in this subsection). IIS logs are stored on the server at www.msftncsi.com. These logs contain the time of each access and the IP address recorded for that access. These IP addresses are not used to identify users, and in many cases, they are the address of a network address translation (NAT) computer or proxy server, not a specific client behind that NAT computer or proxy server.

Wer möchte kann diese Windows-eigene Funktionalität mit den entsprechenden Values im Registrykey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet konfigurieren. Durch Setzen des Values EnableActiveProbing auf 0 wird der gesamte Prozess deaktiviert.

Um nun aus einem eScript Paket heraus die Online-Konnectivität eines Clients während der Installation zu prüfen, kann als Grundlage das PowerShell-Script Get-WebFile von Joel Bennett (http://poshcode.org/417) genutzt werden.

Um das Script möglichst dynamisch in in DSM einzubinden, sind weiterhin folgende Modifikationen notwendig:

  • Aufbau eines eScriptes mit Installationsparametern für den Proxyserver, Proxyserver-Port und Authentifizierungsdetails
  • Aufruf des PowerShell-Scripts mit CallScript
  • Erweitern des PowerShell-Scripts um das Schreiben der Aktionen in die DSM Logfiles (für Fehleranalyse)
  • Erweitern des PowerShell-Scripts um die Auswertung des Inhalts der empfangenen ncsi.txt-Datei
  • Rückgabe der Ergebnisses in DSM

Das komplette Script (eScript mit Installationsparametern und CallScript-Aufruf) kann hier heruntergeladen werden.

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Windows und die x64 Redirection
Erweitertes Fehlerhandling in DSM
 

Kommentare 2

Stefan Brutscher (webseite) am Mittwoch, 17. Oktober 2012 10:53

Sehr coole Lösung. Danke.

Allerdings sollte unbedingt jeder Kunde der so eine Version hat die dem Hersteller wieder zurück senden und eine anständige Enterprise Version verlangen. Und hier hatte ich schon mit Kunden zusammen einige Erfolge.
Selbst mit großen Firmen wie Adobe.

Sehr coole Lösung. Danke. Allerdings sollte unbedingt jeder Kunde der so eine Version hat die dem Hersteller wieder zurück senden und eine anständige Enterprise Version verlangen. Und hier hatte ich schon mit Kunden zusammen einige Erfolge. Selbst mit großen Firmen wie Adobe.
web master (webseite) am Mittwoch, 17. Oktober 2012 11:11

Völlig richtig. Der Hersteller ist auch schon fleissig am werkeln :-)

Völlig richtig. Der Hersteller ist auch schon fleissig am werkeln :-)
Bereits registriert? Hier einloggen
Samstag, 23. November 2024

Sicherheitscode (Captcha)