 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Windows Administration

Mark Russinovich는 이번 호에서 CPU 시간이 사용되는 과정을 보다 정확하게 보여 주는 새로운 스레드 및 프로세스 성능 측정 알고리즘을 설명하기 위해 Windows Vista 커널에 대해 자세히 소개합니다. 또한 바이러스 백신 및 콘텐츠 인덱싱과 같은 백그라운드 작업을 더욱 효율적으로 관리함으로써 더욱 완벽한 재생 환경을 제공하는 멀티미디어 클래스 스케줄러 서비스에 대해 살펴봅니다.

이번 호에서는 Active Directory의 위임 기능을 비롯하여 사용자가 그룹 정책을 더욱 효과적으로 활용할 수 있도록 Windows Vista의 그룹 정책 템플릿에 대해서도 설명합니다. 물론 The Cable Guy, The Scripting Guys, Windows Confidential 등 정기적으로 게시되는 기사의 새로운 내용도 살펴볼 수 있습니다.
주요 기사
Windows Administration Windows Vista 커널 속으로: 1부

Windows Vista에서는 OS 커널이 변경되어 메모리 관리에서 안정성 및 보안에 이르는 다양한 영역에서 기능이 상당히 향상되었습니다. 커널의 변화로 프로세스, 스레드 및 I/O와 같은 영역에서 어떠한 기능 향상을 얻을 수 있는지 살펴봅니다.

Mark Russinovich Active Directory에서 권한 위임

Active Directory에서 위임을 구현하면 보안을 강화하고 관리 작업을 단순화할 수 있습니다. 위임 구현 방법도 생각보다 훨씬 간단합니다. 대부분의 IT 인프라에서 거의 수정하지 않고 적용할 수 있는 몇 가지 간단한 위임 모델을 살펴봅니다.

Joel Yoker 및 Rob Campbell Windows Vista의 새 그룹 정책 템플릿 검토

Windows Vista의 그룹 정책 템플릿에는 중요한 변경 사항이 있습니다. ADMX라는 이름의 새로운 형식에 대해 알아보고 이러한 변경 사항이 시스템 구성을 관리하는 데 어떤 도움을 주는지 살펴봅니다.

Darren Mar-Elia 그룹 정책 문제 해결을 위한 안내

그룹 정책 문제의 근본 원인을 알아내는 것은 어려운 작업일 수 있지만 그룹 정책의 작동 방식과 문제가 발생할 수 있는 위치를 이해한다면 한결 쉬워질 수 있습니다. 이 개요는 그룹 정책 문제를 전문가처럼 해결하는 데 유용합니다.

Derek Melber MOM을 사용하여 Active Directory 모니터링

Microsoft Operations Manager 2005용 관리 팩을 사용하면 IT 인프라를 보다 효과적으로 모니터링할 수 있습니다. 이 다섯 가지 관리 팩이 Active Directory 환경의 상태, 보안 및 안정성 모니터링을 지원하는 방식을 직접 확인해 보십시오.

John Hann 안전한 게임 환경

사무실에서 업무로 바쁠 때에도, 아니면 집에서 게임에 열중할 때에도 제한된 사용자로 실행하면 보안상의 이점이 큽니다. 그러나 아쉽게도 관리자로 실행하지 않으면 작동하지 않는 게임도 있습니다. 이 기사에서는 몇 가지 일반적인 문제와 해결 방법을 소개합니다.

Matt Clapham
칼럼
From the Editor

작동 원리

Joshua Trupin Toolbox

IT 전문가를 위한 새로운 제품

Greg Steen SQL Q&A

데이터베이스 크기, 미러링 및 표시된 트랜잭션 등

편집자: Nancy Michell Utility Spotlight

그룹 정책 인벤토리

Greg Steen The Cable Guy

Windows에서 QoS 지원

Joseph Davies 		Windows PowerShell

한 번에 한 줄씩 스크립팅

Don Jones Hey, Scripting Guy!

자동차 뒤쫓기... 그리고 XML

Microsoft Scripting Guys Security Watch

EFS 배포: 1부

John Morello The Desktop Files

Windows PE 확장

Wes Miller Field Notes

알 수 없는 연결 중단

R'ykandar Korra'ti Windows Confidential

"혼합" 콘텐츠 인식 기능의 향상

Raymond Chen


 Windows Administration: Windows Vista 커널 속으로: 1부
Windows Administration Mark Russinovich

Windows Vista 커널 속으로: 1부
한 눈에 보기:
  • 스레드 우선 순위 및 사용 계획
  • 파일 기반 심볼 링크
  • I/O 작업 취소

이 기사는 Windows Vista 커널의 새로운 기능을 다루는 연재 기사의 첫 회입니다. 이번 호에서는 프로세스 및 스레드 영역과 I/O의 변경 내용을 살펴보고 다음 호에서는 메모리 관리, 시작 및 종료, 안정성 및 복구, 보안 등을 다루겠습니다.
이 기사에서는 Windows Vista™ 커널, 특히 Ntoskrnl.exe 및 이와 밀접하게 연결된 구성 요소의 변경 내용만을 다룹니다. Windows Vista에는 이 기사에서 다루는 커널에 해당하지는 않지만 다른 중요한 변경 사항도 많이 있다는 점에 유념하십시오. 이러한 변경 사항으로는 향상된 셸(예: 통합 데스크톱 검색), 네트워킹(예: 새로운 IPv6 스택 및 양방향 방화벽), 차세대 그래픽 모델(예: Aero™ 투명 효과, Windows® 프레젠테이션 파운데이션, 데스크톱 창 관리자, 새 그래픽 드라이버 모델) 등이 있습니다. 이 기사에서는 또한 Windows UMDF(사용자 모드 드라이버 프레임워크)와 KMDF(커널 모드 드라이버 프레임워크)도 다루지 않는데, 이것은 이전 버전의 Windows에서도 설치가 가능하기 때문입니다.

CPU 사이클 계산
Windows Vista는 보다 균형된 CPU 할당을 위한 CPU 사이클 카운터와 미디어 응용 프로그램이 오류 없이 재생되도록 하는 MMCSS(멀티미디어 클래스 스케줄러 서비스)를 비롯하여 프로세스 및 스레드 영역에서 다양한 향상된 기능을 제공합니다.
Windows Vista를 포함하여 모든 버전의 Windows NT®에서는 하드웨어 플랫폼에 따라 대략 10밀리초나 15밀리초마다 실행되도록 간격 타이머 인터럽트 루틴을 프로그래밍합니다. 루틴은 중단한 스레드를 파악하고 전체 간격 동안 해당 스레드가 실행된 것처럼 스레드의 CPU 사용 통계를 업데이트하지만 실제로는 간격이 끝나기 바로 전에 스레드가 실행되기 시작했을 수도 있습니다. 또한 기술적으로는 이 스레드에 CPU가 할당되었지만 하드웨어와 소프트웨어 인터럽트 루틴이 대신 실행되어 스레드는 실행되지 않은 경우도 있습니다.
스레드와 프로세스의 CPU 사용을 보고하는 진단 도구로 클록 기반 시간 계정을 사용해도 괜찮을 수 있지만 스레드 스케줄러가 이 계산 방법을 사용하면 불균형한 CPU 할당이 발생할 수 있습니다. 기본적으로 클라이언트 버전의 Windows 스레드에서는 최대 2개(포그라운드인 경우 6개)의 클록 틱을 실행할 수 있습니다. 그러나 스레드에는 시스템에서의 해당 동작과 기타 다른 작업에 따라 CPU 시간이 거의 할당되지 않거나 최대 6개의 틱(포그라운드인 경우 18개)이 할당될 수 있습니다.
그림 1에서는 우선 순위가 같은 2개의 스레드가 동시에 실행될 준비가 되었을 때 발생할 수 있는 불균형 상태를 보여 줍니다. 스레드 A가 다음 시간 조각 간격이 만료되는 시점까지 실행되면 스케줄러는 스레드 A가 전체 간격 내내 실행된 것으로 가정하고 스레드 A의 차례가 끝난 것으로 결정합니다. 게다가 스레드 A는 해당 차례에 발생한 인터럽트까지 실행 시간에 포함되는 불이익을 받게 됩니다. 다음 간격에서 스케줄러는 스레드 B를 선택하여 전체 간격 동안 실행합니다.
그림 1 불균형한 스레드 사용 계획
그림 1 불균형한 스레드 사용 계획
Windows Vista의 스케줄러는 최신 프로세서의 사이클 카운터 레지스터를 사용하여 스레드가 실행하는 CPU 사이클 수를 정밀하게 추적합니다. 클록 간격에서 CPU가 실행할 수 있는 사이클 수를 예측하여 CPU에서 차례를 보다 정확하게 할당할 수 있습니다. 또한 Windows Vista 스케줄러는 인터럽트 실행이 스레드 차례에 불이익을 주지 않도록 합니다. 즉, Windows Vista에서는 항상 스레드가 CPU에서 최소한 자신의 차례를 갖고 실행을 위한 별도의 클록 간격을 갖지 않으므로 탁월한 균형성과 보다 명확한 응용 프로그램 동작을 구현할 수 있습니다. 그림 2에서는 Windows Vista가 두 스레드 모두에 적어도 실행을 위한 하나의 시간 조각을 제공하여 그림 1에 표시된 시나리오에 응답하는 방법을 보여 줍니다.
그림 2 Windows Vista 사이클 기반 사용 계획
그림 2 Windows Vista 사이클 기반 사용 계획
"프로세스 CPU 사용 관찰"에서는 Process Explorer 유틸리티를 사용하여 프로세스 CPU 사이클 사용을 직접 모니터링하는 방법을 보여 줍니다.

멀티미디어 클래스 스케줄러 서비스
사용자는 음악 및 비디오 플레이어를 포함한 멀티미디어 응용 프로그램이 원활한 재생 환경을 제공할 것으로 예상합니다. 그러나 바이러스 백신, 콘텐츠 인덱싱 또는 메일 클라이언트와 같이 동시에 실행되는 다른 응용 프로그램의 CPU 요구로 인해 원하지 않는 문제가 발생할 수 있습니다. 더 나은 재생 환경을 제공하기 위해 Windows Vista에서는 MMCSS를 채택하여 멀티미디어 스레드의 CPU 우선 순위를 관리합니다.
Windows Media® Player 11 등의 멀티미디어 응용 프로그램은 해당 멀티미디어의 특징을 나타내는 새로운 API(다음 레지스트리 키 아래에 이름별로 나열된 것 중 하나와 일치해야 함)를 사용하여 MMCSS에 등록됩니다.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

그림 A Process Explorer에서 CPU Time(CPU 시간) 및 Cycles Delta(사이클 변화량) 보기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 A Process Explorer에서 CPU Time(CPU 시간) 및 Cycles Delta(사이클 변화량) 보기
그림 A Process Explorer에서 CPU Time(CPU 시간) 및 Cycles Delta(사이클 변화량) 보기 (더 크게 보려면 이미지를 클릭하십시오.)

그림 3 멀티미디어 클래스 스케줄러 오디오 작업 정의
그림 3 멀티미디어 클래스 스케줄러 오디오 작업 정의 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 멀티미디어 클래스 스케줄러 오디오 작업 정의
그림 3 멀티미디어 클래스 스케줄러 오디오 작업 정의 (더 크게 보려면 이미지를 클릭하십시오.)
%SystemRoot%\System32\Mmcss.dll에서 구현되어 서비스 호스트(Svchost.exe) 프로세스에서 실행되는 MMCSS에는 우선 순위 27로 실행되는 우선 순위 관리 스레드가 있습니다. Windows의 스레드 우선 순위 범위는 0~31입니다. 이 스레드는 등록된 멀티미디어 스레드의 우선 순위를 해당 작업 레지스트리 키의 Scheduling Category 값과 연결된 범위로 높입니다(그림 4 참조). Windows에서 16 이상의 스레드 우선 순위는 실시간 우선 순위 범위에 해당하고 우선 순위 28과 29로 실행되는 커널의 메모리 관리자 작업자 스레드를 제외한 시스템의 다른 모든 스레드보다 우선 순위가 더 높습니다. MMCSS가 실행되는 로컬 시스템 계정과 같은 관리자 계정에만 실시간 스레드 우선 순위를 설정하는 데 필요한 우선 순위 높이기 권한이 있습니다.
Figure 4 MMCSS 스레드 우선 순위 (Close Figure 4)

사용 계획 범주 | 높아진 스레드 우선 순위
높음 | 23-26
보통 | 16-23
Windows Media Player에서는 사용자가 오디오 파일을 재생하면 오디오 작업 스레드를 등록하고 비디오를 재생하면 재생 작업 스레드를 등록합니다. MMCSS 서비스는 포그라운드 창을 소유한 프로세스에서 실행되고 있으며 BackgroundOnly 값이 해당 작업의 정의 키에 True로 설정되어 있는 상태로 스트림을 전달하고 있음을 나타내는 모든 스레드의 우선 순위를 높입니다.
그러나 MMCSS는 멀티미디어 스레드에 필요한 CPU 시간이 할당되도록 할 뿐만 아니라 다른 스레드에도 최소한 약간의 CPU 시간이 할당되도록 하여 시스템과 다른 응용 프로그램의 응답성이 유지되도록 합니다. 이를 위해 MMCSS는 다음 레지스트리 값에 지정된 비율의 CPU 시간을 다른 작업용으로 예약합니다.
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
기본적으로 이 비율은 20%입니다. MMCSS는 CPU 사용을 모니터링하여 다른 스레드가 CPU 시간을 요구할 경우 10밀리초의 기간 중 8밀리초 이내로만 멀티미디어 스레드의 우선 순위를 높입니다. 나머지 2밀리초 동안에는 멀티미디어 스레드가 사용되지 않도록 하기 위해 스케줄러는 해당 스레드의 우선 순위를 1~7 범위로 낮춥니다.
MMCSS가 스레드 우선 순위를 높이는 방법에 대한 자세한 내용은 "MMCSS 우선 순위 높이기 관찰"을 참조하십시오.

파일 기반 심볼 링크
Windows Vista의 I/O 관련 변경 사항으로는 파일 기반 심볼 링크, 보다 효율적인 I/O 완료 처리, 포괄적인 I/O 취소 지원, 우선 순위가 부여된 I/O 등이 있습니다.
많은 사용자들이 NTFS에서 누락되었다고 생각하는 파일 시스템 기능인 심볼 파일 링크(UNIX에서는 소프트 링크라고 함)가 마침내 Windows Vista에 포함되었습니다. Windows 2000 버전의 NTFS에서는 다른 디렉터리를 가리키는 디렉터리를 만들 수 있게 해 주는 디렉터리 교차점이라는 심볼 디렉터리 링크가 사용되었지만 Windows Vista 이전 버전의 NTFS에서는 파일의 하드 링크만 지원했습니다.
Windows에서 심볼 링크와 디렉터리 교차점을 해결하는 방식의 가장 큰 차이점은 처리가 발생하는 위치입니다. Windows에서 심볼 링크는 원격 파일 서버에 있는 위치를 참조할 때조차 로컬 시스템에서 처리됩니다. Windows에서는 원격 파일 서버를 참조하는 디렉터리 교차점을 해당 서버 내에서 처리합니다. 따라서 서버에 있는 심볼 링크는 다른 클라이언트 볼륨과 같이 클라이언트에서만 액세스할 수 있는 위치를 참조할 수 있지만 디렉터리 교차점은 참조할 수 없습니다. 이 문제를 해결하기 위해 Windows Vista에서는 파일과 디렉터리 모두에 대해 새로운 심볼 링크 유형을 지원합니다.
심볼 링크에 내포된 의미를 이해할 수 있도록 다양한 파일 시스템 명령이 업데이트되었습니다. 예를 들어 Delete 명령은 링크를 따르는 대신 링크를 삭제하도록 업데이트되었습니다(링크를 따르면 대상이 삭제됨). 그러나 일부 응용 프로그램에서는 심볼 링크를 올바르게 처리할 수 없으므로 심볼 링크를 만들려면 기본적으로 관리자에게만 부여되는 새로운 심볼 링크 만들기 권한이 있어야 합니다.
Mklink 명령으로 명령 프롬프트에서 심볼 링크를 만들 수 있습니다. 명령 프롬프트에서 기본으로 제공하는 디렉터리 명령은 <SYMLINK>로 플래그를 지정하고 대상을 괄호 안에 표시하여 심볼 링크를 식별합니다(그림 5 참조). 심볼 링크는 Windows 탐색기에서도 확인할 수 있으며 바로 가기 화살표로 표시됩니다. 찾기 창에 링크 대상 열을 추가하여 탐색기에서 링크의 대상을 볼 수 있습니다.MMCSS 우선 순위 높이기 관찰
비디오 또는 오디오 클립 재생, 성능 모니터 실행, 그래프 배율을 31(Windows 스레드의 최고 우선 순위)로 설정, 표시 화면에 Windows Media Player(Wmplayer.exe) 스레드 개체의 모든 인스턴스에 대한 Priority Current 카운터 추가 등을 수행하여 MMCSS 서비스가 Windows Media Player 스레드에 적용하는 스레드 높이기를 확인할 수 있습니다. 하나 이상의 스레드가 우선 순위 21로 실행됩니다.
그림 B Windows Media Player의 스레드 우선 순위 높이기
그림 B Windows Media Player의 스레드 우선 순위 높이기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 B Windows Media Player의 스레드 우선 순위 높이기
그림 B Windows Media Player의 스레드 우선 순위 높이기 (더 크게 보려면 이미지를 클릭하십시오.)

그림 5 Mklink를 사용하여 심볼 링크 만들기
그림 5 Mklink를 사용하여 심볼 링크 만들기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 Mklink를 사용하여 심볼 링크 만들기
그림 5 Mklink를 사용하여 심볼 링크 만들기 (더 크게 보려면 이미지를 클릭하십시오.)

I/O 완료 및 취소
I/O 시스템에는 사용자에게 보이지는 않지만 서버 응용 프로그램 성능을 향상시킬 수 있도록 다양한 기능이 변경되었습니다. 이러한 응용 프로그램에서는 완료 포트라는 동기화 개체를 자주 사용하여 비동기 I/O 요청이 완료될 때까지 대기합니다. Windows Vista 이전에는 이러한 I/O가 완료될 때 I/O를 호출한 스레드가 I/O 완료 작업을 실행하므로 해당 스레드가 속한 프로세스로 전환되고 진행되고 있던 다른 모든 작업이 중단됩니다. 그런 다음 I/O 시스템은 완료 포트의 상태를 업데이트하여 변경 대기 중인 스레드를 활성화합니다.
그러나 Windows Vista에서는 I/O를 호출한 스레드가 반드시 I/O 완료 처리를 수행하는 것이 아니라 완료 포트가 대기 상태를 해제해 주기를 기다리는 스레드가 I/O 완료 처리를 수행합니다. 비교적 간단해 보이지만 이러한 변경을 통해 응용 프로그램과 시스템의 전반적인 성능을 저하시킬 수 있는 불필요한 스레드 사용 계획과 컨텍스트 전환을 방지할 수 있습니다. 서버가 특정한 한 요청의 완료에서 여러 I/O 작업의 결과를 검색할 수 있으므로 커널 모드로의 전환이 방지되어 성능이 더욱 향상됩니다.
아마도 최종 사용자 측면에서 볼 때 I/O 시스템에서 가장 주목할 만한 변경 사항은 Windows Vista에서 동기 I/O 작업 취소가 지원된다는 것일 수 있습니다. net view 명령을 실행하거나 Windows XP 또는 Windows Server® 2003을 사용하여 오프라인 원격 시스템의 공유에 액세스하려고 시도하면 취소할 수 없는 I/O 작업으로 인해 문제가 발생하게 됩니다. 즉, 네트워크 시간 제한이 만료된 후에야 명령이나 파일 브라우저가 응답합니다. 응용 프로그램에서는 I/O를 실행하는 장치 드라이버에 더 이상 I/O에 대해 신경 쓰지 않음을 알릴 방법이 없기 때문에 작업이 실패할 때까지 기다릴 수 밖에 없습니다.
Windows Vista에서는 Net View와 탐색기에서 사용하는 열린 파일 I/O를 비롯하여 대부분의 I/O 작업을 취소할 수 있습니다. 그러나 응용 프로그램을 업데이트해야 I/O를 취소하라는 최종 사용자 요청에 응답할 수 있으며 시간 제한이 있는 장치와 상호 작용하는 많은 수의 Windows Vista 유틸리티에는 필요한 지원 기능이 있습니다. 예를 들어 이제는 타사 응용 프로그램을 포함하여 거의 모든 Windows 응용 프로그램에 사용되는 파일 열기 및 저장 대화 상자에 폴더 내용을 표시하면서 취소 단추를 사용할 수 있습니다. Net 명령의 동기 I/O도 Ctrl+C를 누르면 취소됩니다.
Windows Vista에서 명령 프롬프트를 열고 다음과 같이 입력하여 I/O 취소의 이점을 직접 확인할 수 있습니다.
net view (\\nonexistentmachine)
Windows에서 존재하지 않는 시스템에 연결을 시도할 때는 명령이 멈추지만 Ctrl+C를 누름으로써 명령을 종료할 수 있습니다. Windows XP에서는 Ctrl+C를 눌러도 아무 효과가 없으며 네트워크 작업 시간 제한이 만료되어야만 명령 결과가 반환됩니다.
이전 버전의 Windows에서 문제가 되었던 또 다른 유형의 I/O로는 장치 드라이버가 I/O를 취소하는 간단한 방법이 없어서 해당 장치 드라이버가 올바르게 취소하지 않은 I/O가 있습니다. 프로세스를 종료했지만 나중에 프로세스 보기 도구에서 해당 프로세스가 남아 있는 것을 확인한 경우 장치 드라이버가 프로세스 종료 명령에 응답하지 못하고 완료하지 못한 프로세스에서 호출한 I/O를 취소하는 것을 보게 됩니다. Windows에서는 모든 프로세스의 I/O가 완료되거나 취소된 후에만 최종 프로세스 정리를 수행할 수 있습니다. Windows Vista에서는 장치 드라이버가 프로세스 종료 알림을 손쉽게 등록할 수 있으므로 종료할 수 없는 프로세스 문제가 대부분 해결됩니다.

I/O 우선 순위
Windows에서는 항상 CPU 사용의 우선 순위 매기기를 지원해 왔지만 I/O 우선 순위 개념이 적용되지는 않았습니다. I/O 우선 순위가 없다면 검색 인덱싱, 바이러스 검색, 디스크 조각 모음과 같은 백그라운드 작업이 포그라운드 작업의 응답 성능에 심각한 영향을 미칠 수 있습니다. 예를 들어 다른 프로세스에서 디스크 I/O를 수행하는 동안 사용자가 응용 프로그램을 시작하거나 문서를 열면 포그라운드 작업이 디스크 액세스를 기다리므로 지연이 발생합니다. 동일한 간섭으로 인해 하드 디스크에 저장된 곡 등의 멀티미디어 콘텐츠를 스트리밍 재생할 때도 영향을 받습니다.
Windows Vista에서는 포그라운드 I/O 작업에 우선 순위를 부여하기 위해 새로운 유형의 두 가지 I/O 우선 순위인 개별 I/O 작업 및 I/O 대역폭 예약에 대한 우선 순위가 새롭게 구현되었습니다. Windows Vista I/O 시스템에서는 내부적으로 그림 6에 표시된 5가지 I/O 우선 순위를 지원하지만 이 중에서 4개의 우선 순위만 사용됩니다. 이후 버전의 Windows에서는 높음을 지원할 수도 있습니다.
Figure 6 Windows Vista I/O 우선 순위 (Close Figure 6)

I/O 우선 순위 | 사용량
중요 | 메모리 관리자
높음 | 사용 안 함
보통 | 기본 우선 순위
낮음 | 기본 작업 우선 순위
매우 낮음 | 백그라운드 작업
I/O의 기본 우선 순위는 보통입니다. 메모리 관리자는 메모리가 부족한 상황에서 다른 데이터와 코드에 메모리를 할당할 공간을 확보하기 위해 더티 메모리 데이터를 디스크에 기록하려는 경우 중요를 사용합니다. Windows 작업 스케줄러는 기본 작업 우선 순위가 있는 작업의 I/O 우선 순위를 낮음으로 설정하며 백그라운드 처리를 수행하는 Windows Vista용 응용 프로그램에서 지정하는 우선 순위는 매우 낮음입니다. Windows Defender 검색과 데스크톱 검색 인덱싱을 포함한 모든 Windows Vista 백그라운드 작업은 매우 낮음 I/O 우선 순위를 사용합니다.매우 낮음 I/O 우선 순위 보기
Sysinternals의 실시간 파일 시스템 및 레지스트리 모니터링 유틸리티인 Process Monitor는 Windows Vista에서의 I/O 우선 순위를 포함하여 읽기 및 쓰기 파일 시스템 작업에 대한 자세한 정보를 수집합니다. 강조 표시된 줄은 다음 호에서 살펴볼 SuperFetch에서 호출한 매우 낮음 우선 순위 I/O의 예를 보여 줍니다.
그림 C Proces Monitor에서 매우 낮음 I/O 우선 순위 보기
그림 C Proces Monitor에서 매우 낮음 I/O 우선 순위 보기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 C Proces Monitor에서 매우 낮음 I/O 우선 순위 보기
그림 C Proces Monitor에서 매우 낮음 I/O 우선 순위 보기 (더 크게 보려면 이미지를 클릭하십시오.)

시스템 저장소 클래스 장치 드라이버(%SystemRoot%\System32\Classpnp.sys)가 I/O 우선 순위를 적용하므로 대부분의 저장 장치로 향하는 I/O에 이러한 우선 순위가 자동으로 적용됩니다. 클래스 및 다른 저장소 드라이버는 해당 큐에서 우선 순위가 낮음 및 매우 낮음인 이러한 I/O 앞에 보통 I/O를 삽입하지만 1초마다 적어도 하나의 대기 중인 낮음 또는 매우 낮음 I/O를 호출하므로 백그라운드 프로세스는 큐에서 앞으로 진행될 수 있습니다. 또한 매우 낮음 I/O를 사용하여 데이터를 읽으면 캐시 관리자가 나중에 쓰지 않고 즉시 디스크에 수정 내용을 쓰며 액세스되고 있는 파일에서 우선적으로 읽는 읽기 작업의 미리 읽기 논리를 무시합니다. Process Monitor 유틸리티를 사용한 매우 낮음 I/O 우선 순위의 예를 보려면 "매우 낮음 I/O 우선 순위 보기"를 참조하십시오.
Windows Vista 대역폭 예약 지원은 미디어 플레이어 응용 프로그램에 유용하며 Windows Media Player에서는 이 기능을 MMCSS 우선 순위 높이기 기능과 함께 사용하여 로컬 콘텐츠를 오류 없이 재생합니다. 미디어 플레이어 응용 프로그램에서는 지정한 속도로 데이터를 읽을 수 있도록 I/O 시스템에 요청하며, 장치가 요청한 속도로 데이터를 전달할 수 있고 기존 예약에서 이를 허용할 경우 응용 프로그램에 I/O 호출 속도와 I/O 크기에 대한 지침을 제공합니다. 대상 저장 장치에서 예약을 한 응용 프로그램의 요구 사항을 충족할 수 없는 경우 I/O 시스템에서는 다른 I/O를 처리하지 않습니다.
I/O 시스템에서 주목할 만한 또 다른 최종 변경 사항 중 하나는 I/O 작업의 크기와 관련이 있습니다. Windows NT의 첫 번째 버전 이후로 메모리 관리자와 I/O 시스템에서는 개별 저장소 I/O 요청으로 처리되는 데이터 양을 64KB로 제한합니다. 따라서 응용 프로그램에서 훨씬 더 많은 I/O 요청을 호출하면 해당 요청은 최대 크기가 64KB인 개별 요청으로 나뉩니다. 각 I/O가 커널 모드로의 전환에 따른 오버헤드를 발생시키고 저장 장치에서 I/O 전송을 시작하므로 Windows Vista에서는 저장소 I/O 요청의 크기에 더 이상 제한이 없습니다. 이제 1MB의 I/O를 호출하는 탐색기의 복사 기능과 명령 프롬프트의 Copy 명령을 포함하여 보다 큰 I/O에 대한 지원을 활용하도록 여러 가지 Windows Vista 사용자 모드 구성 요소가 수정되었습니다.

다음 문서에서 다룰 내용
지금까지 Windows Vista 커널에서 향상된 두 가지 영역을 살펴봤습니다. 코드명이 "Longhorn"인 다음 Windows Server 버전과 동시에 출시할 예정으로 집필한 Windows Internals(David Solomon 공저)의 다음 판본에서는 더 깊이 있는 내용을 보실 수 있습니다. 다음 호에서는 메모리 관리와 시스템 시작 및 종료에 대한 논의를 통해 계속해서 새 커널에 대해 소개할 것입니다.

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 IT와 개발자 회의에 자주 서는 연설자이며 최근 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 또한 Process Explorer, Filemon 및 Regmon 유틸리티를 게시한 Sysinternals를 설립했습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Windows Administration: Active Directory에서 권한 위임
Windows Administration Joel Yoker and Rob Campbell

Active Directory에서 권한 위임
한 눈에 보기:
  • 관리자 역할 정의
  • OU 및 보안 그룹 모델 개발
  • 보조 계정 사용
  • 권한 위임용 도구

Active Directory의 강력한 위임 기능은 다양한 보안 문제를 해결하고 관리 작업을 단순화하는 데 매우 유용합니다. Active
Directory® 내에서 적절히 권한을 위임하면 해당 환경에서 특정 역할을 강제 수행할 수 있고, 관리 상의 오류가 발생할 가능성과 그 영향을 줄일 수 있으며, 인프라 전체에 최소 권한 원칙을 적용할 수 있습니다. 그러나 Active Directory를 사용하는 많은 기업은 이 위임 기능을 제대로 활용하지 못하고 있습니다. 회사에 사용할 Active Directory 위임 모델을 개발하는 것은 일견 복잡해 보이기 때문입니다. 가장 큰 문제는 해당 조직의 고유한 상황에 맞는 위임 모델을 개발하는 것입니다. 그러나 사실 대부분의 IT 인프라에 거의 변경 없이 적용할 수 있는 매우 간단한 모델이 존재합니다.
모든 환경은 방식이나 형태에 있어 약간씩 다르긴 하지만 실제로 많은 대기업은 여러 측면에서 비슷하고 당면한 IT 문제도 같은 경우가 많습니다. 예를 들어 많은 기업은 지역별로 세분화되어 있고, 별도의 IT 엔지니어링 또는 운영 지원팀에서 발전했으며, 독립된 사업부를 갖추고 있습니다. 또한 권한 상승 문제, 서비스 계정 남용, "트러스트" 등을 처리해야 하는 대규모 기업도 많습니다.
트러스트는 Active Directory 포리스트를 여러 개 보유해야 하는 이유가 될 때가 많으며, 특정 부서나 지역이 다른 부서나 지역의 시스템 가용성에 영향을 미칠 수 있을 때 자주 문제가 발생합니다. 대부분의 경우 기술 수준은 조직 간에 다르기 때문에 특정 지역이나 사업부를 지원하는 데 필요한 특정 시스템 관련 지식이 부족할 때가 많습니다. 따라서 부서들은 대개 중앙 그룹에 관리 권한을 넘겨주지 않으려 합니다.
한편 Active Directory 구현의 경우 관리자는 Active Directory 인프라를 사용하는 응용 프로그램의 운용 규칙을 정의해야 합니다. 안타깝게도 응용 프로그램 설치 가이드에 자주 언급되는 일반적인 방법은 서비스 계정을 Domain Admins 그룹의 구성원으로 만드는 것입니다. 이런 방법의 문제는 서비스 계정이 본질적으로 일반 계정이라는 점입니다. 이러한 계정에 Domain Administrator 권한을 부여하면 IT 환경의 보안이 상당히 위험해집니다. 서비스 계정은 악의적이거나 부주의한 관리자 또는 응용 프로그램 내의 기본 보안 문제를 악용하는 공격자가 쉽게 악용할 수 있기 때문입니다.
이러한 문제는 해결하기 어려운 것으로 보일 수 있지만, Active Directory 위임 모델 구현의 좋은 시나리오가 되기도 합니다. 위임 모델의 개발은 반복 작업이 많은 디자인 프로세스로서, 다음 단계를 따르는 것이 좋습니다.
  1. 조직 내의 IT 관리자 역할 정의
  2. 조직 구성 단위 및 보안 그룹 모델 개발
  3. IT 관리자의 보조 계정 설정
  4. 권한 위임
이러한 단계를 보다 자세히 살펴보겠습니다.

역할 정의
역할을 정의하기 위해서는 우선 서비스 관리와 데이터 관리를 모두 철저히 이해해야 합니다. 이런 개념은 모든 Active Directory 위임 모델의 기초가 됩니다.
핵심을 요약하자면 서비스 관리는 Exchange 서버 및 도메인 컨트롤러와 같은 중요 디렉터리 서비스 인프라 구성 요소를 관리하는 것이고, 데이터 관리는 이러한 서비스 내에 상주하는 사서함 및 사용자 계정 등의 개체를 관리하는 것입니다. Active Directory의 범위 내에서 서비스 관리자는 디렉터리 서비스의 제공 및 가용성을 최종 책임지고, 데이터 관리자는 사용자 및 서버 계정, 그룹, 기타 도메인 리소스를 관리합니다.
Active Directory는 OU(조직 구성 단위)를 통해 정교한 권한 위임을 지원합니다. OU는 기존 디렉터리 서비스나 도메인 모델 내에서 관리자에게 제공된 것과 같은 수준의 권한을 제공하도록 자주 조정할 수 있습니다. 그러나 일부 기능은 위임이 불가능하고 확실히 신뢰할 수 있는 단일 그룹이나 엔터티가 관리해야 합니다.
작업 분석 또한 중요합니다. 즉, 관리자가 수행하는 Active Directory 작업이 무엇이고 이러한 작업이 역할에 어떻게 매핑되는지 알아야 합니다. 예를 들어 Active Directory 사이트 만들기는 서비스 관리 작업인 반면, 보안 그룹 멤버십 수정은 일반적으로 데이터 관리에 속합니다. 각 작업의 빈도, 중요도 및 난이도도 평가해야 합니다. 이러한 항목은 권한 위임 여부를 결정하기 때문에 작업 정의의 필수 요소입니다. 정기적으로 수행되는 작업, 위험 요소가 제한된 작업, 일상적인 작업 등은 위임에 적합한 대상입니다. 반면 드물게 수행되는 작업, 조직에 큰 영향을 미치는 작업, 높은 수준의 기술이 필요한 작업 등은 위임에 적합한 대상이 아닙니다. 이러한 작업에는 계정을 일시적으로 필요한 역할로 상향 조정하거나 작업을 재할당하는 에스컬레이션이 더 적합합니다.
대규모 조직은 특성이 많이 비슷하기 때문에 일반적인 위임 모델을 구현하는 것으로 간주해도 무방합니다. 본 기사의 목적에 맞게 여기서는 조직의 경계를 고려하고 트러스트 문제(예: 도메인 컨트롤러와 같은 전사적 자산의 가용성)를 완화하도록 주의하면서 관리 기능을 실행하는 일련의 샘플 역할을 제공하겠습니다. 이 모델은 단순한 예제로서, 조직 내에서 역할 논의를 시작하는 데 유용하긴 하지만 그대로 똑같이 사용해서는 안 됩니다.
일부 역할은 Active Directory에서 이미 지정되어 있지만 일부는 위임 모델을 완성하도록 처음부터 새로 만들어야 합니다. 많은 대규모 Active Directory 환경에 맞는 역할 집합의 예로는 서비스 관리의 경우 Enterprise Admins, Domain Admins, Tier4 Admins 등이 있고 데이터 관리의 경우에는 Tier3 Admins, Regional Admins, Tier2 Admins, Tier1 Admins 등이 있습니다. 이러한 역할과 해당 기능 목록이 그림 1에 나와 있습니다.
Figure 1 역할 및 기능 정의 (Close Figure 1)

서비스 관리자 | 설명
Enterprise Admins | 기업 전체의 최상위 서비스 관리를 담당합니다. 영구 구성원이 없어야 합니다.
Domain Admins | 도메인 전체의 최상위 서비스 관리를 담당합니다. 소수의 신뢰할 수 있는 관리자로만 구성되어야 합니다.
Tier 4 Admins | 도메인 전체의 서비스 관리를 담당합니다. 필수 서비스를 관리하는 데 필요한 권한만 부여되며 데이터 관리자의 에스컬레이션 지점 역할을 합니다.
데이터 관리자 | 설명
Tier 1 Admins | 디렉터리 개체의 일반 관리를 담당하며 암호 재설정, 사용자 계정 속성 변경 등의 작업을 수행합니다.
Tier 2 Admins | 해당 로캘이나 조직에서 사용자 및 컴퓨터 계정의 선택적인 생성 및/또는 삭제를 담당합니다.
Regional Admins | 해당 로컬 OU 구조의 관리를 담당합니다. 해당 OU 내에서 대부분의 개체를 만들 수 있는 권한이 부여됩니다.
Tier 3 Admins | 모든 데이터 관리자를 관리하는 일을 담당합니다. 모든 지역 관리자의 최상위 계층 헬프 데스크와 에스컬레이션 지점 역할을 합니다.

