SYSTEM 작업은 어떤 전화번호부에서 VPN 프로필을 찾는가?

VPN 프로필은 설정에 그대로 있는데 예약된 작업은 여전히 연결을 찾을 수 없다고 보고합니다. 손상된 것은 없습니다: 네이티브 Windows VPN 저장소는 프로필이 모든 사용자용으로 만들어지지 않는 한 사용자별이며, 작업은 자신의 principal이 지정한 계정으로 실행됩니다. 보통 작업은 당신의 프로필이 한 번도 들어 있지 않은 전화번호부를 읽고 있습니다. 두 명령과 작업 설정 하나면 이를 증명할 수 있고, 누군가 연결을 다시 만들기 전에 실행할 가치가 있습니다.

두 저장소가 같은 프로필 이름을 담는다

네이티브 Windows VPN 프로필은 그것을 만든 계정의 저장소에 있습니다. 전역 저장소는 다른 전화번호부이고, 프로필이 상승된 세션에서 모든 사용자용 스위치로 만들어졌을 때만 채워집니다. 둘 다 같은 이름의 프로필을 담을 수 있고, 어느 것도 다른 쪽의 보기가 아닙니다.

같은 세션에서 두 저장소를 모두 읽고 반환되는 이름을 비교하세요. 스위치는 전역 저장소를 선택하며, 그것을 읽으려면 보통 상승된 세션이 필요합니다:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

첫 번째 명령이 프로필을 나열하고 두 번째가 나열하지 않으면, 문제는 인증이 아니라 멤버십이므로 다른 계정으로 실행되는 작업에는 자격 증명 변경이 도움이 되지 않습니다. 둘 다 나열하면 저장소가 원인이 아니며 다음 섹션이 적용됩니다. 그 한 번의 비교로 이런 티켓의 절반이 정리됩니다. 두 사실이 없으면 답은 의미가 없으므로 어느 저장소가 응답했는지, 어떤 계정으로 검사를 실행했는지 기록하세요.

자격 증명보다 먼저 작업의 principal을 읽어라

작업을 열어 principal을 읽으면, 그 작업이 어떤 저장소를 볼 수 있는지 알 수 있습니다. SYSTEM으로 실행하도록 설정된 작업은 추가 권한이 있는 당신의 계정이 아닙니다: 자체 프로필을 가지며 로그인해 있을 때 만든 사용자별 전화번호부에 접근할 수 없습니다. 서비스 계정도 정확히 같은 방식으로 동작합니다.

로그인 여부와 무관하게 실행하는 옵션도, 작업에 자격 증명을 빌릴 대화형 세션이 없게 되므로 이것을 바꿉니다. 작업이 whoami을 파일에 쓰게 하고 추측하지 말고 답을 읽으세요.

자신의 터미널에서 나온 진단은 당신의 계정이 보는 것을 보여줄 뿐이므로 이 문제에 대해 아무것도 말해 주지 않습니다. 작업의 ID로, 그에 대해 가진 승인된 절차를 통해 비교를 실행하세요. 관리자 콘솔에서 붙여 넣은 출력은 다른 데이터 세트이며 더 특권적인 것이 아닙니다. 그런 절차가 없다면 작업이 스스로 답을 기록해야 하며, 마지막 섹션이 그것을 설정합니다.

프로필을 찾는 것은 로그인하는 것이 아니다

모든 사용자용 프로필은 구성을 더 넓게 보이게 합니다. 그것은 만든 계정의 저장된 암호를 옮기지 않으며, 당신의 사용자 프로필에 저장된 개인 키를 다른 계정에 넘기지 않습니다. 가시성과 사용 가능한 자격 증명은 별개의 두 시험이며, 첫 번째를 통과한다고 두 번째에 대해 말할 수 없습니다.

작업이 이제 프로필을 찾지만 인증에서 실패한다면 그것은 진전이며 그 단계는 기록에 속합니다. 연결 이름을 다시 만들지 말고 인증서를 컴퓨터 저장소로 옮기거나 배포 자체의 메커니즘으로 비밀을 제공하세요. 다시 만들면 더 새로운 타임스탬프로 같은 실패가 생깁니다. Microsoft는 두 범위를 문서화합니다 그 사이에서 cmdlet 스위치가 선택합니다.

비대화형 과제가 그 단계 뒤의 함정입니다. PIN 프롬프트나 일회용 코드에는 데스크톱이 없는 작업이 답할 수 없으므로, 손으로 완벽하게 연결하는 프로필이 자동화 아래에서는 쓸 수 없을 수 있습니다.

작업 기록에 필요한 네 개의 필드

결과를 결정하는 값은 그중 세 개가 보통 암묵적으로 남으므로 한곳에 모아 두세요. 기록에는 네 줄이 필요합니다:

• 작업 경로: 작업이 실행하는 스크립트 또는 실행 파일이며, 다른 계정에서 다르게 해석되는 바로 가기가 아닙니다.
• 프로필 이름: 두 저장소가 다른 서버를 가리키는 같은 이름을 담을 수 있으므로 정확한 문자열입니다.
• Principal: 작업이 실행되는 계정, 그리고 대화형 세션이 있는지 여부.
• 인증 방법: 그 principal이 실제로 완료할 수 있는 것, 예를 들어 사용자 프로필의 키가 아니라 컴퓨터 저장소의 인증서.

그 네 줄은 티켓이 실제로 묻는 질문, 즉 자동화가 어떤 구성을 사용했는가에 답합니다. 원래 작성자가 이름이 왜 중요했는지 설명할 수 없을 때 다시 만드는 작업에서도 살아남습니다. 그것들이 없으면 같은 실패가 다음 배포 후에 돌아오고 다시 같은 시간을 소모합니다.

작업이 도달한 단계를 찾아라

마지막 실행 결과에서 추측하지 말고, 짧은 래퍼로 작업을 계측해 ID, 볼 수 있는 저장소, 연결 결과를 한곳에 기록하세요.

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

연결 명령은 자체 오류를 인쇄하며, 보통 일반 작업 실패보다 명확합니다. 쿼리는 principal과 마지막 결과 코드를 나란히 반환하므로 ID와 결과가 한 화면에 보입니다. 그 두 사실이 다음 단계가 저장소 변경인지 자격 증명 변경인지 결정합니다.

마지막으로, 사용자가 로그인한 뒤 연결하는 작업을 장치 터널이나 지원되는 로그인 전 워크플로와 구분하세요. 하나의 프로필을 공유하는 것은 둘 중 어느 쪽의 설계도 아니며, principal 필드가 세 가지 중 무엇을 만들었는지 알려줍니다. 로그인 전에 연결이 있어야 한다면 사용자별 프로필 저장소는 고칠 계층이 아닙니다.