Ваш карыстальнік уваходзіць дома, падключае VPN і чакае адлюстравання дыска, якое раней з'яўлялася само ў офісе. Тунель падымаецца, дамен адказвае, а нічога не адлюстроўваецца. Нічога не зламана: сцэнар уваходу выконваецца пры ўваходзе, а тунель, адкрыты праз дваццаць хвілін пасля пачатку сеанса, не з'яўляецца ўваходам. Чытанне гэтых дзвюх падзей як адной прымушае людзей шукаць няспраўнасць VPN, якой не існуе.

Чатыры рашэнні ператвараюць нечаканасць у працоўны працэс, які паводзіць сябе правільна, і першае — проста ведаць, на якіх падзеях трымаецца сцэнар.

Сцэнары трымаюцца на падзеях жыццёвага цыкла, якія нельга паўтарыць

Палітыка боку камп'ютара ўжываецца пры загрузцы машыны, а палітыка боку карыстальніка — калі хтосьці ўваходзіць, у той час як фонавае абнаўленне цыклічна апрацоўвае тыя ж налады без перазапуску чаго-небудзь. Гэта абнаўленне апрацоўвае пашырэнне сцэнараў, але не запускае паўторна асобныя сцэнары, якія спрацоўваюць толькі пры запуску, выключэнні, уваходзе або выхадзе. Таму gpupdate /force можа паведаміць пра поспех, пакуль адлюстраванне ўсё яшчэ адсутнічае, і чыстае абнаўленне не з'яўляецца доказам таго, што сцэнар нешта зрабіў.

Даведнік Microsoft па апрацоўцы палітыкі праводзіць менавіта гэтую мяжу паміж апрацоўкай пашырэння і выкананнем таго, што яно змяшчае, і гэта старонка, на якую спасылаюцца, калі хтосьці настойвае, што абнаўленне павінна было паўтарыць сцэнар.

Не кожны сцэнар правальваецца і па-за сеткай. Той, што чытае толькі лакальныя або кэшаваныя матэрыялы, мог часткова атрымацца, а той, што звяртаецца да агульнага рэсурсу, правальваецца ціха і не пакідае відавочнага следу. Праверце фактычны шлях сцэнара і тое, да чаго ён дацягваецца, перш чым вінаваціць сетку. Такая ж праверка належыць любой заяве, што сцэнар не выконваецца пры ўваходзе, бо запланаваная задача або дзеянне кліента могуць рабіць працу там, дзе ніхто не глядзіць.

Прывяжыце працу да падключэння, а не да ўваходу

За фразай «сцэнар уваходу» хаваюцца тры розныя задачы: адлюстраванне дыска пасля падключэння карыстальніка, ужыванне канфігурацыі машыны да таго, як хтосьці ўвойдзе, і атрыманне абноўленай палітыкі. У іх розныя тэрміны, і толькі другая сапраўды патрабуе сувязі да ўваходу. Запішыце патрабаванне як сказ з тэрмінам, напрыклад: гэта адлюстраванне павінна існаваць на працягу хвіліны пасля ўзняцця тунеля.

Для працы, якая павінна адбыцца пасля падключэння, выкарыстоўвайце задачу, якая запускаецца падключэннем, або дзеянне падключэння, якое падтрымлівае кліент. Праверце, якую падзею кліент фактычна генеруе, бо падзею, якую ўздымае ўласны кліент Windows VPN, не ўздымае кліент трэцяга боку. Для канфігурацыі машыны, якая павінна папярэднічаць уваходу, падтрыманы адказ — тунель прылады або іншая схема да ўваходу, а не задача, якая спрацоўвае пасля з'яўлення працоўнага стала. Выконвайце працу ў той ідэнтычнасці і сеансе, якім яна патрэбна, бо адлюстраванне, створанае як SYSTEM, трапляе ў сеанс, якога карыстальнік ніколі не бачыць.

Праверце гатоўнасць перад дзеяннем і правальвайцеся гучна

Падзея падключэння можа прыйсці раней, чым DNS або файлавы сервер стануць даступнымі, таму задача павінна праверыць тое, што ёй патрэбна, а не меркаваць. Развяжыце канкрэтнае імя, паспрабуйце канкрэтнае падключэнне і паўтарыце спробу з мяжой і затрымкай: Resolve-DnsName files.corp.example у кароткім цыкле аддзяляе «яшчэ не» ад «ніколі». Пасля апошняй спробы паведаміце пра канкрэтную памылку з імем і тэкстам памылкі.

Бясконцы цыкл без журнала неадрозны ад задачы, якая ніколі не запускалася, і ён хавае розніцу паміж састарэлым уліковым запісам і правілам брандмаўэра.

Праверце чатыры рэчы, затым зрабіце гэта паўторным

Падчас пілота запісвайце чатыры назіранні замест аднаго: падзея падключэння адбылася, задача запусцілася, рэсурс адказаў, і запытанае змяненне фактычна ўжылося. Калі журнал спыняецца на «задача запусцілася», сапраўдная няспраўнасць застаецца нябачнай, колькі б вы ні чакалі. Затым выканайце gpresult /scope user /v, каб убачыць, што сеанс лічыць сваёй палітыкай, і параўнайце гэта з чаканымі наладамі. Справаздача, дзе GPO значыцца як ужыты, па-ранейшаму нічога не кажа пра адлюстраванне.

Зрабіце працу бяспечнай для паўтарэння, перш чым пашыраць яе, бо кліент перападключваецца і задача запускаецца зноў. Праверце наяўнае адлюстраванне або канфігурацыю перад стварэннем і запішыце, што знайшлі. Дубляванне працы пасля кожнага кароткачасовага перападключэння — гэта шлях, якім карысная задача ператвараецца ў інцыдэнт.

Там, дзе аўтаматычны трыгер непрыдатны, ухваленае дзеянне карыстальніка, якое запускае той жа подпісаны сцэнар, — законная схема. Яно робіць час відавочным замест таго, каб рабіць выгляд, што падзея ўваходу адбылася.

Падобныя артыкулы