서비스 관리자
이제 서비스 관리자 역할을 자세히 살펴보도록 하겠습니다. 서비스 관리자는 중요한 인프라 구성 요소를 관리하며, 이 범주에 속한 관리자는 모두 높은 권한을 갖습니다. 따라서 작업 수행에 필요한 최소 권한 집합만 부여한다는 의미의 최소 권한 전략을 적용하는 것이 좋습니다.
Enterprise Admins 및 Domain Admins Active Directory는 디렉터리 내의 중요 기능에 필요한 보안 컨텍스트를 가진 두 개의 특수 관리자 그룹을 정의합니다. 이러한 그룹(Enterprise Admins 및 Domain Admins)은 최상위 서비스 관리를 담당합니다. 이렇게 높은 권한을 가진 그룹의 위험 요소를 줄이기 위해서는 해당 그룹의 멤버십을 제한하는 것이 좋습니다. 사실상 Enterprise Admins 그룹에는 영구 구성원이 없어야 하고 Domain Admins 그룹은 조직의 정규 직원으로 근무하는 소수의 신뢰할 수 있는 개인만 포함해야 합니다.
DHCP 서버 권한 부여 또는 Active Directory 사이트 생성과 같은 엔터프라이즈 관리 작업을 수행해야 할 경우 Active Directory 포리스트의 루트 도메인에 있는 Domain Admins는 Enterprise Admins 그룹의 멤버십을 관리하여 권한을 상승시킬 수 있습니다. 이러한 권한은 Enterprise Admins 그룹에 영구 구성원이 생기지 않도록 잠시 동안만 부여해야 합니다. 물론 특정 Active Directory 포리스트에 있는 Domain Admins 그룹의 모든 구성원은 동일하게 트러스트되어야 합니다.
대부분의 기업이 위임 모델을 개발할 때 범하기 쉬운 실수는 이러한 기본 제공 역할이 사용되지 않도록 해제하는 것입니다. 기본 역할을 수정하면 예상치 못한 결과가 초래될 수 있으며 서비스 팩 수정 버전이나 제품 업그레이드가 이러한 설정을 유지한다는 보장도 없습니다. 이러한 수정은 또한 조직 외부에 지원되지 않는 환경을 만들기도 합니다. 실용적인 방법은 기본 제공 그룹과 역할을 사용하면서 구성원을 제한하는 것입니다. 이렇게 하려면 이전에 Domain Admins과 같은 그룹의 멤버십에 의존했던 관리자에 대해 새 역할을 만들어야 할 수 있습니다.
Tier4 Admins 그룹은 모든 엔터프라이즈 서비스를 지원하는 중앙 집중식의 서비스 관리자로 구성됩니다. 이 그룹은 생성된 역할이므로 해당 조직의 특정 요구 사항에 맞게 디렉터리 서비스 및 시스템 액세스 권한을 조정할 수 있습니다. 이 그룹의 구성원은 서비스 관리자이지만 경우에 따라 포리스트 차원의 데이터 관리 작업을 수행할 수도 있습니다. Tier4 역할은 많은 시스템 클래스와 다양한 책임 영역을 보유하기 때문에 디렉터리 내에서 여러 하위 그룹으로 나뉩니다. 예를 들어 Exchange 서버와 같은 특정 시스템에 분리된 관리 작업을 제공하기 위해서는 별도의 Tier4 그룹을 만들어야 합니다. 이 그룹은 데이터 관리자의 에스컬레이션 지점 역할도 수행합니다.
사람들이 Domain Admins 그룹의 멤버십을 원하는 이유 중 하나는 특정 도메인의 모든 시스템에 대해 관리 권한을 얻기 위해서입니다. 이러한 서비스 관리자가 최소 권한 모드로 실행하도록 하려면 Domain Admins로 지정하지 않고 Tier4 Admins에 엔터프라이즈 서버 제어 권한을 부여하면 됩니다. 해당 그룹은 디렉터리 서비스에 대해 분리가 불가능한 많은 기본 권한을 가지므로 권한 상승을 방지하기 위해 Tier4 Admins에는 도메인 컨트롤러의 BUILTIN\Administrators 그룹 멤버십을 부여하면 안 됩니다. 예를 들어 특정 도메인의 BUILTIN\Administrators 그룹에 속한 구성원은 Domain Admins 그룹을 관리할 수 있기 때문에 구성원이 어떠한 견제와 균형 없이 권한을 상승하도록 허용할 수 있습니다.
기본 권한을 해제하면 안 된다는 규칙을 상기하면서 Tier4 그룹을 Server Operators 및 DNS Admins 기본 제공 도메인 그룹의 중첩 구성원으로 만들면 이런 위험을 완화할 수 있습니다. 이렇게 하면 도메인 컨트롤러를 로컬로 관리하면서 Tier4 Admins의 권한 상승 기능을 제한할 수 있습니다. Domain Controllers, Certificate Servers 등을 제외한 대다수 시스템의 경우 Tier4 Admins 그룹은 로컬 Administrators 그룹의 구성원으로 만들어야 합니다. 그룹 정책 내의 제한된 그룹 기능을 사용하면 중첩 로컬 그룹 멤버십을 자동화할 수 있습니다.

데이터 관리자
이제 데이터 관리 역할에 대해 설명하겠습니다. 이러한 역할은 누적 권한을 사용하여 디자인해야 합니다. 즉, Tier2 Admin에는 일부 추가 권한과 함께 Tier1 Admin의 모든 권한이 포함되어야 합니다. 따라서 이러한 그룹을 낮은 권한 단계부터 살펴보도록 하겠습니다.
Tier1 Admins 그룹은 이전에 만든 디렉터리 개체에 대한 일반 관리를 제공합니다. 이 그룹은 최소한의 교육을 받은 관리자나 암호 재설정과 같은 격리된 작업을 수행하는 관리자를 대상으로 합니다. 이 그룹에는 조직 구성 단위 내에서 사용자 계정 속성 수정, 사용자 계정 암호 재설정, 계정 잠금 해제, 사용자 계정 설정/해제, 워크스테이션 컴퓨터 계정 추가 및 재설정, 비관리 그룹의 그룹 개체 멤버십 수정 등을 수행할 수 있는 권한을 부여합니다.
Tier2 Admins 그룹은 Tier1 Admins에서 관리할 수 있는 경우에만 개체가 생성되도록 하여 개체의 선택적인 관리 및 생성을 설정합니다. 예를 들어 보안 그룹은 그룹 OU에만 만들 수 있습니다. Tier2 Admins는 Tier1 Admin 계정을 추가 및 수정할 수 있을 뿐만 아니라 OU의 사용자 계정을 추가, 수정 및 삭제하고 워크스테이션 컴퓨터 개체를 삭제할 수 있으며 서버, 연락처 및 공유 폴더 개체를 추가, 수정 및 삭제할 수 있습니다.
Regional Admins 그룹에는 해당 지역 OU 구조에 대한 독점적 권한이 부여됩니다. 그러나 디렉터리 내의 다른 지역 OU 구조는 관리할 수 없습니다. Regional Admin 계정은 높은 권한을 갖는 것으로 간주되므로 계정이 별도의 OU 계층에 저장되어 Tier4 Admin 서비스 관리자에 의해 관리됩니다. Regional Admins는 해당 OU 구조 내에서 다른 조직 구성 단위를 제외한 대부분의 개체를 무제한으로 만들 수 있습니다. 따라서 하위 계층에서 관리할 수 없는 개체가 생성될 수 있는 위험이 추가로 발생합니다.
다음은 Tier3 Admins입니다. 많은 조직은 중앙 집중식 또는 상위 계층의 헬프 데스크를 보유하고 있습니다. 이 역할은 데이터 관리자 목록을 채워 모든 Regional Admins에 데이터 관리자 그룹을 제공합니다. 권한은 디렉터리 내에서 특별히 이러한 그룹에 위임되는 것이 아니라 각 Regional Admins 그룹의 중첩 구성원을 통해 생성됩니다. 따라서 모든 데이터 관리자에게 최상위 에스컬레이션 지점뿐 아니라 서비스 관리 그룹으로 에스컬레이션되는 문제를 위한 입력 지점도 제공됩니다.

OU 및 보안 그룹 모델 작성
조직에서 역할을 정의한 후에는 OU와 보안 그룹 모델을 정의해야 합니다. Active Directory에서 OU를 만드는 주된 이유는 권한을 위임하고 그룹 정책 개체를 연결할 수 있는 지점을 만들기 위해서입니다. OU는 디렉터리 내에서 SOM(Scope-Of-Management)을 정의하여 권한을 다양한 수준의 개체로 제한하는 데 사용할 수 있습니다. 따라서 권한 위임을 위해 선택하는 방법은 OU 구조를 구현하는 방식을 결정하는 기본 요소가 됩니다.
이를 염두에 두고 모든 개체를 보유할 도메인 바로 아래에 최상위 OU나 일련의 OU를 만들어야 합니다. 이 OU는 Tier4 Admins의 최고 수준 SOM을 정의하려는 특정 목적을 지니고 있습니다. 최상위 OU를 만들면 디렉터리 서비스에 대한 권한이 도메인 수준이 아닌 OU 수준에서 명시적으로 시작할 수 있습니다. 도메인이 아닌 최상위 OU에서 위임하면 사용자가 기본 제공 도메인 그룹을 조작하여 권한을 상승할 위험이 줄어듭니다.
최상위 OU 아래에는 분리된 데이터 관리 팀이 있는 각 지역이나 업무 단위를 나타내는 별개의 하위 OU 계층을 만들어야 합니다. 각 지역의 하위 OU에는 디렉터리 개체 관리를 위한 확장할 수 없는 일반 OU 계층이 있어야 합니다. 권한 위임 중 대부분이 자동화될 예정이므로 지속적인 관리를 위해서는 통일성이 매우 중요합니다. 이것은 지역마다 고유한 OU를 원할 수 있기 때문에 어려울 수 있습니다. 그러나 IT 관리자는 자신의 입장을 고수해야 하며 한 지역에만 확장이 필요해도 모든 지역의 하위 OU 구조를 확장해야 합니다. 처음에는 어려워 보일 수 있지만 조직이 포괄적인 틀을 제공하면 주변 상황은 시간이 흐를수록 그 틀에 맞추어 가게 됩니다.
마지막으로 별개의 하위 관리 그룹과 계정을 만들어 관리자의 권한 상승 기능을 제거하십시오(각 하위 OU 계층의 Tier1 Admins, Tier2 Admins 및 Regional Admins 그룹). 이러한 계정을 별개의 OU에 배치하면 관리를 해당 수준 이하로 제한할 수 있습니다. 따라서 적절한 권한이 없는 OU에 모든 Tier1 Admins 계정 및 관련 보안 그룹이 상주하면 관리자가 다른 관리자 계정을 가로채거나 다른 관리자의 권한을 자신의 수준으로 상승시킬 수 없습니다. 예를 들어 Domain Admins 그룹의 구성원은 도메인의 다른 사용자 계정을 Domain Admin으로 만들 수 있습니다. 그러나 이 OU 모델이 배치되어 있으면 이러한 위험이 줄어듭니다. 그림 2는 관련 보안 그룹이 포함된 OU 구조의 예를 보여 줍니다.
그림 2 OU 구조 및 관련 보안 그룹
그림 2 OU 구조 및 관련 보안 그룹

보조 계정 설정
위임 모델의 성공 여부는 최소 권한 원칙의 적용에 달려 있습니다. 즉, 보안 사용자가 특정 역할에 필요한 작업만 수행할 수 있도록 해야 하는 것입니다. 그러나 안타깝게도 많은 IT 관리자는 디렉터리 관리와 일상적인 작업(예: 웹 검색 및 전자 메일 읽기)에 동일한 보안 사용자를 사용합니다. 별도의 계정을 보유하면 계층이 지정된 관리자가 실수로 디렉터리 서비스를 손상시키거나 일상적인 응용 프로그램을 통해 디렉터리 관리자를 대상으로 하는 공격에 노출될 가능성이 줄어듭니다.
사용자에게 다시 로그온하도록 요구하지 않고 이 작업을 수행하려면 Secondary Logon 서비스(Runas.exe)를 사용해야 합니다. 이 서비스를 사용하면 사용자가 서버와 워크스테이션에서 스크립트 또는 실행 파일을 실행할 때 대체 자격 증명 집합을 제공하여 자신의 권한을 상승시킬 수 있습니다.
최소 권한의 계정을 사용한다는 개념은 비교적 단순하지만 오래된 IT 관행을 깨기 어려운 기업에서는 이 개념을 적용하기가 힘듭니다. 권한 있는 계정이 일상적인 작업에 사용되지 않도록 할 수 있는 간단한 방법은 Exchange 서버에서 이러한 계정에 메일 액세스 권한을 제공하지 않고 조직 내에서 관리 정책을 통해 이를 강제 수행하는 것입니다. 비교적 단순한 이 방법을 사용하면 해당 계정이 관리 작업 이외의 일상적인 작업에 사용될 가능성이 상당히 줄어듭니다.

권한 위임
위임 모델 개발의 최종 단계는 Active Directory 내에서 권한을 실제로 위임하는 것입니다. 이렇게 하려면 디렉터리 내에 저장된 데이터에 대해 ACE(액세스 제어 항목) 및 ACL(액세스 제어 목록)을 조작해야 합니다. Active Directory 컨테이너의 ACL은 생성 가능한 개체와 해당 개체의 관리 방법을 정의합니다. 권한 위임에는 개체 보기, 지정된 클래스의 하위 개체 만들기, 지정된 클래스의 개체에 대한 특성 및 보안 정보 읽기 등과 같은 기본 개체 작업이 포함됩니다. 이러한 기본 작업 외에도 Active Directory는 다음으로 보내기, 복제 토폴로지 관리 등의 작업을 지원하는 확장 권한을 정의합니다.
이전 단계에서는 정의된 조직 구성 역할에 매핑되는 보안 그룹 만들기에 대해 설명했습니다. 모든 역할에는 하위 OU 구조별로 연결된 보안 그룹이 있습니다. 위임 모델을 구현하려면 이러한 그룹에 디렉터리 개체에 대한 사용 권한을 할당해야 합니다. 이 시점에서는 항목을 새로 개발하고 복잡하게 사용자 지정된 환경을 만들고 싶지는 않을 것입니다. 대신 기본 제공 그룹과 권한을 최대한 활용해 볼 수 있습니다. 특정 역할이 포리스트의 DNS 레코드를 관리해야 하는 경우, Active Directory 통합 DNS에 관련된 컨테이너와 명명 컨텍스트에 대한 권한을 위임하지 않고 도메인의 BUILTIN\DNS Admins 그룹을 사용하면 됩니다. 또한 그룹 정책을 통해 사용자 권한 및 기타 사용 권한을 확장하여 특정 역할이 특정 클래스의 시스템을 관리하는 데 필요한 추가 권한을 제공할 수 있습니다.
위임을 통해 사용 권한을 할당할 때는 디렉터리 내의 ACE 거부 사용을 제한하거나 아예 사용하지 않아야 합니다. 이는 문제 해결 작업에서 복잡해질 수 있습니다. 더 바람직한 방법은 명시적인 ACE 허용을 사용하여 해당 역할을 나타내는 사용자 지정 그룹에 권한을 부여하는 것입니다. Tier4 Admins와 같은 사용자 지정 역할은 해당 역할이 지정한 명시적 권한만 갖습니다.
상속은 Active Directory 보안에 중요하며 특정 ACL이 특정 컨테이너나 하위 컨테이너의 하위 개체에 적용되는 방법을 정의합니다. 상속 가능한 ACE가 대상 개체에 최대한 가까이 적용되도록 하여 항상 상속 범위를 명확히 하십시오. 상위 개체에 적용된 상속 가능한 거부 권한이 최상위 개체에 적용된 상속 가능한 거부 권한보다 우선하며 이것이 바로 ACE 거부가 실용적인 위임을 위해 권장되지 않는 주된 이유 중 하나입니다. 또한 상속 가능한 사용 권한은 개체의 명시적 ACE를 무시할 수 없습니다. 따라서 DACL 쓰기 권한을 제거하여 계층별 관리자가 디렉터리 개체의 임의 액세스 제어 목록을 수정할 수 있는 기능을 제한 또는 제거하는 것이 좋습니다. 이러한 권한은 개체를 암시적으로 만든 사람에게 있습니다. 최우선 규칙은 가능한 경우 관리자가 개체의 DACL을 변경하는 것입니다. 선택 항목과 잠재적 관리 오류를 추가하여 조직이 애써 위임 모델에 투자한 노력을 쓸모없게 하지 마십시오.
Active Directory 위임 모델을 제대로 구현하는 데 사용해야 할 도구가 많습니다. 대부분의 대규모 조직에서 기본 제공 위임 마법사를 사용하여 디렉터리 내의 사용 권한을 할당하는 것은 관리 오류가 발생할 수 있는 매우 위험한 작업입니다. 대신 항상 자동화를 통해 위임 모델이 제대로 문서화되고 지원 가능하도록 해야 하며 설정이 실수로 손실 또는 변경될 경우에 대비하여 복구 옵션을 제공하도록 해야 합니다.
위임 구현에 필요한 기본 도구는 개체의 디렉터리 서비스 ACL을 조작하는 데 사용되는 명령줄 도구인 DSACLS.EXE입니다. 이 도구를 사용하면 상위 개체에서 DACL의 상속 플래그를 지정할 수도 있습니다. 상속 플래그는 이 개체와 하위 개체를 모두 포함하거나 하위 개체만 포함하며 하나의 수준에서만 상속 가능한 사용 권한을 전달합니다. 상속 플래그를 잘못 설정하면 최종적으로 DSACLS 명령이 실패하게 되므로 이 도구를 사용할 때는 반드시 테스트를 수행해야 합니다. 다음은 대상 데모 OU에 컴퓨터 개체 생성 기능을 위임하는 DSACLS 구문의 예입니다.
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS는 개체 유형에 한하여 대소문자를 구분합니다. 즉, "cn=computer"에 "cn=Computer" 개체 클래스의 사용 권한을 위임하려고 하면 실패하게 됩니다(그림 3 참조).
그림 3 대소문자 구분으로 인한 오류
그림 3 대소문자 구분으로 인한 오류 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 대소문자 구분으로 인한 오류
그림 3 대소문자 구분으로 인한 오류 (더 크게 보려면 이미지를 클릭하십시오.)
일부 개체를 만들려면 특정 권한 집합이 필요합니다. 이 작업은 개체의 "필수" 특성과 "선택" 특성으로 수행해야 합니다. 이 개념을 설명하는 데 가장 좋은 비유를 들자면 바로 햄버거 모델입니다. 햄버거는 둥글게 다진 고기와 햄버거 빵이 있어야 햄버거로 간주됩니다. 이러한 품목은 햄버거 개체 클래스의 필수 특성입니다. 피클, 케첩, 겨자 등의 품목은 선택 특성입니다. 개체 클래스를 확장하여 치즈버거를 정의하는 경우에는 필수 특성 목록에 치즈를 추가해야 합니다.
사용자 개체도 이와 동일한 방식으로 작동합니다. 이 모델에 따라 다음 DSACLS 구문을 사용하여 사용자 개체를 만들어 볼까요?
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
관리자는 사용자 개체를 만드는 동안 여러 가지 오류에 직면합니다. 암호 설정을 포함하여 사용자 개체에 필요한 특성을 설정하는 데 필요한 권한을 부여해야 하는데, 이는 다음과 같은 추가 DSACLS 구문에서 설명됩니다.
우선 사용자 클래스의 모든 특성에 대한 일반 읽기/일반 쓰기 권한을 부여하여 쓰기 필수 특성에 대한 사용 권한을 부여해야 합니다.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
그런 다음 암호를 변경하는 확장 권한을 부여합니다.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
그리고 마지막으로 암호 설정한 날짜의 읽기 속성 및 쓰기 속성에 사용 권한을 부여하면 됩니다.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
적절한 권한을 위임한 후에는 정의된 역할이 컨테이너의 DACL에 지정된 관리 개체 클래스로만 제한됩니다. 이전 컴퓨터 개체 예제를 사용하면 Active Directory 사용자 및 컴퓨터의 상황에 맞는 메뉴에 따라 해당 권한을 위임 받은 사용자가 만들 수 있는 새 개체 목록이 제한됩니다(그림 4의 제한된 목록 참조).
그림 4 새 개체의 제한된 목록
그림 4 새 개체의 제한된 목록
DSACLS를 자동화하여 복잡한 권한 위임을 제공할 수도 있습니다. 다음은 특정 컨테이너의 사용자 개체에 대해 일반 주소 특성 조작 권한을 위임하는 데 사용할 수 있는 DSACLS 명령입니다.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
이러한 예는 대부분의 위임 모델에 흔히 발생하며 이전에 정의된 역할과 함께 사용할 수 있습니다.
위임 구현에 사용되는 또 다른 도구인 DSREVOKE.EXE를 사용하면 관리자가 디렉터리 내에서 개체의 특정 보안 사용자에 대해 위임된 권한을 찾아서 제거할 수 있습니다. 이 도구는 매우 유용할 수도 있지만 특정 보안 사용자에게만 적용되고 보안 그룹 내에 중첩된 구성원은 평가하지 않습니다.
이러한 명령줄 도구 외에도 그룹 정책과 함께 사용자 권한 할당 및 제한된 그룹을 사용하는 것이 좋습니다. 앞서 설명한 대로 사용자 권한 할당을 사용하면 IT 관리자가 특정 대상 시스템에서 다양한 사용자 그룹의 하위 수준 권한(예: 원격으로 액세스하여 시스템을 다시 시작하는 권한)을 확장하거나 제거할 수 있습니다. 제한된 그룹을 사용하면 포리스트 내에서 로컬 및 도메인 그룹 구성원을 지정하고 적용할 수 있습니다. 이러한 도구를 함께 사용하면 Active Directory 위임 모델을 자동화하고 구현하는 데 필요한 모든 항목이 제공됩니다.

요약
Active Directory 위임 모델의 개발 작업은 일견 복잡해 보일 수 있지만 대부분의 IT 인프라에 적용할 수 있는 매우 단순한 모델이 존재합니다. 실용적인 위임 모델을 배포할 때 가장 중요한 단계 중 하나는 분명한 역할을 정의하는 것입니다. 정의된 역할은 소수의 신뢰할 수 있는 개인으로 제한해야 합니다. 역할이 너무 많으면 사용되지 않는 역할이 발생하고 너무 적으면 역할이 구분되지 않아 균형을 조정하기가 어렵습니다.
작업을 정의할 때는 빈도, 중요도 및 난이도별로 범주를 나누십시오. 역할을 정의한 후에는 각 역할로 할 수 있는 작업과 할 수 없는 작업을 파악하고 테스트 프로세스를 자동화하는 데 도움이 되는 사례 집합을 개발합니다. 사례를 제대로 준비하면 조직의 관련자들에게 해당 역할을 설명하고 자동화 오류로 인한 위험을 줄이는 데 도움이 됩니다.
마지막으로, 위임 모델을 개발할 때는 항상 실용적으로 접근하는 것이 좋습니다. 간단할수록 지원 가능성이 높아지고 장기적으로 유용한 위임 모델은 Active Directory 환경 내에서 관리 권한을 제어하는 데 매우 유용합니다.
추가 리소스
  • Active Directory의 관리 권한 위임 시 디자인 고려 사항
  • Best Practices for Delegating Active Directory Administration(영문)

Joel Yoker는 Microsoft Federal 팀의 수석 컨설턴트입니다. Joel과 Rob은 모두 미연방 정부 고객을 위한 보안 솔루션을 개발하여 배포하는 업무를 주로 담당하고 있습니다.
Rob Campbell은 Microsoft Federal 팀의 수석 기술 전문가입니다. Joel과 Rob은 모두 미연방 정부 고객을 위한 보안 솔루션을 개발하여 배포하는 업무를 주로 담당하고 있습니다.


 Windows Administration: Windows Vista의 새 그룹 정책 템플릿 검토
Windows Administration Darren Mar-Elia

Windows Vista의 새 그룹 정책 템플릿 검토
한 눈에 보기:
  • ADMX 살펴보기
  • ADMX 파일 편집
  • ADM 파일과 ADMX 파일의 차이점
  • 중앙 저장소 만들기

Windows Vista 이전에는 그룹 정책 내에서 레지스트리 값을 설정할 수 있었으며 이 값은 복잡한 전용 구문을 사용하는 ADM 파일에서 관리했습니다. Microsoft에서 표준 ADM 파일과 함께 제공하는 레지스트리 값보다 더 상세하게 레지스트리 값을 제어하려면
이러한 구문을 이해하고 사용자 지정 ADM 파일을 만들어야 했습니다. 또한 이러한 ADM 파일은 Active Directory® 환경에서 각 GPO(그룹 정책 개체)에 저장되었으며 도메인 내의 모든 도메인 컨트롤러에 이러한 개별 GPO와 관련 ADM 파일이 복제되었습니다.
Microsoft는 Windows Vista™의 릴리스에 맞추어 그룹 정책 기반의 레지스트리 템플릿 분야에서 큰 변화를 시도했습니다. Windows Vista에서는 ADM 파일(이제 ADMX라고 함)의 형식은 물론 이러한 ADMX 파일의 저장 방법까지 모두 변경되었습니다. 이 기사에서는 새로운 ADMX 형식에 대해 살펴보고 ADMX 파일이 기존의 ADM 파일과 어떻게 다른지 알아봅니다. 또한 Windows Vista 환경에서 ADMX 파일의 저장소가 처리되는 방법에 대해서도 알아봅니다.

ADMX의 차이점
Windows NT® 4.0부터 사용된 기존의 ADM 파일과 새로운 ADMX 파일의 가장 큰 차이점이라면, ADMX 파일은 XML 표준을 사용하여 레지스트리 정책 설정을 설명한다는 것입니다. XML 표준을 사용하면 몇 가지 이점을 얻을 수 있습니다. 우선 ADM 구문보다 XML을 편집할 수 있는 도구가 훨씬 다양하고 많습니다. 두 번째로, XML을 스키마화할 수 있으므로 향후 알맞은 위치에 알맞은 태그를 넣을 수 있는 도구를 더욱 쉽게 개발하여 올바른 형식의 ADMX 파일을 만들 수 있습니다. 스키마화할 수 있다는 것은 ADMX 형식과 같은 특정한 XML 적용 분야에서 사용 가능한 요소와 특성을 설명하고 이러한 것들이 구성되는 방법을 설명하는 문서화된 스키마를 사용할 수 있음을 의미합니다. 이에 대해서는 이 기사 후반부의 예제를 통해 살펴보겠습니다.
ADMX 파일과 ADM 파일의 또 다른 중요한 차이점은 기본 ADMX 파일의 문자열 섹션이 언어별 ADMX 파일로 분리된다는 점입니다. ADM 파일에 익숙한 사용자라면 모든 파일 끝에 "[strings]" 태그로 구분된 섹션이 있다는 것을 알고 있을 것입니다. 이 섹션에서 그룹 정책 편집기 및 관리 템플릿을 사용하여 표시할 텍스트 문자열에 값을 할당할 수 있습니다. 예를 들어 특정 정책의 설명 탭을 클릭하면 해당 문자열 섹션 내에 저장된 텍스트가 표시됩니다. 이 경우 해당 문자열이 ADM 파일 내에 저장되기 때문에 다른 언어로 실행되는 Windows® 시스템에서서 ADM을 사용하려면 해당 언어에 대한 문자열 섹션이 있는 ADM 파일을 새로 만들어야 하는 문제점이 있었습니다.
예를 들어 프랑스어 버전의 Windows 사용자가 영어로 작성된 ADM 파일이 사용된 기존 GPO를 편집할 경우에는 문제가 더 복잡해지는 것입니다. 프랑스어를 사용하는 관리자는 그룹 정책 편집기에서 영어로만 GPO를 볼 수 있습니다. Windows Vista에서는 [strings] 섹션을 XML 기반의 ADML(ADM Language) 파일에 분리함으로써 이 문제를 해결했습니다. ADML 파일은 지원되는 모든 언어로 제공될 수 있으며 정책을 저장하는 기본 ADMX 파일을 수정하지 않고도 간편한 변경 작업을 통해 새로운 언어를 지원할 수 있습니다. 더욱 중요한 점은 프랑스어를 사용하는 관리자가 Windows Vista 워크스테이션에서 GPO를 편집할 경우 그룹 정책 편집기에서는 현재 사용되고 있는 프랑스어 버전의 Windows를 검색한 다음 해당 GPO에 맞는 프랑스어 ADML 파일을 자동으로 로드한다는 것입니다.
c:\windows\policydefinitions(그림 1 참조)에서 해당 폴더를 열면 Windows Vista와 함께 설치된 ADMX 및 ADML 파일을 모두 볼 수 있습니다.
그림 1 Windows Vista의 ADMX 파일
그림 1 Windows Vista의 ADMX 파일 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Windows Vista의 ADMX 파일
그림 1 Windows Vista의 ADMX 파일 (더 크게 보려면 이미지를 클릭하십시오.)
그림 1을 보면 파일 목록 맨 위에 en-us라는 폴더가 있습니다. 이 폴더는 영어(미국) 사용에 따른 해당 언어별 폴더이며 ADMX 파일에 대한 ADML 파일이 포함되어 있습니다. 이러한 파일들은 PolicyDefinitions 폴더에서 볼 수 있습니다. 각 ADMX에는 ADML 파일이 한 개씩 존재합니다. 이 기사를 작성한 시점을 기준으로 Windows Vista에는 132개의 ADMX/ADML 파일이 기본으로 포함되어 있습니다. 이는 이전 버전의 Windows와 Windows Vista의 또 다른 큰 차이점이라고 할 수 있습니다. Windows XP에서 만든 GPO에는 보통 다섯 개의 ADM 파일이 포함되어 있었습니다. 이 중 가장 큰 파일인 System.adm에는 정책 제어에 따라 대부분의 Windows 구성 요소에 대한 정책 항목이 포함되어 있었습니다. Windows Vista에서는 ADMX 파일을 기능별로 세분화하여 더 많은 수의 ADMX 파일로 나누는 방법을 선택했습니다. 일반적으로 각 ADMX 파일은 제어판, DNS 클라이언트, Windows 탐색기 등과 같은 단일 Windows 구성 요소와 관련이 있습니다.

