1. 개요
본 문서는 Windows Server 2022 기반 멀티 도메인 환경을 구축하고 운영 점검을 수행하는 과정에서 발생한 주요 문제와 해결 과정을 정리한 기록이다.
단순히 오류를 나열하는 것이 아니라, 문제 발생 이후 원인을 분석하고 실제 운영 환경에서 어떤 방식이 더 적절한지 판단한 과정까지 포함하였다.
이번 프로젝트는 Active Directory, DNS, GPO, 파일 서버, IIS 등 여러 서비스를 함께 운영하는 구조이기 때문에, 개별 기능의 정상 동작 여부만 확인하는 것으로는 충분하지 않았다. “기능이 동작하는가”보다 **“어떤 방식으로 운영하는 것이 더 안정적이고 현실적인가”**가 더 중요한 판단 기준이 되었다.
따라서 본 문서에서는 설정 방법 자체보다는, 구축 이후 운영 점검 과정에서 확인된 문제와 그에 대한 대응, 그리고 그 과정에서 정리된 운영 기준을 중심으로 정리하였다.
2. 트러블슈팅
2.1 Server Core 원격 관리 방식 문제
■ 문제
초기에는 Server Core 환경의 서버를 MMC 기반으로 원격 관리하려고 하였다. 특히 컴퓨터 관리와 같은 범용 GUI 도구를 통해 원격으로 연결하는 방식을 먼저 시도하였다.
그러나 실제 진행 과정에서는 연결이 불안정하거나, 환경에 따라 정상적으로 열리지 않는 경우가 발생하였다.
■ 원인
문제의 핵심은 Server Core 자체가 아니라, 원격 관리 방식에 있었다.
컴퓨터 관리 계열의 MMC 원격 연결은 WMI, DCOM 등의 원격 관리 구성과 방화벽 설정에 영향을 받으며, 환경에 따라 동작 편차가 발생할 수 있다.
즉, 단순한 접속 문제가 아니라 관리 방식 자체가 Server Core 환경과 잘 맞지 않는 구조였다.
■ 해결
이후 관리 방식을 다음과 같이 재정리하였다.
- RSAT 기반 관리 도구
- 관리 공유(
\\서버명\C$) - PowerShell 원격 관리
기능별로 관리 방식을 분리하여, 목적이 명확한 도구만 사용하는 구조로 변경하였다.
■ 적용 절차
- HQ-CL-01에 RSAT 도구 설치
- 파일 작업은 관리 공유를 통해 수행
- 서버 상태 확인 및 설정 변경은 PowerShell 원격 세션 활용
■ 결과
관리 흐름이 단순해지고 안정성이 확보되었다.
- 원격 연결 안정성 확보
- 불필요한 방화벽 예외 최소화
- 기능별 관리 방식 분리
■ 운영 판단
Server Core 환경에서는 범용 GUI 기반 관리보다, RSAT + PowerShell + 관리 공유 조합이 더 현실적인 운영 방식이라고 판단하였다.
2.2 네트워크 설계와 실제 구현 간 차이
■ 문제
초기 설계에서는 HQ, USA, JP 도메인을 각각 다른 네트워크 대역으로 분리할 계획이었다.
- HQ: 192.168.57.0/24
- USA: 192.168.81.0/24
- JP: 192.168.52.0/24
그러나 실제 프로젝트에서는 이 구조를 그대로 구현하지 못하였다.
■ 원인
멀티 대역 구조를 구성하려면 다음 요소들이 필요하다.
- 라우팅 구성
- AD Site 설계
- 서브넷 정의
- 네트워크 간 통신 검증
실습 환경에서는 이를 동시에 안정적으로 구성하는 데 한계가 있었고, 핵심 목표였던 멀티 도메인 검증이 지연될 가능성이 있었다.
■ 해결
네트워크 완전 분리는 보류하고, 단일 대역에서 멀티 도메인 구조를 먼저 검증하는 방향으로 우선순위를 조정하였다.
■ 적용 절차
- 모든 DC를 동일 네트워크 대역에서 구성
- 도메인 생성 및 DNS 구성
- 사용자 로그인 및 GPO 적용 검증
■ 결과
다음 핵심 기능을 안정적으로 검증할 수 있었다.
- 멀티 도메인 구조
- 도메인 간 인증
- DNS 이름 해석
- 사용자 로그인
- 자식 도메인 구성
■ 운영 판단
설계를 포기한 것이 아니라, 설계와 구현의 우선순위를 분리한 선택이었다.
핵심 기능 검증 이후 확장하는 방식이 더 현실적인 접근이라고 판단하였다.
2.3 GPO 적용 범위에 대한 오해
■ 문제
초기에는 부모 도메인인 hq.hybe.local에서 설정한 GPO가
자식 도메인인 usa.hq.hybe.local, jp.hq.hybe.local에도 자동으로 적용될 것이라 생각하였다.
그러나 실제 테스트에서는 기대한 방식으로 정책이 적용되지 않았다.
■ 원인
GPO는 포리스트 전체에 자동 확장되는 구조가 아니라, 링크된 도메인 또는 OU 범위 안에서만 적용되는 정책이다.
도메인 경계가 달라지면 정책 적용도 분리된다.
■ 해결
정책 적용 방식을 도메인 단위로 분리하였다.
각 도메인에서 별도의 GPO를 생성하고, 해당 OU에 직접 링크하는 방식으로 재구성하였다.
■ 적용 절차
- 도메인별 GPO 생성
- 대상 OU에 직접 링크
gpupdate,gpresult로 적용 확인
■ 결과
도메인별 독립적인 정책 운영 구조를 확보하였다.
■ 운영 판단
GPO는 설정 자체보다 적용 범위(도메인/OU 경계)가 핵심이라는 점을 확인하였다.
2.4 Administrator 계정명 변경 후 세션 반영 문제
■ 문제
Administrator 계정명 변경 이후,
정책 적용 확인 과정에서 로그인 명칭과 세션 상태가 혼선되는 느낌이 있었고, gpupdate 수행 시 User Policy 관련 오류가 발생하는 경우가 있었다.
■ 원인
계정명 변경은 정책 변경이지만, 이미 로그인된 세션은 이전 인증 상태를 일부 유지할 수 있다.
이로 인해 정책 반영 시점과 세션 상태 사이에 차이가 발생할 수 있다.
■ 해결
계정 정책 변경 후에는
단순 gpupdate 확인이 아니라 로그오프 후 재로그인 기준으로 검증하도록 기준을 수정하였다.
■ 적용 절차
- 계정명 변경 정책 적용
- 기존 세션 종료
- 변경된 계정명으로 재로그인
- 정책 상태 재확인
■ 결과
세션 재초기화 이후 정상 동작을 확인하였다.
■ 운영 판단
계정 관련 정책은 단순 설정 변경이 아니라 세션과 인증 흐름까지 포함해 검증해야 한다는 기준을 확립하였다.
2.5 IIS 원격 관리 구성 과정에서 발생한 문제
■ 문제
IIS 웹 서비스는 정상 동작하였고,
http://intranet.hq.hybe.local/ 접속 시 페이지도 정상 출력되었다.
그러나 IIS Manager를 통한 원격 관리 과정에서 다음 문제가 발생하였다.
- 인증서 경고 발생
- 사이트 기능 일부가 표시되지 않음
■ 원인
- 인증서 경고 Management Service는 Self-Signed 인증서를 사용하는 경우가 많으며, 접속 이름과 인증서 정보가 일치하지 않을 경우 경고가 발생할 수 있다.
- 기능 미노출 IIS 역할 서비스가 일부만 설치된 상태였으며, 정적 웹 사이트 운영에 필요한 기능이 누락되어 있었다.
■ 해결
다음과 같이 대응하였다.
- 인증서 경고는 내부 테스트 환경 기준으로 연결 진행
- 필요한 최소 역할 서비스만 추가 설치
추가한 역할 서비스:
- Static Content
- Default Document
- HTTP Errors
■ 적용 절차
- IIS 역할 서비스 상태 확인
- 필요한 기능만 선택적으로 추가 설치
- IIS Manager 재접속 후 기능 확인
■ 결과
원격 관리 환경에서 사이트 관련 기능이 정상적으로 표시되었다.
■ 운영 판단
IIS는 단순히 웹 페이지가 열리는 것으로 완성된 것이 아니라, 운영 목적에 맞는 역할 서비스 구성이 함께 필요하다는 점을 확인하였다.
2.6 Server Core 환경에서 IIS 운영 방식 정리
■ 문제
HQ-DC-01은 Server Core 환경이므로
로컬에서 IIS Manager(inetmgr)를 직접 사용할 수 없었다.
■ 원인
Server Core는 GUI 구성 요소가 제거된 환경으로, 로컬 GUI 기반 관리 자체가 지원되지 않는다.
■ 해결
다음 방식으로 운영 구조를 정리하였다.
- HQ-CL-01에서 IIS Manager를 통한 원격 GUI 관리
- HQ-DC-01에서 PowerShell 기반 확인 및 설정
■ 적용 절차
- 원격 GUI에서 사이트 및 기능 확인
- 서버 측에서는 PowerShell로 상태 점검
■ 결과
GUI와 CLI를 병행하는 안정적인 관리 체계를 구성할 수 있었다.
■ 운영 판단
Server Core 환경에서는 GUI를 억지로 대체하려 하기보다, 원격 GUI + PowerShell 병행 구조가 더 현실적인 운영 방식이라고 판단하였다.
3. 운영 관점에서 정리된 기준
이번 운영 점검을 통해 다음 기준을 정리하였다.
- Server Core 환경에서는 RSAT + PowerShell + 관리 공유 중심으로 운영한다.
- 멀티 도메인 검증은 네트워크 완전 분리보다 우선한다.
- GPO는 도메인/OU 경계를 기준으로 설계한다.
- 계정 정책 변경은 세션 재로그인까지 포함해 검증한다.
- IIS는 최소 역할 서비스 기반으로 구성하고 원격 관리까지 함께 검증한다.
4. 결론
이번 트러블슈팅 과정은 단순한 문제 해결이 아니라, 운영 방식 자체를 재정리하는 과정이었다.
초기에는 익숙한 방식이나 이상적인 설계를 그대로 적용하려 했지만, 실제 점검 과정에서는 안정성, 보안, 관리 복잡도, 실습 환경의 한계를 함께 고려해야 했다.
그 결과, 기능 중심이 아니라 운영 기준 중심으로 환경을 정리하는 방향이 더 적절하다는 결론에 도달하였다.