이 글의 목적은 Windows 서버 환경에서 RDP 접속 시 “Remote Desktop License Servers available” 관련 오류가 발생하며 라이선스 서버에 연결되지 않는 문제를 체계적으로 진단하고, 서버·클라이언트 라이선스 구성을 재설정하여 안정적으로 원격 데스크톱 서비스를 복구하는 방법을 정리하는 것이다.
1. RDP 라이선스 서버 연결 불가 증상 정리
RDS(Remote Desktop Services) 라이선스 서버 연결 불가 오류는 단순한 포트 차단 문제가 아니라, 라이선스 서버 역할·구성·클라이언트 캐시·유예기간(Grace Period) 등 여러 요소가 겹쳐서 나타나는 경우가 많다.
대표적인 메시지는 다음과 같다.
- The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license.
- The remote session was disconnected because there are no Remote Desktop client access licenses available for this computer.
- Remote Desktop licensing mode is not configured.
- 이 컴퓨터의 원격 데스크톱 서비스 라이선스 유예 기간이 만료되었다는 경고 풍선 알림
운영 환경에 따라 증상은 다음과 같이 체감된다.
- 수개월 이상 정상 사용 후, 어느 날 특정 시점부터 신규 연결이 모두 차단되는 현상
- 일부 사용자만 접속 실패하고, 다른 사용자는 접속이 되는 비일관적 현상
- RDSH(Session Host) 서버는 정상 작동하는 것처럼 보이지만, 클라이언트 쪽에서만 오류 메시지를 출력하는 경우
| 구분 | 오류 메시지 예시 | 주요 원인 후보 |
|---|---|---|
| 라이선스 서버 미구성 | The remote session was disconnected because there are no Remote Desktop License Servers available… | RDS 배포에서 라이선스 서버 지정 누락, 라이선스 모드 미설정, 라이선스 역할 미설치 |
| 유예기간 만료 | Remote Desktop licensing mode is not configured / 유예 기간이 만료되었다는 경고 | Grace Period 만료, 라이선스 서버 활성화 또는 CAL 설치 미완료 |
| 클라이언트 캐시 오류 | The remote session was disconnected because the local computer's client access license could not be upgraded or renewed. | MSLicensing 레지스트리 손상, 이전 서버 정보가 남아 있는 경우 |
| 네트워크/서비스 문제 | 라이선스 서버를 사용할 수 없다는 경고 | RD Licensing 서비스 중지, 방화벽·RPC 통신 차단, DNS 해석 오류 |
2. RDS 라이선스 구조와 동작 원리 이해
정확한 재설정을 위해서는 RDS 라이선스 구조를 이해해야 한다.
2.1 RDS 구성 요소
- RD Session Host 서버 : 사용자가 실제로 접속하는 서버이다.
- RD Licensing 서버 : CAL(Client Access License)을 발급하고 관리하는 역할을 수행하는 서버이다.
- RD Connection Broker, RD Web Access 등 : 규모가 큰 배포에서 추가로 사용하는 역할이다.
소규모 환경에서는 하나의 서버에 RD Session Host와 RD Licensing 역할을 동시에 탑재하는 구성이 일반적이다.
2.2 라이선스 모드와 CAL 유형
- Per Device : 디바이스(PC·단말) 기준으로 라이선스를 부여하는 모드이다.
- Per User : 사용자 계정 기준 라이선스이다. 감사나 라이선스 준수는 관리자의 책임 하에 운영되는 구조이다.
RDSH 서버에는 반드시 위 두 모드 중 하나를 선택해야 하며, 실제로 구입한 CAL 종류와 일치시켜야 한다.
2.3 120일 Grace Period
새롭게 RDS 역할을 설치하면 일정 기간(일반적으로 120일) 동안은 라이선스 서버가 없어도 접속이 가능하다. 이 기간이 만료되면 “라이선스 서버를 사용할 수 없음” 오류가 발생하고 새로운 세션이 차단된다. 이때 올바른 방법은 정식 라이선스 서버를 구성하고 CAL을 설치·연결하는 것이다.
주의 : Grace Period 레지스트리를 삭제하여 유예기간을 재시작하는 방법은 기술적으로 가능하지만, 정식 라이선스를 우회하는 용도로 사용해서는 안 된다. 정식 CAL을 구매·배포한 상태에서 구성이 꼬였을 때 복구용으로만 사용해야 한다.
3. 서버 측 RDS 라이선스 서버 연결 불가 점검 순서
다음 순서대로 서버 측 구성을 점검하면 원인을 빠르게 좁힐 수 있다.
3.1 RD Licensing 역할 설치 및 서버 활성화 확인
- Windows Server에서 서버 관리자(Server Manager)를 연다.
- 역할 및 기능 추가 메뉴에서 원격 데스크톱 서비스 > Remote Desktop Licensing 역할이 설치되어 있는지 확인한다.
- 설치되어 있지 않다면 역할을 추가하고, 설치 후 Remote Desktop Licensing Manager를 실행한다.
- 라이선스 서버를 선택하고 Activate Server를 통해 서버를 활성화한다.
- 구입한 CAL을 종류(Per User/Per Device)와 버전에 맞게 등록한다.
3.2 RDS 배포에서 라이선스 서버 및 라이선스 모드 지정
RDS 배포 환경에서는 배포 수준에서 라이선스 서버와 모드를 명시해야 한다.
- 서버 관리자에서 원격 데스크톱 서비스(Remote Desktop Services) 메뉴를 선택한다.
- 배포 개요(Overview)에서 배포 속성(Edit Deployment Properties)을 연다.
- RD Licensing 탭에서 다음을 설정한다.
- 라이선스 모드: Per User 또는 Per Device 중 실제 계약에 맞게 선택한다.
- 라이선스 서버: RD Licensing 역할이 설치된 서버를 추가한다.
- 적용 후 몇 분 정도 기다린 뒤, RD Licensing Diagnoser를 열어 오류가 사라졌는지 확인한다.
3.3 단독 Session Host 서버에서 로컬 그룹 정책으로 라이선스 지정
배포 구성이 아닌 단독 RDSH 서버(작은 환경)에서 자주 쓰는 방법이다.
- gpedit.msc를 실행한다.
- 다음 경로로 이동한다.
- 컴퓨터 구성 > 관리 템플릿 > Windows 구성 요소 > 원격 데스크톱 서비스 > 원격 데스크톱 세션 호스트 > 라이선스
- 다음 두 정책을 구성한다.
- 원격 데스크톱 라이선스 서버 사용 지정 : 사용으로 설정하고 라이선스 서버 이름(FQDN 또는 NetBIOS)을 입력한다.
- 원격 데스크톱 라이선스 모드 설정 : Per User 또는 Per Device로 설정한다.
- 변경 후 관리자 권한 명령 프롬프트에서 다음을 실행한다.
gpupdate /force - RDSH 서버를 재부팅하거나, 최소한 Remote Desktop Services 관련 서비스를 재시작한다.
3.4 RD Licensing 서비스 및 방화벽 점검
구성이 맞더라도 라이선스 서버가 실제로 통신할 수 없으면 오류가 발생한다.
- 서비스 상태
- 서비스 콘솔에서 Remote Desktop Licensing, Remote Desktop Services 서비스가 실행 중인지 확인한다.
- 중지되어 있으면 자동 시작으로 변경하고 시작한다.
- 네트워크 및 방화벽
- 라이선스 서버 이름이 DNS에서 올바르게 해석되는지
nslookup 라이선스서버이름으로 확인한다. - RDSH 서버와 라이선스 서버 간에 TCP 135(RPC), 3389, 동적 RPC 포트가 차단되지 않았는지 방화벽 규칙을 확인한다.
- 라이선스 서버 이름이 DNS에서 올바르게 해석되는지
3.5 GracePeriod 레지스트리 삭제를 통한 유예기간 재설정 (선택)
정상적인 라이선스 구성과 CAL 설치를 완료했음에도 RDSH 서버가 유예기간 만료 상태에서 벗어나지 못할 때, Grace Period 레지스트리를 삭제하여 내부 타이머를 초기화하는 방법을 사용할 수 있다.
주의 : 이 방법은 라이선스 서버와 CAL이 이미 준비된 상태에서 구성 오류를 복구하기 위한 수단으로만 사용하는 것이 바람직하다. 라이선스 구매 없이 반복적으로 유예기간을 초기화하는 것은 라이선스 정책 위반이 될 수 있다.
- 문제가 되는 RDSH 서버에 관리자 권한으로 로그인한다.
- regedit를 관리자 권한으로 실행한다.
- 다음 경로로 이동한다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod - 해당 키 안에
L$RTMTIMEBOMB로 시작하는 REG_BINARY 항목이 존재한다. - 기본 권한으로는 삭제가 되지 않으므로, 항목의 권한을 변경한다.
- 마우스 오른쪽 클릭 → 권한 → 고급 → 소유자 변경 후 Administrators로 지정한다.
- Administrators 그룹에 대한 전체 제어 권한을 부여한다.
L$RTMTIMEBOMB항목을 삭제한다.- 서버를 재부팅하고, RD Licensing 구성과 CAL 상태를 다시 확인한다.
4. 클라이언트 측 RDP 라이선스 캐시(MSLicensing) 재설정
서버 구성이 모두 정상인데 특정 클라이언트만 접속이 안 되는 경우, 대부분은 해당 PC의 RDP 라이선스 캐시 레지스트리가 손상되었거나 이전 서버 정보가 남아 있는 상황이다. 이때는 MSLicensing 키를 삭제하여 클라이언트 라이선스를 재발급 받게 하면 해결되는 경우가 많다.
4.1 레지스트리 편집기를 이용한 수동 삭제
- 문제가 발생하는 클라이언트 PC에 관리자 권한으로 로그인한다.
- regedit를 관리자 권한으로 실행한다.
- 수정 전 전체 레지스트리를 백업하거나, 적어도 해당 키를 내보내기 한다.
- 다음 경로로 이동한다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing MSLicensing키 전체를 삭제하거나, 하위Store키의 값을 모두 삭제한다.- 레지스트리 편집기를 종료하고 PC를 재부팅한다.
- 이후 처음 한 번은 RDP 클라이언트를 관리자 권한으로 실행하여 라이선스 캐시가 다시 생성되도록 한다.
주의 : MSLicensing 키를 삭제하면 해당 클라이언트가 보유하던 RDS Per Device 라이선스 정보도 함께 초기화된다. 라이선스 서버에서 Per Device CAL이 부족한 상황에서는 오류가 다시 발생할 수 있다.
4.2 .reg 파일을 이용한 일괄 초기화 예시
여러 클라이언트에 동일하게 적용해야 하는 경우 .reg 파일로 배포하면 편리하다. 예시는 다음과 같다.
Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing]
위 내용을 텍스트 파일에 저장한 후 확장자를 .reg로 변경하여 관리자 권한으로 실행하면 된다. GPO 시작 스크립트, 로그인 스크립트 등으로 배포하는 것도 가능하다.
4.3 비 Windows 클라이언트의 라이선스 캐시
일부 macOS·리눅스 RDP 클라이언트는 자체 설정 폴더에 터미널 서버 라이선스 파일을 저장한다. 이 경우 RDS 라이선스 오류가 반복되면 해당 클라이언트의 캐시 파일을 삭제한 다음 다시 접속을 시도해야 한다. 클라이언트 종류에 따라 경로가 다르므로, 각 RDP 클라이언트의 문서를 확인하는 것이 안전하다.
5. 이벤트 로그와 RD Licensing Diagnoser 활용
RDS 라이선스 문제를 정확히 진단하려면 이벤트 뷰어와 RD Licensing Diagnoser를 적극적으로 사용하는 것이 중요하다.
5.1 RD Licensing Diagnoser 사용 방법
- 라이선스 서버 또는 RDSH 서버에서 Server Manager를 열고, 도구 > RD Licensing Diagnoser를 실행한다.
- 상단에서 현재 진단 대상 서버를 선택한다.
- 아래 메시지를 확인하여 다음 항목을 점검한다.
- 라이선스 서버가 활성화되어 있는지
- 해당 서버에 충분한 CAL이 있는지
- 라이선스 모드가 올바르게 구성되어 있는지
- 유예기간 만료 여부
- 표시되는 권장 조치(Recommended actions)를 참고하여 설정을 수정한 뒤, 다시 진단을 실행한다.
5.2 이벤트 뷰어에서 로그 확인
이벤트 뷰어에서는 라이선스 관련 오류 코드를 보다 세밀하게 확인할 수 있다.
- Applications and Services Logs > Microsoft > Windows > TerminalServices-Licensing
- Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager
주요 이벤트 ID와 의미를 표로 정리하면 다음과 같다.
| 이벤트 ID (예시) | 설명 요약 | 대응 방향 |
|---|---|---|
| 18, 22 등 | 클라이언트 라이선스를 발급할 수 없거나 갱신 실패 | MSLicensing 캐시 초기화, CAL 수량·버전 확인 |
| 4105, 4106 등 | 라이선스 서버가 라이선스를 발급하지 못함 | 라이선스 서버 활성화 상태, CAL 설치 상태, 라이선스 모드 확인 |
| 1000번대 기타 | 서비스 시작 실패, RPC 통신 실패 | 서비스 상태, 방화벽, 네트워크 경로 점검 |
6. 온프렘 vs 클라우드 환경별 RDS 라이선스 점검 포인트
온프렘 AD 도메인 환경과 클라우드 VM 환경에서는 라이선스 오류의 전형적인 패턴이 조금 다르다.
6.1 온프렘 도메인 환경
- AD 사이트·서브넷 구성에 따라 특정 RDSH가 잘못된 라이선스 서버를 참조하는 경우가 있다.
- GPO가 여러 개 중첩되어 적용되면서 라이선스 서버 이름·모드가 뒤섞이는 사례가 있다.
- 구형 Windows Server(RDS CAL)와 최신 OS 조합에서 CAL 버전 호환성을 반드시 확인해야 한다.
6.2 클라우드 VM (예: IaaS 기반 Windows Server)
- 단순 관리용 RDP 두 세션만 사용하는 경우에는 RDS 역할이 필요 없고, 일반 “관리용 원격 데스크톱”만 이용하면 된다.
- 실수로 RDS 역할을 추가하고 다수 사용자 접속에 사용하다가 120일 후 라이선스 오류가 발생하는 사례가 많다.
- 이 경우 RDS 역할을 제거하고 기본 RDP 두 세션만 사용하는 방향으로 전환하거나, 정식 RDS CAL을 구매하여 온전한 RDS 환경으로 마이그레이션해야 한다.
| 항목 | 온프렘 RDS 환경 | 클라우드 VM 환경 |
|---|---|---|
| 주요 문제 | GPO 충돌, 다수 라이선스 서버 혼재, CAL 버전 혼합 | RDS 역할 추가 후 유예기간 만료, 라이선스 서버 미구성 |
| 해결 전략 | AD·GPO 정리, 중앙 라이선스 서버 통합 운영 | RDS 역할 제거 또는 정식 RDS 구축 후 CAL 적용 |
| 운영 팁 | 라이선스 서버 최소 2대 이중화 권장, 정기 진단 | 관리 목적만이면 RDS 역할 설치를 피하고 기본 RDP로 운영 |
7. 대량 환경에서의 자동화·운영 팁
수십~수백 대의 클라이언트와 여러 RDSH 서버를 운영하는 환경에서는 개별 PC에 직접 접속하여 조치하는 방식은 비효율적이다. 다음과 같은 자동화 기법을 활용하면 관리 효율을 높일 수 있다.
- GPO 시작 스크립트로 MSLicensing 초기화 .reg 파일을 특정 OU의 PC에만 일괄 적용
- PowerShell Remoting을 활용해 다수 RDSH 서버의 GracePeriod 키 상태, Licensing Core 관련 레지스트리 값을 점검
- 모니터링 시스템에서 Licensing 관련 이벤트 ID를 정기적으로 수집·알림 설정
주의 : 자동화 스크립트로 레지스트리 삭제·수정 작업을 할 때는 테스트 환경에서 충분히 검증한 뒤 단계적으로 적용해야 한다. 실수로 잘못된 키를 삭제하면 부팅 불능 등 심각한 장애로 이어질 수 있다.
8. 자주 발생하는 실수와 예방 전략
- 실수 1 : RDS 역할을 시험 삼아 설치하고, 유예기간 동안 잘 된다고 그대로 운영하다가 4개월 후 전면 접속 불가 상황이 발생하는 경우가 많다.
→ 예방 : RDS를 상시 서비스로 사용할 계획이라면, 초기에 라이선스 설계를 완료하고 CAL을 확보한 후 운영을 시작해야 한다. - 실수 2 : Per User CAL만 구매했는데, RDSH 서버 라이선스 모드를 Per Device로 설정하여 예기치 못한 라이선스 오류가 발생하는 경우이다.
→ 예방 : 실제 계약된 CAL 유형과 서버 설정을 표로 관리하고, 변경 시 이력 관리 체계를 유지해야 한다. - 실수 3 : 클라이언트 PC 이미지를 복제하면서 MSLicensing 레지스트리를 그대로 복사하여, 여러 PC가 동일한 Device 라이선스를 공유하려다 오류가 발생하는 사례이다.
→ 예방 : 마스터 이미지 생성 시 MSLicensing 키를 비워둔 상태로 캡처하거나, 배포 후 초기 스크립트로 자동 삭제하도록 설계한다. - 실수 4 : 라이선스 서버를 교체하거나 OS를 재설치하면서, 기존 CAL 재할당 절차 없이 새로운 서버에서만 구성을 진행하여 중복 또는 미반영 상태를 만드는 경우이다.
→ 예방 : 라이선스 서버 마이그레이션 절차를 문서화하고, 벤더 정책에 따라 CAL 이동·재할당 절차를 준수해야 한다.
FAQ
Q1. 라이선스 서버 1대만 있어도 되는가?
기술적으로는 1대로도 운영 가능하다. 그러나 라이선스 서버는 모든 RDSH 접속의 허브 역할을 하기 때문에 장애 시 전체 서비스 중단으로 이어진다. 중·대규모 환경이라면 최소 2대 이상의 라이선스 서버를 구성하고, RDSH 서버에서 두 대 모두를 지정하는 구성을 권장한다.
Q2. Per User와 Per Device 중 무엇을 선택하는 것이 좋은가?
공용 PC에 여러 사용자가 번갈아 로그인하는 콜센터·PC방·제조 현장 단말 등에서는 Per Device가 효율적이다. 반대로 사용자가 노트북·데스크톱·태블릿 등 여러 디바이스에서 접속하는 지식근로 환경에서는 Per User가 관리 측면에서 유리하다. 조직의 사용 패턴을 분석해 가장 단순한 모델을 선택하는 것이 운영 비용을 줄이는 핵심이다.
Q3. GracePeriod 레지스트리를 삭제했는데도 라이선스 서버 연결 오류가 계속된다.
이 경우는 단순히 유예기간 문제만이 아니라, 라이선스 서버 활성화·CAL 설치·라이선스 모드 설정 등 기본 구성이 불완전한 경우가 대부분이다. RD Licensing Diagnoser와 이벤트 로그에서 경고 메시지를 다시 확인하고, 라이선스 서버가 실제로 CAL을 발급할 수 있는 상태인지 점검해야 한다.
Q4. 라이선스 서버를 다른 서버로 옮길 때 주의할 점은 무엇인가?
기존 라이선스 서버에서 CAL 정보를 백업·해제하고, 새로운 서버에서 다시 활성화하는 절차가 필요하다. 또한 모든 RDSH 서버의 GPO 또는 배포 속성에서 라이선스 서버 이름을 새로운 서버로 업데이트해야 한다. 이 작업이 누락되면 일부 서버가 여전히 이전 라이선스 서버를 참조하면서 간헐적인 접속 오류가 발생한다.
Q5. 클라이언트 MSLicensing 키를 삭제해도 되는지, 보안상 문제는 없는지 궁금하다.
MSLicensing 키에는 터미널 서비스 라이선스 관련 정보만 저장되며, 일반적으로 민감한 사용자 데이터나 인증 정보는 포함하지 않는다. 다만 레지스트리 편집 자체가 위험 작업이므로, 백업을 먼저 수행하고 삭제 후에는 즉시 정상 동작 여부를 확인하는 것이 좋다.