Стартиране на задача при свързване с VPN: събитие, периодично запитване или идентификационни данни?
Скрипт за влизане се изпълнява преди да съществува тунелът. Сравнете тригер за мрежово събитие, периодично запитване на ресурс и запазени идентификационни данни по това какво гарантира всяко.
Скрипт за влизане, който свързва диск или стартира задача за синхронизация, се изпълнява преди тунелът да получи адрес, затова се проваля тихо и потребителят го поправя на ръка всяка сутрин. Windows не предлага на повечето клиенти обратно извикване при свързване за всеки VPN, но записва промяната в мрежата и този запис може да стартира работа в точния момент. Изборът е между реакция на този запис, периодично запитване на ресурса и премахване на подканата, която направи провала видим.
Сравняването на трите механизма по това какво гарантират е по-добро от подреждането им по елегантност. Всеки се проваля различно и режимът на провал е това, с което живеете след това.
Защо влизането стартира твърде рано
Влизането и стартирането се изпълняват преди VPN адаптерът да получи адреса си, затова свързване на диск, вътрешен URL или връзка с база данни, опитани в този момент, нямат нито маршрут, нито резолвер. Заявката се проваля и сесията остава в състояние, което потребителят трябва да поправи ръчно. Преместването на същия скрипт в папката за автоматично стартиране не променя нищо, защото проблемът с подредбата се мести с него. Тригерът трябва да е промяна в мрежата, а не събитие на сесията.
Планирана задача при влизане с произволно закъснение изглежда като поправка, а всъщност е догадка. Работи при бърза връзка и се проваля при бавна, което е най-безполезният вид надеждност.
Три механизма в сравнение
Механизмите се различават по това какво наблюдават, колко бързо реагират и какво правят при повторно свързване по-късно през деня. Таблицата ги сравнява по тези три точки, а не по това колко умно звучи всеки.
| 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 |
Четете таблицата ред по ред. Тригерът за събитие е най-бърз и най-шумен, защото Windows записва всяка мрежа, включително Wi-Fi в кафенето, затова действието трябва да провери ресурса, преди да прави каквото и да е. Периодичното запитване е по-бавно и по-точно, защото успява точно когато споделената папка или името на хоста отговорят, и не се нуждае от знание кой клиент е инсталиран. Запазените идентификационни данни изобщо не са конкурентна опция: те премахват подканата за парола, което е втора и независима причина свързването на диск при влизане да се проваля.
Изборът между първите две се свежда до това дали на клиента има използваемо събитие. Където има, събитие плюс проверка на ресурса е по-добрата настройка по подразбиране.
Изградете тригера за събитие правилно
Записът се намира в журнала Microsoft-Windows-NetworkProfile/Operational, а ID 10001 отбелязва мрежа, която току-що се е свързала. Създайте задачата с тригер „При събитие“, насочен към този журнал, това име на доставчик и този идентификатор. Всяка мрежа, към която машината се присъедини, ще го задейства, затова действието се нуждае от предпазно условие, а не от предположение, и трябва да работи само докато потребителят е влязъл, ако работата засяга свързани дискове.
Предпазното условие трябва да проверява това, което задачата наистина изисква, например път до споделена папка или порт на услуга, и да излиза тихо, когато е недостъпно. Проверката на името на адаптера не е достатъчна, защото клиентът може да използва един адаптер в няколко профила. Тихото излизане пази журнала четим и предотвратява буря от повторни опити срещу мрежа, която никога няма да предостави ресурса.
Проверете дали задачата работи в точния момент
Докажете времето, а не конфигурацията. Командите по-долу показват дефиницията на задачата, последните събития на мрежовия профил и дали ресурсът е достъпен от акаунта, под който работи задачата. Изпълнете ги след истинско повторно свързване, а не след ръчно стартиране.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiЗапис в историята на задачата, който съществува, докато никое мрежово събитие не съвпада, означава, че тригерът е грешен, а не действието. Ако събитията се появяват, а задачата не, задачата може да работи под акаунт, който не вижда ресурса, и изходът на акаунта е следата. Проверка на ресурса, която минава, докато свързването все още липсва, сочи към контекста на сесията, а не към свързаността. Всяко от тези три наблюдения ви води към различно решение.
Записвайте по един ред в журнала за всяко изпълнение с адреса, резултата за ресурса и изхода. Следващият провал тогава ще покаже дали задачата е стартирала рано, стартирала е в грешната мрежа или изобщо не е стартирала.