ADMX 살펴보기
앞서 설명한 것처럼 XML로 작성된 ADMX는 매우 향상된 부분입니다. 그러나 다수의 관리자들이 XML을 쓰는 방법에 대해 잘 모르고 있으며 정책을 확장하기 위해 ADMX에 사용되는 스키마에 대해서만 이해하고 있는 실정입니다. 사용자 지정 ADMX를 만드는 방법은 이 문서에서 다루기에는 광범위한 주제이므로 여기에서는 ADMX가 어떻게 만들어지는지 간단히 살펴보겠습니다.
메모장을 비롯한 모든 텍스트 편집기에서 ADMX 또는 ADML 파일을 열 수 있지만 이러한 편집기에서 XML 구문을 지원하지 않는다면 별로 도움이 되지 못할 것입니다. 필자는 Visual Studio®를 사용하는데 여기에 포함된 IntelliSense®라는 기능을 사용하면 특정 요소를 쉽게 처리할 수 있습니다. 그림 2에서는 Windows Vista와 함께 제공되는 ADMX의 처음 몇 줄을 보여 줍니다.
Figure 2 ADMX 파일에 포함된 일부 XML (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
XML에 익숙하지 않다면 위의 그림이 매우 이상하게 보일 수도 있습니다. 그러나 모든 ADMX 파일에서 이러한 XML 요소를 많이 볼 수 있습니다. 예를 들어 policyNamespaces 요소는 모든 ADMX 파일 내에 있는 이 ADMX 파일을 고유하게 식별합니다.
이전 버전의 Windows에서 사용자 지정 ADM 파일을 만들 경우에는 그룹 정책 편집기에 나타나는 정책 설정을 정의하기 위해 Category, Policy, ListBox 및 ActionList와 같은 여러 가지 태그를 적용했습니다. ADMX 형식에서도 대부분의 태그는 거의 변경되지 않거나 약소한 수준으로 변경되었음에도 불구하고 XML로 표현되기 때문에 매우 다른 형태로 보입니다. 예를 들어 그룹 정책 문제 해결을 위해 Windows 내에서 다양한 유형의 로깅을 설정하는 사용자 지정 ADM 파일을 만들었다고 가정해 보겠습니다. 이 사용자 지정 ADM 섹션은 그림 3에서 볼 수 있습니다. 이 파일을 그림 4와 같이 새로운 ADMX 형식으로 전환했습니다.
Figure 4 ADMX 파일로 변환된 ADM 파일 (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 사용자 지정 ADM 파일 (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
여러 가지 면에서 이 ADMX 조각은 ADM보다 훨씬 이해하기 쉽고 간결합니다. 정책 요소는 해당 정책이 수행하는 내용(폴더 리디렉션 로깅)을 지정합니다. 접두사 $(string.이 붙은 특성은 해당 ADML 문자열 요소에 대한 참조입니다. 키 및 값 이름 특성은 이 정책에 영향을 받는 레지스트리 키 및 값을 지정합니다. parentCategory 요소는 이 정책이 그룹 정책 편집기 관리 템플릿 계층에서 나타나는 위치를 제어합니다. supportedOn 요소는 이 정책에 반영된 운영 체제 버전이 무엇인지 나타내고 이로 인해 enabledvalue 및 disabledvalue 요소는 이 정책이 사용 및 사용 안 함으로 설정되는 경우 레지스트리에 들어갈 값을 지정합니다.
이것은 매우 간단한 설정/해제 정책입니다. ADM 구문에서와 마찬가지로 그룹 정책 편집기 내에서 보다 복잡한 UI 요소를 만들 수 있습니다. ADMX에서 이를 수행할 경우에는 구문에 더 많은 내용을 추가하게 됩니다. 즉, ADML 파일에서 UI 요소의 텍스트 레이블이 있는 부분을 참조하는 프레젠테이션 특성을 구문에 사용합니다. 그러나 ADMX 구문이 그리 복잡하지는 않습니다. 한 가지 기억해야 할 것은 ADM에서 ADMX로 오면서 일부 태그 이름이 변경되었다는 점입니다. 예를 들어 ADM에서 사용하는 "edittext" 및 "listbox" 태그의 경우 ADMX에서는 ADMX 파일 내에서 "text" 및 "list"로 사용되는 것을 볼 수 있습니다. 이러한 요소는 텍스트를 지정하는 ADML 파일에서 해당 항목을 갖게 되며, 이 텍스트는 해당 요소와 함께 표시됩니다.
이미 아는 내용일 수도 있지만 관리자는 기존의 사용자 지정 ADM 파일을 Windows Vista 그룹 정책 개체 편집기에 로드할 수 있습니다. 필자는 Microsoft에서 사용자 지정 ADM 파일을 ADMX 구문으로 전환할 수 있는 유틸리티를 제공할 계획이 있는지에 대해 이따금 질문을 받기도 합니다. 실제로 Microsoft에서는 FullArmor Corp.과의 협력을 통해 ADMX Migrator라는 전환 도구를 무료로 배포하고 있습니다. 이 도구는 두 가지 기능을 수행합니다. 우선 기존의 사용자 지정 ADM 파일을 ADMX 형식으로 전환해 줍니다. 그림 5에서는 이 도구를 사용하여 필자가 사용한 사용자 지정 gpolog.adm 파일을 전환하는 것을 보여 줍니다.
그림 5 ADMX Migrator
그림 5 ADMX Migrator (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 ADMX Migrator
그림 5 ADMX Migrator (더 크게 보려면 이미지를 클릭하십시오.)
두 번째로 ADMX Migrator를 사용하면 ADMX Editor에서 새로운 ADMX 파일을 처음부터 만들 수 있습니다. 이 도구는 go.microsoft.com/fwlink/?LinkID=77409(영문)에서 다운로드할 수 있습니다.

ADMX 저장소
주목할 만한 또 다른 변화로 ADMX 및 ADML 파일을 저장하는 방법을 들 수 있습니다. Windows Vista 이전 버전의 Windows에서는 새 GPO를 편집하는 경우 사용자가 편집 작업을 수행하는 로컬 워크스테이션에서 Active Directory 도메인의 도메인 컨트롤러에 있는 GPO의 SYSVOL 부분으로 ADM 파일이 자동으로 복사되었습니다. 이러한 ADM 파일은 이후 만들어지는 모든 GPO에 대해 도메인 내 각 DC에 복제되었습니다. 위와 같은 프로세스에서는 많은 네트워크 대역폭과 디스크 저장소가 낭비되었으며, 특히 수천 개의 GPO가 있는 대규모 환경에서 이러한 경향이 뚜렷했습니다. Windows Vista에서는 이러한 소모적인 프로세스를 개선했습니다. 기본적으로 Windows Vista 워크스테이션에서 Active Directory 기반의 GPO를 만들 경우 그룹 정책 편집기에 나타나는 관리 템플릿 정책은 사용자가 GPO를 편집하고 있는 컴퓨터의 c:\windows\policydefinitions 폴더에서 로드됩니다.
ADMX 및 ADML 파일은 SYSVOL에 복사되지 않으며 로컬에서만 참조됩니다. 따라서 그룹 정책 환경에서 ADM 파일로 인해 나타나는 저장소 및 네트워크 부담이 해소됩니다. 그러나 이보다 더욱 개선된 사항이 또 있습니다. Windows Vista에서는 관리 템플릿을 위한 리포지토리인 중앙 저장소를 지원하므로 GPO를 편집하는 사용자에 관계없이 GPO 편집에 사용되는 ADMX 파일을 효율적으로 제어할 수 있게 되었습니다. 이렇게 하려면 모든 공식적인 ADMX 및 ADML 파일(모든 사용자 지정 파일 포함)을 네트워크 위치에 복사합니다. 그러면 이후에 Windows Vista 워크스테이션에서 그룹 정책을 편집할 때 개별적인 로컬 버전이 아니라 네트워크 기반의 버전을 모두 참조하게 됩니다. 도메인 하나에 중앙 저장소를 한 번만 설정해 주면 되므로 작업이 간편합니다. 자세한 단계를 보려면 "중앙 저장소 만들기"를 참조하십시오.

요약
Windows Vista의 ADMX 형식은 기존 OS 버전에서 사용된 ADM 파일의 문제점을 눈에 띄게 개선한 새로운 형식입니다. XML을 사용함으로써 이러한 파일을 편집하고 검색할 수 있는 더 나은 프레임워크를 얻게 됩니다. 언어별 문자열을 개별 파일로 분리함으로써 완벽한 다국어 그룹 정책 편집이 가능해졌을 뿐 아니라 중앙 저장소에서는 ADM 파일 복사본이 저장된 모든 GPO를 일일이 복사하고 업데이트해야 할 필요가 없어졌습니다. 이러한 이점을 제공하는 ADMX를 활용해 보시기 바랍니다.
중앙 저장소 만들기
중앙 저장소를 만드는 방법은 비교적 간단합니다. 간단한 다음 단계를 따라 Active Directory 도메인 내부에 하나의 저장소를 만들어 보십시오.
1단계: 탐색기를 열고 사용자 환경의 PDC 에뮬레이터 DC에 있는 SYSVOL 공유로 이동합니다. 모든 DC를 사용할 수 있으나 PDC 역할 소유자는 일반적으로 모든 그룹 정책 변경 사항이 집중된 위치에 있습니다.
2단계: SYSVOL 아래의 Policies 폴더를 찾은 다음 PolicyDefinitions라는 이름으로 새 폴더를 만듭니다.
3단계: Windows Vista 워크스테이션에서 언어별 ADML 폴더(예: 영어(미국) 컴퓨터의 경우 en-us 폴더)를 비롯하여 C:\windows\policydefinitions 폴더의 내용을 새 PolicyDefinitions 폴더로 복사합니다.
ADMX 및 ADML 파일이 중앙 저장소 폴더로 복사되면 Windows Vista의 그룹 정책 개체 편집기에서 해당 파일을 참조하게 되며 로컬로 저장된 파일은 무시하게 됩니다.

Darren Mar-Elia는 Microsoft 그룹 정책 MVP이며 유명한 그룹 정책 사이트인 www.gpoguy.com의 제작자이자 Microsoft Windows Group Policy Guide(Microsoft Press, 2005년)의 공동 저자이기도 합니다. 또한 그는 SDM Software, Inc.의 CTO이자 설립자입니다. 문의 사항이 있으면 Darren@gpoguy.com으로 연락하십시오.


 Windows Administration: 그룹 정책 문제 해결을 위한 안내
Windows Administration Derek Melber

그룹 정책 문제 해결을 위한 안내
한 눈에 보기:
  • 일반 GPO 문제
  • 그룹 정책 규칙
  • GPO 문제 해결
  • 문제 해결 도구

Microsoft Active Directory는 수많은 IT 인프라의 중요한 구성 요소가 되어 왔습니다. Active Directory의 가장 중요한 기능 중 하나는 그룹 정책으로, 이를 통해 관리자는 도메인 컨트롤러, 구성원 서버 및 데스크톱을 중앙 집중 방식으로 관리할 수 있습니다.
그룹 정책은 분명히 여러 가지 장점을 제공하지만 한 가지 작은 단점도 있습니다. 대규모 조직에서 설계 및 구현이 복잡할 수 있으며 문제가 발생할 경우 이를 해결하기 어렵습니다. 이 문서에서는 그룹 정책 구성 방법과 그룹 정책 문제를 해결하는 방법을 살펴보겠습니다. 이 문서를 읽고 나면 거의 모든 그룹 정책 문제를 해결하는 데 필요한 방법을 모두 알게 될 것입니다.

문제가 되는 설정
그룹 정책에는 가변적인 요소가 많이 있으며, 특히 전체 Active Directory® 설계 및 구현과 상호 작용하는 방식과 관련해서는 더욱 그러합니다. 여러 가지 유형의 액세스 및 네트워크 문제를 해결하기 위한 방법을 찾을 때 Active Directory와 그룹 정책 구현의 기본 사항을 항상 염두에 두어야 합니다. 그룹 정책 문제 해결을 위해 잘못 구성되었을 수 있는 그룹 정책 설정부터 살펴본 다음 그룹 정책 오작동을 일으킬 수 있는 보다 복잡한 문제를 검토해 보겠습니다.
그룹 정책 설정은 Active Directory 관리자가 관리 템플릿 파일(ADM 또는 ADMX 파일) 및 그룹 정책 개체 편집기나 GPEdit(gpedit.msc를 실행하여 시작됨)를 사용하여 확인할 수 있습니다. 관리자는 GPEdit를 사용하여 GPO(그룹 정책 개체) 파일 또는 GPO를 만듭니다. GPO는 Active Directory 구조 내에서 컴퓨터와 사용자에게 적용되거나 적용되지 않도록 구성됩니다. 제대로 작동하기 위해 GPO가 따라야 할 몇 가지 규칙이 있는데 지금부터 이 규칙을 살펴보겠습니다.
GPO를 연결해야 함 GPO를 새로 만들 경우 이 GPO가 Active Directory 내의 노드에 연결되지 않을 수 있습니다. GPO를 편집하거나 수정해도 이 GPO가 노드에 연결될 때까지는 개체에 영향을 주지 않습니다. GPO가 제대로 연결되었는지 확인하려면 그림 1에 나와 있는 GPMC(그룹 정책 관리 콘솔) 정보 창을 확인하십시오.
그림 1 명확하게 표시된 GPO 링크
그림 1 명확하게 표시된 GPO 링크 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 명확하게 표시된 GPO 링크
그림 1 명확하게 표시된 GPO 링크 (더 크게 보려면 이미지를 클릭하십시오.)
GPO는 올바른 개체를 대상으로 해야 함 이미 알고 있듯이 그룹 정책은 Active Directory의 올바른 개체를 대상으로 해야 합니다. 그러나 문제 해결 과정에서 이 사항을 간과하는 경우가 종종 있습니다. GPO 내에는 컴퓨터와 사용자라는 두 개의 주요 범주가 있습니다. GPO를 구성할 때는 GPO가 컴퓨터 개체용인지, 아니면 사용자 개체용인지 주의해야 합니다. 그래야 GPO가 연결된 OU(조직 구성 단위)에 올바른 개체 유형이 배치되었는지 확인할 수 있습니다.
GPO는 그룹에 적용되지 않음 GPO는 Active Directory 보안 그룹 개체에 적용할 수 없습니다. GPO 설정에서 구성할 수 있는 단 두 가지 개체는 컴퓨터와 사용자입니다. GPO는 그룹 구성원을 통해 개체를 구성할 수 없습니다. 예를 들어 그림 2와 같이 GPO가 Finance OU에 연결되어 있는 경우 이 설정의 영향을 받게 되는 유일한 개체는 Derek과 Frank뿐입니다. GPO의 설정은 Marketing 그룹의 구성원 자격이 누구에게 있든 이 그룹의 구성원에게는 영향을 주지 않습니다.
그림 2 Finance OU와 그 내부 개체
그림 2 Finance OU와 그 내부 개체 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Finance OU와 그 내부 개체
그림 2 Finance OU와 그 내부 개체 (더 크게 보려면 이미지를 클릭하십시오.)
대상 개체는 GPO 경로에 있어야 함 GPO 설정이 개체에 영향을 주지 않는다는 점과 더불어 염두에 두어야 할 다른 중요 설정 하나는 개체가 GPO의 SOM(관리 범위) 내에 있어야 한다는 것입니다. 즉, 개체는 GPO가 연결된 노드나 자식 노드에 있어야 합니다. 예를 들어 그림 3처럼 Marketing OU의 어떠한 개체도 Finance OU에 연결된 GPO의 영향을 받지 않습니다. GPO의 SOM은 GPO가 연결된 노드에서 시작하여 Active Directory 구조 전체에 적용됩니다.
그림 3 OU가 같은 수준에 있을 경우 GPO는 연결되어 있는 OU에만 적용됨
그림 3 OU가 같은 수준에 있을 경우 GPO는 연결되어 있는 OU에만 적용됨 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 OU가 같은 수준에 있을 경우 GPO는 연결되어 있는 OU에만 적용됨
그림 3 OU가 같은 수준에 있을 경우 GPO는 연결되어 있는 OU에만 적용됨 (더 크게 보려면 이미지를 클릭하십시오.)
GPO를 활성화해야 함 GPO를 생성할 때 GPO는 대상 개체를 수정하도록 구성되지 않습니다. 그러나 컴퓨터와 사용자 부분 모두에 대해 활성화되어 있습니다. 이러한 부분 중 하나가 비활성화된 경우 이를 추적하기가 어려울 수 있습니다. 따라서 적용되지 않는 GPO 문제를 해결할 경우에는 GPO의 일부 또는 전체가 비활성화되었는지 확인하는 것이 좋습니다. 이를 위해서는 GPMC의 그룹 정책 개체 | 계정 정책에서 GPO 상태를 확인하면 됩니다.
일부 설정을 적용하려면 다시 부팅해야 함 GPO 설정이 제대로 작동하지 않을 경우 이는 GPO의 고유한 처리 방식 때문일 수 있습니다. GPO 백그라운드 새로 고침이 정기적으로 트리거될 경우 GPO 설정 전체가 아닌 일부만 처리될 수 있습니다. 따라서 설정을 만들었어도 해당 설정이 아직 적용되지 않았을 수 있습니다. 포그라운드 정책으로 분류되는 몇 가지 설정이 있는데, 이러한 설정은 컴퓨터를 다시 부팅하거나 사용자가 로그 오프한 후 다시 로그인하는 경우에만 적용됩니다. 이와 같은 방식으로 작동하는 설정으로는 소프트웨어 설치, 폴더 리디렉션 및 스크립트 응용 프로그램이 있습니다.

설정의 동기식 및 비동기식 적용
GPO 내에서 부팅할 때와 로그온할 때 정책이 적용되는 방식을 구성할 수 있습니다. 정책이 적용되고 있는 동안에 데스크톱에 즉시 액세스하도록 하거나 모든 정책이 적용된 후 데스크톱에 액세스하도록 변경할 수 있습니다. 그림 4는 각 운영 체제의 기본 동작을 보여 줍니다. 이 동작을 변경하려는 경우 다음과 같은 정책 설정을 수정할 수 있습니다.
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 클라이언트의 기본 처리 (Close Figure 4)

운영 체제 | 시작 | 로그온 | 정책 새로 고침
Windows 2000 | 동기식 | 동기식 | 비동기식
Windows XP Professional | 비동기식 | 비동기식 | 비동기식
Windows Server 2003 | 동기식 | 동기식 | 비동기식
대부분의 관리자는 모든 정책이 적용된 후 사용자가 데스크톱에 액세스할 수 있도록 정책을 동기식으로 적용하는 것을 선호합니다. 이 경우 사용자가 작업을 수행하기 전에 모든 보안 및 구성 설정이 적용됩니다. 그러나 이것은 로그온 속도 향상을 위해 최적화된 Windows® XP Professional의 기본 상태가 아닙니다.

기본 상속 변경
GPO 처리의 기본 상속을 변경하는 데 사용할 수 방법에는 네 가지가 있습니다. 이러한 옵션은 그 영향력이 강력하고 그룹 정책 처리 동작을 크게 변경할 수 있으므로 가급적 사용을 자제해야 합니다. 이러한 옵션은 문제를 해결하기도 매우 어렵습니다. 기본 상속을 변경하는 옵션에는 다음 네 가지 설정과 구성이 포함됩니다.
  • 정책의 상속을 금지
  • GPO 적용
  • ACL(액세스 제어 목록)에 대한 GPO 필터링
  • WMI(Windows Management Instrumentation) 필터
이러한 설정은 제한적으로 사용해야 하므로 언제 사용되는지 쉽게 문서화할 수 있습니다. 이러한 옵션의 사용 여부는 GPMC에서 확인할 수 있습니다. 상속 금지는 GPMC의 도메인 또는 OU(조직 구성 단위) 노드에서 수행되고, GPO 적용, ACL 필터링 및 WMI 필터링은 각 GPO에서 설정됩니다.
또는 대상 컴퓨터에서 Gpresult 명령을 실행하여 이러한 설정이 정책 적용을 금지하고 있는지 알 수 있습니다. 정책 적용 결과를 보다 자세히 표시하려면 Gpresult 명령에 /v 스위치를 추가하십시오. 그러면 결과가 자세히 표시됩니다.

ADM 템플릿 문제
관리 템플릿 섹션에서 GPO 설정을 구성하려고 하는 경우 ADM 템플릿을 사용하고 있는 것입니다. 운영 체제와 함께 제공되는 ADM 템플릿 외에도 GPO에 사용할 고유한 템플릿을 사용자 지정할 수 있습니다. ADM 템플릿의 코드는 그룹 개체 편집기의 관리 템플릿 노드 아래에 폴더와 정책을 만듭니다. 그러나 ADM 템플릿이 손상 또는 누락되거나 제대로 구성되지 않은 경우 편집기에 설정의 일부 또는 전체가 표시되지 않을 수 있습니다. 다음은 ADM 템플릿을 사용할 때 주의해야 할 몇 가지 다른 문제입니다.
ADM 템플릿 누락 GPO를 편집할 때 사용자 지정 ADM 템플릿의 일부 설정이 편집기에 표시되지 않을 경우 ADM 템플릿을 GPO로 가져와야 합니다. 이를 위해서는 편집기에서 관리 템플릿 노드를 마우스 오른쪽 단추로 클릭하고 템플릿 추가/제거를 선택하면 됩니다.
기본 설정 누락 사용자 지정 GPO에서 만들 수 있는 두 가지 설정 유형에는 기본 설정과 정책이 있습니다. 정책은 레지스트리에서 네 개의 하위 키 중 하나로 분류되는 기본 Microsoft 설정으로, "Policies"라는 텍스트로 끝납니다. 기본 설정은 네 개의 하위 키 중 하나로 분류되지 않는 "이전 스타일"의 레지스트리 수정 사항으로 한 번 구성되면 되돌리기 어렵습니다. 이러한 기본 설정은 기본적으로 편집기에 표시되지 않습니다. 따라서 도구 모음의 보기 메뉴를 사용하여 기본 설정이 표시되도록 해야 합니다. 이 메뉴에서 필터링을 선택한 다음 "완전히 관리가 가능한 정책 설정만 표시" 확인란을 선택하십시오. 그러면 가져온 사용자 지정 ADM 템플릿에 구성되어 있는 기본 설정이 즉시 표시됩니다.

편리한 도구
그룹 정책 문제를 추적하는 데 도움이 되는 여러 가지 도구가 있습니다. 운영 체제에 포함되어 있는 도구도 있고 다운로드하여 설치할 수 있는 도구도 있습니다. 다음으로 자신의 작업에 알맞은 도구를 선택할 수 있도록 적절한 도구에 대해 설명하겠습니다.
Dcgpofix 두 개의 기본 GPO인 기본 도메인 정책과 기본 도메인 컨트롤러 정책 중 하나에서 문제가 발생할 수 있습니다. 이 중 하나 둘 모두 손상되었는데 구성이 어려워 이를 해결할 수 없거나 다른 알 수 없는 문제가 발생한 경우 dcgpofix 도구를 사용하여 GPO를 기본 상태로 되돌릴 수 있습니다. 이 도구는 Windows Server® 2003에 포함되어 있으며 Windows 2000 도메인 컨트롤러에서는 이 도구 대신 Recreatedefpol을 사용해야 합니다. 이 도구를 사용하면 사용자 지정된 설정은 모두 손실됩니다.
Recreatedefpol 이 도구는 Dcgpofix와 비슷하지만 Windows 2000 서버용이며 두 개의 기본 GPO를 새로 설치된 상태로 되돌릴 수 있습니다. 이 도구는 일상적인 GPO 유지 관리용이 아니라 재해 복구용으로만 사용해야 하며, 다운로드(영문) 가능합니다.
이벤트 뷰어 이벤트 뷰어에는 그룹 정책과 관련된 다양한 정보가 포함되어 있습니다. 그러나 그룹 정책에 대한 항목을 찾으려면 여러 로그 파일을 모두 살펴봐야 합니다. 이벤트 뷰어에서는 정책 적용, 정책 복제, 정책 새로 고침과 관련된 모든 항목을 찾을 수 있으며 이러한 항목은 모두 문제를 추적할 때 도움이 됩니다. 이벤트 로그에 있는 특정 그룹 정책 오류에 대한 정보가 충분하지 않을 수 있으며 이 경우 식별할 수 없는 오류가 나타나면 언제든지 TechNet을 검색할 수 있습니다.
Gpresult 이 도구는 대상 컴퓨터에서 로컬로만 실행할 수 있으며 RSOP(정책 결과 집합), 차단된 GPO, GPO 권한 등에 대한 정보를 제공합니다. /v 스위치와 함께 이 명령을 사용하면 컴퓨터에 영향을 주는 GPO 및 현재 로그온 세션에 연결된 사용자 계정에 대한 자세한 정보가 표시됩니다.
Gpupdate 새로운 GPO 설정을 구현하고 있거나 모든 GPO 처리가 이루어지도록 하려는 경우 Gpupdate 도구를 사용할 수 있습니다. 이 도구는 운영 체제(Windows XP 이상)와 함께 제공되는 명령줄 도구로서, 실행하면 백그라운드 새로 고침이 트리거되어 이 유형의 새로 고침에 영향을 받는 모든 GPO 설정이 적용됩니다. /force 스위치를 추가하면 마지막 새로 고침 이후로 GPO가 변경되지 않은 경우에도 모든 GPO 설정이 다시 적용됩니다. Gpresult 명령을 실행하기 전에 이 명령을 실행하면 GPO 문제를 추적하는 데 크게 도움이 됩니다.
Gpotool GPO는 GPO가 처음으로 변경된 도메인 컨트롤러에서 다른 모든 도메인 컨트롤러로 복제되므로 복제가 실패하거나 효율적으로 수렴되지 않을 수 있습니다. 그 결과 변경 사항이 대상 컴퓨터에 일관성 없게 적용되거나 잘못 적용될 수 있습니다. Gpresult 및 RSOP와 같은 도구는 어떤 GPO가 적용되었는지 확인하는 데 도움이 되고 Gpotool은 각 도메인 컨트롤러의 GPO가 일관성이 있는지 확인하는 데 도움이 됩니다. 이 도구는 Windows Server 2003 Resource Kit(go.microsoft.com/fwlink/?LinkId=77613)에 포함되어 있습니다.
Replmon 한 도메인 컨트롤러에서 다른 도메인 컨트롤러로 수행되는 GPO 복제 문제를 해결할 때는 복제 작업을 파악하는 데 사용할 수 있는 도구를 아는 것이 중요합니다. 복제해야 할 GPO 부분이 두 개이므로 해결해야 할 부분도 두 개입니다. 첫 번째 부분은 각 도메인 컨트롤러의 SYSVOL 내용으로, 이것은 FRS(파일 복제 서비스)에 의해 제어됩니다. 복제 간격을 트리거할 수 있도록 서비스를 설정하고 해제하는 것을 제외하고는 이러한 복제를 제어하기 위해 수행할 수 있는 작업이 많지 않습니다. GPO의 두 번째 부분은 Active Directory에 저장되며 Active Directory 복제에 의해 제어됩니다. 이 복제는 Active Directory 사이트 및 서비스를 사용하여 같은 Active Directory 사이트에 있는 도메인 컨트롤러 간에 제어할 수 있습니다. 그러나 다른 Active Directory 사이트에 있는 도메인 컨트롤러 간에 복제를 트리거해야 하는 경우에는 Replmon과 같은 도구를 사용해야 합니다. Replmon은 사이트 간에 Active Directory 데이터베이스를 강제로 복제할 수 있지만 Active Directory 사이트 및 서비스는 그럴 수 없습니다. 따라서 Active Directory에 저장된 그룹 정책 정보에 일치하지 않는 부분이 있을 경우 Replmon으로 복제 프로세스를 트리거하여 해당 정보를 각 도메인 컨트롤러에 가져올 수 있습니다. Replmon은 Resource Kit 및 Windows XP 지원 도구에 포함되어 있으며 go.microsoft.com/fwlink/?LinkId=77614에서 다운로드할 수 있습니다.
RSOP 명령줄 도구 Gpresult와 매우 유사한 RSOP는 모든 GPO에 의해 적용된 설정을 확인할 수 있는 그래픽 인터페이스를 제공합니다. RSOP.MSC는 Windows XP Professional 및 Windows Server 2003에서 기본적으로 제공되는 도구로서, 그림 5와 같이 적용된 모든 정책 설정의 결과를 그룹 정책 개체 편집기와 비슷한 형식으로 제공합니다.
그림 5 정책 결과 집합 도구
그림 5 정책 결과 집합 도구

요약
그룹 정책 문제를 해결하는 것은 결코 만만한 작업이 아닙니다. 실제로 이 문서에서 설명한 것처럼 그룹 정책은 상당히 복잡할 수 있습니다. 문제 해결을 위해 그룹 정책에 접근할 경우 그룹 정책의 핵심 구조와 전반적인 프로세싱을 이해해야 합니다. 또한 GPO의 업데이트, 복제, 처리 및 적용 방식도 이해해야 합니다. 이러한 개념을 잘 알고 있다면 특정 그룹 정책 문제를 해결하는 것이 한결 쉬워질 수 있습니다. 이 문서에 설명된 지침에 따라 도구를 적절하게 사용하면 발생할 수 있는 모든 그룹 정책 문제를 해결할 수 있습니다.

Derek Melber는 Microsoft 자회사인 DesktopStandard의 교육, 인증 및 컴플라이언스 솔루션 담당 이사이자 Microsoft Windows Group Policy Guide(Microsoft Press, 2005)의 공동 저자로서, Windows 보안 감사에 대한 여러 권의 책을 저술했습니다(www.theiia.org). 문의 사항이 있으면 derekm@desktopstandard.com으로 연락하시면 됩니다.


 Windows Administration: MOM을 사용하여 Active Directory 모니터링
Windows Administration John Hann

MOM을 사용하여 Active Directory 모니터링
한 눈에 보기:
  • Active Directory 관리 팩
  • MOM을 위한 사용자 지정 팁
  • 경고 조정

관리 팩은 Microsoft Operations Manager(MOM) 2005의 핵심 요소로서, MOM 2005를 여타 관리 제품과 구분 짓는 이유이기도 합니다. 관리 팩을 통해 규칙, 보고서, 작업 및 보기를 한 곳에 통합하는 MOM은 특정 응용 프로그램이나 Active Directory 같은 서비스에 제한하여 사용할 수도 있습니다.
Microsoft 제품 팀은 응용 프로그램을 개발할 때 관리 팩도 만들어 MOM에 제품 팀의 상세한 제품 지식이 반영되도록 합니다. 관리 팩은 고유한 IT 환경에 맞게 사용자 지정할 수도 있습니다. 이렇게 하면 특정 서버 및 응용 프로그램 환경을 기반으로 해당 제품을 관리하고 모니터링하는 규칙이 만들어집니다.
Active Directory®용의 특정 관리 팩 이외에도 Windows Server® Base Operating System, DHCP(Dynamic Host Configuration Protocol), DNS, FRS(파일 복제 서비스) 등의 디렉터리 서비스 상태를 모니터링하는 여러 가지 관리 팩이 있습니다. MOM을 통해 Active Directory를 완벽하게 관리하는 방법을 명확히 이해할 수 있도록 이러한 관리 팩을 보다 자세히 살펴보겠습니다.

DHCP 관리 팩
DHCP 서비스 관리 팩은 Windows NT®, Windows® 2000 및 Windows Server 2003에서 실행되는 DHCP 서비스를 모니터링합니다. DHCP를 모니터링하면 클라이언트에게 네트워크 연결 문제가 있는지 확인할 수 있고, 해당 환경에서 실행되는 무단 DHCP 서버를 가려낼 수도 있습니다. 이 관리 팩의 다운로드 패키지에는 모니터링 시나리오, 배포, 규칙 및 보고서에 관한 가이드가 포함되어 있습니다. 추가 설명서 및 지침은 TechNet MOM 2005 웹 사이트(microsoft.com/technet/prodtechnol/mom/mom2005)(영문)에서 확인할 수 있습니다.
DHCP 서비스가 실행되는 Windows가 최신 버전일수록 관리 작업에 사용할 수 있는 MOM 2005의 도구와 기능이 많아집니다. 따라서 Windows NT DHCP 서버보다는 Windows Server 2003 DHCP 서버에 대해 더 많은 정보를 얻을 수 있는 것입니다. 예를 들어 Windows Server 2003에서 실행되는 DHCP 서버의 경우 대범위 모니터링이 가능한 반면, Windows 2000 DHCP 서버에서는 DHCP 관리 팩이 일반 범위에 대해서만 모니터링합니다. 모니터링 스크립트의 매개 변수로 제외 범위를 지정하면 일부 범위를 모니터링에서 제외할 수도 있습니다.
앞서 언급했듯이 DHCP 관리 팩은 Windows NT, Windows 2000 Server 및 Windows Server 2003에서 실행되는 DHCP 서버를 지원합니다. 컴퓨터 그룹은 해당 운영 체제 버전 및 서버가 DHCP 서버 서비스를 호스트하는지 여부를 사용하는 수식을 통해 채워집니다.
DHCP 관리 팩은 낮은 권한 수준의 구성을 지원하지 않으며, 에이전트 작업 계정은 로컬 Administrators 그룹의 구성원이어야 합니다. 또한 에이전트 없는 모니터링이 지원되기는 하지만 작업은 에이전트 없는 구성에서 지원되지 않습니다. 그림 1은 DHCP 관리 팩에서 사용할 수 있는 보고서를 보여 줍니다.
Figure 1 DHCP 서비스 보고서 (Close Figure 1)

모든 DHCP 서버
권한이 부여된 모든 DHCP 서버
성능 기록 - 활성 대기열 길이
성능 기록 - 충돌 검사 대기열 길이
성능 기록 - 초당 거부 횟수
성능 기록 - 초당 검색 횟수
성능 기록 - 패킷당 밀리초(평균)
성능 기록 - 초당 NACK
성능 기록 - 범위 없는 주소
성능 기록 - 사용 중인 범위 주소
성능 기록 - 대범위 없는 주소
성능 기록 - 사용 중인 대범위 주소
DHCP 관리 팩은 go.microsoft.com/fwlink/?LinkId=79527(영문)에서 다운로드할 수 있습니다.

DNS 관리 팩
DNS(도메인 이름 서비스) 관리 팩은 Windows 2000 Server 및 Windows Server 2003에서 실행되는 DNS 서비스를 모니터링합니다. DNS 관리 팩은 Active Directory의 전체 구현 상태를 모니터링하는 데 없어서는 안 될 부분이므로 MOM 2005를 사용하여 DNS를 모니터링하는 것은 매우 중요합니다. 이 DNS 관리 팩은 이름 확인 문제, 데이터베이스 문제, 레지스트리 문제, 런타임 이벤트 및 오류, 관련 성능 카운터 등을 모니터링합니다.
Windows 2000 Server의 경우 WMI(Windows Management Instrumentation) DNS 공급자를 설치해야 합니다. 그러면 DNS 관리 팩이 정보 및 테스트를 위해 WMI DNS 네임스페이스를 쿼리할 수 있습니다.
컴퓨터 그룹은 해당 운영 체제 버전 및 서버가 그룹 구성원을 확인하기 위해 DHCP 서버 서비스를 호스트하는지 여부를 사용하는 수식을 통해 채워집니다. DNS 관리 팩은 Windows Server 2003에서만 낮은 권한 수준을 지원합니다. Windows 2000에서 작업 계정은 로컬 Administrators 그룹의 구성원이어야 하고, Windows Server 2003에서는 작업 계정이 로컬 Users 및 Performance Monitor Users 그룹의 구성원이어야 합니다. 또한 작업 계정에는 감사 및 보안 로그 관리(SeSecurityPrivilege) 권한과 로컬 로그온 허용(SeInteractiveLogonRight) 권한이 있어야 합니다. 그림 2는 DNS 관리 팩에서 사용할 수 있는 보고서를 보여 줍니다.
Figure 2 DNS 서비스 보고서 (Close Figure 2)

모든 Windows DNS 서버
모든 Windows DNS 서버 - 영역별
모든 Windows DNS 영역 - 서버별
Microsoft® Systems Management Server(SMS)의 MVP인 Marcus Oh는 nslookup을 호출하여 DNS 서버의 이름 확인 기능을 검증하는 DNS 서버 테스트 스크립트를 개발했습니다. Marcus의 블로그(marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html)(영문)에서 내용을 살펴보면 당장 이 스크립트를 DNS 관리 팩에 통합하고 싶어질 것입니다.
DNS 관리 팩은 go.microsoft.com/fwlink/?LinkId=79528(영문)에서 다운로드할 수 있습니다.

FRS 관리 팩
Windows FRS(파일 복제 서비스) 관리 팩은 Windows 2000 및 Windows Server 2003에서 실행되는 FRS 서비스를 모니터링합니다. FRS는 도메인 컨트롤러가 로그온 스크립트와 그룹 정책 정보를 복제하는 데 사용합니다. FRS 관리 팩은 각 도메인 컨트롤러의 FRS 서비스 상태를 자세히 모니터링합니다.
FRS 관리 팩은 go.microsoft.com/fwlink/?LinkId=79529(영문)에서 제공되는 Ultrasound 도구를 사용합니다. 각 도메인 컨트롤러에 FRS를 위한 WMI 네임스페이스를 생성하는 이 Ultrasound는 데이터베이스를 필요로 하며 상태 모니터링을 위해 WMI 네임스페이스 정보를 각 도메인 컨트롤러에 저장합니다. FRS 관리 팩은 Ultrasound의 수집 정보를 사용하여 복제 세트, 구성원, 연결, FRS 서비스 자체 및 Ultrasound 컨트롤러 서비스를 모니터링합니다.
사실 Ultrasound는 관리 서버와 다른 별도의 서버에 설치해야 합니다. Ultrasound 규칙은 다른 컴퓨터를 대신하여 이벤트와 경고를 작성합니다. Ultrasound 규칙이 데이터를 제대로 처리하도록 하려면 Ultrasound가 실행되는 각 서버의 MOM 관리자 콘솔에서 에이전트 프록시를 설정해야 합니다. 그림 3은 FRS 관리 팩에서 사용할 수 있는 네 가지 서비스 보고서를 보여 줍니다.
Figure 3 FRS 서비스 보고서 (Close Figure 3)

Ultrasound에서 자주 감지되는 문제 - 가장 문제가 많은 연결
Ultrasound에서 자주 감지되는 문제 - 가장 문제가 많은 구성원
Ultrasound에서 자주 감지되는 문제 - 가장 문제가 많은 복제 세트
Ultrasound에서 자주 감지되는 문제 - 요약
이 관리 팩과 연관된 컴퓨터 그룹에는 Windows 2000 Server 및 Windows Server 2003에서 실행되는 Microsoft Ultrasound 1.0 서버와 FRS 서버가 포함됩니다. 컴퓨터 그룹은 해당 운영 체제 버전 및 서버가 그룹 구성원을 확인하기 위해 FRS 서비스를 호스트하는지 여부를 사용하는 수식을 통해 채워집니다. Ultrasound Servers 그룹은 서버에 Ultrasound가 설치될 때 구성됩니다.
낮은 권한 수준에 대해 FRS 관리 팩을 구성하는 경우 작업은 수행되지 않지만 관리 팩의 나머지 기능은 지원됩니다. 작업 계정에는 Ultrasound 데이터베이스에 대한 읽기 권한과 GetControllerStatusForMOM001 저장 프로시저에 대한 실행 권한이 있어야 합니다. FRS 관리 팩은 에이전트 관리 컴퓨터는 물론 에이전트 없는 컴퓨터에 대해서도 모니터링 지원을 제공합니다.
FRS 관리 팩은 go.microsoft.com/fwlink/?LinkId=79530(영문)에서 다운로드할 수 있습니다.

Windows 서버 관리 팩
Windows Base Operating System 관리 팩은 Windows NT 4.0 Server, Windows 2000 Server 및 Windows Server 2003을 모니터링합니다. 이 Base OS 관리 팩은 도메인 컨트롤러를 위한 운영 체제의 상태를 보고하고 해당 시스템의 루트 서비스도 모니터링합니다. 이 관리 팩은 또한 핵심 Windows 서비스의 상태, 메모리 및 프로세서 성능, 디스크 여유 공간, 디스크 대기 시간 등도 알려 줍니다. 이 관리 팩과 이 문서에서 다루는 다른 관리 팩의 모니터링 규칙에는 중복되는 부분이 있지만 이러한 정보는 도메인 컨트롤러 상태를 자세히 검토하는 데 매우 유용합니다.
그림 4는 Base OS 관리 팩에서 사용할 수 있는 보고서를 보여 줍니다. 다른 관리 팩과 마찬가지로 컴퓨터 그룹은 해당 운영 체제 버전을 사용하는 수식을 통해 구성됩니다.
Figure 4 Base Operating System 보고서 (Close Figure 4)

디스크 성능 분석
운영 체제 구성
운영 체제 성능
이벤트별 운영 체제 종료
서버별 운영 체제 종료
운영 체제 스토리지 구성
응용 프로그램별 소프트웨어 및 응용 프로그램 설치
인스턴스별 소프트웨어 및 응용 프로그램 설치
서버별 소프트웨어 및 응용 프로그램 설치
안정성 - 응용 프로그램별 응용 프로그램 오류
안정성 - 컴퓨터별 응용 프로그램 오류
안정성 - 이벤트별 응용 프로그램 오류
안정성 - 컴퓨터별 운영 체제 오류
안정성 - 이벤트별 운영 체제 오류
안정성 - 중지 코드별 운영 체제 오류
성능 기록 - 성능 기록
성능 기록 - 추가 보고서
낮은 권한 수준의 작업에 대해 Base OS 관리 팩을 구성하는 경우 Windows 2000에서는 작업 계정이 로컬 Administrators 그룹의 구성원이어야 합니다. Windows Server 2003에서는 작업 계정이 로컬 Users 및 Performance Monitor Users 그룹의 구성원이어야 하고 감사 및 보안 로그 관리(SeSecurityPrivilege) 권한과 로컬 로그온 허용(SeInteractiveLog-onRight) 권한이 있어야 합니다. 작업을 제외한 Base OS 관리 팩의 기능 대부분은 에이전트 없는 모니터링 대상 컴퓨터에서 지원됩니다.
Base OS 관리 팩은 go.microsoft.com/fwlink/?LinkId=79531(영문)에서 다운로드할 수 있습니다.

Active Directory 관리 팩
Active Directory 관리 팩은 매우 광범위하며 그 규칙이 Windows 2000 Server와 Windows Server 2003에 모두 적용됩니다. 이 Active Directory 관리 팩에는 클라이언트 쪽 모니터링, 트러스트 모니터링, 복제 모니터링, 토폴로지 검색, Windows 2000 Server와 Windows Server 2003 운영 체제에 적용되는 규칙 등 모두 다섯 가지 영역의 규칙이 포함되어 있습니다. 앞에서도 언급했듯이 Windows가 최신 버전일수록 사용 가능한 도구가 많아지므로 보다 자세한 모니터링이 가능합니다. 예를 들어 이 관리 팩은 Windows Server 2003에서 트러스트 모니터링을 지원하지만 Windows 2000에서는 지원하지 않습니다.
Active Directory 관리 팩은 여러 그룹을 생성하여 특정 컴퓨터에 규칙을 적용하는 데 사용합니다. 클라이언트 쪽 모니터링 규칙은 Active Directory Client Side Monitoring이라는 그룹을 사용합니다. MOM 에이전트가 설치된 컴퓨터를 이 그룹에 지정하여 이러한 규칙을 모니터링하고 관리할 수 있습니다. 필자는 일부 Exchange 서버 외에도 에이전트로 라이선스를 받은 몇몇 데스크톱 컴퓨터를 이 그룹에 지정했습니다. Exchange 서버는 Active Directory를 광범위하게 사용하면서 문제 발생을 알려 주는 주요 표시기 역할을 합니다. 이 그룹의 데스크톱 컴퓨터는 최종 사용자 만족도를 평가하는 데 유용할 수 있습니다. 클라이언트 쪽 모니터링 규칙은 스크립트를 사용하여 도메인 컨트롤러에 대한 연결을 테스트하며 LDAP를 통해 쿼리하고 오류를 보고합니다. 이때 프록시는 설정되어 있지만 도메인 컨트롤러가 아닌 에이전트 관리 컴퓨터에만 클라이언트 쪽 모니터링 규칙을 적용할 수 있다는 점에 유의해야 합니다.
트러스트 모니터링 규칙은 Active Directory Trust Monitoring이라는 그룹을 사용합니다. Windows Servers 2003 컴퓨터는 이 그룹에 지정되어 트러스트를 테스트합니다. Windows Server 2003에는 트러스트 모니터링을 위해 WMI 네임스페이스가 포함되어 있습니다. 이러한 규칙은 스크립트를 사용하여 WMI 네임스페이스를 쿼리합니다. 그리고 다른 도메인의 트러스트에서 오류가 감지되면 경고를 보냅니다.
Windows 2000 Server 또는 Windows Server 2003에 적용되는 Active Directory 관리 팩 규칙은 많습니다. 이러한 규칙은 이 두 운영 체제의 Active Directory 구현 방식에 나타나는 차이점을 자세히 보여 줍니다. 그러나 대부분의 Active Directory 관리 팩은 두 운영 체제 모두에 결합형 규칙을 적용합니다. 이러한 규칙 중 일부에는 스크립트가 포함되어 있어 도메인 컨트롤러 간의 연결을 테스트하고 FSMO(신축 단일 마스터 작업) 역할 소유자와 DIT(Directory Information Tree) 데이터베이스 크기를 확인하며 그룹 정책 처리, KCC(정보 일관성 검사) 검사, 사이트 간 메시징 서비스 테스트를 확인합니다.
복제 모니터링은 Active Directory 관리 팩의 핵심이라 할 수 있습니다. 여기서는 Active Directory Replication Latency Data 컬렉션(원본) 및 Active Directory Replication Latency Data 컬렉션(대상)의 두 그룹 덕분에 복제 모니터링 보고 전용의 도메인 컨트롤러를 구성할 수 있습니다. 복제 대기 시간은 데이터 수집 그룹의 구성원별로 계산되고, 성능 카운터는 업데이트가 각 그룹 구성원에 복제되는 데 소요된 시간으로 계산됩니다. 회사 전체의 복제 대기 시간이 지정된 임계값을 초과할 경우에는 시간이 계산되어 보고되고 경고가 생성됩니다. 복제 모니터링을 위한 WMI 네임스페이스는 Windows 2000 Server에 설치해야 합니다.
Active Directory 관리 팩의 토폴로지 검색은 구현 다이어그램을 만드는 데 사용됩니다. 이러한 유용한 다이어그램은 Microsoft Office Visio®에 내보낼 수 있으며 MOM에서 실시간으로 작성할 수 있으므로 단 몇 초 만에 최신 버전을 만들 수 있습니다.
MOM 2005 운영자 콘솔의 다이어그램 보기에는 세 가지 Active Directory 관리 팩 다이어그램이 들어 있습니다. 우선 Broken Connection Objects(끊긴 연결 개체) 다이어그램(그림 5 참조)에는 오류 상태의 모든 연결이 표시됩니다. 연결 오류가 없으면 이 다이어그램은 비어 있습니다.
그림 5 다이어그램 보기에서 강조 표시된 끊긴 연결
그림 5 다이어그램 보기에서 강조 표시된 끊긴 연결
Connection Objects(연결 개체) 다이어그램은 DC 간의 연결을 강조 표시합니다. 그리고 Site Links(사이트 링크) 다이어그램은 사이트의 해당 도메인 컨트롤러와 연결 사이트 링크를 포함하여 각 Active Directory 사이트를 보여 줍니다.
MOM이 이러한 보기에 생성한 다이어그램은 동적이므로 Visio에 내보내 간편하게 편집하고 사용자 지정할 수 있습니다. 그림 6은 Visio에서 편집 중인 Site Links(사이트 링크) 다이어그램을 보여 줍니다.
그림 6 Visio에서 Site Links(사이트 링크) 다이어그램 편집
그림 6 Visio에서 Site Links(사이트 링크) 다이어그램 편집 (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 Visio에서 Site Links(사이트 링크) 다이어그램 편집
그림 6 Visio에서 Site Links(사이트 링크) 다이어그램 편집 (더 크게 보려면 이미지를 클릭하십시오.)
그림 7은 Active Directory 관리 팩에서 사용할 수 있는 보고서를 보여 줍니다. 이 관리 팩과 연관된 컴퓨터 그룹은 그림 8에 나와 있습니다. 여기에 나온 것처럼 Active Directory 컴퓨터 그룹은 명시적 구성원을 기반으로 구성되고, Windows 컴퓨터 그룹은 운영 체제의 버전과 시스템이 도메인 컨트롤러인지 여부에 따라 구성됩니다.
Figure 8 컴퓨터 그룹 (Close Figure 8)

Active Directory Client-Side Monitoring
Active Directory Replication Latency Data
컬렉션 - 원본
Active Directory Replication Latency Data
컬렉션 - 대상
Active Directory Trust Monitoring
Windows 2000 Server 도메인 컨트롤러
Windows Server 2003 도메인 컨트롤러
Figure 7 Active Directory 보고서 (Close Figure 7)

AD 도메인 컨트롤러
AD 역할 소유자
AD 복제 연결 개체
AD 복제 사이트 링크
AD DC 디스크 공간
AD 도메인 변경
AD 컴퓨터 계정 인증 오류
AD 복제 대역폭
AD 복제 대기 시간
Active Directory 관리 팩은 Windows Server 2003 도메인 컨트롤러에서 낮은 권한 수준에 대해 구성할 수 있으며, 에이전트 없는 모니터링은 지원하지 않습니다. Windows 2000 Server에서 에이전트 작업 계정은 Domain Admins 또는 로컬 Administrators 그룹에 속해야 합니다. Windows Server 2003 도메인 컨트롤러의 에이전트 작업 계정에는 Users 그룹 및 Performance Monitor Users 그룹의 구성원과 이벤트 로그에 대한 액세스 권한은 물론 SeSecurityPrivilege, SeAuditPrivilege 및 SeInteractiveLogonRight 권한을 비롯하여 낮은 권한 수준에 대해 구성할 수 있는 추가 권한이 있어야 합니다. 뿐만 아니라 Active Directory에서 복제 모니터링을 수행하기 위한 CN=MomLatencyMonitors 컨테이너에 대한 모든 권한, NTDS.dit 데이터베이스와 로그 파일이 포함된 디렉터리에 대한 읽기 권한, 그리고 다음 레지스트리 키에 대한 읽기 권한도 필요합니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Windows Server 2003에서 트러스트를 모니터링하는 경우 AD Monitor Trusts 스크립트를 사용하려면 에이전트 작업 계정에 Domain Admin 또는 Administrators 그룹 구성원 자격이 있어야 합니다.
Active Directory 관리 팩은 go.microsoft.com/fwlink/?LinkId=79540(영문)에서 다운로드할 수 있습니다.

Active Directory에 대해 MOM 사용자 지정
Active Directory 관리 팩을 구성하지 않으면 콘솔이 경고로 가득 차게 됩니다. Active Directory 관리 팩은 도메인 컨트롤러가 다시 시작될 때 가장 활발하게 작동합니다. 이때는 가능한 모든 경고가 트리거되는 것 같습니다. 문제는 이런 경고를 중단하기가 쉽지 않다는 데 있습니다. 가장 최선의 방법은 예상된 유지 관리 창에서 MOM의 유지 관리 모드를 사용하여 이러한 경고를 제어하는 것입니다. 유지 관리 모드의 목적은 도메인 컨트롤러의 경고 메시지를 자동으로 해결하여 콘솔이 가득 차지 않도록 하는 것입니다.
그룹 내에 클라이언트 컴퓨터와 해당 서버를 적절히 배치하여 Active Directory Client Side Monitoring 그룹을 구성하는 것도 잊지 말아야 합니다. 이 그룹과 관련된 규칙은 FSMO 상태 및 이에 대한 연결을 확인하는 데 유용합니다.
임계값을 사용하여 LDAP, PING 및 DNS를 사용하는 FSMO에 바인딩함으로써 연결을 확인하는 성능 규칙이 있습니다. 이러한 규칙은 Active Directory Availability(Active Directory 가용성) 성능 규칙에 있습니다. 경고 심각도를 설정하여 이러한 규칙에 사용되는 임계값을 사용자 지정해야 합니다. 예를 들어 FSMO 바인딩은 초 단위의 특성 값을 사용합니다. 각 FSMO 역할에 대한 성능 규칙은 이 경고 생성 방법을 사용합니다.
상태 규칙의 경고 심각도 계산 설정이 작동하는 방식을 이해하는 것은 매우 중요합니다. 이 대화 상자는 특성 값에 대해 If-Else 조건문을 사용하여 적절한 경고 심각도를 설정합니다(그림 9 참조). 이 규칙은 AD Op Master Response 스크립트가 생성한 Last Bind(마지막 바인드) 성능 카운터 정보를 수집할 때 이러한 규칙에 설정된 조건 임계값과 비교하여 검사를 수행합니다. 이러한 경고 수준은 환경에 맞게 적절히 구성해야 합니다.
그림 9 경고 심각도 규칙 설정
그림 9 경고 심각도 규칙 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 9 경고 심각도 규칙 설정
그림 9 경고 심각도 규칙 설정 (더 크게 보려면 이미지를 클릭하십시오.)
각 도메인 컨트롤러에 대한 복제 일정은 반드시 기억해야 합니다. 지정된 도메인 컨트롤러의 일정이 다른 컨트롤러와 다를 경우 복제 대기 시간 결과가 왜곡되어 임계값을 더 높게 설정해야 하는 결과를 초래합니다. 또한 복제 스크립트의 매개 변수를 특정 환경에 맞게 설정해야 합니다. 도메인 컨트롤러 중 하나가 작동 중단되거나 복제 문제가 발생하면 이들 그룹의 다른 모든 도메인 컨트롤러는 직접적인 복제 파트너가 아니어도 해당 도메인 컨트롤러에 대해 복제 오류를 보고할 수 있습니다. 따라서 문제의 도메인 컨트롤러를 유지 관리 모드로 지정해도 다른 도메인 컨트롤러가 복제 오류를 보고할 수 있습니다.
Active Directory 관리 팩을 조정할 때 가장 많은 노력이 필요한 부분은 복제 모니터링입니다. 몇 주 동안 관리 팩을 실행하면서 경고가 어떻게 발생하는지 확인해야 합니다. 그리고 몇몇 경향이 발견되면 보고서를 사용하여 대기 시간을 요약하고 임계값을 적절히 조정합니다.
마지막으로 Alert Tuning Solution Accelerator(영문)에 나와 있는 지침을 활용하십시오.

결론
MOM 2005 및 Active Directory 관리 팩을 통해 Active Directory 구현을 효과적이고 효율적으로 모니터링할 수 있습니다. Active Directory, DHCP, DNS, FRS 및 Windows Server Base OS 관리 팩을 사용하여 인프라의 모든 측면을 보다 철저히 모니터링하면서 Active Directory 인프라는 물론 관련 사용자들의 안전하고 편리한 사용 환경을 보장할 수 있습니다. 보고 데이터 웨어하우스에 수집된 방대한 데이터는 성능 및 이벤트 데이터를 분석하여 용량 계획 및 성능 예측을 지원하는 데 매우 유용합니다.
여기서 다룬 관리 팩을 포함하여 다양한 관리 팩을 Management Pack Catalog(영문)에서 확인할 수 있습니다.
Active Directory 관리 팩의 차후 업데이트 버전에서는 보다 유용하게 몇 가지 임계값이 수정될 것입니다. 더욱 기대되는 것은 System Center Operations Manager 2007이라는 이름의 신제품에 추가될 새로운 기능입니다. 여기에는 단일 구성 그룹에서 복수의 포리스트를 모니터링하여 다른 그룹 간의 각 예상 복제 대기 시간을 기반으로 도메인 컨트롤러 그룹을 정의하고 다음 버전의 Window Server에서 실행될 도메인 컨트롤러를 모니터링하는 기능이 포함됩니다. 자세한 내용은 MOM 웹 사이트(http://www.microsoft.com/korea/mom/default.mspx)에서 확인하십시오.

John Hann은 MOM 2000 버전부터 MOM을 사용해왔고 2004년부터 MOM MVP로 활동하고 있습니다. John은 또한 MyITForum.com, MOMCommunity.com 및 LearnMOM.com에 글을 기고하기도 합니다. 문의 사항이 있으면 John의 블로그(영문)로 연락하시면 됩니다.


 Windows Administration: 안전한 게임 환경
Windows Administration Matt Clapham

안전한 게임 환경
한 눈에 보기:
  • 보호되는 폴더 및 레지스트리 키에 대한 쓰기 시도
  • 복사 방지 오류
  • 방화벽 문제
  • 엔터프라이즈 클라이언트 문제

필자는 지금까지 Microsoft에서 보안 프로그램 관리자로 일해 왔습니다. 또한 TechNet Magazine에 보안 관련 기사도 자주 싣고 있습니다. 때문에 보안을 매우 중요시하는 건 당연합니다. 물론 다른 관심사도 많지만 말입니다.
여가 시간에는 Windows® 기반 게임을 즐기기도 하는데, FPS(1인칭 슈팅 게임), 시뮬레이션 게임, RPG(롤플레잉 게임), 실시간 전략 게임 같은 장르를 특히 좋아합니다. 그러나 이러한 게임을 즐기는 데에도 한 가지 철칙이 있습니다. 꼭 필요한 경우가 아니면 관리자 권한으로 게임을 실행하지 않는다는 것입니다. 이는 필자의 친구인 Jesper Johansson과 Aaron Margosis도 마찬가지입니다. 이렇게 하는 데는 네트워크 게임에서 실력 부족이 아닌 누군가의 루트킷 공격에 의한 속도 저하 때문에 패하는 일이 없도록 하려는 이유도 있습니다. 이와 관련해서는 리소스 추가 기사의 Quake 3 Buffer Overflow Advisory(영문)를 참조하십시오.
필자는 이 원칙을 철저히 지키기 때문에 새로 나온 멋진 타이틀을 즐기지 못하는 경우가 많습니다(그림 1 참조). 필자는 SBS(Small Business Server) 도메인에 가입된 클라이언트에서 관리자 계정으로 게임을 설치하고 업데이트한 후 LUA(제한된 사용자 계정)로 실행할 수 없으면 바로 제거해 버립니다. 재미 있는 게임은 많으므로 굳이 이렇게 어설프게 엔지니어링된 게임을 즐길 이유가 없기 때문입니다. 너무 극단적으로 보일 수도 있지만 저는 이 원칙을 고수합니다. 그리고 좀 더 안전하게 게임을 즐기기 위해서는 몇 가지 사소한 원칙을 지키는 것이 좋습니다. 여기서 다루고자 하는 것도 바로 그러한 부분입니다. 따라서 먼저 필자가 경험한 게임 관련 문제와 해결 방법에 대해 설명하겠습니다. 최선의 방법에 대한 간단한 요약은 "제한된 사용자로 게임을 즐기기 위한 팁" 추가 기사를 참조하십시오.
그림 1 수동 업데이트 수행 시 파일 액세스 문제
그림 1 수동 업데이트 수행 시 파일 액세스 문제 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 수동 업데이트 수행 시 파일 액세스 문제
그림 1 수동 업데이트 수행 시 파일 액세스 문제 (더 크게 보려면 이미지를 클릭하십시오.)

일반적인 문제
이러한 권한 문제는 이미 잘 알려져 있습니다. 관리자 권한이 있어야 정상적으로 작동하는 게임과 기타 유형의 프로그램이 많이 있기 때문입니다. "제한된 사용자 계정을 통해 로그온하면 특정 프로그램이 작동하지 않는다"(support.microsoft.com/kb/307091) 기술 자료 문서를 살펴보면 Microsoft에서 제공하는 몇 가지 프로그램을 비롯하여 제한된 사용자로 실행했을 때 문제가 발생하는 게임과 응용 프로그램이 거의 200개나 됩니다.
게임을 설치 또는 업그레이드할 때 관리자 권한을 요구하는 것 자체가 문제라는 이야기는 아닙니다. Windows에서 일상적인 사용자별 설치 기능이 제공되기 전까지 이는 일반적인 요구 사항입니다. 이러한 기능은 머지않아 제공되겠지만 아직은 이 기능이 없는 것이 현실입니다. 어쨌든 게임을 설치하고 업데이트한 후에는 제한된 권한의 사용자를 포함하여 시스템의 모든 사용자가 해당 게임을 실행할 수 있어야 합니다.
보호되는 폴더 및 레지스트리 키에 대한 쓰기 시도 지금까지 가장 자주 발생했던 문제는 보호되는 폴더나 레지스트리 키에 쓰기를 시도하여 시작 시 또는 실행 중에 게임에서 오류가 발생하는 문제였습니다. 이는 여러 Windows 기반 응용 프로그램에서 많이 나타나는 문제이기도 합니다. %PROGRAMFILES% 같은 특정 폴더와 HKEY_LOCAL_MACHINE 같은 레지스트리 하이브의 경우 기본적으로 관리자와 Power Users(더 이상 사용되지 않음)만 쓸 수 있습니다. 이러한 문제로 인해 발생하는 오류는 "오류 42: C:\Program Files\CoolGamesInc\NewestFPS\Logs\에 로그 파일을 쓸 수 없습니다." 또는 "게임이 정상적으로 설치되지 않았습니다. 다시 설치한 후 다시 시작하십시오."와 같이 비교적 파악하기가 쉽습니다. 게임 도중에 진행한 게임 내용을 저장하려 하는 등의 경우에도 이러한 오류 메시지가 표시됩니다. Age of Mythology®처럼 적어도 사용자에게 정상적으로 작동하기 위해서는 관리자 권한이 필요하다는 사실을 알리는 게임도 있지만 MMOG(다중 접속 온라인 게임)는 업데이트가 잦고 자동 업데이트 부분은 기술적으로 문제를 해결하기가 다소 어렵기 때문에 이러한 메시지 없이 바로 권한 문제가 발생하는 경우가 많습니다. EVE Online 평가판을 실행했을 때는 잘못된 위치에 로그 파일을 저장할 뿐만 아니라 게임 콘텐츠 데이터를 설치 폴더에 자동 업데이트하려 하는 문제가 발생한다는 사실을 알게 되었습니다.
복사 방지 오류 게임 실행 오류가 발생하는 일반적인 원인 중 두 번째는 게임에서 기본 제공하는 복사 방지 또는 기타 저작권 침해 방지 기능이 제한된 사용자로 실행하는 경우에 제대로 작동하지 않기 때문입니다. 이 경우 드라이버가 제대로 시작되지 않거나 일부 백그라운드 서비스가 실행되지 않을 수 있습니다. 이 문제의 가장 일반적인 유형으로는 필요한 미디어를 이미 드라이브에 넣었는데도 사용자에게 디스크를 넣으라는 메시지가 표시되는 경우입니다. 또한 관리자만 복사 방지 검사를 제대로 수행할 수 있다는 잘못된 믿음에 따라 관리자 권한을 요구하는 게임도 있었습니다. 심지어 게임의 지원 사이트에 대한 참조도 없는 엉터리 오류 메시지가 표시되는 경우도 있었습니다.
방화벽 예외 요청 실패 요즘에는 로컬 네트워크나 인터넷을 통해 즐길 수 있는 멀티플레이 게임을 쉽게 접할 수 있으며 Windows XP 서비스 팩 2(SP2)에는 응용 프로그램이 네트워크에서 데이터를 수신할 때 사용자에게 이를 알리는 경고 메시지가 추가되었습니다. 이후 필자가 발견하게 된 문제는 방화벽 예외가 필요한 게임이 설치 시에 이러한 예외를 추가하도록 요청하지 않는다는 것입니다. 제한된 사용자는 방화벽 구성을 변경할 수 없으므로 관리자가 구성을 변경하지 않는 한 이러한 경고(그림 2 참조)를 해결할 수 없습니다. 또한 게임의 인터페이스가 아니라 Windows 셸에 경고가 표시되어 문제를 파악하기 힘든 경우도 있습니다. 일반적으로 이 경우에는 게임을 종료하지 않으면 오류 메시지를 볼 수도 없습니다.
그림 2 방화벽 설정으로 게임이 실행되지 않는 경우
그림 2 방화벽 설정으로 게임이 실행되지 않는 경우 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 방화벽 설정으로 게임이 실행되지 않는 경우
그림 2 방화벽 설정으로 게임이 실행되지 않는 경우 (더 크게 보려면 이미지를 클릭하십시오.)
엔터프라이즈 클라이언트 문제 제한된 사용자로 실행하는 것과는 직접적인 관련이 없지만 중요하게 살펴보아야 할 다른 문제도 있습니다. 필자는 가정용 컴퓨팅 환경을 소규모 기업처럼 실행하고 있습니다. 여기서 이에 대해 자세히 설명하지는 않겠지만 Jesper Johansson과 함께 쓴 2006년 10월호 TechNet Magazine 기사 "Master Your Domain: Build a Corporate Network at Home"(영문)을 참조하면 자세한 내용을 볼 수 있습니다. 필자는 SBS 2003(R2)을 사용하여 내 문서 폴더에 서버 공유로 리디렉션되는 완벽한 Windows 도메인을 설정했습니다. 그 덕분에 여기서 마지막으로 설명할 일반적인 문제, 즉 엔터프라이즈 클라이언트를 처리하지 못하는 문제를 파악할 수 있었습니다.
이 문제는 Age of Empires® III(AoE3)에서 발생했는데, 제한된 사용자로도 게임을 정상적으로 시작하고 플레이할 수 있다는 개발 팀의 말과는 달리 네트워크를 통해 쓰여지는 로깅 데이터가 많아서 로딩 속도가 느려지는 경우가 있었습니다. 또한 게임을 종료할 때마다 AoE3의 구성, 저장된 게임 및 게임 진행 내용을 잃게 되었습니다. 해당 파일이 내 문서 폴더에 있었지만 게임에서 파일을 제대로 로드하지 못한 것입니다. 특히 AoE3이 시리즈의 이전 타이틀에 비해 훨씬 더 LUA 친화적이라는 점을 감안할 때 이는 매우 실망스러운 결과였습니다.
이러한 엔터프라이즈 클라이언트 문제에 대해 적어도 경고 메시지가 표시되는 게임이 딱 하나 있었습니다. Fable®: The Lost Chapters™를 실행하자 원격 내 문서 폴더가 지원되지 않는다는 메시지와 함께 정상 종료되었습니다. 그래서 개발 팀에게 지원되지 않는 시나리오를 인정하고 실행 환경에서 제외하라고 제안했습니다. 그런데 내 문서 폴더에 몇 메가바이트의 데이터만 저장하면 되는데 게임이 실행을 중단하는 방식으로 동작하는 건 쉽게 납득이 가지 않았습니다.

간단한 해결 방법
지금까지 설명한 문제들은 기억할 수도 없을 만큼 많은 게임에서 자주 발생했습니다. 하지만 다행히 그 중 대부분은 간단한 방법으로 해결할 수 있었습니다. 필자가 가장 즐겨 사용하는 방법은 게임을 모두 제거하고 다른 업체에서 제공하는 같은 장르의 LUA 지원 게임으로 바꾸는 것입니다. 뭐, 너무 극단적인 방법일 수도 있고 새 타이틀을 구입하는 데 드는 비용과 포장을 이미 뜯어 환불 받을 수도 없다는 점을 생각하면 그리 좋은 해결 방법은 아닙니다. 따라서 문제를 해결할 수 있는 필자의 다른 비법을 소개하겠습니다.제한된 사용자로 게임을 즐기기 위한 팁
  • Windows Vista로 업그레이드하십시오.
  • 게임을 구입하기 전에 데모를 실행해 보십시오. 그러면 정식 버전에서 발생하는 모든 LUA 문제를 확인할 수 있습니다.
  • LUA로 실행했을 때 문제가 발생하는 것으로 알려진 프로그램 목록을 확인하십시오.
  • Designed for Windows 로고가 부착된 게임을 구입하십시오.
  • 설치 후 제한된 사용자로 실행하기 전에 게임을 업데이트하십시오.
  • 제한된 사용자로 게임을 실행할 수 없는 경우 공급업체의 기술 지원 서비스 담당자에게 문제에 대해 알리십시오.
  • 꼭 필요한 경우 시스템 로컬 Power User 계정을 사용하십시오.

복사 방지 문제 해결 우선 복사 방지 드라이버 문제를 해결해 보도록 합시다. 복사 방지 시스템이 필요하긴 하지만 그렇다고 해서 관리자가 아닌 사용자가 게임을 실행하지 못하도록 차단해서는 안 됩니다. 대부분의 게임은 드라이버를 설치하여 원본 게임 디스크를 확인하는 Macrovision의 SafeDisc 복사 방지 메커니즘을 사용합니다. 이 드라이버는 기본적으로 요청 시에만 시작되도록 구성되는데, 이 기능이 바로 제한된 사용자로는 실행할 수 없는 기능입니다. Microsoft와 Macrovision에서 이에 대한 픽스를 배포했지만 다른 해결 방법도 있습니다.
  1. 관리자 계정을 사용하여 장치 관리자를 엽니다.
  2. 보기 메뉴에서 숨김 장치 표시를 선택합니다.
  3. 비 플러그 앤 플레이 드라이버 노드를 확장합니다.
  4. 보안 또는 SecDrv 드라이버의 속성(
    그림 3 복사 장비가 정상적으로 실행되도록 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 복사 장비가 정상적으로 실행되도록 설정
그림 3 복사 장비가 정상적으로 실행되도록 설정 (더 크게 보려면 이미지를 클릭하십시오.)
이제 컴퓨터를 부팅할 때 드라이버가 실행되므로 사용자가 디스크를 넣었을 때 게임이 정상적으로 실행됩니다.
파일 시스템 및 레지스트리 액세스 문제 해결 파일 시스템 또는 레지스트리에 대한 무제한 액세스를 전제하는 문제는 게임뿐만 아니라 다른 많은 최신 프로그램 및 기존 프로그램에서 찾아볼 수 있습니다. Aaron Margosis는 "Problems of Privilege: Find and Fix LUA Bugs"(영문) 기사에서 관리자 권한을 요구하게 되는 다양한 문제의 해결 방법을 자세히 설명하고 있으므로 참조하시기 바랍니다.
액세스 문제는 추적하기가 다소 어려울 수 있지만 필요한 파일, 폴더 및 레지스트리 키를 파악하고 나면 제한된 사용자가 게임을 할 수 있도록 ACL(액세스 제어 목록)을 쉽게 구성할 수 있습니다. 이러한 문제는 다음과 같은 방법으로 대부분 해결되었습니다.
  1. microsoft.com/technet/sysinternals(영문)에서 Filemon 및 Regmon의 최신 버전을 다운로드합니다.
  2. 이 두 가지 도구를 관리자로 실행하여 로그를 수집하도록 합니다.
  3. 관리자로 게임을 몇 분 간 실행하면서 새 캠페인 시작, 게임 저장, 네트워크 게임 호스팅 같은 가장 일반적인 작업을 수행해 봅니다.
  4. Filemon 및 Regmon에서 결과를 필터링하여 테스트한 게임에서 발생한 액세스만 표시합니다.
  5. 필요에 따라 해당 폴더 및 레지스트리에 대한 ACL을 구성합니다.
  6. 관리자 이외의 사용자로 게임을 실행하여 정상적으로 작동하는지 확인합니다.
ACL을 구성할 때 주의를 기울여야 할 점이 있습니다. 바로 너무 광범위하게(예: Everyone£모든 권한) 열거나 너무 상위(예: HKEY_CLASSES_ROOT)에서 열어서는 안 된다는 점입니다. 또한 %SYSTEMROOT% 및 %PROGRAMFILES% 같은 시스템 폴더에 대한 사용 권한을 변경하면 Windows가 전체적으로 손상되거나 시스템이 안전하지 않은 상태가 될 수 있으므로 변경하지 않는 것이 좋습니다.
시스템 로컬 Power User로 게임을 실행하는 방법으로 문제를 해결할 수도 있습니다. 필자가 선호하는 방법은 아니지만 시스템의 로컬 계정을 사용하면 문제가 발생할 경우 영향을 받는 범위가 단일 워크스테이션으로 한정되므로 보다 안전합니다. 이 방법은 관리자로 실행하는 것 외에는 방도가 없어 보이는 대부분의 게임에서 효과가 있었습니다.
다른 이야기이지만 관리자로 게임을 잠깐 실행하면 간편하게 자동 업데이트를 실행할 수 있다는 사실을 알게 되었습니다. 필자의 경우 보통 게임을 관리자로 실행하고 업데이트 옵션을 호출한 다음 게임을 종료하고 다시 제한된 사용자 계정으로 게임을 실행합니다. Windows Vista™의 경우 원래 공급업체에서 서명한 패치에 한해 제한된 사용자가 응용 프로그램을 업데이트할 수 있습니다.
Windows Vista를 사용하면 게임이나 기타 응용 프로그램에서 파일 및 레지스트리 액세스 문제를 해결하는 데 도움이 됩니다. 제한된 사용자로 실행되는 프로그램에는 기본적으로 잘못 인식된 파일 및 레지스트리 액세스를 사용자별 캐시로 리디렉션하는 가상화 shim이 설정되어 있습니다. 개인적으로 Windows 9x 시대에 개발된 게임(예: The Neverhood)이 사용 권한 문제로 인해 Windows XP에서는 제대로 실행되지 않았지만 Windows Vista에서는 기본 shim을 사용하여 완벽하게 작동되는 경우를 많이 보았습니다. 그리고 앞으로 문제가 발생한 다른 게임들도 Windows Vista에서 테스트해 볼 예정이지만 Windows Vista에서 정상적으로 작동되지 않는 게임은 찾기 어려울 것 같습니다.
방화벽 문제 해결 방화벽 문제는 게임을 처음 설치할 때 해결하는 것이 가장 좋습니다. 그러나 게임 설치 프로그램이 필요한 방화벽 설정 변경 사항을 사용자에게 물어 구성할 정도로 잘 만들어지지 않은 경우 다음과 같은 방법으로 문제를 해결할 수 있습니다.
  1. 관리자로 로그온합니다.
  2. Windows 방화벽 제어판을 엽니다.
  3. 방화벽 예외 목록에 추가할 프로그램을 선택합니다.
  4. 메시지가 나타나면 원하는 게임을 게임 실행 파일을 목록에서 선택하거나 탐색하면 됩니다.
게임 실행 파일을 방화벽 예외에 추가하면 게임이 정상적으로 작동하는 데 필요한 모든 포트에 액세스할 수 있습니다. 그리고 마음껏 게임을 즐기기만 하면 됩니다.
엔터프라이즈 클라이언트 문제 해결 엔터프라이즈 클라이언트에서 실행하는 게임의 문제는 언젠가 영원히 사라질 것입니다. 여러 대의 컴퓨터와 광대역 연결을 사용하는 가정이 늘어나고 SBS를 집에서 실행하는 사용자가 증가하고 있기 때문입니다. 그러나 현재로서는 이 문제에 대한 해결 방법이 필요합니다.
필자의 경우에는 시스템 로컬 LUA를 사용하여 리디렉션된 내 문서 폴더의 문제를 해결할 수 있었습니다. Age of Empires III과 Fable: The Lost Chapters는 모두 내 문서 폴더가 네트워크 폴더로 리디렉션되지 않는 한 제한된 사용자로도 문제 없이 실행할 수 있습니다.리소스
  • Quake 3 Buffer Overflow Advisory
  • Windows Vista Application Development Requirements for User Account Control Compatibility(영문)
  • Windows XP에서 사용자 계정에 최소 권한의 원칙 적용
  • Aaron Margosis’ LUA Buglight tool(영문)
  • Standard User Analyzer(영문)
  • Master Your Own Domain: Build a Corporate Network at Home(영문)
  • Problems of Privilege: Find and Fix LUA Bugs(영문)
  • 제한된 사용자 계정을 통해 로그온하면 특정 프로그램이 작동하지 않는다

결론
제한된 사용자로 실행하면 관리자로 실행할 때 발생할 수 있는 보안 문제를 방지하는 이점을 얻을 수 있습니다. 엔터프라이즈 환경에서 연결되어 있거나 최소한의 권한만 사용하는 경우에 게임을 실행하기가 다소 어려울 수도 있지만 절대 불가능한 것은 아닙니다. 지난 몇 년 동안 필자는 제한된 사용자로도 정상적으로 작동하는 게임을 각 장르별로 많이 찾아냈습니다. 또한 문제가 발생한 다른 타이틀에서 이를 해결할 수 있는 몇 가지 방법도 알아냈습니다. 게다가 Windows Vista의 가상화 기능을 활용하면 Windows XP에서는 제한된 사용자로 즐길 수 없었던 게임을 다시 한번 즐길 수 있게 됩니다.

Matt Clapham은 Microsoft의 보안 프로그램 관리자로서 Seattle IT Security 커뮤니티에 적극적으로 참여하고 있으며 IT 인큐베이션 프로젝트의 위기 관리 팀원이기도 합니다.


 From the Editor: 작동 원리
From the Editor
작동 원리

Windows Vista는 2007년 각 기업의 IT 부서에 큰 영향을 미칠 것으로 예상되고 있습니다. InformationWeek지의 기사에 따르면 최근의 IDC 보고서는 올해 Windows Vista 탄생의 직접적인 영향으로 미국에서만 100,000개의 IT 부문 일자리가 창출될 것으로 추정했습니다. 또한 올 한 해 동안 세계적으로 Windows Vista가 설치된 약 9,000만 대의 신형 컴퓨터가 판매될 것으로 보이며, 이듬해까지 기업에 판매되는 컴퓨터의 80%에 Windows Vista가 사전 설치될 것으로 보입니다. 따라서 각 기업에서는 이 OS를 배포할지 여부를 결정해야 할 시점이 되었다고 할 수 있습니다. 이번 호에는 이러한 결정에 도움이 되는 기사가 많습니다.
이번 호 TechNet Magazine에서는 Windows Vista의 작동에 핵심이 되는 커널에 대해 심도 있게 살펴보는 새로운 시리즈 기사를 선보입니다. Windows Vista에는 몇 가지 유용한 사용자 환경 기능이 새로 추가되었지만 주된 이유가 그 뿐이라면 굳이 Windows Vista로 마이그레이션할 필요는 없을 것입니다. 그러나 OS의 핵심이라 할 수 있는 커널의 작동 방식이 크게 개선되었다는 점을 고려하면 이야기는 달라집니다.
지구상에서 Mark Russinovich보다 Windows 커널에 대해 잘 아는 사람, 그리고 이러한 OS의 변경 사항에 대한 기사를 쓰기에 더 적합한 사람은 없을 것입니다. 그가 David Solomon과 함께 집필한 저서 Windows Internals는 새로운 운영 체제의 작동 원리에 대해 이해하고자 하는 사용자들에게 최고의 참고 자료가 되고 있습니다.
이번 호에서 Mark는 데스크톱 응용 프로그램의 응답 성능을 높이는 CPU 할당 기능 개선 사항에 대해 설명하고 Windows Vista 커널 수준에서 멀티미디어 성능을 높이는 데 어떤 방법이 사용되었는지를 알아봅니다. 또한 이 기사에서는 파일 기반 심볼 링크, 새로운 동기 I/O 작업 취소 기능(개인적으로 가장 큰 변화라고 생각하는 부분), I/O 우선 순위의 개념 등 Windows Vista I/O 모델의 주요 변경 사항에 대해서도 살펴봅니다. Mark의 광범위한 기사를 통해 Windows Vista를 평가하는 데 필요한 정보를 얻으시기 바랍니다.
일상적인 작업에 대한 기사도 있습니다. 이번 호에서는 Active Directory의 권한 위임, Windows Vista의 새로운 그룹 정책 템플릿, 그룹 정책 문제 해결, MOM을 사용한 Active Directory 모니터링 등에 대한 기사를 통해 여러 가지 Windows 관리 작업과 관련된 정보를 제공합니다.
마지막으로 안전한 환경에서 게임을 즐기는 방법에 대한 기사도 매우 흥미롭습니다. 작업을 하다 보면 가끔 게임을 즐기는 것도 도움이 되니까요. £JOSHUA TRUPIN

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang 및 Andy Zeigler에게 감사를 전합니다.


 Toolbox: IT 전문가를 위한 새로운 제품
Toolbox
IT 전문가를 위한 새로운 제품
Greg Steen

데이터 이동
SQL Examiner Bundle
www.sqlaccessories.com
조직 내의 역할이 DBA든 개발자든 운영 전문가든 심지어 여러 역할을 맡고 있든 상관없이 SQL Server™로 작업하는 작업자는 아마도 여러 환경 간에 데이터를 이동하고 데이터와 데이터 구조의 무결성을 유지해야 할 책임을 지고 있을 것입니다. 물론 SQL Server에는 기본적으로 제공되는 많은 복제 및 동기화 기능이 있지만 QA 데이터베이스가 개발 데이터베이스와 정확히 일치하는지를 검사하는 경우 TulaSoft의 SQL Examiner Bundle 같은 도구는 시간과 노력을 절감할 수 있는 아주 귀중한 도구입니다.
이 응용 프로그램을 사용하면 단 몇 번의 마우스 클릭만으로 두 데이터베이스 인스턴스 사이의 데이터베이스 구조나 데이터 자체의 불일치를 찾아냅니다. 사용자는 그저 검사할 데이터베이스를 가리키고 실행하기만 하면 됩니다. 이름에서 알 수 있듯이 SQL Examiner Bundle은 SQL Examiner와 SQL Data Examiner라는 두 응용 프로그램을 묶은 것입니다. SQL Examiner는 데이터베이스의 구조를 확인하는 반면 SQL Data Examiner는 모든 데이터를 확인하여 차이를 강조 표시합니다.
SQL Examiner는 테이블과 저장 프로시저에서 전체 텍스트 카탈로그와 XML 스키마 컬렉션에 이르기까지 데이터베이스 인스턴스의 모든 항목을 확인하고 비교합니다. SQL Server 2005를 사용하는 경우에는 CLR(공용 언어 런타임) 어셈블리도 비교할 수 있습니다. 데이터베이스를 비교한 후 SQL Examiner에서 동기화해야 할 데이터베이스 개체와 동기화 방향을 선택할 수 있습니다.
SQL Examiner로 데이터베이스 확인 및 비교
SQL Examiner로 데이터베이스 확인 및 비교 (더 작게 보려면 이미지를 클릭하십시오.)
SQL Examiner로 데이터베이스 확인 및 비교
SQL Examiner로 데이터베이스 확인 및 비교 (더 크게 보려면 이미지를 클릭하십시오.)
이 응용 프로그램의 정말로 획기적인 기능 중 하나는 개체를 만드는 SQL 스크립트를 생성한 다음 생성된 스크립트에 데이터베이스 간의 차이를 강조 표시하는 것입니다. 이 기능을 사용하면 만들기 스크립트나 마이그레이션 스크립트가 대상 데이터베이스의 구조를 만드는 데 실패한 경우 오류를 손쉽게 강조 표시할 수 있습니다. 따라서 클러스터형 인덱스가 남아 있는 곳을 확인할 수 있습니다. 생성된 스크립트는 개별적으로 실행하거나, 스크립트를 저장했다가 나중에 실행하거나, Synchronize(동기화) 단추를 클릭하여 모든 작업이 자동으로 수행되도록 할 수 있습니다.
또 다른 멋진 기능은 예외 항목을 비교에 추가할 수 있는 옵션입니다. 이를 통해 개체의 설명, 트리거, 인덱스 또는 확장 속성 등을 무시할 수 있습니다. 구조를 비교한 후 SQL Data Examiner를 사용하면 데이터를 조사하고 불일치가 있는지 확인할 수 있습니다. 비교할 테이블을 선택할 수 있을 뿐 아니라 지정한 테이블에서 비교해야 할 열을 선택할 수도 있습니다. 데이터 테이블의 비교가 끝나면 어떤 행이 같은지, 어떤 행이 다른지, 어떤 행이 한 데이터베이스에만 있는지 등을 확인할 수 있습니다.
SQL Examiner와 마찬가지로 SQL Data Examiner에서도 단추를 클릭하여 테이블을 동기화하거나, 전송해야 할 데이터와 전송 방향을 선택할 수 있습니다. 두 응용 프로그램 모두 설정을 프로젝트로 저장할 수 있으므로 작업을 매번 다시 만들지 않아도 됩니다. 각 응용 프로그램을 따로따로 구입할 수도 있지만 제 경험으로는 둘 다 구입하는 것이 좋습니다.
가격: 단일 사용자 라이선스당 $299.95

중복 파일 검색
zsDuplicateHunter(Professional Edition)
Zizasoft
데스크톱 관리와 관련된 일을 하고 있다면 틀림없이 시스템에서 "공간 부족" 문제를 겪는 사용자를 만나게 될 것입니다. 조사해 보면 이 사용자는 사용자가 파일을 저장하는 NAS(Network Attached Storage) 시스템을 백업하는데도 편집할 때마다 문서를 복사했음을 알 수 있습니다. 또는 막대한 로그를 복제하기 위해 일괄 처리 프로세스를 사용하는 로그 서버가 할당된 서버 공간을 모두 차지하고 있는 경우도 있습니다. 이러한 문제를 해결할 수 있는 솔루션이 바로 Windows®, Linux 또는 Mac OS X에서 실행할 수 있는 Java 기반의 중복 항목 검색 프로그램인 zsDuplicateHunter Professional Edition입니다.
이 응용 프로그램을 사용하면 드라이브, 디렉터리 또는 네트워크 공유를 손쉽게 검색하고 잠재적인 중복 항목을 찾아낼 수 있을 뿐 아니라, 이름 비교 수준을 뛰어 넘어 파일 크기, 파일 체크섬 또는 심지어 파일 다이제스트 계산을 기준으로 파일을 그룹화하여 정리 중인 파일이 실제로 다른지 확인할 수 있습니다. 또한 중복 항목을 영구적으로 삭제할 필요 없이 단지 사전 예방 조치로서, 표시된 모든 중복 항목을 지정한 폴더로 이동할 수 있습니다.
또 하나의 멋진 기능은 깨끗한 원본 디렉터리를 선택한 뒤 디스크의 다른 디렉터리에 있는 중복 파일은 모두 지울 수 있는 "Keep Files in this Folder, Delete Duplicates Elsewhere(이 폴더에 있는 파일은 유지, 다른 위치에 있는 중복 파일은 삭제)" 옵션입니다. 검색 결과 내에서 파일을 두 번 클릭하여 연결된 파일 뷰어로 열거나, 검색 결과를 정렬하거나, 선택하여 원하는 정확한 결과를 얻을 수 있습니다. 멋진 "IT pro(IT 전문가)" 기능을 사용하면 중복 항목을 찾는 동안 사용할 수 있는 메모리 양을 조정할 수 있습니다. 추가적인 보호 수단이긴 하지만, 숨김 또는 시스템 파일을 검색하지 않도록 설정하면 삭제해서는 안 되는 파일이나 운영 체제 또는 다른 응용 프로그램에서 관리하는 파일이 삭제되지 않도록 할 수도 있습니다.
Professional Edition에서 제공하는 정교한 필터를 검색 결과 집합에 적용하면 정규식을 통해 제거할 파일을 정확히 찾을 수 있습니다.
가격: 단일 사용자 라이선스당 $39.95

이동 시 응용 프로그램 휴대
MojoPac
www.mojopac.com
다른 환경으로 이동하여 작업하면서 자주 사용하던 응용 프로그램이나 바탕 화면 설정을 그대로 사용하고 싶거나 다른 사람의 데스크톱에 흔적을 남기고 싶지 않다면 RingCube Technologies의 MojoPac 사용을 고려해 보는 것이 좋습니다.
이름은 다소 이상하지만, MojoPac을 사용하면 Zune이나 iPod와 같이 USB 2.0을 통해 호스트 시스템에 연결할 수 있는 개인 미디어 장치나 USB 하드 드라이브 또는 심지어 저장 공간이 충분한 휴대폰을 사용하여 사용자의 설정과 응용 프로그램을 모든 Windows XP 시스템(Home, Professional, Media Center 또는 Tablet)으로 이동할 수 있습니다. 이 문서를 작성할 당시에는 Windows Vista™와 Windows 2000 호스트가 지원되지 않았지만 제품 웹 사이트에 있는 설명서에 따르면 이러한 OS를 지원하는 업그레이드가 곧 제공될 것입니다.
MojoPac을 통한 설정의 휴대
MojoPac을 통한 설정의 휴대 (더 작게 보려면 이미지를 클릭하십시오.)
MojoPac을 통한 설정의 휴대
MojoPac을 통한 설정의 휴대 (더 크게 보려면 이미지를 클릭하십시오.)
현재는 호스트 시스템에 대한 관리자 권한이 있어야 MojoPac을 사용할 수 있지만 개발 중인 2.0 버전에서는 제한된 사용자 모드가 지원될 예정입니다. 이 도구는 기본적으로 호스트 OS와 저장 장치 간의 간섭을 실행합니다. MojoPac 응용 프로그램을 휴대용 장치에 설치한 후 처음 시작하면 초기 Windows 계정 설정 프로그램이 실행되어 MojoPac 사용자의 개인 설정이 MojoPac 장치에 구성됩니다.
일단 실행된 후에는 호스트 시스템과 Mojo 시스템 간에 쉽게 전환할 수 있습니다. 화면 상단의 도구 모음(최소화할 수 있음)을 클릭하기만 하면 됩니다. MojoPac이 작동 중인 경우라도 평상시대로 Mojo 장치에 응용 프로그램을 설치할 수 있습니다. 추가 정보 문서에 설명한 대로 기본 디렉터리에 설치하는 데 대한 중요한 경고에만 주의한다면 진행할 준비가 된 것입니다.
MojoPac에는 자신의 고유 설정을 가지고 이동하고자 하는 IT 전문가에게 아주 중요한 자산이 될 수 있는 충분한 잠재력이 있습니다. 예를 들어 모든 시스템 유틸리티, 패킷 검색기 및 트래픽 모니터가 포함된 MojoPac을 사용하여 조직 내의 PC에서 문제를 해결하면서도 아무런 흔적을 남기지 않을 수 있습니다.
가격: 단일 사용자 라이선스당 $49.99

서평
Administrator’s Guide to SQL Server 2005(SQL Server 2005 관리자 가이드)
www.aw-bc.com
SQL Sever 2005에서 제공하는 기능의 놀라운 잠재력과 넓은 적용 범위에 대한 인식이 IT 그룹 내에서 점점 더 확산되고 있습니다. 이 응용 프로그램을 통해 광범위한 XML 데이터 지원에서 SSIS(SQL Server Integration Services)와 SQL Server 2005 Service Broker에 이르는 유용한 다수의 향상된 기능을 추가할 수 있습니다. 현재 환경에 맞는 방법으로 업그레이드하거나 최근에 릴리스한 SQL Server 2005 인스턴스를 관리하는 데 도움이 되는 정보를 얻으려면 Buck Woody가 저술한 탁월한 참조 가이드인 Administrator’s Guide to SQL Server 2005(SQL Server 2005 관리자 가이드)(Addison-Wesley Professional, 2006)를 참조하십시오.
이 책은 새 서버 플랫폼에 적용되는 유용한 실무 관리 정보를 제공하면서도 다른 참조서와는 달리 간결합니다. 이 책의 첫 단원에서는 응용 프로그램의 요구에 맞게 인프라의 크기를 조정하는 방법을 설명하고 다양한 시나리오에 적합한 SQL Server 버전도 알려 줍니다. 또한 설치에 의해 불가피한 성능 병목 현상이 발생하지 않도록 인프라를 설계하는 방법에 대한 아이디어도 제공합니다.
이어지는 단원에서는 고급 SQL Server Profiler나 새 SQL Server Management Studio 등과 같은, SQL Server와 함께 제공되는 여러 가지 도구에 대해 설명합니다. 또한 유지 관리와 자동화 작업에 대한 자세한 설명과 함께, 서버 프로필을 기준으로 증설 계획을 세우는 방법 그리고 구현에 적합한 유지 관리 계획을 도출하는 방법을 살펴봅니다.
보안 관련 장에서는 네트워크와 하드웨어에서 OS와 SQL Server 인스턴스에 이르기까지, 설치를 보호하는 방법에 대해 알아봅니다. 새 플랫폼에서 제공하는 추가된 암호화, 인증서 및 키 관리 서비스도 간단히 살펴볼 수 있습니다.
구현 요구 사항에 따라 시스템의 고가용성을 유지하는 메커니즘에 대해 설명하는 장에서는 가동 시간 요구 사항을 달성하기 위한 방법으로 클러스터링, 데이터베이스 미러링, 복제 및 로그 전달에 대해 알아봅니다. 가상화가 물리적으로 인프라를 분리하는 오버헤드 없이 고가용성을 달성하는 훌륭한 방법으로 자리 잡아감에 따라, 이 책에서는 Microsoft Virtual Server를 사용하여 두 개의 노드로 구성된 클러스터를 설정하는 과정을 단계별로 안내합니다.
SSIS 관련 장에서는 새 도구를 사용하여(DTS여, 안녕!) ETL(추출, 변환 및 로드) 기능을 개발하고 배포하는 방법과 서비스를 사용하여 모니터링, 전자 메일 알림 및 백업 작업을 만드는 방법을 보여 줍니다.
마지막 몇 장에서는 새 SQL Server 플랫폼에서 제공하는 Reporting 및 Analysis Services에 대해 자세히 알아봅니다. 여기서는 보고서 디자인 및 만들기, 보고 시스템 관리, 분석 서비스 배포를 유지 관리하는 데 필요한 사항 등을 설명합니다.
지금까지 설명한 것처럼 Administrator’s Guide to SQL Server 2005는 SQL Server 2005의 관리, 모니터링 및 업그레이드 작업을 이해하는 데 큰 도움이 됩니다.
가격: $49.99


 SQL Q&amp;A: 데이터베이스 크기, 미러링 및 표시된 트랜잭션 등
SQL Q&A
데이터베이스 크기, 미러링 및 표시된 트랜잭션 등
편집자: Nancy Michell

클러스터 이동
Q: Windows® 클러스터와 SQL Server™ 클러스터를 비롯한 실제 기본 서버의 새 IP 주소로 SQL Server 2000 클러스터를 이동해야 합니다. 전체 솔루션을 다시 빌드해야 합니까?
A: 아니요. SQL Server 설치 프로그램을 실행하여 IP 주소를 수정하기만 하면 됩니다. 자세한 내용은 기술 자료 문서를 참조하십시오.

데이터베이스 크기
Q: 10GB에 육박하는 업무에 중요한 데이터베이스, 단순 복구 모델, 9,850MB의 주 파일 및 88MB의 트랜잭션 로그 파일이 포함된 SQL Server 2000 SP4를 프로덕션 환경에서 사용하고 있습니다. 데이터베이스 백업 크기도 거의 10GB에 달합니다. 보다 나은 성능을 얻으려면 데이터베이스 크기를 줄여야 합니까? 크기를 줄여야 할 경우 DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE을 사용해야 합니까? 아쉽게도 항상 사용량이 많아서 이러한 유지 보수 작업을 수행하기에 적합한 시간대가 없습니다.
A: DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE은 데이터베이스에서 삭제와 업데이트가 여러 번 수행되어 데이터 볼륨이 줄어드는 경우에만 유용합니다. 그러나 이것은 큰 문제가 되지 않을 것 같습니다. 10GB의 디스크 공간은 오늘날 20달러 정도의 가치를 갖습니다. 100GB 정도의 디스크 공간을 추가하여 그대로 실행하는 것이 더 효율적이지 않을까요? 디스크 공간이 더 많은 조각으로 분할되면 성능이 저하되지만 별다른 유지 관리 작업을 수행할 수 없다면 선택의 폭은 넓지 않습니다. 이러한 경우 두 번째 데이터베이스 복사본을 사용하는 사용자들도 있습니다. 이러한 사용자들은 복제를 통해 백업 복사본을 최신 상태로 유지하고 백업 복사본을 유지 관리한 다음 응용 프로그램을 백업으로 전환합니다. 이렇게 하려면 약간의 코드 변경이 필요하고 단순 복구 모델을 FULL 또는 BULK_LOGGED로 변경해야 하지만 장기적으로는 보면 좋은 효과를 가져올 수 있습니다.

업그레이드 및 성능
Q: 두 개의 응용 프로그램을 SQL Server 2000에서 SQL Server 2005로 이동해야 합니다. 업그레이드 중 어떻게 하면 성능 저하 문제를 피할 수 있습니까?
A: 일반적으로 업그레이드 중에는 다음과 같은 상황으로 인해 성능 저하가 발생할 수 있으므로 이러한 상황이 발생하지 않도록 해야 합니다.
  1. SQL Server 2005로 업그레이드한 후 통계를 다시 작성하지 않은 경우.
  2. 서로 다른 두 가지 데이터 형식을 비교하는 JOINS 및 WHERE 절이 있는 경우 이로 인해 성능이 저하됩니다. 특히 SQL Server 2000 SP3 또는 이전 버전에서 실행했었던 경우에 더욱 그렇습니다(support.microsoft.com/kb/271566/ 참조).
  3. SQL Server 2005 인스턴스가 올바르게 구성되어 있지 않으며, 메모리, AWE(Address Windowing Extension), 드라이버 등이 잘못 구성되어 있는 경우. SQL Server 2000을 실행하는 시스템의 설정이 수정되었는데 이를 수행한 사용자가 문서화하지 않고 퇴사하여 SQL Server 2005 인스턴스에 대해서는 적용되지 않았습니다.
  4. 하드웨어에 문제가 있는 경우. 새 하드웨어가 사양 면에서는 좋아 보여서 구입하지만 실제 성능 면에서는 그렇지 못한 경우가 종종 있습니다.
SQL Server 인스턴스를 프로덕션 환경에 적용하기 전에 기준선을 설정하여 성능이 예상대로 구현되는지 확인해야 합니다. 이 경우 인프라는 발생 가능한 문제에서 제외할 수 있습니다. 디스크, I/O, 메모리와 같은 Perfmon 카운터를 확인하고 인스턴스 간에 이 카운터를 비교해야 합니다.

데이터베이스 미러링
Q: 데이터베이스 미러링을 사용하고 있는데 READ_COMMITTED_SNAPSHOT 데이터베이스 옵션을 설정하고 싶습니다. 그런데 미러링을 설정한 후 이 데이터베이스 옵션을 설정하려고 하면 DB가 미러링 세션에 있어서 명령을 실행할 수 없다는 예외 메시지가 표시됩니다.
A: READ_COMMITTED_SNAPSHOT 옵션을 설정하고 적용하려면 데이터베이스를 다시 시작해야 하기 때문에 이와 같은 문제가 발생합니다. 따라서 미러링 세션을 중단하고 옵션을 설정한 다음 데이터베이스를 다시 시작해야 합니다. 이러한 단계를 수행한 후에야 미러링을 다시 설정할 수 있습니다. 미러 데이터베이스는 세션이 설정된 후 옵션을 선택하고 장애 조치가 발생할 경우 선택한 옵션을 사용합니다.

Q: 비동기 미러링을 설정하려고 하는데 1418 오류가 표시됩니다. Netstat –ano를 실행하면 SQL Server가 모든 서버에서 올바른 포트를 수신하고 있다는 메시지가 표시됩니다. 그런데 미러링을 시작하려고 하면 오류가 표시됩니다. 왜 그런 것인지요?
A: 방화벽이 통신을 차단하는 것이 원인일 수 있습니다. 이 문제는 비교적 자주 발생하는 문제이므로 확인해 봐야 합니다. 자세한 내용은 데이터베이스 미러링 설정 문제 해결 및 MSSQLSERVER_1418(영문) 백서를 참조하십시오.
이 문제는 비동기 미러링에 국한된 문제가 아닙니다. 실제로, 동기 미러링에서도 발생할 수 있습니다.
표시되는 오류 메시지("서버 네트워크 주소 "%.*ls"에 연결할 수 없거나 주소가 없습니다. 네트워크 주소 이름 및 로컬과 원격 끝점이 작동 중인지 확인하십시오.")는 올바른 것입니다. 이 오류의 원인은 대개 원격 파트너가 없기 때문이 아니라 단순히 원격 파트너에 연결할 수 없기 때문입니다.
이 문제는 원격 파트너가 다운되거나 포트를 수신하지 않거나 끝점이 다운된 경우(파트너가 동일한 암호화 메커니즘을 협상할 수 없거나 기타 다른 인증 문제가 있는 경우 나타날 수 있음)에 발생할 수 있습니다. 또한 명령을 보낸 파트너 쪽의 방화벽에서 파트너를 차단하는 경우도 문제의 원인이 될 수 있습니다.
흔히 간과될 수 있는 몇 가지 다른 문제로는 데이터 원본 이름(DSN) 및 이름 확인 문제가 있습니다. 이 문제의 경우 일반적으로 정규화된 도메인 이름을 사용하는 것이 좋습니다. 따라서 방화벽에서 문제가 자주 발생할 경우 원인은 여러 가지일 수 있다는 점을 유념하십시오.

Q: SQL Server 2005 미러링을 사용하려고 합니다. 여러 응용 프로그램을 동일한 SQL Server 인스턴스의 여러 데이터베이스에 연결할 때는 미러링을 사용하지 않는 것이 좋다고 들었습니다. 맞습니까?
A: 응용 프로그램마다 자체 데이터베이스를 가지고 있는지 또는 응용 프로그램에서 데이터베이스 간 트랜잭션 또는 DTC(Distributed Transaction Coordinator) 트랜잭션을 사용하는지 여부에 따라 답은 달라집니다. 데이터베이스 간 트랜잭션을 사용할 경우 미러링으로 인해 논리적 불일치가 발생하여 트랜잭션이 예상대로 커밋되지 않을 수 있습니다. 이 경우 발생할 수 있는 문제에 대한 자세한 내용은 여기(영문)를 참조하십시오.
여러 응용 프로그램에서 여러 개의 데이터베이스를 사용하지만 각 응용 프로그램이 자체 데이터베이스를 가지고 있는 경우에는 미러링으로 인해 이러한 문제가 발생하지는 않습니다.

표시된 트랜잭션
Q: 표시된 트랜잭션이란 정확히 무엇이며, 한 데이터베이스는 SQL Server이고 다른 한 데이터베이스는 Oracle일 경우 이것을 어떻게 사용할 수 있습니까?
A: 트랜잭션을 표시한다는 것은 DBA가 정기적으로 모든 로그의 동일한 위치에 표시를 하는 작업을 말합니다. 테이블을 트랜잭션 표시까지 복원하는 기능과 병행하여 이 작업을 수행하면 모든 데이터베이스를 동일한 지점까지 복원할 수 있습니다. 그러나 이렇게 하면 관련된 모든 데이터베이스를 복원해야 하고 모든 데이터베이스의 데이터가 손실되기 때문에 매우 위험할 수 있으므로 로그 파일이 손실되지 않도록 하여 이러한 상황을 피해야 합니다. 표시된 트랜잭션은 SQL Server에만 해당하는 사항이므로 분산 트랜잭션에 SQL Server가 아닌 다른 데이터베이스가 포함되어 있을 경우에는 트랜잭션 표시를 수행할 수 없습니다. 일반적으로 트랜잭션 표시를 사용하는 분산 데이터베이스 시스템은 극소수입니다. 이러한 시스템에서는 트랜잭션 로그가 하나라도 손실되는 것을 치명적인 이벤트로 간주하므로 이를 복구하는 데는 엄청난 수작업이 수반됩니다.

Access에서 T-SQL로의 변환 도구
Q: 저장 프로시저에 사용할 수 있는 자동화된 Access™ SQL 대 T-SQL 변환 도구가 있습니까?
A: 여기(영문)에서 다운로드할 수 있는 SQL Server Migration Assistant(SSMA) for Access를 사용해 보십시오. 이 사이트에서는 SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase 및 Informix 데이터베이스를 Microsoft® SQL Server 2000으로 마이그레이션하는 방법도 확인할 수 있습니다.
Access에서 SQL Server로 업사이징하는 경우 Office 업사이징 마법사를 사용할 수도 있지만 그림 1에 표시된 것처럼 SSMA for Access를 사용하면 변환 평가 보고서 및 네트워크 검색 등의 더 많은 기능을 사용할 수 있습니다. 또한 SSMA for Access를 사용하면 Office 업사이징 마법사에서는 제대로 처리할 수 없는 여러 가지 문제도 해결할 수 있습니다.
그림 1 SQL Server Migration Assistant for Access
그림 1 SQL Server Migration Assistant for Access (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 SQL Server Migration Assistant for Access
그림 1 SQL Server Migration Assistant for Access (더 크게 보려면 이미지를 클릭하십시오.)

비클러스터형 인덱스
Q: 두 개의 GUID(GUID1 및 GUID2)로 기본 키를 만든 테이블이 있으며 GUID1과 GUID2에는 이미 고유 클러스터형 인덱스가 있습니다. 성능 향상을 위해 GUID1과 GUID2에 또 다른 비클러스터형 인덱스를 만들려고 합니다. 이 인덱스를 고유 인덱스로 선언할 경우 성능 오버헤드가 발생할까요?
A: 비클러스터형 인덱스를 고유 인덱스로 선언할 경우 성능 저하가 발생하지는 않지만 실제로 인덱스 트리의 수준 수가 줄어들 수 있습니다.
비클러스터형 인덱스를 고유하지 않은 인덱스로 선언할 경우 루트 및 비-리프 페이지에서 인덱스 항목의 키 부분에 행 로케이터가 추가됩니다. 이는 중복된 키가 있을 경우 동의어 체인을 검색하지 않도록 하여 인덱스 항목을 쉽게 삭제하고 업데이트하기 위한 것으로, 로케이터가 추가된 해당 키의 시스템 검색(Seek) 작업을 통해 변경할 특정 항목의 위치를 찾을 수 있습니다. 그 결과로 해당 항목이 더 길어집니다. 선택한 클러스터 키를 사용할 경우에는 더욱 길어집니다. 따라서 루트 및 비-리프 페이지가 보다 빠르게 채워집니다. 인덱스가 고유한 경우에는 이와 같이 선언해야 합니다.
요약하자면, 테이블에 클러스터형 인덱스가 있는지 여부와 관계없이 테이블에 있는 비클러스터형 인덱스를 고유하지 않은 인덱스로 선언할 경우 루트 및 다른 비-리프 페이지의 인덱스 항목에 로케이터가 추가됩니다.
또한 int 식별자 열을 서로게이트 키로 사용한 다음 두 개의 고유 인덱스인 (GUID1, GUID2) 및 (GUID2, GUID1)을 추가할 경우 인덱스에 32바이트 클러스터링 키 대신 4바이트 클러스터링 키가 생기므로 성능이 향상됩니다.

업데이트 잠금
Q: 다음과 같은 구조의 저장 프로시저가 있습니다.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
이 저장 프로시저는 잠금을 수행하는 데 하나의 호출자만 허용하므로 다른 호출자는 기다려야 합니다. 격리 수준을 줄여서 동일한 결과를 얻을 수 있을까요?
이 트랜잭션에는 쿼리가 한 개뿐이므로 READ COMMITTED는 올바른 격리 수준으로 보입니다. 또한 다른 트랜잭션에서 동일한 레코드를 업데이트하고 있을 경우 이 트랜잭션은 다른 트랜잭션을 기다려야 합니다. 맞습니까?
A: 이 경우 다른 호출자를 기다리게 하는 것은 직렬화 가능 설정이 아니라 업데이트 자체입니다. 격리 수준을 READ COMMITTED로 설정할 수 있으며 업데이트 시 사용되는 인덱스에 대해서는 기본적으로 업데이트 잠금이 설정됩니다. 이로 인해 업데이트 중 동일한 명령문을 실행하는 다른 프로세스에서는 문제가 발생하므로 업데이트가 완료될 때까지 다른 프로세스는 차단됩니다. UPDATE가 유일한 문일 경우 여기에 명시적 트랜잭션은 필요하지 않으며 문이 명시적 트랜잭션에 없을 경우 각 문은 암시적으로 자체 트랜잭션에 존재합니다.
그러나 UPDATE 문의 WHERE 절과 일치하는 행이 없을 경우 직렬화 가능 격리 수준을 사용하면 이러한 행이 다른 트랜잭션에서 삽입되거나 수정되는 것을 방지할 수 있습니다. READ COMMITTED 격리에서 UPDATE를 실행할 경우에는 이러한 문제가 발생하지 않으며 다른 트랜잭션에서는 업데이트를 충족하는 행을 사용할 수 있습니다. 저장 프로시저 코드가 여기에 표시된 코드와 유사할 경우 이러한 방법(직렬화 가능 또는 트랜잭션)을 사용하는 것이 적절하지 않을 수 있으므로 그냥 업데이트를 수행하십시오.

기술적 자문을 주신 Microsoft IT 전문가: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip 및 Frankie Yuen


 Utility Spotlight: 그룹 정책 인벤토리
Utility Spotlight
그룹 정책 인벤토리
Greg Steen
이 기사의 코드 다운로드: GPInventory.exe (150KB)

내가 가진 자산을 추적하지 않고서 무엇을 가지고 있는지 알 수 있는 방법이 있을까요? 인벤토리 세부 정보를 간단히 파악할 수 있다면 예산 배정 회의와 연간 감사를 준비하는 수고를 덜 수 있을 것입니다. 물론 누가 무엇을 왜 가지고 있는지와 업그레이드를 위해 어떤 조치를 취해야 하는지를 아는 것도 필요하겠지요.
이러한 모든 것을 할 수 있는 도구가 바로 Windows Server® 2003 Resource Kit에 포함된 그룹 정책 인벤토리(GPInventory.exe)입니다. 이 프로그램을 사용하면 그림과 같이 여러 원격 호스트에서 RSOP(Resultant Set of User Policy) 및/또는 WMI(Windows® Management Instrumentation) 쿼리로 시스템 정보를 쿼리하고 검색할 수 있습니다. 이 프로그램은 그룹 정책 정보를 손쉽게 검색하기도 하지만 설치된 응용 프로그램, 프로세서 이름 및 속도, 설치된 핫픽스 목록 등의 시스템 세부 정보를 효과적으로 추출합니다. 게다가 Windows Server 2003 Resource Kit에 포함되기 때문에 100% 무료입니다.
그림 1 GPInventory를 사용하여 정보 수집
그림 1 GPInventory를 사용하여 정보 수집 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 GPInventory를 사용하여 정보 수집
그림 1 GPInventory를 사용하여 정보 수집 (더 크게 보려면 이미지를 클릭하십시오.)
다양한 방법으로 GPInventory.exe를 사용할 수 있습니다. 예를 들어 품질 보증 상태를 확인해야 할 경우 일일이 뒤지지 않고서도 네트워크에 있는 PC의 일련 번호나 서비스 번호를 수집할 수 있습니다. 또는 테스트 환경에서 시스템이 현재 사용 중인지 알고 싶은 경우 앉은 의자에서 일어나지 않고도 시스템에 현재 로그온한 사용자를 쿼리할 수 있습니다. 블레이드 서버가 설치되어 있고 QA 환경 정리 및 복원을 위해 정기적으로 이미지가 블레이드로 전송되는 경우 PC 설치 날짜를 쿼리하여 마지막 이미지가 적용된 시기를 확인할 수 있습니다.
GPInventory는 사용하기도 매우 쉽습니다. 인벤토리를 조사할 컴퓨터 목록이 있는 파일을 가리키고 실행할 쿼리를 선택한 다음 목록을 처리하면 됩니다. 그러면 GPInventory가 목록에 있는 컴퓨터 각각에 연결하여 쿼리합니다. 빠른 쿼리를 위해서는 Active Directory®에서 바로 대상 시스템을 선택하고 Query(쿼리) 메뉴에서 수행할 쿼리 작업을 선택할 수 있습니다.
시스템에 대해 RSOP 쿼리를 실행하려면 도메인 관리자와 위임된 관리자에게 기본적으로 부여되는 정책 결과 집합 생성(로깅) 권한이 있어야 합니다. WMI 컨트롤 MMC 스냅인을 사용하여 대체 사용자에게 root\cimv2 네임스페이스에 대한 계정 사용 및 원격으로부터 사용 가능 권한을 부여한 경우가 아니면 원격 시스템에 대한 관리자 권한이 있어야 WMI 쿼리를 실행할 수 있습니다.
쿼리를 실행했으면 결과를 탭 구분 텍스트 파일이나 XML 파일로 저장할 수 있습니다. 두 파일 모두 Microsoft® Excel®로 가져와서 분석할 수 있습니다. 정렬한 다음 자동 필터를 적용하면 모든 세부 정보를 찾을 수 있습니다.
GPInventory가 명령줄 실행도 지원하므로 시스템 정보를 쿼리하는 예약된 작업을 간편하게 설정하고 GUI 작업 없이 바로 XML 파일로 저장할 수 있습니다. 이 기능은 근무 외 시간에 실행하는 편이 더 나은 장기 실행 쿼리의 경우에 매우 유용합니다.
이 도구는 기본 RSOP 및 WMI 쿼리 집합과 함께 제공되지만 필요한 쿼리가 없는 경우에는 직접 사용자 지정 목록을 쿼리 파일에 추가하거나 편집 또는 업데이트할 수 있습니다. 포함된 도움말 문서에서는 쿼리 목록 XML 파일에서 새 쿼리를 정의하는 방법을 보여 줍니다.
GPInventory.exe는 네트워크를 통해 Windows를 실행 중인 시스템에서 인벤토리, 그룹 정책, 상태 정보 등을 수집할 수 있는 놀라운 도구입니다. Microsoft 웹 사이트의 다운로드 섹션에서 그룹 정책 인벤토리 도구에 대한 링크를 찾을 수 있습니다.

Greg Steen은 사업가이자 열성적인 기술 전문가로, IT 전문가의 개발 및 운영 작업에 도움을 줄 수 있는 새로운 도구와 방법을 끊임없이 연구하고 있습니다.


 The Cable Guy: Windows에서 QoS 지원
The Cable Guy
Windows에서 QoS 지원
Joseph Davies
이 문서는 Windows Server "Longhorn"의 시험판 버전의 일부를 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

QoS(서비스 품질)는 비용 효율적인 방식으로 네트워크 트래픽을 관리함으로써 가정 및 기업에서 사용자 환경을 개선할 수 있는 일련의 기술을 의미합니다. QoS 기술을 사용하여 대역폭을 측정하고 네트워크 상태의 변화를 탐지하며(예: 네트워크 정체 또는 대역폭 가용성)
트래픽의 우선 순위를 정하거나 트래픽을 제한할 수 있습니다. 예를 들어 음성 또는 비디오 응용 프로그램처럼 대기 시간에 민감한 트래픽의 전달에 우선 순위를 두고 대량 데이터 전송과 같은 대기 시간에 민감하지 않은 트래픽으로 인한 영향을 제어하려는 경우 QoS를 사용할 수 있습니다. TCP/IP 트래픽에 우선 순위를 지정하여 전송하려면 호스트 및 네트워크 인프라 장치가 이를 지원해야 합니다. 이 칼럼에서는 Microsoft® Windows® 기반 호스트에 QoS를 사용하는 방법에 대해 설명합니다.
TCP/IP 네트워크에 QoS를 정의할 때 가장 문제가 되는 점은 IP 트래픽의 우선 순위를 지정하고 그에 따라 전송하는 방법을 찾는 것입니다. RFC 791 문서에서는 IP에 우선 순위, 지연, 처리량, 안정성 및 비용적인 특성의 가용성을 규정하기 위한 TOS(Type of Service) 필드를 정의하고 있지만, 근본적으로 IP는 각 패킷을 선착순으로 동일하게 처리하는 최선형(Best-effort) 방식의 데이터그램 기반 패킷 교환 기술입니다.

우선 순위가 지정된 전송 구성
우선 순위가 지정된 전송 서비스를 제공하려면 몇 가지 작업을 수행해야 합니다. 예를 들어 표시된 트래픽을 별도로 처리하고 전송 호스트에서 나가는 트래픽에 표시를 남기도록 네트워크 인프라를 구성하거나, 나가는 트래픽(예: 주소 및 포트 번호)의 특성을 기준으로 별도의 처리 방법을 제공하도록 전송 호스트에서 네트워크 인프라를 동적으로 프로그래밍하게 할 수 있습니다.
TCP/IP 트래픽의 경우 몇 가지 방법을 사용하여 전송 우선 순위를 지정할 수 있습니다. 예를 들어 이더넷의 네트워크 인터페이스 계층에서 IEEE 802. 1p 태그 지정 기능은 이더넷 프레임의 VLAN(Virtual Local Area Network) 헤더에 있는 3비트 우선 순위 필드를 사용해 호스트에서 전송한 프레임에 표시를 하여 전송 우선 순위를 지정합니다. VLAN 헤더는 이더넷 헤더의 Source Address 필드와 Length 필드(IEEE 802.3 프레임용) 또는 EtherType 필드(Ethernet II 프레임용) 사이에 위치합니다.
전송 호스트에 802.1p 태그 지정 기능을 구현하려면 네트워크 어댑터와 장치 드라이버가 802.1p를 지원하고 네트워크 어댑터에서 802.1p 지원이 활성화되어 있어야 합니다. 보통 802.1p 지원은 네트워크 어댑터 드라이버의 속성에서 고급 탭을 선택하면 설정할 수 있으며, 이더넷 스위치에서도 802.1p 지원을 설정해야 합니다.
WMM(Wi-Fi Multimedia)에 대한 Wi-Fi Alliance 인증은 무선 IEEE 802.11용 네트워크 인터페이스 계층에서 우선 순위가 지정된 네트워크 트래픽에 대해 음성, 비디오, 최선형, 배경(앞쪽이 높은 우선 순위)의 네 가지 액세스 범주를 정의합니다. WMM 우선 순위 지정에 대한 호스트 지원을 위해서는 무선 네트워크 어댑터와 드라이버가 모두 WMM을 지원해야 하며 무선 AP(액세스 지점)에서 WMM이 활성화되어 있어야 합니다.
인터넷 계층에서는 차등화 서비스(Differentiated Services)를 사용할 수 있으며 IP 헤더에서 DSCP(Differentiated Services Code Point) 값을 설정할 수 있습니다. RFC 2472에 정의된 바에 따르면, DSCP 값은 IPv4(IP 버전 4) TOS 필드 및 IPv6(IP 버전 6) Traffic Class 필드의 상위 6비트입니다.
오늘날 대부분의 기업 라우터에서는 DSCP 트래픽 차별화를 지원하지만 기본적으로 비활성화되어 있는 경우가 많습니다. DSCP 지원 라우터는 전달 도중 DSCP 값을 읽은 다음 특정 큐에 해당 패킷을 배치합니다. 예를 들어 전달된 패킷을 사용자가 지정한 DSCP 값을 기준으로 높은 순위, 최선형에 배치하거나 최선형 큐보다 낮은 곳에 배치하도록 라우터를 구성할 수 있습니다. 큐 및 DSCP 값을 구성하여 DSCP 표시가 지정된 트래픽의 서비스 수준을 차별화할 수 있습니다. 예를 들어 업무에 중요한 네트워크 트래픽이 낮은 우선 순위에 속하는 대량 데이터 트래픽 때문에 지연되지 않고 우선적으로 전달되도록 할 수 있습니다. WMM 사양은 WMM 액세스 범주가 DSCP 값에 매핑되는 방식을 정의합니다. WMM 지원 무선 AP는 DSCP 값을 읽고 해당 액세스 범주를 기준으로 트래픽을 처리합니다.
또한 인터넷 계층에서 RSVP(Resource Reservation Protocol)를 사용할 수도 있습니다. RSVP는 RFC 2205에서 정의된 신호 프로토콜로, 호스트는 이 프로토콜을 사용하여 네트워크 끝점에 걸쳐 대역폭을 보존할 수 있습니다. 그러나 RSVP는 네트워크에 널리 배포된 프로토콜이 아니며 현재 Windows XP, Windows Server® 2003, Windows Vista™ 또는 현재 베타 버전 상태인 다음 버전의 Windows Server(코드명 "Longhorn")에서 지원되지 않습니다.
우선 순위가 지정된 패킷을 전송하려면 응용 프로그램 또는 운영 체제 구성 요소에서 802.1p 우선 순위나 DCSP 값을 지정할 수 있어야 합니다. 다음 섹션에서는 Windows 구성 요소 또는 Windows 기반 응용 프로그램에서 이더넷 프레임에 대한 802.1p 우선 순위 또는 TCP/IP 트래픽에 대한 DSCP 값을 지정하는 방법에 대해 설명합니다.

Windows XP 및 Windows Server 2003에서의 QoS
Windows XP 및 Windows Server 2003에서는 트래픽에 QoS 매개 변수를 할당할 수 있는 API를 제공합니다. 응용 프로그램 개발자는 Winsock(Windows 소켓) 및 GQoS(Generic QoS) API를 사용하여 응용 프로그램 수준에서 소켓별로 QoS 매개 변수를 적용할 수 있습니다. 네트워크 관리자는 트래픽 관리 도구를 사용하여 TC(Traffic Control) API를 호출하고 호스트 수준에서 QoS 매개 변수를 적용할 수 있습니다.
Winsock 및 IP_TOS 소켓 옵션을 사용하여 소켓의 나가는 패킷에 대해 DSCP 값을 설정할 수 있습니다. 그러나 기본적으로 TCP/IP 스택은 IP_TOS 소켓 옵션을 무시합니다. IP_TOS 소켓 옵션을 사용하려면 먼저 DWORD 레지스트리 값(DisableUserTOSSetting=0)을 다음 레지스트리 키(그림 1 참조) 아래에 만들고 설정해야 합니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
그림 1 DisableUserTOSetting의 레지스트리 값 설정
그림 1 DisableUserTOSetting의 레지스트리 값 설정
이 레지스트리 설정을 적용하려면 컴퓨터를 다시 시작해야 합니다.
GQoS API를 사용하면 IP_TOS 소켓 옵션을 사용하지 않고도 트래픽에 DSCP 값을 지정할 수 있습니다. GQoS는 Winsock2(Windows 소켓 2.0)의 일부입니다. 대부분의 QoS 지원 응용 프로그램은 Windows에서 QoS 기능을 호출하기 위해 GQoS API를 사용합니다. Windows XP SP2(서비스 팩 2)의 GQoS를 사용하면 응용 프로그램에서 DSCP 값을 설정하고 아웃바운드 트래픽을 제한할 수 있습니다. Windows XP SP2를 실행하고 있는 컴퓨터에서 802.1p 우선 순위 기능을 설정하려면 TC API를 사용해야 합니다.
TC API를 사용하면 로컬 호스트의 네트워크 트래픽을 제어하는 트래픽 제어 메커니즘을 이용할 수 있습니다. 또한 DSCP 값, 802.1p 태그 및 스로틀 속도를 직접 제어할 수 있습니다. 네트워크 관리자는 트래픽 관리 프로그램을 통해 QoS를 지원하지 않는 응용 프로그램을 대신하여 TC API를 직접 호출할 수 있습니다. GQoS API보다 수준이 낮은 TC API에는 관리자 권한이 필요합니다.
GQoS API와 달리 TC API는 동일한 전송 호스트의 여러 응용 프로그램에서 보내는 트래픽이 단일 QoS 흐름에 집결될 수 있도록 합니다. 이 과정에서 소스, 대상 IP 주소, 소스 및 대상 포트, 프로토콜(TCP 또는 UDP)에 따라 트래픽을 식별합니다. 예를 들어 특정 IP 주소로 가는 모든 트래픽은 호스트에서 보내는 응용 프로그램이 무엇인지에 관계없이 모든 소스 포트 및 대상 포트에 대한 단일 QoS 흐름에 포함될 수 있습니다. 반면 GQoS API는 응용 프로그램에서 소켓을 통해 전송되는 데이터에 대한 고유한 QoS 처리를 정의할 수 있도록 합니다.
Windows XP 및 Windows Server 2003 기반 컴퓨터에서 QoS 기능을 지원하려면 QoS 패킷 스케줄러 구성 요소가 설치되어 네트워크 연결 폴더의 네트워크 연결 속성에서 활성화되어 있어야 합니다(그림 2참조). Windows XP를 실행하는 컴퓨터의 경우 QoS 패킷 스케줄러 구성 요소(Psched.sys)가 기본적으로 설치 및 설정되어 있으며, Windows Server 2003에도 패킷 스케줄러 구성 요소를 설치할 수 있습니다.
그림 2 QoS 패킷 스케줄러 구성
그림 2 QoS 패킷 스케줄러 구성

Windows Vista 및 Windows Server "Longhorn"에서의 QoS
Windows Vista 및 Windows Server "Longhorn"에서는 보다 간편하고 향상된 방법으로 QoS 지원 기능을 사용할 수 있게 되었습니다. 이제 IT 직원은 정책에 기반한 QoS를 사용할 수 있으므로 API를 사용하거나 기존 응용 프로그램을 수정하지 않고도 DSCP 값을 설정하고 응용 프로그램 전송 속도를 제어할 수 있습니다. 개발자에게는 GQoS 및 TC API가 지원됩니다(Windows 다음 버전에 대한 지원 계획은 없음). 또한 IP_TOS Winsock 옵션이 제거되었습니다. 업그레이드 버전 및 향후 버전의 응용 프로그램에서 GQoS 및 TC API를 대체하고 QoS 지원을 간소화하기 위해 Windows Vista 및 Windows Server "Longhorn"에서는 qWAVE(Quality Windows Audio-Video Experience)라는 이름으로 알려져 있는 새로운 QoS2 API를 지원합니다.
Windows Server "Longhorn" 및 Windows Vista에서 정책 기반의 QoS를 사용하면 보다 나은 최종 사용자 환경을 제공하고 대역폭 확보에 드는 비용을 제어할 수 있으며 대역폭 제공 업체 또는 사업 부서와 세부적인 서비스 수준에 대해 협상할 수 있습니다. 전체 응용 프로그램 및 전체 Active Directory® 인프라를 대상으로 Windows Vista 또는 Windows Server "Longhorn"을 실행하고 있는 컴퓨터의 네트워크 대역폭을 중앙 집중적으로 관리할 수 있습니다. 응용 프로그램 계층 아래에서 트래픽 관리가 이루어지므로 정책 기반의 QoS 트래픽 관리를 위해 기존 응용 프로그램을 수정하지 않아도 됩니다.
Windows Server "Longhorn" 및 Windows Vista에서 정책 기반 QoS 설정을 사용하면 다음 조건을 기준으로, 나가는 트래픽의 전송 속도를 우선 순위에 따라 지정하거나 관리할 수 있습니다.
  • 보내는 응용 프로그램(실행 경로 및 이름)
  • 소스 또는 대상 IPv4 또는 IPv6 주소 또는 주소 접두사
  • 프로토콜(TCP, UDP 또는 모두 해당)
  • 소스 및 대상 포트 또는 포트 범위(TCP 또는 UDP)
QoS 정책은 사용자 로그인 세션에 적용되거나 Active Directory 컨테이너(예: 도메인, 사이트, OU(조직 구성 단위))와 연결된 GPO(그룹 정책 개체)의 일부인 컴퓨터에 적용되며, 보안 그룹에도 적용될 수 있습니다. QoS 정책은 그룹 정책의 일부로 기존 Active Directory 관리 인프라에 구축됩니다.
정책 기반의 QoS를 사용하면 트래픽의 우선 순위를 정의할 수 있습니다. QoS 정책을 구성하면 아웃바운드 IPv4 또는 IPv6 트래픽에 DSCP 값을 표시할 수 있습니다. 또한 아웃바운드 트래픽의 대역폭 사용도 관리할 수 있습니다. QoS 정책에 아웃바운드 트래픽에 대한 스로틀 속도를 구성할 수 있습니다. 이러한 제한을 통해 QoS 구성 요소는 나가는 네트워크 트래픽의 총량을 정해진 수준으로 제한합니다. 고급 설정의 구성을 통해 TCP 수신 창 크기를 최대로 설정하여 TCP 트래픽에 대한 인바운드 처리량을 지정하면 컴퓨터에서 인바운드 트래픽의 대역폭 사용을 관리할 수 있습니다.
Windows Vista 및 Windows Server "Longhorn"에는 QoS 패킷 스케줄러가 기본적으로 설치 및 설정되어 있습니다. Pacer.sys 구성 요소는 새로운 NDIS(Network Device Interface Specification) 6.0 경량 필터 드라이버로, 정책 기반 QoS와 QoS 사용 응용 프로그램의 트래픽에 대한 패킷 스케줄링을 제어합니다. Pacer.sys는 Windows XP 및 Windows Server 2003의 Psched.sys를 대체하는 구성 요소입니다.
인트라넷에서 정책 기반 QoS를 배포하려면 사용자 또는 컴퓨터 기반의 QoS 정책을 구성하고 이를 적절한 Active Directory 컨테이너에 적용해야 합니다. Windows Vista 또는 Windows Server "Longhorn" 기반 컴퓨터에서는 사용자 구성 또는 컴퓨터 구성 그룹 정책 업데이트 시 각 운영 체제에 알맞은 정책 기반의 QoS 설정을 다운로드하고 적용합니다.
네트워크에서 데이터 및 AV(오디오/비디오) 응용 프로그램을 공유하는 비율이 점차 증가하고 있으므로 데이터 트래픽보다 시간의 제약을 받는 AV 트래픽을 우선적으로 처리할 수 있는 QoS 솔루션이 필요합니다. 또한 무선 네트워크의 사용이 증가함에 따라 대기 시간 및 대역폭에 민감한 응용 프로그램과 관련한 문제가 발생하고 있습니다.
Windows Vista의 qWAVE 기능은 AV 응용 프로그램 및 무선 네트워크로 인해 발생하는 네트워크 문제를 해결할 수 있는 QoS 관련 소프트웨어 모듈 집합을 제공합니다. qWAVE는 QoS 하위 시스템에 통합되며 여러 가지 인터넷 및 네트워크 인터페이스 계층 패킷 우선 순위 기술이 사용됩니다. 또한 qWAVE는 여러 가지 다양한 AV 스트림(QoS가 필요한 실시간 흐름)과 데이터 스트림(전자 메일 또는 파일 전송과 같은 최선형 흐름)을 동시에 지원합니다.
qWAVE 기술은 LAN 대역폭을 감지하고 모니터링하며 네트워크의 QoS 기능을 탐지할 뿐 아니라 분산된 허용 제어를 통해 네트워크 대역폭이 공정하고 일관성 있게 사용되도록 합니다. 이러한 기술을 통해 고급 AV 스트리밍 기술이 구현되므로 응용 프로그램에서는 변화하는 네트워크의 상태를 동적으로 반영할 수 있습니다. 이러한 기능은 QoS2 API를 통해 개발자에게만 제공됩니다.
Windows Vista 및 Windows Server "Longhorn"의 QoS2 API는 GQoS API 및 IP_TOS Winsock 옵션을 대체하는 기능이며 기존의 GQoS API보다 사용하기가 훨씬 편리합니다.

자세한 정보
QoS에 대한 자세한 내용을 보려면 TechNet에서 풍부하고 다양한 자료를 참조하십시오. 다음 Microsoft Quality of Service 웹 사이트(영문)를 참조하시기 바랍니다. 또한 Windows Core Networking 블로그(영문)에서 QoS 관련 섹션도 확인하시기 바랍니다.

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰고 가르치는 일을 하고 있습니다. Microsoft Press®에서 5권의 책을 저술한 그는 월간 TechNet Cable Guy 칼럼(영문)의 저자이기도 합니다.


 Windows PowerShell: 한 번에 한 줄씩 스크립팅
Windows PowerShell
한 번에 한 줄씩 스크립팅
Don Jones

필자는 지난 칼럼들을 통해 Windows PowerShell이 셸이라는 점을 강조해 왔습니다. Windows PowerShell은 이미 잘 알고 있는 cmd.exe(또는 명령 프롬프트) 셸과는 달리 대화식으로 사용되며, 여전히 cmd.exe의 배치 언어보다 훨씬 강력한 스크립트 언어를 지원합니다. 심지어
VBScript 같은 언어에 견줄 수 있을 만큼 강력합니다. 그러나 Windows PowerShell™은 대화식 셸이므로 스크립트를 훨씬 쉽게 배울 수 있습니다. 실제로 셸 내에서 스크립트를 대화식으로 개발할 수 있으므로 한 번에 한 줄씩 스크립트를 작성하여 그 결과를 즉시 확인할 수 있습니다.
이와 같은 반복적인 스크립팅 기술에 의해 디버깅도 보다 쉬워집니다. 스크립트 결과를 즉시 확인할 수 있으므로 예상과 다른 결과가 나타날 경우 스크립트를 신속하게 수정할 수 있습니다.
이 칼럼에서는 Windows PowerShell의 대화식 스크립팅 예를 살펴보고, 텍스트 파일에서 서비스 이름을 읽고 각 서비스의 시작 모드를 사용 안 함으로 설정하는 스크립트를 만들어 보겠습니다.
이를 통해 Windows PowerShell의 전체 스크립트를 하나의 커다란 조각으로 다루기 보다는 작은 조각들로 구성하는 개념에 익숙해질 수 있습니다. 수행해야 하는 관리 작업을 하나 선택하여 이를 구성 요소 조각으로 세분화한 다음 각 조각이 독립적으로 작동하도록 구성하는 방법을 확인할 수 있습니다. 앞으로 설명하겠지만 Windows PowerShell은 이러한 조각들을 결합하는 뛰어난 방법을 제공합니다. 작은 조각들을 한 번에 하나씩 구성하면 최종 스크립트를 보다 쉽게 개발할 수 있다는 사실을 발견하게 될 것입니다.

파일에서 이름 읽기
Windows PowerShell에서 텍스트 파일을 읽는 방법을 이해하는 것은 쉽지 않은 일입니다. Help *file*을 실행하면 파일에서 텍스트를 읽는 대신 텍스트를 파일로 보내는 Out-File cmdlet에 대한 도움말이 표시됩니다. 이는 전혀 도움이 되지 않습니다! 그러나 Windows PowerShell cmdlet 이름은 일종의 논리를 따르므로 이를 활용할 수 있습니다. Windows PowerShell이 어떤 항목을 검색할 때 cmdlet 이름은 보통 Get으로 시작됩니다. 따라서 Help Get*을 실행하여 해당 cmdlet을 표시한 다음 목록을 스크롤하여 Get-Content를 확인해 보니, 괜찮아 보입니다! 그래서 Help Get-Content를 실행하여 수행 작업에 대한 자세한 내용(그림 1 참조)을 확인해 보니 원하던 결과와 거의 비슷합니다.
그림 1 Help Get-Content를 실행하여 자세한 정보 확인
그림 1 Help Get-Content를 실행하여 자세한 정보 확인 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Help Get-Content를 실행하여 자세한 정보 확인
그림 1 Help Get-Content를 실행하여 자세한 정보 확인 (더 크게 보려면 이미지를 클릭하십시오.)
Windows PowerShell은 거의 모든 항목을 개체로 취급하는데 텍스트 파일도 예외는 아닙니다. 텍스트 파일은 원칙적으로 볼 때 줄의 집합이며 파일의 각 줄은 일종의 독립적인 개체 역할을 합니다. 따라서 C:\services.txt라는 텍스트 파일을 만들어 서비스 이름으로 채우면(각 이름은 파일 내의 고유한 줄에 위치함) Windows PowerShell에서 Get-Content cmdlet을 사용하여 이름을 개별적으로 읽을 수 있습니다. 이 연습은 스크립트를 대화식으로 개발하는 방법을 보여 주기 위한 것이므로 Get-Content를 실행하고 텍스트 파일에 이름을 지정한 다음 그 결과를 살펴보는 것부터 시작하겠습니다.
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
예상대로 Windows PowerShell은 파일을 읽고 이름을 표시합니다. 물론 단순히 이름을 표시하는 것이 목적은 아니지만 Get-Content가 예상대로 작동한다는 것을 알 수 있습니다.

서비스 변경
이제부터는 서비스의 시작 모드를 변경해 보겠습니다. 올바른 cmdlet을 찾아 보는 것부터 시작하겠습니다. Help *Service*를 실행합니다. 그러면 간단한 목록이 표시되는데 이 중에서 Set-Service cmdlet이 현재 필요에 적합한 것 같습니다. 이 cmdlet을 스크립트에 통합하기 전에 작동 방식을 이해하고 있는지 확인하기 위해 이 cmdlet을 테스트하려고 합니다. Help Set-Service를 실행하면 cmdlet의 작동 방식이 표시되며 간단한 테스트를 통해 이를 확인할 수 있습니다.
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

여러 부분의 결합
이제 Set-Service cmdlet을 사용하여 파일에서 서비스 이름을 읽는 기능을 결합해야 합니다. 그러면 Windows PowerShell의 강력한 파이프라인 기능이 작동하기 시작합니다. 파이프라인을 사용하면 첫 번째 cmdlet의 출력이 두 번째 cmdlet의 입력으로 전달됩니다. 파이프라인은 전체 개체를 전달합니다. 개체 컬렉션이 파이프라인에 삽입될 경우 각 개체는 파이프라인을 통해 개별적으로 전달됩니다. 즉, 개체 컬렉션인 Get-Content의 출력이 파이프라인을 통해 Set-Service에 전달될 수 있습니다. Get-Content는 컬렉션을 전달하므로 컬렉션의 각 개체 또는 텍스트 줄은 파이프라인을 통해 개별적으로 Set-Service에 전달됩니다. 그 결과 Set-Service가 텍스트 파일의 각 줄마다 한 번씩 실행됩니다. 명령은 다음과 같습니다.
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
결과:
  1. Get-Content cmdlet이 전체 파일을 읽으면서 실행됩니다. 파일의 각 줄은 고유한 개체로 취급되며 이들이 모여 개체 컬렉션이 됩니다.
  2. 개체 컬렉션이 파이프라인을 통해 Set-Service로 전달됩니다.
  3. 파이프라인이 각 입력 개체마다 한 번씩 Set-Service cmdlet을 실행합니다. 한 번 실행될 때마다 입력 개체가 cmdlet의 첫 번째 매개 변수(서비스 이름)로 Set-Service에 전달됩니다.
  4. 첫 번째 매개 변수에 대한 입력 개체를 사용하여 Set-Service가 실행되며 다른 매개 변수(이 경우 -startuptype 매개 변수)가 지정됩니다.
흥미로운 점은 이 시점에서 작업을 실제로 완료했지만 아직 스크립트를 하나도 작성하지 않았다는 사실입니다. Cmd.exe 셸에서는 이와 똑같은 작업을 수행하기가 쉽지 않으며 VBScript에서는 수십 줄의 코드가 필요합니다. 그러나 Windows PowerShell에서는 단 한 줄만으로 이 모든 작업을 처리할 수 있습니다. 아직 끝나지 않았습니다. 보다시피 필자가 작성한 명령은 많은 양의 상태 출력이나 피드백을 제공하지 않습니다. 오류가 없는 것은 차치하더라도 실제로 발생한 작업을 확인하기가 쉽지 않습니다. 지금까지 작업을 완료하는 데 필요한 기능을 익혔으므로 이제 실제 스크립팅을 통해 모양을 다듬을 차례입니다.
Windows PowerShell Prompt Here(Michael Murgolo)
가장 인기 있으면서 필자가 가장 선호하는 Microsoft® PowerToys for Windows® 중 하나는 Open Command Window Here(여기서 명령 창 열기) 도구입니다. Windows Server® 2003 Resource Kit 도구의 Microsoft PowerToys for Windows XP 중 하나로 제공되는 Open Command Window Here(여기서 명령 창 열기)를 사용하면 Windows 탐색기에서 폴더나 드라이브를 마우스 오른쪽 단추로 클릭하고 선택한 폴더를 가리키는 명령 창을 열 수 있습니다.
Windows PowerShell에 대해 배울 때 Windows PowerShell에도 같은 기능이 있으면 좋겠다고 생각했었습니다. 그래서 Open Command Window Here(여기서 명령 창 열기) 설치 프로그램의 .inf 파일인 cmdhere.inf를 Windows Server 2003 Resource Kit 도구에서 선택한 후 이를 수정하여 Windows PowerShell Prompt Here 컨텍스트 메뉴를 만들었습니다. 이 .inf 파일은 이 추가 기사의 바탕이 되는 블로그 원본(leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx)에 포함되어 있습니다. 이 도구를 설치하려면 .inf 파일을 마우스 오른쪽 단추로 클릭하고 설치를 선택하십시오.
이 도구의 Windows PowerShell 버전을 만들 때 원본에 버그가 있음을 발견했는데, 그 버그는 Open Command Window Here(여기서 명령 창 열기)를 제거해도 비활성화된 컨텍스트 메뉴 항목이 그대로 남아 있는 것입니다. 그래서 cmdhere.inf의 업데이트된 버전을 제공했습니다. 이 버전도 원본 블로그에서 제공하고 있습니다.
이러한 두 PowerToys는 이 컨텍스트 메뉴 항목이 디렉터리 및 드라이브 개체 유형과 연결된 키의 레지스트리에 구성되어 있다는 사실을 이용합니다. 이는 컨텍스트 메뉴 작업이 파일 형식과 연결되는 방식과 동일한 방식으로 이루어집니다. 예를 들어 Windows 탐색기에서 .txt 파일을 마우스 오른쪽 단추로 클릭하면 목록 맨 위에 몇 개의 작업(예: 열기, 인쇄, 편집)이 표시됩니다. HKEY_CLASSES_ROOT 레지스트리 하이브를 살펴보면 이러한 항목이 어떻게 구성되어 있는지 알 수 있습니다.
레지스트리 편집기를 열고 HKEY_CLASSES_ROOT 분기를 확장하면 .doc, .txt 등과 같은 파일 형식에 대해 이름이 지정된 키가 보입니다. .txt 키를 클릭하면 (Default) 값이 txtfile임을 확인할 수 있습니다(그림 A 참조). 이는 .txt 파일과 연결된 개체 유형입니다. 아래로 스크롤하여 txtfile 키를 확장한 다음 그 아래에 있는 셸 키를 확장하면 .txt 파일의 몇 가지 컨텍스트 메뉴 항목에 대해 이름이 지정된 키가 보입니다. 모든 컨텍스트 메뉴 항목이 보이지 않는 것은 컨텍스트 메뉴를 만드는 다른 방법이 있기 때문입니다. 이러한 각각의 키 아래에는 명령 키가 있습니다. 명령 키 아래에 있는 (Default) 값은 해당 컨텍스트 메뉴 항목을 선택하면 Windows에서 실행되는 명령줄입니다.
명령 프롬프트와 Windows PowerShell 프롬프트용 도구는 이 기술을 사용하여 Open Command Window Here(여기서 명령 창 열기) 및 Windows PowerShell Prompt Here 컨텍스트 메뉴 항목을 구성합니다. 드라이브 및 디렉터리와 연결된 파일 형식은 없지만 이 개체와 연결된 드라이브 및 디렉터리 키가 HKEY_CLASSES_ROOT 아래에 있습니다.
그림 A 레지스트리에 구성된 컨텍스트 메뉴 항목
그림 A 레지스트리에 구성된 컨텍스트 메뉴 항목 (더 작게 보려면 이미지를 클릭하십시오.)
그림 A 레지스트리에 구성된 컨텍스트 메뉴 항목
그림 A 레지스트리에 구성된 컨텍스트 메뉴 항목 (더 크게 보려면 이미지를 클릭하십시오.)

Michael Murgolo는 Microsoft Consulting Services의 수석 인프라 컨설턴트로서, 운영 체제, 배포, 네트워크 서비스, Active Directory, 시스템 관리, 자동화 및 패치 관리 분야를 담당하고 있습니다.

대화식 스크립팅
여기서 설명할 한 가지 작업은 C:\services.txt에 나열된 각 서비스에 대해 여러 개의 cmdlet을 실행하는 것입니다. 그러면 서비스 이름과 원하는 정보를 출력할 수 있으므로 스크립트의 진행 상황을 추적할 수 있습니다.
앞에서는 파이프라인을 사용하여 개체를 한 cmdlet에서 다른 cmdlet으로 전달했습니다. 그러나 이번에는 스크립트와 보다 유사한 기법인 Foreach 구문(지난 달 칼럼에서 소개함)을 사용하려고 합니다. Foreach 구문에서는 개체 컬렉션을 사용할 수 있으며 컬렉션의 각 개체에 대해 여러 개의 cmdlet을 실행합니다. 여기서는 루프를 순환할 때마다 현재 개체를 나타내는 변수를 지정하겠습니다. 예를 들면 다음과 같은 구문으로 시작할 수 있습니다.
foreach ($service in get-content c:\services.txt)
여전히 동일한 Get-Content cmdlet을 사용하여 텍스트 파일의 내용을 검색하지만 이번에는 Get-Content에 의해 반환된 개체 컬렉션 전체에 대해 Foreach 구문을 사용하여 루프를 실행할 것입니다. 루프는 각 개체에 대해 한 번씩 실행되는데 현재 개체는 $service 변수에 위치합니다. 이제 루프 내에서 실행할 코드를 지정하기만 하면 됩니다. 먼저 앞에서 만든 한 줄의 명령을 복제하겠습니다. 이렇게 하는 것이 가장 간단할 뿐 아니라 기능 손실도 전혀 발생하지 않습니다.
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
여기에는 몇 가지 흥미로운 점이 있습니다. 위의 Foreach 구문을 보면 첫 줄이 여는 중괄호로 끝났습니다. 여는 중괄호와 닫는 중괄호 사이에 있는 모든 구문은 Foreach 루프에 속한 것으로 간주되어 입력 컬렉션의 각 개체에 대해 한 번씩 실행됩니다. {를 입력하고 Enter 키를 누르면 Windows PowerShell의 프롬프트가 >>로 변경됩니다(그림 2 참조). 이 프롬프트는 시스템이 어떤 종류의 구문이 시작되었음을 인식하고 이 구문이 종료되기를 기다린다는 것을 나타냅니다. 여기에 Set-Service cmdlet을 입력했습니다. $service는 텍스트 파일에서 읽은 현재 서비스 이름을 나타내므로 이번에는 $service를 첫 번째 매개 변수로 사용했습니다. 다음 줄에서 닫는 중괄호를 사용하여 구문을 종결했습니다. Enter 키를 두 번 누르면 Windows PowerShell에서 코드를 즉시 실행합니다.
그림 2 구문이 시작되었음을 인식하는 Windows Powershell
그림 2 구문이 시작되었음을 인식하는 Windows Powershell (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 구문이 시작되었음을 인식하는 Windows Powershell
그림 2 구문이 시작되었음을 인식하는 Windows Powershell (더 크게 보려면 이미지를 클릭하십시오.)
이처럼 Windows PowerShell에서는 입력 내용을 실제로 즉시 실행하므로 입력된 내용이 스크립트처럼 보이더라도 텍스트 파일로 저장되지 않습니다. 이제 현재 서비스 이름을 출력하는 한 줄의 코드를 추가하여 전체 내용을 다시 입력하겠습니다.
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
위 코드를 보면 어떤 항목을 표시하도록 요청하고 이를 큰 따옴표로 묶은 것을 알 수 있습니다. Windows PowerShell에서는 따옴표 안의 내용을 명령이 아닌 텍스트 문자열로 인식합니다. 그러나 작은 따옴표와 달리 큰 따옴표를 사용하면 Windows PowerShell은 텍스트 문자열에서 변수를 검색합니다. 검색에 의해 변수를 찾으면 변수 이름을 변수의 실제 값으로 바꿉니다. 따라서 이 코드를 실행하면 현재 서비스 이름이 표시되는 것을 확인할 수 있습니다.
그러나 아직도 스크립트라고 할 수 없습니다.
지금까지, 작성한 코드의 결과를 즉시 확인할 수 있는 뛰어난 방법인 Windows PowerShell을 대화식으로 사용해 보았습니다. 그러나 때로는 이러한 코드 줄을 다시 입력하는 것이 번거로울 수 있습니다. 이러한 이유로 Windows PowerShell에서도 스크립트를 실행하는 것입니다. 실제로 Windows PowerShell 스크립트는 워드 스크립트의 정의를 가장 충실히 따릅니다 기본적으로 Windows PowerShell은 스크립트 텍스트 파일을 그대로 읽어서 사용자가 직접 행을 입력하는 것과 똑같이 각 행을 "입력"합니다. 즉, 지금까지 작성한 모든 코드를 스크립트 파일에 붙여 넣을 수 있습니다. 따라서 메모장에서 disableservices.ps1이라는 파일을 만들고 다음 내용을 붙여 넣겠습니다.
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
이 파일은 C:\test 폴더에 저장했습니다. 이제 PowerShell에서 이 파일을 실행해 보겠습니다.
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
이런, 무엇이 잘못된 것일까요? Windows PowerShell이 C:\test 폴더를 검색했지만 작성된 스크립트를 찾지 못합니다. 왜일까요? 보안 제약 조건에 의해 Windows PowerShell은 현재 폴더에서는 스크립트를 실행하지 못하도록 설계되어 있는데, 이는 스크립트가 운영 체제 명령을 가로채지 못하도록 하기 위해서입니다. 예를 들면 dir.ps1이라는 스크립트를 만들어 일반 dir 명령을 다시 정의하도록 할 수 없습니다. 따라서 현재 폴더에서 스크립트를 실행하려면 상대 경로를 지정해야 합니다.
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
하지만 이번에도 여전히 스크립트는 작동하지 않습니다. 경로를 올바르게 지정했지만 Windows PowerShell에서 스크립트를 실행할 수 없습니다. 왜냐하면 기본적으로 Windows PowerShell에서는 스크립트를 실행할 수 없기 때문입니다. 이는 VBScript에서 겪었던 문제를 방지하기 위해 설계된 보안 예방 조치입니다. Windows PowerShell에서는 기본적으로 스크립트를 실행할 수 없기 때문에 악의적인 스크립트가 실행될 수 없습니다. 스크립트를 실행하기 위해서는 실행 정책을 명시적으로 변경해야 합니다.
PS C:\test> set-executionpolicy remotesigned
RemoteSigned 실행 정책은 로컬 컴퓨터에서 서명되지 않은 스크립트의 실행은 허용하지만, 다운로드한 스크립트의 경우에는 여전히 서명이 있어야만 실행됩니다. 이보다 보안이 강화된 정책인 AllSigned 정책에서는 신뢰할 수 있는 게시자가 발급한 인증서를 사용하여 디지털 서명된 스크립트만 실행할 수 있습니다. 그러나 현재는 즉시 사용할 수 있는 인증서가 없어 스크립트에 서명할 수 없으므로 RemoteSigned를 사용하는 것이 적절해 보입니다. 이제 스크립트를 다시 실행해 보겠습니다.
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
사용된 RemoteSigned 실행 정책은 최상의 선택이 아니라 단지 이 상황에 적절한 선택이었다는 점을 지적하고 싶습니다. 훨씬 뛰어난 솔루션이 있습니다. 코드 서명 인증서를 사용하는 것이 훨씬 더 안전하지만, Windows PowerShell Set-AuthenticodeSignature cmdlet을 사용하여 현재 작성된 스크립트에 서명하고 실행 정책을 한층 더 안전한 AllSigned 정책으로 설정하십시오.
절대 사용해서는 안 되는 Unrestricted라는 또 다른 정책도 있습니다. 이 정책은 컴퓨터에서 모든 스크립트 즉, 원격 위치에 있는 악의적인 스크립트라도 아무 제한 없이 실행되도록 허용하므로 매우 위험할 수 있습니다. 따라서 이유 여하를 막론하고 Unrestricted 정책은 사용하지 않는 것이 좋습니다.

즉각적인 결과
Windows PowerShell의 대화식 스크립팅 기능을 사용하면 스크립트 또는 심지어 스크립트의 여러 작은 조각까지도 아주 빨리 프로토타입으로 만들 수 있습니다. 또한 즉각적인 결과를 얻을 수 있으므로, 스크립트를 간편하게 수정하여 원하는 정확한 결과를 얻을 수 있습니다. 작성이 끝난 스크립트는 ps1 파일로 옮겨 영구적으로 보관해 두었다가 나중에 손쉽게 사용할 수 있습니다. 단, 이러한 .ps1 파일에는 반드시 디지털 서명을 하여 Windows PowerShell의 스크립트 실행 정책 중 가장 안전한 정책인 AllSigned 실행 정책이 유지되도록 하는 것이 좋습니다.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 Windows PowerShell: TFM(www.SAPIENPress.com 참조)의 공동 저자입니다. 문의 사항이 있을 경우 don@sapien.com으로 연락하시면 됩니다.


 Hey, Scripting Guy!: 자동차 뒤쫓기... 그리고 XML
Hey, Scripting Guy!
자동차 뒤쫓기... 그리고 XML
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_02.exe (150KB)

오래된 농담 중에 "우리 집 개가 왜 자동차를 뒤쫓는지 모르겠어. 따라잡아서 뭘 하려고 계속 쫓는 걸까?"라는 말이 있습니다.
좋은 질문이지만 Scripting Guys는 이 질문에 대해서는 답할 수 없습니다. 뭐, 우리가 알고 있는 루시라는 개가 자동차를 따라잡는다면 모를까... 아마도 술집을 턴 후에 도망가는 데 사용하지 않을까요? 그리고 우리 앞마당의 상태를 봤을 때 다른 곳에 들렀다 올 시간은 없을 것 같습니다.
이 오래된 농담을 오늘날의 최첨단 기술 시대에 맞게 각색한다면 "시스템 관리자가 왜 계속 XML을 배우려고 애쓰는지 모르겠어. 배워서 뭘 하려고 그러는 걸까?" 정도로 바꿀 수 있을 것 같습니다.
식상한 농담을 각색한다고 했지 재미있을 것이라는 말은 하지 않았다는 점은 분명히 밝혀 두고 싶습니다.
사실 XML은 적어도 시스템 관리와 관련해서는 다소 과장된 측면이 있는 기술이라 할 수 있습니다. 실제로 XML 파일과 상호 작용하는 스크립트를 한 번도 작성해 본 적이 없는 시스템 관리자도 여전히 많이 있으며 당분간 이러한 상황은 바뀌지 않으리라 생각합니다.
반면 XML을 표준 데이터 저장소로 채택하는 응용 프로그램이 점점 더 많아지고 있는 것도 사실입니다. 그렇게 하지 않을 이유가 없으니까요. 잔뜩 꾸민 텍스트 파일에 지나지 않는 XML 데이터 파일은 빠르고 손쉽게 만들 수 있고 플랫폼 간에 이동이 용이하고 비용이 적게 드는 것은 물론이거니와 복잡한 데이터베이스 프로그램이 필요하지도 않습니다. 따라서 운영 체제와 텍스트 편집기만 있으면 누구나 XML 데이터베이스를 만들 수 있습니다.
물론 시스템 관리자의 경우에도 XML을 사용하여 수행할 수 있는 작업이 한 가지는 있습니다. 즉, XML 파일을 완전한 데이터베이스처럼 쿼리하는 스크립트를 작성할 수 있습니다. 이 작업에 대한 내용을 Scripting Guys보다 더 잘 설명할 사람들이 있을까요?
루시라고요? 뭐, 그럴 수도 있겠습니다만 루시는 다른 집 화단을 뒤지느라 너무 바빠 XML에 대해 칼럼을 쓸 시간은 없을 것 같습니다.
먼저 매일 연재되는 Hey, Scripting Guy! 칼럼(영문)에 사용된 네 가지 스크립트 관련 데이터베이스 파일인 XML 파일(그림 1 참조)을 살펴보겠습니다.
Figure 1 Hey, Scripting Guy! XML 스크립트 (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
보시다시피 매우 간단하고 작은 파일입니다. 각각의 개별 스크립트는 <Script> 태그 아래에 있습니다. 지금부터 이러한 스크립트를 레코드라고 하겠습니다. 맞습니다. XML 전문가들은 절대로 이러한 항목을 레코드라고 부르지 않습니다. 그렇지만 여기에서는 이미 알고 있는 지식(데이터베이스 쿼리 기법)을 활용하여 새로운 데이터 원본에 적용하는 방법을 배우는 것이 목표이므로 이렇게 부르도록 하겠습니다. 작업을 수행하는 방법을 먼저 설명하고 나중에 다시 이 주제에 대해 설명하고 올바른 용어를 알려 드리겠습니다.
자, 그럼 이제 다시 레코드로 돌아와서, 각 레코드에는 <Category>, <Subcategory>, <Keyword>, <Title> 및 <URL> 필드가 있습니다.
흠, 예상보다 독자들의 반응이 신통치 않은 것 같군요. XML 파일을 열고 내용을 출력하는 다음 스크립트가 이해하는 데 도움이 되리라 생각합니다.
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
여기서 태그 이름은 대/소문자를 구분한다는 점을 유의해야 합니다. 즉, "/Repository/Script"와 "/repository/script" 또는 "/REPOSITORY/SCRIPT"는 다릅니다.
아직도 그다지 감명을 받은 듯한 반응은 아니군요. 어쨌든 중요한 점은 생각보다 어렵지 않다는 것입니다.
위의 코드에서 알 수 있듯이 XML 파일 작업에 사용되는 COM 개체인 Microsoft.XMLDOM 개체의 인스턴스를 맨 먼저 만들었습니다. 그리고 Async 속성을 False로 설정하여 제어 권한이 스크립트로 반환되기 전에 전체 파일이 메모리로 읽히도록 했습니다. 그런 다음 Load 메서드를 사용하여 C:\Scripts\Scripts.xml 파일을 읽습니다.
xmlDoc.Load("C:\Scripts\Scripts.xml")
파일이 메모리에 로드되면 selectNodes 메서드를 사용하여 데이터베이스에서 지정된 레코드를 선택할 수 있습니다.
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
selectNodes에 전달된 매개 변수를 주의 깊게 살펴보면 XML 파일 내의 경로를 나타낸다는 것을 알 수 있습니다. 예제의 XML 파일의 구조는 다음과 같습니다.
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
이러한 구조가 중요할까요? 결론부터 말하자면, 그렇습니다! XML 파일을 처리할 때는 구조가 매우 중요합니다. 예를 들어 레코드의 개별 속성을 가져오려면 어떻게 해야 할까요? 간단합니다. 개별 속성 태그와 <Script> 태그 앞에 있는 <Repository> 태그에 액세스하면 됩니다. 바로 이것이 selectNodes에 대한 매개 변수로 지정한 경로와 동일합니다. 간단히 해당 경로에 /*를 사용하여 "이 레코드의 모든 속성을 선택"하도록 지시한 것입니다. 다시 말해 반환되는 컬렉션은 데이터베이스의 모든 레코드에 대한 모든 속성으로 구성됩니다. 이는 WMI(Windows® Management Instrumentation)에서 "Select * From" 쿼리를 실행한 결과와 비슷합니다.
이 간단한 스크립트를 실행해 보면 정확한 의미를 이해할 수 있을 것입니다.
스크립트의 나머지 부분은 이해하기 쉽습니다. For Each 루프를 설정하여 컬렉션 전체에 대해 실행하고 각 항목과 속성에 대해 Text 속성 값을 출력합니다.
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
자동차를 뒤쫓는 것보다 훨씬 쉽지 않습니까?
하지만 파일의 전체 내용을 출력하는 것이 전부였다면 XML과 관련된 스크립트를 모두 생략하고 FileSystemObject만 사용했을지도 모릅니다. 물론 이 경우 아주 약간만 더 복잡해질 뿐입니다. 어쨌든 독자로 하여금 "와! XML 기능이 상당히 유용하다"라고 생각하도록 만들려면 아직 갈 길이 멉니다.
다시 본론으로 돌아와 독자를 놀라게 만들 수 있을지 한번 보겠습니다. 첫 번째 스크립트에서 모든 레코드의 모든 속성 값을 출력했습니다. 이 경우에도 문제는 없지만 스크립트 제목만 출력하면 되는 경우에는 어떻게 해야 할까요? 가능하기는 할까요? 자, 한번 알아봅시다.
아! 루시가 말하기를 selectNodes 명령을 수정하여 경로 끝에 원하는 속성을 추가하기만 하면 된다는군요. 즉, 다음과 같습니다.
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
결국 처음에 모든 속성이 출력되었던 이유는 * 와일드카드 문자를 사용했기 때문임을 알 수 있습니다. 이제 Title 속성만 출력되는 이유는 무엇일까요? 바로 해당 속성 값만 출력하도록 요청했기 때문입니다.
흠, 보십시오. XML은 우리가 요청한 항목만 반환했습니다. 루시에게는 미안하지만 이제 인간의 가장 좋은 친구는 XML이 될 것 같군요.
물론 속성을 두 개 이상 반환할 수도 있습니다. 예를 들어 다음과 같이 수정한 명령을 사용하면 Title 속성과 URL 속성의 값이 모두 반환됩니다.
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
구문이 다소 이상해 보이긴 하지만 익숙해진다면 불편하지 않을 것입니다. 먼저 앞에서 한 것처럼 경로의 부모 부분을 지정합니다.
    /Repository/Script/
그리고 괄호를 추가하고 괄호 안에 반환할 속성을 지정합니다. 이때 수직선 구분 기호(| 문자)를 사용하여 개별 속성을 구분합니다. 즉, 다음과 같습니다.
    (Title | URL)
이미 설명했듯이 스크립트가 다소 어색해 보이지만 결과는 정확합니다.
반환할 수 있는 속성 수가 두 개로 제한되지는 않습니다. 수직선 구분 기호만 계속 추가한다면 원하는 모든 정보를 반환할 수 있습니다. 예를 들어 다음 명령은 세 가지 속성(Title, URL 및 Keyword)을 반환합니다.
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
멋지지 않습니까?
뭐, 적어도 우리는 멋지다고 생각했습니다. 독자들의 수준이 너무 높은가 보군요. 그래도 좋습니다. 지금까지는 데이터베이스의 모든 레코드에 대한 정보를 검색한 것에 불과하다는 점은 인정합니다. 그러나 이것이 쓸데없는 일은 아닙니다. 정확히 이러한 결과가 필요한 경우도 많으니까요. 반면 이러한 레코드 중 일부에 대한 정보만 검색해야 하는 경우도 많습니다. 예를 들어 Keyword 특성이 databases인 스크립트에 대한 정보만 출력해야 할 수도 있습니다. 아시다시피 다음과 같은 쿼리를 사용하는 경우입니다.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
이번에도 구문이 다소 이상합니다. 그러나 동시에 쉽고 간단하기도 합니다. 부모 경로를 지정한 후에 다음과 같이 대괄호 안에 "Where" 절(예: x = y)을 추가합니다.
/Repository/Script [Keyword = ‘databases’]
이미 알고 계실지도 모르지만 Where 절은 "Keyword 특성이 databases인 항목만 반환"하도록 지시하는 역할을 합니다. 이때 databases는 작은따옴표로 표시해야 합니다. 이러한 작은따옴표는 사용해도 아무 문제가 없을 뿐만 아니라 여러 가지 면에서 필요하기도 합니다. 필터 용어를 큰따옴표로 표시하면 스크립트를 실행할 때 구문 오류가 발생합니다.
이유가 무엇일까요? 바로 전체 쿼리 문자열("/Repository/Script [Keyword = ‘databases’]")이 큰따옴표로 묶여 있기 때문입니다.
물론 데이터를 필터링할 때 등호(=)는 마음대로 사용할 수 있습니다. 뿐만 아니라 보다 큼(>) 또는 보다 작음(<) 기호, 그리고 누구나 즐겨 사용하는 작거나 같음(<=) 또는 크거나 같음(>=) 기호도 사용할 수 있습니다. 또한 이러한 기호 앞에 느낌표를 추가하여 해당 기호를 부정할 수도 있습니다. 예를 들어 다음 명령은 Keyword가 databases가 아닌(!=) 모든 스크립트를 요청합니다.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
혹시 "물론 필터를 설정할 수는 있겠지만 필터를 설정하고 반환할 속성을 지정할 수는 없을걸?"이라고 생각하는 독자가 있을지 모르겠습니다. 당연히 이러한 작업도 가능합니다.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
이 명령이 정상적으로 실행되면 databases라는 Keyword가 있는 모든 스크립트의 Title 속성이 반환됩니다. 제대로 작동하는지 실행해 보겠습니다.
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
칼럼을 마치기 전에 마지막으로 명령을 하나만 더 살펴보겠습니다. 지금까지 몇 가지 내용을 설명했지만 반환되는 레코드의 범위를 더 좁혀야 할 수도 있습니다. 결과적으로 위에서 설명한 명령은 Microsoft® Access® 스크립트와 Microsoft SQL Server™ 스크립트를 반환합니다. 그 이유는 이러한 모든 스크립트에 databases라는 Keyword가 사용되기 때문입니다. 그렇다면 databases라는 Keyword가 있고 Subcategory가 Microsoft SQL Server인 스크립트로 반환되는 데이터를 제한하려면 어떻게 해야 할까요? 여러 가지 조건을 기준으로 필터링할 수도 있을까요?
다음과 같이 필터링하면 됩니다.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
기본 구문은 동일합니다. 여기에 Keyword = ‘databases’과 Subcategory = ‘Microsoft SQL Server’이라는 두 가지 조건을 사용하고 이 두 조건을 AND 연산자로 연결했습니다.
그렇습니다. 이와 같이 작고 간단한 XML 파일로 Subcategory가 Microsoft SQL Server인 모든 스크립트를 요청할 수 있습니다. 그리고 교육적인 내용이지만 재미있는 시간이 되셨으리라 믿습니다.
OR 절도 사용할 수 있습니다. 예를 들어 Subcategory가 Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook® 등에 해당하는 여러 Microsoft Office 스크립트가 있다면 Microsoft Word 또는 Microsoft Access 하위 범주의 스크립트만 반환되도록 제한할 수 있을까요? 물론입니다.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
이제 마음에 드십니까? 이 정도의 내용만으로 여러분의 인생을 바꿔 놓을 만한 칼럼이 되지는 않겠지만 언젠가는 이러한 XML 파일 쿼리 방법이 유용하게 사용될 가능성은 충분히 있습니다. 물론 이러한 기본적인 XML 기법을 익힐지 아니면 자동차를 뒤쫓을지를 결정하는 것은 여러분의 몫입니다. 후자를 선택하여 거리에서 루시를 만나게 된다면 Scripting Guys를 대신해 인사를 전해 주시기 바랍니다. 그리고 우리 앞마당에서 좀 나가 달라고 전해 주십시오.
Hey, Scripting Guy! - 일일 칼럼
이번 달 Hey, Scripting Guy! 칼럼을 읽고 지금까지 읽으신 기술 자료 중 단연 최고라고 생각하셨으리라 믿습니다. 나아가 지금까지 읽은 어떤 글보다도 훌륭하다고 생각하실지도 모르겠습니다. 너무 감명받은 나머지 이런 기사를 더 읽기 위해 다음 호 TechNet Magazine이 배달되기만을 손꼽아 기다리는 독자도 있으리라 생각합니다.
새로운 세상을 경험하고 싶으십니까? 이웃집 개 루시에 대해 자세히 알고 싶거나 Scripting Guy의 최신 칼럼을 읽고 싶으십니까? 매년 열리는 Turducken Bowl 행사가 작년에 어떻게 진행되었는지 알고 계십니까? 그렇다면 매일 게시되는 Hey, Scripting Guy! 칼럼을 읽어 보십시오. 주요 공휴일과 Scripting Guy의 휴가 기간을 제외하고 월요일에서 금요일까지 매일 고등학교 야구, 대학 축구나 농구 리그 소식뿐만 아니라 지방 날씨에 대한 소식까지 전해 들을 수 있습니다. 물론 레드먼드에 거주하는 분들에게는 "지역" 소식이겠지만 레드먼드에 대해 별로 알고 싶지 않은 독자에게는 무슨 필요가 있냐고요?
이것이 다가 아닙니다. 일상적인 스크립트 작성 업무에 대해서도 새롭고 유용한 내용이 많습니다. 맞습니다. 위에 나열한 흥미로운 내용 외에도 실질적인 스크립트 정보가 포함되어 있습니다. 각각의 칼럼에서 Scripting Guys는 실제 사용자가 가질 수 있는 궁금증에 대한 해답을 제공합니다. 이러한 일일 칼럼은 microsoft.com/technet/scriptcenter/resources/qanda(영문)에서 읽을 수 있습니다. 또한 이미 수백 개의 질문에 대해 칼럼이 연재되었기 때문에 상당히 방대한 양의 스크립팅 정보를 얻을 수 있습니다. 목록을 보려면 microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx(영문)를 참조하십시오.
Scripting Guys에 질문할 내용이 있으시면 scripter@microsoft.com으로 보내 주시기 바랍니다. 가능성이 적긴 하지만 혹시라도 칼럼을 통해 답변을 받을지도 모르니까요. 질문하지 않으면 아예 가능성이 없는 것이니 손해를 볼 것은 없지 않습니까? 게다가 복권과는 달리 돈이 들지도 않고 당첨 가능성도 좀 더 높습니다.

Microsoft Scripting Guys는 Microsoft의 업무를 담당하는, 정확히 말하면 Microsoft에 고용된 직원입니다. 이들은 야구 경기를 하거나, 감독하거나, 관람하는 등의 일상적인 다른 활동을 하지 않을 때 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 http://www.microsoft.com/korea/technet/scriptcenter/default.mspx에서 확인하십시오.


 Security Watch: EFS 배포: 1부
Security Watch
EFS 배포: 1부
John Morello

랩톱 도난이나 방치로 인해 개인 데이터나 중요한 데이터가 손실되었다는 보고를 들어 보지 않은 사람은 없을 것입니다. 랩톱 분실은 아주 흔한 일입니다. ID 도용이 증가하고 규정 준수가 그 어느 때보다도 중요해진 상황에서 모바일 컴퓨팅 시스템의 데이터를 철저하게 보호하는 것은 필수적입니다.
한 가지 해결 방법은 Windows 2000부터 Windows®에 포함되었으며 고성능의 디스크 기반 암호화를 기본적으로 제공하는 EFS(파일 시스템 암호화)를 사용하는 것입니다. EFS는 Windows 탐색기와 완벽하게 통합되므로 최종 사용자는 대개 사용 중인 파일이 언제 암호화되는지조차 알지 못합니다. 또한 기본 Windows 인증 및 액세스 제어 기술과도 동등하게 잘 연동되므로 사용자는 데이터 액세스를 위해 별도의 암호를 기억할 필요가 없습니다. 마지막으로 사용자가 자신의 암호화 키에 액세스할 수 없는 경우(예: 사용자 프로필이 삭제 또는 손상되었거나 스마트 카드가 분실된 경우) 데이터를 복구할 수 있도록 관리하기 쉬운 옵션을 제공합니다.
EFS는 Windows에서 기본적으로 제공하는 암호화 기술을 사용하여 강력한 암호화 키를 생성, 저장 및 배포함으로써 데이터를 보호합니다. Windows XP 서비스 팩 1(SP1) 이상 버전에서 EFS는 AES(고급 암호화 표준) 알고리즘을 256비트 키와 함께 사용하여 디스크의 데이터를 암호화합니다. 이러한 대칭 키는 비대칭(RSA) 키 쌍으로 보호됩니다. EFS는 AES 키를 사용하여 각 파일을 암호화한 다음 사용자의 RSA 키를 사용하여 이 키를 암호화하고 그 결과를 파일에 저장합니다. EFS 암호화에 대한 자세한 내용은 "EFS 리소스" 추가 기사를 참조하십시오. 지금은 EFS의 기술적인 토대에 초점을 맞추지 않고 EFS를 배포하고 현재 환경에서 작동되도록 하는 방법에 대해 중점적으로 다루겠습니다. 따라서 이 문서에서는 독자가 EFS 암호화 개념을 이미 이해하고 있다는 전제 하에 설명합니다.

EFS 보안 참고 사항
EFS 암호화를 해독하거나 손상시킬 수 있다고 주장하는 응용 프로그램이 있습니다. 이러한 응용 프로그램은 AES (또는 DES(데이터 암호화 표준)나 DESX(Expanded Data Encryption Standard))로 암호화된 암호 텍스트를 실제로 해독하는 것이 아니라 사용자 암호를 무작위로 추측하여 사용자의 EFS 개인 키에 대한 액세스 권한을 얻는 것입니다. EFS 암호화에 대해 유념해야 할 중요한 사항은 암호화된 데이터를 생성하고 보호하는 데 사용되는 개인 키는 DPAPI(데이터 보호 API)를 사용한다는 점입니다. DPAPI는 사용자 로그온 자격 증명에서 파생된 정보를 이용하여 데이터를 보호하므로 EFS를 사용한 데이터 보호 수준은 사용자 암호에 의해 결정됩니다. Windows Vista™에서는 이제 EFS 암호화 인증서를 스마트 카드에 저장할 수 있게 됨에 따라, 이 패러다임이 달라질 뿐 아니라 EFS로 보호된 데이터의 상대적 보안이 크게 강화됩니다.
암호가 공격에 견디려면 얼마나 길어야 할까요? 오늘날의 하드웨어 성능과 최신 암호 공격 알고리즘을 고려할 때 11자 이상의 암호(또는 보다 정확하게 암호 구문)를 사용하는 것이 좋습니다. 11자 이상의 암호 구문은 미리 계산된 해시 공격(예: 레인보우 테이블)을 비롯한 오늘날의 최첨단 공격 방식에 매우 잘 대응합니다. 레인보우 테이블에 대한 자세한 내용은 "리소스" 추가 기사에 나열된 "Why you shouldn't be using passwords of any kind on your Windows networks"(영문)가 게시된 블로그를 참조하십시오.

PKI 사용 여부 결정
EFS에 대한 가장 흔한 오해 중 하나는 EFS를 사용하려면 PKI(공개 키 인프라)가 작동해야 한다는 것입니다. EFS는 PKI와 쉽게 통합되고 PKI를 활용할 수 있으므로 조직에 이미 PKI가 있을 수는 있지만 PKI가 반드시 있어야 하는 것은 아닙니다. 하지만 EFS 배포에서 PKI를 사용할 것인지 여부에 따라 배포와 관련된 추후의 여러 사항들이 다르게 결정될 수 있으므로 PKI 사용 여부를 먼저 검토해야 합니다.
EFS와 함께 PKI를 사용할 경우의 기본적인 이점은 키 보관 및 복구를 수행할 수 있다는 점입니다. 데이터 복구의 경우 관리자가 EFS만 사용해도 수행할 수 있지만, 자동 키 복구는 PKI를 함께 사용할 경우에만 가능합니다. 그 경우라도 Windows Server® 2003 Enterprise Edition을 CA(인증 기관)으로 실행해야만 가능합니다. 데이터 복구는 자신의 암호화 키에 액세스할 수 없는 사용자가 자신의 암호화된 데이터를 DRA(데이터 복구 에이전트)라고 알려진 지정된 관리자에게 제공할 수 있는 프로세스로서, DRA는 이 데이터를 해독한 다음 해당 사용자에게 다시 보내거나 새 개인 키와 함께 사용할 수 있도록 다시 암호화합니다. DRA는 사용자의 암호화 프로세스에서 보이지 않게 작업을 수행하는데, 이로 인해 사용자가 자신의 키를 사용하여 암호화하는 모든 내용도 DRA 키 복사본을 사용하여 암호화됩니다. 따라서 사용자 키를 분실한 경우 DRA는 이 과정에 개입하여 암호 텍스트 데이터를 가져와서 DRA 키를 이 데이터에 적용하여 해독(또는 다시 암호화)한 다음 데이터를 사용자에게 돌려보낼 수 있습니다. DRA 접근 방법은 잘 작동하지만 사용자가 대용량의 데이터를 암호화했거나 DRA 역할을 수행할 로컬 IT 직원이 없을 경우에는 관리하기 어려울 수 있습니다.
반면 키 복구를 사용하려면 키 생성 프로세스 중 CA에서 사용자 암호화 키 복사본을 만들어 이 키 복사본을 CA의 데이터베이스에 안전하게 저장해야 합니다. 그러면 사용자가 암호화된 파일에 액세스할 수 없을 경우 CA 관리자가 이 데이터베이스에 액세스하여 사용자 키를 검색하기만 하면 됩니다. 이때 사용자는 DRA에 데이터 복구를 의뢰할 필요 없이 즉시 자신의 데이터에 다시 액세스할 수 있습니다. 이와 같은 방식으로 수행될 경우 키 복구가 보다 빠르고 효율적으로 수행될 수 있습니다. 그러나 키 복구를 사용하는 경우라도 DRA를 항상 지정하여 키 분실에 대비한 백업 메커니즘을 제공하는 것이 최선의 방법입니다. 그러면 대규모 조직에서도 PKI 관리자 그룹에 참여할 필요 없이 로컬 IT 관리자가 사용자 데이터를 복구할 수 있는 분산된 복구 시스템을 사용할 수 있습니다.
EFS와 함께 PKI를 사용할 경우 얻을 수 있는 또 다른 이점은 암호화된 파일을 보다 쉽게 공유할 수 있다는 점입니다. EFS는 랩톱 시스템에만 국한되어 사용되는 것이 아니라 컴퓨터의 물리적 보안을 보장할 수 있는 모든 상황에서도 마찬가지로 아주 유용하게 활용할 수 있습니다. 이러한 상황에서는 여러 명의 사용자가 암호화된 동일한 파일에 액세스해야 할 수 있습니다. Windows에서는 디렉터리가 아닌 개별 파일의 공유만 허용하기 때문에 암호화된 파일의 공유에 대한 지원이 다소 제한적이므로 PKI가 유용한 도구가 될 수 있습니다. EFS 파일을 쉽게 공유하기 위해서는 파일을 공유하는 사용자가 함께 공유하고 있는 다른 사용자들의 공개 키에 액세스할 수 있어야 하는데, 가장 쉬운 방법은 다른 사용자들이 올바른 EFS 인증서를 Active Directory®의 자신의 계정에 게시한 경우입니다. 수동으로 게시할 수도 있지만 엔터프라이즈(Active Directory에 통합) 모드로 설치된 Windows CA를 사용하여 이 프로세스를 완전히 자동으로 수행할 수 있습니다.

EFS 키 관리
Windows Server 2003 기반 PKI를 사용할 수 있는 경우 사용자의 EFS 인증서를 생성하는 과정은 간단합니다. Windows Server 2003 CA는 기본 EFS라는 인증서가 포함된 기본 인증서 템플릿 집합과 함께 제공됩니다. 그러나 이 템플릿은 버전 1 템플릿이므로 키 보관을 지원하지 않습니다. 따라서 CA에서 이 템플릿을 사용할 수 있도록 하기 전에 먼저 템플릿을 복제하여 새로운 버전 2 템플릿을 만들 수 있는데, 예를 들면 그림 1에 나타난 것처럼 "키 보관이 가능한 EFS"라고 이름을 붙일 수 있습니다. 이 새 템플릿에서 요청 처리 탭으로 이동하여 사용자의 암호화 키를 보관하는 옵션을 선택합니다. 이 옵션을 사용하기 위해서는 먼저 CA에 키 보관이 적절하게 구성되어 있어야 합니다. 리소스 섹션에 이 프로세스의 세부 단계가 나와 있습니다. 클라이언트에서 이 새로운 버전을 사용하게 하려면 이 템플릿이 기본 EFS 템플릿을 대체하도록 설정해야 합니다(그림 2 참조).
그림 1 키 보관이 가능한 EFS
그림 1 키 보관이 가능한 EFS (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 키 보관이 가능한 EFS
그림 1 키 보관이 가능한 EFS (더 크게 보려면 이미지를 클릭하십시오.)
그림 2 기본 EFS 템플릿 대체
그림 2 기본 EFS 템플릿 대체 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 기본 EFS 템플릿 대체
그림 2 기본 EFS 템플릿 대체 (더 크게 보려면 이미지를 클릭하십시오.)
이제 올바른 사용자 집합이 템플릿에 대한 액세스 권한을 등록할 수 있도록 템플릿에 대해 적절한 권한을 설정해야 합니다. Windows의 EFS 구성 요소는 EFS가 처음 사용될 때 자동으로 인증서를 요청하므로 일반적으로 사용자가 EFS 템플릿에 자동으로 등록하도록 허용할 필요가 없습니다. 자동 등록된 모든 사용자가 EFS를 사용할 것이 확실하지 않다면 EFS 인증서에 대한 자동 등록을 사용하지 않는 것이 좋습니다. 그림 3은 EFS 등록 설정을 보여 줍니다. EFS를 사용할 가능성이 없는 사용자에게 인증서를 발급하면 CA 데이터베이스의 크기만 커질 뿐 아무런 이점도 없습니다. CA 데이터베이스 자체에 대한 크기 제한은 없지만 발급된 인증서가 많아질수록 관리, 특히 MMC(Microsoft Management Console)를 통한 관리가 어려워질 수 있습니다.
그림 3 EFS 사용자 권한 설정
그림 3 EFS 사용자 권한 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 EFS 사용자 권한 설정
그림 3 EFS 사용자 권한 설정 (더 크게 보려면 이미지를 클릭하십시오.)
끝으로, 암호화된 파일의 공유를 지원해야 할 경우 CA에서 자동으로 사용자의 인증서를 Active Directory에 게시하도록 할 수 있습니다.
CA에 템플릿이 적절하게 구성되면 EFS를 사용하여 파일을 처음 암호화할 때 사용자는 CA에서 자신의 인증서를 가져오며 CA는 사용자의 개인 키를 자동으로 보관합니다.

DRA 키 관리
PKI가 적절히 설정된 경우 다음으로 고려해야 할 사항은 CA에서 생성한 DRA 인증서를 사용할지 여부입니다. PKI의 DRA 인증서를 사용하지 않으려는 이유는 무엇일까요? 인증서 유효 기간을 매우 짧게(2년 이하) 발급하는 CA가 있다고 가정해 보겠습니다. 이 CA는 이보다 유효 기간이 긴 인증서는 발급할 수 없으므로 DRA 인증서의 유효 기간은 길어야 2년입니다. 이로 인해 데이터 복구 시나리오가 상당히 복잡해질 수 있습니다. 이와 같은 가상 예제를 보여 주는 다음과 같은 시나리오를 생각해 볼 수 있습니다.
  1. 2006년 1월 한 사용자가 파일을 암호화했는데, 그룹 정책을 통해 자신의 컴퓨터로 보내진 DRA 인증서의 유효 기간은 2년입니다. 즉, 2008년 1월에 만료됩니다.
  2. 이 사용자는 그때까지 EFS를 사용하여 새 파일을 암호화합니다.
  3. 2008년 1월 DRA 인증서가 만료되어 관리자가 그룹 정책을 통해 새 인증서를 사용자에게 보냅니다.
  4. 따라서 이 이후로 수행된 모든 암호화 작업에는 새 DRA 인증서가 사용되지만(이전 DRA를 사용하여 암호화된 파일을 여는 경우 이 파일이 저장될 때는 새 DRA가 사용됨) 이 사용자가 손대지 않은 파일은 여전히 이전 DRA에 의해 보호됩니다.
  5. 그런데 실수로 사용자의 프로필이 손상되어 데이터 복구가 필요한 상황이 발생합니다.
  6. IT 관리자는 이제 두 개의 DRA 인증서 집합을 가지고 있어야 합니다. 하나는 3단계 이후에 사용된 파일을 위한 새 인증서이고, 다른 하나는 3단계 이후에는 사용되지 않은 파일에 대한 이전 인증서입니다.
IT 관리자가 3단계 이후에 스크립트를 실행하여 모든 파일을 새 DRA로 업데이트할 수는 있지만(cipher.exe /u 사용) 이를 수행하려면 시간이 많이 걸립니다. 또한 만료된 DRA 인증서가 복구 정책에 포함되어 있을 경우 EFS 구성 요소가 어떠한 새로운 암호화 작업도 허용하지 않는다 할지라도, 만료 날짜에 도달한 후에 DRA 키 쌍이 필요할 수 있습니다. 물론 만료된 DRA 키 쌍으로 암호화된 이전 파일은 여전히 이 키 쌍을 사용하여 복구할 수 있습니다. 따라서 유효 기간이 만료된 후라도 DRA 키 쌍이 필요한 경우가 있을 수 있으므로 DRA 키 쌍은 절대 제거해서는 안 됩니다.
이러한 이유로 CA의 인증서 유효 기간이 짧은 환경에서는 유효 기간이 이보다 긴 자체 서명 DRA 인증서를 사용하는 것이 좋습니다. 암호화 유틸리티에는 유효 기간이 100년인 EFS 복구 에이전트 키 쌍을 자동으로 만드는 스위치(cipher.exe /r)가 포함되어 있습니다(그림 4 참조). 이 키 쌍의 인증서는 GPO(그룹 정책 개체)에 연결되어 조직 전체에서 DRA로 사용될 수 있습니다. EFS 구성 요소는 DRA 인증서의 신뢰 체인을 검사하지 않으므로 이러한 자체 서명 인증서는 시스템에서 신뢰할 수 있는 루트 인증 기관 목록을 변경하지 않고도 작동합니다. 조직의 CA 유효 기간과는 무관하게, 이보다 유효 기간이 긴 DRA 인증서를 최소한 하나 만들어 이를 도메인 전체에 적용되는 GPO에 연결하는 것이 좋습니다. 이는 다른 모든 옵션을 사용할 수 없는 경우에 사용할 대체 데이터 복구 옵션으로, 보관된 CA 키가 없어 CA에서 생성한 DRA 키를 사용할 경우에 특히 필요한 옵션입니다. DRA 인증서는 손상되어서는 안 되므로 새 인증서로 GPO를 업데이트한 다음 앞에서 설명한 cipher.exe /u를 사용하여 파일을 업데이트할 수 있습니다.

그림 4 Ciquer /R 실행 (더 작게 보려면 이미지를 클릭하십시오.)

그림 4 Ciquer /R 실행 (더 크게 보려면 이미지를 클릭하십시오.)
EFS 리소스
EFS에 대한 세부 사항 및 유용한 방법에 대한 자세한 정보를 보려면 다음 사이트를 방문하십시오
  • Why you shouldn't be using passwords of any kind on your Windows networks(영문)
  • Implementing Key Archival Walkthrough(영문)
  • Encrypting File System in Windows XP and Windows Server 2003>(영문)

KRA 및 DRA 배포
키 보관을 통해 CA 관리자는 사용자를 대신해서 보관된 암호화 키를 복구할 수 있습니다. 이 경우 CA에서 서명한 키를 사용한 조직의 데이터를 CA 관리자가 해독할 수 있으므로 이는 매우 민감하면서도 강력한 기능입니다. 따라서 키 보관 및 복구는 매우 신중하게 처리해야 하며 소수의 신뢰할 수 있는 보안 직원에게만 이 권한을 부여해야 합니다. 키 복구는 매우 민감한 사안이므로 EFS 암호화 데이터에 다시 액세스하는 기본 메커니즘으로 키 복구를 사용할 때에는 복구 요청을 CA 관리 팀으로 보내기 위한 단계적 프로세스를 명확하게 정의하는 것이 중요합니다. 복구 요청을 신중하게 검토한 후에만 복구 프로세스를 시작해야 합니다. 복구된 키로는 모든 사용자의 EFS 보호 데이터에 액세스할 수 있으므로 키가 실제로 복구되면 안전한 방법으로(즉, 전자 메일을 통해 보내선 안 됨) 사용자에게 제공해야 합니다.
KRA(키 복구 에이전트) 키는 생성되면 CA 관리자에 의해 보관되므로 그룹 정책을 통해 알려지지 않습니다. 실제로 EFS 자체에서는 사용되는 키가 보관되었는지 여부를 확인할 수 없으므로 평상시대로 단순히 암호화 작업만 수행합니다. 또한 CA에서 생성된 KRA 키는 EFS에만 국한되지 않습니다. 키 보관을 사용하는 CA의 경우 CA 수준에서 n개의 KRA 키가 첨부되어 CA에 의해 보관된 키를 보호하는 데 사용됩니다. 이러한 키에는 EFS와 함께 사용된 키, 보안 전자 메일에 사용된 키 또는 암호화가 포함된 기타 인증서 용도로 사용된 키 등이 있습니다. KRA 키는 개별 키 복구 에이전트에 의해 안전하게 저장되어야 하며 키 하나를 분실하더라도 다른 키를 사용할 수 있도록 적어도 두 개의 KRA를 사용해야 합니다.
관리자가 새로 만들어진 도메인의 도메인 컨트롤러에 처음 로그인하면 DC의 관리자 프로필에 저장된 자체 서명 인증서와 키 쌍을 사용하여 도메인 수준에서 기본 복구 정책이 만들어집니다. 이 DRA 인증서의 유효 기간은 3년입니다. 이 기본 인증서를 제거하고 유효 기간이 이보다 긴 자체 서명 인증서나 PKI에서 발급한 인증서로 대체하는 것이 좋습니다. 이 기본 자체 서명 인증서를 제거하지 않을 경우 인증서를 만든 지 3년이 경과하면 EFS는 더 이상 도메인을 통해 새 파일을 암호화하지 않습니다. 이는 인증서가 만료되었으므로 만료된 DRA 인증서가 복구 정책에 포함되어 있을 경우 EFS에서 더 이상 데이터를 암호화하지 못하게 하기 때문입니다. Windows XP 이상의 시스템은 복구 에이전트 정책 없이도 작동할 수는 있지만 이 방법은 사용하지 않는 것이 좋습니다. 이 방법을 사용하면 사용자가 어떤 이유로든 자신의 암호화 키에 액세스할 수 없고 키 복구도 가능하지 않은 경우 모든 데이터가 영구적으로 손실될 수 있습니다.
이미 설명한 것처럼 DRA 키는 자체 서명된 키이거나 CA에서 발급한 키일 수 있습니다. 대부분의 경우 여러 키를 혼용하는 것이 가장 바람직한데 최소한 2개의 자체 서명된, 유효 기간이 긴 DRA를 기업 전체에서 최후의 복구 에이전트로 사용하는 것이 좋습니다. DRA 인증서는 그룹 정책 개체를 통해 배포되므로 다른 GPO와 동일한 상속 기능을 갖습니다. 즉, 다른 GPO 설정의 적용을 제어하는 표준 로컬, 사이트, 도메인, OU(조직 구성 단위) GPO 누적 및 적용 알고리즘도 DRA에 적용됩니다. 따라서 조직에서는 중앙 IT 그룹이 기업의 모든 부문에 대한 DRA 액세스 권한을 가지고 있지만 로컬 IT 그룹도 특정 담당 영역에 대해서는 기능을 유지 관리하는, DRA에 대한 계층형 접근 방식을 쉽게 구현할 수 있습니다. 이 접근 방식은 WAN 링크를 통해 대용량의 암호화된 데이터를 전송할 필요가 없어 데이터 복구를 수월하게 수행하므로 특히 지리적으로 분산된 대규모 조직에서 유용하게 사용할 수 있습니다. 그림 5는 여러 계층으로 구성된 일반적인 DRA 배포를 보여 줍니다.
그림 5 여러 계층으로 구성된 DRA 배포
그림 5 여러 계층으로 구성된 DRA 배포
이 경우 Baton Rouge OU의 사용자는 암호화된 파일마다 6개의 DRA를 갖습니다. 즉, 로컬 관리자로부터 두 개, North America IT 그룹에서 두 개, 도메인 수준에서 두 개를 받게 됩니다. 따라서 사용자가 자신의 암호화된 데이터에 액세스할 수 없을 경우 North America IT 그룹 또는 Baton Rouge의 로컬 DRA에 의해 데이터를 복구할 수 있습니다. 이러한 네 개의 DRA를 사용할 수 없거나 손실한 경우 최후의 대체 방법으로 도메인 수준 DRA를 사용하여 데이터를 복구할 수도 있습니다. 어떤 DRA가 복구를 수행했는지에 관계없이 복구 프로세스는 본질적으로 동일합니다. 먼저 사용자는 데이터를 DRA에 제공합니다. DRA는 요청이 합법적이고 실제 데이터 소유자로부터 보내진 것인지 확인하기 위해 필요한 단계를 수행해야 합니다. 이 단계를 완료한 후 DRA는 DRA 인증서를 로드하고 데이터를 해독(및 가능하면 다시 암호화)한 다음 데이터를 다시 최종 사용자에게 보냅니다. 경우에 따라 일부 조직에서는 DRA가 문제가 되는 사용자를 실제로 찾아 이 사용자의 DRA 키 쌍을 프로필로 로드한 다음 데이터를 해독하고 키 쌍을 제거하는 로컬 복구를 수행하기도 합니다. 이제 사용자는 일반 텍스트 형식의 데이터에 액세스할 수 있게 되고 새로운 키를 사용하여 데이터를 다시 암호화할 수 있습니다. 이 접근 방법은 DRA 키 쌍이 일시적이기는 하지만 로컬 컴퓨터에 복사되기 때문에 별로 안전하지 않다는 단점이 있지만, 특히 많은 양의 데이터를 복구해야 할 경우에는 시간을 다소 절약할 수 있습니다.
복구가 키 보관 및 복구를 통해 사용자에게 제공되어야 하는 경우 복구 요청은 이 프로세스와는 완전히 별도로 처리됩니다. DRA를 사용하는 대신 사용자의 키 복구 요청이 CA 관리자에게 전달되고 CA 관리자는 요청을 검사한 다음 사용자의 개인 키를 보관하고 검색해야 합니다. 그런 다음 이 개인 키를 다운로드할 수 있도록 보안 웹 사이트에 배치하는 등의 안전한 방식으로 사용자에게 제공합니다. 사용자가 스마트 카드를 사용하여 Windows Vista에서 사용할 수 있는 EFS 키를 저장하는 경우 키도 다시 발급해야 합니다. 사용자는 이 키를 자신의 프로필로 로드하여 암호화된 모든 데이터에 즉시 액세스할 수 있습니다.
DRA 및 KRA 키 쌍은 중요한 데이터를 해독하는 데 사용될 수 있으므로 적절히 보호하는 것이 중요합니다. 따라서 이들 키 쌍은 관리자의 일반 데스크톱 프로필(관리자가 일상적인 업무를 수행하는 데 사용하는 프로필)에 저장해서는 안 되며, 플로피 미디어, 광 미디어 또는 플래시 미디어에 오프라인으로 안전하게 저장하여 물리적으로 안전한 장소에 보관해야 합니다. 그러면 복구가 필요할 때 복구 에이전트에서 이러한 미디어에 있는 키 쌍을 복구 워크스테이션으로 로드하여 복구 작업을 수행한 다음 이들 키 쌍을 제거할 수 있습니다. 특별히 보안에 민감한 몇몇 조직에서는 이러한 키 쌍에 대한 보안을 강화하기 위해 복구 전용의 워크스테이션을 지정하기도 하는데, 모든 조직에서 이 방법을 사용할 필요는 없습니다.

다음 기사 소개
이번 기사에서는 EFS 계획의 키 관리, 데이터 복구 및 Active Directory 측면을 살펴봤으므로 다음 달에 발표될 이 기사의 2부에서는 클라이언트 쪽 배포 질문에 대해 중점적으로 다룰 것입니다. 또한 그룹 정책을 통한 EFS 사용 제어, 암호화할 항목 선택, 로그온 스크립트를 통한 데이터 자동 암호화, EFS 보호 데이터를 보다 쉽게 사용할 수 있도록 하는 Windows 탐색기의 클라이언트 쪽 개선 사항 등에 대해 설명할 것입니다.

John Morello는 LSU를 수석으로 졸업했으며 지난 6년 동안 Microsoft에서 다양한 업무를 담당했습니다. 시니어 컨설턴트로서 Fortune 100대 기업 및 연방 민간 및 방어 클라이언트용 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 프로그램 관리자로서 보안 및 원격 액세스 기술을 담당하고 있습니다.


 The Desktop Files: Windows PE 확장
The Desktop Files
Windows PE 확장
Wes Miller

적극적인 고객 중에는 5년 전 Windows PE를 릴리스하기 전부터 추가 기능을 요구하는 사람들이 있었습니다. 그러나 아쉽게도 Windows PE는 운영 체제 계층을 추가하는 방식으로 확장이 가능한 Windows XP Embedded처럼 확장이 용이하도록 설계되지 않았습니다. 물론 Windows PE도 기본적인 확장 기능은 제공합니다.
이러한 기본 기능에는 Windows® 응용 프로그램이 작동되도록 하는 Win32® 지원 기능, 네트워크를 통해 통신하고 Windows를 설치할 수 있는 네트워킹 및 대용량 저장소 지원 기능 등이 있습니다. 그러나 셸의 경우에는 처음부터 우리가 원하는 방식으로 구현하고자 했습니다. 때문에 기존의 Windows 탐색기 셸 대신 cmd.exe를 사용하여 Windows PE 환경에서 실행할 수 있는 작업을 제한했을 뿐만 아니라, 모든 자동 작업에 따라 기본 환경을 쉽게 스크립트로 작성할 수 있도록 셸을 만들었습니다.
하지만 Windows PE의 확장이 불가능한 것은 아니며 단지 그 범위가 제한될 뿐입니다. 예를 들면 그림 1(전체 목록은 아님)에 나열된 기술을 하나라도 요구하는 응용 프로그램은 작동하지 않거나 비정상적으로 작동할 수 있습니다.
Figure 1 누락된 Windows API (Close Figure 1)

.NET Framework(모든 버전)
ADSI(Active Directory® Services Interfaces)
DirectX®
Microsoft Data Access Components(MDAC)
Jet(Access)
Visual Basic®(.NET 이전 버전 포함)
Windows와 함께 기본적으로 설치되지 않는 프레임워크를 필요로 하는 모든 실행 파일 형식
Windows 탐색기 또는 Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI(각각 Windows Speech, Mail, Telephony API를 나타냄)
따라서 응용 프로그램에서 요구하는 기술을 정확하게 파악해야 합니다. 어떻게 이를 파악할 수 있을까요? Windows PE를 릴리스하기 전에 ADO, HTA(HTML 응용 프로그램) 및 WSH(Windows 스크립트 호스트) 구성 요소가 Windows PE에서 작동하도록 만들려고 했을 때에도 이와 같은 문제에 직면했었습니다. 본 기사에서 이러한 종속성을 추적하는 방법을 설명하겠지만, MKIMG 명령의 범위를 벗어나서 Windows PE 이미지에 Windows 바이너리를 추가할 경우 EULA(최종 사용자 사용권 계약)에 위배된다는 점에 유의해야 합니다. 사용자 환경에서 이러한 변경 사항을 적용하려면 Microsoft로부터 추가 라이선스를 취득해야 합니다.

종속성 이해
응용 프로그램의 .inf 파일을 메모장에서 열고 주의 깊게 살펴보면 많은 것을 배울 수 있습니다. 실제로 이는 응용 프로그램을 이해하고 종속성을 파악하는 가장 손쉬운 방법입니다. 일반적으로 Windows PE는 많은 계층으로 이루어져 있기 때문에 응용 프로그램이 안정적으로 실행되도록 하려면 종속성을 여러 수준에 걸쳐 디버깅해야 합니다. 다시 말해 응용 프로그램의 고유한 직접적 종속성과 이러한 각 종속성으로 인해 부수적으로 발생하는 종속성을 해결해야 합니다. 따라서 주의를 기울이지 않으면 종속성이 단계적으로 매우 복잡해질 수 있습니다. 실수로, 또는 고의로 구성 요소를 몇 개만 추가해도 이미지의 크기와 복잡성이 크게 증대될 수 있습니다.
응용 프로그램을 설명하는 .inf 파일이 있는 경우 해당 .inf 파일에 의해 시스템에 추가되는 레지스트리 키와 파일을 확인하면 종속성을 파악하기 위한 단서를 얻을 수 있습니다. .inf 파일에서 CopyFiles 섹션과 AddReg 섹션을 살펴보면 됩니다. 이러한 항목은 응용 프로그램, DLL, 응용 프로그램이 종속된 기타 파일을 가리킵니다. Windows PE의 세 가지 추가 기능(ADO, HTA 및 WSH) 중에서 WSH가 가장 만들기 쉽습니다. 이전 Windows 버전의 경우 재배포 가능한 버전의 WSH가 아직 제공되며 Windows의 현재 버전에는 WSH의 파일 연결을 수행하는 .inf 파일(%windir%\inf\wsh.inf)이 포함되어 있기 때문에 Windows PE에 WSH를 비교적 간단하게 설치할 수 있습니다.

Orca 및 스냅숏
MSI(Microsoft® Installer) 파일로 배포되는 응용 프로그램의 경우 두 가지 방법으로 종속성을 파악할 수 있습니다. MSI에 익숙한 사용자는 Windows Server® 2003 R2 Platform SDK(http://go.microsoft.com/fwlink/?LinkId=77941)의 일부로 배포되는 Windows Installer 파일 편집 도구인 Orca를 사용하여 MSI를 볼 수 있습니다. 또한 원하는 구성 요소에 대해 MSI를 설치하고 변경된 파일 및 레지스트리 키를 변경되기 전과 비교하여 분석할 수도 있습니다. 레지스트리 덤프 작업을 수행하고 응용 프로그램을 설치한 후 레지스트리를 다시 내보내고 WinDiff를 실행하면 됩니다("WinDiff 사용" 추가 기사 참조). 이 실행 결과를 템플릿으로 활용하여 레지스트리에 필요한 변경을 수행할 수 있습니다. 문제는 변경 사항이 엄청나게 많아질 수 있다는 점입니다. 어쨌든 이 방법은 .inf를 사용할 수 없는 경우(또는 응용 프로그램 작성자의 도움을 받을 수 없는 경우)에 가장 바람직한 방법입니다.
응용 프로그램 스냅숏을 만드는 프로세스는 모두 잘 알고 있을 것입니다. 본질적으로 스냅숏을 만드는 과정은 응용 프로그램이 실행되도록 하기 위해 수행하는 변경 전후 비교 분석과 동일합니다. 예전에는 Microsoft에서 이러한 작업을 수행하는 도구를 배포했지만(Windows 2000의 경우) 이후 버전의 Windows에서는 이 도구가 작동하지 않습니다. 이 작업은 여러 가지 상업용 응용 프로그램(설치 파일 재포장기)은 물론, 일부 무료 유틸리티를 사용하여 수행할 수도 있습니다. WinDiff가 포함되어 있는 Platform SDK(이전 단락의 링크 참조)를 설치하는 것도 하나의 방법입니다. 원칙적으로 WinDiff 비교 작업을 수행하려면 Windows Server 2003 서비스 팩 1(SP1)에 응용 프로그램을 설치하는 것이 좋습니다. 왜냐하면 사용해야 하는 Windows PE 버전이 Standard Edition 또는 Enterprise Edition(SP1 포함)에서 빌드된 Windows PE 1.6이기 때문입니다. Windows Server 2003을 사용하면 Windows PE와 가장 유사한 환경(MSI를 실행할 수 없는 환경임)에서 이 작업을 수행할 수 있습니다. "WinDiff 사용" 추가 기사의 단계를 따르십시오.
그러면 상당히 많은 양의 변경된 정보가 표시됩니다. 그러나 애석하게도 응용 프로그램 설치에 사용할 일종의 매니페스트를 만들기 위해 레지스트리 또는 파일 캡처에서 변경된 정보를 내보내는 간단한 방법은 없으므로 변경 내용을 수동으로 통합해야 합니다. 첫 번째 버전의 Windows PE에서는 이와 관련하여 어려운 문제에 직면했었습니다. 즉, Microsoft 내에는 Internet Explorer® 외부의 HTA 구성 요소에 대한 정의가 없었기 때문에 해당 구성 요소를 제대로 작동하도록 만드는 것은 어려운 문제였습니다. 결국 차이점을 일일이 비교함으로써 HTA가 작동하도록 지원할 수 있었습니다. Windows PE 레지스트리에 이러한 키를 수동으로 추가할 수 있지만 이 경우 Windows PE를 시작한 후에 키를 추가하는 것이 좋습니다. Windows PE 빌드 도구에 포함된 buildoptionalcomponents.vbs 스크립트를 통해 HTA, WSH 및/또는 ADO 지원 기능을 Windows PE에 설치하는 데 사용된 OC.bat 파일과 OC2.bat 파일을 살펴볼 수 있습니다.

유용한 도구
직접적인 종속성은 격리했더라도, 응용 프로그램이 종속된 모든 바이너리를 찾을 수 없는 경우가 많습니다. 예를 들어 일부 작업을 수행하는 데 다른 DLL 또는 OCX가 필요한지 여부를 알 수 없습니다. 그렇다면 어떻게 확인할 수 있을까요? Sysinternals의 유명한 개발자였던 Mark Russinovich(현재는 Microsoft의 기술적 동료)는 바로 이러한 기능을 수행하는 listdlls라는 유용한 유틸리티를 만들었습니다. listdlls는 www.microsoft.com/technet/sysinternals/utilities/ListDlls.mspx(영문)에서 다운로드할 수 있습니다. 이 유틸리티를 사용하려면 listdlls.exe > dlls.txt 명령을 실행한 다음 출력된 내용을 살펴보면 됩니다. 그림 2는 listdlls 자체에 대한 출력을 보여 줍니다. 이 목록을 Windows PE에 포함된 DLL 파일 및 OCX 파일과 비교하면 응용 프로그램의 모든 종속성이 구현되어 있는지 여부를 확인할 수 있습니다. listdlls의 경우 이미 구현되어 있습니다. Windows PE의 HTA 지원의 경우 다른 방법으로는 파악할 수 없었던 일부 종속성을 listdlls로 파악할 수 있었습니다.
그림 2 Lisdlls를 자체적으로 실행한 경우의 출력
그림 2 Lisdlls를 자체적으로 실행한 경우의 출력 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Lisdlls를 자체적으로 실행한 경우의 출력
그림 2 Lisdlls를 자체적으로 실행한 경우의 출력 (더 크게 보려면 이미지를 클릭하십시오.)
그러나 단순히 이 출력에 나열된 DLL이라고 해서 응용 프로그램이 작동하는 데 꼭 필요한 것은 아닙니다. 예를 들어 메모장을 로드하면 uxtheme.dll이라는 파일이 로드됩니다. Windows PE에서는 이 DLL을 사용할 수 없으며, Windows 테마가 사용되지 않으므로 실제로는 로드되지 않습니다. listdlls에 표시되는 DLL 중 실제로 필요한 DLL과 Windows 요청에 따라 로드되는 DLL을 파악하려면 안타깝게도 많은 시행착오를 거치거나 Windows의 하위 수준에 익숙해져야 합니다. Mark Russinovich와 David Solomon의 공저인 Microsoft Windows Internals, Fourth Edition(Microsoft Press®, 2004)을 읽어 보면 이와 관련하여 많은 도움을 얻을 수 있습니다.
실제로 Mark는 Windows 작업 관리자를 대체하는 무료로 제공되는 Process Explorer에 동일한 기능을 포함시켰습니다. 필자의 개인적인 견해지만 listdlls와의 차이점이라면 누락된 종속성을 찾거나 수집하기 위해 사용하거나 스크립트를 작성하기에는 listdlls의 출력이 더 간편하다는 것입니다.
이미지에 DLL을 추가한 후에도 몇 가지 작업을 더 수행해야 합니다. 즉, 등록이 필요한 DLL과 등록이 필요 없는 DLL을 파악해야 합니다. 안타깝게도 DLL을 일일이 등록해 보는 방법 외에는 간단하게 이러한 두 가지 유형의 DLL을 구분할 수 있는 방법이 없습니다. DLL 또는 OCX를 등록하려면 regsvr32 dllname.dll을 실행해야 합니다. 이 파일이 올바르게 작동하면 DLL이 등록되었다는 메시지가 표시됩니다. 그렇지 않으면 메시지가 표시되지 않을 수도 있지만, DLL 등록에 실패했거나 등록할 수 없다는 메시지가 표시되는 경우가 많습니다. Windows PE용 HTA 및 ADO 선택 구성 요소를 개발하면서 발견한 사실 중 하나는 DLL을 등록할 때는 설치용 .inf 파일을 임시로 쓰거나 기타 종속성(예: DLL에 필요한 특정 디렉터리)을 기록하기 위해 쓰기 가능한 저장소가 필요하다는 점입니다. 예전에는 Windows PE에서 이는 곧 오류를 의미했습니다. 다행히 Windows PE 2.0에서는 스크래치 공간이 기본적으로 제공되므로 이러한 작업이 아무 문제 없이 이루어집니다.
Mark가 만들어 최근에 발표한 세 번째 도구가 있는데 바로 Process Monitor입니다. Process Monitor는 Regmon과 Filemon을 결합한 유틸리티라고 할 수 있지만 완전히 새로운 계층인 프로세스 간 통신 계층을 추가하여 이 두 유틸리티보다 훨씬 자세한 정보를 제공합니다. 이 강력한 도구를 사용하면 Windows에서 응용 프로그램의 문제를 해결할 수 있을 뿐만 아니라 DLL 상호 종속성과 관련하여 실제로 수행되는 작업에 대한 궁금증을 해결할 수 있습니다. Process Monitor는 인터넷을 통해 다운로드(영문)할 수 있습니다.

Windows PE 파일 제거
Windows PE를 확장하는 기능 외에도 Windows PE의 크기를 작게 만드는 방법에 대한 문의가 많았습니다. 몇 가지 단계에 따라 Windows PE의 크기를 다소 줄일 수 있습니다. 정식으로 사용이 허가된 Windows PE 복사본에는 몇 가지 빌드 도구 및 설명서가 포함되어 있습니다. 이러한 문서 중에는 winpe.chm이라는 도움말 파일도 있습니다. 이 파일을 열고 Windows Preinstallation Environment User’s Guide(Windows 사전 설치 환경 사용자 가이드) 섹션을 살펴보면 Reducing the Size of Windows PE(Windows PE 크기 축소)라는 항목이 있습니다. 이 섹션에는 필요 없는 경우 안전하게 제거할 수 있는 파일의 목록이 나와 있습니다. 다음 세 곳의 섹션에 제거 가능한 파일과 관련된 내용이 나옵니다.
  • 글꼴 파일은 항상 안전하게 제거할 수 있습니다.
  • 네트워킹 관련 .inf 파일과 유틸리티는 제거할 수 있지만 빌드를 네트워크에서 사용하지 않을 계획인 경우에 한합니다.
  • 명령줄 유틸리티는 제거해서는 안 됩니다. 이러한 유틸리티의 기능과 제거할 경우 발생할 결과를 정확히 알지 못할 경우에는 유틸리티를 제거하지 않는 것이 좋습니다.
안전하게 제거할 수 있는 파일이 확인되면 mkimg.cmd에 의해 빌드가 완성된 후 일괄 파일 또는 기타 스크립트를 작성하여 Windows PE 빌드에서 해당 파일을 제거할 수 있습니다.

Windows PE 레지스트리 수정
빌드 시간에 선택적 구성 요소를 설치하지 않기로 한 것은 의도적인 결정이었습니다. 이로 인해 런타임에 시간이 좀 더 걸리긴 하지만 이러한 구성 요소를 Windows PE에 통합하기 위해 완전히 새로운 방법을 개발할 필요가 없어졌습니다. 이럴 시간이 없기도 했지만 이로 인해 해당 구성 요소가 완전히 제외될 뻔했습니다. 그러나 응용 프로그램에 대한 레지스트리 변경의 델타를 추가하는 것과 같은 레지스트리 변경을 수행하거나, 응용 프로그램이 정상적으로 작동하는 데 필요한 키를 편집하려 한다면 어떨까요? 이러한 작업은 그림 3에 나와 있는 regedit를 사용하여 다음 단계에 따라 간단히 수행할 수 있습니다.
  1. regedit를 실행하고 HKEY_LOCAL_MACHINE 하이브를 선택합니다.
  2. 파일 | 하이브 로드를 선택한 다음 Windows PE 빌드 위치를 탐색합니다. I386\System32\(또는 하드 드라이브에 설치할 이미지인 경우 MiniNT\System32)에서 setupreg.hiv를 선택합니다.
  3. 하이브의 임시 이름을 WinPE와 같이 입력하고 HKLM에서 해당 노드로 이동합니다.
  4. 이 키를 적절하게 수정합니다. 흥미로운 것은 이 노드가 일반적인 Windows 설치의 HKLM\System 노드와 사실상 같다는 점입니다.
  5. 수정이 끝났으면 3단계에서 만든 키를 HKLM에서 선택합니다. 이 단계를 올바르게 수행하지 않으면 시스템이 손상될 수 있습니다.
  6. 파일 | 하이브 언로드...를 선택하고, 예 | 아니요 대화 상자에서 예를 선택하여 매번 레지스트리가 분리되도록 합니다. 레지스트리가 잠기면 Windows PE가 성공적으로 빌드되지 않습니다.
그림 3 Windows PE 레지스트리 열기
그림 3 Windows PE 레지스트리 열기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 Windows PE 레지스트리 열기
그림 3 Windows PE 레지스트리 열기 (더 크게 보려면 이미지를 클릭하십시오.)
다음 단계에 따라 HKLM\System을 수정할 수 있습니다. I386\System32에는 레지스트리의 다른 부분을 수정할 수 있는 또 다른 두 개의 키가 있습니다. 그 중 DEFAULT는 Windows PE를 실행하는 동안 사용하는 SYSTEM을 비롯한 사용자의 기본 하이브이며 SOFTWARE는 HKLM\Software와 같습니다. 언제나 그렇듯이 레지스트리를 편집할 때에는 각별한 주의가 요구되며 반드시 필요한 경우에만 편집해야 합니다.
지금까지 즐겨 사용하는 문제 해결 또는 복구 도구를 Windows PE에 통합하는 데 도움이 되는 몇 가지 사항을 살펴보았습니다. 다음 달 기사에서는 역시 Mark Russinovich가 만든 유용한 시스템 관리 도구 모음인 PSTools 제품군에 대해 알아보겠습니다.
WinDiff 사용
WinDiff는 응용 프로그램의 종속성을 찾는 데 도움이 됩니다. 이 도구의 성공적인 설치와 실행을 위해서는 다음 단계를 따르십시오.
  1. 도구를 설치할 수 있도록 시스템을 준비합니다. 즉, 소요되는 시간을 최소화하고 초기 스냅숏과 최종 스냅숏 간의 파일 또는 레지스트리 변경 내용을 최소한으로 줄여야 합니다.
  2. 명령 프롬프트를 열고 reg export HKLM C:\HKLM1.reg를 실행하여 HKEY_Local_Machine 레지스트리 하이브를 완전히 내보냅니다.
  3. dir C:\*.* /S > C:\C1.txt를 실행하여 C: 드라이브(C:가 시스템 드라이브인 경우)의 모든 파일에 대해 전체 덤프 작업을 수행합니다.
  4. 응용 프로그램을 설치하고 설치 후 설정을 구성합니다.
  5. reg export HKLM C:\HKLM2.reg를 실행합니다.
  6. dir C:\*.* /S > C:\C2.txt를 실행합니다.
  7. WinDiff를 열고 File | Compare Files...(파일 | 파일 비교)를 선택하고 첫 번째 File Open(파일 열기) 대화 상자에서 HKLM1.reg를, 두 번째 대화 상자에서 HKLM2.reg를 각각 선택합니다.
  8. 그러면 어느 파일이 최신 파일인지를 나타내는 빨간색 메시지가 표시됩니다. 내보내는 HKLM 파일이 상당히 클 수 있으므로 이 작업에는 다소 시간이 걸립니다.
  9. 빨간색으로 표시된 텍스트를 두 번 클릭하여 차이점이 자세히 표시되도록 합니다.
  10. Options | Show Right-Only Lines(옵션 | 새로 추가된 줄만 표시)를 선택하면 비교 결과에 표시되는 내용을 구성할 수 있습니다. 그러면 두 번째 비교 파일에 새로 추가된 줄(새 파일 및 레지스트리 키)만 표시됩니다.
응용 프로그램과 관련된 키를 찾으려면 Find 기능을 사용해야 할 수도 있습니다. 그림 A와 그림 B에는 필자가 작성한 가상의 응용 프로그램에 대한 파일 및 레지스트리 변경 사항이 나타나 있습니다. 편리하게도 WinDiff에서는 복사 및 붙여넣기 기능을 사용할 수 있습니다. 이들 기능을 사용하려면 !> 줄을 클릭하고 원하는 줄을 선택하면 됩니다.
그림 A WinDiff 항목
그림 A WinDiff 항목 (더 작게 보려면 이미지를 클릭하십시오.)
그림 A WinDiff 항목
그림 A WinDiff 항목 (더 크게 보려면 이미지를 클릭하십시오.)
그림 B WinDiff의 특정 키
그림 B WinDiff의 특정 키 (더 작게 보려면 이미지를 클릭하십시오.)
그림 B WinDiff의 특정 키
그림 B WinDiff의 특정 키 (더 크게 보려면 이미지를 클릭하십시오.)

Wes Miller는 텍사스 오스틴에 있는 Pluck(www.pluck.com)에 근무하는 개발 관리자입니다. 이전에는 오스틴에 있는 Winternals Software에서 근무했으며 Microsoft에서 프로그램 관리자 및 Windows 제품 관리자로도 근무한 경력이 있습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.


 Field Notes: 알 수 없는 연결 중단
Field Notes
알 수 없는 연결 중단
R'ykandar Korra'ti

"대체 왜 자꾸 연결이 끊어지는지 모르겠습니다."
"아무 때나 그런 현상이 일어납니까? 아니면 특정한 작업을 수행하거나 특정 컴퓨터에서 연결할 때 발생합니까?"
"아닙니다. 그냥 연결한 후 어느 순간에 갑자기 연결이 끊어집니다."
"그런 정보로는 문제를 해결할 수 없습니다. 문제의 원인을 찾을 수 있는 정보가 필요합니다."
"더 이상 말씀드릴 수 있는 것이 없습니다. 가끔 아무 이유도 없이 그냥 연결이 끊깁니다. 문제를 해결할 수 있을까요?"
필자는 노력해 보겠다고 말했습니다. 라우터 로그에는 별다른 내용이 없었습니다. 그러나 가끔 트래픽이 끊어져 있는 것으로 미루어 문제가 있는 것은 분명했지만 1-2분 정도만 끊어졌다가 다시 정상 상태로 돌아왔습니다. 오류도 없고 특정한 패턴도 없이 자주 트래픽이 끊기는 알 수 없는 현상이 발생한 것입니다. 그러다가 운 좋게도 다음과 같은 원인을 찾을 수 있었습니다.
DSL에 연결된 전화로 전화가 걸려옵니다.
IP 연결이 끊깁니다.
그럴 리가 없다고 생각했지만 같은 현상이 재현되었습니다. 아무도 사용하지 않고 사용해서도 안 되는 DSL 전화 번호로 전화가 걸려 오면 연결이 끊기는 것입니다. 전화 회사에서 절대 걱정할 필요가 없다고 공언하는 커다란 문제가 회사의 최대 상품인 DSL 서비스에 아주 짧은 순간 동안 발생하고 있었습니다.
그리고 전화 지국에서 27km밖에 떨어져 있지 않기 때문에 이러한 문제가 발생할 이유가 없습니다. 케이블도 확인했고 필요한 설정도 모두 재설정했고 혹시나 해서 연결도 모두 정리해 보았지만 도움이 되지 않았습니다. 그래서 결국 전화 회사에 전화를 걸어 "계약할 당시에 걸려오는 전화 때문에 연결이 중단되는 일은 없을 거라고 약속하지 않았습니까? 그런데 텔레마케터 전화 때문에 연결이 끊겨 골치가 아플 지경입니다."

구리선 문제?
다음날 기술자가 와서 지국에서 90km 이상 떨어져 회선을 테스트했습니다. 이 정도의 거리에서는 약간의 방해만으로도 연결이 끊길 수 있습니다. 결국 케이블을 새로 설치하는 데 따른 비용을 줄이기 위해 이 구역의 모든 건물에 연결된 전화 회선이 모두 같은 케이블을 사용하고 있다는 사실을 알아냈습니다. 아날로그 방식의 전화만 사용하던 시절에는 문제가 되지 않았지만 DSL의 측면에서는 이러한 회선 분기가 지국으로부터의 회선 길이로 간주되어 회선이 1cm만 길어져도 신호 강도가 떨어집니다.
다행히 문제는 쉽고 빠르게 해결되었습니다. 모든 회선 분기가 차단되었고 "다시 연결하지 마시오. DSL 연결 사용 중"이라는 안내문까지 달았습니다. 이제 지국과의 거래가 실질적으로 27km밖에 되지 않기 때문에 신호 강도가 훨씬 좋아졌고 걸려오는 전화로 인한 트래픽 손실도 사라졌습니다.
이 이야기의 교훈은 연결 문제의 원인이 항상 난해하다거나 소프트웨어에 있을 거라고 쉽게 단정하지 말라는 것입니다. 경우에 따라 구리 케이블 자체의 문제일 수도 있습니다. 따라서 굳이 필요가 없다고 생각되더라도 전화 설치 시에는 항상 전화 회사의 기술자들이 실제 DSL 신호 강도를 확인하도록 해야 합니다. 다른 회선이 연결되어 있어 나중에 문제가 될 수도 있으니까요. 그리고 지국과의 거리에 대해서는 전화 회사에서 하는 말을 그대로 믿어서는 안 됩니다. 케이블이 어디까지 설치되어 있는지, 또한 어디에 사용되는지 알 수 없기 때문입니다. 그래서 테스트를 통해 정확하게 알아내야 합니다. 전화 회사는 이러한 정보를 알아낼 수 있는 도구와 기술을 보유하고 있으므로 이를 이용하도록 해야 합니다. 특히 텔레마케터가 DSL 번호를 알아낸 경우에 큰 도움이 될 것입니다.

R'ykandar Korra'ti는 소규모 공동 ISP의 전자 메일 관리자로, 파트너 Anna와 함께 시애틀 근교에 거주하고 있습니다. Microsoft에서 전자 메일 제품 개발에 참여했던 Korra'ti는 현재 이름조차 생소한 매우 심오한 전공 분야의 대학원을 찾고 있습니다. Korra'ti에게 학문적 조언을 해 주실 분은 darako@murkworks.net으로 연락하시기 바랍니다.


 Windows Confidential: &quot;혼합&quot; 콘텐츠 인식 기능의 향상
Windows Confidential
"혼합" 콘텐츠 인식 기능의 향상
Raymond Chen

CD 또는 DVD를 넣을 경우 셸에서 디스크를 "검사"하여 디스크에 있는 콘텐츠 형식을 확인한 후 이를 바탕으로 어떤 자동 실행 동작을 수행할지 결정합니다. 이러한 검사 프로세스는 추후 향상된 알고리즘이 개발되면 변경될 수 있는 추론적 방법을 통해 이루어지기 때문에 구체적인 검사 방법은 문서화되어 있지 않습니다.
알고리즘을 공식적으로 문서화하면 계약의 적용을 받아 후속 릴리스에서 변경하기가 곤란할 수 있습니다. 따라서 구체적인 알고리즘은 공식적으로 지정되어 있지 않습니다.
SDK에 대한 설명서를 작성해 보지 않으면 문서화가 곧 계약을 의미한다는 사실을 알기 어렵습니다. 특정 기능의 구현 방식을 공식적으로 지정하면 해당 기능을 변경할 수 없게 됩니다. 이 경우 문서화된 기능을 변경하면 해당 기능의 사용자가 "설명서와 다르지 않습니까? 경기가 시작된 후에 경기 규칙을 바꾸는 법이 어디 있습니까?"라고 불평할 수도 있으니까요.
이 기사에서는 이러한 걱정은 잠시 제쳐 두고 Windows® XP 서비스 팩 2(SP2)에서 autorun.inf 파일이 없는 데이터 CD와 데이터 DVD의 콘텐츠를 분류하는 방법에 대해 부족하지만 간단하게나마 설명하도록 하겠습니다. 앞으로 릴리스되는 서비스 팩과 Windows 버전은 이 기사에서 설명하는 내용과 다르게 작동할 수 있다는 점을 먼저 밝혀 둡니다. "부족하지만 간단하게" 설명하겠다고 했는데, 그 이유는 실제 알고리즘이 61단계 결정 테이블로 복잡하게 이루어져 있기 때문입니다. 이 알고리즘에서는 포그라운드 응용 프로그램이 "쿼리 취소 자동 실행" 알림에 응답하는지 여부, 전체 화면 프로그램 실행 여부, 컴퓨터가 최근 도킹 또는 도킹 해제된 랩톱인지 여부 등 모든 구체적인 정보가 고려됩니다. 그러나 이 기사에서는 콘텐츠 검사 단계에 대해서만 살펴보겠습니다.

먼저 셸에서는 사용자가 모든 콘텐츠 형식에 대한 동작을 "아무 작업 안 함"으로 지정했는지 확인합니다. 이 경우 검사가 수행되지 않고 아무 동작도 실행되지 않습니다.
그렇지 않은 경우 셸은 디스크의 각 파일을 최대 4개의 디렉터리 수준까지 살펴본 후 인식된 형식에 따라 이미지, 음악, 동영상 범주 중 하나로 분류합니다.
이러한 세 가지 범주에 해당하지 않는 파일은 무시됩니다. 디스크의 모든 파일이 음악 파일인 경우와 같이 확인된 모든 파일이 하나의 범주에 해당하면 그에 따라 디스크의 형식이 설정됩니다. 세 가지 범주 중 두 가지 이상에 해당하면 디스크는 혼합 콘텐츠로 인식됩니다.
즉, 음악 파일로 채워져 있는 CD에 앨범 아트가 하나만 포함되어 있어도 해당 CD는 Windows XP SP2에서 혼합 콘텐츠로 취급됩니다. 그런데 이것은 변경이 가능한 기능 중 하나입니다. MP3 파일이 주를 이루고 간간히 그림 파일이 포함된 CD가 혼합 콘텐츠로 인식되지 않도록 이러한 알고리즘을 변경했다고 가정해 보겠습니다. 많은 수의 오디오 파일과 단 몇 장의 그림이 포함된 CD를 사용하는 회사도 있을 수 있습니다. 이러한 회사에서는 CD를 혼합 콘텐츠로 인식하는 기능이 필요합니다. 그러나 알고리즘을 변경하면 이 CD는 음악 CD로 잘못 분류되고 회사는 곤란을 겪게 됩니다. 이 문제는 과연 누구의 탓일까요? 검사 알고리즘의 구체적인 작동 방식만을 믿은 회사의 잘못일까요? 아니면 알고리즘 변경에 대한 책임이 있는 Windows가 잘못된 것일까요?
그런데 놀랍게도 제한적인 범위이기는 하지만 Windows Vista™에서는 이 알고리즘이 변경되었습니다. Windows Vista는 잘 알려진 특정 디스크 레이아웃에 대해 알고리즘을 단순화하기 위해 몇 가지 확인 프로세스가 미리 이루어지도록 구현되었습니다. 예를 들어 디스크의 루트 폴더가 DCIM 폴더인 경우 이 폴더는 디지털 사진으로 구성된 것으로 간주됩니다. 한번 사용해 보면 이를 알게 될 것입니다.

Raymond Chen은 그의 웹 사이트 The Old New Thing(영문)과 같은 제목의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. Raymond는 아직도 태양이 어떻게 생겼는지 궁금해 하는 호기심 많은 소년 같습니다.