VPN 로그인이 느린 이유: 프로필, 리디렉션 또는 오프라인 파일

노트북은 사무실에서는 약 사십 초 만에 로그인되고 집에서는 몇 분이 걸리는데, 그 사이에 아무도 정책을 바꾸지 않았습니다. 바뀐 것은 비슷해 보이지만 다르게 동작하는 세 기능 아래의 네트워크 경로입니다. 로밍 프로필은 레지스트리 상태와 프로필 폴더를 로드하고, 폴더 리디렉션은 셸 폴더를 서버 공유로 지정하며, 오프라인 파일은 해당 네트워크 데이터의 캐시를 유지합니다. 세 가지 모두 로그인에 시간을 더할 수 있지만 보통 그중 하나만 원인입니다.

세 번의 대기와 세 가지 원인

로밍 프로필은 참여 컴퓨터 사이에서 사용자 설정이 사람을 따라가게 하는 기능이며, 로드는 세션 초반에 일어납니다. 로그인할 때 사용자의 레지스트리 하이브와 프로필 폴더가 복사되거나 병합되고, 로그아웃할 때 다시 기록됩니다. 이 작업은 동기 방식이므로 프로필 공유로 가는 느린 경로는 느린 파일 복사가 아니라 느린 데스크톱처럼 느껴집니다.

폴더 리디렉션은 다른 메커니즘입니다. 선택한 셸 폴더(흔한 예는 문서)를 지원되는 네트워크 위치로 옮기고 그대로 둡니다. 데이터가 그 안에 없으므로 프로필은 작게 유지될 수 있고, 비용은 셸이나 애플리케이션이 그 폴더를 건드릴 때 발생합니다.

오프라인 파일은 해당 네트워크 파일에 로컬 캐시와 동기화를 추가합니다. 이것은 다른 질문, 즉 서버에 연결할 수 없을 때 무슨 일이 일어나는지에 답하며, 캐시가 오래되면 로그인과 로그아웃 시 동기화에 시간을 쓸 수 있습니다. 세 가지를 하나의 설정으로 취급하는 것이 한 방향으로는 느리고 다른 방향으로는 쓸모없는 정책을 만듭니다.

실제로 무엇이 기다리는지 측정하기

프로필이 어디에 있고 서버 경로에서 로드되는지부터 확인한 다음, 세션이 건드리는 각 공유에서 디렉터리 목록 시간을 측정하세요. LAN에서 밀리초 단위로 응답하는 공유도 터널과 바쁜 파일 서버를 거치면 몇 초가 걸릴 수 있기 때문입니다.

이 두 사실은 어떤 정책 감사보다 빠르게 문제를 좁히며, 수집하는 데 구성 변경이 필요하지 않습니다. 영향을 받는 노트북에서 실행하고, 공유 옆에 있는 서버에서 실행하지 마세요.

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

프로필 경로가 로컬이고 리디렉션된 폴더가 하나만 서버를 가리킨다면, 헬프데스크 티켓이 무엇을 말하든 프로필 로드는 기다림이 아닙니다. 프로필 경로가 원격이고 목록에 몇 초가 걸린다면 로그인은 그 공유를 기다리는 것이며, 해결책은 데스크톱 자체가 아니라 경로나 프로필 크기에 관한 것입니다. 이 순서로 숫자를 읽으면 논의는 보통 거기서 끝납니다.

연결은 대기가 시작된 뒤에 도착한다

데스크톱에서 시작하는 사용자 터널은 프로필이 로드된 훨씬 뒤에 나타나므로 느렸던 단계를 도울 수 없습니다. Windows는 사용할 수 없는 경로를 인지하고 캐시된 자격 증명과 로컬 프로필로 대체하며, 세션은 결국 열립니다. 그래서 캐시된 프로필이 있으면 같은 노트북이 집에서 첫 로그인에는 몇 분, 두 번째에는 몇 초가 걸릴 수 있습니다. 기다림은 실제이지만 그 시점에 필요한 연결은 존재하지 않습니다.

이를 고치려면 프로필을 조정하는 것이 아니라 연결을 더 앞으로 옮겨야 합니다. 컴퓨터 인증을 사용하는 컴퓨터 터널이나 로그온 전 연결은 사용자가 로그인하기 전에 경로를 설정하지만, 자체 인증서 수명 주기와 자체 방화벽 규칙이 필요합니다. 캐시된 자격 증명은 설계의 나머지 절반이며, 이전에 로그인한 적이 있는 계정에만 작동합니다.

구성 요소가 아니라 순서를 테스트하세요. 완전히 로그아웃하고 원격 사용자가 하듯 터널을 시작한 뒤, 자격 증명 프롬프트에서 사용 가능한 데스크톱까지 로그인 시간을 측정하세요.

문서를 프로필 밖에 두기

프로필 공유는 큰 문서 모음에 부적합한 위치이며, Microsoft의 로밍 프로필 배포 가이드가 프로필 저장소와 리디렉션된 폴더 공유를 분리하는 이유도 바로 그것입니다. 몇 기가바이트의 문서 폴더를 담은 프로필은 로그인과 로그아웃마다 느려지고, 누군가 측정할 때까지 크기가 조용히 늘어납니다.

데이터를 보관하는 폴더를 리디렉션하고, 프로필에는 설정을 남기세요. 브라우저 캐시와 애플리케이션 임시 데이터처럼 다시 만들 수 있는 캐시는 전송해도 시간만 늘고 사용자가 보는 것은 아무것도 바뀌지 않으므로 제외하세요. 사서함 데이터와 기타 애플리케이션 저장소는 로밍 경로가 아니라 애플리케이션이 지원하는 위치에 두세요.

프로필 공유를 오프라인에서 사용할 수 있게 하지 마세요. 오프라인 파일은 해당 데이터 공유에 속하며, 양방향으로 동기화되는 캐시된 프로필 하이브는 발생을 기다리는 손상 보고서입니다.

해결됐다고 말하기 전에 네 가지 시나리오 모두 확인하기

사무실에서 빠른 로그인은 거의 아무것도 증명하지 않습니다. 설계는 사무실 접속, 터널을 통한 재택 작업, 연결 없는 작업, 사무실 복귀를 모두 견뎌야 하는데, 동기화 충돌이 나타나는 것은 네 번째 경우이기 때문입니다. 같은 네 가지를 하나의 통제된 계정과 실제 애플리케이션으로 측정하고 숫자를 적어 두세요.

프로필 서비스 로그와 그로부터 나온 정책 집합을 관리 워크스테이션에서가 아니라 영향을 받은 세션에서 수집하세요.

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

그 시간을 사무실 기준선과 전송되는 데이터의 크기와 비교하세요. 작은 프로필과 빠른 공유에도 로그인에 여전히 일 분이 걸린다면 그것은 프로필 문제가 아니며, 다음으로 볼 곳은 그룹 정책 처리나 네트워크를 기다리는 로그온 스크립트입니다. 차이가 거기에 있다면 프로필은 애초에 문제가 아니었습니다. 폴더 정책을 바꾸거나 캐시를 지우기 전에 동기화와 복구 가능한 백업은 서로 다른 보장임을 염두에 두고 동기화되지 않은 작업이 보존되는지 확인하세요.