 TechNet Magazine April 2007
TechNet Magazine April 2007
APRIL 2007
Windows Administration

이번 호에서 Mark Russinovich는 한번 더 Windows Vista 커널로 돌아가 보안, 안정성, 복구 성능의 향상된 부분을 자세하게 살펴봅니다. Active Directory 복구도 이번 호에서 크게 다루는 주제입니다. 응급 상황이 벌어진 후에 이를 수습하려고 애쓰기 보다는 사전에 Active Directory 복구 계획을 세워 보십시오. 마지막으로 Windows XP Embedded가 자신의 조직에서는 별 쓸모가 없다고 생각하시는 분들은 주목해 주십시오. 분명 놀라실 것입니다.

Management

하드웨어의 용량과 비용의 효율성 간에 균형을 맞추려면 어떻게 해야 할까요? 이번 호에서는 올바른 계획을 세우기 위해 System Center Capacity Planner를 사용하여 인프라 요구 사항을 모델링하는 방법을 살펴보겠습니다. 또한 Systems Management Server, WMI, 클라이언트 인벤토리 보고 기능을 개선해 주는 스크립트를 함께 사용하는 방법과 SMS를 이용하여 사용자 지정 업데이트를 배포하는 방법을 배워 보겠습니다.
주요 기사
Windows Administration Windows Vista 커널 속으로: 3부

이번 호에서는 Windows Vista 커널의 새로운 기능에 대해 자세히 다루었던 연재 기사를 정리합니다. 연재물의 마지막인 이번 호에서는 안정성, 복구 및 보안에 관련하여 변경된 내용과 새로운 기능을 살펴봅니다.

Mark Russinovich 재해 복구: Active Directory 사용자 및 그룹

Active Directory에서 데이터를 복구하는 작업은 매우 복잡할 수 있으며, 복구 계획을 제대로 세우는 것이 무엇보다 중요합니다. 여기서는 Active Directory가 개체를 저장, 삭제, 복원 및 복제하는 방식을 자세히 설명하므로 나중에 사용자 또는 그룹 구성원을 실수로 삭제했을 때 문제 해결에 활용할 수 있습니다.

Gil Kirkpatrick Windows XP Embedded가 중요한 이유

아직은 모르고 계실 수 있지만 Windows XP Embedded는 여러분 조직의 IT 구성에 최상의 선택이 될 수 있습니다. Windows XP Embedded를 통해 어떻게 관리 오버헤드를 줄이고, 비용을 절감하고, 보안을 향상시킬 수 있는지 알아보겠습니다.

Don Jones Management System Center Capacity Planner를 사용한 사전 계획

하드웨어가 충분하지 않으면 응답 시간이 느려지는 반면 하드웨어가 너무 많으면 예산과 관리 자원이 낭비됩니다. 이 문서에서는 System Center Capacity Planner를 사용하여 네트워크를 모델링하고 인프라 요구 사항을 정확하게 예측하는 방법을 살펴보겠습니다.

John Savill SMS를 사용한 고급 클라이언트 인벤토리

Microsoft Systems Management Server 2003은 기본적으로 많은 정보를 수집하지만 이 정보만으로 충분하지 않을 수도 있습니다. 이 문서에서는 스크립팅, WMI 및 SMS에 관한 지식을 적절하게 조합하고 이를 바탕으로 SMS 인벤토리를 확장하여 거의 모든 정보를 수집하고 보고하는 방법에 대해 살펴보겠습니다.

Wes Dobry SMS 2003 R2를 사용하여 사용자 지정 소프트웨어 배포

Systems Management Server 2003 R2를 사용하면 관리되는 업데이트 기능을 통해 사용자 지정 업데이트를 배포할 수 있습니다. 이 문서에서는 ITCU(사용자 지정 업데이트용 인벤토리 도구)와 CUPT(사용자 지정 업데이트 게시 도구)라는 두 가지 새로운 도구에 대해 살펴보고 이러한 도구를 사용하여 자신의 고유한 업데이트와 타사 개발자 업데이트를 배포하는 방법에 대해 알아보겠습니다.

Steve Rachui
칼럼
From The Editor

교정 정책에 관하여...

Joshua Trupin Toolbox

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

Greg Steen SQL Q&A

인덱스 다시 작성, 디스크 큐 길이 외

편집자: Nancy Michell Utility Spotlight

Autoruns

Lance Whitney The Cable Guy

Windows Vista의 무선 그룹 정책 설정

Joseph Davies Windows PowerShell

데이터 필터링 및 서식 지정

Don Jones 		Hey, Scripting Guy!

로컬 사용자 및 그룹에 대한 순진한 이야기

Microsoft Scripting Guys Security Watch

보안 구성 마법사

John Morello The Desktop Files

64비트 아키텍처

Wes Miller Inside Microsoft.com

Active Directory Federation Services 사용

Jim Guthrie Field Notes

배움의 즐거움 그리고 고통

Mark D. Scott Windows Confidential

버그의 힘

Raymond Chen


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

Windows Vista 커널 속으로: 3부
한 눈에 보기:
  • 안정성
  • 복구
  • 보안

지금까지 프로세스, I/O, 메모리 관리, 시스템 시작, 종료 및 전원 관리에 관련된 Windows Vista 커널의 향상된 기능에 대해 알아봤습니다. 세 번째이자 마지막 기사인
이번 호에서는 안정성, 복구 및 보안에 관련된 새로운 사항과 향상된 기능에 대해 살펴보겠습니다.
이 연재물에서 다루지 않는 한 가지 기능은 UAC(사용자 계정 컨트롤)입니다. UAC는 레거시 응용 프로그램을 위한 파일 시스템 및 레지스트리 가상화, 관리 권한 액세스를 위한 권한 상승 승인, 관리 권한으로 실행되는 프로세스를 동일한 계정에서 더 낮은 권한으로 실행되는 프로세스와 격리하는 Windows® 무결성 수준 메커니즘을 비롯한 여러 가지 기술로 구성됩니다. UAC에 대해서는 TechNet Magazine의 향후 기사에서 자세히 다룰 것입니다.
Windows Vista™에서는 다양한 새로운 기능과 향상된 기능을 통해 시스템 안정성과 시스템 및 응용 프로그램 문제를 진단하는 기능이 향상되었습니다. 예를 들어 커널 ETW(Windows용 이벤트 추적) 로거는 항상 활성화되어 파일, 레지스트리, 인터럽트 및 기타 작업 유형에 대한 추적 이벤트를 순환 버퍼로 생성합니다. 문제가 발생하면 새로운 WDI(Windows 진단 인프라)가 버퍼의 스냅숏을 캡처하여 로컬에서 분석하거나 문제 해결을 위해 Microsoft 기술 지원부로 보낼 수 있습니다.
새로운 Windows 성능 및 안정성 모니터를 사용하면 충돌이나 중단과 같은 오류를 시스템 구성 변경 내용과 연관하여 분석할 수 있습니다. 또한 부팅 불가능한 시스템의 오프라인 복구를 위한 기존 복구 콘솔이 강력한 SRT(시스템 복구 도구)로 대체되었습니다.
시스템에 대한 커널 수준의 변경에 많은 영향을 받는 세 가지 영역은 KTM(커널 트랜잭션 관리자), 향상된 충돌 처리, 그리고 이전 버전입니다. 이번 기사에서는 이 세 가지 영역에 대해 자세히 살펴보겠습니다.

커널 트랜잭션 관리자
소프트웨어 개발에서 많은 어려움이 따르는 분야 중 하나가 오류 조건의 처리입니다. 특히 높은 수준의 작업을 수행하는 과정에서 응용 프로그램이 파일 시스템 또는 레지스트리를 변경하는 하위 작업을 한 가지 이상 수행한 경우에 더욱 그렇습니다. 예를 들어 응용 프로그램의 소프트웨어 업데이트 서비스가 레지스트리 업데이트를 수행하고 응용 프로그램의 실행 파일 중 하나를 바꾸었는데 두 번째 실행 파일을 업데이트하려고 하자 액세스가 거부되는 경우가 발생할 수 있습니다. 이 경우 응용 프로그램을 일관성 없는 상태로 남겨두지 않으려면 변경 내용을 모두 추적하여 실행을 취소할 수 있도록 준비해야 합니다. 오류 복구 코드를 테스트하는 것은 상당히 까다롭기 때문에 생략되는 경우가 많습니다. 이 경우 복구 코드의 오류로 인해 위와 같은 노력이 물거품이 될 수 있습니다.
Windows Vista용으로 개발된 응용 프로그램은 NTFS의 새로운 트랜잭션 지원과 커널 트랜잭션 관리자를 통한 레지스트리를 사용함으로써 별다른 어려움 없이 자동 오류 복구 기능을 갖출 수 있습니다. 많은 수의 관련된 변경을 수행하려는 응용 프로그램에서는 DTC(Distributed Transaction Coordinator) 트랜잭션과 KTM 트랜잭션 핸들을 만들거나, KTM 핸들을 직접 만들어서 파일 및 레지스트리 키의 수정 내용을 트랜잭션에 연결할 수 있습니다. 모든 변경이 성공적으로 수행되면 응용 프로그램은 트랜잭션을 커밋하고 변경 내용이 적용됩니다. 그러나 이 단계 이전에는 언제라도 응용 프로그램에서 트랜잭션을 롤백하고 변경을 취소할 수 있습니다.
또한 다른 응용 프로그램에서는 트랜잭션이 커밋될 때까지는 해당 트랜잭션의 변경 내용을 볼 수 없지만 Windows Vista와 향후 출시될 Windows Server®(코드명 "Longhorn")의 DTC를 사용하는 응용 프로그램에서는 SQL Server™, Microsoft® Message Queue Server(MSMQ) 및 기타 데이터베이스를 통해 트랜잭션을 조정할 수 있습니다. 따라서 KTM 트랜잭션을 사용하는 응용 프로그램 업데이트 서비스로 인해 응용 프로그램이 일관성 없는 상태가 되는 일은 없습니다. 이러한 이유 때문에 Windows Update와 시스템 복원 모두에 트랜잭션이 사용됩니다.
NTFS, 레지스트리 등의 트랜잭션 리소스 관리자는 트랜잭션 지원의 핵심인 KTM을 통해 응용 프로그램이 수행한 특정 변경 사항과 자체 업데이트를 조정합니다. Windows Vista의 NTFS에서는 TxF라고 하는 트랜잭션 지원 확장 기능을 사용합니다. 레지스트리에서는 TxR이라고 하는 비슷한 확장 기능을 사용합니다. 사용자 모드 리소스 관리자가 DTC를 사용하여 여러 사용자 모드 리소스 관리자를 대상으로 트랜잭션 상태를 조정하는 것처럼 이 커널 모드 리소스 관리자는 KTM을 통해 트랜잭션 상태를 조정합니다. 타사에서도 KTM을 사용하여 자체 리소스 관리자를 구현할 수 있습니다.
TxF와 TxR은 트랜잭션 매개 변수를 포함한다는 점 외에는 모두 기존의 것과 비슷한 새로운 파일 시스템 및 레지스트리 API를 정의합니다. 응용 프로그램이 트랜잭션 내에서 파일을 만들려면 먼저 KTM을 사용하여 트랜잭션을 만든 다음, 그 결과로 생성되는 트랜잭션 핸들을 새 파일 만들기 API로 전달합니다.
TxF 및 TxR은 Windows Server 2003 R2에서 소개된 CLFS(공용 로그 파일 시스템)(%SystemRoot%\System32\Clfs.sys)의 고속 파일 시스템 로깅 기능을 사용합니다. TxR 및 TxF는 CLFS를 사용하여 트랜잭션을 커밋하기 전에 트랜잭션 상태 변경을 안정적으로 저장합니다. 따라서 전원이 끊긴 경우에도 트랜잭션을 복구하여 신뢰성을 확보할 수 있습니다. TxR은 CLFS 로그 외에도 각 사용자 레지스트리 하이브에 대한 별도의 로그 파일 집합뿐만 아니라 그림 1에서 볼 수 있는 것처럼 %Systemroot%\System32\Config\Txr의 시스템 레지스트리 파일에 대한 트랜잭션 변경을 추적하기 위해 관련 로그 파일 집합을 만듭니다. TxF는 각 볼륨의 트랜잭션 데이터를 해당 볼륨에서 \$Extend\$RmMetadata라고 하는 숨겨진 디렉터리에 저장합니다.
그림 1 시스템 레지스트리 하이브 TxR 로깅 파일
그림 1 시스템 레지스트리 하이브 TxR 로깅 파일 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 시스템 레지스트리 하이브 TxR 로깅 파일
그림 1 시스템 레지스트리 하이브 TxR 로깅 파일 (더 크게 보려면 이미지를 클릭하십시오.)

향상된 충돌 지원
장치 드라이버의 버그, 하드웨어 또는 운영 체제의 오류 등의 이유로 복구할 수 없는 커널 모드 오류가 발생하는 경우 Windows에서는 "블루 스크린"을 표시한 다음 시스템을 중지하여 디스크의 데이터 손상을 방지합니다. 또한 구성에 따라서는 실제 메모리의 내용 전체 또는 일부를 크래시 덤프 파일에 씁니다. 충돌이 발생한 후 다시 부팅하면 Microsoft Online Crash Analysis(OCA) 서비스에서 덤프 파일을 분석하여 근본 원인을 찾기 때문에 이 덤프 파일은 유용하게 사용됩니다. 필요한 경우 Windows용 Microsoft 디버깅 도구를 사용하여 직접 원인을 분석할 수도 있습니다.
그러나 이전 버전의 Windows에서는 세션 관리자(%Systemroot%\System32\Smss.exe) 프로세스가 페이징 파일을 초기화할 때까지 크래시 덤프 파일을 사용할 수 없습니다. 따라서 이 시점 이전에 심각한 오류가 발생하면 블루 스크린이 표시되지만 덤프 파일은 생성되지 않습니다. Smss.exe가 시작하기 전에 많은 장치 드라이버의 초기화가 수행되기 때문에 초기에 충돌이 발생하면 크래시 덤프가 생성되지 않으므로 원인을 진단하기가 매우 어렵습니다.
Windows Vista에서는 모든 부팅 시작 장치 드라이버가 초기화된 후 시스템 시작 드라이버가 로드되기 전에 덤프 파일 지원이 초기화되므로 덤프 파일이 생성되지 않는 시간이 줄었습니다. 따라서 부팅 프로세스의 초기 단계에서 충돌이 발생하더라도 시스템에서 크래시 덤프를 만들 수 있기 때문에 OCA를 통해 문제 해결에 도움을 받을 수 있습니다. 또한 이전 버전의 Windows에서는 데이터를 4KB 블록 단위로 덤프 파일에 저장하지만 Windows Vista는 64KB 블록 단위로 저장합니다. 따라서 용량이 큰 덤프 파일도 최대 10배까지 더 빠르게 기록할 수 있습니다.
Windows Vista에서는 응용 프로그램 충돌 처리도 개선되었습니다. 이전 버전의 Windows에서는 응용 프로그램이 충돌하면 처리되지 않은 예외 처리기가 실행됩니다. 이 처리기는 Microsoft AER(응용 프로그램 오류 보고) 프로세스(%Systemroot%\System32\Dwwin.exe)를 실행하여 프로그램에 오류가 발생했음을 알리고 Microsoft에 오류 보고서를 보낼 것인지 묻는 대화 상자를 표시합니다. 그러나 충돌로 인해 프로세스의 주 스레드 스택이 손상된 경우에는 처리되지 않은 예외 처리기가 실행될 때 오류가 발생하여 커널에 의해 프로세스가 종료되고 프로그램 창이 사라지며 오류 보고 대화 상자가 나타나지 않습니다.
Windows Vista에서는 충돌 프로세스의 컨텍스트가 아니라 새로운 서비스인 WER(Windows 오류 보고)에서 오류 처리를 수행합니다. 이 서비스는 서비스 호스팅 프로세스 내의 DLL(%Systemroot%\System32\Wersvc.dll)로 구현됩니다. 응용 프로그램 충돌이 발생할 때 여전히 처리되지 않은 예외 처리기가 실행되기는 하지만 이 처리기는 WER 서비스로 메시지를 보내고 WER 서비스는 WER 오류 보고 프로세스(%Systemroot%\System32\Werfault.exe)를 실행하여 오류 보고 대화 상자를 표시합니다. 스택이 손상되고 처리되지 않은 예외 처리기가 충돌하면 처리기가 다시 실행되고 다시 충돌이 발생하여 결과적으로 스레드의 모든 스택(스크래치 메모리 영역)을 소비하게 됩니다. 이 단계에서 커널이 개입하여 해당 서비스에 충돌 알림 메시지를 보냅니다.
Windows XP 및 Windows Vista에서 충돌하는 테스트 프로그램인 Accvio.exe의 프로세스 관계와 녹색으로 강조 표시된 오류 보고 프로세스를 보여 주는 그림 2와 3에서 이 두 가지 방식의 차이를 확인할 수 있습니다. 새로운 Windows Vista 오류 처리 아키텍처에서는 충돌한 프로그램이 자동으로 종료되어 Microsoft에 오류 보고서를 보내지 못하는 경우가 발생하지 않습니다. 따라서 소프트웨어 개발자는 응용 프로그램을 개선할 기회를 얻을 수 있습니다.
그림 2a Windows XP에서의 응용 프로그램 오류 처리
그림 2a Windows XP에서의 응용 프로그램 오류 처리 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2a Windows XP에서의 응용 프로그램 오류 처리
그림 2a Windows XP에서의 응용 프로그램 오류 처리 (더 크게 보려면 이미지를 클릭하십시오.)
그림 2b
그림 2b (더 작게 보려면 이미지를 클릭하십시오.)
그림 2b
그림 2b (더 크게 보려면 이미지를 클릭하십시오.)
그림 3a Windows Vista에서의 응용 프로그램 오류 처리
그림 3a Windows Vista에서의 응용 프로그램 오류 처리 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3a Windows Vista에서의 응용 프로그램 오류 처리
그림 3a Windows Vista에서의 응용 프로그램 오류 처리 (더 크게 보려면 이미지를 클릭하십시오.)
그림 3b
그림 3b

볼륨 섀도 복사본
Windows XP에서는 디스크 볼륨의 지정 시간 스냅숏을 만들기 위한 볼륨 섀도 복사본이라는 기술이 도입되었습니다. 백업 응용 프로그램은 이 스냅숏을 사용하여 일관된 백업 이미지를 만들 수 있습니다. 스냅숏은 사용자에게 표시되지 않으며 백업 프로세스 실행 중에만 유지됩니다.
스냅숏이 실제로 볼륨의 전체 복사본은 아닙니다. 스냅숏은 실시간 볼륨 데이터 위에 스냅숏이 생성된 이후 변경된 볼륨 섹터 복사본을 덧씌운 형태로 이루어진, 이전 시점의 볼륨 보기입니다. 볼륨 스냅숏 공급자 드라이버(%Systemroot\%System32\Drivers\Volsnap.sys)는 볼륨을 대상으로 수행되는 작업을 모니터링하면서 해당 작업이 변경하는 내용을 허용하기 전에 섹터의 백업 복사본을 만들고 원래 데이터는 해당 볼륨의 System Volume Information 디렉터리에 있는 스냅숏과 연결된 파일에 저장합니다.
Windows Server 2003에서 서버의 관리자와 클라이언트 시스템의 사용자는 공유 폴더의 섀도 복사본을 통해 스냅숏 관리를 확인할 수 있습니다. 이 기능을 사용하면 사용자가 서버의 파일 공유에 있는 자신의 폴더 및 파일에 대한 탐색기 속성 대화 상자의 이전 버전 탭을 통해 영구 스냅숏에 액세스할 수 있습니다.
Windows Vista의 이전 버전 기능은 이러한 기능을 모든 클라이언트 시스템에서 사용할 수 있도록 지원하며 일반적으로 매일 한 번씩 자동으로 볼륨 스냅숏을 만듭니다. 사용자는 공유 폴더의 섀도 복사본에 사용되는 것과1 동일한 인터페이스를 사용하여 탐색기 속성 대화 상자를 통해 볼륨 스냅숏에 액세스할 수 있습니다. 따라서 실수로 수정했거나 삭제한 파일과 디렉터리의 이전 버전을 보거나 복원하거나 복사할 수 있습니다. 기술적인 면에서 볼 때 새로운 것은 아니지만 Windows Vista에서 구현되는 볼륨 섀도 복사본의 이전 버전 기능은 Windows Server 2003의 볼륨 새도 복사본을 클라이언트 데스크톱 환경에서 사용할 수 있도록 최적화한 것입니다.
또한 Windows Vista에서는 볼륨 스냅숏을 활용하여 사용자 및 시스템 데이터 보호 메커니즘을 단일화하고 백업 데이터가 중복 저장되지 않도록 합니다. 응용 프로그램 설치 또는 구성 변경으로 인해 올바르지 않거나 바람직하지 않은 동작이 발생하면 Windows XP에서 Windows NT® 운영 체제 제품군에 도입된 기능인 시스템 복원을 사용하여 시스템 파일과 데이터를 복원 지점이 생성된 시점의 상태로 복원할 수 있습니다.
Windows XP에서 시스템 복원 기능은 파일 수준에서 변경 내용을 확인할 수 있는 드라이버 유형인 파일 시스템 필터 드라이버를 사용하여 변경 시점에서 시스템 파일의 백업 복사본을 만듭니다. Windows Vista의 시스템 복원 기능은 볼륨 스냅숏을 사용합니다. Windows Vista에서 시스템 복원 사용자 인터페이스를 사용하여 복원 지점으로 돌아가는 경우 실제로는 수정된 시스템 파일의 이전 버전이 복원 지점과 연결된 스냅숏에서 현재 볼륨으로 복사됩니다.

BitLocker
Windows Vista는 지금까지의 Windows 운영 체제 중 가장 안전한 버전입니다. Windows Vista에서는 Windows Defender 스파이웨어 방지 엔진 외에도 BitLocker™ 전체 볼륨 암호화, 커널 모드 코드를 위한 코드 서명, 보호된 프로세스, 주소 공간 로드 불규칙화, 향상된 Windows 서비스 보안 및 사용자 계정 컨트롤을 비롯하여 다양한 보안 및 심층 방어 기능을 제공합니다.
운영 체제는 활성화 상태에서만 보안 정책을 적용할 수 있기 때문에 시스템의 물리적 보안이 손상되었을 경우와 운영 체제 외부에서 데이터에 액세스할 경우를 대비하여 데이터를 보호하기 위한 추가적인 대책도 마련해야 합니다. BIOS 암호 및 암호화와 같은 하드웨어 기반 메커니즘은 분실이나 도난의 위험이 큰 랩톱에서 무단 액세스를 방지하는 용도로 많이 사용되는 두 가지 기술입니다.
Windows 2000에서 도입된 EFS(파일 시스템 암호화)는 Windows Vista에서 성능이 더욱 향상되어 페이징 파일 암호화 지원 및 스마트 카드에 사용자 EFS 키 저장과 같은 다양한 향상된 기능을 제공합니다. 그러나 레지스트리 하이브 파일과 같이 시스템의 중요한 영역에 대한 액세스를 보호하는 용도로 EFS를 사용할 수는 없습니다. 예를 들어 도메인에 연결되어 있지 않더라도 랩톱에 로그온할 수 있도록 그룹 정책이 설정된 경우 도메인 자격 증명 확인 프로그램이 레지스트리에 캐시되기 때문에 공격자가 도구를 사용하여 도메인 계정 암호 해시를 취득하고 이를 사용하여 암호 크래커를 통해 암호를 알아내려는 시도를 할 가능성이 있습니다. 공격자가 암호를 알아내면 사용자의 계정과 EFS 파일(EFS 키를 스마트 카드에 저장하지 않은 경우)에 액세스할 수 있게 됩니다.
Windows Vista에서는 모든 시스템 파일과 데이터를 포함한 전체 부팅 볼륨(Windows 디렉터리가 있는 볼륨)을 쉽게 암호화할 수 있도록 Windows BitLocker 드라이브 암호화라고 하는 전체 볼륨 암호화 기능을 제공합니다. NTFS 파일 시스템 드라이버로 구현되며 파일 수준에서 작동하는 EFS와는 달리 BitLocker는 그림 4에 설명된 것처럼 FVE(전체 볼륨 암호화) 드라이버(%Systemroot%\System32\Drivers\Fvevol.sys)를 사용하여 볼륨 수준에서 암호화합니다.
그림 4 BitLocker FVE 필터 드라이버
그림 4 BitLocker FVE 필터 드라이버 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 BitLocker FVE 필터 드라이버
그림 4 BitLocker FVE 필터 드라이버 (더 크게 보려면 이미지를 클릭하십시오.)
FVE는 필터 드라이버이므로 NTFS가 볼륨으로 전송하는 모든 I/O 요청을 자동으로 확인하고, 처음에 BitLocker를 사용하도록 볼륨을 구성한 경우 해당 볼륨에 할당된 FVEK(전체 볼륨 암호화 키)를 사용하여 블록을 기록할 때 암호화하고 블록을 읽을 때 암호를 해독합니다. 기본적으로 볼륨은 128비트 AES 키와 128비트 Diffuser 키를 통해 암호화됩니다. 암호화 및 암호 해독은 I/O 시스템의 NTFS 아래에서 수행되기 때문에 볼륨은 암호화되지 않은 것처럼 NTFS에 표시되고 NTFS는 BitLocker가 설정되어 있는 것을 알 필요도 없습니다. 그러나 Windows 외부에서 볼륨에 있는 데이터를 읽으려고 시도하면 해당 데이터는 무작위 데이터로 보입니다.
FVEK는 VMK(볼륨 마스터 키)로 암호화되어 볼륨의 특별한 메타데이터 영역에 저장됩니다. BitLocker를 구성할 때는 시스템의 하드웨어 성능에 따라 VMK의 보호 수준을 다양하게 설정할 수 있습니다. 시스템에 TPM 사양 v1.2를 준수하는 TPM(신뢰할 수 있는 플랫폼 모듈)이 설치되어 있고 BIOS에서 이를 지원하는 경우 TPM을 통해 VMK를 암호화하거나, TPM에 저장되어 있는 키와 USB 플래시 장치에 저장되어 있는 키를 사용하여 시스템에서 VMK를 암호화하도록 하거나, TPM 저장 키와 시스템 부팅 시 사용자가 입력하는 PIN을 사용하여 키를 암호화할 수 있습니다. TPM이 없는 시스템의 경우 BitLocker는 외부 USB 플래시 장치에 저장된 키를 사용하여 VMK를 암호화하는 옵션을 제공합니다. 어떠한 경우든 암호화되지 않은 1.5GB의 NTFS 시스템 볼륨이 필요합니다. 이 볼륨에는 부팅 관리자와 BCD(부팅 구성 데이터베이스)가 저장됩니다.
TPM을 사용할 때 얻게 되는 이점은 BitLocker를 사용하도록 설정한 이후에 BIOS나 시스템 부팅 파일이 변경된 경우 BitLocker가 TPM을 사용하여 VMK의 암호를 해독하거나 부팅 볼륨의 잠금을 해제하지 못하도록 할 수 있다는 것입니다. 시스템 볼륨을 처음 암호화하는 경우, 그리고 앞에서 언급한 구성 요소를 업데이트할 때마다 BitLocker는 해당 구성 요소의 SHA-1 해시를 계산하고 TPM 장치 드라이버(%Systemroot%\System32\Drivers\Tpm.sys)를 사용하여 측정값이라고 하는 각 해시를 TPM의 개별 PCR(플랫폼 구성 레지스터)에 저장합니다. 그런 다음 TPM을 사용하여 VMK를 봉인합니다. 이 작업에는 VMK를 암호화하기 위해 TPM에 저장된 개인 키와 BitLocker가 TPM으로 전달하는 다른 데이터와 함께 PCR에 저장된 값이 사용됩니다. 그런 다음 BitLocker는 봉인된 VMK와 암호화된 FVEK를 볼륨의 메타데이터 영역에 저장합니다.
시스템은 부팅될 때 자체 해시 값과 PCR 로딩 코드를 측정하여 해시를 TPM의 첫 번째 PCR에 씁니다. 그런 다음 BIOS를 해시하여 해당 측정값을 적절한 PCR에 저장합니다. BIOS는 부팅 시퀀스의 그 다음 구성 요소인 부팅 볼륨의 MBR(마스터 부트 레코드)을 해시하고 이 프로세스는 운영 체제 로더가 측정될 때까지 계속됩니다. 이후 실행되는 각 코드는 로드되는 코드를 측정하고 측정값을 TPM의 적절한 레지스터로 저장하는 역할을 합니다. 마지막으로 사용자가 부팅할 운영 체제를 선택하면 부팅 관리자(Bootmgr)가 볼륨에서 암호화된 VMK를 읽고 TPM에 봉인 해제를 요청합니다. 선택적으로 사용할 수 있는 PIN을 포함하여 측정값이 VMK가 봉인될 때와 동일한 경우에만 TPM이 VMK의 암호를 성공적으로 해독합니다.
이러한 체계는 부팅 시퀀스의 각 구성 요소가 그 다음 구성 요소를 TPM에 설명하는 확인 체인(Verification Chain)에 비유할 수 있습니다. 모든 설명이 원래 할당된 설명과 일치하는 경우에만 TPM이 암호 해독을 수행합니다. 따라서 BitLocker는 디스크를 분리하여 다른 시스템에 설치하거나, 다른 운영 체제를 사용하여 시스템을 부팅하거나, 부팅 볼륨의 암호화되지 않은 파일이 손상된 경우에도 암호화된 데이터를 보호할 수 있습니다.

코드 무결성 확인
루트킷을 포함하여 커널 모드 장치 드라이버로 구현되는 맬웨어는 커널과 동일한 권한 수준에서 실행되기 때문에 이를 식별하여 제거하는 것이 매우 어렵습니다. 이러한 맬웨어는 사실상 눈에 띄지 않게 커널 및 기타 드라이버의 동작을 수정할 수 있습니다. KMCS(커널 모드 코드 서명)라고도 하는 커널 모드 코드에 대한 Windows Vista 코드 무결성 기능은 CA(인증 기관) 중 하나에서 인증을 받은 개발자가 게시하고 디지털 서명한 장치 드라이버만 로드할 수 있도록 허용합니다. KMCS는 64비트 시스템용 Windows Vista에서 기본적으로 적용됩니다.
인증 기관은 제공하는 서비스에 대해 요금을 부과하고 비즈니스 ID 확인과 같은 기본적인 배경 검사를 수행합니다. 따라서 64비트 Windows Vista에서 실행되는 익명 커널 모드 맬웨어를 만드는 것이 더욱 어렵습니다. 또한 확인 프로세스를 빠져 나가는 맬웨어라도 공격을 받은 시스템에서 맬웨어가 발견되었을 때 만든 이를 추적할 수 있는 단서가 남을 가능성이 많습니다. 또한 KMCS는 사용자 시스템에서 충돌을 일으키는 버그가 있는 것으로 의심되는 드라이버에 대해 Windows Online Crash Analysis 팀에게 연락처 정보를 제공하고 고화질 멀티미디어 콘텐츠의 잠금을 해제하는 등의 용도로도 사용됩니다. 이에 대해서는 뒷부분에서 간단히 살펴보겠습니다.
KMCS는 Windows에서 10년 이상 사용되고 있는 공개 키 암호화 기술을 사용하며 신뢰할 수 있는 인증 기관 중 하나가 생성한 디지털 서명을 커널 모드 코드에 포함하도록 요구합니다. 게시자가 드라이버를 Microsoft Windows Hardware Quality Laboratory(WHQL)에 제출하고 해당 드라이버가 안정성 테스트를 통과하면 Microsoft는 해당 코드에 서명한 인증 기관 역할을 하게 됩니다. 대부분의 게시자는 WHQL을 통해 서명을 얻습니다. 그러나 드라이버에 WHQL 테스트 프로그램이 없거나, 게시자가 WHQL 테스트에 드라이버를 제출하지 않으려 하거나, 드라이버가 시스템 시작 초기에 로드되는 부팅 시작 드라이버인 경우에는 게시자가 직접 코드에 서명해야 합니다. 이렇게 하려면 해당 게시자는 먼저 Microsoft에서 커널 모드 코드 서명을 신뢰할 수 있는 것으로 구분한 인증 기관 중 한 곳을 통해 코드 서명 인증서를 얻어야 합니다. 그런 다음 게시자는 코드를 디지털 방식으로 해시하고 개인 키로 이를 암호화하여 해시에 서명하고 코드에 인증서와 암호화된 해시를 추가합니다.
드라이버 로드가 시도되면 Windows에서는 인증서에 저장된 공개 키를 사용하여 코드에 포함된 해시의 암호를 해독한 다음 이 해시가 코드에 포함된 것과 일치하는지 확인합니다. 인증서의 신뢰성도 이와 동일한 방법으로 확인하지만 이 경우에는 Windows에 포함된 인증 기관의 공개 키를 사용합니다.
또한 Windows에서는 Windows 부팅 로더와 운영 체제 커널에 포함된 루트 인증 기관 중 하나까지 연관된 인증서 체인을 확인합니다. 프로덕션 시스템에서는 서명되지 않은 64비트 드라이버의 로드가 시도되지 않아야 합니다. 따라서 WQHL 테스트를 통과했음을 확인하는 서명이 없는 드라이버를 로드하려고 하면 경고 대화 상자를 표시하는 플러그 앤 플레이 관리자와는 달리 64비트 Windows Vista에서는 서명되지 않은 드라이버의 로드를 차단할 때마다 그림 5에 표시된 것처럼 CodeIntegrity 응용 프로그램 이벤트 로그에 이벤트를 자동으로 기록합니다. 32비트 Windows Vista에서도 드라이버 서명을 확인하지만 서명되지 않은 드라이버의 로드가 허용됩니다. 이를 차단하면 Windows XP에서 로드된 드라이버를 필요로 하는 업그레이드된 Windows XP 시스템의 작동에 문제가 생길 수 있습니다. 또한 서명되지 않은 드라이버 로드를 허용하면 Windows XP 드라이버만 있는 하드웨어를 지원할 수도 있습니다. 32비트 Windows Vista도 서명되지 않은 드라이버를 로드할 때 CodeIntegrity 이벤트 로그에 이벤트를 기록합니다.
그림 5 서명되지 않은 드라이버 로드 시도 이벤트
그림 5 서명되지 않은 드라이버 로드 시도 이벤트 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 서명되지 않은 드라이버 로드 시도 이벤트
그림 5 서명되지 않은 드라이버 로드 시도 이벤트 (더 크게 보려면 이미지를 클릭하십시오.)
코드 서명은 일반적으로 엄격한 테스트를 통과한 공식 릴리스 코드에 사용되기 때문에 테스트 코드에는 서명을 하지 않으려고 하는 게시자가 많습니다. 따라서 Windows Vista에는 자체 인증 기관에서 생성한 테스트 인증서로 디지털 서명된 커널 모드 드라이버를 로드하는 Bcdedit 도구(필자의 2007년 3월 TechNet Magazine 기사에서 설명)를 통해 사용하거나 사용하지 않도록 설정할 수 있는 테스트 서명 모드가 포함되어 있습니다. 이 모드는 프로그래머가 코드 개발 과정에서 사용하도록 설계되었습니다. Windows가 이 모드에 있을 때는 바탕 화면에 그림 6과 같은 표시가 나타납니다.
그림 6 Windows Vista 테스트 서명 모드
그림 6 Windows Vista 테스트 서명 모드

보호된 프로세스
향후 몇 년 이내에 HD-DVD, 블루 레이 및 AACS(Advanced Access Content System)에 따라 사용이 허가된 기타 형식과 같은 차세대 멀티미디어 콘텐츠가 널리 사용될 것입니다. Windows Vista에는 AACS 표준에 따라 이러한 콘텐츠를 재생하는 데 필요한 여러 기술이 포함되어 있으며 이를 통칭하여 PMP(Protected Media Path)라고 합니다. PMP에는 승인되지 않은 소프트웨어 또는 하드웨어에서 콘텐츠를 고화질로 캡처하는 것을 방지하기 위해 미디어 플레이어 응용 프로그램과 오디오 및 비디오 드라이버를 위한 메커니즘을 제공하는 PUMA(Protected User-Mode Audio) 및 PVP(Protected Video Path)가 포함됩니다.
PUMA와 PVP는 오디오 및 비디오 플레이어, 장치 드라이버 및 하드웨어에 관련된 인터페이스와 지원을 정의하지만 PMP는 Windows Vista에 포함된 보호된 프로세스라고 하는 일반 커널 메커니즘도 활용합니다. 보호된 프로세스는 실행 가능 이미지, DLL, 프로세스가 실행되는 계정과 보안 권한을 의미하는 보안 컨텍스트 및 프로세스 내에서 코드를 실행하는 스레드를 캡슐화하는 표준 Windows 프로세스 구성을 기반으로 하지만 특정한 유형의 액세스는 차단합니다.
표준 프로세스는 프로세스의 소유자 및 프로그램 디버깅 권한이 있는 관리자 계정에게 모든 권한을 부여하는 액세스 제어 모델을 구현합니다. 모든 권한을 보유한 사용자는 프로세스에 매핑된 코드와 데이터를 비롯하여 프로세스의 주소 공간을 보고 수정할 수 있습니다. 또한 프로세스에 스레드를 삽입할 수도 있습니다. 이러한 유형의 액세스 권한은 승인되지 않은 코드가 콘텐츠를 재생하고 있는 프로세스에 저장된 DRM(디지털 권한 관리) 키와 고화질 콘텐츠에 대한 액세스 권한을 획득하는 것이 가능하도록 할 수 있기 때문에 PMP의 요구 사항에 맞지 않습니다.
보호된 프로세스는 프로세스의 이미지 이름 쿼리 및 프로세스의 종료나 일시 중단을 포함한 일부 정보 및 프로세스 관리 인터페이스에 대한 액세스를 제한합니다. 그러나 시스템의 모든 프로세스에 관련된 데이터를 반환하는 커널의 일반 프로세스 쿼리 기능을 사용하면 보호된 프로세스에 대한 진단 정보를 사용하는 것이 가능하기 때문에 프로세스에 직접 액세스할 필요가 없습니다. 미디어 악용을 초래할 수 있는 액세스는 다른 보호된 프로세스에 의해서만 허용됩니다.
또한 내부로부터의 악용을 방지하기 위해, 실행 가능 이미지와 DLL을 포함하여 보호된 프로세스로 로드되는 모든 실행 가능 코드는 Microsoft WHQL에 의해 PE(보호 환경) 플래그로 서명을 받거나 Microsoft에서 얻은 DRM 서명 인증서를 통해 개발자로부터 서명을 받아야 합니다. 커널 모드 코드는 보호된 프로세스를 포함하여 모든 프로세스에 대한 모든 권한을 얻을 수 있으며 32비트 Windows에서는 서명되지 않은 커널 모드 코드를 로드하는 것이 허용되기 때문에 커널은 커널 모드 환경의 "무결성"을 확인하고 그 결과를 사용하여 서명되지 않은 코드가 로드되지 않은 경우에만 중요한 콘텐츠의 잠금을 해제하는 보호된 프로세스용 API를 제공합니다.
보호된 프로세스 식별
보호된 프로세스를 식별하는 별도의 전용 API는 없지만 보호된 프로세스에 대한 제한적인 정보와 관리자 계정을 사용해도 보호된 프로세스를 디버깅할 수 없다는 점을 이용하면 간접적으로 보호된 프로세스를 식별할 수 있습니다. CSS(Content Scramble System)로 인코딩된 DVD를 재생하는 데 사용되는 오디오 장치 그래프 격리 프로세스(%Systemroot%\System32\Audiodg.exe)는 관리자 권한으로 실행할 때도 작업 관리자에서 명령줄, 가상화 및 데이터 실행 방지 상태를 사용할 수 없다는 점을 감안할 때 보호된 프로세스라는 것을 알 수 있습니다.
보호된 프로세스인 audiodg가 표시된 작업 관리자
보호된 프로세스인 audiodg가 표시된 작업 관리자 (더 작게 보려면 이미지를 클릭하십시오.)
보호된 프로세스인 audiodg가 표시된 작업 관리자
보호된 프로세스인 audiodg가 표시된 작업 관리자 (더 크게 보려면 이미지를 클릭하십시오.)

주소 공간 로드 불규칙화
데이터 실행 방지 및 향상된 컴파일러 오류 검사와 같은 대책에도 불구하고 맬웨어 작성자는 Internet Explorer®, Windows 서비스 및 타사 응용 프로그램과 같은 네트워크 관련 프로세스를 감염시켜 시스템 침투의 발판을 만들 수 있는 버퍼 오버플로 취약점을 파악하기 위해 계속 시도합니다. 그러나 프로세스를 감염시키더라도 사용자 데이터를 읽거나 사용자 또는 시스템 구성 설정을 수정하여 영구적인 침투 경로를 만드는 궁극적 목표를 달성하려면 Windows API를 사용할 수밖에 없습니다.
응용 프로그램을 DLL에서 내보낸 API 진입점과 연결하는 작업은 운영 체제 로더가 처리하는 것이 일반적이지만 이러한 유형의 맬웨어 감염은 로더 서비스를 이용하지 못합니다. 이전 버전의 Windows에서는 시스템 실행 가능 이미지와 DLL이 항상 동일한 위치에서 로드됩니다. 따라서 맬웨어는 API가 고정된 주소에 있는 것으로 가정할 수 있으므로 문제가 발생할 수 있었습니다.
하지만 Windows Vista의 ASLR(주소 공간 로드 불규칙화) 기능은 시스템이 부팅될 때마다 각기 다른 위치에서 시스템 DLL과 실행 파일을 로드하기 때문에 맬웨어가 API의 위치를 알아내는 것이 불가능합니다. 부팅 프로세스의 초기 단계에서 메모리 관리자가 사용자 모드 주소 공간 위쪽의 16MB 영역에 있는 256개의 64KB 정렬 주소 중 하나에서 임의의 DLL 이미지 로드 바이어스를 선택합니다. 이미지 헤더에 새로운 동적 재할당 플래그가 있는 DLL이 프로세스에 로드되면 메모리 관리자는 해당 이미지 로드 바이어스 주소에서 시작하여 이러한 DLL을 메모리에 압축합니다.
플래그가 설정된 실행 파일도 비슷하게 처리되어 이미지 헤더에 저장된 16MB의 기본 로드 주소 내에서 임의의 64KB 정렬 지점으로 로드됩니다. 또한 해당 DLL이나 실행 파일이 모든 프로세스에 의해 해제된 후 다시 로드되더라도 메모리 관리자는 로드할 위치를 무작위로 다시 선택합니다. 그림 7에서는 ASLR이 이미지 로드 바이어스와 실행 파일 로드 주소를 선택하는 영역을 포함하여 32비트 Windows Vista 시스템의 주소 공간 레이아웃 예제를 보여 줍니다.
그림 7 ASLR이 실행 파일 및 DLL 로드 주소에 미치는 영향
그림 7 ASLR이 실행 파일 및 DLL 로드 주소에 미치는 영향 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 ASLR이 실행 파일 및 DLL 로드 주소에 미치는 영향
그림 7 ASLR이 실행 파일 및 DLL 로드 주소에 미치는 영향 (더 크게 보려면 이미지를 클릭하십시오.)
레거시 이미지를 이동하면 이미지 로드 위치에 대해 개발자가 세운 가정과 어긋나게 되므로 모든 Windows Vista DLL과 실행 파일을 포함하는 동적 재할당 플래그가 있는 이미지만 위치가 다시 지정됩니다. Visual Studio® 2005 SP1에서는 타사 개발자가 ASLR을 충분히 활용할 수 있도록 플래그 설정을 추가로 지원합니다.
DLL 로드 주소를 256개의 위치 중 하나로 불규칙화하더라도 맬웨어가 API의 정확한 위치를 전혀 추측할 수 없는 것은 아니지만 네트워크 웜의 전파 속도를 크게 낮출 수 있으며, 시스템을 감염시킬 기회가 한 번뿐인 맬웨어의 정상적 작동을 차단할 수 있습니다. 또한 ASLR의 위치 재할당 방법을 사용하면 주소 공간이 이전 버전의 Windows에 비해 더 강력하게 압축되므로 메모리 여유 공간을 더 많이 확보하여 지속적으로 메모리를 할당할 수 있으며 메모리 관리자가 주소 공간 레이아웃을 추적하기 위해 할당하는 페이지 테이블의 수를 줄일 수 있고 TLB(Translation Lookaside Buffer) 실패를 최소화할 수 있는 추가적인 이점도 얻을 수 있습니다.

서비스 보안 향상
Windows 서비스는 맬웨어가 자주 공격하는 대상입니다. 많은 수의 Windows 서비스가 해당 기능에 대한 네트워크 액세스를 허용하기 때문에 시스템에 대한 원격 액세스가 악용될 가능성이 있으며, 대부분의 서비스가 표준 사용자 계정보다 많은 권한의 계정으로 실행되기 때문에 맬웨어에 감염되면 로컬 시스템에서 권한이 승격될 위험성이 있습니다. 이러한 이유 때문에 Windows에서는 Windows XP SP2부터 서비스에 할당된 권한과 액세스 권한을 해당 서비스의 역할에 필요한 것으로 제한하기 시작했습니다. 예를 들어 Windows XP SP2에서는 이전에는 서비스 실행에 항상 사용되던 계정(로컬 시스템)이 사용할 수 있는 권한의 일부만 포함된 로컬 서비스 및 네트워크 서비스 계정이 도입되었습니다. 이를 통해 공격자가 서비스를 악용할 때 획득할 수 있는 액세스 권한이 최소화됩니다.
ASLR 실제 적용
Sysinternals의 Process Explorer와 같은 도구를 사용하여 서로 다른 두 가지 부팅 세션에서 프로세스의 DLL 로드 주소를 비교하면 ASLR의 이점을 쉽게 확인할 수 있습니다. 서로 다른 두 세션에서 가져온 다음 두 스크린 샷에서 Ntdll.dll은 처음에는 주소 0x77A30000에서 Explorer에 로드되고 다음에는 주소 0x77750000에서 로드됩니다.
ntdll.dll의 서로 다른 기본 주소
ntdll.dll의 서로 다른 기본 주소 (더 작게 보려면 이미지를 클릭하십시오.)
ntdll.dll의 서로 다른 기본 주소
ntdll.dll의 서로 다른 기본 주소 (더 크게 보려면 이미지를 클릭하십시오.)
ntdll.dll의 서로 다른 기본 주소
ntdll.dll의 서로 다른 기본 주소 (더 작게 보려면 이미지를 클릭하십시오.)
ntdll.dll의 서로 다른 기본 주소
ntdll.dll의 서로 다른 기본 주소 (더 크게 보려면 이미지를 클릭하십시오.)

이전 기사에서 필자는 서비스가 어떻게 자체 세션에서 다른 사용자 계정과 격리되어 실행되는지 설명했지만 Windows Vista에서는 파일, 레지스트리 키 및 대부분의 서비스에 할당하는 방화벽 포트에 대한 권한과 액세스 권한을 더 제한하여 최소 권한이라는 원칙을 더욱 폭넓게 적용합니다. Windows Vista에서는 각 서비스에 고유한 서비스 SID(보안 식별자)라는 새로운 그룹 계정을 정의합니다. 서비스는 자신의 리소스에 사용 권한을 설정하여 해당 서비스 SID만 액세스할 수 있도록 하고 서비스가 공격을 받더라도 동일한 사용자 계정에서 실행되고 있는 다른 서비스가 액세스 권한을 얻지 못하도록 할 수 있습니다. 그림 8에서 볼 수 있는 것처럼 sc showsid 명령과 서비스 이름을 사용하여 서비스의 SID를 확인할 수 있습니다.
그림 8 서비스 SID 보기
그림 8 서비스 SID 보기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 8 서비스 SID 보기
그림 8 서비스 SID 보기 (더 크게 보려면 이미지를 클릭하십시오.)
서비스 SID는 특정 서비스가 소유한 리소스에 대한 액세스를 보호하지만 기본적으로 서비스는 해당 서비스를 실행하는 사용자 계정이 액세스할 수 있는 모든 개체에 대해 액세스 권한을 가집니다. 예를 들어 로컬 서비스 계정에서 실행되는 서비스는 서비스 SID를 참조하는 사용 권한으로 개체를 보호하는 다른 프로세스에서 로컬 서비스로 실행되는 다른 서비스가 만든 리소스에는 액세스할 수 없지만, 로컬 서비스 및 서비스 그룹과 같이 로컬 서비스가 속하는 모든 그룹이 사용 권한을 갖고 있는 모든 개체를 읽고 쓸 수 있습니다.
따라서 Windows Vista에서는 서비스 SID, Everyone 그룹 및 로그온 세션에 할당된 SID에 액세스할 수 있는 개체에만 서비스 쓰기 액세스 권한을 허용하는, 쓰기가 제한된 서비스라고 하는 새로운 유형의 제한된 서비스를 사용합니다. 이를 위해 Windows 2000에 도입된 SID 유형인 제한된 SID가 사용됩니다. 개체를 여는 프로세스가 쓰기가 제한된 서비스인 경우 제한된 형식과 제한되지 않은 형식 모두에서 프로세스에 할당되지 않은 SID가 프로세스에 개체에 대한 쓰기 액세스 권한을 부여하는 데 사용될 수 없도록 액세스 검사 알고리즘이 변경됩니다. 다음 명령을 사용하여 서비스가 제한되었는지 확인할 수 있습니다.
sc qsidtype [service]
또한 서비스가 자신이 만든 개체에 대해 동일한 계정에서 실행되는 다른 서비스가 액세스 권한을 갖는 것을 쉽게 차단할 수 있도록 변경되었습니다. 이전 버전의 Windows에서는 개체의 작성자가 곧 개체의 소유자이고 소유자는 자신이 만든 개체의 사용 권한을 읽고 변경할 수 있기 때문에 자신의 개체에 대해 모든 권한을 가집니다. Windows Vista에서는 새로운 소유자 권한 SID가 추가되었습니다. 개체의 사용 권한에 이 소유자 권한 SID가 있으면 소유자가 자신의 개체에 대해 갖는 액세스 권한을 제한할 수 있으며 사용 권한을 설정하고 쿼리하는 권한을 제거할 수도 있습니다.
Windows Vista에서는 서비스 보안 모델이 더욱 향상되었기 때문에 서비스 개발자는 서비스가 시스템에 등록될 때 서비스의 작동에 필요한 보안 권한을 정확하게 지정할 수 있습니다. 예를 들어 서비스가 감사 이벤트를 생성해야 하는 경우 감사 권한을 나열할 수 있습니다.
서비스 제어 관리자는 하나 이상의 Windows 서비스를 호스팅하는 프로세스를 시작할 때 프로세스의 서비스에 필요한 권한만 포함된 프로세스용 보안 토큰을 만듭니다. 여기서 보안 토큰이란 프로세스 사용자 계정, 그룹 구성원 및 보안 권한을 나열하는 커널 개체입니다. 서비스가 해당 서비스가 실행되는 계정에서 사용할 수 없는 권한을 지정하면 서비스가 시작되지 않습니다. 예를 들어 로컬 서비스 계정에서 실행되는 서비스 중 프로그램 디버깅 권한이 필요한 서비스가 없는 경우 서비스 제어 관리자는 프로세스의 보안 토큰에서 해당 권한을 제거합니다. 따라서 서비스 프로세스가 공격을 받은 경우에도 악성 코드는 프로세스에서 실행되고 있는 서비스가 명시적으로 요청하지 않은 권한을 사용할 수 없습니다. sc qprivs 명령을 사용하면 서비스가 요청한 권한을 볼 수 있습니다.

결론
지금까지 3회에 걸쳐 Windows Vista 커널의 변경 내용에 대해 살펴봤습니다. 응용 프로그램 개발자를 위한 새로운 작업자 스레드 풀, 공유 판독기/기록기 잠금과 같은 새로운 동기화 메커니즘, 서비스 스레드 태그 지정, 온라인 NTFS 디스크 검사 및 볼륨 크기 조정의 지원 및 ALPC(Advanced Local Procedure Call)라고 하는 새로운 커널 IPC 메커니즘 등과 같이 기사에서 설명하거나 언급하지 않은 기능이나 구현 기술도 있습니다. 이러한 항목과 기타 기능에 대한 자세한 내용은 2007년 말 발간 예정인 Windows Internals의 새 버전에서 자세히 다루겠습니다.
쓰기 제한된 서비스 보기
Windows Vista에서 하나의 서비스 호스팅 프로세스만 제한된 서비스를 호스팅할 수 있으며 다음 명령줄을 사용할 수 있는 Process Explorer와 같은 프로세스 보기 도구로 이를 확인할 수 있습니다.
svchost -k LocalServiceNoNetwork
이 프로세스에서 실행하도록 구성된 서비스로는 기본 필터링 엔진, 진단 정책 서비스, Windows 방화벽, 성능 로그 및 경고, Windows Media® Center Service Starter 등이 있습니다.
이 화면에서는 기본 필터링 엔진의 서비스 SID인 NT SERVICE\BFE의 텍스트 형태를 제한됨 플래그가 있는 상태와 없는 상태에서 보여 줍니다. 없는 상태에서 이 프로세스는 해당 계정에서 액세스 가능한 리소스에 대해 액세스 권한을 가집니다. 하지만 일반적으로 로컬 서비스 계정이 액세스할 수 있는 다른 개체에는 액세스할 필요가 없습니다. 예를 들어 NT AUTHORITY\SERVICE 계정은 제한됨 플래그가 있는 프로세스 토큰에 나타나지 않기 때문에, 프로세스는 해당 계정에만 쓰기 액세스 권한이 부여되었고 제한됨 플래그가 있는 토큰의 다른 계정에는 부여되지 않은 개체를 수정할 수 없습니다.
속성 대화 상자 아래쪽에 나열된 권한이 로컬 서비스 계정에 사용 가능한 권한의 일부이기 때문에 이 프로세스에서 실행되는 서비스는 권한도 제한됩니다.
서비스의 SID 플래그
서비스의 SID 플래그 (더 작게 보려면 이미지를 클릭하십시오.)
서비스의 SID 플래그
서비스의 SID 플래그 (더 크게 보려면 이미지를 클릭하십시오.)

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


 Windows Administration: 재해 복구: Active Directory 사용자 및 그룹
Windows Administration Gil Kirkpatrick

재해 복구: Active Directory 사용자 및 그룹
한 눈에 보기:
  • 복제 및 개체 연결의 원리
  • NTDSUTIL을 사용한 백업 및 복원
  • 권한 있는 복원과 권한 없는 복원

Active Directory는 Windows 네트워크에서 가장 중요한 서비스 중 하나입니다. 작동 중단과 생산성 손실을 방지하기 위해서는 Active Directory 관련 문제에 대해 효과적인 재해 복구 계획을 마련해 놓아야 합니다. 이것은 당연한 소리로 들리지만 사실상 놀라울 정도로 많은 관리자가
가장 흔하게 발생하는 Active Directory® 오류 시나리오라 할 수 있는 '실수로 인한 데이터 삭제'에 대비해 별다른 계획을 갖고 있지 않습니다.
실수로 인한 개체 삭제는 서비스 실패를 유발하는 가장 흔한 원인 중 하나입니다. 필자는 세미나와 컨퍼런스를 진행할 때 실수로 인한 데이터 삭제로 Active Directory 장애를 경험한 사람이 있는지 자주 묻는데 항상 거의 모든 사람이 손을 듭니다.
데이터 복구 작업이 왜 그토록 복잡한지 그 이유를 알기 위해서는 먼저 Active Directory가 개체를 저장, 복제 및 삭제하는 방식과 권한 있는 복원 및 권한 없는 복원의 원리를 이해할 필요가 있습니다.

개체 저장
Active Directory는 X.500/LDAP 데이터 모델을 구현하는 특수한 개체 데이터베이스입니다. DIT(디렉터리 정보 트리)라고 하는 데이터 저장소는 ISAM(Indexed Sequential Access Method) 데이터베이스 엔진인 ESE(Extensible Storage Engine)를 기반으로 합니다. 개념상으로 Active Directory는 DIT를 두 개의 테이블에 저장합니다. 즉, 실제 Active Directory 개체와 특성을 포함하는 데이터 테이블과 개체 간의 관계를 포함하는 연결 테이블로 나누어 저장하는 것입니다.
각 Active Directory 개체는 데이터 테이블에서 별도의 행으로 저장되며 각 열은 개별 특성에 해당합니다. 데이터 테이블에는 도메인 컨트롤러(DC)에 저장된 전체 복제본의 모든 항목이 포함됩니다. 일반적인 DC의 경우에는 도메인 NC(명명 컨텍스트), 구성 NC 및 스키마 NC의 항목이 데이터 테이블에 포함되며, 글로벌 카탈로그의 경우에는 포리스트의 각 개체에 대한 항목이 데이터 테이블에 포함됩니다.
Active Directory는 32비트 정수인 고유 이름 태그(DNT)를 사용하여 데이터 테이블의 각 행을 식별합니다. 내부적으로 개체를 참조하는 데 사용되는 이 DNT는 고유 이름(DN)이나 objectGUID(16바이트 바이너리 구조) 등의 다른 식별자에 비해 크기가 훨씬 작지만 objectGUID와 달리 로컬 식별자이며 각 DC마다 다릅니다.

Active Directory의 개체 연결 방식
Active Directory는 DIT에 있는 개체 간의 관계 중 두 가지 유형, 즉 컨테이너 관계라고 하는 부모-자식 관계와 연결 관계라고 하는 참조 관계를 관리합니다. 부모-자식 관계를 구현하려는 경우 Active Directory는 데이터 테이블에 부모 고유 이름 태그(PDNT)라는 추가 열을 저장합니다. 이 열은 항상 개체의 부모에 해당하는 DNT를 포함합니다.
Active Directory의 각 특성은 Active Directory 스키마 컨테이너에 있는 attributeSchema 개체에 의해 정의됩니다. Active Directory에서 일부 특성은 attributeSchema 개체의 linkID 특성에 지정된 0이 아닌 짝수 값으로 결정되는 연결 특성으로 정의됩니다. 연결 특성은 디렉터리에 있는 개체 간의 관계를 설정하며 단일값이거나 다중값일 수 있습니다. 그룹 개체의 구성원 특성은 다중값 연결 특성의 예로서, 그룹 개체와 해당 구성원 개체 간의 연결을 설정합니다.
예를 들어 Active Directory 사용자 및 컴퓨터 스냅인에 표시되는 것처럼, 그룹의 구성원 특성에 구성원의 DN이 포함되어 있는 것처럼 보여도 이것은 Active Directory의 저장 방식이 아닙니다. 관리자가 구성원 개체의 DN을 그룹의 구성원 특성에 추가할 때 Active Directory는 개체의 DN이 아닌 DNT를 저장합니다. 개체 이름이 바뀌어도 DNT는 변경되지 않기 때문에 관리자가 사용자 개체의 이름을 바꿀 수 있고 Active Directory는 각 구성원 특성의 DN을 업데이트하기 위해 시스템의 모든 그룹을 정렬할 필요가 없습니다. Active Directory는 바로 이런 방식으로 DIT 내의 참조 무결성을 유지합니다. 그림 1은 데이터 테이블과 연결 테이블이 서로 연관되는 방식을 간단하게 나타낸 것입니다. 이 테이블에서는 Molly Clark, Alexander Tumanov 및 Makoto Yamagishi라는 세 개의 사용자 개체가 모두 Senior Engineers 그룹의 구성원임을 알 수 있습니다.
Figure 1 데이터 테이블과 연결 테이블이 서로 연관되는 방식 (Close Figure 1)

데이터 테이블 |  |  |
DNT | PDNT | 개체 클래스 | Cn
14529 | 14401 | organizationalUnit | Engineers
14530 | 14529 | 그룹 | Senior Engineers
14531 | 14529 | 사용자 | Molly Clark
14532 | 14529 | 사용자 | Alexander Tumanov
14533 | 14529 | 사용자 | Makoto Yamagishi
연결 테이블 |  |  |
특성 | DNT | 정방향 연결 |
구성원 | 14530 | 14531 |
구성원 | 14530 | 14532 |
구성원 | 14530 | 14533 |
이러한 연결을 정방향 연결이라고 합니다. Active Directory는 역방향 연결 특성도 제공합니다. 이런 특성은 연결 대상 개체가 참조를 수행하는 개체(정방향 연결이 있는 개체)를 역방향으로 참조할 수 있게 합니다. 사용자와 그룹에 대한 memberOf 특성은 이런 역방향 연결 특성의 한 예입니다. 역방향 연결 특성을 설명하는 attributeSchema 개체의 linkID 값은 짝수 값인 해당 정방향 연결 특성의 linkID 값에 1을 더한 값입니다. 예를 들어 Windows Server® 2003 R2 스키마에서 구성원 특성의 linkID 값이 2인 경우, 역방향 연결을 수행하는 memberOf 특성의 linkID 값은 3입니다. 그림 2에는 Windows Server 2003 R2 스키마에 기본적으로 정의되어 있는 연결된 특성의 목록이 나와 있습니다.
Figure 2 Windows Server 2003 R2 스키마의 연결 특성 (Close Figure 2)

정방향 연결 특성 | linkID | 역방향 연결 특성 | 연결된
구성원 | 2 | memberOf | 3
관리자 | 42 | directReports | 43
소유자 | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
역방향 연결 특성은 항상 다중값이며 Active Directory에 의해 자동으로 유지 관리됩니다. 사실상 역방향 연결 특성은 직접 수정할 수가 없습니다. Active Directory 사용자 및 컴퓨터 MMC 스냅인을 통해 사용자나 그룹의 memberOf 특성을 수정할 수 있는 것처럼 보여도 이 스냅인은 실제로 해당 그룹의 구성원 특성을 수정하는 것이며 Active Directory가 배후에서 memberOf 특성을 업데이트하는 것입니다. 따라서 사용자를 그룹에 추가하는 데 해당 사용자 개체에 대한 권한은 필요 없습니다. 사실상 그룹 개체의 구성원 특성을 수정하는 것이기 때문입니다. 각 DC는 역방향 연결 특성을 로컬로 관리하므로 역방향 연결에 대한 변경 사항은 절대 복제되지 않고, 그룹의 구성원 특성과 같은 정방향 연결 특성에 대한 변경 사항만 복제됩니다.
일반적인 DC의 경우 데이터 테이블에는 구성 및 스키마 컨테이너의 개체는 물론 도메인 개체의 항목이 포함됩니다. 그러나 일부 그룹 유형은 다른 도메인에 상주하는 개체에 대한 참조도 포함할 수 있습니다. 그렇다면 Active Directory는 해당 데이터 테이블에 없는 개체의 DNT는 어떻게 저장할까요? 그 해답은 인프라 마스터의 신축 단일 마스터 작업(FSMO) 역할 소유자와 유령 개체라는 것에서 찾을 수 있습니다.

유령 개체
특정 도메인의 구성원을 다른 도메인의 그룹에 추가하면 Active Directory가 데이터 테이블에 유령 개체를 자동으로 생성합니다. 이 특수한 개체에는 추가된 새 구성원의 objectGUID, objectSid 및 DN이 포함되어 있습니다. 이 개체는 또한 그룹의 구성원 특성에 저장할 수 있는 DNT를 제공합니다. 그러나 도메인 컨트롤러가 글로벌 카탈로그인 경우에는 데이터 테이블에 포리스트의 각 개체에 대한 항목이 이미 존재하기 때문에 유령 개체를 생성할 필요가 없습니다.
인프라 FSMO 역할을 보유한 DC는 글로벌 카탈로그를 기반으로 데이터 테이블의 항목을 정기적으로 검사하여 이동 또는 삭제되거나 이름이 변경된 개체가 발견되면 데이터 테이블의 유령 개체를 업데이트하고 도메인의 다른 DC에 변경 사항을 복제합니다. 또한 인프라 마스터는 참조 횟수를 사용하여 도메인의 어떠한 정방향 연결 특성도 더 이상 참조하지 않는 유령 개체를 제거할 수 있습니다.
DC는 유령 개체를 사용하여 포리스트 내의 다른 도메인에 있는 개체에 대한 참조를 관리할 수 있지만, 정방향 연결 특성은 트러스트된 도메인과 같이 포리스트 외부에 있는 개체도 참조할 수 있습니다. 이런 경우 Active Directory는 도메인 NC의 CN=ForeignSecurityPrincipals 컨테이너에 외부 보안 정책(FSP)이라는 개체를 생성합니다. 이 FSP에는 외부 개체의 보안 식별자(SID)를 비롯하여 외부 도메인의 해당 개체를 식별하는 기타 특성이 들어 있지만 FSP를 최신 상태로 업데이트하는 프로세스는 없습니다. 데이터 복구의 관점에서는 FSP가 다른 Active Directory 개체와 똑같이 취급됩니다.

개체 삭제
여기에서는 사용자와 사용자의 그룹 구성원 자격을 복원하는 것에 대해 주로 설명하지만 다른 연결된 특성을 복구하는 경우에도 동일한 원리가 적용됩니다.
Active Directory가 개체를 삭제할 때 이 개체는 DIT에서 물리적으로 삭제되는 것이 아닙니다. 개체의 isDeleted 특성을 true로 설정하여 개체가 삭제된 것으로 표시함으로써 일반적인 디렉터리 작업에서 해당 개체가 보이지 않도록 하는 것입니다. Active Directory는 스키마의 정의에 따라, 저장하도록 지정되지 않은 모든 특성을 제거하고 개체의 상대 고유 이름(RDN)을 <old RDN>\0aDEL:<objectGUID>로 변경합니다. 그런 다음 해당 개체를 NC의 CN=Deleted Objects 컨테이너로 이동합니다.참고로, 구성 NC에는 Active Directory가 삭제된 개체 컨테이너로 이동하지 않는 몇 가지 개체 클래스가 있습니다. Active Directory는 삭제된 개체가 보유하는 다른 개체에 대한 모든 정방향 연결을 삭제하며, 이에 따라 연결 테이블의 참조 횟수도 줄어들게 됩니다. 그리고 삭제된 개체에 대한 정방향 연결이 포함된 다른 개체가 있으면 Active Directory는 이러한 연결도 제거합니다.
그 결과로 나타난 개체를 삭제 표시라고 합니다. Active Directory는 이런 삭제 표시를 다른 DC에 복제하여 똑같은 변경 사항이 적용되도록 합니다. 그러나 Active Directory는 삭제된 개체를 참조하는 정방향 연결에 대한 변경 사항은 복제하지 않습니다. 각 DC는 해당 변경 사항을 로컬에서 수행하므로 복제 작업이 필요 없습니다. 이런 사실은 그룹 구성원 자격을 복구하는 데 중대한 영향을 미칩니다. 이에 대해서는 이 문서의 뒷부분에서 자세히 다룰 것입니다.
Active Directory는 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 개체의 tombstoneLife 특성에 따라 삭제 표시를 DIT에서 유지 관리합니다. 각 DC의 가비지 수집 프로세스는 구성된 삭제 표시 유효 기간을 초과하는 삭제 표시를 제거합니다. 기본적으로 삭제 표시 유효 기간은 Windows® 2000, Windows Server 2003 및 Windows Server 2003 R2의 경우 60일이고, Windows Server 2003 SP1의 경우 180일입니다.
삭제 표시 유효 기간은 복원 프로세스에 매우 중요한 영향을 미칩니다. 예를 들어 삭제 표시 유효 기간을 초과한 백업에서는 복원이 불가능합니다. 이것은 삭제된 후 도메인에서 가비지 수집된 개체에는 더 이상 삭제 표시가 나타나지 않으므로 삭제 작업이 복원된 DC에 다시 복제되지 않기 때문입니다. 따라서 삭제된 개체는 복원된 DC에 느린 개체로 남아 있게 되며 이 복원된 DC는 도메인의 다른 DC와 올바르게 통합되지 않습니다.

개체 복제
도메인 컨트롤러는 개체를 추가하거나 특성을 수정하는 등의 업데이트 작업을 수행할 때마다 업데이트 시퀀스 번호(USN)라는 64비트 고유 번호를 해당 업데이트 작업에 할당합니다. 그리고 Active Directory는 업데이트된 개체와 특성에 이 USN을 태그로 표시하므로 업데이트된 항목의 복제가 필요한지 여부를 쉽게 알 수 있습니다.
Active Directory는 개체를 특성별로 복제합니다. 즉, 개체의 특성을 수정하면 Active Directory가 전체 개체가 아닌 해당 특성만 복제합니다. 이를 위해 Active Directory는 복제 메타데이터를 사용하여 각 특성에 대한 변경 사항을 추적합니다. 특성에 대한 복제 메타데이터에는 다음과 같은 항목이 포함되어 있습니다.
  • 로컬 DC에 대한 변경 작업을 나타내는 로컬 USN
  • 도메인 컨트롤러에서 특정 DIT 생성을 식별하는, 변경을 유발한 DC의 invocationID(특히 DC의 해당 nTDSSettings 개체가 보유한 invocationID 특성)
  • 원래 DC에서와 같은 원래 작업의 USN
  • 원래 변경 작업이 수행된 DC 시스템 시간을 포함하는 타임스탬프
  • 값이 변경될 때마다 증가되는 순차적인 32비트 버전 번호
대상 DC는 원본 DC 파트너에 수행된 변경 사항을 요청할 때 가장 최근에 성공적으로 복제된 변경 사항의 USN을 원본 DC로 전송합니다. 이때 NC 복제본을 생성하는 각 DC의 원래 USN 중에서 가장 큰 값을 포함하는 최신 벡터도 함께 전송합니다. 원본 DC는 이 정보를 사용하여 대상 DC가 확인하지 못한 업데이트만 전송합니다.
대상 DC는 들어오는 특성 업데이트를 처리할 때 각 특성의 버전 번호를 검사합니다. 그래서 들어오는 특성의 버전 번호가 DC가 갖고 있는 해당 특성의 버전보다 크면 이 값을 저장합니다. 만약 들어오는 버전 번호가 DC가 이미 갖고 있는 버전과 같을 경우, DC는 타임스탬프를 비교하여 최신 타임스탬프를 가진 특성을 사용합니다. 그런데 타임스탬프마저 같으면 대상 DC는 invocationID가 가장 큰 값을 선택합니다. 이런 방식으로 인해 모든 DC는 복제된 모든 특성에 대해 결국 같은 값을 갖게 됩니다.

연결된 값 복제
Windows 2000에서 Active Directory는 다중값 특성을 단일값 특성과 같은 방식으로 복제했습니다. 그러나 이런 방식은 다중값 구성원 특성이 다른 DC에서 자주 변경될 수 있는 대규모 동적 그룹 개체에서 문제를 일으켰습니다. 즉, 어떤 관리자가 한 DC에서 그룹에 사용자를 추가했는데 다른 관리자가 복제 대기 시간 내에 다른 DC에서 동일한 그룹에 다른 사용자를 추가한 경우, Active Directory는 나중에 추가된 사용자를 선택하고 먼저 추가된 사용자는 완전히 놓치게 됩니다. Microsoft는 연결된 값 복제(LVR)라는 프로세스를 사용하여 Windows Server 2003에서 이 문제를 해결했습니다.
Active Directory는 Windows Server 2003 포리스트 기능 수준 또는 임시 포리스트 기능 수준을 사용하여 다중값 정방향 연결 특성의 개별 값을 하나씩 복제하며 이때 각 값은 고유의 복제 메타데이터를 포함합니다. 따라서 여러 DC에 그룹 구성원 자격 업데이트를 거의 동시에 수행할 때 데이터가 손실될 수 있는 Windows 2000에서의 문제가 효과적으로 해결되는 것입니다.
그러나 한 가지 알아야 할 점이 있습니다. 즉, 포리스트 기능 수준을 높여도 새로운 복제 메타데이터로 기존의 다중값 연결 특성을 자동으로 수정할 수는 없다는 것입니다. 포리스트 기능 수준을 높인 후에 추가된 값만 새 메타데이터를 갖게 됩니다. 잠시 후에 살펴보겠지만 이런 사실은 그룹 구성원 자격을 복구하는 데 중요한 영향을 미칩니다.

백업
Windows에는 매우 기본적인 NTBACKUP 유틸리티가 포함되어 있습니다. 이 유틸리티는 DC의 시스템 상태 백업을 수행하는 데 사용할 수 있습니다. 도메인 컨트롤러의 시스템 상태는 레지스트리, SYSVOL, Active Directory DIT 파일 및 중요한 시스템 파일을 포함합니다. 또한 대부분의 타사 백업 유틸리티도 DC의 시스템 상태를 백업 및 복원할 수 있습니다.
디스크 파일에 시스템 상태를 백업하려면 다음 명령을 사용하십시오.
NTBACKUP backup systemstate /F “<filename>”
여기서 <filename>은 생성할 백업 파일의 이름이며 확장명은 .bkf여야 합니다.

권한 없는 복원 수행
백업을 사용하여 삭제된 Active Directory 개체를 복원하는 작업은 2단계 프로세스입니다. 먼저 DC를 디렉터리 서비스 복원 모드(DSRM)로 다시 부팅한 다음 Windows NTBACKUP 유틸리티나 동등한 타사 제품을 사용하여 시스템 상태 백업에서 전체 Active Directory DIT를 복원합니다. 이 프로세스는 전체 DIT를 덮어씁니다.
DC를 DSRM으로 부팅하는 데는 두 가지 방법이 있습니다. DC의 시스템 콘솔에 액세스할 수 있는 경우 DC를 종료하고 다시 시작하면서 Windows 부팅 메뉴가 표시될 때 F8 키를 누르십시오. 그런 다음 메뉴에서 디렉터리 서비스 복원을 선택하고 DSRM 암호를 입력하면 됩니다.
서버를 원격으로 관리하는 경우에는 Windows 부팅 메뉴에 액세스할 수 없습니다. 대신 내 컴퓨터에서 속성을 선택하고, 고급 탭을 클릭한 후 시작 및 복구 아래의 설정 단추를 눌러 시스템 부팅 옵션을 변경할 수 있습니다. 그림 3과 같이 시스템 시작 섹션의 편집 단추를 눌러 boot.ini 파일을 편집하고 줄 끝에 스위치 /SAFEBOOT:DSREPAIR을 추가하면 됩니다. boot.ini 스위치에 대한 자세한 내용은 microsoft.com/technet/ sysinternals/information/bootini.mspx를 참조하십시오.
그림 3 DSRM에 대한 부팅 옵션 설정
그림 3 DSRM에 대한 부팅 옵션 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 DSRM에 대한 부팅 옵션 설정
그림 3 DSRM에 대한 부팅 옵션 설정 (더 크게 보려면 이미지를 클릭하십시오.)
서버를 다시 부팅하면 이제 DSRM 모드로 부팅됩니다. DC를 표준 모드로 다시 시작하려는 경우에는 boot.ini에서 /SAFEBOOT 스위치를 제거해야 합니다.
DSRM 암호를 사용하여 로그인했으면 매개 변수는 지정하지 않고 NTBACKUP 명령을 다시 사용하여 시스템 상태 백업을 복원하십시오(명령줄에서 NTBACKUP을 사용하여 복원을 수행할 수는 없음). 마법사가 나타나면 파일 및 설정 복원을 선택하고 다음을 클릭합니다. 그런 다음 해당 백업 파일을 선택하고 그림 4와 같이 시스템 상태 확인란을 선택합니다.
그림 4 백업 또는 복원 마법사를 사용하여 시스템 상태 복원
그림 4 백업 또는 복원 마법사를 사용하여 시스템 상태 복원 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 백업 또는 복원 마법사를 사용하여 시스템 상태 복원
그림 4 백업 또는 복원 마법사를 사용하여 시스템 상태 복원 (더 크게 보려면 이미지를 클릭하십시오.)
이때 도메인 컨트롤러(DC)를 다시 표준 모드로 부팅하려고 하면 Active Directory 복제 프로세스가 복원된 도메인 컨트롤러를 도메인의 다른 DC와 다시 동기화하며 최신 데이터가 복원된 모든 데이터를 덮어씁니다. 물론 이런 결과는 원하지 않으시겠지요? 따라서 복원되는 개체가 도메인의 다른 DC로 복제되도록 강제할 방법이 필요합니다.

권한 있는 복원 수행
NTDSUTIL 또한 백업일과 복원일 사이에 매일 100,000씩 각 특성의 버전 번호를 높입니다. 따라서 매일 100,000번 이상 업데이트되는(거의 가능성 없음) 특성이 없으면 복원된 특성의 버전 번호는 다른 DC가 보유한 버전 번호보다 훨씬 높으며 이렇게 권한 있는 복원이 수행된 개체는 다른 DC로 복제됩니다. 권한 없이 백업으로 복원한 기타 개체는 다른 도메인 컨트롤러(DC)의 기존 데이터가 결국 덮어쓰게 됩니다.
권한 없는 복원을 완료했으면 표준 모드로 다시 부팅하기 전에 NTDSUTIL 프로그램을 사용하여 복구하려는 개체에 대해 권한 있는 복원을 수행하십시오. 이름과 달리, 권한 있는 개체 복원은 개체를 정말 "복원"하는 것이 아니라 Active Directory가 해당 개체를 다른 DC로 복제하도록 보장할 뿐입니다. 이 작업을 위해 NTDSUTIL은 다음으로 사용 가능한 USN을 해당 개체의 특성에 해당하는 로컬 USN에 지정합니다. 따라서 이 개체는 다음 동기화 수행 시 복제 파트너로 전송됩니다. 단일 개체를 복원하려면 DC가 DSRM 모드로 부팅하도록 하고 다음 단계를 수행하십시오.
  1. 명령 창을 열고 다음을 입력합니다.
    ntdsutil
  2. ntdsutil 프롬프트에서 다음을 입력합니다.
    authoritative restore
  3. 권한 있는 복원 프롬프트에서 다음을 입력합니다.
    restore object “<DN of object to be restored>”
    예를 들어 DRNET 도메인의 Eng OU에서 Molly Clark 계정을 복원하려면 다음을 입력합니다.
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    전체 디렉터리 하위 트리(예: OU)에 대해 권한 있는 복원을 수행하려면 대신 다음을 입력합니다.
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    NTDSUTIL도 구성 및 스키마 NC를 포함하여 전체 도메인에 대해 권한 있는 복원을 수행하는 데이터베이스 복원 명령을 제공합니다. 전체 도메인을 복원하는 일은 위험 부담이 너무 크기 때문에 이 옵션은 권장하고 싶지 않습니다. 전체 도메인을 복원해야 하는 경우에는 "Active Directory 포리스트 복구를 위한 계획에 나온 설명과 같이 한 개 도메인 컨트롤러를 복원하고 도메인의 다른 DC 수준을 다시 올리십시오.
  4. 메시지가 나타나면 권한 있는 복원이 각 개체와 해당 특성의 버전 번호를 높이도록 합니다.
  5. ntdsutil을 종료합니다(quit을 두 번 입력해야 함).
  6. DC를 표준 Active Directory 모드로 다시 부팅합니다.
다음에 DC가 해당 파트너를 사용하여 복제할 때 복원된 사용자는 외부로 복제됩니다. 그러나 사용자 개체를 복원하는 것은 문제의 절반일 뿐입니다. 그룹과 그룹 구성원 간의 연결처럼 개체 연결을 수행하면 상황이 더욱 복잡해집니다. 복원 도중 또는 이후에 발생할 수 있는 몇 가지 근본적인 문제는 조금 후에 설명하겠습니다.
우선 역방향 연결을 포함하는 개체를 삭제했을 때 어떤 일이 발생하는지 살펴봅시다. 예를 들어 한 개 이상의 그룹에 속한 사용자 개체를 삭제할 경우, 이 사용자 개체의 복사본을 가진 각 도메인 컨트롤러는 이 복사본을 삭제 표시로 변환하고 연결 테이블에서 모든 참조를 제거하여 사용자 도메인의 모든 그룹 구성원 자격에서 해당 사용자 개체를 제거합니다. (그룹 구성원 자격에서 사용자를 제거하는 것은 복제된 변경이 아닙니다. 각 DC가 구성원 자격을 로컬로 업데이트하기 때문입니다. 그룹 구성원 특성의 버전 번호와 로컬 USN은 변경되지 않습니다.) 잠시 후 다른 도메인의 연결 테이블에서 유령 개체가 제거됩니다. 이때도 그룹 구성원 특성의 복제 메타데이터는 업데이트되지 않습니다.
사용자 도메인의 도메인 컨트롤러에 있는 DIT에 권한 없는 복원을 수행할 때는 사용자 개체가 도메인의 여러 그룹에 있는 모든 그룹 구성원 자격과 함께 복구되기 때문에 복원된 DC의 일관성이 유지됩니다. 또한 NTDSUTIL 유틸리티를 사용하여 사용자에 대해 권한 있는 복원을 수행하고 나면 해당 사용자 개체가 도메인의 다른 모든 DC로 복제됩니다.
그러나 도메인의 최신 그룹에 속한 복제 메타데이터는 변경되지 않기 때문에 복원된 DC에 있는 그룹의 구성원 특성은 다른 DC의 특성과 일관되지 않습니다. 또한 이러한 특성을 하나의 공통된 상태로 통합할 방법도 없습니다. 따라서 이 사용자의 구성원 자격은 도메인의 다른 DC에서 복원되지 않는 것입니다.

문제: 도메인 내의 그룹 구성원 자격이 복원되지 않음
사용자 개체에 권한 있는 복원을 수행해도 이 사용자의 그룹 구성원 자격이 복구되지 않는 이유는 무엇일까요? 그것은 바로 구성원 자격 관계가 사용자의 memberOf 특성(역방향 연결)이 아니라 그룹 개체의 구성원 특성(정방향 연결)을 사용하여 저장되고 복제되기 때문입니다. 문제는 사용자의 기존 그룹 구성원 자격을 찾아야 하고, 만약 알고 있다면 이를 제대로 복구해야 한다는 것입니다.
Microsoft는 사용자 그룹 구성원 자격의 복구 프로세스를 점진적으로 개선해왔기 때문에 현재 사용하는 Active Directory의 버전에 따라 적용할 기술이 달라집니다. 다음 내용은 Windows 2000 Active Directory에 주로 적용됩니다.
사용자의 기존 그룹 구성원 자격은 매우 쉽게 확인할 수 있습니다. 즉, 복원된 DC에서 역방향 연결 특성을 검사하면 됩니다. 여기서는 사용자 개체의 memberOf 특성이 되겠지요? 이 memberOf 특성은 사용자 도메인의 로컬 및 글로벌 그룹에 대한 모든 구성원 자격을 포함합니다. 이제 Active Directory 사용자 및 컴퓨터 MMC 스냅인(ADUC)을 사용하거나 Windows Server에 포함되어 있는 LDIFDE 유틸리티를 사용하여 복원된 사용자의 그룹 구성원 자격을 나열할 수 있습니다.
다음의 LDIFDE 명령 줄은 Molly Clark가 구성원으로 속해 있는 DRNET 도메인의 그룹을 보여 주며 그 결과를 output.ldf 파일에 저장합니다.
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
LDAP 도구를 사용하려면 DC를 표준 모드로 부팅해야 하고 인바운드 복제도 비활성화해야 합니다. 그렇지 않으면 새 데이터가 복원한 데이터를 덮어씁니다. 인바운드 복제를 비활성화하는 가장 쉬운 방법은 다음과 같은 REPADMIN 명령을 사용하는 것입니다.
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
여기서 <dcname>은 복원이 수행된 DC의 이름입니다. 완료했으면 –DISABLE_INBOUND_REPL을 사용하여 복제를 다시 활성화하는 것도 잊지 마십시오.
복구하려는 사용자 수가 적은 경우에는 ADUC를 사용하여 사용자를 그룹에 다시 추가하는 방법이 제일 간단합니다. 그러나 복구할 사용자 수가 많으면 일부 프로세스를 자동화할 수 있는 몇 가지 도구 중 선택하여 사용하면 됩니다. Microsoft GROUPADD 유틸리티(Microsoft 기술 지원 서비스에서 제공)는 관리자가 사용자의 기존 그룹 구성원 자격을 검색하기 위해 생성한 LDIF 파일을 활용하여 이러한 구성원 자격을 다시 생성하는 LDIF 파일을 만들어 줍니다. 예를 들어 앞의 예에서 Molly Clark를 위해 생성한 LDIF 파일을 다음의 GROUPADD 명령을 사용하여 처리한다고 가정해 봅시다.
C:\> groupadd /after_restore output.ldf
이 명령을 실행하면 Molly Clark가 그룹 구성원 자격을 보유하고 있는 각 도메인에 대해 groupadd_<domain>.ldf라는 이름으로 새로운 LDIF 파일이 생성됩니다. 여기서 <domain>은 업데이트되는 그룹이 속한 도메인의 정규화된 도메인 이름입니다. 이렇게 생성된 LDIF 파일은 다음과 같은 명령으로 가져옵니다.
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Windows Server 2003에서 더욱 향상된 NTDSUTIL은 구성원 특성에 있는 추가 메타데이터를 활용하여 연결된 값 복제(LVR)를 지원합니다. 만약 복원된 사용자 개체가 도메인의 특정 그룹에 속한 구성원이었고 이 사용자의 그룹 구성원 자격이 LVR 메타데이터와 함께 저장된 경우, NTDSUTIL은 이 구성원 특성의 해당 버전 번호 값을 높여 복원된 구성원 자격이 외부로 복제되도록 합니다.
Windows Server 2003 SP1 버전의 NTDSUTIL에는 GROUPADD 기능이 통합되어 있어 사용자 개체에 대해 권한 있는 복원을 수행할 때 LDIF 파일을 자동으로 생성합니다. 그림 5는 이 새로운 버전의 NTDSUTIL을, 그림 6은 자동 생성된 LDIF 파일의 내용을 보여 줍니다.
Figure 6 NTDSUTIL이 생성한 LDIF 파일의 콘텐츠 (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
그림 5 GROUPADD 기능이 내장된 새로운 NTDSUTIL
그림 5 GROUPADD 기능이 내장된 새로운 NTDSUTIL (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 GROUPADD 기능이 내장된 새로운 NTDSUTIL
그림 5 GROUPADD 기능이 내장된 새로운 NTDSUTIL (더 크게 보려면 이미지를 클릭하십시오.)
포함된 사용자와 그룹 수가 많은 OU 전체를 복원하려는 경우 사용자를 해당 그룹에 직접 추가하려면 많은 시간이 소모됩니다. 복원된 그룹 구성원 자격을 복구하는 또 다른 방법은 그룹 자체에 권한 있는 복원을 수행하는 것입니다.
그러나 이렇게 그룹에 대해 권한 있는 복원을 수행하는 데는 두 가지 문제가 따릅니다. 첫 번째 문제는 누가 보기에도 확실한 것으로, 그룹을 복원하면 이 그룹의 구성원 자격이 백업 당시의 상태로 돌아간다는 점입니다. 즉, 마지막 백업을 수행한 이후 그룹에 적용된 모든 변경 사항을 그룹에 다시 적용해야 하는 것입니다. 두 번째 문제는 포착하기가 약간 어려운 것으로서, Active Directory 복제가 작동하는 방식과 관련이 있습니다. 사용자와 그룹 모두에 대해 권한 있는 복원을 수행하고 나면 이런 항목이 어떤 순서로 외부에 복제될 것인지가 확실하지 않습니다. 만약 그룹 개체가 복원된 사용자 개체보다 먼저 DC에 복제될 경우, 사용자 개체가 DC에 아직 존재하지 않기 때문에 복제를 수행하는 도메인 컨트롤러는 그룹에서 사용자 참조를 자동으로 삭제합니다. 그리고 나중에 사용자 개체가 복제되어 들어오면 그룹에 추가되지 않습니다.
이 문제를 해결하는 가장 쉬운 방법은 그룹에 대한 권한 있는 복원을 두 번 수행하는 것입니다. 즉, 첫 번째 권한 있는 복원을 수행한 후 표준 모드로 다시 부팅하고 복제가 제대로 수행되었는지 확인합니다. 그런 다음 DSRM 모드로 다시 부팅하고 NTDSUTIL을 실행하여 해당 사용자가 구성원으로 속했던 그룹에 대해 권한 있는 복원을 수행하면 됩니다. 이렇게 하면 다시 표준 모드로 부팅할 때 사용자 개체가 그룹 개체보다 먼저 복제되어 그룹 개체가 복제를 위해 사용자 개체를 참조할 수 있습니다.

문제: 다른 도메인의 그룹 구성원 자격이 복원되지 않음
"사용자가 구성원으로 속했던 그룹을 찾아내는 작업"은 사실 필자가 설명한 것보다 더 어렵습니다. 복원하려는 사용자는 다른 도메인의 도메인 로컬 및 유니버설 그룹에 속한 구성원이었을 수 있고 이러한 그룹 구성원 자격은 권한 없는 복원을 수행할 때 복원되지 않습니다. 그렇다면 다른 도메인에서 사용자가 어떤 그룹에 속했었는지 어떻게 알 수 있을까요? 해답은 글로벌 카탈로그에 있습니다. 글로벌 카탈로그는 해당 도메인의 데이터 외에도 포리스트의 다른 도메인이 보유한 데이터의 읽기 전용 복사본을 포함하고 있습니다.
포리스트 전체를 포괄하는 글로벌 카탈로그의 데이터를 활용하려면 글로벌 카탈로그에 대해 권한 없는 복원을 수행해야 합니다. 즉, 처음부터 글로벌 카탈로그가 백업되어 있어야 하는 것입니다. 이제 LDIFDE를 실행하여 사용자의 그룹 구성원 자격을 확인할 때는 다른 도메인에서도 사용자의 유니버설 그룹 구성원 자격을 확인할 수 있습니다.
복구하려는 사용자의 그룹 구성원 자격을 나열할 때는 기본값인 389 대신 글로벌 카탈로그 포트 3268에 연결하고, 포리스트의 루트 도메인을 포함하여 검색하도록 지정하십시오. LDIFDE는 포리스트의 모든 도메인에 속한 유니버설 그룹의 구성원 자격을 포함하여 복구된 사용자의 모든 그룹 구성원 자격을 표시합니다. 다음은 이 작업을 수행하는 방법입니다.
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
글로벌 카탈로그에 대해 GROUPADD 또는 새로운 NTDSUTIL을 실행하면 사용자의 도메인에 대한 LDIF 파일 하나와, 복원된 사용자가 유니버설 그룹의 구성원이었던 각 도메인에 대한 LDIF 파일 하나가 각각 생성됩니다. 이러한 LDIF 파일을 가져오면 해당 사용자에 대한 모든 그룹 구성원 자격이 복원되는 것입니다. 지금부터 설명할 한 가지 문제만 제외하면 말이죠.

문제: 다른 도메인의 도메인 로컬 그룹 구성원 자격 복구
Windows Active Directory 환경에는 세 가지 종류의 그룹이 있습니다. 글로벌 그룹은 동일한 도메인의 구성원만 포함할 수 있지만, 포리스트의 해당 도메인과 다른 도메인에 있는 도메인 로컬 그룹 내에서 구성원으로 사용될 수 있습니다. 글로벌 그룹의 구성원 특성은 글로벌 카탈로그에 나타나지 않지만 글로벌 그룹은 해당 도메인의 구성원만 포함하기 때문에 이것은 문제가 되지 않습니다. 한편 유니버설 그룹은 모든 도메인의 구성원을 포함할 수 있으며, 포리스트의 다른 유니버설 그룹에서는 물론 포리스트의 해당 도메인과 다른 도메인에 있는 도메인 로컬 그룹에서도 구성원으로 사용될 수 있습니다. 그리고 유니버설 그룹의 구성원 특성은 글로벌 카탈로그에 복제됩니다. 도메인 로컬 그룹의 경우 포리스트에 있는 모든 도메인의 구성원을 포함할 수 있지만 다른 도메인의 그룹에서 구성원으로 사용될 수 없습니다. 더 중요한 사실은 도메인 로컬 그룹의 구성원 특성이 글로벌 그룹의 구성원 특성과 마찬가지로 글로벌 카탈로그에 표시되지 않는다는 것입니다. 따라서 다른 도메인의 도메인 로컬 그룹에 속한 사용자의 구성원 자격을 복구하기가 쉽지 않습니다.
Windows Server 2003 SP1 이전에는 외부 도메인의 도메인 로컬 그룹 구성원 자격을 복구하는 유일한 방법은, 각 도메인에서 DC를 복원하고 도메인 데이터를 수동으로 검색하여 복원된 사용자가 포함된 도메인 로컬 그룹이 있는지 찾은 다음 검색된 그룹에 해당 사용자를 다시 추가하는 것이었습니다. 도메인 수가 많은 대규모 환경에서 이 방법을 사용하면 곧 지치고 말 것입니다.
그러나 Windows Server 2003 SP1 버전의 NTDSUTIL은 다릅니다. 도메인 컨트롤러에 대해 NTDSUTIL을 실행하면 이 유틸리티가 복원된 사용자 개체의 DN과 GUID를 포함하는 텍스트 파일을 생성합니다. 이제 각 외부 도메인에 대해 단일 DC에 권한 없는 복원을 수행하고, 텍스트 파일을 이 DC에 복사한 후, NTDSUTIL을 실행하여 새로운 도메인별 LDIF 파일을 생성할 수 있습니다. 이 LDIF 파일은 복구된 사용자를 이 사용자가 구성원으로 속했던 도메인 로컬 그룹에 다시 추가해 줍니다.
이 방법을 사용하려면 각 외부 도메인의 DC에서 다음 작업을 수행합니다.
  1. 해당 외부 도메인의 DC를 DSRM 모드로 부팅합니다.
  2. NTBACKUP을 사용하여 복원된 사용자의 그룹 구성원 자격이 포함되어 있는 DIT의 복사본을 복원합니다.
  3. NTDSUTIL이 생성한 .txt 파일을 현재 DC에 복사합니다.
  4. 명령 창을 열고 ntdsutil을 입력합니다.
  5. authoritative restore를 입력합니다.
  6. create LDIF file(s) from <file name>을 입력합니다(여기서 <file name>은 텍스트 파일의 이름).
  7. quit을 두 번 입력하여 ntdsutil을 종료합니다.
  8. DC를 표준 Active Directory 모드로 다시 부팅합니다.
  9. ldifde –i –f <ldif filename>을 입력합니다(여기서 <ldif filename>은 방금 생성한 LDIF 파일의 이름).
이제 삭제되었던 사용자의 그룹 구성원 자격을 모두 복원한 것입니다.

단계별 방법
Active Directory 사용자와 이들의 그룹 구성원 자격을 복구하는 일은 그리 간단하지 않습니다. 특히 도메인이 많은 환경에서는 더욱 복잡해집니다. 그룹 구성원 자격을 제대로 복구하는 데 필요한 구체적인 단계별 방법은 사용하는 Windows의 버전에 따라 달라집니다.
Windows 2003 SP1을 사용하는 경우에는 다음의 단계를 따라야 합니다.
  1. 글로벌 카탈로그(GC)를 DSRM 모드로 부팅하고 삭제된 사용자가 포함된 백업을 사용하여 시스템 상태 복원을 수행합니다.
  2. NTDSUTIL을 사용하여 삭제된 사용자에 대해 권한 있는 복원을 수행합니다. NTDSUTIL이 복원된 개체의 DN과 GUID를 포함하는 한 개의 텍스트 파일과, 사용자의 그룹 구성원 자격을 복원하기 위한 한 개 이상의 LDIF 파일을 생성합니다.
  3. LDIFDE –i –f <LDIF filename>(여기서 <LDIF filename>은 2단계에서 생성된 LDIF 파일의 이름)을 사용하여 현재 도메인과 다른 도메인의 그룹 구성원 자격을 가져옵니다.
  4. 글로벌 카탈로그를 표준 모드로 다시 부팅합니다.
  5. 각 외부 도메인의 DC에서 DSRM 모드로 부팅하고 복원된 사용자의 그룹 구성원 자격이 포함된 백업을 사용하여 시스템 상태 복원을 수행합니다.
  6. create ldif files 명령을 사용하여 NTDSUTIL을 실행합니다.
  7. DC를 표준 모드로 다시 부팅합니다.
  8. LDIFDE –i –f <filename>(여기서 <filename>은 6단계에서 생성한 LDIF 파일의 이름)을 사용하여 외부 도메인의 그룹 구성원 자격을 복원합니다.
  9. 이제 원하는 경우 REPADMIN /syncall을 사용하여 복제를 강제 수행할 수 있습니다.
SP1을 설치하지 않고 Windows Server 2003을 사용하거나 Windows 2000을 실행하는 경우에는 몇 가지 단계가 추가됩니다. 기존 버전의 NTDSUTIL은 LDIF 파일을 생성하지 않기 때문에 GROUPADD 유틸리티를 사용하여 생성해야 합니다. 프로세스는 다음과 같습니다.
  1. 글로벌 카탈로그를 DSRM 모드로 부팅하고 삭제된 사용자가 포함된 백업을 사용하여 시스템 상태 복원을 수행합니다.
  2. NIC를 비활성화하거나 케이블 연결을 해제하여 인바운드 복제를 방지합니다.
  3. 글로벌 카탈로그를 표준 모드로 다시 부팅합니다.
  4. LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf를 사용하여 고유 이름이 <dn>인 사용자의 구성원 자격을 덤프합니다.
  5. GROUPADD /after_restore membership.ldf를 사용하여 LDIF 파일을 생성합니다.
  6. LDIFDE –i –f <LDIF filename>(여기서 <LDIF filename>은 5단계에서 GROUPADD가 생성한 LDIF 파일의 이름)을 사용하여 현재 도메인과 다른 도메인의 그룹 구성원 자격을 가져옵니다.
  7. REPADMIN /options <dcname> -DISABLE_INBOUND_REPL을 사용하여 인바운드 복제를 다시 활성화합니다.
  8. 각 외부 도메인의 DC에서 DSRM 모드로 부팅하고 복원된 사용자의 그룹 구성원 자격이 포함된 백업을 사용하여 시스템 상태 복원을 수행합니다.
  9. DC를 표준 모드로 다시 부팅합니다.
  10. LDIFDE –i –f <filename>(여기서 <filename>은 5단계에서 GROUPADD가 생성한 LDIF 파일의 이름)을 사용하여 외부 도메인의 그룹 구성원 자격을 복원합니다.
  11. 이제 원하는 경우 REPADMIN /syncall을 사용하여 복제를 강제 수행할 수 있습니다.
이제 마지막으로, Windows Server 2003 SP1 이전 버전의 환경에서는 복원된 사용자의 외부 도메인 로컬 그룹 구성원 자격을 복구하기만 하면 됩니다. 가능한 방법은 도메인 로컬 그룹 구성원 자격을 직접 복원하거나, 백업에서 DC를 복원하고 도메인 로컬 그룹에 대해 권한 있는 복원을 수행하는 것입니다.

요약
Active Directory에서 실수로 사용자나 심지어 OU를 삭제하기는 쉽지만 삭제된 사용자와 이들의 그룹 구성원 자격을 제대로 복구하는 일은 대단히 복잡하고 많은 시간이 소요되며 오류도 자주 발생합니다. 이런 종류의 재해로부터 최대한 빨리 복구하기 위해서는 개체 연결, 복제, 삭제, 권한 있는 복원 등의 원리를 명확히 이해하고 있어야 합니다.
여러분은 프로덕션 환경에서 이 모든 단계별 절차를 처음부터 제대로 수행할 자신이 있습니까? 다음에 혹시 CEO의 사용자 개체를 복구해야 할 수도 있는 상황을 대비하여 삭제된 개체를 복구하는 데 필요한 계획을 문서로 준비해 두십시오. 그리고 이런 계획을 실제 데이터에 적용해 보기 전에 한두 번 이상 연습해 보는 것도 잊지 마십시오. 여러분의 상사와 CEO에게 깊은 인상을 남길 수 있으니까요.
추가 리소스
  • Active Directory에서 삭제된 사용자 계정 및 해당 그룹 구성원을 복원하는 방법
  • Microsoft 기술 지원 서비스
  • Active Directory 관리를 위한 단계별 가이드

Gil Kirkpatrick은 NetPro의 CTO로서 1996년부터 Active Directory용 소프트웨어를 개발해오고 있으며, HP의 Guido Grillenmeier와 함께 인기 있는 Active Directory 재해 복구 워크샵을 진행하고 있습니다. 또한 Directory Experts Conference(www.dec2007.com)의 창립자이기도 합니다.


 Windows Administration: Windows XP Embedded가 중요한 이유
Windows Administration Don Jones

Windows XP Embedded가 중요한 이유
한 눈에 보기:
  • Windows XP Embedded 들여다보기
  • 특수한 하드웨어 옵션
  • Windows XP Embedded 사용자 지정

Windows XP Embedded는 셋톱 박스나 가전 제품 같은 전자 제품에 많이 사용되는 Windows의 구성 요소화된 버전입니다. 하지만 Windows XP Embedded는 조직의 IT 구성에도 적합할 수 있습니다. 모든 사용자에게 최고의 솔루션이 될 수는 없겠지만
몇 가지 상황에서는 Windows XP Embedded를 통해 관리 오버헤드를 줄이고, 비용과 하드웨어 수를 줄이며, 보안을 강화할 수 있습니다.

Windows XP Embedded의 정의
Windows® XP Embedded는 Windows Embedded CE 및 Windows Embedded for Point of Service와 함께 리소스 사용량이 적은 세 가지 Windows 버전 중 하나입니다. 또한 임베디드 Windows 운영 체제 중 Windows XP Embedded만이 Windows XP Professional 클라이언트 컴퓨터의 전체 기능 또는 그에 준하는 잠재적인 기능을 제공합니다. Windows XP Embedded는 Windows XP Professional 서비스 팩 2(SP2)를 기반으로 하지만 강력한 모듈화를 지원한다는 점에서 일반적인 Windows XP와 다릅니다. Windows XP Embedded에는 표준 설치 이미지라고 할 수 있는 것이 없습니다. 대신 어떤 장치를 만들든 Windows Embedded Studio 도구 키트를 사용하여 해당 장치에 맞게 사용자 지정된 Windows XP Embedded 환경을 구축할 수 있으며, 이렇게 구축된 환경에는 장치에 필요한 기능만 포함됩니다. 즉, DirectX® 또는 Windows 탐색기가 필요 없다면 설치하지 않으면 됩니다. 모듈화란 구축하고 배포하는 각 Windows XP Embedded 이미지에 소위 말하는 구동부의 수가 적다는 것을 의미합니다. 따라서 저비용 하드웨어에서 실행할 수 있을 뿐 아니라 관리 오버헤드는 낮아지고 보안은 향상되었습니다. 그림 1에서는 Windows Embedded Studio에서 제공되는 Target Designer(대상 디자이너)에서 사용할 수 있는 옵션을 일부 볼 수 있습니다.
그림 1 Target Designer(대상 디자이너)에서 구성 요소 선택
그림 1 Target Designer(대상 디자이너)에서 구성 요소 선택 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Target Designer(대상 디자이너)에서 구성 요소 선택
그림 1 Target Designer(대상 디자이너)에서 구성 요소 선택 (더 크게 보려면 이미지를 클릭하십시오.)

엔터프라이즈에서 차지하는 위치
사용자들이 Windows XP Embedded 기반 장치를 필요로 하는 상황은 점차 늘어나고 있습니다. 대규모 고객 서비스 콜 센터를 운영하는 회사를 예로 들어 보겠습니다. 이 경우 콜 센터 담당자에게는 내부에서 개발된 응용 프로그램 한두 가지와 웹 브라우저가 필요할 것입니다. 이러한 사용자는 컴퓨터의 성능 중 일부만 사용하기 때문에 Windows XP Embedded를 통해 필요한 수준의 성능만 구현할 수 있습니다. 기능이 줄어든다는 것은 곧 사용자의 실수나 보안 공격에 따르는 위험도 줄어든다는 의미가 됩니다.
Windows XP Embedded 장치는 제한된 기능을 갖기 때문에 성능이 낮고 더 저렴한 하드웨어에서 실행될 수 있습니다. 많은 업체에서 저전력 Intel 호환 프로세서가 사용되는 마더보드를 생산합니다. 이러한 마더보드는 크기가 매우 작고 전력 소비량이 낮으며, 발열량이 적어 팬을 사용하지 않는 경우도 많습니다. 따라서 제한된 수의 응용 프로그램만 실행하며 리소스 사용량이 낮은 임베디드 장치로 매우 적합합니다.

Windows XP Embedded의 특별한 성능
Windows XP Embedded는 정식 버전의 Windows XP에서는 사용할 수 없는 매우 유용한 옵션 몇 가지를 제공합니다. EWF(Enhanced Write Filter)와 HORM(Hibernate Once, Resume Many)은 Windows 관리 작업을 단순화하는 데 도움을 줍니다. EWF는 디스크 볼륨을 읽기 전용으로 만드는 Windows XP Embedded 배포에 추가할 수 있는 선택적 구성 요소로, 이를 사용하면 디스크에 대해 수행된 모든 쓰기 작업을 다른 디스크나 메모리에 있는 오버레이로 전환할 수 있습니다. 운영 체제는 EWF 오버레이와 상위 볼륨을 하나의 단위로 인식하기 때문에, 일반적인 디스크 볼륨과 같은 방식으로 다룹니다. 하지만 그 이면을 보면 상위 볼륨은 실제로 변경되지 않으며 EWF 오버레이만 변경되는 것을 알 수 있습니다. 이 기능을 유용하게 활용할 수 있는 몇 가지 방법이 있습니다. Windows XP Embedded 이미지를 CF(컴팩트 플래시) 카드에 배포하는 경우를 예로 들어 보겠습니다. Windows XP Embedded 이미지의 크기는 작게는 5MB부터 평균적으로는 200MB 가량 되기 때문에 CF의 저장 공간으로도 충분합니다. 이 CF 카드를 어댑터에 삽입하여 마더보드의 IDE 커넥터에 연결하면 CF 카드가 보통의 고정 디스크처럼 인식됩니다. 최근의 CF 카드는 쓰기 성능이 100,000회 정도로 제한되기 때문에 EWF를 사용하여 CF 볼륨을 읽기 전용으로 만들 수 있습니다. 또한 RAM에 EWF 오버레이를 두는 경우를 예로 들 수 있습니다. 이 경우 사용자가 실수를 하면 시스템을 끄기만 하면 됩니다. 그러면 EWF 오버레이 및 시스템에 대한 모든 변경 내용이 즉시 사라집니다. 재부팅하면 CF 카드에 저장된 시작 시점으로 돌아갈 수 있습니다. CD 또는 DVD 기반의 이미지에도 같은 설정을 사용할 수 있습니다. 이러한 미디어 유형은 기본적으로 읽기 전용이기 때문에 EWF는 모든 쓰기 작업을 오버레이로 캡처합니다. 오버레이가 작은 내장 하드 디스크에 저장되는 경우에도 CD 또는 DVD에 있는 원본 부팅 볼륨은 변경되지 않습니다. 시스템을 원래 구성으로 재설정해야 하는 경우 EWF 오버레이를 지우기만 하면 됩니다.
HORM은 이름에서 알 수 있듯이, 시스템을 최대 절전 모드로 전환한 다음 이 최대 절전 모드에서 몇 번이고 다시 시작할 수 있도록 해 주는 기능입니다. 따라서 컴퓨터가 거의 즉각적으로 켜집니다. 컴퓨터를 구성하고 필요한 모든 응용 프로그램을 실행한 다음 최대 절전 모드로 전환한 경우 시스템을 켤 때 단지 몇 초만 기다리면 모든 것이 다시 실행됩니다.

Windows XP Embedded 이미지 만들기
Microsoft는 Windows XP Embedded 관련 작업을 전문적으로 수행하는 기업들로 구성된 Embedded Partner 프로그램을 운영하고 있습니다. 기업 목록은 microsoft.com/embedded의 Windows XP Embedded 홈 페이지에서 볼 수 있습니다. 하지만 많은 업체에서 일반 PC 제조업체에게 자사의 응용 프로그램과 특정한 구성을 포함하여 사전에 구성된 이미지를 제공하는 것처럼, 여러분도 Windows XP Embedded 이미지를 직접 제작하여 완전한 소형 시스템을 제공하는 Embedded Partner와 공유할 수 있습니다. Windows XP Professional에 설치되는 Windows Embedded Studio를 사용하면 Windows XP Embedded 이미지를 만들고 관리할 수 있습니다.
도구 키트를 사용하려면 먼저 Windows XP Embedded 시스템에 사용할 하드웨어에 Windows XP Pro의 정식 버전을 설치해야 합니다. 이렇게 하면 전체 Windows XP 설치 루틴을 사용하여 모든 하드웨어가 정상적으로 작동하게 할 수 있습니다. 그런 다음 Windows Embedded Studio를 설치합니다. 이 경우 일반적으로 임베디드 이미지의 관리에 사용되는 데이터베이스가 설치되지만 실제로 데이터베이스는 다른 곳에 설치되어 중앙 리포지토리 역할을 할 수 있습니다. 다음으로는 Windows XP Embedded가 사용할 수 있는 특별한 새 구성 요소를 만드는 Tap.exe라는 명령줄 유틸리티를 실행합니다. 일반적으로 구성 요소는 미디어 플레이어, 파일 시스템 또는 기타 사용자 지정 응용 프로그램 등의 기능을 캡슐화합니다. 이번에는 시스템에 필요한 하드웨어 장치 드라이버가 포함된 구성 요소를 만들어야 합니다. 이 단계는 도구가 적절한 하드웨어 드라이버를 감지하여 포함할 수 있도록 대상 하드웨어에서 수행되어야 합니다.
다음 단계에서는 Windows XP Embedded Component Designer(구성 요소 디자이너)를 실행하여 Tap.exe 유틸리티로 생성된 구성 요소 패키지를 가져옵니다. 그림 2에서 볼 수 있듯이 Component Designer(구성 요소 디자이너)는 장치 정보를 읽어 완전한 Windows XP Embedded 구성 요소를 조합하며 이것은 새 Windows XP Embedded 이미지의 기반이 될 수 있습니다. 이렇게 하면 해당 플랫폼에 필요한 장치 드라이버를 확인하는 과정이 대폭 간소화됩니다. 구성 요소를 만든 뒤에는 Component Database Manager(구성 요소 데이터베이스 관리자)를 사용하여 알려진 모든 Windows XP Embedded 구성 요소가 저장되는 리포지토리인 Windows XP Embedded 구성 요소 데이터베이스로 새 구성 요소를 가져옵니다. 구성 요소가 데이터베이스에 있으면 Windows XP Embedded 이미지에서 해당 구성 요소를 사용할 수 있습니다.
그림 2 Component Designer(구성 요소 디자이너)
그림 2 Component Designer(구성 요소 디자이너) (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Component Designer(구성 요소 디자이너)
그림 2 Component Designer(구성 요소 디자이너) (더 크게 보려면 이미지를 클릭하십시오.)
이제 실제 작업을 대부분 수행하는 도구인 Windows XP Embedded Target Designer(대상 디자이너)를 사용하여 새 대상 구성을 만들 준비가 되었습니다. 그림 1에서처럼 장치에서 필요로 하는 기능 집합을 만드는 데 필요한 모든 구성 요소를 추가합니다. 또한 Windows 탐색기(장치에 그래픽 셸이 필요한 경우), NTFS 파일 시스템(또는 FAT32), NT 로더, 언어 지원, 사용자 인터페이스 코어 등과 같은 일부 Windows 핵심 구성 요소도 추가해야 할 수 있습니다. 기본적으로 10,000개 이상의 구성 요소를 사용할 수 있습니다.
각 구성 요소의 설정을 미리 구성할 수도 있습니다. 예를 들어 사용자 인터페이스 코어 구성 요소를 사용자 지정하여 Windows 시작 메뉴, 바탕 화면 및 기타 위치에 특정 항목을 표시할 수 있습니다. 각 구성 요소의 설정을 사용자 지정하면 각 장치를 필요에 맞게 미리 구성할 수 있습니다(그림 3 참조).
그림 3 설정 사용자 지정
그림 3 설정 사용자 지정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 설정 사용자 지정
그림 3 설정 사용자 지정 (더 크게 보려면 이미지를 클릭하십시오.)
Windows XP Embedded 이미지의 가장 복잡한 부분은 종속성입니다. 예를 들어 이미지에 DirectX 구성 요소를 추가하려면 Windows에 핵심 그래픽 처리 기능을 제공하는 몇 가지 구성 요소도 함께 추가해야 합니다. 이렇게 모든 종속성을 추적하는 작업, 특히 수천 가지의 종속성이 있을 수 있는 크고 복잡한 이미지의 종속성을 추적하는 작업은 매우 어려울 수 있습니다. 이 작업을 구성 요소 데이터베이스가 수행합니다. Target Designer(대상 디자이너)에서 F5 키를 누르기만 하면 추가된 모든 구성 요소를 검사하여 나열된 구성 요소에 필요한 모든 종속성을 자동으로 추가합니다. 그림 4는 검사가 진행 중인 상태입니다. 이 단계는 매우 중요하며 이를 통해 Windows XP Embedded의 높은 모듈화가 유지될 수 있습니다. Target Designer(대상 디자이너)에 이러한 인텔리전스 기능이 내장되어 있지 않다면 종속성이 모두 올바르게 포함된 이미지를 만드는 것은 매우 어려운 일일 것입니다.
그림 4 종속성 확인
그림 4 종속성 확인 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 종속성 확인
그림 4 종속성 확인 (더 크게 보려면 이미지를 클릭하십시오.)
모든 구성 요소 및 종속성이 추가되었으면 Windows XP Embedded 이미지를 만들 수 있습니다. 이미지는 Windows XP Embedded 장치의 부팅 볼륨에 복사해야 하는 파일입니다. 이를 배포하는 데 특별한 도구가 필요하지는 않습니다. 하지만 Windows XP Embedded 도구 집합에는 원격 설치 서비스와 비슷한 기능을 하는 원격 부팅 서버가 포함되어 있으며 이를 통해 Windows XP Embedded 이미지를 하드웨어에 배포할 수 있습니다. 이 단계를 완료하면 이미지의 실제 크기를 확인할 수 있습니다. 이 예제에서는 메모장과 그림판 등의 몇 가지 응용 프로그램과 탐색기 셸이 포함된 매우 기본적인 이미지를 만들었으며 이 경우 크기는 90MB 미만입니다. 물론 메모장과 그림판만 실행할 수 있는 장치를 원하는 사용자는 거의 없겠지만 이를 통해 특정 작업용 이미지를 얼마나 작게 만들 수 있는지 알 수 있습니다.

Windows XP Embedded 대 Windows XP
Windows XP Embedded가 단지 단순화된 운영 체제 옵션인 것은 아닙니다. Microsoft는 Windows XP Embedded를 실행하는 컴퓨터가 정식 버전의 Windows XP와 거의 동일한 기능을 수행할 수 있도록 하기 위해 미리 패키지된 구성 요소를 제공합니다. 여기에는 DirectX 9.0c, Microsoft® .NET Framework, Windows Media® Player 10 등을 설치하는 옵션이 포함됩니다. 탐색기를 대체하는 사용자 지정 셸 같은 사용자 지정 구성 요소를 만드는 방법을 설명하는 많은 개발자 문서도 제공되기 때문에 각자의 임베디드 장치에 맞게 사용자 지정된 환경을 만들 수 있습니다.
하지만 Windows XP Embedded가 Windows XP Pro 정식 버전에 포함된 모든 기능을 제공하지는 않습니다. 예를 들어 Windows XP Embedded에는 WFP(Windows 파일 보호)가 포함되어 있지 않으며 Windows XP 둘러보기, 새 사용자의 컴퓨터 구성을 돕는 마법사와 초기 시작 화면 또는 Windows 설치 같은 사용자에게 편리한 기능도 일부 포함되어 있지 않습니다. Windows XP Embedded는 또한 Windows 정품 인증을 사용하지 않습니다. Windows XP Embedded 이미지는 Windows Embedded Studio 도구에서 런타임 제품 키로 인증됩니다. 또한 Windows XP Embedded는 환경 내의 Microsoft Software Update Services 서버는 사용할 수 있지만 Windows Update는 사용하지 않습니다. 마지막으로 Windows XP Embedded에는 Windows XP Pro에 포함된 MSN® Explorer가 없습니다.
Windows XP Embedded의 기능은 나날이 풍부해지고 있습니다. Feature Pack 2007이 발표되었으며, USB 기반 부팅과 같은 새 기능이 추가되고, 전체 오버레이를 커밋하지 않고도 상위 볼륨에 새 파일을 커밋할 수 있도록 EWF가 향상되었고, NTFS 압축에 대한 지원도 추가되었습니다. 이렇게 Windows XP Embedded 운영 체제에 유연성과 다양한 옵션이 지속적으로 추가됨에 따라 Windows XP Professional의 기능에 차츰 근접하고 있습니다.

임베디드 실행
임베디드 시스템은 전통적인 Windows XP 시스템에 비해 구축을 위한 노력이 더 많이 필요하지만 특정한 상황에서는 매우 큰 이점을 가집니다. 제공하는 기능은 상대적으로 적지만 Windows XP Embedded 시스템은 관리와 보수가 쉽고, 비용도 크게 절감되는 작은 크기의 저전력 하드웨어를 지원할 수 있습니다. 전력 소비량이 낮으면 전기 요금과 발열이 줄고, 촘촘한 작업 공간을 보다 유연하게 설계할 수 있습니다. 일반 가전, 건강 관리 장치, 키오스크 및 Windows XP Embedded가 사용될 것으로 생각하지 못한 많은 용도에서 활용하는 이외에 이 임베디드 운영 체제는 여러분의 조직에서도 훌륭한 역할을 할 수 있습니다.

Don Jones는 SAPIEN Technologies의 프로젝트 및 서비스 담당 이사이자 Windows PowerShell: TFM (SAPIEN Press)의 공동 저자입니다. 문의 사항이 있으면 www.ScriptingAnswers.com으로 연락하십시오.


 Management: System Center Capacity Planner를 사용한 사전 계획
Management John Savill

System Center Capacity Planner를 사용한 사전 계획
한 눈에 보기:
  • SCCP 기본 사항
  • 새로운 모델 만들기
  • 적절하게 모델 수정
  • 실제 사용 시뮬레이션

현재의 인프라 구성 요소는 이들의 지원을 받는 비즈니스에 매우 중요한 역할을 합니다. 하지만 사용자의 수가 늘어나고 비즈니스의 범위가 다양해질수록 이러한 구성 요소를 실행할 서버의 수와 규모를 예측하는 것이
점점 더 어려워집니다. 하드웨어가 충분하지 않으면 최종 사용자가 느끼는 응답 시간이 느려지고 하드웨어가 너무 많으면 예산이 낭비될 뿐만 아니라 이를 관리하는 데 필요한 인력도 늘어납니다. Microsoft에서 SCCP(System Center Capacity Planner) 2006을 만들게 된 것도 바로 이러한 이유 때문이었습니다.
대략적으로 봤을 때 SCCP를 사용하면 네트워크의 위치, 연결 속도, 대기 시간 등의 네트워크 토폴로지에 대한 정보, 사용할 소프트웨어 및 하드웨어에 대한 정보, 보낸 메시지 수와 같은 사용 프로필에 대한 정보 등을 입력할 수 있습니다. 그러면 SCCP에서는 다양한 사용 수준에 대한 시뮬레이션을 실행하여 하드웨어 및 네트워크 구성 요소의 사용률을 자세히 보여 줍니다. 이러한 모델링을 수행하면 제시된 구성이 구현된 서비스 요구 사항을 만족하는 데 적합한지 여부를 결정할 수 있습니다.
SCCP를 특정 서버에서 실행해야 한다거나 SCCP에서 네트워크 테스트를 수행해야 할 필요는 없습니다. SCCP는 기본적으로 모델링된 환경에 대해 테스트 시나리오를 실행하는 데 사용할 수 있는 시뮬레이션 도구입니다. SCCP 실행을 위한 최소 시스템 요구 사항은 Windows® XP with 서비스 팩 2(SP2), Windows Server® 2003 또는 Windows 2000 SP4와 Microsoft®입니다. 차세대 SCCP는 SMS(Systems Management Server) 및 MOM(Microsoft Operations Manager)과 보다 긴밀하게 상호 작용할 것으로 예상되며, MOM에서 이미 서버 사용률에 대한 정보를 수집하고 있고 SMS에서 하드웨어 구성 정보를 유지 관리하고 있으므로 차세대 SCCP에서는 정보 수집 작업의 일부가 자동화될 것으로 기대됩니다.
SCCP 2006의 설치는 간단합니다. 표준 설치 관리 마법사에서 사용권 계약에 동의하고 설치 폴더 위치만 확인하면 됩니다. 제품이 설치되면 모든 프로그램 메뉴에 바로 가기가 추가됩니다. SCCP를 처음 시작하면 그림 1과 같이 Capacity Planner의 네 가지 구성 요소 중 세 가지 구성 요소에 액세스할 수 있는 Microsoft Capacity Planner Welcome(Microsoft Capacity Planner 시작) 화면이 표시됩니다.
그림 1 Capacity Planner 도구 시작
그림 1 Capacity Planner 도구 시작 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Capacity Planner 도구 시작
그림 1 Capacity Planner 도구 시작 (더 크게 보려면 이미지를 클릭하십시오.)
Model Wizard(모델 마법사)는 시스템 아키텍처 모델(SAM)을 만들기 위해 원하는 환경에 대한 몇 가지 질문을 합니다. SAM에는 자세한 위치, 사용자, 네트워크, 사용 패턴 및 하드웨어가 포함됩니다.
Model Editor(모델 편집기)를 사용하면 마법사나 편집기를 통해 이전에 만든 SAM을 정밀 조정하고 수정할 수 있습니다. 이때 모델의 유효성을 검사하거나 시뮬레이션된 사용을 표시할 수 있으며 메일 서버에 대한 추가 로드나 원격 사용자의 존재 여부 등과 같은 다른 시나리오를 테스트할 수 있습니다.
Capacity Planner에는 SAM에 사용할 수 있도록 미리 정의된 여러 가지 하드웨어 유형이 제공됩니다. 하지만 사용자의 요구 사항이 이와 다를 경우에는 Hardware Editor(하드웨어 편집기)에서 하드웨어 구성을 필요에 맞게 정의할 수 있습니다.
모델을 선택하면 Capacity Planner Simulation(Capacity Planner 시뮬레이션)을 통해 선택한 모델에 대해 다양한 테스트를 수행해 봄으로써 모델이 실제 구현에서도 적합한지를 확인할 수 있습니다.
구성 요소와 각 구성 요소의 상호 작용 방법을 살펴보려면 도구를 실제로 사용해 보는 것이 가장 좋습니다. 이제 마법사를 시작하고 시뮬레이션을 실행한 다음 사용자 지정 하드웨어를 추가하여 아키텍처 모델을 적절하게 수정해 보겠습니다. 이 연습에서는 Exchange 환경을 사용하지만 프로세스는 MOM의 경우와 비슷합니다.

새로운 모델 만들기
계획된 인프라에 대해 유효성 확인 또는 "가정" 시나리오를 수행하기 전에 또는 현재 배포된 인프라에 대한 시나리오만 실행하려는 경우라도 해당 환경에 대한 정보를 SCCP에 제공해야 합니다. 안타깝게도 현재 버전에서는 네트워크를 간단하게 검색할 방법이 없습니다. 대신 서버의 실제 위치와 서버 간 연결의 종류, 서버 배치, 사서함 및 사용자의 측면에서 해당 인프라에 대한 자세한 정보를 제공하고 사용자가 해당 환경을 사용하는 방법을 자세히 지정해야 합니다.
SCCP에는 몇 가지 제한이 따르는데 이에 대해서는 사용자 가이드에 자세히 설명되어 있습니다. 예를 들어 Exchange 모델에서는 단일 포리스트만 지원됩니다. 따라서 외부 포리스트의 도메인은 모델링되지 않으며 프런트 엔드 서버의 경우에는 글로벌 카탈로그와 사서함 저장소 모두 동일한 사이트에 있는 것으로 간주됩니다. 사이트는 최대 100개까지만 모델링할 수 있으며 이 중에서 10개만 허브 사이트가 될 수 있습니다. 또한 서버 컴퓨터는 최대 300대까지만 지원되고 Outlook® 2003 클라이언트(웹 또는 로컬)만 지원됩니다. 다행히 SCCP는 중앙/허브 위치에서는 클라이언트를 최대 49,999개까지, 그리고 지사 위치에서는 클라이언트를 최대 10,000개까지 지원할 수 있습니다. ActiveSync® 및 Outlook Mobile Access 연결과 같은 Exchange 기능은 지원되지 않으며 POP 및 IMAP과 같은 레거시 연결 옵션도 지원되지 않습니다. 백업 및 복원 작업으로 인해 야기되는 사용률이나 클러스터 구성은 고려되지 않습니다. 하지만 Capacity Planner에는 일상적인 메일 사용을 정확하게 모델링하는 데 필요한 옵션이 포함되어 있습니다.
연습을 시작하려면 Welcome(시작) 페이지에서 "Create a model with the Model Wizard(모델 마법사를 사용하여 모델 만들기)"를 선택하고 모델링할 인프라에 대한 정보를 제공합니다. 여기서는 댈러스에 중앙 위치가 있고 휴스턴과 오스틴에는 지사가 있으며 각각의 위치에는 많은 로컬 전자 메일 사용자가 있는 회사를 만들어 보겠습니다. 각 위치에 자체 서버를 둘 필요가 없으므로 여기서는 전자 메일 사용자의 수와 유형에 대한 정보를 제공하겠습니다. 그러면 SCCP에서는 로컬 Exchange 서버가 있는 위치와 사용자가 해당 Exchange 서버에 원격으로 액세스하는 위치를 계산합니다.
엔터프라이즈 인프라의 기본 모델을 만든 후 마법사는 중앙 및 지사 사이트의 수, 사이트 간 연결, 메시징에 사용할 수 있는 대역폭의 비율 등을 묻습니다. 그런 다음 마법사는 대략적으로 모델을 만듭니다. 마법사가 만든 모델은 나중에 적절하게 수정하여 보다 자세한 수준으로 개별 링크를 구성할 수 있습니다. 이 예제에서는 중앙 사무실이 하나이고 지사 사이트가 둘인 모델이 만들어졌습니다(그림 2 참조). 지사와 중앙 사이트 간에는 T1 연결이 사용되고 메시징에는 대역폭의 50%를 사용할 수 있습니다. 중앙 사이트는 하나뿐이므로 중앙 사이트 간 속도는 구성할 필요가 없습니다.
그림 2 WAN 토폴로지 및 연결 대역폭 구성
그림 2 WAN 토폴로지 및 연결 대역폭 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 WAN 토폴로지 및 연결 대역폭 구성
그림 2 WAN 토폴로지 및 연결 대역폭 구성 (더 크게 보려면 이미지를 클릭하십시오.)
마법사의 다음 창에서는 지사 위치에 있는 평균 사용자 수, 전자 메일 클라이언트(캐시 모드의 Outlook 2003 또는 Outlook Web Access), 중앙 위치에 있는 사용자 수 등을 묻습니다. 다시 말하지만 이는 매우 대략적인 정보일 뿐이며 나중에 Model Editor(모델 편집기)를 사용하여 적절하게 수정할 수 있습니다. 이 예제에서는 각 지사에 각각 200명의 사용자가 있고 중앙 사무실에는 500명의 사용자가 있으며 이들 모두 캐시 모드에서 Outlook을 사용한다고 가정합니다.
마법사에는 High(높음), Medium(중간), Low(낮음)이라는 세 가지 기본 메일 사용 수준이 제공됩니다. 수준마다 평균 사서함 크기, 보내고 받은 메시지 수, 전자 메일 메시지의 평균 크기 등이 각각 다릅니다. 기본 제공되는 유형 중 조직의 사용 패턴과 일치하는 것이 없으면 위의 네 가지 사용 특성 각각에 대해 개별 값을 구성할 수 있습니다.
다음 단계는 그림 3에 나온 것처럼 하드웨어 기본 설정을 구성하는 것입니다. SCCP에서는 CPU 구성을 최대 세 가지까지 지정할 수 있으며 이러한 구성은 다양한 서버 역할에 맞게 하드웨어를 모델링하는 데 사용됩니다. CPU 구성은 단일 프로세서 1GHz Pentium III Xeon에서 사중 프로세서 3.66GHz Xeon MP에 이르기까지 다양하게 지정할 수 있습니다. Exchange 2003은 사서함 저장소, 브리지헤드, 프런트 엔드, 추가 Active Directory® 글로벌 카탈로그 역할 등의 다양한 역할로 구성됩니다. 사용률이 허용한다면 보다 적은 수의 서버로 역할을 통합하는 옵션을 사용할 수도 있습니다. 서버 통합을 지정하지 않으면 사용률에 필요하지 않더라도 별개의 서버가 각 역할에 맞게 구성됩니다. SCCP에서 역할 통합을 허용하면 최상의 결과를 얻을 수 있습니다.
그림 3 서버에 맞게 하드웨어 프로필 구성
그림 3 서버에 맞게 하드웨어 프로필 구성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 서버에 맞게 하드웨어 프로필 구성
그림 3 서버에 맞게 하드웨어 프로필 구성 (더 크게 보려면 이미지를 클릭하십시오.)
마지막으로 사용할 수 있는 디스크의 종류는 인터페이스, 크기 및 속도를 기준으로 선택할 수 있습니다. 디스크의 수는 Capacity Planner에서 자동으로 계산하므로 지정할 필요가 없습니다. Capacity Planner에서는 저장소 영역 네트워크(SAN)도 지정할 수 있습니다. 아직까지 클러스터를 만드는 기능은 지원되지 않습니다.
마법사의 다음 단계에서는 SCCP에서 최적으로 계산한 서버의 수, 각 서버의 역할, 프로세서, 메모리 및 디스크 구성과 같은 세부 정보 등 계산된 모델을 요약하여 보여 줍니다. SAN을 선택한 경우에는 SAN도 표시됩니다.
이 예제에서는 위치를 여러 개 선택했으므로 해당 위치의 하위 집합에만 서버가 표시될 수도 있습니다. 이는 그림 4의 예제에서처럼 SCCP가 일부 위치의 로컬 Exchange 서버는 최적이 아니며 이 경우에는 원격 Exchange 사서함 서버를 통해 사서함 서비스를 제공하는 것이 더 낫다는 것을 확인했기 때문입니다. 이 경우 400명의 지사 사용자는 로컬 Exchange 사서함 저장소를 사용할 수 없지만 대신 이들이 댈러스에 있는 단일 Exchange 사서함 저장소 서버로 통합되어 이제 이 서버의 사용자가 500명으로 표시됩니다.
그림 4 초기 용량 계획 평가에 대한 요약
그림 4 초기 용량 계획 평가에 대한 요약 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 초기 용량 계획 평가에 대한 요약
그림 4 초기 용량 계획 평가에 대한 요약 (더 크게 보려면 이미지를 클릭하십시오.)
마법사의 이 단계까지는 Back(뒤로)과 Next(다음) 단추를 클릭하거나 왼쪽의 탐색 창에서 원하는 마법사 페이지를 직접 클릭하여 대답을 수정하거나 모델 요약을 적절하게 수정할 수 있었습니다. 구성에 만족하면 Model Summary(모델 요약) 페이지에서 Finish(마침) 단추를 클릭하면 됩니다. 그러면 Model Editor(모델 편집기)에서 모델이 열리고 여기에서 보다 자세히 구성을 지정할 수 있습니다.

적절하게 모델 수정
Model Wizard(모델 마법사)는 기본 모델을 만드는 데 사용할 수 있는 뛰어난 도구입니다. 하지만 다양한 위치들이 모두 동일하고 평균적이지는 않으므로 모델이 사용률을 계산하는 기본 도구로서의 가치를 제대로 발휘하기 위해서는 어느 정도의 사용자 지정이 필요할 수밖에 없습니다. 대개 각 위치에는 다양한 수의 사용자가 있고 사용자 중 일부는 캐시 모드의 Outlook 2003을, 다른 사용자는 OWA(Outlook Web Access)를 사용하는 등 다양한 메시징 클라이언트가 조합되어 있을 수도 있습니다. Model Wizard(모델 마법사)가 이 정도로 자세한 수준까지 정보를 파악할 수는 없겠지만 Model Editor(모델 편집기)를 통해 충분히 구성할 수 있으므로 염려할 필요가 없습니다. Model Wizard(모델 마법사)는 또한 위치나 사용자 환경을 추가하는 등 환경의 특정 측면을 수정할 경우 그 결과를 확인하려는 경우에도 유용합니다.
그림 5에 나오는 Model Editor(모델 편집기)는 전용 형식인 .sam 파일로 모델을 저장하고 검색합니다. 모델을 상당 부분 변경하려면 먼저 모델을 파일로 저장하고 알아보기 쉬운 이름을 지정하여 작업 중인 모델이 손실되지 않도록 하는 것이 좋습니다. File(파일) 메뉴의 Export(내보내기) 메뉴를 사용하면 Excel® 형식과 Visio® 토폴로지 다이어그램으로 모델에 대한 자세한 요약 보고서를 생성할 수 있습니다.
그림 5 Model Editor(모델 편집기)에서 SAM 구성 수정
그림 5 Model Editor(모델 편집기)에서 SAM 구성 수정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 Model Editor(모델 편집기)에서 SAM 구성 수정
그림 5 Model Editor(모델 편집기)에서 SAM 구성 수정 (더 크게 보려면 이미지를 클릭하십시오.)
Model Editor(모델 편집기)의 왼쪽 창은 글로벌 토폴로지, 사이트 토폴로지 또는 모델 요약을 볼 수 있는 옵션이 있는 기본 탐색 영역입니다. Global Topology(글로벌 토폴로지)는 인터넷과 같은 추가 네트워크와 함께 사이트의 관점에서 아키텍처 모델을 보여 줍니다. Site Topology(사이트 토폴로지) 보기는 선택한 사이트나 네트워크에 대한 정보를 표시합니다. Model Summary(모델 요약)는 Model Wizard(모델 마법사)가 끝날 때 표시되는 것과 같은 형식으로 환경을 텍스트로 요약하여 보여 줍니다.
어떤 옵션을 선택하든 Model Editor(모델 편집기)의 가운데 창에 세부 정보가 표시됩니다. Windows Server 2003 R2와 함께 제공되는 새로운 버전의 MMC(Microsoft Management Console)와 맥락을 함께 하여 오른쪽 창은 두 개의 하위 영역으로 분할된 "작업" 영역입니다. 이 중에서 위쪽 영역은 현재 보기나 선택된 개체에 따라 바뀌는 상황에 맞는 작업을 제공하고 아래쪽 영역에는 항상 적용되는 일반적인 작업이 포함됩니다. 필자는 아래쪽 영역의 일반적인 작업을 통해 새 사이트를 추가하고 사용자의 사용 프로필을 편집한 다음 시뮬레이션을 실행했습니다.
Model Editor(모델 편집기)의 가운데 창에서 작업할 때는 모든 항목을 선택할 수 있습니다. 항목을 선택한 후에는 선택한 개체에 따라 변경되는 현재 항목 작업 이외에도 해당 개체에 대한 보다 자세한 정보를 볼 수 있습니다. 예를 들어 사이트를 두 번 클릭하면 Site Topology(사이트 토폴로지) 보기로 전환되어 해당 사이트에 대해 모델링된 개체에 대한 정보가 표시됩니다. 따라서 로컬에서 실행되는 사이트를 선택하면 해당 위치에 있는 사용자, 네트워크 및 서버가 한 개 이상 표시됩니다. 선택한 개체를 두 번 클릭하여 개체의 자세한 속성을 보고 필요에 따라 수정할 수 있습니다.
사이트를 연결하는 선은 각 위치를 연결하는 네트워크를 나타내며 네트워크의 정확한 구성을 반영하도록 편집할 수 있습니다. 예를 들어 업링크 및 다운링크 대역폭의 속도와 사용 가능한 대역폭의 비율을 다양하게 지정할 수 있습니다. 안정적인 연결에 매우 중요한 특성인 연결 대기 시간도 구성할 수 있습니다. 이외에도 사용자 유형을 추가하여 모델을 변경할 수 있습니다. 이 예제에서는 중앙 위치에서 Outlook Web Access와 Outlook 2003 클라이언트를 함께 실행한다고 가정합니다. Site Topology(사이트 토폴로지) 보기에서 댈러스를 연 다음 "Add a client profile(클라이언트 프로필 추가)"을 선택하고 OWA 클라이언트가 사용할 서버, 사용자가 연결을 시작할 네트워크 및 사용할 수 있는 대역폭 등 OWA 기반 사용자에 대한 정보를 추가합니다(그림 6 참조).
그림 6 모델에 요소를 추가하거나 수정하는 것은 쉽습니다.
그림 6 모델에 요소를 추가하거나 수정하는 것은 쉽습니다. (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 모델에 요소를 추가하거나 수정하는 것은 쉽습니다.
그림 6 모델에 요소를 추가하거나 수정하는 것은 쉽습니다. (더 크게 보려면 이미지를 클릭하십시오.)
SAM은 기존 인프라 또는 계획된 인프라를 가능한 한 가깝게 반영하고 향후에 인프라 수정이 필요할 경우 이를 쉽게 식별할 수 있도록 적절하게 이름을 지정하여 저장합니다. 이제 구성된 설정에서 모델이 어떤 방식으로 수행될지에 대한 벤치마크를 얻기 위해 시뮬레이션을 실행해 보겠습니다. 이때 얻은 벤치마크를 기준으로 모델을 수정하여 새 사이트 및 사용자 추가, 서버 추가 또는 제거, 위치에 새 사용자 추가, 연결 또는 전자 메일 클라이언트의 유형 변경과 같은 다양한 "가정" 시나리오를 테스트할 수 있습니다. 이러한 새로운 요소로 모델을 업데이트한 후에는 다른 시뮬레이션을 실행하여 새로운 구성은 어떤 결과를 보여 주는지 확인할 수 있습니다.

실제 사용 시뮬레이션
Run simulation(시뮬레이션 실행) 일반 작업 단추 또는 도구 모음 단추를 클릭하기만 하면 시뮬레이션을 실행할 수 있습니다. 시뮬레이션이 수행되기 전에 먼저 모델에 대한 온전성 검사가 수행되어 모델에 결함이 있으면 표시됩니다. 예를 들어 이전에는 OWA 클라이언트와 프런트 엔드 서버가 구성되어 있지 않았던 모델에 OWA 클라이언트를 여러 개 추가하면 프런트 엔드 서버가 존재하지 않음을 알려 주는 오류 메시지가 표시됩니다. 결함이 없으면 시뮬레이션이 수행되면서 진행 상황이 표시됩니다.
시뮬레이션이 완료되고 나면 모든 구성 요소에 대한 자세한 사용 정보가 있는 보고서가 생성되고 Simulation Results(시뮬레이션 결과) 보기가 열립니다. 처음에는 병목 현상의 일반적인 원인인 가장 높은 CPU, 저장소 및 연결 링크 사용률, 그리고 최종 사용자 환경에 영향을 미칠 수 있는 가장 긴 트랜잭션 및 대기 시간에 대한 세부 정보를 보여 주는 요약 보기가 표시됩니다. 서버, SAN, 로컬 및 외부 연결의 정확한 사용률 정보는 그림 7과 같이 왼쪽의 Simulation Results(시뮬레이션 결과) 창에서 링크를 선택하여 볼 수 있습니다.
그림 7 단순한 모델에 대한 시뮬레이션 결과 요약
그림 7 단순한 모델에 대한 시뮬레이션 결과 요약 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 단순한 모델에 대한 시뮬레이션 결과 요약
그림 7 단순한 모델에 대한 시뮬레이션 결과 요약 (더 크게 보려면 이미지를 클릭하십시오.)
Bottleneck analysis(병목 현상 분석)와 같은 각 그래픽 화면 위에 마우스를 놓으면 병목 현상을 야기하는 서버와 서버의 특성이 표시됩니다. 왼쪽 창의 Threshold settings(임계값 설정)를 주목하십시오. 이 범주를 사용하면 적정 사용률 값을 설정하여 이를 초과할 경우 경고를 표시할 수 있습니다. 참 편리한 기능입니다.
자세한 시뮬레이션 보고서는 하드웨어 구입 결정을 내리는 데 유용한 정보를 제공할 뿐만 아니라 메시징 응용 프로그램에 사용되는 네트워크 리소스의 양을 보여 주는 등 매우 중요한 정보를 제공합니다. 예를 들어 이 보고서는 느린 WAN 링크를 통해 연결하는 사용자의 연결 속도가 적절한지를 보여 주는 정보를 제공합니다. 연결 속도가 적절하지 않은 경우에는 특정 조건에 맞는 결과를 얻기 위해 모델을 수정하고 시뮬레이션을 다시 실행함으로써 위치 간 연결 속도를 업그레이드해야 하는지 또는 로컬 사서함 저장소 서버를 추가해야 하는지 등을 알아낼 수 있습니다. 마찬가지로 서버가 모두 5%의 CPU 사용률로 실행될 경우 해당 서버 지정을 삭제할 수 있습니다. 모델을 수정하거나 시뮬레이션을 다시 실행하는 것이 매우 간단하므로 다양한 솔루션 옵션을 얼마든지 시도해 볼 수 있습니다. 테스트한 모든 시나리오에서 얻은 정확한 수치를 가지고 있으므로 이제 확신을 가지고 예산 및 계획 회의에 참석할 수 있습니다.

요약
이 문서에서는 SCCP를 사용하여 Exchange 배포를 시뮬레이션하고 분석하는 방법을 간단하게 살펴보았습니다. SCCP는 MOM에 대해서도 동일한 수준의 모델링과 시뮬레이션을 수행한다는 점을 염두에 두십시오. SCCP는 현재 MSDN® Premium 다운로드 또는 TechNet Plus를 통해 다운로드할 수 있습니다. ¦

John Savill은 Geniant의 기술 인프라 팀장으로, Windows Server 2003의 CISSP이자 보안 및 메시징 MCSE이고 여덟 번이나 MVP로 선발된 경력이 있으며 크라브 마가 강사로도 활동하고 있습니다. Packt Publishing에서 출판한 Windows Server 2003 Active Directory Design and Implementation의 저자이기도 합니다.


 Management: SMS를 사용한 고급 클라이언트 인벤토리
Management Wes Dobry

SMS를 사용한 고급 클라이언트 인벤토리
한 눈에 보기:
  • SMS 2003 하드웨어 인벤토리 에이전트 사용
  • MIF 파일을 사용하여 인벤토리 확장
  • 동적 MOF 파일과 정적 MOF 파일
이 기사의 코드 다운로드: DobrySMSInventory2007_04.exe (152KB)

관리자라면 많은 시간을 들여야 수집할 수 있는 정보를 상관에게 제출해야 하는 경우가 있게 마련입니다. 그런데 이와 같은 경우에 미리 대비해 두었다고 가정해 봅시다.
즉, 데이터를 사전에 수집해 두었다면 상관에게 정보를 즉시 제공할 수 있으므로 불필요하게 시스템 작동을 중단하거나 야근을 할 필요가 없게 됩니다. 또한 회사에 많은 비용 절감 효과도 가져다 줌으로써 능력 있는 관리자로 인정받게 될 것입니다.
Microsoft® Systems Management Server(SMS) 2003은 기본적으로 많은 정보를 수집하지만 모든 정보를 수집하지는 않습니다. 예를 들어 SMS 2003은 기본적으로 로컬 그룹 및 로컬 그룹의 구성원 또는 로컬 사용자와 사용자의 특성에 대해서는 보고하지 않습니다. 이러한 정보가 없다면 엔지니어가 작업 중인 각 시스템의 로컬 관리자 그룹에 Domain Users, 또는 한술 더 떠 Everyone을 넣을 경우 문제가 될 수 있습니다. 또는 회사의 바이러스 백신 솔루션이나 스파이웨어 방지 솔루션에 있는 로컬 파일 및 폴더 제외 목록이 어떤 것인지를 알 수 없게 될 수도 있습니다. 이러한 문제가 대수롭지 않게 보일 수도 있지만, 사용자가 제외 목록에 c:\*.*를 입력하고 있는 것을 IT 부서의 누군가가 발견하게 된다면 상황은 달라질 것입니다.
스크립팅, Windows® Management Instrumentation(WMI) 및 SMS에 관한 지식을 적절하게 조합하여 활용하면 SMS 인벤토리를 확장하여 거의 모든 정보를 포함할 수 있는데, 이 작업은 MIF(Management Information Format) 및 MOF(Management Object Format) 파일을 통해 이루어집니다.

인벤토리 사용
SMS를 사용하면 조직은 상황에 맞게 배포를 수행하고 대상을 모니터링하고 배포된 시스템을 유지 관리할 수 있습니다. 더 나아가 SMS 인벤토리를 확장하여 상황에 맞게 보다 더 세밀하게 대상을 만들어 관리할 수도 있습니다. 예를 들어 사용자가 수정한 정책이 있는 시스템에 보안 정책을 배포하여 회사의 로컬 보안 정책을 적용할 수 있으며, 승인되지 않은 로컬 사용자 계정을 비활성화하거나 관계없는 로컬 관리자를 제거할 수도 있습니다.
물론 조직에서는 클라이언트 시스템에 대한 자세한 정보를 제때에 얻기 위해 SMS을 사용하기도 합니다. 인벤토리를 확장하면 원하는 정보로만 채워진 보고서를 만들 수 있는데, 기본 인벤토리에만 의존해서는 이러한 정보를 곧바로 얻을 수 없습니다. 정보를 세분화하여 볼 수도 있습니다. 예를 들어 특정 서버 팜을 가리키는 특정 레지스트리 키가 있는 시스템의 수가 포함된 보고서를 만들 수 있습니다. 이를 통해 관리자는 특정 시간에 각 팜을 가리키는 클라이언트의 수를 대략적으로 평가할 수 있으며, 보안 팀에서는 네트워크에서 스파이웨어로 알려진 특정 프로세스를 실행하고 있는 시스템이 어떤 것인지를 확인할 수 있습니다.
MIF 및 MOF 파일은 약간의 변환만 거치면 거의 모든 소스의 정보를 입력할 수 있다는 점에서 매우 유용합니다. 텍스트를 기반으로 하는 모든 정보는 MOF 파일을 통해 조작하여 WMI로 가져오거나 MIF 파일 형식으로 수집하여 다음 하드웨어 인벤토리 사이클에 전송할 수 있습니다. 인벤토리 확장을 구현하려면 VBScript 또는 JScript®에 관한 지식과 더불어 수집해야 할 정보가 무엇인지에 대해서도 정확하게 이해하고 있어야 합니다. SMS로 거의 모든 정보를 수집할 수 있다는 점을 감안한다면 WMI에서 고급 SQL에 이르기까지 매우 방대한 지식이 필요할 수도 있습니다. 물론 수집한 데이터에 대해 보고를 하려면 SQL에 관한 지식이 필요하므로 수집하려는 정보의 종류에 관계없이 SQL에 대해서는 이해하고 있어야 합니다.

인벤토리 작동 방식
SMS에는 하드웨어 인벤토리와 소프트웨어 인벤토리라는 두 가지 유형의 인벤토리 프로세스가 있습니다. 소프트웨어 인벤토리에는 파일의 위치, 파일 버전, 파일 크기 및 기타 파일 특성 등 파일에 관한 정보만 포함되지만 소프트웨어 인벤토리 프로세스를 사용하여 파일을 수집하고 사이트 서버에 저장할 수도 있습니다.
하드웨어 인벤토리는 시스템에 대한 가장 큰 정보 배열을 포함하므로 쉽게 확장할 수 있습니다. 하드웨어 인벤토리의 정보는 주로 WMI, 레지스트리 및 시스템 BIOS에서 가져옵니다.
하드웨어 인벤토리는 예약된 일정에 따라 수집되는데, 이러한 일정은 SMS 2003의 하드웨어 인벤토리 에이전트의 사이트 설정을 통해 지정합니다. 정보 수집 빈도는 1분에 한 번에서 몇 달에 한 번에 이르기까지 다양한 간격으로 설정할 수 있습니다 일반적으로 관리하기에 용이한 가장 빠른 빈도로 정보를 수집하되, 이러한 정보 수집 빈도가 네트워크, 사이트 서버, 관리 지점 또는 클라이언트에 부담을 주지 않는 선에서 적절한 균형점을 찾는 것이 좋습니다.
하드웨어 인벤토리 에이전트를 처음 설치하면 sms_def.mof 파일이 컴파일됩니다. 이 파일에는 SMS에서 초기에 수집하는 모든 정보가 포함됩니다. 이 파일이 컴파일되고 나면 하드웨어 인벤토리 에이전트에 필요한 모든 SMS 네임스페이스 및 관련 클래스가 WMI에 만들어지며 이들 중 대부분은 \\.\root\CIMv2\SMS 네임스페이스에 있습니다. 설치 후 하드웨어 인벤토리 에이전트는 이러한 클래스의 대부분을 검토하여 관리 지점과 사이트 데이터베이스로 전송될 정보를 구성합니다.

MIF 파일
하드웨어 인벤토리 에이전트는 WMI 클래스에서 정보를 가져올 뿐만 아니라 NOIDMIF 및 IDMIF 모음 폴더에서도 MIF 파일을 찾습니다. 이들 폴더에서 찾은 MIF 파일은 처리되어 다음 하드웨어 인벤토리로 보내집니다.
MIF 파일을 사용하면 SMS 하드웨어 인벤토리를 가장 쉽게 확장할 수 있습니다. MIF 파일에는 NOIDMIF와 IDMIF의 두 종류가 있습니다. 이 두 파일은 XML과 비슷한 형태의 정적 파일로서, 사용자가 SMS 데이터베이스에 넣고자 하는 거의 모든 정보를 포함할 수 있습니다. 이 파일은 일반 텍스트 파일을 만드는 방법으로 만들 수 있으므로 대부분의 스크립팅 언어를 사용하여 만들거나 직접 만들 수 있습니다.
일반적으로 MIF 파일은 레지스트리나 WMI에 정보가 포함되어 있지 않거나 정보를 수동으로 입력해야 할 경우에 사용합니다. 예를 들어 하드웨어 배포 팀에서 새로운 시스템을 배포하는 경우에 이러한 파일을 만들 수 있습니다. 배포 엔지니어가 시스템에서 HTML 응용 프로그램을 찾아 자산 관리 데이터베이스를 업데이트하는 데 사용할 모든 자산 정보를 입력할 수 있습니다. 정보가 입력되면 HTML 응용 프로그램에서 동적으로 NOIDMIF 파일을 만들고, 엔지니어는 이 파일을 NOIDMIF 파일 모음 폴더로 다운로드할 수 있습니다. 이 NOIDMIF 파일은 배포 엔지니어가 입력한 모든 정보를 포함할 수 있으며 SMS 데이터베이스에 통합됩니다.
NOIDMIF와 IDMIF 파일에는 약간의 차이만 있습니다. IDMIF 파일은 아키텍처 정보와 고유 ID를 제공하는 고유 헤더를 포함하며, 시스템이 아닌 장치를 고유 엔터티로 SMS에 통합하는 데 사용할 수 있습니다. 예를 들어 스크립트를 사용하여 실제로는 프린터인 시스템을 SMS에 만들고 이에 대한 정보를 SMS 데이터베이스에 쓸 수 있습니다.
NOIDMIF와 IDMIF 파일은 레지스트리 키에 지정된 표준 위치에 저장되며, SMS 에이전트가 기본 위치에 설치된 경우에는 일반적으로 %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF와 %SYSTEMROOT%\system32\ccm\Inventory\IDMIF에 있습니다. 에이전트가 사용자 지정 위치에 설치된 경우에는 이 두 MIF 디렉터리는 %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF와 %CCMAGENTINSTALLDIR%\Inventory\IDMIF에 있습니다. 두 디렉터리의 위치를 확실하게 알 수 없는 경우에는 다음 레지스트리 키를 통해 확인할 수 있습니다.
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
MIF 파일의 형식은 수집되는 정보에 관계없이 항상 같습니다. 그림 1의 MIF 파일을 보면 파일이 여러 개의 그룹과 각 그룹에 단일 특성이 포함된 단일 구성 요소로 이루어져 있음을 알 수 있습니다. 그룹 또는 특성 항목이 하나만 필요한 경우에도 모든 섹션이 필요합니다. MIF 파일의 각 그룹은 하드웨어 인벤토리에서 명명된 섹션 데이터의 한 행으로, 그리고 그룹의 모든 특성은 해당 행의 한 열로 볼 수 있습니다.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
그림 2의 LocalAdmin.vbs 샘플은 상당히 간단한 VBScript입니다. 이 스크립트는 NOIDMIF 디렉토리를 조회하여 임시 MIF 파일이 있으면 이를 삭제하고 임시 MIF 파일을 새로 만든 다음 수집된 정보를 간단한 WMI 쿼리를 통해 임시 파일에 반복해서 씁니다. 그런 다음 NOIDMIF 모음 폴더에 있는 MIF 파일을 삭제하고 마지막으로 임시 NOIDMIF를 NOIDMIF 모음 폴더로 이동합니다.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
MIF 파일이 SMS 하드웨어 인벤토리를 확장할 수 있는 쉬운 방법을 제공하기는 하지만 이 파일을 사용할 때 고려해야 할 몇 가지 문제도 있습니다. MIF는 모든 하드웨어 인벤토리 사이클에서 처리됩니다. 그러나 이들 파일은 만들어지고 수집되고 분석된 다음 최종적으로 인벤토리에 저장되므로 MIF에 포함된 정보가 하드웨어 인벤토리에 나타나는 시간이 사이클 1회에 해당하는 시간만큼 지연될 수 있습니다. 즉, 회사의 하드웨어 인벤토리 사이클 간격이 1일인 경우 해당 사이트 데이터베이스의 데이터가 인벤토리에 나타날 때까지 최대 이틀이 걸릴 수 있습니다. 따라서 MIF 파일을 만드는 프로그램을 보급할 시기와 하드웨어 인벤토리 사이클을 실행할 시기를 주의 깊게 고려해야 합니다.
Contoso라는 회사의 인벤토리 사이클 간격이 1일이고 사이클이 자정에 실행된다고 가정해 보겠습니다. 월요일 오전 1시에 VBScript가 실행되어 rootkit 스캐너의 출력이 포함된 NOIDMIF 파일을 만듭니다. 이 출력은 자정에 수집되어 관리 지점에 보고됩니다. Contoso의 SMS 관리자는 수요일 밤 10시 정도에 이 정보를 보고 정보가 45시간이나 지난 정보라는 사실을 알게 됩니다. 이는 SMS 관리자가 NOIDMIF 파일을 만드는 데 사용되는 프로그램을 보급하는 시기를 고려하지 않았기 때문에 발생한 결과입니다.

MOF 파일
MOF 파일은 MIF 파일보다 복잡하지만, WMI에 직접 정보를 입력하고 하드웨어 인벤토리 에이전트의 표준 데이터 수집 프로세스의 일부가 된다는 점에서 MIF 파일보다 우수합니다. 따라서 정보를 수집하기 위해 VBscript를 반복해서 보급할 필요가 없으므로 시간과 노력을 절약할 수 있습니다. 컴퓨터마다 MOF를 한 번씩 보급한 다음 컴파일할 수 있습니다.
MOF 파일은 하드웨어 인벤토리의 나머지 정보와 마찬가지로 정보를 최신 상태로 유지한다는 점에서도 MIF 파일보다 우수합니다. 하드웨어 인벤토리 에이전트에서 사이클을 실행할 때마다 MOF 파일에 있는 클래스와 공급자가 쿼리되어 해당 정보가 빠르게 반환됩니다. 빠른 시간 내에 정보를 봐야 할 경우에는 MOF 파일과 VBScript가 포함된 패키지를 실행하여 하드웨어 인벤토리를 시작할 수 있습니다. 그러면 보급된 프로그램의 정책 사이클 1회 내에 필요한 정보를 얻을 수 있습니다.
MOF 파일에는 기존 WMI 클래스 및 네임스페이스용, 기존 WMI 공급자가 있는 추가 클래스용, 그리고 WMI 공급자가 없는 추가 클래스용의 세 종류가 있습니다.
MOF 파일에는 두 부분이 포함됩니다. 첫 번째 부분은 네임스페이스 정의 섹션으로 여기에서는 WMI 공급자 정보를 확인할 수 있습니다. 두 번째 섹션에는 SMS 보고 특성이 포함됩니다. 이 섹션은 앞에서 언급한 WMI 클래스에 포함된 정보를 찾아서 처리할 위치를 하드웨어 인벤토리 에이전트에 알려 줍니다. MOF 파일은 WMI를 직접 다루므로 MOF 파일을 사용할 계획이라면 시간을 내서 Microsoft SDK(Software Development Kit)를 살펴보는 것이 좋습니다. 자세한 내용은 go.microsoft.com/fwlink/?LinkID=83121을 참조하십시오.
앞에서 분류한 각 MOF 파일은 정적 파일이거나 동적 파일입니다. 예를 들어 회사의 빌드 절차에서 시스템을 빌드한 사람, 사용된 서버의 빌드, 초기 빌드 버전, 컴퓨터가 빌드된 날짜 등에 관한 정보가 포함된 MOF 파일을 컴파일한 경우 MOF 파일은 정적입니다. 이러한 정보는 업데이트할 필요가 없으므로 직접 MOF 파일에 입력하고 mofcomp.exe를 사용하여 WMI에 컴파일할 수 있습니다. 이 작업이 이루어진 후에는 사이트 서버의 sms_def.mof 파일에 그룹 및 클래스 정보를 추가하여 하드웨어 인벤토리 에이전트의 검색 영역을 확장해야 합니다.
동적 MOF 파일은 수집된 정보를 WMI에 직접 쓰는 대신 WMI 공급자를 통해 데이터를 수집한다는 점을 제외하고는 정적 MOF 파일과 비슷합니다. WMI 공급자는 응용 프로그램 또는 서비스에서 WMI에 정보를 직접 입력할 수 있게 해 주는 플러그 인입니다. 이 공급자를 사용하면 레지스트리, 파일 위치, 설치 관리자 정보 같은 WMI 및 시스템의 다른 영역에 동적으로 액세스할 수 있습니다.
MOF 파일로 작업하는 경우에 WMI에 이미 있는 정보를 인벤토리 카탈로그에 더 많이 포함하면 하드웨어 인벤토리를 가장 쉽게 확장할 수 있습니다. 이는 sms_def.mof를 확장하거나 현재 비활성화되어 있는 추가 보고 클래스를 활성화하여 수행할 수 있습니다. sms_def.mof 파일은 \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv 폴더에 있습니다. 이렇게 하면 회사의 모든 장치가 다음 컴퓨터 정책 사이클에서 새로운 sms_def.mof를 가져와 정보를 수집하고 보고하기 시작합니다.
작업 난이도 측면에서 두 번째로 쉬운 방법은 기존 WMI 공급자를 사용하되 새 클래스를 만드는 것입니다. 그림 3에서는 이 방법의 예를 보여 줍니다. 이 예제에서는 기본 제공되는 레지스트리 공급자를 통해 로컬 장치의 HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper를 쿼리하는 동적 속성을 사용하여 CU_Desktop 클래스가 만들어집니다. 클라이언트에서 이 MOF 파일이 컴파일되고 나면 SMS_Def_Extension.mof(그림 4 참조)를 sms_def.mof에 추가해야 합니다. 이 파일에는 SMS가 장치에 대해 보고할지 여부, 그룹 이름, 클래스 ID, 하드웨어 인벤토리 에이전트가 보고할 정보를 찾기 위해 WMI에서 검토할 클래스 및 실제 값 등의 정보가 포함됩니다.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
또한 MOF 파일을 사용하면 WMI 공급자가 제공하지만 기본적으로 시스템에 포함되어 있지는 않은 정보에 액세스할 수 있습니다. 이러한 공급자를 사용하려면 클라이언트에서 MOF 파일을 컴파일하고 sms_def.mof를 확장하기 전에 WMI 공급자를 배포하고 설치해야 합니다.

요약
MIF와 MOF 파일은 정보를 빠르고 간편하게 수집하는 데 사용할 수 있는 강력한 도구입니다. 이 두 파일 형식은 테이블을 직접 수정할 필요 없이 SMS 데이터베이스에 정보를 쉽게 가져올 수 있는 프레임워크를 제공합니다. 상상력만 충분히 발휘한다면 거의 모든 정보를 인벤토리에 포함하고 보고할 수 있으며, 더 나아가 관리자는 중요한 정보를 사전에 수집할 수 있으므로 문제가 될 만한 상황을 미연에 방지할 수 있습니다.
MIF와 MOF 파일을 이해하는 데는 약간의 시간이 걸립니다. 그러나 다음의 유용한 리소스를 참조하면 이러한 파일을 사용하는 방법을 쉽게 배울 수 있습니다. 먼저 WMI 설명서 및 SDK와 Systems Management Server 2003 운영 가이드를 읽어 보십시오. 이러한 개념을 이해하려고 노력한다면 SMS 인벤토리 확장을 통해 훨씬 많은 것을 얻을 수 있을 것입니다.

Wes Dobry는 플로리다주 올랜도에서 대형 의료 회사의 컨설턴트 겸 네트워크 관리자로 근무하고 있습니다. 문의 사항이 있으면 wesdobry@wesdobry.com으로 연락하시면 됩니다.


 Management: SMS 2003 R2를 사용하여 사용자 지정 소프트웨어 배포
Management Steve Rachui

SMS 2003 R2를 사용하여 사용자 지정 소프트웨어 배포
한 눈에 보기:
  • SMS 2003 R2의 새로운 업데이트 관리 기능
  • 사용자 지정 업데이트 게시 도구
  • 사용자 지정 업데이트용 인벤토리 도구

특수 하드웨어나 LOB(기간 업무) 응용 프로그램 등을 위해 시스템에 사용자 지정 업데이트를 배포해야 할 경우에는 Windows 업데이트에서처럼 관리되는 자동 프로세스를 이용할 수 없습니다. 최소한 지금까지는 이런 방식으로 업데이트할 수 없었습니다. 그러나 이제는 사정이 달라졌습니다.
Systems Management Server(SMS) 2003 R2 덕분에 이러한 관리되는 업데이트 기능을 사용하여 고유의 사용자 지정 업데이트를 배포할 수 있게 되었습니다. SMS 2003 R2에는 장치 관리 기능 팩 업데이트, OSD(Operating System Deployment) 기능 팩 링크, 보안 모니터링을 개선하는 여러 가지 기능을 비롯하여 많은 새로운 기능이 포함되어 있습니다. 또한 이 제품에는 OS 구성, 사용자 암호, IIS 및 SQL Server™ 구성의 취약성과 같은 시스템 및 네트워크의 잠재적 취약성을 이해하는 데 중요한 역할을 하는 취약성 평가를 위한 검색 도구가 있으며, ITCU와 CUPT가 포함되어 있습니다. 이 문서에서는 고유한 사용자 지정 업데이트를 효율적으로 빠르게 배포하는 데 도움이 되는 이 두 가지 도구에 대해 중점적으로 살펴보겠습니다.

사용자 지정 업데이트 게시 도구
SMS 2003 R2를 설치하고 사용하려면 클라이언트를 비롯한 계층 구조를 SMS 2003 SP2(서비스 팩 2)로 업데이트해야 합니다. CUPT를 사용하려면 Microsoft® Management Console(MMC) 3.0으로 업그레이드해야 합니다. SMS 사이트 서버에 CUPT를 설치할 필요는 없지만 최소한 Windows® XP에는 CUPT를 설치해야 합니다. 또한 데이터베이스를 호스팅하려면 SQL Server 2005가 설치되어 있어야 하며 SQL Server 2005를 사용할 수 없는 경우에는 SQL Server Express Edition이 설치되어 있어야 합니다. CUPT는 SMS 시스템에서 사용자 지정 업데이트를 가져오고 관리하는 데 핵심 역할을 하며, 생성된 카탈로그를 SMS에 게시하기 전에 테스트할 수 있는 기능도 포함하고 있습니다.
사용자 지정 업데이트에는 소프트웨어를 만든 타사 공급업체에서 제공하는 업데이트와 특정 환경에 맞게 내부에서 만든 업데이트의 두 가지 형태가 있는데, CUPT는 이 두 종류의 업데이트를 관리하는 데 사용할 수 있는 도구입니다. 타사에서 제공하는 사용자 지정 업데이트를 사용하는 것이 가장 쉬우므로 먼저 이에 대해 살펴보겠습니다. 이 문서를 작성하는 시점을 기준으로 SMS에서 적합한 패치를 검색 및 배포하는 데 사용할 수 있는 업데이트 카탈로그를 생산하는 업체는 Adobe, 1e, Citrix 세 업체입니다. 그림 1과 같이 사용자 지정 업데이트 파트너 카탈로그를 선택하면 여기에 참여하고 있는 회사를 볼 수 있습니다.
그림 1 사용 중인 CUPT
그림 1 사용 중인 CUPT (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 사용 중인 CUPT
그림 1 사용 중인 CUPT (더 크게 보려면 이미지를 클릭하십시오.)
파트너가 제공하는 업데이트를 사용할 경우 카탈로그를 다운로드하여 SMS에 추가하기만 하면 됩니다. 먼저 필요한 업데이트를 다운로드한 다음 Action(작업) 메뉴에서 업데이트를 가져오는 옵션을 선택합니다. 그러면 다운로드한 .cab 파일의 위치를 묻는 메시지가 마법사에 표시됩니다. 마법사가 완료되고 CUPT에 새로운 업데이트가 표시되면 업데이트를 추가로 구성하여 SMS 사이트 서버에 게시할 수 있습니다. 이때 필요한 각 업데이트마다 업데이트가 게시용임을 나타내는 플래그를 지정해야 합니다. 업데이트에 플래그가 지정되지 않으면 게시 요청을 할 때 업데이트가 포함되지 않습니다. 업데이트에 플래그를 지정하는 작업은 그림 2와 같이 한 번에 수행할 수 있습니다. 맨 오른쪽 열에 플래그가 설정되어 있어야 업데이트가 게시됩니다.
그림 2 게시 플래그 설정
그림 2 게시 플래그 설정 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 게시 플래그 설정
그림 2 게시 플래그 설정 (더 크게 보려면 이미지를 클릭하십시오.)
필요한 경우 다운로드한 각 업데이트를 추가로 사용자 지정할 수 있습니다. 업데이트를 선택하고 Edit(편집)를 선택하여 설정을 지정하기만 하면 됩니다. 업데이트를 사용자 지정할 때는 구성이 적절하지 않으면 예기치 않은 결과가 발생할 수 있으므로 세심한 주의가 필요합니다.
업데이트에 플래그를 지정한 후에는 업데이트를 게시합니다. 업데이트를 외부 .cab 파일에 게시하여 나중에 사용할 수도 있고, 선택한 업데이트를 SMS 사이트 데이터베이스와 동기화하여 즉시 사용할 수도 있습니다. SMS 사이트 데이터베이스와 동기화하려면 사이트 서버 이름이나 패키지 원본 경로와 같은 구성 정보를 제공해야 합니다(그림 3 참조).
그림 3 동기화 정보
그림 3 동기화 정보 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 동기화 정보
그림 3 동기화 정보 (더 크게 보려면 이미지를 클릭하십시오.)
이 화면은 Custom Updates(사용자 지정 업데이트) 노드를 선택한 다음 Action(작업) 메뉴에서 Settings(설정)를 선택하면 볼 수 있습니다. 액세스 가능한 사이트 서버 이름과 사용자 지정 업데이트용 인벤토리 도구의 원본 디렉터리를 가리키는 경로를 제공하면 사이트 코드 및 상태가 업데이트됩니다.
동기화 옵션을 설정했으므로 이제 CUPT를 SMS 사이트 서버와 동기화할 수 있습니다. 동기화를 수행하려면 Action(작업) 메뉴에서 업데이트 게시 옵션을 선택합니다. 그러면 게시 마법사가 시작됩니다. 즉시 사용할 수 있도록 SMS 데이터베이스에 업데이트를 게시하려면 Systems Management Server의 사이트 데이터베이스와 동기화하는 옵션을 선택해야 합니다. 이 단계에서는 동기화 설정이 구성되었는지 여부를 쉽게 확인할 수 있습니다. 동기화 설정이 구성되어 있지 않으면 이 옵션은 회색으로 표시됩니다.
마법사가 완료되고 나면 SMS 관리 콘솔에서 사용자 지정 업데이트를 사용할 수 있습니다. Distribute Software Updates Wizard(소프트웨어 업데이트 배포 마법사)를 시작하면 사용 가능한 사용자 지정 업데이트로 작업할 수 있는 옵션이 표시됩니다.
지금까지 다른 공급업체에서 생산하는 제품의 업데이트를 사용하는 방법을 살펴보았습니다. 그렇다면 미리 패키지된 업데이트를 사용할 수 없는 경우 공급업체에서 제공하는 소프트웨어에 대해 사용자 지정 업데이트를 사용하려면 어떻게 해야 할까요? 이때 CUPT의 진가가 발휘됩니다. CUPT를 사용하면 거의 모든 상황에서 대상 조건을 모두 갖춘 사용자 지정 업데이트를 만들 수 있습니다.
사용자 지정 업데이트를 만드는 것은 그다지 어려운 작업은 아니지만 소프트웨어를 패치하는 방법, 패치의 적용 가능 여부를 결정하기 위해 사용할 조건, 업데이트 대상을 결정하는 데 사용할 대상 지정 규칙 등을 반드시 이해하고 있어야 합니다. 대상 지정 규칙은 업데이트 생성 프로세스와는 별도로 정의됩니다. 이러한 규칙은 Action(작업) 메뉴에서 Manage Rules(규칙 관리) 옵션을 선택하면 볼 수 있습니다.
사용자 지정 업데이트를 만들려면 먼저 Action(작업) 메뉴에서 Create Update(업데이트 만들기) 항목을 선택하여 사용자 지정 업데이트에 대한 세부 정보를 지정할 수 있는 마법사를 시작합니다. 사용자 지정 업데이트를 만드는 것에 대한 자세한 내용은 이 문서의 범위를 벗어나지만, 가져온 사용자 지정 타사 업데이트 중 하나에 대해 속성을 선택하면 고유의 업데이트를 만들 때 각 필드에 필요한 정보를 쉽게 이해할 수 있다는 것을 기억해 두시기 바랍니다. 그림 4에서는 구성된 타사 업데이트의 속성을 보여 줍니다.
그림 4 타사 업데이트의 속성
그림 4 타사 업데이트의 속성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 타사 업데이트의 속성
그림 4 타사 업데이트의 속성 (더 크게 보려면 이미지를 클릭하십시오.)
사용자 지정 업데이트 생성 프로세스를 사용하면 업데이트를 만들 수 있을 뿐 아니라 클라이언트 시스템에 배포할 수 있도록 소프트웨어를 구성할 수도 있습니다. 그러나 이 방법은 가능하기는 하지만 권장되지는 않으며 CUPT의 본래 용도도 아니라는 점을 기억하십시오.

사용자 지정 업데이트용 인벤토리 도구
ITCU는 사용자 지정 업데이트 카탈로그와 함께 사용되는 새로운 인벤토리 도구입니다. 이전의 검색 도구와 마찬가지로 ITCU는 기업의 SMS 클라이언트에 검색 도구를 배포하는 데 사용되는 사용자 지정 모음, 패키지 및 보급을 만듭니다. 또한 마찬가지로 액세스 가능한 SMS 배포 지점에서 카탈로그(이 경우 사용자 지정 업데이트 카탈로그)를 검색하고 카탈로그 데이터를 기반으로 검색을 수행하며 검색 결과를 Windows Management Instrumentation(WMI)에 삽입하고 하드웨어 인벤토리를 통해 그 결과를 보고합니다. 검색 프로세스에서 이전과의 주요 차이점은 사용되는 카탈로그에 있습니다.
SMS 2003 R2의 출시를 통해 기존의 SMS 보안 창고에 또 하나의 강력한 도구가 추가된 셈입니다. 이전에는 관리자가 기존 SMS 인프라를 활용하여 타사 및 사용자 지정 응용 프로그램을 패치할 수 없었습니다. 패치 관리를 담당하는 관리자에게 SMS R2는 매우 환영할 만한 기능입니다.
이제 이 두 도구를 통해 Microsoft 이외의 회사에서 제공하는 소프트웨어 업데이트를 원하는 대로 처리할 수 있게 되었습니다. CUPT와 ITCU가 제공하는 관리 효율성과 편리함은 항상 사용해 온 Windows 업데이트만큼 원활하게 사용자 지정 업데이트를 배포할 수 있도록 지원할 것입니다.
업데이트 관리 리소스
  • TechNet: 업데이트 관리
  • 웹 캐스트: 쇼 타임 - SMS 2003 R2
  • Microsoft 패치 관리를 위한 10가지 원칙

Steve Rachui는 Microsoft 기술 지원 서비스 그룹의 관리 효율성 지원 향상 엔지니어로, SMS 버전 1.2부터 SMS를 지원해 왔습니다. 문의 사항이 있으면 steverac@microsoft.com으로 연락하시면 됩니다.


 From The Editor: 교정 정책에 관하여...
From The Editor
교정 정책에 관하여...

인쇄물과 웹의 가장 큰 차이점 중 하나는 한번 인쇄한 인쇄물은 변경할 수 없다는 점입니다. 반면 웹에서는 정보를 게시한 후 나중에 필요에 따라 자유롭게 업데이트할 수 있습니다. 둘 다 나름대로 장단점이 있습니다.
물론 인쇄물은 웹과는 완전히 다릅니다. 일단 인쇄기에 들어가고 나면 되돌릴 방법이 없기 때문입니다. 한번에 수십만 부가 인쇄되며 인쇄된 내용은 책꽂이에서 인쇄물의 수명이 다할 때까지 또는 집을 이사할 때까지 머물러 있게 됩니다. 또한 인쇄물은 시간에 따라 차례로 발행되므로 가장 최근에 발간된 인쇄물에 가장 최신 기사가 실려 있음을 누구나 알 수 있습니다.
간행물이 발간된 후에 온라인에도 게시되면서부터 새로운 문제가 생겨났습니다. 온라인에서 검색하는 사용자의 입장에서 보면, 웹 사이트에 있는 모든 콘텐츠는 시간의 구분 없이 같은 시간에 게시되어 있는 것과 마찬가지입니다. 이러한 웹 콘텐츠 중에서 최신 정보는 어떻게 찾아야 할까요?
이 문제를 해결하기 위해 저희는 인쇄물을 온라인 독자에게 보다 효과적으로 제공할 수 있도록 하는 교정 정책을 몇 년 전에 수립했습니다. 즉, TechNet Magazine 교정 페이지에서 각 기사의 게시 후 변경 내용을 모두 확인할 수 있습니다. 기사가 업데이트되는 이유는 크게, 기술적 필요, 편집상의 필요, 새로운 정보 추가, 더 이상 적용되지 않는 정보의 삭제, 보안상의 이유로 나뉠 수 있습니다.
예를 들어 2006년 5월에 게시된 "데스크톱 이미지 생성을 단순화하는 기법" 기사에서는 아직 사용자에게 제공되지 않았던 CNIC라는 도구에 대해 언급했습니다. 이후 CNIC가 제공되었을 때 교정 페이지를 업데이트하고 온라인에 게시된 기사에 Editor's Update를 추가했습니다. 이 Editor's Update 링크를 클릭하면 새로 추가된 정보로 바로 이동합니다.
TechNet Magazine의 각 호는 매달 새로운 호로 대체되지만, 저희는 교정 정책을 통해 시간이 지나도 기사의 내용을 정확하게 유지하고 있습니다. -JOSHUA TRUPIN

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher 및 Alan von Weltin에게 감사를 전합니다.


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

파일 및 디렉터리 동기화
Allway Sync
allwaysync.com

IT 전문가들은 담당하고 있는 IT 업무에 관계없이 데스크톱에서 USB 키로 또는 네트워크를 통해 서버에서 서버로 파일과 디렉터리를 옮기는 데 많은 시간을 할애합니다. 중요한 것은 이러한 디렉터리를 동기화된 상태로 유지하여 불필요하게 중복된 파일을 만들지 않고 항상 최신 버전의 파일로 작업할 수 있게 만드는 것입니다. 일련의 웹 서버에 정적 XML 또는 HTML 파일을 배포하는 경우와 같이 여러 컴퓨터에서 파일과 디렉터리를 동기화해야 하는 경우가 있을 수 있습니다. Usov Lab의 Allway Sync를 사용하면 이러한 종류의 작업을 처리하는 데 도움이 됩니다.
Allway Sync는 단방향 파일 및 디렉터리 복제에서부터 양방향 다중 디렉터리 옵션에 이르기까지 진정한 n방향 동기화를 제공합니다. 또한 로컬 드라이브와 네트워크 리소스의 동기화 상태를 유지하는 기능 이외에도 USB 키와 다시 쓰기 가능 광 드라이브 같은 이동식 장치에 대한 자동 동기화도 지원합니다. 장치가 컴퓨터에 연결될 때 Allway Sync가 자동으로 시작되도록 할 수 있습니다.
동기화를 위한 기타 자동 시작 옵션으로는 파일 변경 사항이 감지되었을 때, 로그인 또는 로그아웃했을 때, Allway Sync가 시작되었을 때 그리고 지정된 시간 간격으로 시작 등이 있습니다. 응용 프로그램 GUI를 사용하여 예약된 작업과 동기화를 연결할 수도 있습니다.
Allway Sync를 사용한 파일 및 폴더 동기화
Allway Sync를 사용한 파일 및 폴더 동기화 (더 작게 보려면 이미지를 클릭하십시오.)
Allway Sync를 사용한 파일 및 폴더 동기화
Allway Sync를 사용한 파일 및 폴더 동기화 (더 크게 보려면 이미지를 클릭하십시오.)
모든 파일 수정 사항과 삭제 사항은 Allway Sync의 로컬 데이터베이스에서 추적되며 Allway Sync는 항목을 영구적으로 삭제하거나, 휴지통으로 이동하거나, 지정된 폴더로 이동하는 것을 비롯하여 수정된 파일에 버전을 지정하고 충돌하는 파일을 삭제하기 위한 여러 가지 옵션을 제공합니다.
작업마다 여러 개의 포함 또는 제외 필터를 지정하여 필요한 파일은 가져오고 필요하지 않은 파일은 무시할 수 있습니다. 또한 경고 또는 오류가 발생할 때 Allway Sync에서 취할 조치를 사용자 지정하고 경고 또는 오류의 유형별로 서로 다른 조치를 구성할 수 있습니다. 예를 들어 오류 발생 시 복사를 자동으로 다시 시도하도록 선택할 수도 있고 네트워크 대기 시간이나 일시적인 연결 문제를 고려하여 자동 재시도 횟수와 재시도 간 시간 지연을 구성할 수도 있습니다.
이 응용 프로그램에서는 로깅 기능의 자세한 표시 수준을 구성할 수 있으므로 작업에 대한 최대한의 정보를 얻을 수 있습니다. XML을 통해 응용 프로그램 설정을 가져오고 내보낼 수 있으므로 이러한 설정을 백업하거나 다른 컴퓨터로 전송하는 것이 간편합니다. 또한 흥미로운 기능으로 간단한 사용량 통계 창(Help 메뉴를 통해 액세스할 수 있음)도 제공합니다. 이 편리한 도구는 파일을 손쉽게 동기화할 수 있는 살펴볼 가치가 충분한 도구입니다.
가격: 개인적인 용도로 사용 시 무료이며 상업적인 용도로 사용 시 29.99달러입니다.

네트워크 매핑 및 모니터링
LANState Pro
10-strike.com/lanstate

네트워크 리소스의 상태와 가용성에 대한 빠른 액세스는 능동적인 IT 운영 환경에 필수적입니다. 따라서 IT 전문가는 발생한 문제에 대해 다른 사람보다 먼저 알고 있어야 합니다. 10-Strike Software의 편리한 LANState Pro 네트워크 매퍼 및 모니터는 Windows® 기반 네트워크에 사용할 수 있는 신속한 가상화 및 LAN 관리 기능을 제공합니다.
이 응용 프로그램을 시작하여 네트워크를 모니터링하는 경우 Network Mapping Wizard를 선택하여 네트워크 환경이나 해당 호스트에 대한 IP 주소 범위를 검색할 수 있으며, 원하는 경우 호스트에 수동으로 추가할 수 있습니다. 네트워크 맵이 만들어지면 LANState가 자동으로 TCP 포트 검사 또는 ICMP ping 검사와 같은 구성된 상태 검사를 시작합니다. 이 검사에서 응답이 있는 호스트는 색상으로 구분되고 응답이 없는 호스트는 회색으로 비활성화됩니다. 그런 다음 사용 중인 구성에 해당하는 논리적 그룹에 맵을 배열하고 시각적 요소를 변경하며 설명을 추가할 수 있습니다.
LANState Pro를 사용하여 논리적 네트워크 그룹 만들기
LANState Pro를 사용하여 논리적 네트워크 그룹 만들기 (더 작게 보려면 이미지를 클릭하십시오.)
LANState Pro를 사용하여 논리적 네트워크 그룹 만들기
LANState Pro를 사용하여 논리적 네트워크 그룹 만들기 (더 크게 보려면 이미지를 클릭하십시오.)
이 그리기 및 편집 도구는 다소 조잡하지만 맵이 완성되면 이를 파일로 저장할 수 있어 다시 만들 필요가 없습니다. TCP 포트 및 ICMP ping 검사 이외에도 구성 가능한 간격 및 시간 제한에 따라 폴더나 파일의 존재 여부, 파일 크기 또는 원격 호스트에서 사용 가능한 디스크 공간의 크기를 확인하도록 LANState Pro를 구성할 수 있습니다. 호스트를 마우스 오른쪽 단추로 클릭하면 경로 추적 수행, ping 전송, 기본 검사 수행, 네트워크 메시지 보내기를 비롯한 원격 호스트에서 보다 많은 시스템 정보를 수집할 수 있는 상황에 맞는 메뉴가 표시됩니다.
시스템 정보 보기에는 NIC MAC 주소의 모든 항목 및 네트워크 공유, 서비스 및 로컬 계정에 대한 바운드 IP 주소가 표시됩니다. 대부분의 OS 수준 정보에는 원격 시스템에 대한 적절한 권한과 열린 포트가 필요한데 RPC 호출을 통해 유용한 데이터를 확인할 수 있습니다. 그리고 권한을 가지고 있는 경우 원격 호스트에 원격 전원 켜기 및 시스템 종료 신호를 보낼 수도 있습니다.
가격: 단일 사용자 라이선스당 249.95달러

명령줄 스크립팅
서평
www.syngress.com

대화형 마법사 및 구성 GUI는 복잡한 작업을 정말로 간단하게 만들어줍니다. 그러나 IT 전문가에게 이러한 인터페이스는 작업을 느리게 만들고 세밀한 제어를 어렵게 만드는 요소이기도 합니다. 다행히도 거의 대부분의 경우 명령줄 인터페이스(CLI)를 통해 이러한 수준의 제어가 가능합니다. Windows에 포함된 도구에 익숙해지고 명령 프롬프트 사용자 지정 방법을 익혀 관리 작업을 원활하게 수행할 수 있게 되면 시간 절약, 효율성 증대 및 보다 정확한 제어 효과를 경험할 수 있습니다. Pawan K. Bhardwaj가 집필한 How to Cheat at Windows System Administration Using Command Line Scripts(Syngress 출판, 2006)를 통해 CLI 및 OS 유틸리티를 마스터해보십시오.
이 책에서는 명령 셸 사용자 지정, 자동화를 위한 배치 파일 사용, 예약된 작업의 일괄 처리 및 CLI 관리에 대해 소개합니다. 이러한 내용을 설명한 후에는 디스크, 파일 및 디렉터리 관리에 도움되는 Windows OS에 포함된 유틸리티를 소개합니다. 또한 이전 장에서 다룬 일괄 처리 기술과 함께 사용할 경우 대용량의 디렉터리 구조를 관리하는 데 걸리는 시간을 절약할 수 있는 DSQuery 및 DSMod와 같은 Directory Services 명령에 대한 개요도 제공합니다.
또한 Netstat에서 Pathping에 이르는 다양한 Windows Networking 명령을 익히고 TFTP, RSH, RCP와 같은 원격 연결 도구에 대한 개요도 확인할 수 있습니다. 다시 말하지만 자동화 및 예약된 작업과 관련하여 이 책의 첫째 단원에서 다룬 기술과 이러한 도구를 함께 사용하면 분명히 생산성을 증대시킬 수 있습니다. 이러한 점에서 Bhardwaj의 이 책은 Windows 유틸리티에 대한 종합적인 참조서는 아니지만 유용한 서적임에 분명입니다.
가격: 39.95달러

하드웨어 안정성 테스트
BurnInTest
passmark.com/products/bit.htm

맞춤형 PC 생산, 고객별 맞춤 하드웨어 구성 요소 업데이트 수행, 새로운 수퍼 관리자 데스크톱 장치 구성 등의 작업을 수행할 때는 새로운 구성 요소를 사용자에게 전달하기 전에 해당 구성 요소가 안정적인 성능을 보이는지 확인하는 것이 중요합니다. PassMark Software의 BurnInTest는 지정한 구성 요소에 대해 여러 개의 서로 다른 스트레스 테스트를 실행하여 전달 시 오류가 발생하지 않도록 하므로 이러한 목적에 부합됩니다.
다른 스트레스 테스트 소프트웨어와 마찬가지로, 이 응용 프로그램은 짧은 시간 동안 오랜 작업 주기를 시뮬레이션하기 위해 선택적인 시스템 구성 요소에 부하를 주어 하드웨어를 "사용"합니다. 이는 시스템이나 장치가 시작되기 전에 잠재된 오류를 발견하기 위한 것입니다. BurnInTest를 사용하면 CPU 및 그래픽 카드 메모리에서 하드 드라이브 및 CD 버너에 이르는 모든 항목을 테스트할 수 있습니다.
이 응용 프로그램은 사용과 구성이 매우 간편하여 특정 구성에 있는 각 구성 요소 단위 테스트에 대한 듀티 사이클과 기본 설정을 변경할 수 있습니다. 테스트 구성을 설정한 후에는 기본 설정을 저장하여 나중에 다시 사용할 수 있으므로, 몇 달이 지난 후에도 동일한 테스트를 빠르게 실행할 수 있습니다.
각 테스트에는 구성 가능한 듀티 사이클이 있으므로 테스트할 각 구성 요소에 대해 1 – 100 범위의 로드 값을 설정할 수 있습니다. 예를 들어 CPU 수학 연산 작업은 75% 로드에서 테스트하고, 동시에 시스템 메모리에 대해서는 90% 로드를 테스트할 수 있습니다. 또한 지정한 분 단위 시간이 흐른 다음이나 작업 주기 횟수를 수행한 후에 BurnInTest를 중지하도록 설정할 수 있습니다.
이 응용 프로그램을 사용하면 하드 드라이브, 플로피 드라이브 및/또는 광 드라이브를 동시에 20개까지 테스트할 수 있으므로 이러한 드라이브를 일괄 테스트한 다음 클라이언트 환경에 배포할 수 있습니다. 따라서 모든 시스템을 개별적으로 테스트할 필요 없이 각각의 새 구성 요소를 한 번에 테스트할 수 있으므로 시스템 구성 요소를 업그레이드할 때 시간을 크게 절약할 수 있습니다. 이 프로그램은 SMART 매개 변수 검사 기능도 제공합니다.
Professional Edition은 USB 2.0, 병렬 포트 및 직렬 포트에 대해 다양한 루프백 테스트를 지원합니다. 하드웨어 루프백 장치는 PassMark에서 구매할 수 있습니다. 이 버전의 BurnInTest는 CD 또는 USB 키 드라이브에서 실행할 수 있기 때문에 테스트할 시스템에 응용 프로그램이 미치는 영향이 줄어들어 수행할 테스트의 신뢰성을 높여줍니다.
가격: Professional Edition 49달러, Standard Edition 24달러

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


 SQL Q&amp;A: 인덱스 다시 작성, 디스크 큐 길이 외
SQL Q&A
인덱스 다시 작성, 디스크 큐 길이 외
편집자: Nancy Michell

Q: SQL Server 인덱스는 어떻게 다시 작성됩니까? DBCC DBREINDEX 명령이 디스크 공간을 모두 사용하는 이유와 이 명령이 실패해도 디스크 공간이 해제되지 않는 이유를 알고 싶습니다. 현재 데이터베이스 크기는 90GB이고 가장 큰 테이블은 70GB입니다.
사용 가능한 공간을 10% 남겨두고 DBCC DBREINDEX 명령을 실행하면 사용 가능한 디스크 공간이 모두 사용되고 명령이 실패합니다. 처음에는 데이터베이스 파일이 90GB였는데 DBCC 명령이 실패하면 데이터베이스 파일이 160GB로 늘어나서 증가된 70GB가 해제되지 않습니다. 따라서 이 공간을 다시 확보하기 위해 수동으로 데이터베이스를 여러 번 축소해야 합니다.
이 명령이 제대로 작동해도 데이터베이스 파일의 크기가 160GB가 되고 몇 시간 후 자동 축소를 통해 공간이 자동으로 해제됩니다. DBREINDEX 대신 조각 모음을 수행하면 공간 소모를 줄일 수 있을까요? 클러스터형 인덱스는 없으며 단순 복구 모드를 사용하고 있습니다.
A: 쉽게 말해서 새 인덱스 복사본을 만든 다음 이전 인덱스를 삭제하면 인덱스가 다시 작성됩니다. 따라서 잠깐 동안은 인덱스 복사본이 두 개가 되는 것입니다. 새 인덱스를 만들기 위해서는 원본 인덱스를 만들 때만큼의 데이터베이스 파일 공간이 필요하며, 다시 작성에서 정렬 작업이 필요할 경우에는 정렬을 위해 인덱스 크기의 20%가 추가로 필요합니다.
따라서 최악의 경우 인덱스를 다시 작성하는 데 원래 인덱스 공간의 1.2배가 필요하게 됩니다. 데이터베이스 파일에 사용 가능한 공간이 충분하지 않을 경우 작업이 진행되면 파일 크기가 늘어나야 합니다. 따라서 자동 증가 기능이 설정되어 있지 않거나 디스크 볼륨의 공간이 충분하지 않을 경우 사용 가능한 공간이 부족하여 다시 작성 작업이 실패하게 됩니다.
다시 작성 작업의 실패 여부와 관계없이 작업이 완료된 후 데이터베이스 파일에 할당된 추가 공간이 해제되지 않습니다. 이 공간은 정규 데이터베이스 작업에 사용될 것입니다.
수동으로든 자동으로든 축소를 실행하면 알고리즘 작동 방식 때문에 거의 인덱스 조각화가 발생합니다. 자세한 내용은 SQL Server 저장소 엔진을 참조하십시오. 정규 작업을 위해 데이터베이스에 공간이 필요할 경우에 자동 축소를 수행하면 자동 증가-자동 축소-자동 증가-자동 축소 순환에 빠져 조각화 및 성능에 악영향을 주므로 특히 성능이 저하될 수 있습니다.
DBCC INDEXDEFRAG(SQL Server™ 2005의 경우 ALTER INDEX ... REORGANIZE)를 사용하면 데이터베이스 파일 공간을 추가로 소모하지 않는다는 이점이 있지만 인덱스 다시 작성보다 시간이 더 오래 걸리며 트랜잭션 로깅이 훨씬 더 많이 생성됩니다. DBCC INDEXDEFRAG는 사용 중인 복구 모드와 상관없이 항상 완전 로그되지만, 단순 복구 모드에서 인덱스 다시 작성은 대량 로그됩니다. 각 방법에는 여러 가지 장단점이 있는데 이에 대해서는 SQL Server 인덱스 조각 모음을 위한 최선의 방법 백서에 자세히 설명되어 있습니다.
조각화 해결 방법을 결정하기 전에 먼저 조각화를 해결할지 여부를 결정하십시오. 인덱스가 사용되는 작업 유형에 따라 조각화가 성능에 별 영향을 주지 않을 수 있으므로 조각화를 해결하는 것이 리소스 낭비가 될 수 있습니다. 자세한 내용은 위 백서를 참조하십시오.
결론: 현재 환경에 가장 적합한 조각화 제거 방법을 선택하고 조각화를 제거하면 쿼리 성능에 도움이 됩니다.

Q: 두 SQL Server 2005 인스턴스 간의 데이터베이스 미러링을 성공적으로 구성했습니다. 응용 프로그램은 SQL Server 로그인을 사용하여 SQL Server에 연결되어 있으며 ADO 및 SQL Native Client를 사용하여 작성되었습니다. 연결 문자열과 연결 설정에는 적절한 장애 조치 파트너를 비롯하여 올바른 정보가 지정되어 있습니다. 또한 주 서버의 것과 동일한 모든 로그인을 미러 서버에도 만들었습니다. 데이터베이스 오류를 테스트하면 미러 서버 인스턴스가 성공적으로 주 서버 역할을 수행하며 이 SQL Server 인스턴스에서 모든 사항이 올바르게 작동하는 것으로 보입니다. Windows® 로그인을 사용하여 미러 서버 인스턴스에 연결할 수도 있습니다. 그런데 응용 프로그램이 다음과 같은 오류와 함께 다시 연결되지 않습니다.
Cannot open database "<db name>" requested by the login. The login failed.
로그인이 새로운 주(원래 미러) 데이터베이스의 사용자와 연결되어 있지 않은 것 같습니다. sp_change_users_login을 실행하여 데이터베이스의 로그인과 사용자를 동기화했는데 여러 명의 분리된 사용자를 수정했다는 메시지가 표시되었습니다. 그런 다음 응용 프로그램이 새로운 주 서버에 성공적으로 다시 연결되었습니다. 장애 조치를 여러 번 시도해 봤는데 그때마다 로그인과 사용자 간의 연결이 손실됩니다.
이러한 문제 없이 미러링 설정을 구성하는 방법이 있습니까?
A: 예. 이 문제는 로그인의 이름은 같지만 각 서버의 SQL Server 로그인에 대한 SID(보안 식별자)가 일치하지 않기 때문에 발생합니다. Windows/도메인 사용자/그룹 로그인에 대한 SID는 사용자/그룹의 도메인 SID에 따라 만들어지므로 사용자/그룹이 어떤 SQL Server 서버에 추가되어도 해당 사용자/그룹에 대해 동일하기 때문에 Windows/도메인 사용자/그룹 로그인에서는 문제가 되지 않습니다.
sp_change_users_login 동기화 단계를 수행하지 않기 위해서는 미러 서버에 주 서버의 것과 이름뿐 아니라 SID도 동일한 SQL Server 로그인을 만들어야 합니다. 미러 서버에 로그인을 만들 때는 다음과 같이 CREATE LOGIN 문에 SID를 지정하면 됩니다.
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
sys.sql_logins 카탈로그 뷰를 쿼리하면 주 서버에서 각 로그인에 대한 SID를 검색할 수 있습니다. 지정된 서버에 각 SQL Server/Windows 로그인에 대한 실제 CREATE LOGIN 문을 생성하는 쿼리의 예가 그림 1에 나와 있습니다.
Figure 1 CREATE LOGIN 문 생성 (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

Q: 평균 디스크 큐 길이는 어떻게 계산해야 합니까? 예를 들어 RAID 01 구성으로 SAN(Storage Area Network)에 별도의 실제 스핀들 20개가 있는 경우 평균 디스크 큐 길이는 어떻게 계산합니까? 평균 디스크 큐 길이/20입니까 아니면 평균 디스크 큐 길이/2입니까?
A: 우선 SAN 환경에서 평균 디스크 큐 길이를 계산하기 전에 디스크 대기 시간을 확인해야 합니다. 그러나 대기 시간은 어떤 것을 계산하려고 하는지에 따라 달라지는데 그 이유는 잠시 후에 알게 될 것입니다.
성능 모니터에서 이 카운터에 대한 설명은 "Avg. Disk Queue Length는 샘플 간격 동안 선택된 디스크에 대해 큐에 있는 읽기 및 쓰기 요청의 평균 수입니다."라고 나옵니다. 이 카운터는 실제 디스크 또는 논리적 디스크 카운터이므로 기본 저장소가 운영 체제에 제공되는 방식에 따라 값이 달라집니다.
지금부터 질문 내용에 대해 살펴보겠습니다. RAID 01 구성으로 20개의 스핀들을 사용하고 있는데 이는 스핀들이 스트라이프된 후 미러링되었거나 01 또는 10을 읽는 방식에 따라 미러링된 후 스트라이프되었음을 의미합니다. 스토리지 배열에서 중요한 점은 스트라이프 집합에는 10개의 스핀들이 있다는 것입니다.
그러나 현재는 스트라이프 크기, 쓰기 크기, 실행할 I/O의 종류(읽기, 쓰기, 순차 또는 임의)와 같은 필수 정보가 없습니다.
따라서 일단 누락된 정보를 무시하고 계산해 보겠습니다. 평균 디스크 큐 길이가 10일 경우 OS에서는 10개의 I/O를 디스크 배열 큐에 배정합니다. 이론적으로는 스트라이프에 있는 10개의 미러링된 집합 각각에 대해 I/O가 한 개씩 있거나 한 디스크에 대해 10개의 I/O가 모두 있을 수 있습니다. 그러나 이 중 어떤 것이 해당되는지는 확인할 수 없습니다.
이번에는 누락된 정보를 포함하여 스트라이프 크기는 64KB이고 쓰기 크기는 8KB이며, 전체적으로 순차 쓰기를 수행한다고 가정해 보겠습니다. 이는 SQL Server 저장소 작업의 일반적인 시나리오입니다. 이 경우 전체 I/O 중 8개는 첫 번째 디스크에 배정되고 다음 두 개의 I/O는 다음 디스크에 배정될 수 있습니다. 따라서 이 시나리오에서 디스크당 디스크 큐 길이는 첫 번째 디스크는 8, 두 번째 디스크는 2, 배열에 있는 나머지 8개의 디스크는 0이 됩니다.
이제 이론적 스트라이프 크기는 8KB로, 쓰기 블록 크기는 64KB로 변경하고 디스크 큐 길이는 10으로 유지해 보겠습니다. 이 경우 각 64KB 블록은 8개 디스크에 분산되므로 한 개의 I/O가 8개의 디스크에 쓰여지고 큐에 있는 10개의 I/O는 배열에 있는 10개의 디스크에 대해 80개의 디스크 쓰기로 분산됩니다. 따라서 배열의 디스크당 디스크 큐 길이를 계산해 보면 배열의 각 디스크에 대해 8이 됩니다
현실적인 관점에서 또 다른 불확실성도 감안해 보겠습니다. 대부분의 경우 SAN 저장소는 서버에 연결될 때 서버에 있는 한 개 이상의 HBA를 사용하거나, 여러 개의 파이버를 사용하여 HBA를 SAN에 연결하거나, SAN의 프런트 엔드에 있는 여러 포트를 사용하거나, 서버와 SAN 간 패브릭에 있는 여러 유형의 파이버를 사용합니다. 이제 SAN 내에 있는 버스의 내부 아키텍처와 SAN 프런트에 있는 포트에 디스크가 연결되는 방식을 참작할 수 있습니다.
성능 모니터에 보고된 큐가 있다면 이는 대기 시간이 높거나, OS에서 디스크 큐 길이를 측정하는 위치와 디스크 표면 사이의 어느 지점에 큐가 있음을 나타냅니다. 이런 이유 때문에 대기 시간을 확인한 다음 평균 디스크 큐 길이가 아닌 이 카운터에 따라 결정을 내려야 합니다.

Q: 트랜잭션 복제를 사용하고 있으며 구독자의 테이블에서 여러 개의 행이 수동으로 변경된 것을 알고 있습니다. 따라서 게시자가 구독자에 더 이상 존재하지 않는 행을 업데이트하려고 하면 오류가 표시됩니다.
전체 스냅숏을 다시 적용하는 대신 복제를 통해 해당하는 한 개의 게시자 테이블만 다시 초기화할 수 있는 방법이 있는지 알고 싶습니다. tablediff 함수를 사용하면 제가 원하는 작업을 할 수 있을 것 같아 살펴봤지만 이 함수가 복제에 어떤 영향이 있을지 의문입니다.
예를 들어 tablediff 함수가 게시자 테이블의 스냅숏을 제때에 만들어 이를 구독자의 해당 테이블과 비교합니까? 데이터의 일관성을 보장하기 위해 복제를 중지하고 tablediff 유틸리티를 사용해야 합니까? 이 밖에도 알아야 할 사항이 있습니까?
A: 우선 tablediff는 게시 테이블 또는 구독 테이블의 리터럴 스냅숏을 만들지 않습니다. 이러한 시나리오를 위해 살펴볼 수 있는 두 가지 선택 사항이 있습니다.
첫 번째 방법은 일시적으로 복제를 중지하고 유틸리티를 실행하는 것입니다. 사용자가 데이터를 수정하는 것이 걱정되면 -sourcelocked 및 -destinationlocked 매개 변수를 사용하면 됩니다. 이 두 매개 변수는 유틸리티가 실행되는 동안 두 테이블에 배타적 잠금을 설정합니다. 이 방법이 적절하지 않으면 복제가 실행 중인 동안 -rc 및 -ri 매개 변수를 확인하는 방법이 있습니다. 이 방법은 tablediff를 한 번 실행한 후 오류가 발생할 때 이를 연속으로 실행하여 복제 전파가 지연될 경우 발생할 수 있는 오류를 방지합니다. 그러나 이 방법을 사용할 경우 복제 지연 정도에 따라 구독자에서 변경된 행 일부를 감지하지 못할 수도 있다는 점에 유의하십시오.

기술적 자문을 주신 Microsoft IT 전문가: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe, Steven Wort.


 Utility Spotlight: Autoruns
Utility Spotlight
Autoruns
Lance Whitney
이 기사의 코드 다운로드: Autoruns (490KB)

Windows®를 실행하는 일반 PC는 시작 시 파일, 드라이버, 작업, 서비스를 비롯한 다양한 항목을 로드합니다. 그러나 때로는 특정 시작 항목을 확인하고 비활성화하여 시작 시 충돌 문제를 해결하거나 자동 시작 시퀀스에 있는 맬웨어를 추적하거나 Windows 시작 시간을 단축하거나 메모리와 시스템 리소스를 확보해야 합니다.
시스템 구성 유틸리티(msconfig.exe)를 사용하면 다양한 시작 파일과 서비스를 확인하고 비활성화할 수 있지만, 이 유틸리티에는 도구 모음, 브라우저 도우미 개체, Windows 탐색기 셸 확장과 같은 항목을 처리하는 방법이 없습니다. 또한 msconfig는 이러한 항목에 대한 세부 사항을 제공하지 않습니다. 시작 시 로드되는 모든 항목을 확인하고 관리하는 보다 나은 방법은 Sysinternals의 Autoruns를 사용하는 것입니다.
Autoruns는 Mark Russinovich와 Bryce Cogswell이 작성한 무료 유틸리티로서, Windows 기반 PC에 있는 모든 시작 항목(이미지라고도 함)을 찾아냅니다. 이 유틸리티를 사용하면 시작 폴더, 레지스트리 및 숨겨진 기타 영역에 저장된 모든 이미지를 확인할 수 있습니다(그림 1).
그림 1 Autoruns를 통한 시작 항목 확인
그림 1 Autoruns를 통한 시작 항목 확인 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Autoruns를 통한 시작 항목 확인
그림 1 Autoruns를 통한 시작 항목 확인 (더 크게 보려면 이미지를 클릭하십시오.)
Autoruns는 각 이미지의 이름과 위치를 표시하는데, 파일의 경우 디렉터리 경로를 표시하며 레지스트리의 경우 정확한 키를 표시합니다. 또한 항목의 버전 데이터에 따라 게시자의 이름과 간략한 설명도 표시합니다. 항목을 두 번 클릭하면 해당 디렉터리나 레지스트리 키로 이동하고, 마우스 오른쪽 단추를 클릭하면 추가 옵션이 표시된 팝업 메뉴가 열립니다. 이 팝업 메뉴에는 자세한 버전 정보를 제공하는 표준 파일 속성 창을 표시하는 Properties 명령이 포함되어 있습니다. "Include Empty Locations" 옵션을 사용하면 포함하는 항목이 있는지 여부에 관계없이 PC의 모든 시작 영역을 표시할 수 있습니다. 또한 PC의 다른 사용자 계정을 선택하여 해당 계정의 시작 환경을 확인할 수도 있습니다.
Verify 명령을 사용하면 항목의 디지털 서명을 확인할 수 있습니다. 이 명령은 인증서 해지 목록(CRL)을 참고로 웹 사이트를 쿼리하여 이미지에 디지털 서명이 있는지, 서명이 유효한지 확인합니다. "Hide Signed Microsoft Entries" 옵션은 타사 이미지를 중점적으로 확인할 수 있도록 Microsoft에서 이미 서명한 항목을 제외시킵니다.
전체 시작 항목 목록을 텍스트 파일로 내보낼 수 있습니다. 이 기능은 원하는 항목을 비활성화하고 시작 환경을 조정하기 전에 스냅숏을 보관하려는 경우 편리하게 사용할 수 있습니다. 그런 다음 수정된 시작 구성과 내보낸 텍스트 파일을 비교하면 변경 내용을 확인할 수 있습니다.
Autoruns는 다음과 같은 몇 가지 시작 범주를 지원합니다.
Logon 해당 사용자와 모든 사용자의 시작 폴더 및 레지스트리에 있는 실행 키가 포함됩니다.
Explorer 탐색기 셸 확장, 도구 모음 및 활성 설정 실행 목록이 포함됩니다.
Internet Explorer 브라우저 도우미 개체 및 Internet Explorer® 도구 모음과 확장이 포함됩니다.
LSA Providers 로컬 보안 기관 인증, 알림 및 보안 패키지가 포함됩니다.
Autoruns에서는 시작 항목을 영구적으로 삭제하거나 비활성화할 수 있습니다. Online Search 옵션을 사용하면 안전하게 비활성화할 수 있는 항목을 찾을 수 있습니다. 이 옵션은 항목이나 항목 범주를 설명하는 웹 페이지에 대한 인터넷 검색을 실행하여 시작 목록에서 해당 항목을 삭제할 것인지 여부를 안내합니다. 비활성화된 항목은 레지스트리나 하드 드라이브의 백업 위치로 이동합니다.
Autoruns는 Windows XP 64비트 Edition과 Windows Server® 2003 64비트 Edition을 비롯한 모든 Windows 버전에서 작동하며, microsoft.com/technet/technetmag/code07.aspx에서 구할 수 있습니다

Lance Whitney는 IT 컨설턴트 겸 강사이자 테크니컬 라이터로, Windows 워크스테이션과 서버를 조정하는 데 많은 시간을 할애하고 있습니다. 원래 저널리스트였던 그는 15년 전 IT 업계에 뛰어들었습니다.


 The Cable Guy: Windows Vista의 무선 그룹 정책 설정
The Cable Guy
Windows Vista의 무선 그룹 정책 설정
Joseph Davies
이 칼럼에는 Windows Server "Longhorn"에 대한 시험판 정보가 수록되어 있으며 정보는 변경될 수 있습니다.

Active Directory 네트워크의 모든 컴퓨터에 대한 무선 네트워크 설정을 중앙 집중식으로 구성하고 배포할 수 있다면 관리자의 작업이 훨씬 수월해질 것입니다. 다행히도 Windows에서는 이를 가능하게 하는 특별한 컴퓨터 구성 그룹 정책 확장을 지원합니다.
이 확장은 무선 네트워크(IEEE 802.11) 정책 확장이라고 하는데, 현재 Windows Vista™, Windows® XP, Windows Server® 2003 및 차기 버전의 Windows Server(코드명 "Longhorn")에서 지원됩니다.
이 확장이 어떻게 작동하는지 알아보겠습니다. 이 그룹 정책 확장의 무선 설정은 도메인에 참가하거나 이러한 운영 체제를 시작할 때, 그리고 그 이후에 계속하여 자동으로 다운로드되고 적용됩니다. 그룹 정책 개체 편집기 스냅인의 컴퓨터 구성 | Windows 설정 | 보안 설정 | 무선 네트워크(IEEE 802.11) 정책 노드에서 도메인 기반 그룹 정책 개체에 대한 무선 정책을 구성할 수 있습니다.
그림 1은 Windows Server 코드명 "Longhorn" 도메인 또는 802.11Schema.ldf 및 802.3Schema.ldf 스키마 확장 파일로 스키마가 확장된 Windows Server 2003 도메인에 대한 무선 네트워크(IEEE 802.11) 정책 노드의 위치를 보여 줍니다. 스키마 확장 파일에 대한 자세한 내용은 microsoft.com/technet/network/wifi/vista_ad_ext.mspx를 참조하십시오.
그림 1 무선 네트워크(IEEE 802.11) 정책 노드
그림 1 무선 네트워크(IEEE 802.11) 정책 노드 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 무선 네트워크(IEEE 802.11) 정책 노드
그림 1 무선 네트워크(IEEE 802.11) 정책 노드 (더 크게 보려면 이미지를 클릭하십시오.)
기본적으로는 무선 네트워크(IEEE 802.11) 정책이 없으므로 새로 만들어야 합니다. 새 정책을 만들려면 콘솔 트리에서 무선 네트워크(IEEE 802.11) 정책을 마우스 오른쪽 단추로 클릭한 다음 새 Windows XP 정책 만들기 또는 새 Windows Vista 정책 만들기를 클릭합니다. 각 정책 유형별로 하나의 정책만 만들 수 있지만, 각 정책에는 여러 무선 네트워크의 설정이 포함될 수 있습니다.
Windows XP 정책의 경우 정책 설정은 필자의 2003년 7월 칼럼에서 설명한 설정과 매우 비슷합니다. 그러나 non-broadcast 무선 네트워크, WPA2(Wi-Fi Protected Access 2) 인증 방법 및 WPA2 인증을 위한 빠른 로밍 설정에 대한 새로운 옵션이 있습니다. 이러한 새로운 설정을 지원하려면 Windows XP SP2(서비스 팩 2)를 실행하는 컴퓨터에 support.microsoft.com/kb/917021의 Windows XP SP2용 무선 클라이언트 업데이트를 설치해야 합니다.
Windows Vista 무선 정책에는 Windows Vista와 Windows Server "Longhorn" 무선 클라이언트에 고유한 정책 설정이 포함되어 있습니다. 두 유형의 무선 정책을 모두 구성하면 Windows XP 무선 클라이언트와 Windows Vista 무선 클라이언트가 모두 자체 정책 설정만 사용하게 됩니다. Windows Vista 정책 설정이 없으면 Windows Vista 무선 클라이언트는 Windows XP 설정을 사용합니다. 이 기사에서는 Windows Vista 무선 정책으로 구성할 수 있는 설정에 대해 설명합니다.
Windows Vista 무선 네트워크 정책의 일반 탭에서는 정책의 이름과 설정을 구성하고, WLAN AutoConfig 서비스의 사용 여부를 지정하고, 무선 네트워크 프로필 및 설정의 목록을 원하는 순서로 구성할 수 있습니다(그림 2 참조). 또한 프로필을 선택하고 내보내기를 클릭하여 프로필을 XML 파일로 내보낼 수도 있습니다. XML 파일을 무선 프로필로 가져오려면 가져오기를 클릭한 다음 파일 위치를 지정합니다.
그림 2 무선 네트워크 정책 속성
그림 2 무선 네트워크 정책 속성 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 무선 네트워크 정책 속성
그림 2 무선 네트워크 정책 속성 (더 크게 보려면 이미지를 클릭하십시오.)
그림 3은 기본 설정 상태의 Windows Vista 무선 네트워크 정책의 네트워크 권한 탭을 보여 줍니다. Windows Vista에 새로 추가된 이 탭에서는 이름을 사용하여 무선 네트워크를 지정하고 해당 네트워크에 대한 액세스를 허용하거나 거부할 수 있습니다. 예를 들어 Windows Vista 무선 클라이언트의 연결을 허용하는 SSID(Service Set Identifier)라고도 하는 무선 네트워크 이름이 포함된 허용 목록을 만들 수 있습니다. 이러한 목록은 네트워크 관리자가 조직의 랩톱 컴퓨터에서 무선 네트워크 및 인터넷 서비스 공급자를 포함하는 일련의 특정 무선 네트워크에 연결하도록 하려는 경우에 유용합니다.
그림 3 네트워크 권한 탭
그림 3 네트워크 권한 탭 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 네트워크 권한 탭
그림 3 네트워크 권한 탭 (더 크게 보려면 이미지를 클릭하십시오.)
거부 목록을 사용하면 무선 클라이언트의 연결이 허용되지 않는 일련의 무선 네트워크를 이름으로 지정할 수 있습니다. 이 목록은 관리되는 랩톱 컴퓨터가 범위 내의 다른 무선 네트워크에 연결하지 못하도록 할 때 유용합니다. 예를 들어 건물 한 층을 사용하고 있는 조직에서 인접 층에 있는 타 조직의 다른 무선 네트워크에 액세스하지 못하도록 할 때 효과적입니다. 또한 거부 목록을 사용하면 관리되는 랩톱 컴퓨터가 안전하지 않은 것으로 알려진 무선 네트워크에 연결하는 것을 방지할 수 있습니다. 액세스를 허용하거나 거부할 개별 무선 네트워크를 지정하거나 목록을 만들려면 추가를 클릭하여 이름으로 무선 네트워크를 추가하고 허용 여부를 지정합니다.
네트워크 권한 탭에는 애드혹 무선 네트워크 또는 인프라 모드 무선 네트워크에 연결하지 못하도록 하는 설정도 있습니다. 또한 거부되도록 구성된 무선 네트워크를 볼 수 있게 하거나 모든 사용자 프로필을 만들 수 있게 할 수도 있습니다. 모든 사용자 프로필은 컴퓨터에 계정이 있는 사용자가 특정 무선 네트워크에 연결할 때 사용할 수 있습니다. 이 설정을 사용하지 않도록 설정하면 Network Administrators 그룹 또는 Network Operators 그룹의 사용자만 컴퓨터에서 모든 사용자 무선 프로필을 만들 수 있습니다.

무선 네트워크 프로필 속성
Windows Vista 무선 정책의 일반 탭에서 무선 네트워크 프로필을 관리하려면 기존 프로필을 선택하고 편집을 클릭하거나, 추가를 클릭한 다음 애드혹 무선 네트워크나 인프라 모드 무선 네트워크 중 새 무선 프로필이 적용될 네트워크를 지정할 수 있습니다.
새 무선 프로필을 만들려면 먼저 연결 탭에서 프로필 이름을 지정하고 해당 프로필이 적용될 무선 네트워크 이름의 목록을 만듭니다(그림 4 참조). 네트워크 이름(SSID)에 이름을 입력하고 추가를 클릭하여 새 이름을 추가할 수 있습니다. 또한 프로필에 이름이 지정된 무선 네트워크가 범위 내에 있을 경우 해당 프로필을 사용하는 무선 클라이언트가 해당 네트워크로의 연결을 시도할지 여부도 지정할 수 있습니다. 이때 연결 시도는 Windows Vista 정책의 일반 탭에 있는 무선 프로필 목록의 우선 순위에 따라 이루어집니다. 그 밖에도 범위 내에 우선 순위가 더 높은 무선 네트워크가 있을 때 자동으로 해당 무선 네트워크와의 연결을 끊을 것인지 지정하고 해당 프로필의 무선 네트워크가 숨겨진 네트워크라고도 하는 non-broadcast 네트워크임을 지정할 수 있습니다.
그림 4 연결 탭
그림 4 연결 탭 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 연결 탭
그림 4 연결 탭 (더 크게 보려면 이미지를 클릭하십시오.)
그림 5에 나와 있는 보안 탭에서는 프로필의 무선 네트워크에 대한 인증 및 암호화 방법을 구성할 수 있습니다. 암호화 방법은 인증 방법에 따라 달라집니다. 그림 6에는 각 방법이 나와 있습니다.
Figure 6 보안 방법 (Close Figure 6)

인증 방법
Open(공개)
Shared(공유)
WPA(Wi-Fi Protected Access)-개인
WPA2-개인
WPA2-엔터프라이즈
암호화 방법
WEP(Wired Equivalent Privacy)
TKIP(Temporal Key Integrity Protocol)
AES(Advanced Encryption Standard)
그림 5 보안 탭
그림 5 보안 탭 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 보안 탭
그림 5 보안 탭 (더 크게 보려면 이미지를 클릭하십시오.)
WPA-엔터프라이즈, WPA2-엔터프라이즈 또는 802.1X로 열기를 인증 방법으로 선택할 경우 네트워크 인증 방법(EAP[Extensible Authentication Protocol] ), 인증 모드(사용자 재인증, 컴퓨터 인증, 사용자 인증 또는 게스트 인증), 인증이 중단되기까지 허용할 인증 시도 실패 횟수, 이후 연결을 위해 사용자 정보를 캐시할 것인지 여부도 구성할 수 있습니다. 마지막 설정은 사용자가 로그오프할 때 사용자 자격 증명 데이터를 레지스트리에서 제거할지 여부를 지정합니다. 따라서 다음에 사용자가 로그온할 때 이름과 암호와 같은 자격 증명을 묻는 메시지가 표시됩니다.
WPA-엔터프라이즈, WPA2-엔터프라이즈 또는 802.1X로 열기 인증 방법에 대한 고급 보안 설정을 구성하려면 고급을 클릭합니다. 그림 7은 기본 고급 보안 설정 대화 상자를 보여 줍니다.
그림 7 고급 보안 설정 대화 상자
그림 7 고급 보안 설정 대화 상자 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 고급 보안 설정 대화 상자
그림 7 고급 보안 설정 대화 상자 (더 크게 보려면 이미지를 클릭하십시오.)
IEEE 802.1X 섹션에서는 초기 EAPOL(EAP over LAN)-Start 메시지에 대한 응답이 수신되지 않았을 때 전송될 연속적인 EAPOL-Start 메시지의 수와, 이전에 전송된 EAPOL-Start 메시지에 대한 응답이 수신되지 않았을 때 EAPOL-Start 메시지를 재전송할 시간 간격을 지정할 수 있습니다. 또한 인증 클라이언트가 인증자로부터 인증 실패 알림을 받은 후 어떠한 802.1X 인증 활동도 수행하지 않을 기간과, 종단 간 802.1X 인증이 시작된 후 802.1X 요청을 재전송하기까지 인증 클라이언트가 기다릴 간격도 설정할 수 있습니다.
SSO(Single Sign-On)를 사용하면 802.1X 인증이 수행될 시점을 사용자 로그온 시점에 상대적으로 구성하고, 사용자 로그온과 802.1X 인증 자격 증명을 Windows 로그온 서버에 통합할 수 있습니다. SSO 섹션에는 사용자 로그온 프로세스 직전 또는 직후 무선 인증을 수행하도록 하는 설정과 프로세스가 시작되기 전에 연결이 지연되는 시간(초)을 지정하는 설정이 있습니다. 또한 인증 방법에 따라 사용자가 추가적인 자격 증명을 입력해야 하는 경우 사용자에게 추가적인 입력 필드를 표시할 것인지 여부, 해당 필드의 표시 시간, 해당 프로필의 무선 네트워크가 컴퓨터 또는 사용자 인증에 다른 가상 LAN(VLAN)을 사용할 것인지 여부도 지정할 수 있습니다.
빠른 로밍 섹션에서는 PMK(Pairwise 마스터 키) 캐싱 및 미리 인증 옵션을 구성할 수 있습니다. 빠른 로밍 섹션은 WPA2-엔터프라이즈를 인증 방법으로 선택하는 경우에만 나타납니다. PMK 캐싱을 사용하면 무선 클라이언트와 무선 AP(액세스 지점)가 802.1X 인증의 결과를 캐시합니다. 따라서 무선 클라이언트가 이미 인증한 무선 AP로 다시 로밍하는 경우 훨씬 빠르게 액세스할 수 있습니다. 항목을 PMK 캐시에 유지할 최대 시간과 최대 항목 수를 구성할 수 있습니다. 미리 인증을 사용하면 무선 클라이언트가 현재 무선 AP와 연결된 상태에서 범위 내의 다른 무선 AP와 802.1X 인증을 수행할 수 있습니다. 무선 클라이언트가 미리 인증된 무선 AP로 로밍하면 액세스 시간이 크게 단축됩니다. 무선 AP와의 미리 인증을 시도할 최대 횟수를 구성할 수 있습니다.
Windows의 무선 지원에 대한 자세한 내용은 microsoft.com/wifi를 참조하십시오. Windows 그룹 정책에 대한 자세한 내용은 microsoft.com/gp의 리소스를 참조하십시오.

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


 Windows PowerShell: 데이터 필터링 및 서식 지정
Windows PowerShell
데이터 필터링 및 서식 지정
Don Jones

Windows PowerShell이 많은 사용자 작업 없이도 대량의 유용한 정보를 반환할 수 있다는 데는 의문의 여지가 없습니다. 예를 들어 로컬 컴퓨터의 서비스 목록을 반환하는 데 사용할 수 있는 간단한 Get-WMIObject cmdlet 명령을 살펴보겠습니다. 기본 보기에는 실행 중인 서비스의 상태, 이름 및 시작 모드가 나열됩니다.
이 보기는 본질적으로 서비스 콘솔의 명령줄 보기인데, Windows PowerShell™을 사용하면 이 보기를 훨씬 쉽게 표시할 수 있습니다.
또한 서비스에 사용할 수 있는 유용한 정보를 기본 보기에서보다 더 많이 포함할 수 있습니다. 이제 이 명령을 실행해 보겠습니다.
$s = get-wmiobject win32_service
$s[0] | gm
첫 번째 명령줄은 모든 서비스의 모음, 즉 Windows® Management Instrumentation(WMI)의 Win32_Service 클래스에 대한 모든 인스턴스를 반환하고 이를 $s 변수에 저장합니다. 두 번째 줄은 해당 모음의 첫 번째 서비스(대괄호로 표시된 서수 0)를 가져와서 이를 Get-Member cmdlet(gm이라는 별칭으로 줄여 씀)에 전달합니다. 그 결과로 해당 데이터 형식에 사용할 수 있는 속성과 메서드가 모두 표시됩니다. 필자는 Windows PowerShell의 기본 제공 Get-Service cmdlet 대신 WMI의 Win32_Service 클래스를 사용하기로 했는데, WMI가 StartName 속성을 비롯하여 실제로 Microsoft® .NET ServiceController 개체보다 더 많은 정보를 보여 주기 때문입니다. 이 속성은 서비스가 실행 중인 사용자 계정의 이름을 알려 줍니다. 다음과 같이 단일 인스턴스(예: 첫 번째 인스턴스)의 이름을 확인할 수 있습니다.
PS C:\> $s[0].StartName
LocalSystem
그러나 서비스는 특정 순서로 되어 있지 않으므로 모음 내에서 서수로 서비스를 참조하는 것은 그리 유용하지 않습니다 참고로, 서비스는 거의 대부분 사전순으로 나열됩니다. 관리 관점에서 봤을 때 사용자가 가장 관심을 갖는 항목은 모든 서비스 목록 및 각 서비스가 로그인에 사용하는 계정입니다. 이러한 항목은 준수성 감사 등에 유용합니다. 따라서 잠시 WMI에서 기본적으로 제공하는 사항에 대해 알아보겠습니다. 이를 위해 Get-WMIObject의 단축 별칭인 gwmi를 사용할 것입니다(그림 1 참조).
Figure 1 gwmi 사용 (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
이것은 간단한 샘플이지만 그 결과가 관리 보고용으로 그리 만족스럽지 않다는 것을 알 수 있습니다. 필자가 원하는 것은 서비스의 이름과 서비스가 실행 중인 계정인 StartName입니다. 또한 알아 보기 힘든 목록보다는 보기 좋은 형식의 보고서를 원합니다. 따라서 여기에서 Windows PowerShell의 뛰어난 서식 및 데이터 필터링 명령인 cmdlet가 사용됩니다.

필요한 데이터 가져오기
먼저 관심 있는 속성이 표시될 수 있도록 Get-WMIObject의 데이터를 필터링해 보겠습니다. 가장 좋은 방법은 Windows PowerShell Select-Object cmdlet 또는 간단한 별칭인 select를 사용하는 것입니다. select는 Get-WMIObject에서 반환하는 모음과 같은 개체 모음을 받아들여 이러한 개체의 원하는 속성만 표시하기 위해 설계되었습니다. 다시 말해 gwmi의 출력을 select에 전달하여 원하는 두 개의 속성을 지정할 수 있습니다. 그림 2는 표로 서식이 지정된 Name 및 StartName 속성이 포함된 결과를 보여 줍니다.
그림 2 Name 및 StartName 속성을 표 형식으로 보기
그림 2 Name 및 StartName 속성을 표 형식으로 보기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Name 및 StartName 속성을 표 형식으로 보기
그림 2 Name 및 StartName 속성을 표 형식으로 보기 (더 크게 보려면 이미지를 클릭하십시오.)
그러나 준수성 감사를 위해 이러한 보고서를 생성한 경우에는 보고서에 포함된 정보가 너무 많습니다. 일부 서비스는 비활성화되어 있으므로 출력을 읽는 사용자에게 비활성화된 서비스가 이론적으로 어떤 계정을 사용하는지는 중요하지 않을 것입니다. 따라서 시작 유형, 즉 Win32_Service 클래스의 StartMode 속성이 Disabled인 모든 서비스를 필터링하여 제외하려고 합니다.
Windows PowerShell은 Where-Object cmdlet 또는 간단한 별칭인 where를 사용하여 개체 필터링을 수행합니다. where cmdlet 명령은 입력 개체 모음을 받아들인 다음 스크립트 블록에서 각각을 실행하여 정의된 일련의 조건에 따라 각 개체를 cmdlet의 출력에 표시해야 하는지 여부를 확인합니다. 조건을 충족하는 각 개체는 True 값을 생성하고 출력에 포함됩니다. False 값을 생성하는 개체는 포함되지 않습니다.
따라서 필자는 StartMode 속성이 Disabled인 개체만 출력하기로 결정했습니다. Windows PowerShell 구문에서 평가식은 다음과 같습니다.
$object.StartMode –eq “Disabled”
물론 $object는 단지 예에 불과합니다. 실제로 스크립트를 작성하고 있는 것이 아니므로 $object라는 변수는 사용하고 있지 않습니다. 그러나 where에서 사용되는 스크립트 블록 내에서는 cmdlet에 의해 현재 평가되고 있는 개체를 나타내는 $_이라는 특수 변수를 사용했습니다. 따라서 where 스크립트 블록은 다음과 같습니다.
$_.StartMode –eq “Disabled”
다음과 같이 테스트할 수 있습니다.
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
물론 이 간단한 테스트에서 출력은 기본 목록 스타일로 표시됩니다. 그리고 공간 절약을 위해 한 개의 서비스만 포함했습니다. 그런데 이 출력이 원하는 결과와 반대임을 알 수 있습니다. 여기에서는 비활성화된 서비스가 제외되지 않고 포함되어 있는데, 이는 스크립트 블록을 반대로 작성했기 때문입니다. 실제로는 다음 예제에서 수정된 것과 같이 StartMode가 Disabled가 아닌 모든 서비스를 포함해야 합니다.
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
이제 원하는 결과가 나왔습니다. 출력에 정말 필요한 서비스만 포함되어 있으므로 다시 한 번 출력을 select에 전달하여 원하는 속성만 지정할 수 있습니다.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
데이터를 한 cmdlet에서 다른 cmdlet로 전달하는 과정은 Windows PowerShell의 기능을 정말 잘 보여 줍니다. 아직 스크립트가 완성되지는 않았지만 찾고 있는 출력만 가져오도록 큰 데이터 집합을 필터링했습니다.

보기 좋은 모양
select의 출력은 여전히 일련의 개체라는 점에 주의를 기울어야 합니다. Windows PowerShell을 사용하여 보기 좋게 서식이 지정된 테이블을 가져올 경우 표시되는 개체는 PowerShell.exe를 통해 렌더링된 것입니다. 즉, Windows PowerShell은 사람의 눈에는 개체가 보이지 않다는 것을 인식하고 개체를 텍스트로 렌더링합니다. 이 경우 그림 2와 같이 개체가 각 속성에 대한 열을 포함하는 테이블로 렌더링됩니다.
이제 정보를 감사용으로 사용하기에 충분해 보입니다. 그러나 한편으로는 충분하지 않을 수도 있습니다. 모든 사람의 요구 사항은 각기 다르므로 Windows PowerShell은 사용자의 구체적인 요구 사항을 알 수는 없지만, 대신 출력 서식을 각 사용자에게 가장 적합한 방식으로 지정할 수 있는 도구를 제공합니다. 네 개의 기본 cmdlet인 Format-List, Format-Custom, Format-Table, Format-Wide는 개체 모음(예: select에 의해 반환된 모음)을 받아들인 다음 해당 개체의 서식을 다양한 방식으로 지정하기 위해 설계되었습니다. Format-Table은 Windows PowerShell에서 기본적으로 필자가 사용한 select cmdlet의 출력 서식을 지정하는 데 이미 사용되고 있는 방식입니다. 다른 모양을 원하면 Format-List를 사용해 보십시오.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
그 결과는 다음 샘플과 유사합니다.
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Format-Wide cmdlet는 기본적으로 각 개체의 첫 번째 속성을 여러 열로 된 목록으로 생성하기 위해 설계되었습니다. 다음 예를 살펴보겠습니다.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
이 예에서는 서비스 이름 목록이 생성되는데, 이것은 필자가 원하는 정보가 아닙니다. 이 출력에는 감사 보고서에 필요한 중요한 정보인 StartName(그림 3 참조)이 누락되어 있습니다.
그림 3 Format-Wide cmdlet를 사용하여 표시된 출력에 중요 정보인 StartName이 누락됨
그림 3 Format-Wide cmdlet를 사용하여 표시된 출력에 중요 정보인 StartName이 누락됨 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 Format-Wide cmdlet를 사용하여 표시된 출력에 중요 정보인 StartName이 누락됨
그림 3 Format-Wide cmdlet를 사용하여 표시된 출력에 중요 정보인 StartName이 누락됨 (더 크게 보려면 이미지를 클릭하십시오.)
필자는 두 가지 속성만 다룰 것이므로 Format-Table 또는 Format-List가 적합합니다. 그런데 감사자가 이 정보를 화면에서 보는 것을 좋아하지 않을 수 있습니다. 이 정보를 파일로 출력하기를 원할 수 있습니다.

데이터 내보내기
그렇다면 감사자는 데이터를 어떤 방식으로 보기를 원할까요? 서비스 및 로그인 이름 목록을 CSV(쉼표로 구분된 값) 파일로 출력하면 Microsoft Excel®에서 쉽게 열 수 있으므로 이 파일을 사용하는 것이 좋습니다. CSV 파일을 만들려면 출력을 Windows PowerShell Export-CSV cmdlet로 전달하기만 하면 됩니다.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
그러나 요즘에는 CSV가 다소 구식이 된 것 같습니다. 감사자는 데이터가 인트라넷 서버에서 웹 페이지로 표시되는 것을 선호할 수 있습니다. 이를 위해 먼저 다음과 같이 ConvertTo-HTML cmdlet를 사용하여 출력을 HTML로 변환하겠습니다.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
원시 HTML은 보기 힘들 수 있으므로 출력을 파일에 써야 합니다.
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
그림 4와 같이 보기 좋게 서식이 지정된 HTML 페이지가 만들어지며, 이 페이지는 추가 수정 없이도 모든 웹 서버에 게시할 수 있습니다.
그림 4 보기 좋게 서식이 지정된 HTML 페이지로 표시된 출력
그림 4 보기 좋게 서식이 지정된 HTML 페이지로 표시된 출력 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 보기 좋게 서식이 지정된 HTML 페이지로 표시된 출력
그림 4 보기 좋게 서식이 지정된 HTML 페이지로 표시된 출력 (더 크게 보려면 이미지를 클릭하십시오.)

요약
Windows PowerShell은 다양한 범위의 관리 데이터에 빠르게 액세스할 수 있도록 합니다. 그러나 원시 상태의 이 데이터가 늘 비즈니스에서 유용한 것은 아닙니다.
where를 통해 데이터를 필터링하고 select로 원하는 개체 속성을 선택한 다음 Format-Table이나 Format-List 등의 적절한 서식 지정 옵션을 적용하면 이러한 관리 데이터를 간단하고 빠르게 유용한 정보로 바꿀 수 있습니다. 그런 다음 쉽게 공유할 수 있는 파일 형식으로 데이터를 내보내면 자신의 컴퓨터에 있던 가치 있는 정보를 회사의 다른 사람들에게 전달할 수 있습니다.

Don Jones는 SAPIEN Technologies의 프로젝트 및 서비스 담당 이사이자 Windows PowerShell: TFM(SAPIEN Press)의 공동 저자입니다. 문의 사항이 있으면 www.ScriptingAnswers.com으로 연락하시면 됩니다.


 Hey, Scripting Guy!: 로컬 사용자 및 그룹에 대한 순진한 이야기
Hey, Scripting Guy!
로컬 사용자 및 그룹에 대한 순진한 이야기
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_04.exe (151KB)

파일과 폴더에 대한 보안 설명자는 어떻게 관리해야 합니까?

믿기 어렵겠지만 한때 Scripting Guy가 별로 똑똑하지 못했던 적도 있습니다. 물론, 오래전 이야기지요. 믿기 힘든 이야기죠? 아니라고요? 지금도 별로 똑똑해 보이지 않는다고요? 왜 그렇게 생각하시죠? 혹시 얼마 전에 Scripting Guy 중 한 명이 새로 산 TV를 연결하지 못해 애먹는 모습을 보셨나요?
그 Scripting Guy를 대신해 변명을 하자면 새 TV를 연결하는 것은 로켓 공학과는 다르지 않습니까? 사실 로켓 공학보다 훨씬 더 복잡하지요. TV를 연결하는 것 자체는 세 가닥의 비디오 케이블과 두 가닥의 오디오 케이블만 연결하면 되는 간단한 일이지만, 거기에 VCR, DVD 플레이어, Xbox®까지 연결하고 범용 리모컨에서 모든 장치를 인식하도록 해야 하니까요. 거기에 비하면 인공위성을 화성 궤도에 띄우는 것 정도는 식은 죽 먹기지요.
놀랍게도 그 Scripting Guy는 결국 모든 연결 작업을 완벽하게 마무리했습니다. 그러나 장치를 모두 켜도 화면이나 소리가 전혀 나오지 않았습니다. 그래서 모든 연결을 꼼꼼하게 재차 확인하고 설명서를 전부 읽고 놓친 정보가 없는지 인터넷에서 검색까지 해 보았지만 소용이 없었습니다. 그런데 전자 제품의 신에게 MP3 플레이어를 제물로 바치려던 찰나에 케이블 선을 벽면의 케이블 TV 단자에 연결하지 않았다는 사실을 알게 되었습니다.
참고: 이렇게 장치를 연결하기가 어려운 것은 분명 굉장히 많은 장치가 있기 때문일 것이다라고 생각하시겠지요? 사실 이 Scripting Guy도 같은 생각입니다. 그렇지만 이 Scripting Guy는 새로운 장치를 구입하는 데 대해 가족 투표를 할 때마다 늘 2-0으로 이기곤 합니다. 2-1이 아니라 2-0으로 말입니다. 어떻게 된 일인지 이 Scripting Guy의 아버지는 투표권이 없었던 모양입니다. 뭐, 기록이 없으니 확인할 길은 없지만요.
그렇다고 그 아버지가 방관만 하고 있었던 것은 아닙니다. 그러나 아직까지 UN은 그 집에 선거 관리 위원회를 보내지 않고 있으니 어찌할 도리가 없지요.
잘 생각해 보면 Scripting Guy들(특히 새 TV를 연결하려던 사람)은 순진할 따름이지 그렇게 바보는 아닙니다. Scripting Guy들은 Microsoft® Windows® 2000 Scripting Guide를 계획할 당시에 책의 구성에 대해 여러 전문가로부터 도움을 구해야 했습니다. 그 과정에서 삭제된 단원 중 하나가 바로 로컬 사용자 및 그룹을 관리하는 방법에 대한 단원이었습니다. 전문가는 "로컬 사용자 및 그룹 관리? 이런 내용이 왜 필요하죠?"라고 말하더군요. "대체 누가 이런 내용을 넣을 생각을 했죠? 로컬 사용자와 그룹을 관리하는 방법을 누가 알고 싶어 하겠습니까?"라고 말이죠.
그랬는데, 뒤늦게 원통하게도 우리 "전문가"들을 제외한 모두가 로컬 사용자 및 그룹에 대해 알고 싶어한다는 사실을 알게 되었습니다. 저희는 매주 사용자들로부터 컴퓨터에서 사용자를 로컬 그룹에 추가하거나 로컬 그룹에서 사용자를 제거하거나 로컬 Administrator 암호를 바꾸는 방법을 묻는 전자 메일을 엄청나게 받았습니다.
스크립트 센터 스크립트 리포지토리에 이러한 작업을 수행하는 방법을 보여 주는 몇 가지 샘플 스크립트가 있긴 하지만 대부분 한번에 한 컴퓨터에서만 사용할 수 있는 스크립트입니다. 하지만 여러 컴퓨터에서 동시에 이러한 작업을 수행하는 방법을 알고 싶어하는 독자가 많습니다. 한 대의 컴퓨터에서만 로컬 Administrator 암호를 변경한다고요? 그러한 작업은 현실적으로 전혀 도움이 되지 않습니다. 사내의 모든 컴퓨터에서 이러한 작업을 수행하거나 적어도 OU의 모든 컴퓨터 또는 모든 메일 서버에 대해 이러한 작업을 수행해야 하는 경우가 대부분입니다.
Scripting Guide가 2003에 출간되었으니, 거의 4년 동안 같은 내용의 전자 메일 메시지 공세를 받아온 셈입니다. 얼마 전에는 Scripting Guy 중 한 명이 "또 독자 중 한 명이 Excel® 스프레드시트에서 컴퓨터 이름을 읽어 각 컴퓨터에서 로컬 Administrator 암호를 바꾸는 방법에 대해 문의해 왔다"면서, "이게 가능하기는 한 겁니까?"라고 반문하더군요.
뭐, 4년이 걸리긴 했지만 결국 방법을 알아냈습니다. 그림 1에 그 방법이 나와 있습니다.
Figure 1 마침내 찾아낸 방법! (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
참고: 아시다시피 이 스크립트를 작성하기가 특히 어려워서 4년이나 걸린 것은 아니고 우리는 무슨 일을 하든 그만큼 시간이 걸립니다. Scripting Guy의 송년 파티를 한번 놓치면 또 언제 그런 기회가 올지 모르는 것과 마찬가지지요.
이 스크립트는 스프레드시트에서 컴퓨터 이름을 가져와 각 컴퓨터에서 로컬 Administrator 암호를 변경합니다. 이 작업을 수행하는 방법을 최대한 간단하게 보여 주기 위해 그림 2와 같은 매우 간단하고 짧은 스프레드시트를 사용하도록 하겠습니다. 간단한 스프레드시트가 없다면 지금 당장 새로 만드십시오.
그림 2 컴퓨터의 필수 항목 목록
그림 2 컴퓨터의 필수 항목 목록 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 컴퓨터의 필수 항목 목록
그림 2 컴퓨터의 필수 항목 목록 (더 크게 보려면 이미지를 클릭하십시오.)
그림에서 볼 수 있는 것처럼 특별한 것은 없습니다. 열 1(열 A)에는 암호를 변경해야 하는 모든 컴퓨터의 이름이 나열되어 있습니다. 열 2(열 B)에는 각 컴퓨터의 Administrator 암호를 마지막으로 변경한 날짜와 시간이 기록됩니다. 따라서 Administrator 암호가 모두 동기화된 상태로 관리되고 있는지 확인할 수 있습니다.
스크립트에 대해 설명하자면, 먼저 On Error Resume Next 문을 사용합니다. 보통 우리는 스크립트에 오류 처리 기능을 추가하지 않습니다. 오류 처리 기능이 필요 없다고 생각해서가 아니라 스크립트를 가능한 한 이해하기 쉽도록 짧고 간단하게 만들기 위해서입니다. 그러나 이 예에서는 On Error Resume Next 문이 중요한 역할을 합니다. 지금 우리가 작성하는 스크립트는 많은 수의 컴퓨터에 연결하게 되는데, 컴퓨터 중 하나가 꺼져 있다면 어떻게 될까요? 오류 처리 기능만 있다면 아무 문제가 없을 것입니다. 오류가 발생하기는 하겠지만 스크립트에서 오류를 처리하고 작업을 계속 진행할 수 있을 테니까요. 그러나 오류 처리 기능이 없다면 Scripting Guy가 TV를 처음 설치할 때 겪었던 것과 같은 문제를 겪게 될 것입니다. 스크립트를 실행해도 아무 결과도 얻지 못하게 되는 것이죠.
다음으로 아래의 코드 블록을 사용하여 Excel.Application 개체의 인스턴스를 만들고 해당 Excel 인스턴스가 화면에 표시되도록 한 다음 C:\Scripts\Test.xls 스프레드시트를 엽니다.
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
그리고 마지막으로 i라는 카운터 변수에 값 2를 할당했습니다. 이 변수는 스프레드시트에서 현재 행을 추적하는 데 사용됩니다.
참고: 그렇다면 변수 i에 2라는 값을 할당한 이유는 무엇일까요? 간단합니다. 스프레드시트를 자세히 살펴보면 행 1은 머리글 행이고 실제 데이터는 행 2부터 시작한다는 사실을 알 수 있습니다.
이제 아시겠죠? Scripting Guy가 YPbPr1 케이블을 연결하는 데에는 서툴지 모르지만 스크립팅에 대해서는 일가견이 있다는 사실을 말이죠.
뭐, 적어도 가끔은 말입니다.
이제 본 작업을 실행할 준비가 다 되었습니다. 먼저 열 1에서 빈 셀에 도달할 때까지 실행되는 Do Until 루프를 설정합니다. 따라서 어떠한 경우라도 열 1의 셀은 비워 둘 수 없습니다. 스크립트가 빈 행에 도달하면 데이터의 끝에 도달한 것으로 간주하여 루프와 스크립트가 끝나기 때문입니다. 이러한 문제를 해결하는 방법이 몇 가지 있기는 하지만 그냥 스프레드시트에 빈 행이 없도록 하는 것이 가장 간단합니다.
루프에서는 먼저 행 i, 열 1의 셀에 있는 값을 strComputer라는 변수에 할당합니다. 앞서 설명했듯이 처음 루프를 실행하면 i에 2가 할당되므로 행 2, 열 1의 셀 값을 사용하여 작업을 실행하게 됩니다. 그리고 다음 코드 줄을 사용하여 변수 strComputer로 표시되는 컴퓨터의 로컬 Administrator 계정에 대한 개체 참조(objUser)를 만듭니다.
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
이 스크립트를 실행했을 때 문제가 발생하면 여기서 중지됩니다. 네트워크 문제가 있다거나 컴퓨터의 전원이 꺼져 있다거나 Scripting Guy 중 한 명이 DVD 플레이어를 잘못 연결해서 미국 서부 지역 전체가 정전이 되었다면 말이지요. 이러한 일이 발생하면 컴퓨터에 연결할 수 없게 됩니다. 때문에 VBScript Err 개체의 값을 바로 확인해야 합니다.
If Err = 0 Then
Err 개체의 값이 0이면 아무 문제 없이 컴퓨터와 Administrator 계정에 연결할 수 있습니다. Err의 값이 0이 아니면 연결 시도가 실패합니다. 컴퓨터에 연결할 수 없다면 당연히 암호를 변경할 수도 없으므로 해당 컴퓨터에서 암호 변경을 시도할 필요조차 없습니다.
모든 작업이 순조롭게 진행되고 오류가 발생하지 않으면 다음 두 줄의 코드를 실행합니다.
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
첫 번째 줄에는 로컬 Administrator의 계정에 새 암호 egTY634!alK2를 할당하기 위해 SetPassword 메서드가 사용되었습니다. (아이의 이름을 암호로 사용하지는 않으시겠지요?) 두 번째 줄에서는 VBScript Now 함수를 사용하여 행 i, 열 2의 셀에 현재 날짜와 시간을 기록합니다. Password Changed 열은 원격 컴퓨터에 연결하여 실제로 암호를 변경할 수 있는 경우에만 업데이트됩니다. 컴퓨터에 연결할 수 없으면 해당 Password Changed 필드가 업데이트되지 않습니다. 따라서 성공적으로 실행된 작업과 실패한 작업을 구분할 수 있습니다.
이것이 의미하는 바가 무엇인지 궁금하실 것입니다. 이는 루프를 처음 실행할 때 스프레드시트가 그림 3과 같이 된다는 의미입니다.
그림 3 첫 번째 암호를 다시 설정한 후의 컴퓨터 목록
그림 3 첫 번째 암호를 다시 설정한 후의 컴퓨터 목록 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 첫 번째 암호를 다시 설정한 후의 컴퓨터 목록
그림 3 첫 번째 암호를 다시 설정한 후의 컴퓨터 목록 (더 크게 보려면 이미지를 클릭하십시오.)
자, 이제 컴퓨터 1에 대해서는 작업을 충분히 실행했으니 다음 컴퓨터로 넘어가기 전에 간단히 정리하기만 하면 됩니다.
Err.Clear
i = i + 1
이 두 줄의 코드는 간단하지만 매우 중요합니다. Scripting Guy가 작성하는 코드는 언제나 중요하지만 말입니다! 첫 번째 줄은 Err 개체를 0으로 다시 설정합니다. 오류가 발생하지 않으면 이 프로세스는 불필요합니다. Err가 이미 0으로 설정되어 있으니까요. 그러나 오류가 발생했다면 Err가 0이 아닌 다른 값으로 설정되므로 Err 개체를 수동으로 다시 설정하는 것이 필요합니다. 왜일까요? Error 개체는 오류만 추적하고 성공한 작업은 추적하지 못하기 때문입니다. 예를 들어 컴퓨터 1에서 문제가 발생하여 연결할 수 없다고 가정해 봅니다. 그리고 설명을 위해 Error 개체가 99로 설정되었다고 가정해 보겠습니다.
그리고 루프를 계속 실행하여 컴퓨터 2에 성공적으로 연결했다면 Err 값은 어떻게 설정될까요? 그렇습니다. Err 값은 여전히 99로 설정되어 있습니다. Err 개체 값은 오류가 발생할 때만 변경되므로 오류가 발생하지 않으면 계속 현재 값이 유지되기 때문입니다.
이 문제가 그렇게 중요한 것일까요? 그렇습니다. 연결이 성공하는 경우에 컴퓨터의 암호를 변경하는 것이 아니라 Err가 0인 경우에만 암호를 변경합니다. 그리고 99는 0이 아닙니다. 계산기로 확인해 보았는데, 확실히 다릅니다! 앞에서 소개한 Scripting Guy의 아버지가 가족 투표에서 행사한 99표가 결국 0이 된 경우를 제외하면 말입니다. 이 경우 컴퓨터 2에 연결하는 데 성공했다 하더라도 Err가 0이 아닌 값으로 설정되어 있고, Err 값이 0이 아니면 로컬 Administrator 암호 변경을 시도조차 하지 않기 때문에 이 문제는 중요합니다.
다시 말해, Err 값이 변경될 때마다 값을 0으로 다시 설정해야만 스크립트가 오류가 발생한 것으로 인식하는 상황을 방지할 수 있습니다. 그렇다면 Err 개체를 0으로 다시 설정하려면 어떻게 해야 할까요? 맞습니다. Err.Clear를 호출하기만 하면 됩니다.
다음으로 i의 값을 1 증가시킵니다. 왜일까요? 처음으로 루프를 실행할 때에는 행 2, 열 1의 컴퓨터에 연결해야 했으므로 변수 i의 값은 2였습니다. 두 번째로 루프를 실행할 때는 행 3, 열 1의 컴퓨터에 연결해야 하고, i는 작업을 실행할 행을 나타내는 변수이므로 i의 값을 3으로 설정해야 합니다. 그리고 다들 알다시피 2+1=3입니다. (계산기가 있어서 참 다행이죠?) 이렇게 해야만 루프를 실행하고 스프레드시트의 다음 컴퓨터에 대해 프로세스를 반복할 수 있습니다.
이만하면 우리가 더 이상 그렇게 순진하지만은 않다는 것을 보여 준 듯해서 만족스럽지만, 이 스크립트 자체로는 독자들이 전자 메일로 문의한 질문에 충분한 답이 되지 않는다는 사실은 잘 알고 있습니다. 이 기사를 읽은 독자가 "그 Excel과 관련한 기사는 도움이 많이 되었습니다만, OU의 모든 컴퓨터나 텍스트 파일에 나열된 모든 컴퓨터에서 로컬 Administrator 암호를 변경하는 작업은 어떻게 해야 합니까? 또한 컴퓨터의 팝업 목록을 표시하고 목록 상자에서 선택할 수 있도록 하고 싶습니다. 그리고 또..."라고 말할 수도 있으니까요.
결론부터 말하자면, 걱정하지 않아도 됩니다. 독자가 원한다면 Scripting Guy는 무엇이든 합니다. 4년만 기다려 주신다면 말이죠. 스크립트 센터에는 여러 컴퓨터에 대해 스크립트를 간단히 실행할 수 있도록 하는 컴퓨터 서식 파일이 여러 개 게시되어 있습니다. 예를 들어 OU의 모든 컴퓨터에서 로컬 Administrator 암호를 변경하는 작업도 아무 문제 없이 처리할 수 있습니다. 그림 4와 같이 OU의 모든 컴퓨터에 대해 스크립트를 실행하는 서식 파일을 사용하면 됩니다.
Figure 4 OU를 대상으로 스크립트 실행 (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
서식 파일에서 "Insert your code here"라고 표시된 구역이 보이십니까? 이 구역의 샘플 코드를 삭제하고 이 칼럼에서 로컬 Administrator 암호를 변경하는 코드를 복사해 넣기만 하면 됩니다. 즉, 샘플 코드를 다음 코드로 바꾸면 되는 거죠.
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
이 예에서는 로그에 결과가 기록되지 않지만 로그를 기록하는 코드도 쉽게 추가할 수 있습니다. 샘플 코드를 바꾼 후에는 연결 문자열 LDAP://OU=Finance,dc=fabrikam,dc=com을 변경하여 원하는 OU 중 하나를 가리키도록 하면 됩니다.
사실 이들 서식 파일이 게시된 지는 일 년도 더 되었습니다. 당시만 해도 우리는 스크립트 센터에서 가장 인기 있는 게시물이 될 것이라고 생각했습니다. 그러나 예상은 완전히 빗나갔습니다. 여러 컴퓨터에 대해 스크립트를 실행하는 방법을 묻는 전자 메일은 거의 매일 받았지만, 이들 서식 파일을 사용하는 독자는 거의 없었습니다. 사람들은 이러한 서식 파일이 있는지조차 몰랐던 것 같습니다. 하지만 이제 microsoft.com/technet/scriptcenter/scripts/templates에 이러한 서식 파일이 게시되어 있다는 사실을 아셨으니 많이 이용해 주시기 바랍니다. 흠, 우리 사이트를 방문하기 싫어서 사용하지 않은 것이 아니라면 말입니다.
이제 Scripting Guy가 더 이상 순진하지 않다는 사실은 증명되었는데, 그렇다면 더 이상 바보도 아닌 것일까요? 이렇게 말하고 싶군요. 얼마 전 Scripting Guy 중 한 명이 주말에 집을 수리하겠다고 한 적이 있습니다. 월요일에 출근해 보니 엄지 손가락을 크게 다쳐 피가 계속 흐르고 있었고 다리에도 상처가 있더군요.
Scripting Guy에게 이 정도는 큰일도 아니랍니다.

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


 Security Watch: 보안 구성 마법사
Security Watch
보안 구성 마법사
John Morello
이 칼럼에는 Windows Server "Longhorn"에 대한 시험판 정보가 수록되어 있으며 정보는 변경될 수 있습니다.

효율적이고 지속적인 서버 보호는 대부분의 IT 조직, 특히 많은 수의 컴퓨터가 지리적 및 조직적 경계를 넘어 분산되어 있는 조직에서 해결해야 하는 과제입니다. 숙련된 관리자에게 있어 서버 한 대의 보안을 강화하는 것은 비교적 수월한 작업일 수도 있습니다. 하지만 수백에서 수천 대에 이르는 서버의 보안을 강화하는 것은
완전히 다른 문제입니다. 오랫동안 많은 조직에서는 서버 보안을 위해 자체적인 내부 검사 목록 또는 표준을 만들거나 Microsoft, 미국 국립 표준 기술원(National Institute of Standards and Technology) 또는 여타의 외부 기관에서 제공하는 지침을 도입했습니다. 물론 이러한 문서들이 많은 도움을 줄 수는 있지만 문서만으로는 조직이 제시된 최선의 방법을 네트워크에 실현하기에는 충분하지 않습니다. 따라서 많은 조직에서는 기본 설치 설정을 그대로 유지하거나 많은 시간과 노력을 투자하여 시스템 보안 강화를 위한 고유의 스크립트나 정책을 만들었습니다.
하지만 이제는 Windows Server® 2003 서비스 팩 1(SP1)의 보안 구성 마법사(SCW) 덕분에 훨씬 간편하게 서버 역할을 기준으로 서버 보안을 강화하고 공격 노출 영역을 줄일 수 있게 되었습니다. SCW의 장점을 그룹 정책의 중앙 배포 및 관리 기능과 결합하여 SCW를 확장하면 규모가 가장 큰 IT 기업의 보안까지 SCW로 처리할 수 있습니다. 이번 달 칼럼에서는 IT 조직에서 SCW와 그룹 정책을 사용하여 보다 안전하고 일관된 방식으로 서버를 관리하는 동시에 배포 및 운영 비용을 줄이는 방법을 간단하게 살펴보겠습니다.

SCW 개요
SCW는 Windows® 구성 요소 추가/제거 제어판에서 설치할 수 있는 선택적 구성 요소로서 Windows Server 2003 R2를 비롯한 모든 Windows Server 2003 SP1 제품군에서 사용할 수 있습니다. 관리자는 먼저 대상 서버에 대해 SCW를 실행하여 서버의 역할을 식별한 다음 최소 권한 구성을 통해 컴퓨터의 보안을 강화하는 보안 정책을 만들 수 있습니다. 다시 말해 SCW를 사용하면 서버가 해당 역할을 수행하는 데 필요한 서비스, 응용 프로그램 기능 및 포트만 사용하고 해당 역할에 필요하지 않은 기능이나 서비스 등은 사용하지 않도록 설정할 수 있습니다. 이와 같은 방법을 사용하면 대상 서버의 공격 노출 영역을 줄일 수 있습니다. 서버가 수행하는 역할에 필요하지 않은 서비스를 실행하면 기능상의 이점은 없으면서 서버가 감당해야 할 총 위험만 늘어납니다. 이러한 서비스는 사용하지 않도록 설정하여 위험은 줄이고 서버 성능은 개선할 수 있습니다.
Microsoft는 Windows Server 2003에서 보안과 관련된 많은 고급 기술을 선보임으로써 이전 버전의 Windows Server에 비해 공격 노출 영역을 대폭 줄이기는 했지만 Windows Server 2003은 Windows Vista™나 차세대 Windows Server 코드명 "Longhorn"과는 달리 완전히 구성 요소화된 코어를 기반으로 만들어지지 않았습니다. 따라서 Windows Server 2003 기본 설치에서는 모든 서버 역할 구성에 필요하지 않은데 사용하도록 설정되어 실행되는 서비스가 있을 수 있습니다. 예를 들어 인쇄 스풀러 서비스는 기본적으로 사용하도록 설정되어 있지만 데이터베이스 서버 역할만 수행하는 컴퓨터에는 필요하지 않은 서비스입니다.

역할 기반 보안의 실현
지난 몇 년 동안 Microsoft는 관리자가 다양한 서버 역할에 필요한 서비스를 이해하는 데 도움이 되는 수많은 보안 관련 문서를 제공했으며 웹 서버와 같은 잘 알려진 역할에는 미리 만들어진 템플릿을 제공하고 있습니다. 하지만 Windows Server 2003 보안 가이드에 나오는 것과 같은 지침은 대규모 환경에서 구현하기에는 어려우며 특히 해당 환경에서 사용되는 응용 프로그램이 대개 기본 IIS나 SQL Server 설치보다 복잡한 경우에는 더욱 그렇습니다. 문제를 더욱 복잡하게 만드는 요소는 기업에서 사용하는 수많은 타사 응용 프로그램입니다. 이러한 응용 프로그램의 상당수는 여러 서버 역할에 종속되는데다 응용 프로그램 및 서비스 요구 사항이 제대로 정의되어 있지 않은 경우도 있기 때문입니다.
SCW는 가이드에 포함된 모든 종속성 정보와 최선의 방법을 관리자 기반 마법사에 캡슐화함으로써 이러한 문제를 해결합니다. 예를 들어 관리자가 SQL Server™와 IIS를 모두 필요로 하는 새로운 기간 업무(LOB) 응용 프로그램을 배포하는 경우 이전과 달리 많은 시간을 들여 보안 가이드를 샅샅이 뒤져 고유의 사용자 지정 종속성 목록을 만들 필요가 없습니다. 이제 서버에 응용 프로그램을 설치하고 SCW를 실행하기만 하면 됩니다. SCW는 현재 실행되고 있는 서비스를 검색하고 선택할 수 있는 서버 역할 목록을 관리자에게 제공합니다. 관리자가 선택한 역할에 따라 SCW는 해당 역할의 종속성 매트릭스에 필요하지 않은 모든 서비스는 사용하지 않도록 설정하는 정책을 생성합니다. SCW는 또한 레지스트리 보안 강화, 필요 없는 네트워크 통신 차단, 효과적인 감사 정책 적용 등을 위한 옵션도 제공합니다. SCW를 실행한 후 관리자는 SCW 정책을 XML 파일로 저장하여 동일한 LOB 응용 프로그램이 실행되는 다른 서버에 적용할 수 있습니다.
SCW를 실행하면 기존의 수동에 가깝던 Windows Server 보안 방법에 비해 세 가지 뛰어난 이점을 얻을 수 있습니다. 첫째, 주어진 작업에 필요한 서비스 및 설정을 위해 관리자가 늘 제품 설명서를 참조할 필요가 완전히 없어지지는 않더라도 크게 줄어듭니다. 이러한 정보는 SCW에 미리 제공되어 있으므로 관리자는 질문 기반 인터페이스를 통해 필요한 정보를 쉽게 제공할 수 있습니다. 둘째, SCW에는 서비스 보안 강화, 네트워크의 공격 노출 영역 줄이기, LDAP 및 SMB 서비스의 보안 강화, IIS 잠금을 비롯하여 다양한 영역에 대한 지침이 통합되어 있습니다. 이전에는 이러한 구성 작업을 수행하려면 별도의 유틸리티가 필요했으며 유틸리티마다 인터페이스와 구성 방법이 각기 달랐습니다. 셋째, SCW는 해당 설정을 XML 정책 파일로 출력하므로 "한 번만 만들어 다양한 상황에서 사용"해야 하는 시나리오에서 매우 유용합니다. 특정 LOB 응용 프로그램을 지원하기 위해 몇 대의 서버를 배포하는지에 관계없이 모든 서버에 동일한 SCW 정책을 쉽게 적용할 수 있으므로 보안 설정의 일관성이 높아지고 운영 비용이 절감됩니다. SCW 정책을 롤백하는 작업도 간편해집니다.

SCW 구성 요소
기능과 장점이 다양한데 비해 SCW는 마법사 인터페이스, 명령줄 인터페이스 및 보안 구성 데이터베이스(SCD)의 세 부분으로 이루어진 매우 단순한 도구입니다. 중소 규모 기업의 관리자에게는 마법사 인터페이스만 필요할 수도 있습니다. 이보다 크거나 복잡한 환경의 경우 관리자가 명령줄 인터페이스를 사용하여 SCW 정책을 그룹 정책 개체(GPO)로 변환하는 등의 SCW 작업을 자동화할 수 있습니다. 일반적으로 SCD를 수정하는 작업은 고유의 사용자 지정 SCW 역할을 만들고자 하는 고급 관리자만 수행합니다.
그림 1에 나오는 마법사 인터페이스를 사용하면 관리자가 대상 서버에 대한 보안 설정을 만들고 편집하고 적용하며 롤백할 수 있습니다. 마법사 인터페이스는 서비스 및 설정 검토, 네트워크 연결 검토, 보안 감사 정책 검토, IIS 설정 검토라는 일관된 워크플로를 통해 관리자에게 선택할 수 있는 항목을 제시합니다.
그림 1 SCW 인터페이스
그림 1 SCW 인터페이스 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 SCW 인터페이스
그림 1 SCW 인터페이스 (더 크게 보려면 이미지를 클릭하십시오.)
SCW 명령줄 인터페이스는 세 가지 기본 기능을 제공합니다. SCW 명령줄 인터페이스를 사용하여 관리자는 로컬 또는 원격의 다양한 서버를 분석 및 구성하고 정책을 롤백할 수 있습니다. 또한 XML 기반 SCW 정책을 그룹 정책 관리 콘솔과 같은 표준 GPO 관리 도구에서 기본적으로 사용할 수 있도록 GPO로 변환하는 작업도 자동으로 수행할 수 있습니다. 마지막으로 그림 2의 SCW 명령줄 도구를 사용하면 새 보안 구성 데이터베이스 확장을 등록할 수 있습니다.
그림 2 SCW 명령줄 도구
그림 2 SCW 명령줄 도구 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 SCW 명령줄 도구
그림 2 SCW 명령줄 도구 (더 크게 보려면 이미지를 클릭하십시오.)
SCD는 각 SCW 역할에 필요한 특정 서비스와 설정에 대해 자세히 설명된 XML 파일 모음으로서, %windir%\security\msscw\kbs에 있습니다. 기본적으로 SCW에는 BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server, Systems Management Server라는 미리 정의된 12가지 응용 프로그램 역할과 함께 다양한 핵심 Windows Server 역할이 포함되어 있으며, 역할마다 고유의 XML 파일이 있습니다(그림 3 참조). 역할 정의를 새로 만들 때마다 해당 XML 파일이 이 디렉터리에 저장됩니다. 이 파일들은 표준 XML로, 텍스트 뷰어나 XML을 지원하는 기타 응용 프로그램에서 읽을 수 있습니다(그림 4 참조).
그림 3 미리 정의된 역할
그림 3 미리 정의된 역할 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 미리 정의된 역할
그림 3 미리 정의된 역할 (더 크게 보려면 이미지를 클릭하십시오.)
그림 4 역할 구성 파일
그림 4 역할 구성 파일 (더 작게 보려면 이미지를 클릭하십시오.)
그림 4 역할 구성 파일
그림 4 역할 구성 파일 (더 크게 보려면 이미지를 클릭하십시오.)

SCW와 그룹 정책 결합
SCW 자체로도 우수한 도구지만 이를 그룹 정책과 결합해야 비로소 SCW의 진정한 가치가 드러납니다. Windows® 2000을 릴리스한 이후부터 Microsoft는 Windows 서버의 보안을 위해 그룹 정책을 통해 중앙에서 관리하는 일관되고 지속적인 방식의 정책 적용 방법을 사용하도록 권장해 왔습니다. 그룹 정책을 사용할 경우 관리자는 역할을 기준으로 서버를 조직 구성 단위(OU)로 그룹화하여 개별 컴퓨터 수준에서가 아니라 조직 전체에 걸쳐 표준화된 보안 구성을 배포할 수 있습니다. 또한 누적된 표준 그룹 정책 및 응용 프로그램 논리를 기반으로 단지 몇 개의 마스터 정책만으로도 수백 또는 수천 대의 개별 서버를 안전하게 보호할 수 있는 계층화된 서버 역할 계층을 설계할 수 있습니다. 고유의 서버 역할 요구 사항이 마스터 정책과 다를 경우에는 이 OU 계층에서 해당 서버와 좀 더 "가까운" 위치에 마스터 정책보다는 작은 역할 중심의 델타 정책을 만들 수 있습니다. 이렇게 하면 마스터 정책 전체를 복제할 필요 없이 역할에 해당하는 기능만 사용할 수 있도록 정책을 조금만 변경하면 됩니다. 대규모 조직에서는 이와 같은 방법을 통해 중앙에서 관리하는 정책의 장점과 함께 필요한 경우 특정 응용 프로그램에 맞게 정책을 수정하는 융통성을 확보할 수 있습니다.
이 방법을 사용하는 데 있어서 진정한 문제는 이를 실현하는 데 있습니다. 응용 프로그램 및 서버 역할이 매우 다양한 대규모 조직에서 올바른 정책 집합을 만드는 것은 매우 어려운 작업일 뿐만 아니라 시간도 많이 소요됩니다. 적어도 SCW가 출현하기 전까지는 그랬습니다. SCW를 사용하여 정책을 생성한 다음 이를 적절한 OU에 연결하면 기존 작업 및 차후에 추가될 작업 모두에 대해 디렉터리에 저장된 역할 기반 보안을 배포하는 데 드는 시간을 대폭 줄일 수 있습니다. 조직에서 이러한 작업을 실제로 적용하는 방법을 알아 보기 위해 대규모 조직에서 SCW와 역할 기반 GPO를 구현하는 방법을 살펴보겠습니다.

조직에서 SCW 사용
이 예제에서는 Contoso라는 가상의 네트워크를 사용하겠습니다. Contoso에는 규모가 크고 복잡하며 지리적으로 분산된 IT 조직이 있습니다. Contoso는 이 IT 조직의 운영 비용을 줄이고 서버의 보안을 증대시키기 위해 작업을 기준으로 서버를 구분하고 구성하는 역할 기반 OU 계층을 만드는 Microsoft의 지침을 따릅니다. 그런 다음 SCW를 사용하여 이 OU에 연결할 정책을 만듭니다.
SCW는 기본 설치되는 구성 요소가 아니므로 무인 설치 이미지에서 SCW 구성 요소를 사용하도록 설정해야 합니다. 이를 위해 Unattend.txt의 [Components] 섹션에 SCW=On이라는 줄을 새로 추가합니다. 이후부터는 이 이미지를 사용하여 빌드하는 모든 새 시스템의 경우 시스템이 설치되는 동안 SCW 구성 요소가 설치됩니다. SCW가 설치되도록 구성했다고 해서 컴퓨터를 빌드하는 동안 컴퓨터에 정책이 적용되는 것은 아닙니다.
설치하는 동안 기본 정책을 적용하기 위해 Contoso는 scwcmd를 호출하도록 다음 옵션을 사용하여 이미지의 cmdlines.txt 파일에 있는 [Commands] 섹션을 편집합니다.
scwcmd configure /p:ContosoBaselinePolicy.xml
텍스트 파일과 XML 파일 모두 이미지의 $OEM$ 디렉터리에 있어야 합니다. Contoso에서 디렉터리의 최상위 OU에 연결된 정책에 의존하는 대신 빌드할 때 기본 정책을 적용하는 이유가 궁금하지 않으십니까? 빌드할 때 정책을 적용하면 컴퓨터가 Active Directory®에 참가하는지 여부에 관계없이 일관된 기본 정책을 적용할 수 있기 때문입니다. 예를 들어 테스트용으로 빌드한 서버의 경우 빌드하는 동안 기본 정책을 적용하면 서버가 프로덕션 Active Directory에 디렉터리에 참가하지 않더라도 최소한 조직의 표준 보안 정책을 따르도록 할 수 있습니다. 이 서버가 나중에 Active Directory에 참가하면 그룹 정책 적용 및 우선 순위 알고리즘에 따라 로컬 설정이 도메인 또는 OU 수준 설정으로 덮어쓰입니다. 정책을 적용하는 우선 순위는 로컬, 사이트, 도메인, OU 순입니다.
SCW가 설치되고 나면 Contoso에서 기본 정책을 만드는 작업을 시작할 수 있습니다. 기본 정책은 역할 기반 보안 OU 계층의 최상위 수준에 배포되어야 하며 일반적으로 계층에서 제한이 가장 많은 정책입니다. 이는 기본 정책은 가능한 한 안전하게 만든 다음 해당 서버 역할에 필요한지 여부에 따라 개별 작업에 대해 서비스와 포트를 열기 위해서입니다. 이를 위해서는 새로 빌드한 일반 서버에 표준 Contoso 관리 도구 및 유틸리티 스택을 추가한 다음 이에 대해 SCW를 실행하여 기본 정책을 만들어야 합니다. 예를 들어 Contoso에서는 기본 Windows 설치가 완료된 후 수동으로 또는 cmdlines.txt 파일을 통해 표준 바이러스 백신, 백업, 관리 및 모니터링 도구를 서버에 설치합니다. 이러한 각각의 도구는 고유의 Windows 서비스를 만들기 때문에 기본 정책을 만들기 전에 이들을 서버로 가져오면 SCW가 서비스 잠금 단계에서 이들을 인식할 수 있습니다.
서버가 빌드되고 나면 Contoso에서 서버에 대해 SCW를 실행합니다. SCW는 컴퓨터의 로컬 관리자 그룹의 구성원이 로컬 또는 원격에서 실행할 수 있습니다. SCW를 원격에서 실행할 경우에는 원격 호스트에서 SCW를 실행하는 데 사용할 사용자 계정을 지정할 수 있는 옵션을 SCW에서 제공합니다. 로컬에서 실행할 경우에는 runas.exe를 사용하여 사용자 계정을 지정할 수 있습니다. SCW는 먼저 로컬 컴퓨터에서 실행되는 서비스를 평가한 다음 현재 설치되어 있는 역할을 표시합니다(그림 5 참조).
그림 5 서버 역할 선택 및 보기
그림 5 서버 역할 선택 및 보기 (더 작게 보려면 이미지를 클릭하십시오.)
그림 5 서버 역할 선택 및 보기
그림 5 서버 역할 선택 및 보기 (더 크게 보려면 이미지를 클릭하십시오.)
Contoso의 기준 서버는 제한이 많은 상태에서 실행되도록 설계되었으므로 이 서버에서는 어떤 역할도 선택되어 있지 않아야 합니다. 서버가 수행할 역할을 선택한 다음에는 자동 업데이트, Active Directory 또는 FTP 클라이언트 등의 기능을 수행하는 데 필요한 클라이언트 기능을 식별합니다. 대부분의 조직에서 그림 6과 같이 SCW 기본값을 사용하면 도메인 참가와 같은 중요한 기능은 제공되지만 FTP 클라이언트와 같이 덜 중요한 기능은 제한됩니다.
그림 6 설치된 기능
그림 6 설치된 기능 (더 작게 보려면 이미지를 클릭하십시오.)
그림 6 설치된 기능
그림 6 설치된 기능 (더 크게 보려면 이미지를 클릭하십시오.)
그런 다음에는 허용할 특정 관리 도구 및 기본 서비스 이외의 서비스를 선택할 수 있습니다. 표준 Contoso 서버 관리 스택을 설치한 후에 SCW를 실행해야 하는 이유는 이러한 기본 서비스 이외의 서비스 옵션 때문입니다. 바이러스 백신, 백업 및 관련 응용 프로그램이 설치되면 SCW는 이러한 서비스에 대한 정보를 확보할 수 있으므로 이를 결과 정책 설정에 포함시킬 수 있습니다.
서비스 보안 강화 단원에서 다루게 될 마지막 질문은 미지정 서비스를 어떤 방법으로 처리하는가입니다. SCW 정책이 원래 만들어진 컴퓨터에서는 실행되지 않더라도 정책이 적용된 다른 컴퓨터에서 실행되는 서비스가 있을 수 있습니다. 예를 들어 새로운 타사 응용 프로그램이 있는 새 서버에 기본 정책을 적용하면 해당 응용 프로그램에 의해 설치되는 모든 서비스는 관리자가 새 서버에서 선택한 옵션에 따라 처리됩니다. 관리자는 SCW를 사용하여 서비스 시작 모드를 변경하지 않거나 서비스를 사용하지 않도록 설정할 수 있습니다. 서비스를 사용하지 않도록 설정하는 것이 보다 안전한 옵션이기는 하지만 명시적으로 실행이 허용되지 않은 서비스는 실행되지 않으므로 이 옵션을 사용하려면 신중을 기해야 합니다. 이러한 이유로 이 옵션은 보안이 잘 되어 있는 관리되는 환경에 가장 적합합니다. 조직의 다른 곳에서는 시작 모드를 변경하지 않는 방법을 선택하는 것이 좋습니다. Contoso 예제에서는 이 옵션을 선택했습니다. SCW는 서비스 보안 강화 작업을 완료하기 전에 변경될 서비스에 관한 보고서를 관리자에게 제공합니다.
서비스 보안 강화 작업을 완료한 후에는 인바운드 네트워크 액세스를 제한하는 옵션을 제공합니다. 지정된 역할에 필요한 서비스 목록과 함께 지정된 작업에 필요한 포트 목록이 SCW의 XML 데이터베이스에 포함됩니다.
관리자는 그림 7과 같이 필요한 경우 추가 포트를 구성할 수 있으며 서비스 별로 포트 규칙을 만들 수도 있습니다. Contoso 기준 서버의 경우 원격 데스크톱과 같은 가장 기본적인 서비스만 허용되어야 합니다. 예외적인 다른 모든 서비스는 OU 계층의 하위 수준에 있는 역할 기반 정책에 구성됩니다.
그림 7 포트 보기 및 허용
그림 7 포트 보기 및 허용 (더 작게 보려면 이미지를 클릭하십시오.)
그림 7 포트 보기 및 허용
그림 7 포트 보기 및 허용 (더 크게 보려면 이미지를 클릭하십시오.)
그런 다음에는 파일 및 트래픽 출력 서명과 같은 레지스트리 옵션을 선택할 수 있습니다. 다시 말하지만 기본 구성에서는 가장 안전한 기본 설정을 선택하는 것이 가장 좋습니다.
그 다음에 선택해야 할 사항은 시스템 감사 정책입니다. 대부분의 시스템에서는 성공 작업 감사 옵션을 선택하는 것이 가장 좋습니다. 모든 작업을 감사하면 프로세서 사용량이 늘어나고 감사 로그에 많은 양의 데이터가 생성됩니다. 공격이 의심되거나 보다 자세한 분석이 필요한 경우에는 필요한 특정 컴퓨터에서 실패 감사 옵션을 사용할 수 있습니다.
마지막으로 SCW는 ISS 보안 강화를 위한 옵션을 제공합니다. 이 옵션은 IIS 잠금 도구에서 사용할 수 있는 옵션과 비슷하며 지금은 SCW 정책에 직접 통합되어 있습니다.
모든 단계가 완료되면 XML 파일을 저장할지 묻는 메시지가 표시됩니다. 파일을 저장한 후에는 그룹 정책에서 기본적으로 인식할 수 있는 형식으로 파일을 변환해야 합니다. 저장한 XML 파일은 Scwcmd.exe를 사용하여 GPO로 변환할 수 있습니다. 입력할 명령은 다음과 같습니다.
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
이 정책은 자동으로 Active Directory에 만들어지며 Contoso 역할 기반 보안 강화 OU 계층의 최상위 수준에 연결할 수 있습니다.
이 정책이 계층의 최상위 수준에 적용되고 나면 해당 OU 계층에 추가되는 모든 컴퓨터에 해당 정책 설정이 상속됩니다. W3SVC 서비스를 실행해야 하는 IIS 서버와 같이 정책 수정이 필요한 컴퓨터를 추가하는 경우에는 Contoso 관리자가 새 서버 역할에 대해 SCW를 다시 실행한 다음 새 정책이 만들어지면 이 정책을 GPO로 변환합니다. 그런 다음 이 GPO를 해당 서버가 포함된 새 하위 OU에 연결하면 됩니다. 서버와 가장 가까운 GPO가 가장 먼저 적용되므로 최종적으로는 모든 기본 설정이 적용되게 됩니다. 단, 해당 OU에 필요한 역할 기능을 사용하도록 수정이 필요한 설정은 제외되어 적용되지 않습니다(그림 8 참조).
그림 8 Contoso의 정책 적용
그림 8 Contoso의 정책 적용 (더 작게 보려면 이미지를 클릭하십시오.)
그림 8 Contoso의 정책 적용
그림 8 Contoso의 정책 적용 (더 크게 보려면 이미지를 클릭하십시오.)
이 방법은 대규모 조직에서 또는 아주 많은 서버를 배포할 때 효과를 볼 수 있습니다. 초기 SCW 정책이 만들어져 이를 OU에 연결하고 나면 이후의 서버는 해당 OU에 추가하기만 하면 됩니다. 그러면 해당 서버에 적절한 보안 정책이 자동으로 상속됩니다. 따라서 초기 정책 집합이 만들어져 이를 Active Directory에 추가하고 나면 새로운 서버를 배포하거나 기존 서버를 대체하는 작업을 빠르고 간단하게 수행할 수 있습니다.

결론
차세대 Windows Server "Longhorn"을 통해 Microsoft는 운영 체제의 거의 모든 부분을 구성 요소화함으로써 기본적으로 공격 노출 영역을 대폭 줄였습니다. 이제 관리자는 최소 기본 설치만 고집하는 대신 서버 관리자 도구를 사용하여 각 서버에 필요한 역할과 작업을 추가할 수 있게 되었습니다. 서버 관리자에는 원하는 역할 서비스를 제공하는 데 필요한 기능만 설치자가 추가할 수 있도록 허용하는 내부 종속성 데이터베이스가 있다는 점에서 SCW와 작동 방식이 상당히 비슷합니다. 더 나아가 이 문서에서 설명한 그룹 정책을 통한 중앙에서 관리하는 역할 기반 보안은 대폭 확장된 GPO 제어 기능 집합을 통해 한층 더 개선되었습니다. Windows Server "Longhorn"은 기본적으로 확대된 융통성과 더욱 강력해진 보안 설정을 통해 SCW의 개념을 한 수준 높였다고 볼 수 있습니다.
SCW 리소스
다음 웹 페이지를 참조하면 SCW를 사용하는 데 많은 도움이 됩니다.
  • 보안 구성 마법사 설명서
  • Windows Server 2003용 보안 구성 마법사
  • Windows Server "Longhorn"

John Morello는 LSU를 졸업했으며 지난 6년 동안 Microsoft에서 다양한 업무를 담당했습니다. 선임 컨설턴트로서 Fortune 100대 기업과 미국 민간 및 군사 부문 고객을 위한 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 선임 프로그램 관리자로 보안 및 원격 액세스 기술을 담당하고 있습니다.


 The Desktop Files: 64비트 아키텍처
The Desktop Files
64비트 아키텍처
Wes Miller

지난 5년 전부터 Windows XP는 기본적으로 64비트 아키텍처에 사용할 수 있었습니다. Itanium용 Windows XP는 Windows XP와 동시에 출시되었는데, Intel Itanium 프로세서를 초기에 채택한 일부 사용자를 제외하고 대부분의 사용자는 x64 시스템에 Windows XP 및 Windows Server 2003 버전을 사용할 수 있다는 소식을 최근에 와서야 접할 수 있었을 것입니다.
업계에서 x86-64라고도 하는 x64는 AMD의 AMD64 아키텍처와 Intel의 EM64T를 가리키는 일반적인 이름입니다. 또한 작년 즈음에 PC를 새로 구입했다면 대개는 PC가 현재 32비트로 실행되더라도 64비트와 호환될 가능성이 높습니다.
현재 필자는 텍사스 주 오스틴의 작은 신생 회사에서 근무하고 있습니다. Microsoft® Exchange 2007 팀과 마찬가지로 저희 회사도 제품 중 하나의 아키텍처로 인해 x64 아키텍처가 지닌 매우 고유한 몇 가지 이점을 활용하는 데 관심을 가지게 되었으며, 이에 따라 x64 아키텍처 전용 제품 개발에 착수하여 이러한 제품을 제공하기 시작했습니다. 마찬가지로 필자가 관리하는 개발 및 테스트 팀의 개발 워크스테이션, 랩톱, 서버 및 프로덕션 서버에도 x64 버전의 Windows® XP와 Windows Server® 2003만 배포했습니다. 또한 제품을 테스트 및 디버깅하기 위해 필자의 개인용 랩톱에서도 Windows XP Professional x64 Edition을 실행하고 있습니다.
필자가 64비트 Windows를, 특히 모바일 시스템에서 실행한다고 말할 때 사람들의 첫 반응은 다소 당혹스러운 표정이었습니다. 64비트 컴퓨팅에 친숙한 사람들은 64비트 시스템에 맞는 장치 드라이버를 구하기가 매우 어렵다는 선입견 때문에 믿지 못하거나 부정적인 의견과 놀라움이 뒤섞인 반응을 보였습니다. 이번 달에 제공되는 본 칼럼을 통해 필자는 x64 시스템에서 64비트 모드로 Windows XP 및 Windows Server 2003을 사용하는 방법과 그 이유에 대해 설명하고 아울러 이를 통해 얻을 수 있는 배포상의 이점과 직면할 수 있는 난관에 대해 살펴보겠습니다. 또한 Windows Vista™ x64 지원, 마이그레이션 및 배포의 몇 가지 측면에 대해서도 알아보겠습니다.

간단한 역사
앞에서 설명했듯이 Windows의 64비트 지원은 Intel Itanium 프로세서를 지원할 때부터 시작되었습니다. 그 전에도 64비트 Alpha 프로세서에서 Windows를 사용하는 것이 가능하기는 했지만 실제로 Alpha에서 Windows가 64비트로 실행된 적은 없었습니다. Windows XP와 Windows Vista에서는 Itanium이 지원되지 않으므로 현재는 x64 아키텍처가 64비트 Windows 클라이언트 컴퓨팅을 지원하는 역할을 하고 있습니다. 현재는 Itanium에 비해 더 많은 버전의 Windows Server 2003을 x64에서 사용할 수 있게 되었는데 이는 근본적으로 최고급 데이터 센터 작업에 적합하며 이와 같은 추세는 다음 버전의 Windows Server(코드명 "Longhorn")에서도 계속될 것으로 보입니다.
x64 플랫폼에서의 Windows 지원은 Windows Server 2003 SP1(서비스 팩 1)이 제공되었을 때부터 가능해졌습니다. 다소 혼란스러울 수도 있지만 이때는 x64 버전의 Windows XP를 사용할 수 있게 되었을 때이기도 합니다. 즉, Windows XP 32비트 제품과 64비트 제품이 Windows 내의 서로 다른 코드 트리에서 파생되었습니다. Windows XP 32비트 제품의 경우 현재 두 번째 서비스 팩이 제공되고 있지만 64비트 버전의 경우에는 기술적으로 서비스 팩 수준이 하나도 없습니다. 또는 Windows Server 2003 SP1이 64비트 버전에 이미 통합되어 있는 것으로 볼 수도 있습니다.
Windows XP, Windows Server 2003, Windows Vista 또는 Windows Server "Longhorn" 등의 64비트 Windows를 실행하려는 경우 요구 사항은 모두 같습니다. 먼저 64비트 호환 프로세서가 있어야 합니다. AMD 프로세서를 사용하는 경우에는 AMD64 호환성을 갖춘 단일, 이중 또는 사중 코어 시스템이 있어야 합니다. 자세한 내용은 amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html을 참조하십시오. Intel 프로세서를 사용하는 경우에는 EM64T를 지원하거나 Intel 64 아키텍처를 갖춘 단일, 이중 또는 사중 코어 시스템이 있어야 합니다. 자세한 내용은 intel.com/technology/intel64를 참조하십시오. 이제 이러한 시스템을 찾는 어려움에 대해 자세히 설명하겠습니다. 예를 들어 Intel Core Duo 시스템은 64비트와 호환되지 않지만, Intel Core 2 Duo 시스템은 64비트와 호환됩니다. 이 시스템은 제 랩톱에서처럼 단순히 Centrino Duo라고도 합니다.

x64의 세계
시스템에서 기본적으로 64비트 버전의 Windows를 지원하는지 여부를 확인하고 나면 장치 지원 문제를 처리해야 합니다. Microsoft는 적어도 2년 동안의 WinHEC 세션에서 공급업체와 OEM에 자사 장치 및 시스템에 사용할 64비트 드라이버를 만들어 인증할 것을 권장해 온 만큼 Windows x64를 사용할 때 직면하게 되는 가장 큰 과제는 하드웨어 장치 또는 소프트웨어에 적합한 드라이버를 찾는 일일 것입니다. 필자의 경험에 비추어 봤을 때, 필요한 장치 지원이 제한되어 있고 x64를 통해 얻을 수 있는 이점이 가장 분명히 나타나는 서버에서 x64를 실행할 경우에 가장 성공적입니다.
데스크톱과 모바일 시스템용 드라이버를 찾는 것이 가장 어렵습니다. 일반적으로 주요 OEM 공급업체나 엔터프라이즈급 구성 요소에서 만들어진 시스템을 사용할 경우에는 비즈니스 용도로 공급업체나 OEM에서 x64 호환 드라이버를 만들고 서명했을 가능성이 높으므로 운이 좋다고 할 수 있습니다.
Windows Vista에서는 상황이 훨씬 낫습니다. 즉, x86 아키텍처가 선호되고 x64 아키텍처는 대부분의 하드웨어에 사용할 수 있는 드라이버가 제한된다는 점으로 인해 무시되는 현실과는 정반대의 상황이 Windows Vista에서 펼쳐집니다. Windows Vista의 경우에는 장치 공급업체가 호환성 테스트를 위해 반드시 x64 드라이버를 제출해야 합니다. 사실 x86 드라이버는 포함될 필요가 없지만 포함될 가능성은 있습니다. 개념적으로 보면 이는 일부 하드웨어, 특히 새로운 Windows Vista 기능을 이용하는 장치가 실제로 x64 Windows 지원만 제공하고 x86 지원은 제공하지 않을 수도 있음을 의미합니다.
사실 기본적으로 64비트 Windows를 실행하려고 할 때는 드라이버 문제만 나타나는데, 드라이버를 찾은 후나 마이그레이션할 때에 더 큰 문제가 시작됩니다. 이에 대해서는 나중에 설명하겠습니다.

왜 64비트인가?
AMD, Intel 및 Microsoft가 64비트 아키텍처로 전환한 데에는 그만한 이유가 있습니다. 64비트로 전환하면 몇 가지 중요한 이점을 얻을 수 있습니다. 그림 1에서 볼 수 있듯이 x64 아키텍처에서 가장 탁월하게 개선된 점은 처리할 수 있는 메모리의 양이 32비트 Windows의 4GB에 비해 최대 16TB로 크게 늘어났다는 점입니다. 단, 64비트 포인터는 최대 16TB의 메모리를 처리할 수는 있지만 응용 프로그램에서는 최대 8TB 가량의 메모리만 액세스할 수 있다는 점에 유의하십시오.
Figure 1 메모리 주소 공간 제한 (Close Figure 1)

주소 공간 | 64비트 Windows | 32비트 Windows
가상 메모리 | 16TB | 4GB
페이징 파일 | 512TB | 16TB
페이징 풀 | 128GB | 470MB
비페이징 풀 | 128GB | 256MB
시스템 캐시 | 1TB | 1GB
뿐만 아니라 x64 버전 Windows에서는 하드웨어 기반 DEP(데이터 실행 방지)를 제공하는데 이 기능은 NX(No eXecute)가 지원되는 x86 시스템에서도 사용할 수 있습니다. 이는 Windows에서 버퍼 오버플로를 방지하기 위해 활용하는 하드웨어 기반 솔루션을 가능하게 해 줍니다. 하드웨어 기반 DEP는 메모리의 데이터 페이지에서 코드가 실행되는 것을 방지합니다. 이에 대한 자세한 내용은 support.microsoft.com/kb/875352를 참조하십시오.
x64 버전 Windows에서는 x86 버전 Windows와 마찬가지로 다중 프로세서 또는 다중 코어 CPU가 기본적으로 지원됩니다. 그러나 설치된 모든 Windows x64에서 단일 HAL(하드웨어 추상화 계층)을 사용할 경우 Windows XP 시스템의 이미지를 만드는 데 따르는 가장 복잡한 문제 중 하나가 없어지므로 비 ACPI 또는 단일 CPU 시스템에서 사용 중인 HAL을 식별하기 위해 더 이상 고생할 필요가 없습니다.
기본적으로 Windows x64 아키텍처에서는 크게 향상된 메모리 액세스 기능을 사용하여 64비트 소프트웨어뿐 아니라 에뮬레이션을 통해 기존의 관리 인프라 및 기존의 32비트 소프트웨어도 사용할 수 있습니다. 사실 Windows x64로 전환하는 데 따르는 단점은 16비트 설치 관리자를 사용하는 32비트 응용 프로그램을 비롯하여 16비트 응용 프로그램에 대한 지원이 전무하다는 점, 프로세스 단위로 DEP를 해제할 수도 있고 Windows 응용 프로그램 호환성 팀에서 DEP가 설정된 상태에서 올바르게 실행되지 않는 일부 응용 프로그램을 보완하고 있기도 하지만 하드웨어 DEP가 설정되어 있을 경우 응용 프로그램이 안정적으로 실행되지 않는다는 점, 마지막으로 64비트 Windows Vista에서는 모든 드라이버가 디지털 서명되어야 한다는 점뿐입니다.
마지막에 언급한 드라이버의 디지털 서명은 rootkit에서 흔히 사용하는 기술인 메모리의 Windows 커널 훼손을 방지하기 위해 추가된 것입니다. 그런데 x64는 Microsoft에서 Windows 하드웨어 품질 테스트를 통해 최적의 드라이버를 얻을 수 있도록 공급업체에 최우선으로 드라이버를 개발하도록 권장하고 있는 아키텍처이므로 이러한 요구 사항이 과거와 같이 만족하기 힘든 요구 사항은 아닙니다.
x64 시스템용 Windows를 고려할 때 유의해야 할 몇 가지 사항이 또 있습니다. x64 시스템용 Windows XP 버전에는 Windows Media® Center Edition 또는 Windows Tablet PC Edition에 포함된 기능이 포함되어 있지 않습니다. 그러나 Windows Vista에서는 이 문제가 해결되어 x64 버전과 x86 버전에서 기능이 동일합니다.

가상화
한 가지 언급하지 않은 것이 있는데 바로 가상화입니다. 여기서 말하는 가상화는 Microsoft Virtual PC나 VMWare PC 가상화 제품과 관련된 것이 아니라 32비트 실행 파일을 위한 운영 체제 가상화를 의미합니다. 32비트 버전 Windows에서는 모든 16비트 응용 프로그램이 Virtual MS-DOS® Machine인 NTVDM의 컨텍스트 내에서 실행됩니다. 앞에서도 설명했듯이 64비트 버전 Windows에서는 16비트 응용 프로그램이 전혀 지원되지 않습니다. 대신 대부분의 Windows 통합 구성 요소가 기본적으로 64비트 바이너리로 실행되고 일부 구성 요소와 대부분의 타사 프로그램은 32비트 응용 프로그램으로 실행됩니다.
64비트 Windows에서는 이러한 32비트 응용 프로그램이 운영 체제를 다르게 인식하여 사실상 32비트 버전의 Windows에서 실행되도록 하는 WOW(Windows On Windows)라는 완전히 새로운 에뮬레이션 계층을 제공합니다. WOW에서는 x86 응용 프로그램이 Program Files(X86)를 단순히 Program Files로 인식합니다. 마찬가지로 x86 응용 프로그램에서는 %WINDIR%\SysWOW64가 %WINDIR%\System32로 나타나고 레지스트리 키 HKLM\SOFTWARE\Wow6432Node는 HKLM\SOFTWARE 노드로 나타납니다.
Process Explorer 도구를 사용하면 가상화의 다른 측면을 자세히 살펴볼 수 있습니다. 대부분의 32비트 응용 프로그램은 통합 32비트 Windows 바이너리와 상호 작용할 것으로 예상되므로 이러한 바이너리의 대부분이 64비트 및 32비트 버전 모두로 제공됩니다. Process Explorer에 열을 하나 추가하면 이를 쉽게 확인할 수 있습니다. 그림 2에서는 cmd.exe의 32비트와 64비트 버전 인스턴스를 보여 줍니다. 그림에서 강조 표시된 32비트 인스턴스를 보면 프로세스에 여러 개의 wow64* DLL이 로드되었음을 알 수 있습니다. 이는 32비트 응용 프로그램이 64비트 Windows에서 작동할 수 있도록 가상화가 일어나고 있음을 보여 줍니다. cmd.exe의 64비트 및 32비트 버전에서 사용 중인 작업 디렉터리, 즉 Path(경로)도 눈 여겨 보십시오.
그림 2 Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe
그림 2 Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe
그림 2 Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe (더 크게 보려면 이미지를 클릭하십시오.)
가상화와 관련해서 주목해야 할 사항이 한 가지 더 있습니다. Windows에서는 explorer.exe가 기본 64비트 응용 프로그램으로 실행되는데 여기에는 몇 가지 장점과 단점이 있습니다. 가장 큰 단점은 Explorer 셸 확장은 제대로 작동하기 위해 x64용으로 다시 컴파일되어야 하는데 대부분은 다시 컴파일되지 않았다는 것입니다.
Internet Explorer®는 그 반대로 기본적으로 32비트 버전에서 실행되는데, 이는 현재 인터넷에서 사용되고 있는 많은 ActiveX® 컨트롤이 현재 상태 그대로 올바르게 작동하도록 하기 위한 것입니다. 그렇지 않으면 64비트 응용 프로그램에서는 처리 중 32비트 DLL이나 드라이버를 로드할 수 없으므로 현재 사용되는 ActiveX 컨트롤의 거의 대부분을 차지하는 32비트 ActiveX 컨트롤을 64비트 브라우저에서 로드할 수 없게 되며 그 결과 상당량의 인터넷 콘텐츠에 액세스할 수 없게 됩니다. 이에 대한 예를 들어 보도록 하겠습니다. 64비트 Windows 시스템에서 C:\Program Files\Internet Explorer\iexplore.exe를 로드한 다음 Windows Update를 비롯하여 ActiveX 컨트롤 콘텐츠를 로드하는 아무 사이트나 방문해 보십시오. 정도의 차이는 있지만 ActiveX 컨트롤이 제대로 실행되지 않을 것입니다. 현재는 이와 같은 상황에서 32비트 Internet Explorer 인스턴스를 열도록 Windows Update가 업데이트되었습니다(그림 3 참조). 앞으로 64비트 Internet Explorer를 사용하도록 일부 ActiveX 컨트롤 콘텐츠가 업데이트될 예정입니다. 그러나 현재 32비트 Windows만 실행하는 대부분의 Windows 시스템의 경우에는 ActiveX 컨트롤 콘텐츠의 업데이트가 크게 필요하지 않으며 이러한 추세는 당분간 계속될 것으로 예상됩니다.
그림 3 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤
그림 3 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤 (더 작게 보려면 이미지를 클릭하십시오.)
그림 3 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤
그림 3 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤 (더 크게 보려면 이미지를 클릭하십시오.)

Pluck의 x64 Windows
이 문서의 앞 부분에서 언급했듯이 Pluck에서는 x64 Windows로의 전환을 이미 시작했으며 Windows의 세 가지 버전, 즉 Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 및 Windows Vista x64를 사용했습니다.
Pluck의 경우 회사 규모가 그다지 크지 않아서 최신 제품을 개발하기 시작했을 때 x64의 장점을 활용하기 위해 x64용 Windows로의 마이그레이션을 비교적 수월하게 시작할 수 있었습니다. 마이그레이션한다는 것은 새로 주문하는 모든 하드웨어가 x64와 호환되어야 함을 의미했습니다. 사실 현재와 같은 방식으로 제품을 실행할 수 있게 해 준 것은 바로 x64의 확장된 메모리 기능과 가상화였습니다. Pluck의 모든 실제 서버는 64비트 호스트 서버에서 64비트 가상 서버로 실행됩니다. 각 호스트 서버에는 16GB의 RAM이 있으며 이 RAM은 서버에서 호스팅되는 가상 서버들 간에 고르게 나뉘어 사용됩니다. 일반적으로 준비 단계의 VM(가상 컴퓨터)에는 2GB의 RAM이, 각 프로덕션 VM에는 3GB의 RAM이 각각 할당됩니다.
계층 1 시스템과 가상화된 하드웨어를 함께 사용함으로써 장치를 거의 완벽하게 지원할 수 있게 되었습니다. 예를 들어 필자의 랩톱에는 사용 가능한 x64 드라이버가 없는 장치가 세 개 있습니다. 이들은 모두 중요하지 않은 백플레인 유형의 장치로 나타나며 없어도 시스템이 문제 없이 작동합니다. 흥미롭게도 Windows Vista RC1 x64를 설치한 결과 장치 지원이 정확히 동일했습니다. 단, 필자의 시스템에서는 Windows Vista Capable 로고가 표시되기는 했지만 현재 없는 드라이버도 조만간 공급업체로부터 제공될 것입니다.
사용하는 시스템이 주로 Microsoft Office, Visual Studio®, 그리고 개발 및 빌드 프로세스에서 사용되는 몇 가지 추가 도구로 제한되므로 마이그레이션 중 호환성 문제를 야기할 만한 레거시 응용 프로그램이 많지 않았습니다. 회사의 극히 일부에서만 32비트 버전 Windows를 사용했으므로 새로운 하드웨어를 사용하여 64비트로의 마이그레이션을 시작할 수 있었으며 작업이 비교적 수월했습니다.

x64 배포 및 마이그레이션
배포와 관련하여 몇 가지 고려해야 할 사항이 있습니다. Microsoft는 x64 아키텍처 전용의 Windows PE(Pre-installation Environment) 버전을 제공합니다. 그러나 x64 시스템에 x86 패리티가 있으므로 특히 이미징 솔루션을 사용하는 경우에는 x86 Windows PE를 사용하여 배포하기를 원할 수 있습니다. 무인 설치로 Windows XP를 배포하려는 경우에는 아키텍처별로 Windows PE를 준비해야 하는데 이는 winnt32.exe가 배포되는 것과 동일한 아키텍처에서 실행되어야 하기 때문입니다. Windows PE에는 32비트 호환성 계층이 없으며 x64에서는 winnt32.exe가 64비트 응용 프로그램이므로 32비트 Windows의 경우 32비트 Windows PE가 필요합니다. 이는 64비트 버전 Windows에도 동일하게 적용되어 64비트 버전 Windows에는 64비트 Windows PE가 필요합니다.
RIS(원격 설치 서비스)의 경우는 사정이 다르므로 이 때문에 Pluck에서는 RIS를 사용했습니다. Windows Server 2003 SP1부터는 RIS로 x64 및 x86 또는 Itanium 아키텍처에 Windows를 배포할 수 있습니다. x64 시스템이 RIS 서버에 연결되면 서버가 기본 구성일 경우 x86 및 x64 RISetup 또는 RIPrep 이미지를 제공합니다. x64 클라이언트에 x86 이미지만 또는 x64 이미지만 제공하도록 RIS를 구성할 수도 있습니다. 이 옵션은 x64 하드웨어에 최상의 경험을 제공하기 위해 기본적으로 제공됩니다.
아직 업그레이드에 대해서는 설명하지 않았는데 여기에는 나름의 이유가 있습니다. 안타깝게도 전체 OS를 x86에서 x64로 업그레이드하는 것은 어마어마한 작업입니다. 이러한 이유와 Windows XP Pro x64 Edition이라는 제한된 배포 환경으로 인해 x86 버전에서 Windows XP x64로 업그레이드할 수 없으며 x86이든 x64든 어떤 버전의 Windows XP에서도 Windows Vista x64로 업그레이드할 수 없습니다. x64 시스템의 Windows Vista는 Windows XP Pro x64 Edition과 마찬가지로 새로 설치만 가능한 제품입니다. 이러한 이유로 대부분의 조직에서는 하드웨어 교체 시기가 다가올 때에만 x64로의 마이그레이션을 고려합니다. 이는 대부분의 조직에서 일거양득의 효과를 얻기 위해 Windows Vista에서도 채택할 것으로 예상되는 전략입니다.
그러나 이것이 x86 Windows에서 x64 Windows로 전환하는 조직이나 사용자가 손쉽게 사용할 수 있는 도구가 없다는 의미는 아닙니다. 도구는 분명히 있습니다. Windows XP 및 Windows Vista용 USMT(사용자 상태 마이그레이션 도구) 버전은 모두 한 버전의 Windows에서 다른 버전으로의 마이그레이션을 지원할 수 있도록 확장되었습니다. 이때의 마이그레이션은 같은 OS 내 업그레이드와는 상반되는 개념입니다. USMT는 동일한 PC에서 Windows를 제거하고 다시 로드하든지에 관계없이 대부분의 조직에서 Windows를 배포하는 데 가장 많이 사용하는 방법이므로 동일한 메커니즘을 사용하여 완전히 새로운 아키텍처의 Windows로 전환하는 것이 이전보다 상당히 수월해졌습니다.

결론
Pluck과 같은 소규모 조직에서 x64로 점진적으로 마이그레이션하는 것은 대규모 조직의 광범위한 마이그레이션 프로세스보다 훨씬 간단해 보일 수 있습니다. 그러나 아무리 어렵다고 해도 IT 전문가라면 누구든지 결국 x64 아키텍처로 전환하는 것에 대해 고려해야 할 것입니다. 향후 10년간은 x86 아키텍처와 x86 기본 버전 Windows가 계속 사용되겠지만 그 이후에는 x64 아키텍처가 엔터프라이즈 컴퓨팅의 대세를 이룰 것입니다. Microsoft는 Exchange Server 및 이외 다른 제품을 통해 완전히 x64 기능으로 전환하고 있습니다. 이제 여러분도 x64 시스템이 사용 중인 아키텍처에 적합한지, Windows Vista 마이그레이션 계획에서 x64 시스템으로의 전환이 의미가 있는지, 그리고 현재 x64 시스템에서 기본적으로 Windows XP 또는 Windows Server 2003을 활용하고 있는지 등을 파악하기 위해 노력을 기울여야 할 것입니다.

Wes Miller는 텍사스 주 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 Winternals Software와 Microsoft에서 Windows 프로그램 관리자 겸 제품 관리자로 근무했습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시면 됩니다.


 Inside Microsoft.com: Active Directory Federation Services 사용
Inside Microsoft.com
Active Directory Federation Services 사용
Jim Guthrie

Microsoft는 중요한 내부 리소스에 액세스할 수 있도록 비즈니스 파트너에게 엑스트라넷을 제공합니다. 엑스트라넷 아키텍처를 사용하려면 조직 외부에 있는 각 참가자가 이 공간에 대한 고유한 도메인 계정을 가지고 있어야 합니다. 이 계정은 명백한 이유로 파트너가 아닌 Microsoft 직원들이 만들어 관리합니다.
±×·¯³ª 제대로 작동한다 하더라도 사용자 환경은 그리 만족스럽지 못할 수 있으며 Microsoft에서 모든 파트너 사용자를 관리하려면 리소스도 상당히 많이 필요합니다.
지금부터 엑스트라넷이 현재 어떻게 작동하는지 알아보겠습니다. 고객이나 파트너는 응용 프로그램에 로그인할 때 자격 증명을 입력해야 합니다. 같은 세션에서 다른 리소스에 액세스할 때도 자격 증명을 입력하라는 메시지가 표시됩니다. 이러한 메시지는 다른 리소스를 보려 할 때마다 계속 표시됩니다. 재무 데이터베이스와 같이 리소스를 여러 개 사용하는 단일 응용 프로그램에 로그인할 경우 각 리소스에 대해 개별적으로 인증해야 하는데, 이것은 사용자의 입장에서 번거롭고 귀찮은 일입니다.
그런데 ADFS(Active Directory® Federation Services)를 사용하면 여러 번 인증해야 하는 문제를 쉽게 해결할 수 있습니다. ADFS는 Windows Server® 2003 R2 구성 요소로서, 조직 간의 트러스트를 원활하게 하여 각 조직이 고유한 사용자를 관리하면서 동시에 여러 리소스를 공유할 수 있도록 합니다. 이 칼럼에서는 Microsoft가 ADFS를 사용하여 엑스트라넷의 리소스에 액세스할 때 여러 번 자격 증명을 입력해야 하는 문제를 해결하는 방법에 대해 살펴보겠습니다. 이 방법은 여러분이 나중에 직접 유사한 솔루션을 구현하는 데 도움이 될 것입니다. 자세한 설명에 앞서 몇 가지 기본 ADFS 용어에 익숙해질 수 있도록 그림 1을 살펴보겠습니다.
Figure 1 ADFS 용어 (Close Figure 1)

용어 | 정의
페더레이션 | Active Directory 페더레이션 트러스트를 설정한 영역 또는 도메인 쌍입니다.
FS-R(페더레이션 서비스 리소스) | 들어오는 인증 요청을 FS-A 및 원하는 리소스로 라우팅합니다.
FS-A(페더레이션 서비스 계정) | FS-R에 대해 인증할 계정 토큰을 제공합니다.
FS-P(페더레이션 서비스 프록시) | 인바운드 인터넷 트래픽과 별도의 FS 서버 계층을 제공합니다.
클래임 | 서버에서 작성하는 클라이언트에 대한 정보입니다(예: 이름, ID, 키, 그룹, 권한 또는 기능).
영역 검색 | 각 FS-A에는 자격 증명이 저장되는 도메인 또는 영역이 있습니다. 영역 검색에 따라 ADFS 세션에 사용할 FS-A가 결정됩니다.

ADFS 솔루션
사용자가 ADFS 지원 응용 프로그램에 액세스하려고 하면 영역 검색을 위해 브라우저가 FS-R(페더레이션 서비스 리소스)로 전송됩니다. 이때 사용자는 세션 동안 사용할 자격 증명을 선택하고, 클라이언트가 선택한 영역에 따라 FS-A(페더레이션 서비스 계정) 서버로 리디렉션됩니다. 이 서버에서 사용자는 Windows Live™ ID(이전의 Passport 계정), Windows 통합 인증 또는 SSL 인증의 형식으로 입력하는 자격 증명을 기준으로 쿠키로 저장되는 유효한 계정 토큰을 받게 됩니다(그림 2 참조). 이 모델에서 자체의 고유한 계정 페더레이션 서버를 유지 관리하는 것은 개별 조직의 책임입니다. 따라서 Microsoft 파트너 서버의 경우 해당 환경에 있는 모든 계정을 Microsoft.com에서 관리할 필요가 없어집니다. 물론 책임 수준을 구현하는 경우에는 페더레이션할 조직을 신중하게 선택하고 이 조직이 계정 정보를 적극적으로 관리하도록 해야 합니다.
그림 2 ADFS 흐름
그림 2 ADFS 흐름 (더 작게 보려면 이미지를 클릭하십시오.)
그림 2 ADFS 흐름
그림 2 ADFS 흐름 (더 크게 보려면 이미지를 클릭하십시오.)
다음 단계에서는 다시 FS-R 서버로 돌아가서 계정 토큰을 리소스 토큰으로 교환합니다. 해당 구성에서 이 토큰은 FS-R에서 수행된 클래임-매핑 프로세스를 통해 사용자에게 부여된 전체 권한 목록을 포함합니다. 토큰을 받은 후 사용자는 세션이 열려 있는 동안 또는 기본적으로 최대 24시간 동안 ADFS 지원 응용 프로그램에서 SSO(Single Sign-On) 기능을 사용할 수 있게 됩니다. SSO 창은 구성이 가능하므로 기본 시간을 변경할 수도 있습니다. 이제 ADFS 지원 응용 프로그램에 SSO가 설정되었으므로 보다 안전하고 효율적으로 엑스트라넷에 액세스할 수 있습니다. ADFS 인증 프로세스에 대한 자세한 내용은 2006년 7월에 발행된 Matt Steele의 TechNet Magazine 기사 "ADFS를 사용하여 Single Sign-on 단순화"를 참조하십시오.
Microsoft는 회사 리소스의 보안을 유지하기 위해 엑스트라넷의 인터넷 통로를 회사 네트워크와 분리하여 각 서버를 잠재적인 이중 홈으로 설정했으며, 회사 내부 사용자의 단방향 트러스트를 허용하고 서버를 활용하여 필요한 보호 수단을 제공했습니다. 또한 외부 사용자가 필요한 리소스에 액세스할 수 있도록 허용한 엑스트라넷 공간에 별도의 도메인을 사용했습니다.
구현할 때 가장 주의를 기울였던 두 가지 사항은 부하 분산과 ADFS 정책 파일 변경입니다. 부하 분산은 전역 수준과 로컬 수준에서 모두 수행해야 하는 작업이었습니다. 처음에는 프로덕션 환경에서 두 영역에 있는 프런트 엔드 웹 서버 클러스터에 CDN(Content Delivery Network) 파트너 Akamai 또는 Savvis의 전역 부하 분산을 사용하려 했습니다. 그러면 한 쌍의 영역 서버가 모두 오프라인이 되는 경우(그렇게 될 가능성은 낮지만)에도 최종 사용자에게는 시스템 가용성이 보장되기 때문입니다. 이것은 CDN에서 제공하는 서버 상태 확인 서비스를 이용하는 장애 조치 자동화를 통해 이루어집니다. 또한 CDN 서비스를 사용하면 나중에 더 많은 클러스터를 쉽게 추가할 수도 있습니다. 그러나 비용 절감 차원에서 프리프로덕션 배포에서는 CDN 서비스를 사용하지 않기로 결정했습니다.
영역 수준에서는 NLB(네트워크 부하 분산) 클러스터링을 통해 로컬 장애 조치용 서버를 쌍으로 구성했습니다. 특별한 부하 분산 기능을 사용하지 않으므로 하드웨어로 이 작업을 쉽게 마칠 수 있었는데, NLB를 사용한 이유도 역시 비용 절감을 위해서입니다. 이 구성에서는 지원되는 모든 환경에서 99.9% 이상의 가동 시간을 보장하는 안정성을 제공합니다.
또 다른 작업은 ADFS의 핵심인 ADFS 정책 파일이 전체 환경에 올바르게 배포되고 이 파일의 변경 사항도 복제되도록 하는 것이었습니다. 이를 위해 Windows Server 2003 R2의 또 다른 기본 제공 기능이자 새로운 상태 기반 멀티 마스터 복제 엔진인 DFS-R(분산 파일 시스템 복제)을 사용했으며, 각 백 엔드 서버에서 24시간 풀 메시 복제로 DFS-R 그룹 구성원을 설정했습니다. 이제 어디에서 정책 파일이 변경되든 변경 내용이 모든 서버에 배포됩니다. 이 파일을 변경할 수 있는 사용자를 제어하기만 하면 계속해서 안정적이고 가용성이 높은 서비스를 제공할 수 있습니다.
Microsoft는 ADFS 스냅인에서 모든 변경이 이루어지도록 노력해 왔는데, 실제 사용하면서 이 파일을 가끔 수동으로 업데이트해야 한다는 것을 알게 되었습니다. 수동으로 업데이트할 경우 ADFS가 이 파일의 버전을 추적한다는 것에 주목해야 합니다. 이것은 변경 사항이 해당 환경에 적용되도록 파일을 증분해야 함을 의미합니다.
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
또한 모든 XML과 마찬가지로 정책 XML 파일도 대소문자를 구분한다는 점도 유의해야 합니다. 정책 XML 파일에는 응용 프로그램이나 다른 ADFS 서버에 대한 참조가 많이 있으며 항상 서버 간에 그대로 복사되어야 합니다. 다음의 일반적인 예를 살펴보십시오. 여기에서 첫 번째 RevocationCheckFlags는 수동으로 입력되었으며 두 번째 RevocationCheckFlags는 UI에서 수정된 트러스트된 응용 프로그램 URL입니다.
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
보안을 한층 강화하기 위해 ADFS의 또 다른 구성 요소인 FS-P(페더레이션 서비스 프록시)를 사용하여 들어오는 인터넷 요청에서 직접 액세스할 수 없는 계층에 FS-R을 유지하도록 했습니다. 단일 프록시 집합을 사용하여 프리프로덕션 영역에서 여러 ADFS 환경을 호스트하는 독특한 방법을 통해 Microsoft.com에서 프록시를 구현했습니다. 재미있게도 초기 기술 램프 업(ramp-up) 중 레지스트리 키를 수정하기만 하면 이를 달성할 수 있음을 발견했습니다. 이 키는 HKLM\Software\Microsoft\WebSSO에 있는데 이 키에서 초기 디렉터리의 값만 변경하면 여러 환경에 프록시를 사용할 수 있습니다. 기본값은 다음과 같습니다.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
다음과 같이 키를 변경하면 환경을 전환할 수 있습니다.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
배치 파일을 만들면 이 프로세스를 간편하게 관리할 수 있습니다. 그런데 프록시와 리소스 또는 계정 서버 간에는 일대일 관계가 있으므로 현재 버전의 ADFS MMC 스냅인에서는 전환 환경을 지원하지 않습니다. 따라서 배치 파일이 프록시 서버의 사용을 최대화하는 유일한 방법입니다. 이 방법은 호스트할 환경 수에 관계없이 필요한 실제 서버의 수를 제한하기 때문에 결과적으로 상당한 비용 절감 효과를 가져다 줍니다.
아키텍처 관점에서 또 다른 비용 절감 수단인 가상 컴퓨터를 사용하여 프리프로덕션 환경을 실행하고 있는데, 이 덕분에 6개의 서버를 추가로 구매하고 보관할 필요가 없어졌으며 현재까지 성능 문제도 발생하지 않았습니다. 그러나 프로덕션 환경의 요구 사항이 상당히 늘어나 이를 충족하기 위해 고성능의 실제 컴퓨터를 사용하기로 했습니다.

Active Directory에만 적용이 국한되지 않음
Microsoft.com은 인증에 Active Directory 계정을 사용할 뿐 아니라 Windows Live ID 계정과도 성공적으로 통합되었습니다. Windows Live ID(WLID) 4.5를 사용하면 개인의 Windows Live ID 계정으로 사용자 지정 클래임 변환을 통해 Microsoft 리소스에 대한 액세스를 위임할 수 있습니다. 따라서 이제 더 이상 특정 도메인 계정이 필요하지 않으므로 SSO 인증 측면에서 큰 소득입니다.

당면 문제
앞으로 해결해야 할 가장 큰 문제는 토큰 서명 인증서 공유를 위한 ADFS 관리입니다. 현재는 대개 1년 후에 갱신하기까지 유효한 표준 인증서를 사용하고 있습니다. 그러나 갱신할 때 각 해당 서버가 적절하게 업데이트되어야 하는데, 이 작업은 FS-R에 상당한 영향을 줍니다. 페더레이션을 15개나 20개만 사용하여 겨우 관리할 수도 있겠지만 수천 개는 아니어도 최소한 수백 개의 규모를 고려해야 합니다. 이 경우 단일 환경의 SSL 인증서를 관리하기 위해 전담 직원이 필요합니다. 여러 팀에서 이 솔루션을 자동화하는 최상의 방법을 찾고 있지만 아직까지는 찾지 못했습니다.
또 다른 문제는 일부 응용 프로그램이 기본적으로 ADFS를 지원하지 않을 수도 있다는 것입니다. 사이트에서 ADFS 기능을 사용하기 위해서는 약간의 프로그래밍이 필요한데 차세대 SharePoint에서 ADFS의 구현 요구를 지원하도록 Microsoft® Office SharePoint® Services 팀과 긴밀하게 협력하고 있습니다.

결론
ADFS 모델을 사용할 것인지 결정할 때는 여러 가지 사항을 고려해야 합니다. 그 중 하나는 고객이 액세스할 리소스 수 입니다. 조직 간의 페더레이션 트러스트를 설정하는 프로세스는 단순한 작업일 수 있지만 허용 가능한 액세스 정책을 작성, 검토 및 실행하는 데는 시간과 노력이 필요합니다. 따라서 고객이 한 개의 리소스에만 액세스할 경우 수고할 가치가 있는지 결정해야 합니다. 그러나 리소스 수가 많아질수록 이점도 많아집니다.
자세한 내용은 ADFS 개요 및 Active Directory Federation Services: 페더레이션 ID 및 액세스 관리 방법을 참조하십시오.

Jim Guthrie는 Microsoft.com 운영 팀에서 ADFS를 담당하고 있으며 Enterprise Portal Platform Support 팀의 시스템 엔지니어이기도 합니다.


 Field Notes: 배움의 즐거움 그리고 고통
Field Notes
배움의 즐거움 그리고 고통
Mark D. Scott

새로운 무언가가 출시되었을 때, 다른 사람보다 먼저 그 최신 기술을 접하고, 제품을 샅샅이 조사하여 작동 방법을 익힌 후 마침내 작동하게 되었을 때의 기쁨을 기억합니다. 필자는 새로운 기술이 출시되었을 때 그 내용을 먼저 익히고 이 비밀스런 지식을 다른 사람들에게 알려 주는 초기 도입자로서의 역할을 큰 기쁨으로 여겨 왔습니다.
하지만 언제부터인가 그러한 기쁨이 퇴색되어 갔습니다. 어쩌다가 그렇게 된 것인지는 잘 모르겠습니다. 아마도 새벽 3시에 중요한 응용 프로그램을 붙들고 씨름하느라 지쳐서 그렇게 되었을 수도 있고, 회사 메일 서버에 오류가 발생했을 때 제품 설명서를 잘못 읽고 고생했던 시절 때문일 수도 있습니다. 서버 한 대로 충분했던 옛날 이야기지만요. 이제 나이가 들어 그만큼 냉소적이 되었기 때문일 수도 있습니다. 어쨌든, 이제는 십 년 전처럼 밤 늦게까지 몰두할 만큼 그렇게 열정적이지 않습니다. 하지만 그렇다고 새로운 것을 익히는 것을 중지해도 괜찮다는 뜻은 아닙니다. 이 점을 필자는 바로 얼마 전에 깨달았습니다.
필자는 최근 Microsoft® Outlook® 2007로 업그레이드했는데 매우 마음에 드는 프로그램이었지요. 필자는 또한 MSN® Premium의 구독자이기도 한데요, ISP에서 자사 서비스의 일부로 제공하고 있습니다. 이전 버전의 Outlook에서는 MSN 전자 메일 주소에 액세스할 때 커넥터라고 하는 특별한 소프트웨어가 필요했습니다. 이 소프트웨어 커넥터가 Outlook 2007에서 작동하지 않아, 필자는 MSN에 이를 문의했습니다. MSN 측에서는 ISP에게 문의하라고 하더군요. 필자는 ISP에 이를 문의했구요. 문의한 결과 Outlook 2007에서 MSN Outlook 커넥터를 지원하지 않는다고 하더군요. 전자 메일, 채팅 및 전화로 문의하고 답변을 받으며 이 정보를 얻기까지 너무나 많은 시간이 걸렸습니다.
그런데 갑자기, 어쩌면 더 이상 커넥터가 없어도 될지도 모른다는 생각이 들었습니다. 그래서 Outlook 2007을 시작하여 커넥터 소프트웨어를 사용하지 않고 MSN에 대한 연결을 구성해 보았습니다. 그러자 Outlook이 인터넷에서 아무 문제 없이 서버를 찾아 계정을 구성했습니다. 몇몇 다른 POP3 계정도 이와 같이 구성했습니다. 이렇게 해서 제 전자 메일에 액세스할 수 있게 되었으며 이 제품의 엄청난 새 기능도 알게 되었습니다.
제가 드리고 싶은 말씀은, 지원 부서의 누군가가 이 새 제품을 사용하는 데 어려움을 겪었더라면 아마도 저에게 바로 커넥터가 필요하지 않다고 말해 줄 수 있었을 것이고, 우리 모두의 시간을 크게 절약할 수 있었을 거라는 것입니다.
또한 그보다 먼저, 만일 필자가 처음에 제품을 자세히 살펴보았다면 스스로 해결책을 찾았을지도 모르지요. 하지만 그 대신 다른 사람에게서 답변을 얻으려 했습니다. 우리 모두에게 있어 중요한 무언가에 대해 시간을 들여 알아보려고 한 사람이 아무도 없었기 때문에, 결국 우리 모두 스스로 문제를 해결하려고 했을 때보다 많은 시간을 허비하게 된 것입니다. 이것이 바로 제가 하고 싶은 말입니다.
기술의 변화는 우리의 예상을 뒤엎습니다. IT 전문가로서, 우리는 스스로의 선입견으로부터 벗어나야 합니다. 우리가 힘들게 얻은 지식은 곧 새로운 기술에 대한 지식으로 대체되어야 합니다. 새롭게 대체되는 지식은 기술을 더욱 쉽게 사용할 수 있게 해 주기 때문입니다. 우리는 한번 얻은 지식을 언제까지나 우리의 경쟁력으로 활용할 수 없습니다. 진정한 경쟁력은 기술에 대한 낡은 사실들의 축적이 아닌 새로운 개념과 기술을 습득하는 능력에 있습니다. 지속적인 배움을 통해 배움을 우리 일상의 일부로 만들어야 그러한 기술을 연마할 수 있습니다. 끊임없이 출시되는 다양한 새 제품들이 있기 때문에 배움은 우리의 삶의 방식에서 반드시 존재해야 하는 것입니다.
필자에게 문의 사항이 있으면 제 Microsoft 계정이나 MSN 계정으로 전자 메일을 보내 주십시오. 어느 계정으로 보내셔도 Outlook 2007에서 확인할 수 있습니다.

Mark D. Scott은 Microsoft Consulting Services의 수석 컨설턴트입니다. 그의 업무는 고객과 긴밀하게 협력하여 대규모의 데이터 중심 응용 프로그램을 디자인하고 구축하는 것입니다. Mark에게 질문이 있으면 granddaddy2002@msn.com 또는 mascott@microsoft.com으로 문의하십시오.


 Windows Confidential: 버그의 힘
Windows Confidential
버그의 힘
Raymond Chen

Windows 95에서는 문제 해결 페이지로 이동하여 "동기화 버퍼 커밋 사용 안 함"을 선택할 수 있습니다. 그런데 이 확인란이 어떤 역할을 하는지 알고 계시나요? 또는 왜 이 확인란을 선택해야 하는지 알고 계시나요?
MS-DOS® 커밋 기능의 일반적인 동작은 특정 파일의 기록되지 않은 모든 데이터를 디스크로 플러시하고 데이터를 반환하기 전 해당 데이터가 기록된 것으로 확인될 때까지 기다리는 것입니다. 동기화 버퍼 커밋 사용 안 함 옵션을 선택하면 데이터가 기록되는 것을 기다리지 않고 해당 호출이 즉각적으로 반환됩니다. 물론 이는 데이터가 기록되기 전까지 호출을 반환할 수 없는 기능 사양을 위반하는 것입니다. 이러한 동작은 플러시를 요청한 프로그램에서 실제로는 그렇지 않음에도 불구하고 해당 데이터가 안전하게 디스크에 있는 것으로 인식하도록 하기 때문에 기술 자료 문서 139669에서 말하는 "파일 무결성 문제"의 위험을 증대시킵니다.
데이터베이스 프로그램은 커밋 기능을 사용하여 프로그램이 예상하는 디스크 상태와 디스크의 파일 상태가 일치하는 지점에 포인트를 설정합니다. 업데이트 도중 컴퓨터의 전원이 꺼지는 경우 데이터베이스 프로그램은 최종 커밋 포인트에 기록된 정보를 사용하여 데이터베이스 무결성을 재구축합니다. 커밋이 완료되기 전에 즉시 반환되면 이러한 무결성 검사점이 손실되므로 데이터베이스가 손상되는 결과를 가져옵니다.
이렇듯 바람직하지 않은 결과를 가져오는 데도 이 옵션이 제공되는 이유는 무엇일까요? 원인은 Windows® 3.11의 버그에 있습니다.
그림 1 Windows Server 2003에서 버그가 있는 동작 활성화
그림 1 Windows Server 2003에서 버그가 있는 동작 활성화 (더 작게 보려면 이미지를 클릭하십시오.)
그림 1 Windows Server 2003에서 버그가 있는 동작 활성화
그림 1 Windows Server 2003에서 버그가 있는 동작 활성화 (더 크게 보려면 이미지를 클릭하십시오.)
Windows 3.11에서는 하위 수준 파일 I/O 인터페이스의 32비트 구현인 "32비트 파일 액세스" 기능을 도입했습니다. 그러나 여기에 구현된 커밋 기능에는 파일 버퍼 플러시 요청을 무시하는 버그가 포함되어 있었습니다. Windows 3.11에서 파일 버퍼를 플러시하는 프로그램을 실행할 경우 플러시 호출은 아무런 결과를 반환하지 않았습니다. 결과적으로, 적절하지 않은 시기에 전원 공급이 중단되는 경우 데이터베이스가 손상될 수 있습니다.
Windows 95 파일 시스템 개발 팀은 이 버그를 수정했지만 곧 새로운 버그 보고서가 나오기 시작했습니다. 일부 회계 프로그램의 실행 속도가 매우 느려진 것입니다. 이후 다른 데이터베이스 프로그램에서도 같은 문제가 나타났습니다. 무슨 일이 일어났던 것일까요?
문제를 일으킨 프로그램은 끊임없이 플러시를 호출하는 것으로 밝혀졌습니다. 프로그래머들은 Windows 3.11에서 플러시 호출이 매우 빠른 것을 알고 이를 프로그램 곳곳에 넘치도록 사용했습니다. 바이트를 쓰고 플러시를 호출하고, 문자열을 쓰고 또 플러시를 호출했습니다. 플러시가 매우 빨랐으므로 응용 프로그램에서는 눈에 띄는 성능 저하 없이 모든 작업 후 디스크로 데이터를 커밋할 수 있었습니다. 하지만 Windows 95에서 이 버그가 수정되어 커밋 호출이 실제 작업을 수행하게 되면서 이러한 프로그램의 실행 속도가 매우 느려지게 된 것입니다.
이때 파일 시스템 팀에서 아무런 조치도 취하지 않았다면 이 프로그램은 계속해서 느리게 실행되었을 것이고 사람들은 이를 Windows 95의 문제로 결론지었을 것입니다. 그리고 다른 사람들에게 "Windows 95는 너무 느려요."라고 말했겠지요. 그런 반면, 파일 시스템이 이전 Windows 3.11 동작으로 돌아갔다면 성가신 "파일 무결성 문제"를 야기하는 버그로 어려움을 겪었을 것입니다.
결국 파일 시스템 팀은 버그를 수정하되, 버그 수정으로 인해 문제가 발생한 프로그램을 사용하는 경우에는 Windows 3.11 동작으로 돌아갈 수 있도록 문제 해결 페이지에 확인란을 추가하는 방법을 해결책으로 결정했습니다.
역사는 계속 반복됩니다. Windows Server® 2003에서는 FUA(Forced Unit Access)로 태그가 지정된 요청이 FUA 태그 손실로 인해 일반적인 I/O로 수행되는 버그가 발견되었습니다. 이것은 플러시 요청을 무시하는 버그의 새로운 형태입니다. I/O 팀에서는 이 버그를 수정했으나 이전의 버그가 있는 동작으로 돌아가는 옵션을 남겨 두었습니다. Windows Server 2003 버전의 이 확인란은 "고급 성능 사용"이라 합니다. 하지만 여러분은 이제 이 이름이 실제로 뜻하는 것이 "이전의 버그가 있는 동작 복구"라는 것을 아실 것입니다.

Raymond Chen은 그의 웹 사이트 The Old New Thing과 같은 제목의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 그는 자신의 베개에 붙은 태그를 떼지 않습니다.