Aufgabe bei VPN-Verbindung starten: Ereignis, Abfrage oder Anmeldedaten?
Ein Anmeldeskript läuft, bevor der Tunnel existiert. Vergleichen Sie einen Netzwerkereignis-Trigger, eine Ressourcenabfrage und gespeicherte Anmeldedaten danach, was jedes davon garantiert.
Ein Anmeldeskript, das ein Laufwerk verbindet oder einen Synchronisierungsjob startet, läuft, bevor der Tunnel eine Adresse hat, sodass es still scheitert und der Benutzer es jeden Morgen von Hand repariert. Windows bietet den meisten Clients keinen Verbindungs-Callback pro VPN, protokolliert aber die Netzwerkänderung, und dieser Eintrag kann die Arbeit im richtigen Moment starten. Die Wahl liegt zwischen dem Reagieren auf diesen Eintrag, dem Abfragen der Ressource und dem Entfernen der Eingabeaufforderung, die den Fehler sichtbar machte.
Die drei Mechanismen danach zu vergleichen, was sie garantieren, ist besser, als sie nach Eleganz zu ordnen. Jeder scheitert anders, und mit dem Fehlermodus leben Sie danach.
Warum die Anmeldung zu früh auslöst
Anmeldung und Start laufen, bevor der VPN-Adapter seine Adresse erhält, sodass eine Laufwerkszuordnung, eine interne URL oder eine Datenbankverbindung, die in diesem Moment versucht wird, weder eine Route noch einen Resolver hat. Die Anfrage scheitert, und die Sitzung bleibt in einem Zustand, den der Benutzer manuell reparieren muss. Dasselbe Skript in den Autostartordner zu verschieben ändert nichts, weil das Reihenfolgeproblem mitwandert. Der Auslöser muss eine Netzwerkänderung sein und kein Sitzungsereignis.
Eine geplante Aufgabe bei der Anmeldung mit beliebiger Verzögerung sieht wie eine Reparatur aus und ist in Wahrheit eine Vermutung. Sie funktioniert auf einer schnellen Verbindung und scheitert auf einer langsamen, was die am wenigsten nützliche Art von Zuverlässigkeit ist.
Drei Haken im Vergleich
Die Mechanismen unterscheiden sich darin, was sie beobachten, wie schnell sie reagieren und was sie bei einer Wiederverbindung später am Tag tun. Die Tabelle vergleicht sie an diesen drei Punkten und nicht danach, wie klug jeder klingt.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
Lesen Sie die Tabelle Zeile für Zeile. Der Ereignis-Haken ist am schnellsten und am lautesten, da Windows jedes Netzwerk erfasst, einschließlich des Café-WLANs, sodass die Aktion die Ressource prüfen muss, bevor sie etwas tut. Die Abfrage ist langsamer und genauer, weil sie genau dann erfolgreich ist, wenn die Freigabe oder der Hostname antwortet, und sie muss nicht wissen, welcher Client installiert ist. Gespeicherte Anmeldedaten sind überhaupt keine konkurrierende Option: Sie entfernen die Passwortabfrage, was ein zweiter und unabhängiger Grund ist, warum eine Zuordnung zur Anmeldezeit scheitert.
Die Wahl zwischen den ersten beiden hängt davon ab, ob auf dem Client ein brauchbares Ereignis existiert. Wo es das gibt, ist ein Ereignis plus Ressourcenprüfung die bessere Voreinstellung.
Den Ereignis-Trigger richtig bauen
Der Eintrag liegt im Protokoll Microsoft-Windows-NetworkProfile/Operational, und ID 10001 kennzeichnet ein Netzwerk, das gerade verbunden wurde. Erstellen Sie die Aufgabe mit einem Trigger Bei einem Ereignis, der auf dieses Protokoll, diesen Anbieternamen und diese Kennung zielt. Jedes Netzwerk, dem der Rechner beitritt, löst ihn aus, daher braucht die Aktion eine Schutzklausel statt einer Annahme, und sie sollte nur ausgeführt werden, während der Benutzer angemeldet ist, wenn die Arbeit zugeordnete Laufwerke berührt.
Die Schutzklausel sollte prüfen, was die Aufgabe tatsächlich braucht, etwa einen Freigabepfad oder einen Dienstport, und still beenden, wenn er nicht erreichbar ist. Den Adapternamen zu prüfen reicht nicht, weil ein Client einen Adapter über mehrere Profile hinweg wiederverwenden kann. Ein stilles Beenden hält das Protokoll lesbar und verhindert einen Wiederholungssturm gegen ein Netzwerk, das die Ressource nie bereitstellen wird.
Prüfen, dass die Aufgabe im richtigen Moment läuft
Beweisen Sie den Zeitpunkt statt die Konfiguration. Die folgenden Befehle zeigen die Aufgabendefinition, die letzten Netzwerkprofilereignisse und ob die Ressource aus dem Konto erreichbar ist, unter dem die Aufgabe läuft. Führen Sie sie nach einer echten Wiederverbindung aus und nicht nach einem manuellen Start.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiEin Aufgabenverlaufseintrag, der existiert, während kein Netzwerkereignis dazu passt, bedeutet, dass der Trigger falsch ist und nicht die Aktion. Wenn die Ereignisse erscheinen und die Aufgabe nicht, läuft die Aufgabe möglicherweise unter einem Konto, das die Ressource nicht sieht, und die Kontoausgabe ist der Hinweis. Eine Ressourcenprüfung, die besteht, während die Zuordnung noch fehlt, deutet auf den Sitzungskontext statt auf die Konnektivität hin. Jede dieser drei Beobachtungen führt Sie zu einer anderen Reparatur.
Schreiben Sie pro Lauf eine Protokollzeile mit der Adresse, dem Ressourcenergebnis und dem Ausgang. Der nächste Fehler zeigt dann, ob die Aufgabe zu früh lief, im falschen Netzwerk lief oder gar nicht lief.