Windows erbjuder ingen återuppringningspolicy för sin VPN-klient, så en anslutning som faller vid midnatt är fortfarande nere vid frukosten. En schemalagd uppgift som bevakar avbrottet och kör rasdial stänger igen den luckan utan en tredjepartsklient. Om uppgiften beter sig som en operatör eller som en slinga beror på tre detaljer: vilka händelser den matchar, vilka autentiseringsuppgifter den kan se och vad den gör med resultatet. Ingen av de tre är svår, och att missa någon av dem är det som skapar en uppgift som ringer för alltid.

Varför en timer är fel utlösare

En timer ringer enligt sitt eget schema oavsett om tunneln är nere eller inte. Det ger försök som ingen behövde, och ett försök under en arbetssession kan avbryta den. En händelseutlösare utlöses bara när anslutningen byter tillstånd, vilket är billigare och lättare att resonera kring. Händelsen bär också orsaken, och orsaken är det som skiljer ett nätverksfel från en person som kopplar ner med avsikt.

Den skillnaden är skillnaden mellan en användbar uppgift och en som slåss med användaren varje kväll. Det är också den del som vanligtvis saknas i recept som bara beskriver åtgärden.

Händelseparet, och den som ska undertryckas

Remote Access Service-klienten skriver livscykelposter till Application-loggen under leverantören RasClient. 20226 markerar en anslutning som avslutades, och 20227 markerar ett försök som misslyckades, så båda kan motivera ett nytt samtal. Allt annat i uppgiften beror på att matcha de två identifierarna exakt. De har varit stabila i åratal, därför cirkulerar recept byggda på dem fortfarande, men ett bygge som byter namn på leverantören eller ID:na gör att frågan inte returnerar något. Kör om bevissteget efter varje funktionsuppdatering i stället för att vänta på att uppgiften slutar utlösas.

En avslutning måste uteslutas. Fel 631 betyder att användaren kopplade ifrån porten, och ett nytt samtal i det ögonblicket slåss med personen som just bytte nätverk med avsikt. Lägg undantaget i utlösarens filter och inte i skriptet, så att uppgiften inte startar alls. Det måste bara gälla ett händelse-ID, eftersom ett EventData-predikat bara matchar när det namngivna elementet finns, och en delad sats skulle tyst släppa varje händelse med det andra ID:t. Läs elementnamnet ur en riktig post innan du skriver filtret:

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

XML visar de exakta Data-namnen i den posten. ErrorCode är den vanliga stavningen, och en post som använder något annat kräver att namnet byts ut i filtret nedan.

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

Klistra in det i utlösarens anpassade filter och bevisa det som en fråga innan det blir en utlösare. Samma XPath körs från PowerShell mot den levande loggen, vilket är det billiga sättet att se vad den matchar medan uppgiftshistoriken ännu inte är inblandad.

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

En utlösare som tyst inte matchar något ser precis ut som en uppgift som körs och misslyckas. Båda framstår som "automatiseringen fungerar inte", och ingen av dem säger vilken halva som saknas. Kontrollera frågans utdata först, eftersom det skiljer de två fallen i ett enda steg.

Samtalet misslyckas eftersom ingen finns där för att skriva lösenordet

Åtgärden kör rasdial med anslutningens namn. När profilen inte har några cachelagrade autentiseringsuppgifter misslyckas samtalet direkt eftersom ingen finns där för att svara på prompten. Det är den vanligaste orsaken till att en korrekt utlöst uppgift inte gör något synligt, så kontrollera det innan du rör utlösaren. Manuell uppringning från en kommandoprompt skiljer ett autentiseringsproblem från ett schemaläggningsproblem.

Spara autentiseringsuppgifterna en gång under det konto som uppgiften ska köras som, och gör det kontot till en del av designen. En uppgift som körs som SYSTEM kan inte läsa autentiseringsuppgifter som cachelagrats av ditt interaktiva konto, och en uppgift som körs som någon annan kan inte heller. Namnet måste också stämma exakt med profilen, inklusive eventuellt domänprefix i användarfältet.

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

Det första kommandot listar namnen som Windows känner till. Det andra ringer upp med namn med de cachelagrade autentiseringsuppgifterna, och det tredje är den form som en PowerShell-åtgärd bör använda, eftersom den väntar och returnerar ett värde som uppgiften kan registrera.

Läs slutkoden i stället för fönstret

En uppgift som startar en process utan att vänta rapporterar framgång så snart processen finns. För ett samtal som kan misslyckas en sekund senare är den domen värdelös. Att vänta på slutkoden gör åtgärden till ett riktigt resultat. Uppgiftshistoriken ensam visar bara att en process startade, aldrig att en tunnel kom upp.

Logga värdet med en tidsstämpel vid varje körning. Ett enstaka misslyckande efter ett avbrott är normalt, medan tre misslyckanden i rad med samma kod pekar på autentiseringsuppgifterna eller profilen och inte på nätverket. Det mönstret är det som gör historiken värd att läsa.

Lägg till ett kort upprepningsintervall som försäkring, och var tydlig med hur det samverkar med en händelseutlösare. En upprepning varje minut i fem minuter ger det andra försöket när internet kom tillbaka tillsammans med tunneln, och under Inställningar, "Om uppgiften redan körs gäller följande regel", vill uppgiften "Starta inte en ny instans" så att en upprepning inte överlappar ett samtal som fortfarande pågår. Utan den inställningen kan två rasdial-processer tävla om samma port och den andra misslyckas utan någon användbar anledning.

Bevisa återhämtningsvägen

Testa båda riktningarna med avsikt. Koppla ner manuellt och bekräfta att ingen ny uppringning sker, inaktivera sedan nätverksadaptern och bekräfta att uppgiften utlöses när länken kommer tillbaka. De två testerna täcker undertryckningsregeln och det verkliga felet, och ingenting annat gör det.

Läs sedan uppgiftshistoriken i stället för anslutningsikonen. Historiken registrerar när uppgiften kördes, vilket konto den använde och vad åtgärden returnerade, och det är beviset som behövs när samma maskin faller igen nästa månad.

Relaterade artiklar