NWC Services Blog
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.
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.
Comments 2
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.
Völlig richtig. Der Hersteller ist auch schon fleissig am werkeln :-)