 TechNet Magazine September 2007

TechNet Magazine September 2007

Windows Vista: BDD 2007을 사용한 Windows Vista 배포

Windows 2000이나 Windows XP에서 Windows Vista로의 마이그레이션 프로젝트를 계획하고 있는 조직에서는 방법을 걱정할 필요가 없습니다. 이 문서에서는 Business Desktop Deployment 2007 Solution Accelerator를 사용하여 Windows Vista를 간편하게 배포하는 방법을 단계별로 자세히 설명합니다.

Michael Niehaus Windows Vista: Windows Vista 백업 기술

대부분의 사람들은 이미 늦은 뒤에야 백업의 중요성을 깨닫곤 합니다. 하지만 이제 백업을 해두지 않은 데 대한 핑계를 대기 어려워졌습니다. Windows Vista 백업 및 복원 센터에서 수많은 형태의 데이터 손실로부터 데이터를 쉽게 보호할 수 있는 다양한 기능을 제공하기 때문입니다. 이 문서를 통해 Windows Vista의 기능을 사용하여 완벽한 복구 전략을 수립하는 방법을 알아보십시오.

Christine Fok Windows Server: Active Directory 관리를 위한 11가지 필수 도구

대규모 조직의 경우에는 개체 추가나 수정과 같은 매우 일반적인 Active Directory 작업도 번거롭고 시간이 많이 걸리는 일일 수 있습니다. 이 기사에서 설명하는 11가지 도구를 활용하면 Active Directory를 훨씬 쉽게 관리할 수 있습니다.

Laura E. Hunter Windows Server: Active Directory 삭제 표시 개체 다시 애니메이션

모든 Active Directory 재난 복구 계획에 반드시 채택해야 하는 몇 가지 필수 기법과 도구가 있습니다. 삭제 표시 다시 애니메이션은 이러한 기법 중 하나로, 도메인 컨트롤러를 오프라인으로 전환하지 않고도 삭제된 개체를 복구할 수 있는 유일한 방법을 제공합니다. 여기서는 Active Directory에서 삭제 표시를 찾고 복구하는 방법을 소개합니다.

Gil Kirkpatrick Communications: 사용자와 Office Communications Server 2007 연결

통합 통신 방법을 소개합니다. Microsoft Office Communications Server 2007을 살펴보고 통합 메시징, 음성, 비디오 및 회의 기능을 통해 조직에서 생산성을 높이고 장거리 공동 작업을 향상시키는 방법을 알아봅니다.

Alan Maddison From The Editor: 배움의 길

Joshua Trupin Letters: 질문에 대한 답변

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

Greg Steen SQL Q&A: CPU 병목 현상, 데이터베이스 복원과 이동 및 추가 정보

Edited by Nancy Michell Utility Spotlight: PageDefrag

일반적인 Windows defrag 도구를 사용하면 하드 드라이브에 있는 대부분의 파일을 최적화할 수 있습니다. 하지만 Windows 페이지 파일 및 레지스트리 하이브와 같은 특정 항목은 일반적인 조각 모음 도구로는 처리할 수 없습니다. Sysinternals의 Mark Russinovich가 만든 이 유틸리티를 사용하면 다른 도구가 처리하지 못하는 파일에 대해 조각 모음을 수행할 수 있습니다.

Lance Whitney The Cable Guy: 강력한 호스트 모델 및 취약한 호스트 모델

멀티홈 호스트는 여러 네트워크에 동시에 연결함으로써 연결 성능을 개선합니다. 하지만 멀티홈 호스트에서 실행되는 서비스의 경우 공격에 취약한 영역이 늘어나는 문제가 발생합니다. 이 문서에서는 이러한 공격을 방지하기 위해 마련된 다양한 멀티홈 호스트 모델 및 Windows에서 이러한 모델을 지원하는 방법에 대해 설명합니다.

Joseph Davies Windows PowerShell: 셸 보안

Windows PowerShell을 설계할 때 Microsoft는 보안을 최우선으로 고려했습니다. Windows PowerShell이 VBScript와 같은 문제에 빠지지 않도록 해주는 자격 증명 처리 및 실행 정책 등의 주요 보안 기능과 설정 몇 가지를 살펴봅니다.

Don Jones Hey, Scripting Guy!: 이 관계를 저장할 수 있을까요?

관계형 데이터베이스는 일대다 관계를 처리하도록 설계되었습니다. 이로 인해 이러한 데이터베이스를 쿼리하는 스크립트를 작성하는 것이 다소 까다롭습니다. 하지만 걱정할 필요는 없습니다. Scripting Guys가 있으니까요.

The Microsoft Scripting Guys Exchange Q&A: 설치, 메시지 저널링, 저장소 옵션 및 기타 정보

메시지 저널링을 사용하여 회사에서 전자 메일을 모니터링하는 방법을 알아보고, Office 2003 사용자가 통합 메시징을 사용할 수 있는지 확인하고, Exchange 2007 구현 시에 사용 가능한 저장소 옵션을 살펴보고, 이전 버전의 Outlook을 사용하여 Exchange 2007에 연결하는 것과 관련한 문제의 해답을 알아봅니다.

KC Lemson and Nino Billic Security Watch: 사용자 계정 컨트롤의 장기적 영향

사용자 계정 컨트롤의 경우 그 범위가 워낙 넓기 때문에 이에 대한 의문점과 잘못된 생각이 많이 있습니다. 이 기사에서는 UAC란 과연 무엇인지, 이에 대한 잘못된 생각으로는 어떤 것이 있는지, 그리고 UAC가 시스템 관리 방식에 어떠한 영향을 미치는지에 대해 솔직 담백하게 설명합니다.

Jesper M. Johansson The Desktop Files: Windows PE를 사용한 PC 복구

Windows Vista에는 간편하게 시스템 복구를 수행하는 데 유용한 몇 가지 훌륭한 도구가 포함되어 있습니다. 하지만 다양한 부문으로 구성된 대규모 조직의 경우 솔루션을 처음 제공된 상태 그대로 사용할 수 없는 경우가 많습니다. 사용자 지정 자동 복구 솔루션을 구축해야 하는 대규모 조직의 경우에는 Windows PE를 통해 자체 복구 솔루션을 구축하는 방법에 대해 알아보시기 바랍니다.

Wes Miller Field Notes: 공짜 음식과 교육 팁

문제를 최소화하기 위해서는 효과적인 사용자 교육이 필요합니다. 때문에 쉽게 참여할 수 있는 교육 세션을 제공하고 질문이 있지만 직접 질문하기 꺼려하는 사용자가 있는지 사무실을 둘러보는 것이 중요합니다.

Michael Dragone Windows Confidential: 알려진 DLL 균형 조정 작업

알려진 DLL 기능은 성능 향상을 위한 한 가지 방법으로 Windows에 포함되었습니다. 이 기능의 작동 방식을 알아보고 시간에 따라 어떻게 변화했는지 살펴보겠습니다.

Raymond Chen


 Windows Vista: BDD 2007을 사용한 Windows Vista 배포
Windows Vista Michael Niehaus

BDD 2007을 사용한 Windows Vista 배포
한 눈에 보기:
  • BDD 2007 Solution Accelerator
  • 이미지 준비
  • 드라이버 및 응용 프로그램 패키지

지금까지는 이 마이그레이션 작업을 미루었지만 이제 작업에 착수할 때가 되었습니다. Windows 2000이나 Windows XP에서 Windows Vista로 마이그레이션해야 할 수백, 수천 대의 컴퓨터가 있는 조직의 경우를 생각해 보겠습니다.
시작
지난 수년간 Windows® 운영 체제를 설치해 본 경험이 있다면 Windows NT® 3.5부터 Windows XP에 이르기까지는 그다지 큰 변화가 없었다는 사실을 이미 알고 있을 것입니다. 설치 및 구성 프로세스가 거의 변하지 않았고 도구도 동일합니다. 즉, 전반적인 프로세스가 변경되지 않았습니다. 하지만 Windows Vista®에서는 전반적인 프로세스가 완전히 새롭게 디자인되었으며 새로운 도구도 많이 있습니다. Windows Vista에서 변경된 사항 및 이러한 변경이 가져오는 영향을 대략적으로 살펴보려면 2006년 11월호 TechNet Magazine의 "Windows Vista 배포에 대해 알아야 할 10가지 사항"을 참조하십시오. 이 문서는 technetmagazine.com/issues/2006/11/Deployment에서 온라인으로 볼 수도 있습니다.

새 프로세스 및 도구 확인
두 가지 방법이 있습니다.
  1. 첫째는 각각의 새 도구에 대해 살펴보는 것입니다. 사용할 수 있는 모든 설명서를 참조하고, 기존 프로세스에 이러한 각 도구를 적용하는 방법을 확인합니다. 그런 다음 필요에 맞게 조정하고 결과가 적절한지 평가합니다.
  2. 둘째는 모든 것을 자동으로 수행하는 도구를 사용하는 것입니다.
물론, 첫 번째 방법을 선택할 수도 있지만 그러려면 책 한 권 분량에 이르는 방대한 설명서를 읽어야 할 것입니다. 필자는 두 번째 방법, 즉, 자동으로 모든 것을 수행하는 도구인 Business Desktop Deployment(BDD) 2007 Solution Accelerator를 활용하는 방법을 권장합니다. 이 도구는 Microsoft® Desktop Deployment Center(microsoft.com/desktopdeployment)에서 다운로드할 수 있습니다.
BDD 2007 Solution Accelerator는 Windows Vista에 새롭게 도입된 모든 배포 프로세스와 도구를 통합하여 Windows 운영 체제의 배포 프로세스를 간소화하는 도구, 지침 및 단계별 절차의 모음입니다.
BDD 2007을 시작하려면 BDD 2007을 설치할 Windows XP 또는 Windows Server® 2003 컴퓨터를 확인합니다. 먼저 Microsoft .NET Framework 2.0과 Microsoft Management Console(MMC) 3.0을 설치해야 BDD 2007을 설치할 수 있습니다. 설치가 끝나면 시작 메뉴의 BDD 2007 폴더에 있는 Release Notes(릴리스 정보) 문서를 읽어 보십시오. 그런 다음 Deployment Workbench(배포 워크벤치) 바로 가기를 사용하여 MMC 스냅인을 실행합니다(그림 1 참조).
그림 1 BDD 2007 Deployment Workbench(배포 워크벤치) 시작
그림 1 BDD 2007 Deployment Workbench(배포 워크벤치) 시작
이때 Information Center(정보 센터)에 있는 정보, 특히 Getting Started(시작) 검사 목록과 Documentation(설명서)을 검토하는 것이 좋습니다. Components(구성 요소) 노드를 마우스 오른쪽 단추로 클릭하고 Check for updates(업데이트 확인)를 선택하여 최신 뉴스와 구성 요소 목록을 다운로드합니다.
필수 구성 요소가 한 가지 더 있는데 바로 Windows AIK(자동 설치 키트)입니다. Windows AIK에 포함된 도구는 다양한 기능을 수행하므로 BDD 2007을 실행하려면 이러한 도구가 필요합니다. Windows AIK는 Microsoft 다운로드 센터(go.microsoft.com/fwlink/?LinkId=85377)에서 다운로드하거나 Deployment Workbench(배포 워크벤치)의 "Components"(구성 요소) 노드를 통해 자동으로 다운로드할 수 있습니다. 어떤 방법을 사용하든 파일의 크기가 매우 크므로 시간이 걸릴 것을 예상하고 있어야 합니다.
Windows AIK를 설치한 후에는 Windows Vista 배포를 수행하는 데 필요한 모든 파일을 수집하는 작업을 시작할 수 있습니다.

필요한 파일
이 단계에서는 Windows Vista 설치 파일, 설치할 응용 프로그램, 하드웨어에 필요한 드라이버, 사용할 Windows Vista 업데이트 또는 언어 팩을 수집해야 합니다. 수집한 모든 파일은 BDD 2007 설치 시 만들어진 배포 공유 디렉터리 구조에 복사됩니다.
사용자 지정 이미지 만들기
이 문서에서는 Microsoft 제품 DVD에서 직접 표준 Windows Vista 이미지를 배포하는 방법에 대해 단계별로 설명합니다. 하지만 2007 Microsoft Office system과 같이 모든 컴퓨터에 필요한 추가 응용 프로그램이 포함된 사용자 지정 이미지를 배포해야 할 수도 있습니다. 최소한의 구성 요소만 포함된 "작은" 이미지를 만든 다음 나머지는 배포 시 설치하는 방법과 모든 구성 요소가 미리 설치된 "큰" 이미지를 만드는 두 가지 방법이 있지만, 대부분의 경우 배포에 투입할 시간, 이미지를 만들고 유지 관리하는 데 투입할 관리 인력, 네트워크 성능 등의 여러 요인을 고려하여 적절한 방법을 선택하는 것이 좋습니다. 일반적으로 이미지가 작을수록 좋지만 어떤 방법을 선택하느냐는 여러분의 몫입니다.
이미지에 포함할 구성 요소가 무엇이든지 사용자 지정 이미지를 만드는 프로세스는 완전히 자동화되어야 합니다. 프로세스가 자동화된 경우 프로세스에 다른 단계를 추가하고 전체 프로세스를 다시 실행하여 맨 마지막에 새 이미지를 캡처하기만 하면 간편하게 이미지를 업데이트할 수 있습니다.
그러면 BDD 2007을 사용하여 프로세스를 자동화하려면 어떻게 해야 할까요? 정말로 간단합니다.
  1. 사용자 지정 이미지를 생성할 빌드를 만듭니다.
  2. 사용자 지정 단계가 모두 포함되도록 이 빌드의 작업 순서를 수정합니다.
  3. 테스트 배포 지점(Windows PE ISO에서 부팅)에서 이 빌드를 선택하여 BMD(Bare Metal Deployment)를 수행합니다.
  4. 작업 그룹에 참가하도록 지정합니다.
이러한 단계를 수행할 때는 배포 마법사가 또 다른 창을 제공합니다.
BDD 2007은 참조 컴퓨터의 이미지를 캡처하도록 선택함으로써 자동으로 Sysprep을 실행하여 캡처할 운영 체제를 준비한 다음, Windows PE로 다시 부팅하여 ImageX.exe를 실행하고 새 WIM 이미지를 캡처합니다. 그러면 이 이미지를 Deployment Workbench(배포 워크벤치)로 가져와서 다음 배포에 사용할 수 있게 됩니다.
BDD 2007을 사용하여 참조 이미지 캡처
BDD 2007을 사용하여 참조 이미지 캡처

먼저 OS 설치 파일을 복사합니다. Windows Vista DVD를 삽입한 다음 Deployment Workbench(배포 워크벤치)에서 Operating Systems(운영 체제) 노드를 마우스 오른쪽 단추로 클릭하고 New(새로 만들기) 명령을 선택하여 New OS Wizard(새 OS 마법사)를 시작합니다. 설치할 때마다 별도의 제품 키를 입력할 필요가 없는 볼륨 라이선스 미디어를 사용하는 것이 더 좋습니다. Full Set of Source Files(전체 원본 파일 집합)를 선택하고 DVD 드라이브 경로를 지정하거나 설치 파일을 다른 위치에 복사해 둔 경우 해당 경로를 지정합니다. 나머지 단계에서는 기본값을 그대로 사용하여 마법사를 완료합니다. 이제 Operating Systems(운영 체제) 노드를 클릭하면 나타나는 목록에 하나 이상의 OS 이미지(사용한 미디어에 따라 다름)가 표시됩니다.
다음으로 응용 프로그램을 추가할 차례입니다. 이 단계에서 응용 프로그램을 반드시 추가할 필요는 없지만, 추가하는 경우 Windows Vista를 배포할 때 목록에서 응용 프로그램을 선택할 수 있습니다. 명령줄에서 사용자의 작업 없이 응용 프로그램을 설치하도록 지정하면 사용자가 응용 프로그램 설치가 시작되기를 기다릴 필요가 없으므로 이 방법을 사용하는 것이 가장 좋습니다. Deployment Workbench(배포 워크벤치)의 Applications(응용 프로그램) 노드에서 New(새로 만들기) 명령을 선택한 다음 New Application Wizard(새 응용 프로그램 마법사)를 완료하여 응용 프로그램 하나를 추가해 보십시오. 그러면 이 작업이 어떻게 수행되는지 볼 수 있습니다(그림 2 참조).
그림 2 워크벤치에 응용 프로그램 추가
그림 2 워크벤치에 응용 프로그램 추가
이제 OS 패키지를 포함해야 합니다. 일반적으로 포함하는 패키지로는 언어 팩, 보안 업데이트 및 Windows Vista 구성 요소가 있습니다.
언어 팩은 다양한 언어로 Windows Vista를 실행하는 데 필요합니다. 지원되는 언어에 대한 자세한 내용은 microsoft.com/globaldev/vista/Vista_Language_Support.mspx를 참조하십시오. Software Assurance 고객의 경우 licensing.microsoft.com에서 CAB 파일로 패키지된 언어 팩을 다운로드할 수 있으며 Windows Vista Ultimate를 실행하는 경우 Windows Update에서도 언어 팩을 다운로드할 수 있습니다. Windows Vista Enterprise 및 Windows Vista Ultimate를 실행하는 경우에만 컴퓨터 한 대에 여러 개의 언어 팩을 설치할 수 있습니다.
Windows Vista 보안 업데이트는 보통 매달 릴리스되며 microsoft.com/technet/security/bulletinsandadvisories에서 개별 MSU 파일로 다운로드할 수 있습니다.
Windows PowerShell™과 같은 새 Windows Vista 구성 요소를 포함할 수도 있습니다. 이러한 구성 요소는 Microsoft 다운로드 센터(microsoft.com/downloads)에서 다운로드할 수 있으며 MSU 파일로도 패키지되어 있습니다.
이러한 모든 파일은 실제로는 구성 요소이지만 패키지라고도 하므로 OS Packages(OS 패키지) 노드에 포함됩니다. 이러한 구성 요소는 온라인(OS가 실행 중인 경우) 또는 오프라인(OS가 실행 중이지 않은 경우) 상태에서 Windows Vista에 포함할 수 있습니다. BDD 2007을 사용하는 경우에는 이러한 구성 요소를 항상 Windows Vista 이미지를 확장하여 디스크에 배치한 후에, 그리고 이미지를 처음으로 부팅하기 전에 오프라인으로 포함하십시오.
이때 한 가지 추가적인 문제가 발생합니다. MSU 파일은 Windows Vista가 실행되는 동안 WUSA.EXE 업데이트 설치 관리자를 사용하여 온라인으로 설치하도록 디자인되었습니다. 하지만 이 예제에서는 이러한 업데이트를 오프라인으로 설치합니다. 이를 위해서는 실제 구성 요소가 포함된 CAB 파일이 있어야 합니다. 실제로는 MSU 파일 자체가 실제 구성 요소 CAB 파일이 포함된 CAB 파일입니다. 아래와 같은 명령을 사용하여 직접 MSU 파일에서 CAB 파일의 압축을 풀 수 있습니다.
EXTRACT.EXE file.msu -F:*.CAB C:\
이렇게 하면 가져와야 할 CAB 파일이 추출됩니다. Microsoft에서는 이러한 압축 풀기 작업을 자동으로 수행하는 BDD 2007용 패치를 릴리스했습니다. 따라서 설치한 후에는 이러한 수작업이 필요하지 않습니다. 즉, 해당 MSU 파일을 가리키도록 BDD 2007을 설정하기만 하면 나머지 작업은 자동으로 수행됩니다. 이 패치에 대한 자세한 내용은 support.microsoft.com/kb/937191을 참조하십시오.
이러한 구성 요소를 Deployment Workbench(배포 워크벤치)에 추가하려면 OS Packages(OS 패키지) 노드를 마우스 오른쪽 단추로 클릭하고 New(새로 만들기)를 선택하여 New Package Wizard(새 패키지 마법사)를 시작합니다. 그런 다음 추가할 패키지가 들어 있는 폴더의 경로를 지정합니다.
마지막으로, Windows Vista를 실행할 컴퓨터 하드웨어용 드라이버가 필요할 수도 있습니다. 공급업체 웹 사이트나 Microsoft Update에서 필요한 드라이버를 찾아서 다운로드한 다음 압축을 풉니다. 이 마지막 단계는 약간 복잡할 수도 있습니다. 하지만 압축을 푼 후 나타나는 파일은 원시 드라이버 파일인 .inf, .sys, .dll과 드라이버 자체에 필요한 관련 파일입니다.
드라이버 파일의 압축을 푼 후에는 Drivers(드라이버) 노드를 마우스 오른쪽 단추로 클릭하고 New Deployment(새 배포)를 선택하여 New Driver Wizard(새 드라이버 마법사)를 실행합니다. Deployment Workbench(배포 워크벤치)에서 자동으로 디렉터리 구조를 검색하여 모든 .inf 파일을 찾으므로 압축이 풀린 디렉터리 구조를 정리할 필요가 없습니다.
드라이버를 가져올 때 Deployment Workbench(배포 워크벤치)는 지원되는 플랫폼, 제조업체 및 버전, 드라이버에서 지원하는 PnP(플러그 앤 플레이) ID 목록 등 드라이버 정보가 모두 포함된 카탈로그를 만듭니다.

드라이버에 대해 수행할 작업: 앞서 가져온 운영 체제 이미지에 드라이버 포함
BDD 2007은 가져온 OS 이미지를 수정하지 않습니다. 대신 배포 프로세스 중에 드라이버가 포함됩니다. 기본 프로세스는 다음과 같습니다.
  1. 배포할 대상 컴퓨터에서 Microsoft.BDD.PnpEnum.exe 유틸리티를 실행하여 컴퓨터에 있는 모든 PnP ID를 확인합니다.
  2. 드라이버 카탈로그에 있는 각 PnP ID를 검토합니다. 일치하는 각 항목에 대해 필요한 드라이버 파일을 컴퓨터에 복사합니다.
  3. 디스크에 이미지를 적용한 후에, 그리고 Windows Vista를 처음 시작하기 전에 OS로 드라이버를 주입하도록 Windows Vista 설치 프로그램에 지시합니다. 운영 체제를 시작하는 데 대용량 저장소 드라이버와 같은 몇 가지 드라이버가 필요할 수도 있으므로 이 단계는 매우 중요합니다.

이제 배포할 준비가 되었을까요?
배포를 시작하기 전에 수행해야 할 몇 가지 단계가 더 있습니다. 먼저, 배포 공유에 있는 운영 체제와 사용해야 할 설정을 연결하는 빌드를 정의하고 OS 설치와 구성을 수행하는 데 필요한 작업의 순서를 정의해야 합니다.
이 빌드를 만들려면 Builds(빌드) 노드를 마우스 오른쪽 단추로 클릭하고 New(새로 만들기)를 선택하여 New Build Wizard(새 빌드 마법사)를 시작합니다. 빌드 ID(공백 또는 특수 문자를 제외한 사용자 지정 단순 값), 빌드 이름 및 설명을 지정합니다. 빌드 이름과 설명은 운영 체제를 배포할 때 표시됩니다(그림 3 참조). 그런 다음 설치할 운영 체제를 선택하고 사용할 몇 가지 기본 설정을 지정합니다.
그림 3 기본 빌드 정보 지정
그림 3 기본 빌드 정보 지정

자, 이제는 배포할 준비가 되었을까요?
한 가지가 더 필요한데, 바로 배포 지점입니다. 간단히 말해, 배포 지점은 지금까지 수집한 모든 파일, 모든 빌드 정보, 배포 프로세스에 사용할 Windows PE 이미지가 들어 있는 네트워크 공유입니다. 배포 지점을 만드는 방법은 앞서 살펴본 여러 단계와 비슷합니다. Deployment Points(배포 지점) 노드를 마우스 오른쪽 단추로 클릭하고 New(새로 만들기)를 선택합니다. Lab or single-server deployment(테스트 환경 또는 단일 서버 배포)(그림 4 참조)를 선택하고 나머지는 기본값을 그대로 사용합니다.
그림 4 배포 지점의 유형 선택
그림 4 배포 지점의 유형 선택
마법사를 완료한 후 목록 창에서 새 배포 지점을 마우스 오른쪽 단추로 클릭하고 Update(업데이트)를 선택하여 공유 및 Windows PE 이미지를 생성합니다.
앞서 추가한 드라이버를 기억하십니까? 이 드라이버 중에서 최소한 네트워크 드라이버와 대용량 저장소 드라이버는 Windows PE에도 필요하므로 업데이트 프로세스 중에 이러한 드라이버가 자동으로 Windows PE 이미지에 추가됩니다.

이제 정말로 배포할 준비가 되었을까요?
그렇습니다. 먼저 새 컴퓨터에 배포해 보겠습니다. \distribution\boot 폴더에서 LiteTouchPE_x86.iso 파일을 가져와서 원하는 CD 작성기 소프트웨어 또는 Microsoft(go.microsoft.com/fwlink/?LinkID=77796)에서 다운로드할 수 있는 cdburn.exe 도구를 사용하여 CD-R에 굽습니다. CD에서 컴퓨터를 부팅합니다. 그러면 Windows PE가 시작되고 그림 5와 같이 마법사의 초기 시작 화면이 표시됩니다.
그림 5 배포 시작 준비 완료
그림 5 배포 시작 준비 완료
Run the Deployment Wizard(배포 마법사 실행)를 선택하고 Next(다음)를 클릭하여 마법사를 시작합니다. 이때 앞서 정의한 빌드, 추가한 응용 프로그램, 가져온 언어 팩을 선택할 수 있습니다. 도메인에 참가하도록 선택하거나 컴퓨터 이름을 지정하거나 다양한 다른 설정을 구성할 수도 있습니다. Sysprep, Windows PE 및 ImageX를 사용하여 새 이미지 파일 생성하는 방법으로 새 사용자 지정 이미지를 자동으로 캡처하도록 지정할 수도 있습니다.
컴퓨터의 종류와 속도에 따라 배포가 완료되는 데 다소 시간이 걸릴 수 있지만 사용자의 작업이 필요하지는 않습니다. 배포 마법사가 완료되면 배포 프로세스 중 기록된 경고나 오류를 보여 주는 요약 화면이 표시됩니다. 이를 통해 배포가 성공적으로 완료되었는지 여부를 쉽게 확인할 수 있습니다. 노란색이나 빨간색 요약 화면은 주의가 필요함을 나타내고 흰색 요약 화면은 모든 것이 정상적으로 실행되었음을 나타냅니다.
이제 Windows XP가 이미 설치되어 있는 컴퓨터에 배포해 보겠습니다. 명령 프롬프트에서 BDD 2007 서버에 만들어 둔 Distribution$ 공유에 드라이브를 매핑한 다음 LiteTouch.vbs를 실행하여 배포를 시작합니다.
NET USE M: \\MyServer\Distribution$
cscript.exe M:\Scripts\LiteTouch.vbs
그러면 몇 가지 새 옵션이 추가된 것만 제외하고는 앞에서 본 것과 같은 배포 마법사가 시작됩니다(그림 6 참조).
그림 6 Windows XP를 실행하는 컴퓨터에서의 옵션
그림 6 Windows XP를 실행하는 컴퓨터에서의 옵션
Refresh this computer(이 컴퓨터 새로 고침)를 선택한 경우 기존 OS가 제거됩니다. 필요한 경우 사용자 상태 마이그레이션 도구를 사용하여 사용자 데이터와 설정을 캡처한 후 이 작업을 수행할 수도 있습니다. 사용자 상태 마이그레이션 도구는 Windows AIK와 마찬가지로 Components(구성 요소) 노드를 사용하여 다운로드해야 합니다. Refresh this computer(이 컴퓨터 새로 고침)를 선택한 경우에는 Windows Vista 새로 설치가 실행됩니다. Upgrade this computer(이 컴퓨터 업그레이드)를 선택할 수도 있습니다. 이 경우 Windows Vista 설치 프로그램이 컴퓨터에 있는 기존 응용 프로그램, 데이터 및 설정은 그대로 유지하면서 기존 OS를 업그레이드합니다. 여러 가지 요인에 따라 선택하는 옵션이 다를 수 있지만, 대부분의 경우에는 새로 고침을 수행하여 문제가 없는 빈 상태로 시작합니다.

숙지해야 할 추가 사항
Windows XP 배포 관련 사항
Windows XP를 배포하는 경우에도 문제는 없습니다. 이때도 BDD 2007을 사용하여 배포를 완료할 수 있습니다. 단계는 Windows Vista를 배포할 때와 동일합니다. Windows XP 설치 파일을 사용하여 초기 빌드를 만들고 새 Windows XP WIM(Windows Imaging) 이미지를 캡처하기만 하면 됩니다. Windows XP 이미지를 배포하는 것이 무인 설치보다 훨씬 빠릅니다. 그런 다음 이후 배포 시 이 WIM 파일을 사용하면 됩니다.
Windows XP를 배포할 때는 Windows Vista를 배포할 때와는 달리 해결해야 할 몇 가지 추가적인 문제가 있습니다.
Windows XP 대용량 저장소 드라이버에는 TEXTMODE 폴더, unattend.txt 설정, sysprep.inf 설정 등의 추가 구성이 필요합니다. 물론 대용량 저장소 드라이버는 기존 Windows XP 이미지에 포함할 수 없으므로 또 다른 대용량 저장소 드라이버를 추가할 때마다 새 이미지를 캡처해야 합니다. 뿐만 아니라 Windows XP 이미지는 HAL에 종속되므로 두세 개의 별도의 이미지가 필요할 수 있습니다. 또한 언어 팩과 보안 업데이트는 오프라인으로 Windows XP에 포함할 수 없으므로 Windows XP를 시작하여 실행한 후 설치해야 합니다.
Windows XP 배포에 BDD 2007을 사용한다면 Windows Vista 배포는 이미 준비되어 있는 것과 마찬가지입니다. 배포 시기만 적절하게 선택하면 됩니다.

지금까지 설명한 내용은 겉핥기에 불과합니다. 그러나 이 프로세스가 처음부터 끝까지 작동하는 방법을 살펴보면 모든 새로운 도구 각각에 대해서는 자세히 모르더라도 도구들의 상호 작용 방식은 알 수 있습니다. 이제 BDD 2007 스크립트와 로그를 검토하여 어떤 작업이 수행되었는지 살펴볼 수 있습니다. 원하는 사용자 지정 이미지를 만들고 BDD 2007에 추가하여 표준 Windows Vista 이미지 대신 배포할 수 있습니다. 사용자 지정 이미지가 로드된 DVD 미디어 또는 USB 플래시 드라이브를 만들 수 있습니다. SMS 2003과 해당 OS 배포 기능 팩을 이 프로세스에 통합할 수도 있습니다.

추가 정보 확인
이 칼럼에서는 자세히 다루지 않은 문서도 모두 읽어 보십시오. 배포 프로젝트에 참여한 다양한 팀에서 분야별로 작성한 문서가 1,000페이지 이상 있습니다. 앞에서 언급한 microsoft.com/desktopdeployment 사이트도 확인하십시오. Windows 배포와 관련하여 IT 전문가들의 다양한 질문이 게시된 microsoft.public.deployment.desktop 뉴스 그룹을 이용할 수도 있습니다. deployvista.com 및 myitforum.com과 같은 타사 웹 사이트도 참조할 수 있습니다. 이들 사이트에는 BDD 2007 및 Windows Vista 배포에 관한 수많은 정보가 있습니다. Microsoft Press에서 제공하는 새 Windows Vista Resource Kit 서적(microsoft.com/mspress/books/9536.aspx)도 훌륭한 참고 자료입니다. 필자의 블로그(blogs.technet.com/mniehaus)에서는 BDD 2007의 여러 기능에 대한 다양한 의견을 볼 수 있습니다. 해당 지역에서 이용할 수 있는 BDD 2007 및 Windows Vista 교육 세미나에 대해서는 해당 지역의 Microsoft 담당자에게 문의하십시오. 마지막으로 "배포 리소스" 추가 기사를 참조하십시오.
Microsoft Office System의 Software Assurance 고객인 경우 Desktop Deployment Planning Services(microsoft.com/licensing/sa/benefits/deployment.mspx)를 이용할 수 있습니다. 이 서비스를 이용할 경우 Microsoft 또는 Microsoft 파트너가 사용자와의 긴밀한 협력을 통해 계획을 수립하거나 직접 사용자 조직을 방문하여 개념 검증 테스트 환경을 설정하는 작업을 도와 줍니다.
배포 리소스
  • Microsoft Desktop Deployment Center microsoft.com/desktopdeployment
  • Windows Vista 배포에 대해 알아야 할 10가지 사항 technetmagazine.com/issues/2006/11/Deployment
  • Microsoft .NET Framework 2.0 go.microsoft.com/fwlink/?LinkId=94601
  • Windows Server 2003용 Microsoft Management Console 3.0(KB907265) go.microsoft.com/fwlink/?LinkId=94602
  • 보안 공지 및 권고 microsoft.com/technet/security/bulletinsandadvisories

Michael Niehaus는 Microsoft의 Solution Accelerators 팀의 시스템 디자인 엔지니어로, Business Desktop Deployment를 위한 모범 사례, 도구 및 스크립트를 개발하고 있습니다. 문의 사항이 있으면 michael.niehaus@microsoft.com으로 연락하십시오.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Windows Vista: Windows Vista 백업 기술
Windows Vista Christine Fok

Windows Vista 백업 기술
한 눈에 보기:
  • 파일 백업 및 복원
  • Windows Complete PC 백업 및 복원
  • 시스템 복원
  • 섀도 복사본

대부분의 사람들은 데이터가 이미 손실된 뒤에야 데이터 백업을 고려하게 되며, 이런 일은 발생하지 않아야 하지만 여전히 발생하고 있는 것이 현실입니다. Windows Vista는 광범위한 기능을 통해 백업을 간편하게 만듦으로써 데이터를 완벽하게 보호하는 데 목표를 둡니다.
친숙한 시스템 복원 기능은 보다 다양한 시스템 복구 시나리오를 지원할 수 있도록 더욱 강력하게 재설계되었습니다. 파일 백업 기능은 보다 간편한 방법으로 데이터를 완벽하게 보호할 수 있도록 개선되었으며 Windows® Complete PC 백업 및 복원과 섀도 복사본이라는 두 가지 새로운 기능도 추가되었습니다.
이러한 기능은 모두 어떤 식으로든 볼륨 섀도 복사본 서비스에 의존합니다. 볼륨 섀도 복사본은 "섀도 복사본"이라는 볼륨의 특정 시점 복사본을 만든 다음 섀도 복사본 간의 변경 내용을 추적하는 서비스입니다.
새로 소개된 백업 및 복원 센터(그림 1 참조)에서 사용할 수 있는 이 네 가지 기능은 모두 데이터를 백업하고 복원하는 데 사용할 수 있지만 각 기능의 성격은 많이 다릅니다. 하지만 이 네 가지 기능을 함께 사용한다면 컴퓨터의 수명이 다할 때까지 다양한 형태의 데이터 손실로부터 데이터를 완벽하게 보호할 수 있습니다.
그림 1 Windows Vista의 백업 및 복원 센터
그림 1 Windows Vista의 백업 및 복원 센터

파일 백업
Complete PC 백업 예약
정기적으로 Complete PC 백업을 수행하도록 예약하면 항상 전체 컴퓨터의 최신 이미지를 보관할 수 있습니다. Complete PC 백업은 제어판에서 예약할 수 없으며 작업 스케줄러에서 새 작업을 만들어 예약할 수 있습니다. Complete PC 백업을 예약하는 경우 정기적인 모니터링을 통해 백업이 성공적으로 완료되었는지 확인하는 것이 좋습니다. 이것은 예약을 사용하는 경우, 디스크 공간 문제나 일시적인 문제로 인해 백업이 실패해도 이를 알려주는 팝업 메시지가 표시되지 않기 때문입니다. Complete PC 백업을 예약했더라도 파일 백업을 정기적으로 수행해야 합니다. 지금부터는 작업 스케줄러를 사용하여 Complete PC 백업을 예약하는 방법을 설명하겠습니다.
  1. 시작 메뉴의 모든 프로그램에 있는 보조프로그램/시스템 도구 폴더에서 작업 스케줄러로 이동합니다.
  2. 작업 만들기를 클릭합니다.
  3. 일반 탭으로 이동합니다.
  4. 작업에 대해 설명하는 이름(예: 예약된 Complete PC 백업)을 입력합니다.
  5. 로그온 여부에 관계없이 작업을 실행하려면 사용자의 로그온 여부에 관계없이 실행을 클릭합니다.
  6. 가장 높은 수준의 권한으로 실행을 클릭합니다.
  7. 트리거 페이지로 이동합니다.
  8. 새로 만들기를 클릭하고 예약한 백업을 수행할 시기와 간격을 지정합니다.
  9. 작업 페이지로 이동합니다.
  10. 새로 만들기를 클릭합니다.
  11. 프로그램/스크립트에서 wbadmin을 입력합니다.
  12. 인수 추가(옵션)에서 필요에 따라 다음 명령을 입력합니다. 대상 드라이브 문자는 필요에 맞게 수정합니다.
    Start backup –allcritical –backupTarget:D: -quiet
    시스템 볼륨, 부팅 볼륨 또는 Windows 복구 환경 볼륨이 아닌 다른 볼륨을 추가로 포함하려면 대신 다음 문을 사용합니다. E와 F는 적절한 드라이브 문자로 바꾸고 쉼표로 구분합니다.
    Start backup –allcritical –backupTarget:D: -include:E:,F: -quiet
    이 명령에는 항상 allcritical 플래그를 포함해야 합니다. 이 플래그를 포함하지 않으면 중요한 시스템 볼륨이 백업에서 누락되어 복원 중 오류가 발생할 수 있습니다.
  13. 작업과 관련된 다른 설정을 구성합니다.
  14. 확인을 클릭합니다.

새 랩톱을 구입했다고 가정해 보겠습니다. 새 시스템에 사진, Microsoft® Word 문서 등의 다양한 파일을 복사하고 응용 프로그램을 설치하고 최신 Windows 업데이트를 다운로드한 후 파일 백업을 수행하려고 합니다. 백업을 위해 랩톱에 외부 하드 드라이브를 연결하고 백업 및 복원 센터로 이동합니다. 파일 백업 단추를 클릭하면 해당 단계를 자세히 안내하는 마법사가 나타납니다. 마법사에서 백업 대상(이 예의 경우, 외부 하드 드라이브), 백업할 파일 범주(예: 그림), 백업 수행 시기 등을 지정합니다.
파일 백업에서는 백업할 파일을 범주에 따라 지정합니다. 원본 하드 드라이브는 NTFS로 포맷되어 있어야 하지만 대상 하드 드라이브는 NTFS 또는 FAT로 포맷된 드라이브 모두 가능합니다. 파일이 특정 범주와 연결되어 있는지 여부는 MIME 형식, 연결된 응용 프로그램, 파일 확장명의 세 가지 요소를 통해 확인할 수 있습니다.
Windows에서 인식할 수 없는 확장명을 가진 파일과 같이 어느 범주에도 해당하지 않는 파일을 백업하는 경우에는 기타 파일 범주를 선택하면 됩니다. 하지만 실행 파일과 시스템 파일은 지원되지 않습니다. 이러한 파일에는 사용자 데이터가 거의 포함되지 않으므로 파일 백업에서 백업하지 않습니다. 파일 백업으로 시스템 파일과 실행 파일을 백업하려는 경우에는 파일을 .zip 파일로 압축한 다음 마법사에서 압축 파일 범주를 선택합니다.
지금은 새 랩톱에서 백업 기능을 처음 사용하는 경우이므로 선택한 범주의 파일을 모두 백업하는 전체 백업이 곧바로 수행됩니다. 이후에는 증분 백업만 수행됩니다. 파일 백업에서 증분이란 업데이트되거나 새로 추가된 파일만 추적한다는 것을 의미합니다. 예를 들어 이전 Word 문서에 몇 가지 변경을 가한 경우 파일 백업 도구는 이전 문서 및 업데이트된 문서의 복사본을 둘 다 유지합니다. 하나의 전체 백업과 이후에 만들어진 일련의 증분 백업을 백업 세트라고 합니다.
증분 백업만 계속 할 것이 아니라, 마지막 전체 백업 이후 경과한 시간, 백업하는 파일의 수, 백업에 사용한 CD 또는 DVD 수와 같은 여러 가지 요인을 고려하여 필요할 때 전체 백업을 수행해야 합니다. 이렇게 하면 자체로 완전한 기본 백업을 언제든지 사용할 수 있습니다.
백업된 데이터는 크기가 최대 200MB인 여러 개의 .zip 파일에 저장되므로 거의 모든 경우에 데이터에 액세스할 수 있습니다. 예를 들어 백업 미디어에서 직접 데이터를 찾아서 Windows Vista를 실행하지 않는 컴퓨터에 복원할 수 있습니다. 백업 데이터는 별개의 파일에 저장되고 여러 디스크에 분산되므로 한 디스크에서 오류가 발생하더라도 다른 미디어의 백업 데이터에는 액세스할 수 있습니다.
파일 백업의 경우 응용 프로그램에서 열려 있거나 사용 중인 파일의 일관된 복사본을 만드는 데 볼륨 섀도 복사본 서비스가 사용됩니다. 백업 프로세스 중 백업 응용 프로그램은 이러한 일관된 복사본에서 데이터를 읽습니다. 따라서 Microsoft Outlook®에서 항상 열려 있는 .pst 파일을 백업하는 등의 경우에 매우 유용합니다. 볼륨 섀도 복사본 서비스는 복원 중 백업된 .pst 파일에 액세스할 수 있도록 파일을 일관된 상태로 유지합니다.
파일 백업은 자동으로 삭제되지 않습니다. 공간이 부족하면 파일 백업을 수동으로 삭제할 수 있습니다. 증분 백업의 경우 개별적으로 삭제하는 반면 전체 백업은 항상 전체 백업 세트를 삭제해야 합니다.
또한 파일 백업을 다른 위치에 복사하지 않는 것이 좋습니다. 꼭 필요한 경우에는 단일 원본 백업 미디어를 다른 단일 대상 미디어로 이동하는 것만 가능하다는 사실을 염두에 두십시오. 예를 들어 한 CD의 백업 데이터를 한 DVD에 복사할 수는 있지만 여러 CD의 데이터를 한 DVD에 복사할 수는 없습니다. 백업을 이동할 때는 백업 미디어의 루트에 있는 컴퓨터 이름 및 mediaid.bin 파일과 함께 백업 폴더를 복사해야 합니다. 다른 곳으로 이동한 파일을 복원하는 경우 컴퓨터의 백업 카탈로그가 새 백업 위치를 알지 못하므로 백업 제어판에서 고급 복원 | 다른 컴퓨터에서 만든 백업 파일을 선택하여 해당 파일에 액세스해야 합니다.

Complete PC 백업
새 랩톱에 필요한 모든 것을 설치하고 구성했으므로 지금부터는 OS, 설치한 응용 프로그램, 구성 설정 및 업데이트를 비롯한 모든 데이터를 보호하기 위해 전체 백업을 수행하려고 합니다. Complete PC 백업 기능을 사용하면 하드 드라이브 오류나 다른 장애가 발생할 경우 Complete PC 백업 기능이 백업한 데이터를 사용하여 시스템을 복구할 수 있습니다. 또한 응용 프로그램을 개별적으로 설치하거나 구성 설정 작업을 모두 다시 수행할 필요가 없습니다. Complete PC 백업을 처음 실행하는 경우, 정보가 저장되지 않은 블록을 제외한 선택한 볼륨의 모든 블록에 대해 전체 백업이 수행됩니다. 이후의 백업은 블록 수준별로 다르며 이에 대해서는 잠시 후에 자세히 살펴보겠습니다.
백업을 수행하고 나면 백업 및 복원 센터 제어판이 업데이트되어 백업이 수행된 시기 및 백업 저장 위치와 같은 정보가 표시됩니다(그림 2 참조).
그림 2 이전 백업에 대한 자세한 정보를 보여 주는 백업 및 복원 센터
그림 2 이전 백업에 대한 자세한 정보를 보여 주는 백업 및 복원 센터
Complete PC 백업과 파일 백업 모두 백업을 수행하지만 작동 방식은 완전히 다릅니다. Complete PC 백업은 가상 하드 드라이브 형식(.vhd)으로 전체 컴퓨터에 대한 블록 수준 이미지 백업을 만듭니다. 첫 번째 전체 백업을 수행하는 동안 백업 엔진은 디스크를 검색하여 데이터가 들어 있는 블록을 대상 디스크에 저장된 .vhd 파일에 복사합니다. 백업된 데이터가 압축되어 있지 않더라도 이 파일은 압축됩니다.
이후에 Complete PC 백업을 수행할 때는 새로 추가되거나 변경된 데이터만 .vhd 파일에 기록되고 동일한 블록에 있는 이전 데이터는 섀도 복사본 저장 영역으로 이동됩니다. 이때 볼륨 섀도 복사본 서비스는 만들어진 스냅숏 간의 차이점을 계산하고 이전 데이터를 대상 디스크의 섀도 복사본 영역으로 이동하는 프로세스를 처리합니다(그림 3 참조). 변경된 블록만 백업되고 또한 데이터가 압축된 형식으로 저장되므로 백업이 빠르고 효율적으로 수행됩니다. 대상 디스크에서 사용할 수 있는 섀도 복사본 최대 저장 공간은 백업 응용 프로그램에서 정의합니다. 시스템에 대해 Complete PC 백업을 정기적으로 또는 자동으로 실행하는 단계별 절차를 보려면 "Complete PC 백업 예약" 추가 기사를 참조하십시오.
그림 3 Complete PC 백업 및 복원의 데이터 이동 방법
그림 3 Complete PC 백업 및 복원의 데이터 이동 방법
데이터를 복원할 때 블록은 원래 위치에 복원됩니다. 이전 백업에서 복원하는 경우 백업 엔진은 섀도 복사본 영역에서 데이터를 읽어 적절한 블록을 복원합니다.
Complete PC 백업은 NTFS로 포맷된 디스크만 백업할 수 있습니다. 백업 대상이 하드 드라이브인 경우 NTFS로 포맷되어 있어야 합니다.

시스템 복원
시스템 복원은 기본적으로 사용됩니다. 백업 및 복원 센터의 왼쪽 위에 있는 “시스템 복원을 사용하여 Windows 복구”를 사용하여 시스템 복원 마법사에 액세스합니다. 시작 메뉴, 모든 프로그램, 보조프로그램, 시스템 도구 폴더에서 이 마법사에 액세스할 수도 있습니다. "다른 복원 지점 선택"을 클릭하고 다음을 클릭하면 랩톱을 설정하고, 응용 프로그램을 설치하고, 백업을 수행하는 동안 다양한 위치에 만들어진 복원 지점을 확인할 수 있습니다.
시스템의 하드 디스크에 여러 개의 볼륨이 있더라도 복원 지점은 기본적으로 시스템의 부팅 볼륨에서만 설정됩니다. 복원 지점은 응용 프로그램과 드라이버를 설치하는 동안 만들어지며, 선택한 여러 볼륨에서 매일 만들어집니다(해당 날짜에 복원 지점이 이미 만들어지지 않은 경우). 시스템 제어판 애플릿에서 시스템 보호 옵션을 선택하여 복원 지점을 수동으로 만들 수도 있습니다. 파일 백업 및 Complete PC 백업 중 만들어진 섀도 복사본도 복원 지점으로 사용할 수 있습니다.
Windows XP의 시스템 복원 기능은 파일 시스템 필터를 사용하여 시스템 파일의 변경을 추적합니다. Windows Vista의 시스템 복원 기능은 볼륨 섀도 복사본 서비스를 사용하여 선택된 볼륨의 변경을 블록 수준으로 추적합니다. 이 때문에 시스템 복원은 다른 기능보다 강력하며 광범위한 복구 시나리오를 지원합니다.
뿐만 아니라 이제 설치된 Windows가 오프라인에 있는 경우에도 시스템 복원을 실행할 수 있게 되었습니다. Windows 복구 환경을 사용하여 시스템 복원이 수행되므로 Windows를 부팅할 수 없는 경우에도 시스템을 복구할 수 있게 된 것입니다.

섀도 복사본
사용자가 섀도 복사본에 대해 신경 써야 하는 경우는 거의 없습니다. 섀도 복사본은 기본적으로 사용되며 사용자의 작업이 필요하지 않습니다. 사용자가 파일을 복원해야 할 때 이 기능의 존재를 처음 알게 되는 경우가 많을 것입니다. 섀도 복사본은 기본적으로 볼륨 섀도 복사본 서비스로 만들어진 파일의 특정 시점 복사본을 제공합니다.

섀도 복사본 공간 관리
라이브 볼륨과 Complete PC 백업용 백업 디스크에는 섀도 복사본용으로 예약된 별도의 저장 공간이 있습니다. 관리자 권한으로 실행한 명령 프롬프트에서 다음 명령을 실행하여 섀도 복사본 저장 공간의 사용된 공간, 할당된 공간 및 최대 공간을 확인할 수 있습니다.
VSSAdmin list ShadowStorage
사용된 공간은 현재 섀도 복사본에 사용된 공간을 나타내고 할당된 공간은 섀도 복사본용으로 예약되어 있으며 다른 용도로는 사용할 수 없는 공간을 나타내며 최대 공간은 섀도 복사본이 차지할 수 있는 크기 제한을 나타냅니다.
섀도 복사본에 대한 공간 할당은 자동으로 이루어지므로 사용자가 설정할 수 없습니다. 이전에 할당된 공간이 모두 사용되면 그때마다 고정된 증가 값으로 새 공간이 할당됩니다. 사용된 공간 값이 항상 할당된 공간 값보다 작은 것은 바로 이 때문입니다.
라이브 볼륨의 경우, 첫 번째 섀도 복사본이 만들어질 때 허용되는 최대 섀도 저장 공간이 결정되며, 대개 이는 시스템 복원 기능을 처음 실행할 때이자 설치하는 동안 복원 지점이 만들어질 때입니다. 최대 섀도 저장 공간은 사용 가능한 공간의 30% 또는 볼륨 전체 크기의 15%에 해당하는 공간 중 작은 공간으로 결정됩니다. 이 크기는 정적이어서 사용 가능한 공간의 양이 늘거나 줄어도, 그리고 볼륨 크기가 조정된 후에도 변경되지 않습니다.
하지만 관리자 권한으로 실행한 명령 프롬프트에서 VSSAdmin 도구를 사용하여 이 저장 공간의 크기를 수동으로 조정할 수 있습니다. 예를 들어 C:\에서 최대 저장 공간 크기를 15GB로 늘리려면 다음 명령을 실행합니다.
VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB
이 도구는 특정 볼륨의 섀도 복사본을 다른 볼륨에서 관리할 수 있게 된 Windows Server®에서 처음 소개되었습니다. Windows Vista에서는 볼륨의 여러 섀도 복사본이 동일한 볼륨에 보관됩니다. 따라서 "섀도 복사본을 만드는 대상(For)" 볼륨과 "섀도 복사본이 있는(On)" 볼륨이 같아야 합니다.
반면 Complete PC 백업용 백업 대상 디스크는 최대 섀도 복사본 저장 크기가 디스크 공간의 30%로 고정되어 있습니다. 이 값은 Complete PC 백업 기능이 제어하며 수동으로 변경할 수 없습니다. 이 섀도 복사본 저장 공간은 Complete PC 백업의 증분 백업을 저장하는 데 사용됩니다.
섀도 복사본 저장 영역에 충분한 공간만 있다면 볼륨 하나에 최대 64개의 섀도 복사본을 보관할 수 있습니다. 최대 공간 제한에 도달하면 새 섀도 복사본을 보관할 수 있도록 이전 섀도 복사본이 삭제됩니다. 따라서 라이브 볼륨에서 섀도 저장 공간 크기 제한에 도달하면 시스템 복원의 이전 복원 지점이 삭제되고 백업 디스크에서 크기 제한에 도달하면 이전의 Complete PC 백업이 삭제됩니다. 뿐만 아니라 백업 디스크에 다른 데이터를 저장하고 편집하면 이전 백업에 대한 에이징 프로세스가 정상적으로 수행되지 않아 이전 백업이 빠른 속도로 삭제됩니다.

섀도 복사본을 사용하여 파일 복원
한 동안 이 랩톱에서 몇 가지 프레젠테이션을 만들었다고 가정해 보겠습니다. 프레젠테이션을 완성하여 고객에게 전달했습니다. 프레젠테이션 파일을 삭제한 후 한 달이 지났고 이제 새 프로젝트에 착수하려고 합니다. 그런데 상관이 이전 프레젠테이션의 복사본을 요청했습니다. 바로 이러한 경우에 섀도 복사본이 유용합니다.
삭제한 파일의 복사본을 찾는 방법은 두 가지입니다. 파일이 저장된 위치를 알고 있는 경우에는 삭제한 파일이 있었던 폴더를 마우스 오른쪽 단추로 클릭하고 "이전 버전 복원"을 선택하기만 하면 됩니다. 그 다음 복원할 파일 버전이 포함된 날짜를 선택하고(그림 4 참조) 열기를 클릭한 다음 대상 파일을 라이브 볼륨의 다른 위치에 복사합니다. 이 복사 작업은 일반 파일 복사만큼 빠르게 수행됩니다.
그림 4 삭제한 파일 복원
그림 4 삭제한 파일 복원
파일이 저장된 위치를 기억하지 못하는 경우에는 파일 트리에서 해당 파일과 가장 가까운 상위 폴더의 이전 버전을 연 다음 여기에서 검색할 수 있습니다. 예를 들어 특정 폴더의 위치는 기억하지 못하지만 문서 폴더 내의 한 하위 폴더에 있었다는 것을 기억하는 경우, Windows 탐색기 창의 오른쪽 위에 있는 검색 상자에 파일 이름 전체 또는 일부를 입력하고 문서 폴더의 이전 버전을 검색할 수 있습니다(그림 5 참조). 루트 폴더에서는 섀도 복사본 검색 기능이 작동하지 않습니다. 또한 섀도 복사본은 인덱싱되지 않으므로 라이브 볼륨에서 검색할 때보다 검색 시간이 길어질 수 있습니다.
그림 5 파일 이름 일부를 입력하여 문서 폴더의 이전 버전 검색
그림 5 파일 이름 일부를 입력하여 문서 폴더의 이전 버전 검색

파일 백업에서 파일 복원
섀도 복사본은 사용 가능한 공간을 관리하기 위해 정기적으로 정리되므로 영구히 사용할 수는 없습니다. 섀도 복사본으로는 복원할 수 없는 파일이 필요한 경우 예약된 파일 백업을 이용할 수 있습니다. 백업 및 복원 센터에서 파일 복원을 선택하고 삭제한 프레젠테이션이 포함된 백업 날짜를 선택해 보겠습니다. 파일 추가 단추를 클릭하면 백업을 탐색할 수 있는 파일 열기 대화 상자가 나타납니다. 찾고 있는 파일을 선택하면 이전과 같은 위치 또는 다른 위치에 파일을 복원할 수 있는 옵션이 표시됩니다.
파일 복원 옵션은 최신 백업 세트에 포함된 백업만 표시합니다. 이전 백업 세트의 백업을 보려면 고급 복원을 선택하고 이 컴퓨터에서 만든 이전 백업 파일을 선택합니다. 드물기는 하지만 이 옵션을 사용하여 이전 백업 세트를 찾을 수 없는 경우, 고급 복원을 선택하고 다른 컴퓨터에서 만든 백업 파일 옵션을 선택합니다. 컴퓨터의 백업 카탈로그가 너무 커져서 잘린 경우 이와 같은 상황이 발생할 수 있습니다.

Complete PC 백업에서 파일 복원
Complete PC 백업은 개별 파일을 복원하는 데도 사용할 수 있습니다. Complete PC 백업은 원래 볼륨 수준 복원에 맞게 설계되었지만 데이터를 .vhd 형식으로 저장하므로 오프라인 VHD 탑재 도구를 사용하여 개별 파일에 액세스하여 파일을 복원할 수 있습니다. 이 문서를 작성하는 시점에서는 microsoft.com/technet/prodtechnol/eval/virtualserver에서 다운로드할 수 있는 Microsoft Virtual Server 2005 R2 SP1의 일부로만 VHD 탑재 도구를 사용할 수 있습니다. 백업을 탑재하려면 관리자 권한으로 명령 프롬프트를 열고 Microsoft Virtual Server\Vhdmount로 이동한 다음 다음 명령을 사용합니다.
vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]
이 작업을 처음 수행하는 경우 필요한 드라이버가 할당되어 있지 않아서 드라이버가 선택되지 않을 수도 있습니다. 이 경우 장치 드라이버를 로드할 수 없음을 알려주는 오류 메시지가 표시됩니다. 이 문제를 해결하려면 위의 명령을 사용하여 .vhd 파일에 액세스한 후 장치 관리자로 이동하여 표시되는 새 장치를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다. 여기에서 드라이버 탭으로 이동한 후 드라이버 업데이트를 선택하고 컴퓨터에서 드라이버 소프트웨어 찾아보기를 클릭한 다음 컴퓨터의 장치 드라이버 목록에서 직접 선택을 클릭합니다. 올바른 드라이버 파일은 Microsoft Virtual Server\Vhdmount\vhdstor.inf에 있습니다. 파일을 설치하고 나면 새 드라이브가 나타납니다. 그러면 최신 Complete PC 백업을 찾아 원하는 파일을 다른 위치에 복사할 수 있습니다.

Complete PC 복원
어느 화창한 날 오후에 수영장에서 랩톱을 사용하려 한다고 가정해 보겠습니다. 수영장 바닥이 미끄러워 넘어졌는데 랩톱이 물속에 빠졌습니다. 이런 경우에는 복구가 불가능하므로 새 랩톱을 구입하는 것 외에는 방법이 없습니다. 이전에 Complete PC 백업 도구를 실행했으므로 새 랩톱에 시스템을 복원하는 데 아무런 문제가 없습니다. 각 응용 프로그램을 수동으로 설치하고 개인 설정으로 응용 프로그램을 다시 구성하는 데 많은 시간을 들일 필요도 없습니다. Complete PC 복원은 매우 쉽습니다. 시작할 때 Windows Vista 설치 디스크를 사용하여 Windows 복구 환경으로 부팅합니다. 이때 시스템 이미지가 들어 있는 장치에 연결할지 묻는 메시지가 표시됩니다. 적절한 이미지를 선택하면 복원 프로세스가 시작됩니다.
복원이 완료되고 나면 최신 파일 백업에서 파일 복원을 수행합니다. 최신 파일 백업을 사용하는 이유는 이전 랩톱에서 파일 백업을 자주 수행하여 파일 백업에 포함된 데이터가 최신 데이터이기 때문입니다. 선택한 파일 백업 이전 시점으로 컴퓨터가 되돌아갔으므로 이 백업에 대한 기록이 카탈로그에 없습니다. 따라서 고급 복원 | 다른 컴퓨터에서 만든 백업 파일 | 이 백업에 있는 모든 파일 복원을 선택합니다. 또한 새로 복원된 데이터를 보호하기 위해 새 전체 백업을 시작합니다.
Windows 복구 환경은 대개 OEM에서 숨겨진 파티션으로 하드 드라이브에 설치하며, Complete PC 백업 이미지를 동일한 하드웨어에 복원하는 데 사용할 수 있습니다. 한 컴퓨터에서 만든 이미지를 다른 컴퓨터에 복원해야 하는 경우에는 Windows 설치 디스크와 같은 외부 미디어에서 Windows 복구 환경을 실행해야 합니다.
이때 몇 가지 주의해야 할 사항이 있습니다. Complete PC 복원은 백업을 가져온 것과 동일한 하드웨어에 복원하는 경우에는 하드웨어 오류와 같은 문제가 없는 한 간단하게 작동합니다.
그러나 Complete PC 백업에는 전체 컴퓨터의 이미지가 포함되므로 다른 하드웨어에 복원하는 경우에는 몇 가지 제한이 따릅니다. 무엇보다도 백업 이미지에는 복원이 완료된 후 컴퓨터를 부팅하는 데 사용되는 드라이버가 포함됩니다. 드물기는 하지만 새 컴퓨터에서 부팅하는 데 필요한 드라이버가 없을 수도 있습니다. 이러한 상황은 한 종류의 디스크 컨트롤러(IDE, SATA 또는 SCSI)에서 가져온 이미지 백업을 다른 종류의 디스크 컨트롤러에 복원하는 경우에 발생할 수 있습니다. 하지만 이미지 백업에 포함된 일반적인 Windows 드라이버는 대부분 호환되므로 이러한 경우에도 대개는 복원을 성공적으로 완료할 수 있습니다.
또한 새 컴퓨터의 하드 드라이브 수가 원래 컴퓨터와 같거나 많아야 하고 각 하드 드라이브 크기가 대체되는 원래 하드 드라이브 크기와 같거나 큰 경우에만 복원을 수행할 수 있습니다. 새 하드웨어로 마이그레이션하는 데 Complete PC 백업을 사용하려는 경우 이러한 제한 사항을 염두에 두어야 합니다.
백업과 복원은 전체 볼륨에 대해 블록 수준으로 수행되므로 Complete PC 복원을 수행하는 경우 볼륨 하나를 완전히 복원하거나 완전히 건너뛰어야 합니다. 따라서 시스템 파일과 데이터 파일을 구분하기 위해 백업 볼륨을 여러 개 만들 수 있습니다. 그러면 복원을 수행할 때 중요한 볼륨으로 표시된 시스템 볼륨만 복원할지 또는 모든 볼륨을 복원할지 선택할 수 있습니다.

실제로 기능 사용
Windows Vista에서는 새로운 백업 기술을 도입하고 기존의 옵션을 개선함으로써 데이터 및 시스템 보호에 있어 Windows XP보다 대폭 향상된 면모를 보여 줍니다. 파일 백업 및 복원, Windows Complete PC 백업 및 복원, 시스템 복원, 섀도 복사본이라는 네 가지 주요 백업 기능은 각기 다르지만 서로를 보완하는 기능을 통해 광범위한 데이터 보호 방법을 제공합니다. 이러한 기능들이 연동되는 방식을 정확하게 이해함으로써 네 가지 방법을 모두 활용하도록 시스템을 구성하고 상황에 맞는 적절한 보호 및 복구 방법을 적용하는 것이 매우 중요합니다.
섀도 복사본 저장소 기능은 대개 데이터의 가장 최신 복사본을 확보하므로 데이터 손실의 경우에 대비하려면 이 기능을 최우선으로 사용하는 것이 좋습니다. 시스템 불안정 및 복구에 대비하려면 시스템 복원을 사용합니다. Complete PC 복원은 대개 전체 시스템 복구를 위한 최후의 수단으로, 신중을 기해 사용해야 합니다. Complete PC 복원이야말로 시스템을 복구할 수 있는 유일한 방법인 경우도 있습니다. 가장 중요한 것은 늦기 전에 대비하는 것입니다. 지금 당장이라도 백업을 수행하십시오.
이 기사를 작성하는 데 도움을 주신 Eduardo Laureano, Ivan Pashov, Jill Zoellere와 그 외 백업 및 복원 제품 팀의 모든 팀원에게 감사의 말을 전합니다.

Christine Fok는 Microsoft 저장소 솔루션 부문의 프로그램 관리자로, Windows 클라이언트 플랫폼의 백업 및 복원 기술을 개발하는 업무를 담당하고 있습니다.


 Windows Server: Active Directory 관리를 위한 11가지 필수 도구
Windows Server Laura E. Hunter

Active Directory 관리를 위한 11가지 필수 도구
한 눈에 보기:
  • 명령줄에서 개체 만들기
  • Active Directory 내에서 일괄 작업 수행
  • Active Directory 업데이트 및 유지 관리

200명의 신입 사원이 나열된 Excel 스프레드시트를 받았거나, 지원 부서의 담당자가 어떤 것을 잘못 클릭하여 사용자 계정이 잘못 구성된 경우 등 Active Directory에 관련된 상황은 다양합니다.
이러한 상황에서 매번 사용자 및 컴퓨터를 여는 것 외에도 더 쉬운 방법으로 Active Directory®를 관리하고자 할 때 도움이 될 수 있는 다양한 무료 관리 도구가 있습니다. Windows® OS에서 기본으로 제공하는 도구도 있고 Resource Kit 또는 Windows 지원 도구로 제공되는 도구도 있으며, 타사의 무료 도구도 있습니다. 이러한 편리한 도구로는 무엇이 있으며 어디에서 찾을 수 있는지 살펴보겠습니다.
우선 Active Directory에서 개체를 만들고, 삭제하고, 수정하고, 검색할 수 있는 Windows Server® 2003 기본 제공 명령줄 도구부터 시작하겠습니다.

CSVDE
CSVDE(Comma-Separated Values Data Exchange) 도구를 사용하면 CSV 원본 파일을 사용하여 새 개체를 Active Directory로 가져올 수 있습니다. 또한 기존 개체를 CSV 파일로 내보낼 수도 있습니다. 기존 개체를 수정하는 데는 CSVDE를 사용할 수 없습니다. 이 도구를 가져오기 모드에서 사용하면 새 개체를 만드는 것만 가능합니다.
CSVDE를 사용하여 기존 개체의 목록을 내보내는 방법은 꽤 간단합니다. 다음은 Active Directory 개체를 ad.csv라는 이름의 파일로 내보내는 방법입니다.
csvde –f ad.csv
–f 스위치는 뒤에 출력 파일의 이름이 온다는 것을 나타냅니다. 하지만 환경에 따라서는 이 기본 구문을 사용했을 때 방대하고 다루기 힘든 출력 파일이 생성될 수 있음을 알아야 합니다. 특정 OU(조직 구성 단위) 내의 개체만 내보내도록 도구를 제한하려면 명령문을 다음과 같이 수정할 수 있습니다.
csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com
이제 사용자 개체를 CSV 파일로 내보내는 경우를 가정해 보겠습니다. 이 경우 검색을 위한 LDAP(Lightweight Directory Access Protocol) 필터를 지정할 수 있는 –r 스위치와, 내보낼 특성 수를 제한하는 –l 스위치를 추가할 수 있습니다. 다음은 모두 한 줄에 입력해야 합니다.
csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
    "(&(objectcategory=person)(objectclass=user))" –l
    DN,objectClass,description
–i 스위치를 사용하면 개체를 원본 CSV 파일에서 Active Directory로 가져올 수 있습니다. 하지만 CSVDE를 통해 사용자 개체를 만드는 데에는 한 가지 중요한 제한이 있습니다. 즉, 해당 개체에 사용자 암호를 설정할 수 없다는 점입니다. 이점 때문에 필자는 사용자 개체를 만들 때는 CSVDE를 사용하지 않습니다.

LDIFDE
Active Directory는 일괄 사용자 작업을 위한 또 하나의 기본 제공 도구인 LDIFDE를 제공하는데 이 도구는 CSVDE보다 강력하고 활용도가 뛰어납니다. LDIFDE를 사용하면 새 개체를 만들 수 있을 뿐만 아니라 기존 개체를 수정 및 삭제하고 Active Directory 스키마를 확장할 수도 있습니다. LDIFDE는 활용도가 높은 대신, LDIF 파일(.ldf)이라고 하는 필수 입력 파일의 형식이 CSV 파일보다 복잡하다는 단점이 있습니다. LDIFDE에서는 약간의 작업을 통해 사용자 암호도 구성할 수 있습니다. 이에 대해서는 뒷부분에서 간단히 살펴보겠습니다.
우선 OU의 사용자를 LDF 파일로 내보내는 간단한 예제부터 시작하겠습니다. 다음은 모두 한 줄에 입력해야 합니다.
ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
       –r "(&(objectcategory=person)(objectclass=user))"
대부분의 명령줄 도구와 마찬가지로 LDIFDE /? 명령을 실행하면 LDIFDE 스위치에 대한 전체 설명을 볼 수 있습니다. 그림 1에서는 이에 대한 예를 보여 줍니다. 실제로 CSVDE와 LDIFDE 명령의 스위치는 동일합니다.
Figure 1 LDIFDE 스위치 (Close Figure 1)

스위치 | 설명
-d | LDIFDE가 작업을 위해 연결해야 하는 LDAP 경로를 지정합니다.
-f | 사용할 파일의 이름, 이 경우 내보내기 결과를 출력할 파일의 이름을 나타냅니다.
-r | 내보내기에 사용할 LDAP 필터를 지정합니다.
-s | 작업을 수행하기 위해 연결할 DC(도메인 컨트롤러)를 지정합니다. 이 스위치를 지정하지 않으면 LDIFDE는 로컬 DC(이 도구를 워크스테이션에서 실행하는 경우 사용자를 인증한 DC)에 연결합니다.
LDIFDE의 진가는 개체 만들기 및 조작에서 드러납니다. 하지만 이 작업을 수행하기 전에 먼저 입력 파일을 만들어야 합니다. 다음 예에서는 afuller 및 rking이라는 두 사용자 계정을 만듭니다. 입력 파일을 만들려면 텍스트를 메모장 또는 기타 원하는 일반 텍스트 편집기에 입력하고 NewUsers.ldf라는 이름으로 저장합니다.
dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking
파일을 만들었으면 다음 명령을 실행합니다.
ldifde –i –f NewUsers.ldf –s DC1.contoso.com
여기서 새로운 스위치는 -i뿐인데, 이것은 내보내기가 아니라 가져오기 작업을 의미함을 추측할 수 있을 것입니다.
기존 개체를 수정하거나 삭제할 경우 LDIFDE 명령의 구문은 바뀌지 않으며 대신 LDF 파일의 내용을 수정합니다. 사용자 계정의 설명 필드를 변경하려면 그림 2와 같은 ModifyUsers.ldf라는 텍스트 파일을 만듭니다.
그림 2 ModifyUsers LDF 파일
그림 2 ModifyUsers LDF 파일
이전 구문과 동일한 LDIFDE 명령 구문을 실행하되 -f 스위치 뒤에 새 LDF 파일 이름을 지정하여 변경 내용을 가져옵니다. 개체를 삭제하기 위한 LDF 형식은 더 간단합니다. 작업 중이던 사용자를 삭제하려면 DeleteUsers.ldf라는 파일을 만들고 다음을 입력합니다.
dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete
CSVDE와는 달리 LDIFDE에서는 사용자 암호를 구성할 수 있습니다. 하지만 사용자 계정의 unicodePWD 특성을 구성하려면 먼저 도메인 컨트롤러에 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 암호화를 구성해야 합니다.
또한 LDIFDE를 사용하면 사용자 계정만이 아니라 모든 유형의 Active Directory 개체를 만들고 수정할 수 있습니다. 예를 들어 다음 LDF 파일은 contoso.com 포리스트의 스키마에 EmployeeID-example이라는 사용자 지정 스키마 확장을 만듭니다.
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example
LDIFDE 파일은 산업 표준 LDAP 파일 형식을 사용하기 때문에 Active Directory 스키마를 수정해야 하는 타사 응용 프로그램에서는 프로덕션 환경에 변경 내용을 적용하기 전에 해당 변경 내용을 검사하고 승인할 때 사용할 수 있는 LDF 파일을 제공하기도 합니다.
일괄 가져오기 및 내보내기 작업을 위한 도구 이외에도 Windows Server 2003에서는 특정 조건에 일치하는 개체에 대해 쿼리를 수행하며 다양한 Active Directory 개체를 만들고, 삭제하고, 수정하는 데 사용할 수 있는 기본 제공 도구 집합도 제공합니다. 이러한 도구(dsadd, dsrm, dsget 및 dsquery)는 Windows 2000 Active Directory에서는 지원되지 않습니다.

Dsadd
Dsadd는 특정 디렉터리 파티션에 Active Directory 개체 클래스의 인스턴스를 만들 때 사용합니다. 이러한 클래스에는 사용자, 컴퓨터, 연락처, 그룹, 조직 구성 단위 및 할당량이 포함됩니다. Dsadd에는 다음으로 구성된 일반 구문이 사용됩니다.
dsadd <ObjectType> <ObjectDistinguishedName> attributes
만들 각 개체 유형에는 해당 유형에 사용할 수 있는 특성에 해당하는 특정한 스위치 집합이 사용됩니다. 다음 명령은 여러 특성이 지정된 하나의 사용자 개체를 만듭니다. 다음은 모두 한 줄에 입력해야 합니다.
dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
–memberOf 스위치에는 사용자를 추가할 각 그룹의 전체 DN(고유 이름)이 필요합니다. 사용자를 여러 그룹에 추가하려면 여러 DN을 공백으로 구분하여 추가할 수 있습니다.
Help Desk 그룹의 DN과 같이 특정 요소에 공백이 포함되어 있을 때는 큰따옴표로 묶어야 합니다. IT\EMEA라는 OU와 같이 요소에 백슬래시가 포함된 경우에는 IT\\EMEA와 같이 백슬래시를 두 번 입력해야 합니다. 이 요구 사항은 모든 ds* 도구에 적용됩니다.
-pwd * 스위치를 사용하면 명령줄에서 사용자 암호를 입력하라는 메시지가 나타납니다. 명령 자체에 암호를 지정할 수 있지만(-pwd P@ssword1), 이렇게 하면 화면 또는 명령을 입력한 모든 텍스트나 스크립트 파일에서 암호가 일반 텍스트로 표시됩니다.
마찬가지로 다음 두 명령을 사용하여 그룹 개체와 OU를 만들 수 있습니다.
dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod
Dsmod는 기존 개체를 수정할 때 사용하며 dsadd와 사용 방법은 거의 비슷하고 수정하는 개체의 유형에 따라 다른 하위 메뉴와 구문을 사용합니다. 다음 dsmod 문은 사용자의 암호를 변경하고 다음 로그온 시 새 암호로 변경하라는 메시지가 표시되도록 해당 계정을 수정합니다.
dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
스위치가 얼마나 비슷한지 확인할 수 있도록 동일한 특성이 구성된 이 사용자를 만들기 위해 사용하는 dsadd 구문을 살펴보겠습니다.
dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
여기서 볼 수 있듯이 dsadd에서 개체를 만들기 위한 스위치를 알고 있으면 해당 스위치와 동일한 스위치를 dsmod에서 사용하여 사용자를 수정할 수 있습니다.

Dsrm
dsadd의 반대 기능을 하는 것이 dsrm입니다. 이 도구를 사용하면 명령줄에서 개체를 삭제할 수 있습니다. dsrm의 기본 구문은 매우 간단합니다. 다음과 같이 dsrm을 입력하고 삭제할 개체의 고유 이름을 그 뒤에 입력하면 됩니다.
dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com
기본적으로 dsrm에서 "이 개체를 삭제하시겠습니까?"라는 메시지를 표시합니다. 이때는 Y를 입력한 다음 Enter 키를 누르면 됩니다. –noprompt 스위치를 사용하면 이 메시지가 표시되지 않도록 할 수 있지만 이렇게 하면 삭제하기 전에 올바른 개체를 선택했는지를 확인할 기회가 없습니다. 컨테이너 개체, 즉 다른 개체가 포함되어 있을 수 있는 조직 구성 단위를 삭제할 때는 두 개의 추가적인 스위치가 도움이 될 수 있습니다. 다음 명령은 TrainingOU 조직 구성 단위와 여기 포함된 모든 개체를 삭제합니다.
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
이 명령은 TrainingOU 안에 포함된 모든 자식 개체를 삭제하고 조직 구성 단위 개체 자체는 남겨 둡니다.
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
    –exclude

Dsmove
Active Directory에서 개체를 이동하거나 이름을 바꾸려면 dsmove 도구를 사용합니다. 단, 하나의 도메인 내에서 개체를 이동할 때만 사용해야 합니다. 도메인 또는 포리스트 사이에서 개체를 마이그레이션하려면 Microsoft 웹 사이트에서 무료로 다운로드할 수 있는 ADMT(Active Directory 마이그레이션 도구)를 사용하십시오. Dsmove는 개별적으로 또는 함께 사용할 수 있는 두 개의 스위치를 제공합니다. 이 명령은 Steve Conn의 계정에 새로운 성을 지정합니다.
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
    –newname "Steve Conn"
이 명령은 Steve의 계정을 IT OU에서 Training OU로 이동합니다.
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
    ou=Training,dc=contoso,dc=com
다음과 같이 두 스위치를 함께 지정하여 이름 바꾸기와 이동을 하나의 작업으로 결합할 수 있습니다.
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
    "Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget 및 Dsquery
ds* 명령줄 도구 집합에는 개체를 만들거나 수정하는 것이 아니라 Active Directory에서 정보를 쿼리하는 데 사용하는 두 개의 도구도 포함되어 있습니다.
Dsget 도구는 개체의 DN을 입력으로 사용하여 사용자가 지정한 특성의 값을 제공합니다. Dsget 도구는 dsadd 및 dsmod와 동일한 하위 메뉴(사용자, 컴퓨터, 연락처, 그룹, ou 및 할당량)를 사용합니다.
사용자 계정의 SAM 계정 이름 및 SID(보안 식별자)를 가져오려면 다음 명령을 입력합니다. 다음을 모두 한 줄에 입력해야 합니다.
dsget user cn=afuller,ou=IT,dc=contoso,dc=com
    –samAccountName –sid
그림 3과 같은 출력이 표시됩니다.
그림 3 dsget 실행
그림 3 dsget 실행
Dsquery는 사용자가 지정한 조건에 맞는 Active Directory 개체의 목록을 반환합니다. 사용하는 하위 메뉴에 관계없이 다음 매개 변수를 지정할 수 있습니다.
dsquery <ObjectType> <StartNode> -s <Search Scope> -o <OutputFormat>
ObjectType의 경우 dsquery는 각각 자체 구문이 있는 하위 메뉴인 컴퓨터, 연락처, 서브넷, 그룹, ou, 사이트, 서버(서버 하위 메뉴는 환경의 구성원 서버가 아니라 도메인 컨트롤러에 대한 정보를 검색함), 사용자, 할당량 및 파티션을 사용할 수 있습니다. 이러한 쿼리 유형 중 하나가 적합하지 않은 경우에는 * 하위 메뉴를 사용하여 자유 형식 LDAP 쿼리를 입력할 수 있습니다.
StartNode는 Active Directory 트리에서 검색을 시작할 위치를 지정합니다. ou=IT,dc=contoso,dc=com과 같은 특정 DN을 사용하거나, 특정 도메인의 루트에서 시작되는 domainroot 또는 검색 수행을 위해 글로벌 카탈로그 서버를 사용하여 포리스트 루트 도메인의 루트에서 시작되는 forestroot와 같은 바로 가기 지정자 중 하나를 사용할 수 있습니다.
마지막으로, Search Scope 옵션은 dsquery가 Active Directory 트리를 검색할 방법을 지정합니다. 기본값인 subtree는 지정된 StartNode 및 모든 자식 개체를 쿼리하고, onelevel은 StartNode의 직접적인 자식만 쿼리하고, base는 StartNode 개체만 쿼리합니다.
검색 범위에 대한 이해도를 높이기 위해 사용자 개체 및 자체적으로 추가 개체를 포함하는 자식 OU가 모두 포함된 OU에 대해 살펴보겠습니다. subtree 범위를 사용하면 OU, OU에 포함된 모든 사용자 개체, 자식 OU 및 자식 OU의 내용을 쿼리합니다. onelevel 범위는 OU 안에 포함된 사용자만 쿼리하며 자식 OU나 자식 OU의 내용은 쿼리하지 않습니다. base 쿼리는 OU에 포함된 개체는 쿼리하지 않고 OU 자체만 검색합니다.
마지막으로, OutputFormat을 사용하여 dsquery 결과의 형식을 지정하는 방법을 제어할 수 있습니다. 기본적으로 dsquery는 다음과 같이 쿼리에 일치하는 개체의 고유 이름을 반환합니다.
"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com"
IT OU와 모든 자식 OU에 포함된 모든 사용자 개체를 쿼리하려면 다음을 사용합니다.
dsquery user ou=IT,dc=contoso,dc=com
사용하지 않도록 설정된 사용자 계정만 반환하는 -disabled, 지난 x주 이상 로그온하지 않은 사용자만 반환하는 -inactive x 또는 x일 이상 암호를 변경하지 않은 사용자만 반환하는 -stalepwd x와 같은 스위치를 추가하여 이 쿼리를 더 상세하게 조정할 수 있습니다.
디렉터리에 있는 개체의 수에 따라 쿼리를 실행할 때 -limit x 스위치를 지정해야 할 수 있습니다. 기본적으로 dsquery는 쿼리의 구체적 요구 사항에 일치하는 개체를 100개까지 반환합니다. -limit 500과 같이 더 큰 수를 지정하거나 -limit 0을 사용하여 dsquery가 일치하는 모든 개체를 반환하도록 지정할 수 있습니다.
다른 하위 메뉴를 사용하여 다른 개체 유형에 대해서도 유용한 쿼리를 수행할 수 있습니다. 10.1.x.x 주소 공간에 있는 Active Directory 사이트 및 서비스에 정의된 모든 서브넷을 반환하는 다음 쿼리를 살펴보겠습니다.
dsquery subnet –name 10.1.*
또는 다음을 사용하여 Corp 사이트에 위치한 모든 서브넷을 반환합니다.
dsquery subnet –site Corp
또 다른 하위 메뉴를 사용하면 포리스트에서 글로벌 카탈로그 서버로 구성된 도메인 컨트롤러의 수를 빠르게 확인할 수 있습니다.
dsquery server –forest –isgc
또한 이 구문을 사용하면 도메인에서 PDC(주 도메인 컨트롤러) 에뮬레이터 FSMO(신축 단일 마스터 작업) 역할을 호스팅하는 도메인 컨트롤러를 확인하는 데에도 도움이 됩니다.
dsquery server –hasfsmo pdc
하위 메뉴가 포함된 다른 ds* 명령과 마찬가지로 명령 프롬프트로 이동하여 dsquery user /?, dsquery computer /?, dsquery subnet /? 등을 입력하면 특정 dsquery 하위 메뉴 안에서 사용할 수 있는 모든 스위치를 볼 수 있습니다.
| 문자를 사용하여(미국 키보드에서 Shift+백슬래시) dsmod와 같은 다른 도구로 dsquery 출력을 파이프하는 다른 몇 가지 유용한 팁도 있습니다. 예를 들어 회사에서 Training 부서의 이름을 Internal Development로 변경했으며 이제 각 관련 사용자의 설명 필드를 이전 부서 이름에서 새 부서 이름으로 업데이트해야 하는 경우를 가정해 보겠습니다. 단일 명령줄에서 다음과 같이 설명 필드가 Training인 사용자 개체를 쿼리한 다음 해당 설명 필드를 일괄적으로 수정합니다.
dsquery user –description "Training" | dsmod
    -description "Internal Development"

몇 가지 유용한 타사 도구
Active Directory는 LDAP 표준을 기반으로 하기 때문에 LDAP를 지원하는 모든 도구를 사용하여 Active Directory를 쿼리하고 수정할 수 있습니다. 많은 수의 타사 공급 업체에서 Active Directory 관리에 도움이 되는 유료 도구를 제공하고 있습니다. 하지만 무료로 제공되는 유용한 도구도 찾을 수 있습니다. 디렉터리 서비스 MVP인 Joe Richards가 만든 컬렉션(joeware.net/freetools에서 다운로드 가능)이 그 예입니다. 이 사이트에서는 여러 기능을 제공하는 많은 도구를 찾을 수 있습니다. 그 중에서 필자가 자주 사용하는 도구는 adfind, admod 및 oldcmp입니다.

Adfind와 Admod
Adfind와 admod는 dsquery 및 dsmod와 비슷합니다. adfind는 Active Directory용 명령줄 쿼리 도구이며 admod는 하나 이상의 Active Directory 개체를 만들고, 삭제 또는 수정할 수 있습니다.
개체 유형에 따라 여러 하위 메뉴와 여러 스위치가 있는 ds* 도구와는 달리 adfind 및 admod에는 수행할 수정 또는 쿼리 작업의 유형에 관계없이 일관된 구문이 사용됩니다. adfind의 기본 구문은 다음과 같습니다.
adfind –b <Search Base> -s <Search Scope> -f <Search Filter>
    attributesDesired
따라서 도메인 내의 모든 컴퓨터 개체의 DN과 설명을 쿼리하려면 다음과 같이 합니다.
adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
    description
모든 사용자 개체에 대한 쿼리는 다음과 비슷합니다.
adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
    (objectclass=user))" dn description
LDAP 쿼리의 내용을 제외하고 구문은 변경되지 않은 것을 알 수 있습니다.
adfind를 사용하다 보면 입력을 줄일 수 있는 여러 바로 가기 연산자를 발견하게 됩니다. 예를 들어 -default 스위치를 통해 앞서 살펴본 예의 -b dc=contoso,dc=com을 대체하여 전체 도메인을 검색할 수 있습니다. -gc는 GC(가비지 수집)에 대해 검색을 수행하여 Active Directory 포리스트의 모든 사용자를 반환합니다. 또한 -rb 스위치를 사용하여 검색의 상대적 기준을 설정할 수 있습니다. phl.east.us.contoso.com 도메인에서 Training OU를 검색하려는 경우 –b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com 대신 –default –rb ou=Training을 지정하여 시간을 절약할 수 있습니다.
또한 adfind는 그림 4에 표시된 기능을 포함하여 명령줄에서 관리하기 쉽지 않은 다양한 고급 검색 기능을 수행할 수 있습니다.
Figure 4 Adfind 스위치 (Close Figure 4)

스위치 | 설명
-showdel | Deleted Objects 컨테이너에서 삭제 표시 개체를 쿼리합니다.
-bit | userAccountControl 특성과 같은 비트 연산자를 쿼리합니다.
-asq | 특성 범위가 지정된 쿼리를 수행합니다. 이 기능(dsquery에서 복제할 수 없음)은 특정 개체의 특성을 검색한 다음 이에 대해 쿼리를 수행합니다.
-dsq | adfind 쿼리의 출력을 dsmod 또는 다른 ds* 도구 중 하나로 파이프합니다.
예를 들어 –asq 스위치를 사용하여 다음과 같이 "HelpDesk 구성원의 그룹 등록을 표시"할 수 있습니다.
adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf
admod는 이름에서 알 수 있듯이 Active Directory 내에서 개체를 수정하는 데 사용합니다. adfind와 마찬가지로 기억할 특별한 구문을 사용하는 하위 메뉴는 없습니다. admod는 작업 중인 개체의 유형에 관계없이 동일한 구문을 사용합니다. admod를 사용하면 -add, -rm, -move, -undel과 같은 적절한 스위치를 추가하는 것만으로 개체를 추가, 이동, 이름 바꾸기, 삭제 및 삭제 취소할 수 있습니다. 또한 dsquery 및 dsmod와 마찬가지로 | 문자를 사용하여 adfind 쿼리의 결과를 admod로 파이프할 수도 있습니다.
admod를 사용하여 삭제 취소를 수행하면 개체 특성의 대부분이 제거된 삭제 표시 다시 애니메이션 작업만 수행됩니다. 개체와 해당 개체의 모든 특성을 완전히 복원하려면 개체에 대한 정식 복원을 수행해야 합니다.

Oldcmp
자동화 도구 키트에서 빼놓을 수 없는 도구가 oldcmp입니다. 이 도구는 Active Directory 데이터베이스에서 지정된 시간(단위: 주) 동안 사용되지 않은 컴퓨터 계정을 검색하고 다음을 수행할 수 있습니다.
  • 해당 계정에 특정 작업을 수행하지 않고 계정의 보고서 생성
  • 사용되지 않는 컴퓨터 계정 사용 중지
  • 컴퓨터 계정을 지정한 다른 OU로 이동
  • 컴퓨터 계정 완전히 삭제
oldcmp는 디렉터리에 심각한 영향을 줄 가능성이 있기 때문에 여러 가지 보안 기능을 기본으로 제공합니다. 사용하지 않도록 설정되지 않았으며 삭제를 확인하는 명령줄 스위치를 수동으로 지정하지 않은 계정은 삭제하지 않습니다. 이와 비슷한 확인 스위치가 없으면 한 번에 10개 이상의 개체를 수정하지 않으며 도메인 컨트롤러의 컴퓨터 계정에 대해서는 어떠한 작업도 하지 않습니다.
이 도구의 이름 자체로 인해 오해할 수도 있겠지만 Joe는 특정 시간 동안 사용되지 않은 사용자 계정에 대해 비슷한 기능을 수행하도록 oldcmp를 업데이트했습니다.
소규모 Active Directory 환경이거나 한 번에 하나 또는 두 가지 추가 또는 변경 작업을 하는 환경이라면 Active Directory 사용자 및 컴퓨터와 같은 GUI 도구로도 일상적인 관리 작업을 충분히 수행할 수 있습니다. 하지만 매일 많은 수의 개체를 추가 및 수정하거나 더 효율적인 관리 작업용 솔루션이 필요한 경우 명령줄을 사용하면 Active Directory 내에서 개체를 만들고, 수정하고, 삭제하는 프로세스의 속도를 크게 높일 수 있습니다. 지금까지 살펴봤듯이 Windows에서 기본 제공되거나 Active Directory 커뮤니티에서 다운로드할 수 있는 강력하고 활용도가 뛰어난 무료 도구들이 많이 있습니다. 이러한 도구는 모두 Active Directory 관리자의 생산성을 크게 향상시키며 일상 작업에 필수적인 도구로 자리잡고 있습니다.

Laura E. Hunter는 Windows Server 네트워킹 분야에서 Microsoft MVP를 네 차례 수상했으며 Active Directory Cookbook, Second Edition(O'Reilly, 2006)의 저자입니다. IT 분야에서 10년 동안 일해 온 전문가인 Laura는 현재 세계적 엔지니어링 회사에서 Active Directory 설계자로 근무하고 있습니다. 또한 다양한 산업 분야의 자격증을 소지하고 있으며 사용자 그룹 모임이나 업계 회의에 자주 초청을 받는 강연자이기도 합니다.


 Windows Server: Active Directory 삭제 표시 개체 다시 애니메이션
Windows Server Gil Kirkpatrick

Active Directory 삭제 표시 개체 다시 애니메이션
한 눈에 보기:
  • 삭제된 개체가 Active Directory에 저장되는 방식
  • LDP 및 ADRESTORE를 사용하여 삭제 표시 찾기 및 복원
  • 개체 특성 및 systemFlags

생각하고 싶지 않은 주제겠지만 실수로 인한 데이터 손실은 언제라도 발생할 수 있으므로 IT 전문가는 모든 종류의 복구 시나리오에 대비해야 합니다. TechNet Magazine 2007년 4월호에서 필자는
Active Directory® 사용자 및 그룹 복구 계획 수립의 중요성을 설명했습니다. technetmagazine.com/issues/2007/04/ADRecovery에서 볼 수 있는 이 기사에서는 개체 연결, 복제, 삭제 및 정식 복원의 메커니즘을 다루었습니다. 하지만 정식 복원 기능을 사용하려면 DC(도메인 컨트롤러)를 DSRM(디렉터리 서비스 복원 모드)에서 시작해야 합니다. 이렇게 하면 복원 작업 동안에는 DC를 사용할 수 없습니다.
이 외에 알아두어야 할 다른 방법이 있습니다. 삭제 표시 다시 애니메이션은 DC를 오프라인으로 전환하지 않고 삭제된 개체를 복구할 수 있는 유일한 방법이며, 삭제된 개체의 objectGUID 및 objectSid 특성과 같은 식별 정보를 복구할 수 있는 유일한 방법입니다. 또한 삭제된 사용자 및 그룹을 다시 만들고 삭제된 개체의 objectSid가 포함된 이전 ACL(액세스 제어 목록) 참조를 모두 수정해야 하는 문제를 깔끔하게 해결합니다. 다만 삭제 표시 다시 애니메이션에는 자체적인 제한이 있으므로 정식 복원도 계속 사용해야 할 수 있다는 점만 기억해 두십시오. 삭제 표시 다시 애니메이션만의 제한 사항은 이후에 설명합니다.
삭제 표시 다시 애니메이션은 특정 데이터 복구 시나리오를 단순화하기 위해 Windows Server® 2003 Active Directory에 도입되었습니다. 이 기능은 Active Directory가 삭제된 개체를 물리적으로 제거하기 전에 일정 시간 동안 데이터베이스에 보관한다는 점을 이용합니다. 이 기사에서는 Active Directory가 개체를 삭제하고 다시 애니메이션하는 방법을 자세히 설명하고 표준 Microsoft 도구를 사용하여 삭제된 개체를 복구하는 방법을 설명합니다.

삭제 표시란?
Active Directory가 디렉터리에서 개체를 삭제할 때 이 개체는 데이터베이스에서 물리적으로 제거되는 것이 아닙니다. 대신 Active Directory는 개체의 isDeleted 특성을 TRUE로 설정하고, 개체에서 대부분의 특성을 제거하고, 개체 이름을 변경한 다음 개체의 NC(명명 컨텍스트)에 있는 특수 컨테이너(CN=Deleted Objects)로 개체를 이동하여 개체를 삭제된 것으로 표시합니다. 이렇게 삭제된 개체를 삭제 표시라고 하며 이 개체는 일반 디렉터리 작업에 표시되지 않습니다. 삭제 표시 개체는 또한 어떠한 MMC(Microsoft® Management Console) 스냅인에도 표시되지 않으며 대부분의 LDAP(Lightweight Directory Access Protocol) 유틸리티에서도 그 존재를 인식하지 못합니다. 즉, 의도와 용도에 관계없이 모든 경우에 삭제 표시가 표시되지 않습니다. 하지만 이러한 데이터는 보이지 않을 뿐 여전히 존재합니다. 그렇다면 Active Directory는 왜 삭제 표시 또는 삭제된 개체를 데이터베이스에 보관하는 것일까요?
삭제 표시는 다른 프로세스에서는 표시되지 않지만 Active Directory 복제 프로세스에서는 표시됩니다. 삭제할 개체를 호스트하는 모든 DC에서 삭제가 수행되도록 하기 위해 Active Directory는 삭제 표시를 다른 DC로 복제합니다. 따라서 삭제 표시는 Active Directory 환경 전체에서 삭제를 복제하는 데 사용됩니다.

삭제 표시의 수명
Active Directory는 일반적으로 LDAP 삭제 프로토콜 작업 또는 SAM(Security Accounts Manager) 삭제 작업에 대한 응답으로 디렉터리에서 개체를 삭제합니다. 이 작업을 원래 삭제라고 하며 이 삭제 작업은 Active Directory 복제 프로세스가 수행하는 삭제 작업과 구분됩니다. 여기에서는 삭제 메커니즘이 다르며 TTL(Time-To-Live)이 만료될 때 Active Directory에 의해 직접 삭제되는 동적 개체는 다루지 않습니다.
Active Directory는 삭제 작업을 수신하면 먼저 검사 목록을 통해 개체 삭제가 허용되는지 여부를 확인합니다. 이 프로세스는 놀랍게도 다음 조건이 모두 true인지 확인합니다.
  • 개체의 isDeleted 특성이 아직 TRUE로 설정되어 있지 않습니다. (이미 삭제된 개체는 삭제할 수 없습니다.)
  • "개인 개체" 리소스 특정 보안 설명자 제어 플래그가 개체의 보안 설명자에 설정되어 있지 않습니다. (이는 문서화되지 않은 "기능"으로 나타납니다. 개인 개체 플래그는 보안 설명자 구조의 Sbz1 바이트의 비트 1입니다.)
  • "삭제 허용 안 함" 비트(0x80000000)가 개체의 systemFlags 특성에 설정되어 있지 않습니다.
  • 개체의 isCriticalSystemObject 특성이 TRUE로 설정되어 있지 않습니다.
  • 개체의 보안 설명자가 개체를 삭제할 사용자에게 적절한 액세스 권한을 부여합니다. (좀 더 구체적으로 말하면 사용자가 개체 자체뿐만 아니라 부모 개체에서 자식 개체를 삭제할 수 있도록 허용됩니다.)
  • 개체가 기존 명명 컨텍스트에 대한 상호 참조 개체(objectClass = crossRef)가 아닙니다.
  • 개체에 하위 개체가 없습니다. (LDAP 삭제 작업에 LDAP "트리 삭제" 제어 개체 ID가 포함된 경우 Active Directory는 isCriticalSystemObject 특성이 TRUE로 설정된 개체 이외에는 하위 개체도 자동으로 삭제합니다. 이를 통해 트리 삭제 작업에서 중요한 시스템 개체가 실수로 삭제되는 것을 방지할 수 있습니다. 물론 이들 개체는 개별적으로 삭제할 수 있습니다.)
  • 개체가 중요한 내부 개체가 아닙니다. (예를 들어 DC의 nTDSDSA 개체 또는 NC 헤드 상위 개체에 대한 자리 표시자 개체가 아닙니다.)
이러한 조건이 true이어야 하지만 Active Directory도 삭제 작업을 처리할 적절한 상태에 있어야 합니다. 예를 들어 Active Directory가 도메인 이름 변경 프로세스를 수행 중일 때는 도메인 트러스트 계정 또는 crossRef 개체를 삭제하지 않습니다.
개체를 삭제할 수 있는 것으로 판별되면 Active Directory는 개체를 삭제 표시로 전환합니다. Active Directory는 먼저 개체에서 그림 1에 명시되어 있는 특성과 삭제 표시에 유지되도록 스키마에 정의된 특성은 남겨두고 불필요한 특성을 제거합니다자세한 내용은 "개체 특성 복구" 단원을 참조하십시오. 그런 다음 개체의 RDN(상대 고유 이름)을 CN=<old RDN>\0ADEL:<objectGUID>로 변경합니다. 여기서 \0A는 ASCII 줄 바꿈 문자이고 <objectGUID>는 문자열로 표현된 objectGUID입니다. 그런 후 lastKnownParent 특성을 개체의 부모 컨테이너의 DN(고유 이름)으로 설정하고 isDeleted 특성을 TRUE로 설정합니다. 이 작업을 마친 다음 Active Directory는 개체에서 모든 정방향 및 역방향 연결 특성을 제거합니다. 마지막으로 개체의 systemFlag 특성에 "삭제 시 이동 허용 안 함" 비트가 설정되지 않은 경우 Active Directory는 개체를 NC에 대한 CN=Deleted Objects 컨테이너로 이동합니다. 이 항목에 대한 자세한 내용은 "systemFlags 특성 및 개체 동작" 추가 기사를 참조하십시오.
Figure 1 삭제 표시에 저장된 특성 (Close Figure 1)

저장하도록 하드 코드된 특성
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
searchFlags 설정으로 인해 저장되는 특성
msDS-AdditionalSam-AccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid
CN=Deleted Objects 폴더에는 개체 계층 구조가 없음을 알아두어야 합니다. 이로 인해 CN이 같은 두 개의 다른 개체를 삭제한 경우 이름 충돌이 발생한다고 생각할 수 있습니다. 하지만 실제로는 그렇지 않습니다. objectGUID는 각 삭제 표시의 RDN에 통합되기 때문에 각 삭제 표시의 RDN은 CN=Deleted Objects 컨테이너 내에서 고유합니다.
즉, 개체가 CN=Deleted Objects 컨테이너에 영구적으로 남아 있지 않습니다. 삭제 표시의 기본 수명은 Windows® 2000 및 Windows Server 2003을 사용하여 처음 구축된 포리스트의 경우 60일이고, Windows Server 2003 SP1을 사용하여 처음 구축된 포리스트의 경우에는 180일입니다. 삭제 표시의 수명은 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 개체의 tombstoneLifetime 특성을 설정하여 변경할 수 있습니다.
각 도메인 컨트롤러는 12시간마다 가비지 수집 프로세스를 시작합니다. 가비지 수집 간격은 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 개체의 garbageCollPeriod 특성에 새 값을 설정하여 변경할 수 있습니다. 이 가비지 수집은 DC에서 모든 삭제 표시를 검색하여 삭제 표시 수명보다 오래된 모든 삭제 표시를 물리적으로 삭제합니다.

LDP를 사용하여 삭제 표시 찾기
LDP는 Active Directory를 사용하기 위한 Windows 탐색기와 비슷한 유형의 유틸리티입니다. LDP는 원래 Active Directory 개발 팀에서 Active Directory를 개발할 때 LDAP 코드를 테스트하기 위해 설계했습니다. 이제 Windows Server 2003 지원 도구의 일부로 제공되는 LDP는 Active Directory를 작업하는 데 필요한 강력한 도구로 발전했습니다.
삭제 표시는 일반 디렉터리 작업에서는 표시되지 않지만 LDAP 검색 작업 및 컨트롤이라고 하는 특별한 LDAP 확장을 사용하면 Active Directory에서 삭제 표시 개체를 찾을 수 있습니다. 컨트롤은 LDAP 표준에 정의된 메커니즘으로 다른 LDAP 호환 소프트웨어와의 호환성을 유지하면서 LDAP 표준 정의를 넘어서는 추가 기능을 제공하기 위해 LDAP 프로토콜을 확장하는 데 사용됩니다. Active Directory는 Return Deleted Objects 컨트롤을 포함하여 22개의 컨트롤을 지원합니다. 이 컨트롤을 사용하여 LDAP 검색 작업을 확장하면 컨트롤이 다른 경우에는 표시되지 않는 삭제된 개체를 검색합니다.
이 컨트롤의 작동 방식을 설명하기 위해 필자는 Enterprise Administrator 자격 증명으로 foo.local 도메인에 로그인한 다음 ADUC(Active Directory 사용자 및 컴퓨터) MMC 스냅인을 사용하여 사용자 개체(CN=John Smith,CN=Users,DC=foo,DC=local)를 만들었습니다. 이는 그림 2에서 확인할 수 있습니다. 그런 다음 다시 ADUC를 사용하여 사용자 개체를 삭제합니다.
그림 2 ADUC를 사용하여 사용자 만들기
그림 2 ADUC를 사용하여 사용자 만들기
이제 LDP 프로그램을 실행하고 이를 사용하여 삭제된 사용자에 대한 삭제 표시를 표시할 수 있습니다. 첫 번째 단계로 LDP를 특정 DC에 연결하고 적절한 자격 증명을 사용하여 인증합니다. Connection(연결) 메뉴의 Connect(연결) 옵션을 선택하여 DC에 간단하게 연결합니다. LDP를 DC에서 실행하고 있으므로 OK(확인)를 눌러 로컬 DC에 연결합니다. LDP를 원격으로 실행할 때는 연결할 DC의 이름을 지정해야 합니다. 연결에 성공하면 LDP에서 rootDSE의 특성을 표시합니다. 여기에서는 DC 자체의 상태와 구성을 설명하는 특성을 볼 수 있습니다(그림 3 참조).
그림 3 DC에 연결된 LDP
그림 3 DC에 연결된 LDP
이제 도메인 또는 엔터프라이즈 관리자 자격 증명을 사용하여 DC에 인증하기 위해 Connection(연결) 메뉴에서 Bind(바인딩)를 선택합니다. 이미 포리스트의 Enterprise Administrator로 로그인했기 때문에(Domain Administrators 및 Enterprise Administrators에는 기본적으로 CN=Deleted Objects 컨테이너의 개체를 나열하고 다시 애니메이션할 권한이 있음) Bind(바인딩) 대화 상자의 Username(사용자 이름)과 Password(암호)를 비워두고 OK(확인)를 누릅니다. 그렇지 않은 경우에는 Bind(바인딩) 대화 상자에 적절한 자격 증명을 입력합니다.
다음으로 CN=Deleted Objects,DC=foo,DC=local 컨테이너의 내용을 나열하고자 합니다. 컨테이너 자체가 삭제된 것으로 표시되었기 때문에 일반적으로는 CN=Deleted Objects 컨테이너를 볼 수 없습니다. CN=Deleted Objects 컨테이너를 검색할 수 있는 유일한 방법은 Return Deleted Objects LDAP 컨트롤을 사용하는 것입니다.
LDP에 이 컨트롤을 사용하려면 Browse(찾아보기) 메뉴로 이동하여 Search(검색)를 선택합니다. 그림 4와 같은 Search(검색) 대화 상자가 나타납니다. Base Dn(기본 Dn) 필드에서는 디렉터리 트리에서 검색을 시작할 위치를 지정할 수 있습니다. 도메인에 대한 Deleted Objects 컨테이너의 DN을 입력합니다. 이 예제에서 DN은 CN=Deleted Objects,DC=foo,DC=local입니다.
그림 4 LDP Search(검색) 대화 상자
그림 4 LDP Search(검색) 대화 상자
Filter(필터) 필드에는 LDP가 사용할 검색 조건을 지정합니다. 기본값은 (objectClass=*)로, 이 경우 objectClass 특성 값이 있는 모든 개체가 반환됩니다. Active Directory에서 삭제된 개체도 objectClass 값은 갖고 있기 때문에 기본 필터에서는 검색 범위 내의 모든 개체가 반환됩니다. 이 예제에서는 필터를 (objectClass=user)로 변경하여 사용자 개체만 검색되도록 제한합니다. 이렇게 하면 CN=Deleted Objects 컨테이너에 있는 어쩌면 수천 개에 달할 수 있는 삭제 표시 중에서 삭제된 John Smith 사용자를 더 쉽게 찾을 수 있습니다.
CN=Deleted Objects 컨테이너에는 한 번의 검색 작업으로 Active Directory가 반환하는 것보다 많은 개체가 있음을 볼 수 있습니다. 일반적으로 이 문제를 해결하기 위해 결과를 한 번에 하나의 그룹으로 반환하는 페이지 형식의 LDAP 검색을 사용합니다. 하지만 LDP에서는 페이지 형식의 검색과 확장 검색을 모두 지정할 수 없습니다. 따라서 원하는 개체를 찾기 위해서는 LDAP 필터를 세밀하게 조정해야 합니다.
Scope(범위)의 라디오 단추를 사용하여 검색할 디렉터리 트리의 범위를 지정할 수 있습니다. Base(기본) 검색에서는 Base Dn(기준 Dn) 필드에 지정된 개체만 반환됩니다. One Level(한 수준) 검색에서는 Base Dn(기준 Dn) 개체 바로 아래에 있는 개체가 반환됩니다. Subtree(하위 트리) 검색에서는 Base Dn(기준 Dn) 개체의 모든 하위 개체가 반환됩니다. CN=Deleted Objects 폴더는 단일 구조이기 때문에 모든 삭제 표시를 검색하기 위해 One Level(한 수준) 검색을 사용합니다.
지금까지 일반적인 LDAP 검색을 개괄적으로 설명했습니다. 지금 LDP를 실행하면 CN=Deleted Objects,DC=foo,DC=com이 삭제된 것으로 표시되어 있기 때문에 존재하지 않는다는 오류를 표시합니다. 따라서 검색 작업에 Return Deleted Objects LDAP 컨트롤을 포함해야 합니다. 이렇게 하려면 Search(검색) 대화 상자에서 Options(옵션) 단추를 클릭하고 그림 5에서와 같이 Search Call Type(검색 호출 형식)에 Extended(확장)를 선택합니다. 이 옵션을 사용하면 검색 작업에 대한 컨트롤을 지정할 수 있습니다. 여기에서는 Attributes(특성) 목록도 *로 변경합니다. 이렇게 하면 LDP가 LDP의 기본 특성 집합 대신 검색하는 각 개체에 대한 일반 특성을 모두 표시합니다.
그림 5 LDP Search Options(검색 옵션) 대화 상자
그림 5 LDP Search Options(검색 옵션) 대화 상자
이제 Controls(컨트롤) 단추를 누르면 Controls(컨트롤) 대화 상자가 표시됩니다. LDP의 Controls(컨트롤) 대화 상자는 다소 불편하기 때문에 다음 단계를 신중하게 수행하여 Return Deleted Objects 컨트롤을 추가하십시오.
Load Predefined(로드할 미리 정의된 컨트롤) 드롭다운 목록에서 Return deleted objects를 선택하고 Check in(체크 인) 단추를 누릅니다. 그러면 그림 6에서와 같이 Return Deleted Objects 컨트롤에 대한 OID(개체 식별자) 1.2.840.113556.1.4.417이 Active Controls(활성 컨트롤) 목록에 추가됩니다. 이제 LDP에서 이 컨트롤을 이후의 모든 확장 검색 작업에 추가합니다. OK(확인)를 눌러 컨트롤 설정을 저장하고 다시 OK(확인)를 눌러 Search Options(검색 옵션) 대화 상자를 닫습니다.
그림 6 Return Deleted Objects 컨트롤 추가
그림 6 Return Deleted Objects 컨트롤 추가
Controls(컨트롤) 대화 상자에는 몇 가지 독특한 동작이 있습니다. 자세히 설명하자면 OID가 Active Controls(활성 컨트롤) 목록에 표시되어 있다고 해서 컨트롤이 실제로 적용되는 것은 아닙니다. 경우에 따라서는 컨트롤이 다음 LDAP 작업에 사용되도록 컨트롤을 체크 아웃한 다음 다시 체크 인해야 합니다.
이제 검색을 실행할 준비가 되었습니다. LDP Search(검색) 대화 상자에서 OK(확인) 단추를 누르면 LDP가 도메인의 CN=Deleted Objects 컨테이너에서 모든 사용자 개체를 검색합니다. 그림 7에서 결과를 볼 수 있습니다.
그림 7 CN=Deleted Objects 컨테이너에서 검색한 결과
그림 7 CN=Deleted Objects 컨테이너에서 검색한 결과

LDP 결과 검토
여기에서 설명한 검색을 수행한 결과 두 개의 삭제 표시 개체가 반환되었습니다. 먼저 첫 번째 삭제 표시의 DN인 CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local을 볼 수 있습니다. 삭제된 개체의 objectGUID는 문자열(41800281-6bc4-42c3-a99b-b283022b3af8)로 표현됩니다. DN 아래에는 objectClass, cn, distinguishedName 등에 대한 값이 표시되는 특성 목록이 표시됩니다. isDeleted 특성의 값이 TRUE이므로 개체가 실제로 삭제되었음을 알 수 있습니다. 또한 objectSid가 삭제 표시에서 유지되는 것도 볼 수 있습니다. 이후에 설명하겠지만 이것은 사용자 및 그룹 삭제 표시를 복구하는 데 있어 중요한 항목입니다. 삭제 표시가 되기 전에 개체에 포함되어 있던 개체의 DN을 나타내는 lastKnownParent 특성도 삭제 표시 복구에 있어 매우 중요한 항목입니다.
이 샘플에서 LDP는 두 개의 삭제 표시 개체를 표시하며 이 두 개는 모두 원래 CN=Users,dc=foo,dc=local 컨테이너에 있던 CN=John Smith라는 이름의 사용자 개체였습니다. 어떻게 RDN이 같은 두 개의 서로 다른 개체가 같은 컨테이너에서 올 수 있을까요? 그 이유는 간단하게 설명할 수 있습니다. LDP를 실행하여 삭제 표시를 검색하기 전에 필자는 CN=John Smith 사용자 개체를 CN=Users,DC=foo,DC=local 컨테이너에 만들고 이를 삭제했습니다. 그런 다음 모든 특성이 동일한 다른 사용자 개체를 만든 다음 이 개체도 삭제했습니다. 첫 번째 CN=John Smith 사용자 개체를 이미 삭제했기 때문에 이름이 같더라도 두 번째 개체를 만들 수 있었습니다. 하지만 이들은 objectGUID로 구분되는 별도의 고유한 개체입니다. Active Directory는 objectGUID를 삭제 표시의 DN에 통합하기 때문에 CN=Deleted Objects 컨테이너에서 별도의 개체로 나타납니다.

삭제 표시가 다시 애니메이션되는 방법
Active Directory는 삭제 표시를 다시 일반 개체로 복원하는 메커니즘을 제공합니다. 이 메커니즘은 삭제된 개체에 대한 효과적인 삭제 취소 기능입니다. 이 기능은 두 개의 특정 특성을 수정해야 하는 특별한 형태의 LDAP 수정 작업입니다. 즉, isDeleted 특성을 FALSE로 설정하는 것이 아니라 제거해야 하고 개체의 distinguishedName을 변경하여 개체를 다른 컨테이너로 이동해야 합니다. 새 distinguishedName은 반드시 그런 것은 아니지만 일반적으로 lastKnownParent 특성을 컨테이너로 사용하고 Active Directory가 삭제 표시를 만들 때 추가한 RDN에서 \0ADEL:<objectGUID> 부분을 제외하고는 같은 RDN을 유지합니다.
Active Directory는 삭제 표시를 다시 애니메이션하기 전에 특정 필수 조건이 모두 true인지 검사합니다. 사용자는 삭제 표시가 포함된 NC의 NC 헤드에 대해 정의된 삭제 표시 다시 애니메이션 확장 액세스 권한을 갖고 있어야 합니다. 사용자는 자신이 소유한 개체를 다시 애니메이션할 수 없습니다. 삭제 표시의 isDeleted 특성은 TRUE로 설정되어 있어야 합니다. 또한 보안 설명자에 정의된 대로 개체의 소유자 SID(보안 식별자)는 포리스트 또는 트러스트된 도메인에 있는 도메인 중 하나의 SID를 갖고 있어야 합니다.
해당 개체가 구성 또는 스키마 NC에 있는 경우에는 삭제 표시의 systemFlags 특성에 FLAG_CONFIG_ALLOW_RENAME 및 FLAG_ CONFIG_ALLOW_MOVE 비트가 설정되어 있어야 합니다. 개체가 구성 또는 스키마 NC에 있고 FLAG_CONFIG_ALLOW_LIMITED_MOVE 플래그가 설정되어 있으면 개체는 최상위 컨테이너가 같은 컨테이너로만 이동될 수 있습니다. 즉, 개체는 이동된 뒤에도 최상위 컨테이너를 그대로 유지해야 합니다. 또한 개체가 도메인 NC 또는 응용 프로그램 파티션에 있는 경우에는 삭제 표시의 systemFlags 특성에 FLAG_DOMAIN_DISALLOW_RENAME 및 FLAG_DOMAIN_DISALLOW_MOVE 비트가 설정되어 있지 않아야 합니다.
사용자는 보안 설명자에 정의된 대로 RDN(항상은 아니지만 일반적으로 CN)을 수정하고 새 부모 컨테이너에 개체를 추가할 수 있는 권리를 갖고 있어야 합니다. 또한 새 부모 컨테이너는 스키마 정의대로 삭제 표시의 objectClass에 대한 상위 항목이어야 합니다. Unlock 시스템 하위 트리 레지스트리 값 키가 0 이외의 값인 경우를 제외하고는 시스템 컨테이너 내외로의 이동은 일반적으로 허용되지 않지만 삭제 표시를 시스템 컨테이너로 다시 애니메이션하는 것은 허용됩니다.
스키마 개체를 다시 애니메이션하는 작업은 허용되지 않습니다. 하지만 스키마 NC에서 개체를 합법적으로 삭제할 수 없기 때문에 이 점은 사실상 문제가 되지 않습니다.
모든 검사를 통과하고 필수 요구 조건을 만족하는 경우 Active Directory에서는 삭제 표시에 다음 단계를 수행하여 개체를 다시 애니메이션합니다.
  • isDeleted 특성을 제거합니다.
  • 수정 작업에 미리 지정된 경우가 아니면 objectCategory는 삭제 표시에 지정된 가장 구체적인 objectClass로 설정됩니다.
  • RDN을 변경하고 개체를 새 부모 컨테이너에 씁니다.
다시 애니메이션된 개체는 삭제되기 전 원래 갖고 있던 objectGUID와 objectSid 특성을 동일하게 갖습니다. 따라서 삭제된 개체를 다시 만들 때처럼 ACL 등에서 개체 외부 참조를 다시 설정하지 않아도 됩니다. 다시 애니메이션된 개체는 삭제되기 전과 동일한 모습으로 동일하게 동작합니다. 하지만 한 가지 중요한 차이점이 있습니다. 이는 바로 삭제 표시에 저장되지 않은 특성은 복원된 개체에서 누락된다는 점입니다.

LDP를 사용하여 삭제 표시 다시 애니메이션
systemFlags 특성 및 개체 동작
systemFlags 특성은 이 특성을 모든 Active Directory 클래스에 대한 선택적 특성으로 만드는 최상위 클래스에 대해 정의된 선택적 특성입니다. 이 특성은 개체 이동 및 삭제 동작을 제어하는 32비트 정수 비트 마스크입니다. 다음은 중요 플래그에 대한 간단한 설명입니다.

FLAG_DISALLOW_DELETE (0x80000000)

이 플래그를 설정하면 개체의 삭제 또는 다른 도메인으로의 이동이 허용되지 않습니다.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체의 이름을 변경할 수 없습니다.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체를 이동할 수 없습니다.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

systemFlags 특성에 이 플래그가 설정되어 있지 않으면 구성 및 스키마 NC에 속한 개체를 이동할 수 없습니다. 이 플래그는 이동 작업의 대상 컨테이너를 더욱 제한합니다. 즉, 대상 컨테이너의 최상위 컨테이너가 현재 컨테이너와 동일해야 합니다.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

기본적으로 도메인 NC 또는 응용 프로그램 NC에 속한 개체 이름은 변경할 수 있습니다. 하지만 개체의 systemFlags 특성에 이 플래그가 설정되어 있으면 개체 이름을 변경할 수 없습니다.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

기본적으로 도메인 NC 또는 응용 프로그램 NC의 개체는 다른 컨테이너로 이동할 수 있습니다. 하지만 개체의 systemFlags 특성에 이 플래그가 설정되어 있으면 개체를 이동할 수 없습니다.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

이 플래그가 설정되어 있으면 개체를 명명 컨텍스트의 CN=Deleted Objects 컨테이너로 이동할 수 없습니다. 대신 isDeleted 특성을 설정하고, 개체 이름을 변경하고, 스키마에서 저장되도록 지정되지 않은 특성을 제거합니다. 따라서 삭제된 개체가 모두 명명 컨텍스트의 CN=Deleted Objects 컨테이너에 표시되는 것이 아니라 일부는 원래 부모 컨테이너에 남게 됩니다.

지금까지 삭제 표시의 다시 애니메이션 작동 방식을 개괄적으로 살펴보았으므로 LDP를 사용하여 앞서 삭제한 CN=John Smith 사용자를 복원하는 방법을 설명하겠습니다. 먼저 DC에 연결하고 인증합니다. 이제 LDP를 사용하여 수정 작업을 수행할 수 있습니다. 수정 작업 매개 변수를 통해 isDeleted 특성을 제거하고 동시에 새 DN을 지정할 수 있습니다.
삭제 표시에 대해 작업을 하고 있으므로 Return Deleted Objects LDAP 컨트롤을 지정해야 합니다. LDP에서 수정 작업에 사용할 이 컨트롤을 설정하려면 옵션 메뉴에서 Controls(컨트롤)를 선택하고, Load Predefined(로드할 미리 정의된 컨트롤) 드롭다운 목록에서 Return deleted objects를 선택하고, Check in(체크 인) 단추를 누른 다음 OK(확인)를 눌러 컨트롤 설정을 저장합니다.
이제 Browse(찾아보기) 메뉴에서 Modify(수정)를 선택하여 Modify(수정) 대화 상자를 열고 복원할 삭제 표시 개체의 DN을 입력합니다. DN은 앞서 수행한 검색 작업의 결과에서 DN을 복사한 다음 붙여 넣는 방법으로 쉽게 입력할 수 있습니다.
그런 다음 수행할 특성 작업의 목록을 입력해야 합니다. 삭제 표시를 다시 애니메이션하려면 두 가지 특성 작업이 필요합니다. 즉, isDeleted 특성을 삭제하고 distinguishedName 특성을 다시 애니메이션된 삭제 표시에 대해 원하는 DN으로 바꿉니다. 따라서 Attribute(특성) 필드에는 isDeleted를 입력하고 Delete(삭제) 라디오 단추를 선택합니다. Enter(입력) 단추를 누르면 그림 8에서와 같이 특성 작업이 Entry List(항목 목록)에 추가됩니다.
그림 8 수행할 특성 작업 지정
그림 8 수행할 특성 작업 지정
그런 다음 distinguishedName을 Attribute(특성) 필드에 입력하고 Replace(바꾸기) 라디오 단추를 선택한 다음 Values(값) 필드에 개체의 새 DN을 입력합니다. 이 예제에서는 사용자의 원래 distuiguishedName인 CN=John Smith,CN=Users,DC=foo,DC=local을 사용합니다. Enter(입력) 단추를 누르면 수정 작업이 Entry List(항목 목록)에 추가됩니다.
Return Deleted objects LDAP 컨트롤을 수정 작업에 포함해야 하므로 확장된 LDAP 수정을 사용해야 합니다. 이를 위해 Extended(확장) 확인란을 선택합니다. 그림 9에서와 같이 설정을 마쳤으면 Run(실행) 단추를 눌러 변경 내용을 적용합니다. LDP는 큰 텍스트 창에 결과를 표시합니다.
그림 9 distinguishedName 변경
그림 9 distinguishedName 변경
이제 Active Directory 사용자 및 컴퓨터 MMC 스냅인으로 돌아가서 CN=Users 컨테이너를 보면 삭제된 사용자 개체가 다시 원래 위치로 복원된 것을 볼 수 있습니다. 하지만 이 개체는 원래 상태와 몇 가지 중요한 차이점을 보이는데 이에 대해 잠깐 살펴보겠습니다.

ADRESTORE를 사용하여 삭제 표시 다시 애니메이션
LDP를 사용하는 방법을 알고 나면 삭제 표시를 다시 애니메이션하는 작업은 그리 어렵지 않습니다. 하지만 그다지 편리하지도 않습니다. 다행히도 지금은 Microsoft의 일부가 된 Sysinternals에서 다시 애니메이션 실행 프로세스를 단순화하는 명령줄 도구를 개발했습니다. ADRESTORE라는 이 도구는 Microsoft 웹 사이트(microsoft.com/technet/sysinternals/utilities/AdRestore.mspx)에서 얻을 수 있습니다. 설치는 간단하게 할 수 있습니다. 실행 파일을 C:\WINDOWS\SYSTEM32 디렉터리와 같은 시스템의 적절한 디렉터리로 복사하기만 하면 됩니다.
ADRESTORE는 두 가지 모드에서 실행됩니다. 매개 변수를 지정하지 않고 실행하면 기본 도메인의 CN=Deleted Objects 컨테이너에 있는 모든 삭제 표시가 나열됩니다. 명령줄에 검색 문자열을 추가하여 표시할 개체를 선택할 수도 있습니다. 예를 들면 다음과 같습니다.
C:\> adrestore John
이렇게 하면 CN=Deleted Objects 컨테이너에서 CN 또는 OU 특성에 "John"이라는 문자열이 포함된 모든 삭제 표시 개체가 표시됩니다. 여기에는 LDAP 검색 필터 cn=*John* 및 ou=*John*이 사용됩니다. 이 방법이 삭제 표시 개체를 검색하는 가장 유연한 방법은 아니지만 대부분의 상황에 적합합니다. 그림 10에서는 ADRESTORE에서 반환된 검색 결과를 보여 줍니다.
그림 10 삭제 표시에 저장된 특성
그림 10 삭제 표시에 저장된 특성
삭제 표시를 찾는 것만이 아니라 다시 애니메이션하려면 다음과 같이 선택적 문자열과 함께 -r 스위치를 지정해야 합니다.
C:\> adrestore –r John
이 명령을 실행하면 일치하는 각 삭제 표시 개체를 다시 애니메이션할지 묻는 메시지가 표시됩니다. ADRESTORE는 항상 삭제 표시의 lastKnownParent 특성으로 지정된 컨테이너로 개체를 다시 애니메이션합니다. 다른 컨테이너를 지정할 수는 없습니다.
ADRESTORE는 Active Directory 다시 애니메이션 기능을 사용하기 위한 편리한 명령줄 인터페이스를 제공합니다. 유연성이 뛰어나지는 않지만 LDP보다는 사용하기가 조금 더 쉽습니다. 하지만 ADRESTORE도 삭제 표시 다시 애니메이션과 관련하여 나타나는 두 가지 중요한 문제인 처음 삭제될 때 개체에서 제거된 특성의 복구와 구성 NC에서 삭제된 개체의 복구 문제는 해결하지 못합니다.

개체 특성 복구
데이터 복구의 측면에서 보면 삭제 표시 다시 애니메이션은 정식 복원을 수행하는 것보다 더 큰 장점을 제공합니다. 삭제 표시 다시 애니메이션의 경우 DC를 오프라인으로 전환할 필요가 없기 때문입니다. 또한 삭제 표시 다시 애니메이션은 삭제된 개체의 새 버전을 간단하게 다시 만드는 것보다 훨씬 편리합니다. 개체를 새로 만들려면 항상 새 objectGUID 및 objectSid(사용자와 같은 보안 주체인 경우) 특성을 가져와야 합니다. 그 결과 ACL과 같은 경우 개체에 대한 모든 외부 참조를 업데이트하여 새 개체의 ID를 반영해야 합니다. 이렇게 하려면 작업이 매우 복잡할 수 있습니다.
개체가 삭제될 때는 일부 특성이 제거되는데 이러한 특성은 삭제 표시 다시 애니메이션으로 복구되지 않습니다. 하지만 Active Directory는 일부 중요한 특성을 삭제 표시에 저장하는데 여기서 가장 중요한 것은 objectGUID와 objectSid와 같은 ID 관련 특성입니다. 또한 기본적으로 여러 가지 다른 특성도 저장합니다(그림 1 참조). 저장되도록 하드 코드된 대부분의 특성은 그리 중요하지 않으며 삭제된 사용자 개체의 복구를 이야기할 때는 더욱 그렇습니다. 하지만 Active Directory 스키마에 있는 해당 attributeSchema 개체의 searchFlags 특성을 비트 3(0x00000008)으로 설정하여 삭제 표시에 저장할 추가적인 특성을 지정할 수 있습니다. Windows Server 2003 R2의 경우 스키마의 일부 특성에는 이미 이 비트가 설정되어 있습니다(그림 1 참조).
특정 응용 프로그램을 설치하면 기존 특성의 searchFlags에 설정된 비트 3이 변경되거나 비트 3이 설정된 특성이 새로 추가될 수도 있습니다. 예를 들어 Exchange Server는 몇 가지 추가 특성이 삭제 표시에 저장되도록 구성합니다.
Active Directory는 스키마 개체의 searchFlags 특성에서 지정하더라도 정방향 연결 또는 역방향 연결 특성을 삭제 표시에 저장하지 않습니다. 특히 Active Directory는 그룹의 member 특성 또는 사용자의 memberOf 특성과 같은 항목을 저장하지 않습니다. 따라서 삭제 표시 다시 애니메이션을 사용해서는 Active Directory에서 이와 같은 그룹 구성원 데이터를 복구할 수 없습니다. 필자의 기사인 "재해 복구: Active Directory 사용자 및 그룹"(technetmagazine.com/issues/2007/04/ADRecovery) 기사를 참조하십시오. 따라서 삭제 표시를 다시 애니메이션할 때 이 정보를 복구하기 위한 다른 메커니즘을 제공해야 합니다.
삭제 표시 다시 애니메이션을 데이터 복구 전략의 일부로 사용하려면 중요한 특성이 삭제 표시에 저장되도록 하거나 LDIFDE나 다른 백업/복원 스키마를 사용하는 것처럼 중요한 특성을 저장하고 복구할 다른 방법을 제공해야 합니다. 다른 방법으로 삭제 표시에 저장되거나 삭제 표시에서 복구되지 않는 특성을 백업하고 복원하는 자동화된 메커니즘을 제공하는 타사 Active Directory 데이터 복구 제품을 사용할 수도 있습니다.

구성 명명 컨텍스트에서 개체 다시 애니메이션
삭제 표시 다시 애니메이션의 또 다른 제한은 일반적으로 구성 NC에서 삭제된 개체는 다시 애니메이션할 수 없다는 점입니다. 이러한 개체는 개체의 systemFlags 특성에 정의된 대로 이동 및 이름 변경에 대한 특별한 규칙을 따릅니다. systemFlags 특성을 사용하여 별도로 지정한 경우 이외에는 구성 NC의 개체를 이동하거나 개체의 이름을 변경할 수 없기 때문에 삭제 표시를 다시 애니메이션할 수 없습니다. Active Directory에서는 그림 11에 정의된 것처럼 특정 클래스의 개체를 만들 때 systemFlags 특성에 특정 값을 설정합니다. Active Directory는 추가 작업에서 지정된 모든 systemFlags 값과 함께 해당 값에 비트 논리 OR 연산을 적용합니다. 응용 프로그램이 systemFlags 특성에 다른 값을 지정한 경우에도 이 방법을 통해 필수 비트가 적절하게 설정됩니다.
Figure 11 기본 systemFlags 설정 (Close Figure 11)

클래스 | 기본 설정
server | FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site | FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer | FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA | FLAG_DISALLOW_MOVE_ON_DELETE
siteLink | FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge | FLAG_CONFIG_ALLOW_RENAME
nTDSConnection | FLAG_CONFIG_ALLOW_RENAME
일반적으로 구성 NC에서 다시 애니메이션할 수 있는 유일한 개체는 서버 개체입니다. 흥미롭게도 Active Directory가 서버 개체를 삭제할 때는 삭제 표시가 구성 NC의 CN=Deleted Objects 컨테이너로 이동되지 않습니다. 즉, 삭제 표시는 개체의 원래 위치에 남아 있습니다. 이를 통해 Active Directory 복제 토폴로지 계산을 담당하는 KCC(정보 일관성 검사기)가 삭제된 서버 개체가 적절한 복제를 억제했을 수 있는 특정 시나리오에서 자동으로 복구할 수 있습니다. 따라서 서버 개체를 다시 애니메이션하려는 경우에는 해당 개체를 CN=Deleted Objects 컨테이너에서 찾을 수 없음을 기억하십시오.

복구 계획에서의 다시 애니메이션
삭제 표시 다시 애니메이션은 데이터 복구 도구 키트의 핵심 부분입니다. 이 메커니즘은 DC를 오프라인으로 전환하지 않고 삭제된 개체를 복구할 수 있는 유일한 방법이며 삭제된 개체의 ID 정보를 복구할 수 있는 유일한 방법입니다. 이를 통해 삭제된 사용자나 그룹을 다시 만들고 이전 ACL 참조를 모두 수정해야 하는 문제점이 해결됩니다.
하지만 삭제 표시 다시 애니메이션도 완전한 솔루션은 아닙니다. Active Directory가 삭제 표시 개체에 저장하지 않는 특성을 복구할 수 있는 자체 메커니즘을 제공해야 하며 구성 NC에서 삭제된 개체를 복구하는 기능도 제한적입니다. 삭제된 사용자나 그룹을 다시 애니메이션하려고 결정한 경우에도 필요할 수 있는 다른 연결된 특성 및 그룹 구성원을 복구해야 한다는 점을 기억하십시오.

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


 Communications: 사용자와 Office Communications Server 2007 연결
Communications Alan Maddison

사용자와 Office Communications Server 2007 연결
한 눈에 보기:
  • Office Communications Server 아키텍처
  • 회의 기능
  • Enterprise Voice
  • 향상된 현재 상태

통합 통신 방법을 소개합니다. 새로 출시될 Office Communications Server 2007에서는 Live Communications Server 2005의 사용자 환경을 완전히 새롭게 향상시켜 제공합니다. 아키텍처 및 관리 기능상의 향상뿐만 아니라 Office
Communications Server 2007에는 Office Communicator라는 새로운 클라이언트도 추가되었습니다. 또한 Enterprise Voice, 구내 웹 회의, 향상된 현재 상태 및 인스턴트 메시징, 페더레이션 등 새로운 기능과 향상된 기능도 제공합니다. 이러한 기능을 함께 사용하면 Microsoft® Unified Communication 전략을 위한 플랫폼을 마련할 수 있으며 생산성과 장거리 공동 작업을 향상시킬 수 있습니다.
이 업데이트에는 훨씬 효율적인 MMC(Microsoft Management Console) 스냅인 인터페이스도 포함되어 있습니다. 그림 1에서는 성능 카운터의 새로운 관리 기능 중 하나를 보여 줍니다.
그림 1 성능 카운터가 포함된 새로운 MMC 스냅인
그림 1 성능 카운터가 포함된 새로운 MMC 스냅인
새로운 Office Communications Server 2007은 Standard와 Enterprise의 두 가지 버전으로 제공됩니다. Office Communications Server 2007 Standard는 사용자가 10,000명 미만인 배포 시나리오에 적합합니다. Standard 버전 배포의 경우 단일 프런트 엔드 서버에서 모든 서비스가 호스팅됩니다.
대규모 배포의 경우 Enterprise 버전을 사용하여 통합 구성 또는 확장 구성으로 배포할 수 있습니다. 통합 토폴로지에서는 모든 하드웨어가 단일 프런트 엔드 서버 풀로 구성됩니다. 확장 구성을 사용하면 프런트 엔드 서버의 엔터프라이즈 풀 외부에서 IIS(인터넷 정보 서비스), 웹 회의 및 A/V(오디오/비디오) 회의 서버를 실행하는 전용 웹 서버를 사용할 수 있으므로 확장성을 극대화할 수 있습니다. 그림 2에서는 확장 구성 토폴로지를 보여 줍니다.
그림 2 확장 구성 토폴로지
그림 2 확장 구성 토폴로지

아키텍처
Office Communications Server 2007 아키텍처는 프런트 엔드 서버, 에지 서버, 응용 프로그램 서버 등의 핵심 서버를 기반으로 합니다. 프런트 엔드 서버는 사용자 인증, 주소록 유지 관리, 현재 상태 관리, 회의 관리 및 응용 프로그램 호스팅 기능은 물론, 서버와 클라이언트 간의 신호 처리, 미디어 관리(파일 공유 포함), IM(인스턴트 메시징), 회의 트래픽의 라우팅 등을 제공합니다.
Office Communications Server 2007의 핵심 회의 기능은 MCU(Multipoint Control Unit)라는 일련의 통합 서버를 통해 제공됩니다. 그림 3에서는 이러한 서버와 그 역할을 간단히 보여 줍니다.
Figure 3 회의 서버와 그 기능 (Close Figure 3)

회의 서버(MCU) | 지원되는 기능
인스턴트 메시징 | 참가자 간에 IM 트래픽을 라우팅하여 그룹 IM을 지원합니다. 프런트 엔드 서버에 통합되며 개별 서버에는 설치할 수 없습니다.
전화 통신 | 인바운드 및 아웃바운드 발신음을 지원합니다. 프런트 엔드 서버에 통합되며 개별 서버에는 설치할 수 없습니다.
웹 | 화이트보드, 응용 프로그램 공유, 질문과 대답 등의 공동 작업 기능을 담당합니다. 이 서버는 Office 문서 공유와 PowerPoint 프레젠테이션 지원 기능도 제공합니다. 프런트 엔드 서버에 설치하거나 개별 서버에 확장 풀 구성으로 설치할 수 있습니다.
A/V | 여러 사용자의 IP 오디오/비디오 혼합 및 릴레이에 사용됩니다. 프런트 엔드 서버에 설치하거나 개별 서버에 확장 풀 구성으로 설치할 수 있습니다.
프런트 엔드 서버의 또 다른 중요한 기능으로 주소록 서버에 대한 호스팅 기능을 들 수 있습니다. Live Communications Server 2005 SP1에 익숙한 독자라면 이 서비스도 잘 알 것입니다. Office Communications Server 2007에서 이 서비스는 더 이상 선택적 구성 요소가 아니라 핵심 구성 요소로서 중추적인 역할을 담당합니다. 주소록 서버는 주소록 서비스와 주소록 파일 저장소의 두 구성 요소로 이루어지며 내부 원본과 외부 원본에서 연락처 정보를 제공하는 역할을 담당합니다. Active Directory® 및 Exchange Server의 전체 주소 목록과 메일 그룹이 내부 원본의 대표적인 예라 할 수 있고, 외부 원본으로는 페더레이션 파트너 또는 공용 IM 연락처의 사용자를 들 수 있습니다.
Office Communications Server 2007에서는 Live Communications Server 2005에서 처음 선보인 외부 사용자 연결 기능이 더욱 향상되어 외부 사용자가 구내 회의에 참여할 수 있습니다. 이 추가 기능을 지원하기 위해서는 웹 회의 에지 서버와 A/V 에지 서버가 필요합니다. 또 다른 변경 사항으로, 이전의 액세스 프록시 서버가 액세스 에지 서버로 바뀌었습니다. Office Communications Server 에지 서버는 네트워크 경계(스크린된 서브넷)에 배치되도록 설계되었으며 중요한 외부 사용자 연결 기능을 제공합니다. 그림 4에는 에지 서버 역할과 용도가 요약되어 있습니다.
Figure 4 에지 서버 역할 (Close Figure 4)

서버 | 지원되는 기능
액세스 에지 서버 | 페더레이션, 원격 사용자 연결, PIC(공용 IM 연결)를 담당합니다.
웹 회의 에지 서버 | 외부 웹 회의를 담당합니다.
A/V 에지 서버 | 외부 사용자를 대상으로 한 A/V 회의 및 지점 간 A/V 통화를 담당합니다.
역방향 프록시 서버 | 그룹 확장, 주소록 파일 다운로드, 모임 콘텐츠에 대한 웹 회의 액세스에 사용됩니다. 엄밀히 말해 Office Communications Server 역할이라고 할 수는 없지만 중요한 기능을 제공합니다. ISA Server 2006에서도 역방향 프록시 기능이 제공됩니다.
앞서 설명한 통합 서버 외에 Office Communications Server는 다양한 응용 프로그램 서버를 사용하여 인증, 회의 메타데이터 저장, 메일 그룹 기능 제공 등의 핵심 기능을 수행합니다. Office Communications Server에서 주로 사용되는 응용 프로그램 서버로는 IIS, 인증서 서버, Active Directory 환경의 글로벌 카탈로그 서버, SQL Server® 2005, Exchange Server 2007 및 파일 서버가 있습니다.
IIS는 모임 콘텐츠, 주소록 업데이트, IM을 위한 Active Directory 메일 그룹 확장 및 외부 사용자를 위한 Outlook® 메일 그룹 확장에 대한 액세스를 제공하고 Office Communications Server 구성 요소 간의 기본 통신을 지원하는 데 사용됩니다.
인증서 서버는 Office Communications Server에서 클라이언트와 서버 간 통신 및 서버 간 통신의 보안과 관련하여 중요한 역할을 합니다. 내부 엔터프라이즈 인증서 서버를 사용하는 경우 모든 내부 클라이언트와 서버가 인증서를 발행하는 CA(인증 기관)를 신뢰해야 합니다. 이를 위해서는 각 CA 인증서 체인이 각 컴퓨터의 신뢰할 수 있는 루트 저장소에 설치되어야 합니다. Office Communications Server 페더레이션 서비스를 사용하는 경우에는 파트너 조직에서도 동일한 방법으로 인증서를 설치해야 합니다.
회의 참가자 인증은 Active Directory 환경의 글로벌 카탈로그 서버에 의해 지원됩니다. 글로벌 카탈로그 서버에서는 내부 사용자와 페더레이션 사용자에 대해 Kerberos 인증을 사용합니다. 또한 회사의 원격 사용자는 NTLM을 통해 자신의 Active Directory 자격 증명을 사용하고 익명 사용자는 다이제스트 인증을 통해 인증됩니다.
회의에 대한 상태 데이터, 사용자 등록 및 현재 상태 정보를 관리하는 데에는 SQL Server 2005가 사용됩니다. 오류가 발생할 경우 SQL Server에 저장된 데이터로 모임을 손쉽게 복원할 수 있으므로 콘텐츠 손실 없이 빠르고 안정적으로 복구할 수 있는 수단이 제공됩니다.
Exchange Server 2007과 통합 메시징 기능에 음성 메시징 및 자동 전화 교환 기능이 추가되면서 Office Communication Server 2007에 중요한 부가 기능을 제공하게 되었습니다.
파일 서버는 클라이언트에서 액세스하는 데이터를 저장하는 데 사용됩니다. 예를 들어 주소록을 다운로드할 때 클라이언트에서 필요로 하는 실제 파일은 파일 서버에 저장됩니다. 마찬가지로 추가 모임 콘텐츠도 파일 서버에 저장됩니다.
Office Communications Server 2007의 기본 프로토콜 아키텍처에는 표준 인터넷 프로토콜과 Microsoft 프로토콜이 복합적으로 사용됩니다. 예를 들어 IM, 회의 및 현재 상태 구독과 같은 기능에는 SIP(Session Initiation Protocol)가 광범위하게 사용됩니다. 이 프로토콜은 다양한 Office Communications Server 구성 요소에서 성능과 유연성을 최대한 제공하기 위해 사용됩니다. 그림 5에서는 핵심 프로토콜과 그 용도를 간단히 보여 줍니다.
Figure 5 프로토콜과 그 용도 (Close Figure 5)

프로토콜 | 지원되는 기능
HTTP(Hypertext Transfer Protocol) | 클라이언트 액세스, 모임 콘텐츠 다운로드 및 주소록 데이터에 사용됩니다. 또한 회의 서버와 Office Communications Server의 구성 요소 중 하나인 Focus 간의 통신에도 사용됩니다.
SIP(Session Initiation Protocol) | Enterprise Voice, IM, 회의 서버, 향상된 현재 상태 등의 여러 Office Communications Server 구성 요소에서 세션 생성과 관리에 사용됩니다.
CCCP(Centralize Conference Control Protocol) | 회의 및 회의 클라이언트를 설정하고 제어하는 데 사용되는 사용자 지정 프로토콜입니다.
PSOM(Persistent Shared Object Model) | 보안 키, 사용자 역할 및 권한을 비롯한 웹 회의 콘텐츠 전송에 사용되는 사용자 지정 프로토콜입니다.
RTP(Real-Time Transport Protocol) | 실시간 데이터를 전달하는 데 사용됩니다. Office Communications Server 2007에서는 Enterprise Voice와 A/V 회의의 전송 메커니즘을 제공하는 역할을 합니다.
SRTP(Secure Real-Time Transport Protocol) | 암호화, 메시지 인증 및 RTP 데이터 무결성 검사와 같은 보안 서비스를 제공합니다. Office Communications Server 2007에서는 마이크나 스피커와 같은 미디어 장치에 전송되는 오디오 및 비디오 콘텐츠의 보안에 사용됩니다.
RTCP(Real-Time Transport Control Protocol) | 미디어 장치 간에 A/V 회의 세션의 신호 품질에 대한 정보를 전달하기 위해 SRTP와 함께 사용됩니다.

Enterprise Voice
Enterprise Voice는 Microsoft에서 구현한 VoIP(Voice over Internet Protocol) 전화 통신 기능으로, 가장 중요한 추가 기능 중 하나라고 할 수 있습니다. 신호에 SIP(Session Initiation Protocol)를 사용하고 음성 트래픽에 RTP(Real Time Protocol)를 사용하는 Enterprise Voice를 통해 PC 간 또는 PC와 전화 간에 전화를 걸거나 받을 수 있습니다. 뿐만 아니라 Enterprise Voice는 호출 제어 및 라우팅, 번호 정규화 등의 기능도 제공합니다. 또한 PSTN(공중 전화망)을 지원하고 SIP 또는 CSTA(Computer-Supported Telecommunications Applications)를 지원하거나 Office Communications Server 2007 API와의 직접 상호 작용하는 PBX(사설 교환기)와 상호 운용이 가능합니다.
Office Communications Server 2007은 구성을 크게 변경하지 않고도 기존 음성 인프라에 배포하여 유용하게 활용할 수 있습니다. 이는 Enterprise Voice에서 SIP–PBX, SIP–IP–PBX 및 IP-PSTN의 세 가지 배포 구성을 지원하기 때문입니다.
SIP–PBX 설치의 경우 모든 원격 호출이 PBX에 의해 제어되고 기존 전화를 그대로 사용할 수 있습니다. 이러한 통합은 RCC(원격 호출 제어) 게이트웨이와 CSTA 덕분에 가능한 것입니다.
SIP–IP–PBX 구성에서는 CSTA를 사용하지 않으면서 Office Communicator 클라이언트가 전화를 걸고 IP-PBX 전화를 제어할 수 있도록 하는 IP-PSTN 게이트웨이가 사용됩니다. 기존에 사용 중인 송수화기가 없으면 Office Communicator를 "소프트폰(Softphone)"으로 구성할 수 있습니다.
IP-PSTN 구성 요소를 사용하여 Office Communications Server 2007을 배포하면 호출 제어를 프런트 엔드 서버로 라우팅할 수 있습니다. Office Communicator는 VoIP 또는 Microsoft 인증 타사 SIP 끝점(대부분의 조직에서 이 끝점은 송수화기임)과 상호 작용하여 인터넷을 통해 전화를 걸거나 받을 수 있습니다.
VoIP와 PSTN 간의 신호 및 미디어 변환을 제공하는 타사 게이트웨이를 미디어 게이트웨이라고 합니다. Office Communications Server 2007은 기본, 고급 및 기본 복합형의 세 가지 미디어 게이트웨이를 지원합니다. 고급형 게이트웨이 이외의 다른 게이트웨이를 지원하기 위해 Office Communications Server 2007에서는 핵심 프로토콜과 미디어 변환 기능을 지원하는 중개 서버 역할을 제공합니다. Office Communications Server에서 제공되는 구성 요소를 사용하면 원격 사무실 통합도 가능합니다.
Office Communications Server 2007의 다른 구성 요소와 마찬가지로 Enterprise Voice도 에지 서버를 통해 외부 사용자 연결 기능을 제공합니다. 특히 회사 경계 외부에 존재하는 사용자의 경우 액세스 에지 서버(SIP 신호에 사용됨)가 필수적이며, A/V 에지 서버는 음성 또는 비디오 서비스에 액세스하는 외부 사용자가 방화벽, NAT(Network Address Translation) 구현 등의 경계 네트워크 서비스를 통해 연결하도록 하는 데 사용됩니다.
향후 Enterprise Voice는 다양한 클라이언트를 지원하게 되겠지만 현재로서는 최신 버전의 Office Communicator가 Enterprise Voice의 클라이언트로 권장됩니다. Microsoft와 해당 파트너는 Office Communications Server와 통합되는 새로운 VoIP 전화 하드웨어 출시 계획을 발표하기도 했습니다.
Enterprise Voice는 Exchange Server 2007의 통합 메시징 역할과 통합되어 Outlook Voice Access나 컴퓨터에서 전화를 걸어 음성 메일, 전자 메일, 일정, 연락처 및 팩스 수신 기능에 액세스할 수 있는 단일 인터페이스를 제공합니다. 통합 메시징 기능은 또한 자동화된 전화 메뉴 시스템을 구현하는 데 사용되는 자동 전화 교환 서비스도 제공합니다.

향상된 현재 상태
Live Communications Server 2005를 통해 잘 알려져 있는 현재 상태의 개념이 Office Communications Server 2007에서는 더욱 확장되고 향상되었습니다. 일반적으로 현재 상태란 사용자의 상태나 연락 가능 여부와 관련이 있습니다. Office Communications Server에서는 현재 상태 관련 정보를 보다 세부적으로 구성할 수 있는 사용자 환경을 구현하도록 지원 인프라가 향상되었습니다.
따라서 사용자는 이제 온라인, 다른 용무 중, 방해 금지, 곧 돌아오겠음, 자리 비움 또는 오프라인으로 표시의 여섯 가지 상태 모드 중에서 선택할 수 있습니다. 또한 추가 정보를 표시하도록 이러한 상태를 사용자 지정할 수도 있습니다. 예를 들어 사용자가 상태를 방해 금지로 설정하는 경우 방해를 받고 싶지 않은 이유를 설명하는 추가 정보를 제공할 수 있습니다.
이러한 향상된 현재 상태 기능을 사용하면 Personal(개인), Team(팀), Workplace(회사), Public(공개) 및 Block(차단)의 다섯 가지 현재 상태 수준 옵션을 통해 다른 사용자에게 표시되는 정보를 필터링할 수도 있습니다. 이러한 수준 옵션을 사용하면 현재 상태를 계층적으로 관리할 수 있습니다. 예를 들어 현재 상태 수준을 Personal(개인)로 설정하면 사용자의 상태가 다른 용무 중인 경우에도 연락처에 추가된 사용자가 IM을 통해 연락할 수 있는 등 유연성이 최대한으로 제공됩니다. 연락처에 추가된 사용자에게 표시되는 정보의 양도 현재 상태 수준에 따라 제어됩니다.
뿐만 아니라 Office Communicator를 사용하면 사용자가 위치 상태도 사용자 지정 위치나 기본 위치(집 또는 사무실) 중 하나로 설정할 수 있습니다. 위치 정보는 Personal(개인) 또는 Team(팀)으로 분류된 연락처에 제공됩니다.
향상된 현재 상태 기능은 유용하고 원활한 통신에 도움이 될 뿐만 아니라 조직에 큰 영향을 미치는 Office Communications Server와 현재 상태 정보 엔진의 기본 인프라가 됩니다. 예를 들어 Office Communications Server 2007에는 사용자가 SharePoint 웹 사이트 또는 포털에 연결된 다른 사용자의 현재 상태를 볼 수 있도록 하는 SharePoint Server 2007 웹 파트인 구성원 웹 파트가 함께 제공됩니다. 이 웹 파트는 SharePoint 사이트에 손쉽게 추가하여 핵심 공동 작업 인프라에서 현재 상태 정보를 활용하는 데 사용할 수 있습니다.
현재 상태 정보는 문서 작업 영역과 스마트 태그 동작 단추를 통해 전체 Microsoft® Office 2007 응용 프로그램 제품군에 통합됩니다. 예를 들어 사용자의 상태, 연락처 및 일정 정보를 표시하는 스마트 태그 동작 단추를 사용할 수 있습니다. 이러한 스마트 태그 동작을 사용하면 작업을 공유하거나 모임 일정을 설정하거나 IM 대화를 시작할 수 있습니다.

구내 회의
Office Communications Server 2007의 또 다른 중요한 향상 기능으로 구내 회의 기능을 들 수 있습니다. 내부 또는 외부 사용자(익명 사용자 또는 페더레이션 사용자)와의 실시간 회의를 호스팅하는 이 기능은 여러 조직에서 매우 유용한 도구가 될 것입니다. 이러한 회의는 사전에 일정을 잡거나 특별 회의로 실시할 수 있으며 IM 회의, A/V 회의, 웹 회의뿐만 아니라 파일 공유, 화이트보드, 슬라이드 주석, 참가자 투표, 참가자 질문과 대답 세션 등을 포함할 수 있습니다. Office Communications Server에서는 회의 유형을 전환할 수도 있습니다. 예를 들어 기존 IM 세션에 공동 작업을 추가하도록 선택하거나 특별 회의를 만들 수 있습니다.
회의용 클라이언트로는 Office Communicator가 권장되지만 Office Live Meeting 2007 및 Outlook 2007용 Office Live Meeting 추가 기능도 지원됩니다. Office Communicator 2007은 IM, A/V 세션 참가, 응용 프로그램 공유, 화이트보드 및 파일 전송을 지원합니다. Office Live Meeting 2007에는 회의 참가뿐만 아니라 세션 예약, 세션 기록, 참가자 투표 및 질문과 대답에 대한 지원 기능이 포함되어 있습니다.
Outlook 2007용 Office Live Meeting 2007 추가 기능에는 Outlook 2007을 사용한 회의 작업 기능, 개별 참가자를 참가자 또는 발표자로 지정하는 기능, 역할별로 서로 다른 초대 메시지를 보내는 기능 등이 포함되어 있습니다. 사용자는 모임 이끌이, 발표자 또는 참가자로 역할이 설정될 수 있을 뿐만 아니라 위치와 자격 증명에 따라 내부 사용자 그룹 또는 외부 사용자 그룹으로 분류될 수도 있습니다. 즉, Active Directory 로그온 권한이 있고 회사 LAN에 연결되어 있는 사용자는 내부 사용자가 되고, 외부 사용자는 원격, 페더레이션 및 익명 사용자로 분류됩니다.
원격 사용자는 조직 내에서 Active Directory 계정을 가지고 있는 사용자를 의미하며 원격 작업자와 계약업체가 이 범주에 포함될 수 있습니다. 모든 원격 사용자는 회의를 호스팅하고 회의에 참가하고 발표할 수 있습니다.
페더레이션 사용자는 Office Communications Server 내의 페더레이션 설정에 따라 정의된 자격 증명이 있는 사용자를 말하며 모임에 참가하고 발표자 역할을 할 수 있지만 모임을 구성할 수는 없습니다.
익명 사용자는 권한이 가장 많이 제한된 그룹으로, 초대를 받은 모임에만 참가할 수 있습니다.
여러 가지 참가 제어 설정을 통해 모임의 보안 수준을 높일 수도 있습니다. Office Communications Server 2007에서는 공개 인증, 비공개 인증 및 익명의 참가 제어 옵션이 제공됩니다.
공개 인증 모임의 경우 Active Directory 로그인 권한이 있는 모든 원격 또는 내부 사용자의 참가가 허용됩니다. 또한 페더레이션 사용자도 참가할 수 있습니다. 비공개 인증 모임의 경우 모임 이끌이로부터 초대를 받은 사용자만 참가할 수 있도록 모임이 제한되고 페더레이션 사용자는 모임에 참가할 수 없습니다.
익명 모임은 초대를 받은 모든 사용자에게 공개되는 모임입니다. 이 모임에 참가하려면 사용자가 회의 키를 제공하고 다이제스트 인증을 통해 자신의 자격 증명을 확인 받아야 합니다. 모임에 참가한 후에 발표자로 승격되지 않는 한, 모든 익명 사용자에게는 참가자 역할만 부여됩니다. 그림 6에서는 몇 가지 사용 가능한 설정을 보여 줍니다.
그림 6 모임 설정
그림 6 모임 설정

전화 걸기
Office Communications Server 2007은 통신의 효율성을 높이고 다양한 통신 매체를 통합하고 제어 권한을 사용자에게 부여함으로써 회사의 업무 처리 방식을 혁신적으로 바꿀 수 있습니다. 현재 상태 정보와 통신 방법이 응용 프로그램에 포함되어 있는 상황에 맞는 통신이라는 개념은 이러한 혁신의 기반이 될 것입니다. 이러한 점에서 Office Communications Server 2007은 프로덕션 환경에 구현할 만한 가장 유용한 솔루션이라 하겠습니다.
Office Communications Server 2007에 대한 자세한 내용을 확인하고 베타 버전을 사용해 보려면 TechNet Office System TechCenter(technet.microsoft.com/en-us/office/bb267356.aspx)를 참조하십시오. 또한 Unified Communications Group 팀 블로그(blogs.technet.com/uc)도 방문해 보시기 바랍니다.

Alan Maddison은 MTI Technology Corporation의 수석 컨설턴트로, Active Directory, Exchange Server 및 가상화 관련 업무를 중점적으로 수행하고 있습니다.


 From The Editor: 배움의 길
From The Editor
배움의 길
Joshua Trupin

TechNet Magazine을 만들 때 9월호는 항상 "개학"을 모티브로 제작했습니다. 물론 이 시기가 항상 정확하지는 않습니다. 예를 들어 미국 학교의 경우 8월말에 개학하는 경우가 많습니다. 그리고 방학이 전혀 없는 사람들도 있고 말이죠.
그러나 대부분의 사람들에게 9월은 개학을 떠올리기에 적절한 시기라고 봅니다. TechNet Magazine이 IT 전문가 학위를 수여하는 고등 교육 기관의 역할을 한다는 점에서 이러한 모티브가 잘 어울린다고 할 수 있습니다. 물론 그런 학위가 실제로 있는 것은 아닙니다. 하지만 TechNet Magazine이 교육적인 효과가 있다는 것은 분명한 사실입니다. 이번 달에는 이 교육 과정을 체계적으로 정리해 보도록 하겠습니다.
훌륭한 고등 교육 기관이 모두 그런 것처럼, TechNet Magazine도 스크립팅 애호가를 위한 SQL 초급 과정("Hey, Scripting Guy!")에서부터 Active Directory 관리 도구 개론에 이르기까지 다양한 교육 기회를 제공합니다.
중급 학습 과정으로는 Windows Vista와 관련한 학위 과정이 있습니다. 먼저 BDD(Business Desktop Deployment) 2007을 사용하여 Windows를 배포하는 방법에 대해 배웁니다. 그리고 회사에 Windows Vista를 배포한 후에는 시스템에서 정기 백업을 구현하는 방법에 대한 지침과 사용 가능한 몇 가지 최신 기술에 대한 소개를 받을 수 있습니다.
자, 이제 고급 Active Directory 과정만 이수하면 IT 전문가 학위를 받을 수 있습니다. 시체 소생술에 대해 알고 싶지만 할로윈 특별판을 기다리기가 지루한 독자는 이번 달 기사를 읽으면서 아쉬움을 달래 보시기 바랍니다.
물론 TechNet Magazine은 배움의 종착역이 아니라 중간 기착지 정도에 불과합니다. Microsoft TechNet 사이트에서는 보다 심층적인 교육 과정이 제공됩니다. IT 전문가를 위한 수백 개의 주요 기술 관련 웹 캐스트가 준비되어 있으며, 그 중에는 Microsoft IT에서 내부적으로 이러한 기술을 어떻게 활용하고 있는지를 보여 주는 웹 캐스트도 있습니다. 웹 캐스트는 독자 유형(IT 전문가, 경영진 등)과 기술별로 분류되며 실제 대학 교과 과정과 마찬가지로 난이도 등급이 매겨져 있습니다.
일례로 이번 달 TechNet Magazine에는 Active Directory에 대해 깊이 있게 다룬 기사가 몇 개 실려 있습니다. 그러나 이러한 수준 높은 내용을 활용하기에는 아직 지식이 부족한 독자라면 TechNet 웹 캐스트에서 "Active Directory 기본 사항"(msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295120)이라는 Level 200 프레젠테이션을 보면 됩니다.
현대의 교육은 다양한 형태로 이루어집니다. TechNet에서는 독자에게 필요한 정보를 제공하기 위해 정기 간행물에서 인터넷에 이르기까지 다양한 형태의 교육 방법을 이용하고 있습니다. 몇 가지 기사를 읽어본 후 TechNet Magazine 블로그(blogs.technet.com/tnmag)를 방문하여 수업 내용을 복습하는 시간을 가져보는 것도 좋지 않을까요?
—Joshua Trupin

도움을 주신 Paul Bowden, Justin Hall, Anand Lakshminarayanan, Eduardo Laureano, Mike Lewis, Tim Mintner, Michael Murgolo, Mark Russinovich, Jim Truher를 비롯한 Microsoft 기술 전문가들에게 이 자리를 빌어 감사의 마음을 전합니다.


 Letters: 질문에 대한 답변
Letters
질문에 대한 답변

PsTools
2007년 3월 Desktop Files 칼럼에서 Wes Miller는 PsTools 유틸리티를 소개했습니다("PsTools 입문서", technetmagazine.com/issues/2007/03/DesktopFiles 참조). 그런데 이 멋진 유틸리티를 실행하려고 할 때 약간의 문제가 생겼습니다. 저는 특히 PsLoggedOn에 관심이 있습니다. 이 유틸리티를 제 경로에 있는 폴더에 추가하는 방법을 정확히 설명해 주시겠습니까? 예제를 곁들여 주시면 큰 도움이 되겠습니다.
—Tim

시작하기에 가장 좋은 방법은 전체 PsTools 패키지(download.sysinternals.com/Files/PsTools.zip)를 작업 디렉터리(예: c:\toolbox)로 다운로드하는 것입니다. ZIP 파일을 해당 디렉터리로 추출하면 도구를 사용할 준비가 된 것입니다. 이 디렉터리를 PATH에 추가하여 도구를 어디에서나 실행할 수 있게 하려면 명령 프롬프트에서 다음 명령을 실행하기만 하면 됩니다. 여기서 c:\toolbox는 사용하는 작업 디렉터리로 변경하십시오.
SET PATH=%PATH%;c:\toolbox

Robocopy 칭찬의 글
2006년 11월, Robocopy GUI에 대한 기사(technetmagazine.com/issues/2006/11/UtilitySpotlight)를 읽기 전까지 저희 회사 헬프 데스크는 네트워크 폴더에서 SharePoint® 저장소로 이동되는 파일의 타임스탬프를 유지할 방법을 찾지 못해 고생하고 있었습니다. Robocopy는 매우 멋진 도구입니다.
—Cristino

레지스트리 하위 키 확인
지난 몇 주 동안 저는 EnableLUA 레지스트리 하위 키의 값이 설정되었는지, 해제되었는지 테스트하는 방법을 찾기 위해 많은 노력을 기울였습니다. 이 값이 해제된 경우에는 사용자 계정 컨트롤이 해제됩니다. 확인을 위해 관리자 계정으로 로그인할 필요 없이 프로그램을 테스트 환경에 자동으로 설치할 수 있게 하려면 이 값을 해제해야 합니다. 저희는 이 테스트를 모든 설치 스크립트의 시작 부분에 추가하여 스크립트 실행 전에 EnableLUA의 값을 1(설정)에서 0(해제)으로 변경하는 스크립트를 실행하고자 합니다. 하지만 이 테스트를 실제 작동하는 데는 실패했습니다. 도움을 주시면 감사하겠습니다.
—Derek

다음은 레지스트리 키를 읽고, 값을 검사하고, 필요한 경우 값을 변경하는 기본 스크립트입니다. 이 예제에서는 키 HKLM\Software\Microsoft\Test\TestKey를 읽고, 값이 1인지 검사하고, 1이면 값을 0으로 변경합니다. 값이 1이 아닌 경우 스크립트는 종료됩니다.
On Error Resume Next
Set WSHShell =  Wscript.CreateObject _
    ("Wscript.Shell")
RegLoc = _
    "HKLM\Software\Microsoft\Test\TestKey"
KeyValue = WSHShell.RegRead(RegLoc)
If (KeyValue = "1") then
  WSHShell.RegWrite RegLoc,"0"
end If
Wscript.Quit
언제나 그렇듯이 레지스트리를 수정하는 스크립트, 특히 이런 종류의 스크립트는 특별히 주의해서 사용하시기 바랍니다.

ReadyBoost
ReadyBoost에 대해 좀더 명확하게 설명해 주시겠습니까? 제가 이해하기로는 ReadyBoost는 시스템의 RAM과 하드 드라이브 사이에 있는 버퍼처럼 동작하되 데이터는 동시에 기록되는 것으로 보입니다. 이 경우 시스템이 데이터를 이중으로 복사하기 때문에 성능이 저하되지 않습니까? ReadyBoost를 사용할 때와 사용하지 않을 때의 시스템 성능을 어떻게 테스트할 수 있을까요?
—Alex

ReadyBoost의 개념은 플래시 메모리(USB 스틱 등)가 임시 캐시처럼 작동하게 하여 비용이 더 많이 드는 일반 RAM의 양을 늘린다는 것입니다. ReadyBoost가 같은 데이터를 플래시 메모리와 하드 디스크에 동시에 쓰는 것만은 아닙니다. 대신 RAM과 디스크 사이의 중간 캐싱 계층으로 작동합니다. Mark Russinovich가 2007년 3월호 기사 "Windows Vista 커널 속으로: 2부"에서 이에 대해 다음과 같이 좀더 자세히 설명했습니다.
"ReadyBoost 서비스가 캐시를 초기화하고 나면 Ecache.sys 장치 드라이버는 로컬 하드 디스크 볼륨(예: C:\)에 대한 모든 읽기와 쓰기를 가로채고 기록 중인 모든 데이터를 서비스가 만든 캐시 파일에 씁니다...
...ReadyBoost는 캐시에서 사용 가능한 임의 읽기 작업이 있으면 캐시에서 이를 지원합니다. 그러나 하드 디스크는 플래시 메모리보다 순차 읽기 액세스 성능이 더 뛰어나므로 ReadyBoost는 순차 액세스 패턴의 일부인 읽기 작업을 데이터가 캐시에 있더라도 디스크에서 직접 수행할 수 있습니다."
Mark가 작성한 전체 기사는 technetmagazine.com/issues/2007/03/VistaKernel에서 볼 수 있습니다.

Windows PE 다운로드
2007년 5월호의 Letters 칼럼에 약간 일관되지 않는 내용이 있는 것 같습니다. 첫 번째 질문 "이미지 만들기"에 "Windows® PE 2.0 이미지는 WAIK의 도구를 사용하여 빌드하고 사용자 지정할 수 있으며..."라는 내용이 있습니다. 이 문구는 Windows PE가 도구에 포함되어 있고 다운로드할 수 있다는 의미입니다.
하지만 마지막 질문인 "Windows PE 구하기"의 답변에서는 "Windows PE는 Software Assurance 혜택으로만 제공됩니다..."라고 되어 있습니다. 제 생각에는 첫 번째 답변이 맞고 두 번째 답변은 이전 버전에 대한 답변을 갖다 쓴 것 같습니다.
—Xihui

Windows PE 2.0은 WAIK(Windows 자동 설치 키트)에서 다운로드 형태로 사용할 수 있습니다. 여기에는 Windows PE 1.6과 다른 라이선스 규칙이 적용됩니다. 이 이전 버전은 작년 기사인 "Windows PE 시작"에서 다뤘습니다. 이 기사는 technetmagazine.com/issues/2006/09/WindowsPE에서 볼 수 있습니다. Windows PE 1.6은 Software Assurance의 일부로만 제공되었습니다.

Windows PowerShell 보안
Windows PowerShell™에 대한 많은 이야기가 있었습니다. UNIX와 비슷한 구문, 손쉬운 명령 출력 형식 지정 등과 같은 내용을 다루는 기사는 많이 봤지만 Windows PowerShell을 데이터 센터에 도입할 때의 보안 관련 문제에 대해서는 들은 바가 없습니다.
이러한 강력한 셸을 프로덕션 서버에서 Windows PowerShell로 실행하거나 배포할 때 주의해야 할 보안 문제점은 무엇입니까?
—Carlos

Windows PowerShell에 관련된 보안이 중요하다는 점에는 전적으로 동감합니다. 실제로 Windows PowerShell 칼럼니스트인 Don Jones는 이번 호 TechNet Magazine에서 이 주제에 대해 깊이 있게 다룹니다. 이외에도 최근 출간된 두 권의 중요한 책도 참조할 수 있습니다. 이 두 책은 Windows PowerShell in Action(Bruce Payette 저, Manning Publications, 2007)과 Windows PowerShell: TFM(Don Jones and Jeffrey Hicks 저, SAPIEN Press, 2007)입니다. 두 권 모두 Windows PowerShell을 매우 깊이 있게 다루며 별도의 장을 할애하여 보안 문제를 설명합니다.

SQL을 이용하는 최선의 방법
BPA(Best Practices Analyzer) 및 스키마 정규화 개체에 대한 답변에서 설명한 권장 사항에 대해 동의하지 않는 부분이 있습니다(technetmagazine.com/issues/2007/05/SQLQA 참조). SQL Server™ 2005는 여전히 스키마(SQL Server 2000의 소유자와 반대의 개념. 기사 작성자는 이를 실수로 "스키마"로 지칭했음)를 확인해야 합니다. SQL Server 2005에 대한 확인 순서는 온라인 설명서(BOL)에 잘 설명되어 있습니다.
따라서 모호성 오류가 발생하지 않도록 하고 개체 이름을 확인하는 최적화 프로그램 CPU 사이클을 절약하기 위해서는 개체 정규화가 여전히 최선의 방법입니다. 칼럼에서 제시한 권장 사항은 Microsoft 백서 "Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005(SQL Server 2005의 일괄 컴파일, 재컴파일 및 캐싱 계획 문제)"의 내용에 상반됩니다.
—Mike

위 질문에 대한 답은 SQL Q&A 칼럼의 기고자이자 텍사스 주 댈러스에 있는 Microsoft Technology Center의 기술 설계자인 David Browne에게 직접 구했습니다. 그의 답변은 다음과 같습니다.
최선의 방법에 대한 의견은 사람마다 다를 수 있습니다. 특히 성능에 관해서는 주요 성능 차이를 구성하는 요소와 최적화할 수 있는 요소에 대한 인식이 사람마다 다릅니다.
예를 들어 저는 컴파일에서 최적화 프로그램 CPU 사이클을 절약하기 위해 쿼리를 특정한 방식으로 작성하는 것을 고려해 본 적이 없습니다. 이러한 방법이 실제 작업에 체감할 수 있을 정도의 차이를 주는지에 대해 의구심을 갖고 있습니다.
반면 쿼리 계획 재사용을 촉진하여 컴파일의 빈도를 줄이는 것은 널리 인정되는 성능 최적화 방법입니다.

WinPE
OS 설치에 Systems Management Server(SMS) Operating System Deployment Feature Pack(OSDFP)을 사용하고 있습니다. 이제 Windows Vista®가 출시되었기에 이 운영 체제를 OSDFP를 통해 설치하여 최신 버전으로 업그레이드하고자 합니다. 최신 OSDFP에서 제공하는 Windows PE의 버전은 무엇입니까?
이미지 설치 .iso 파일을 작성하고 이 파일을 RIS(원격 설치 서비스)에 복사했었습니다. 그런 다음 네트워크 부팅 옵션을 사용하여 새 시스템을 부트해 왔습니다. 하지만 RIS를 WIM(Windows Imaging) 파일만 부팅 이미지로 지원하는 WDS(Windows 배포 서비스)로 업그레이드했습니다. OSD의 설치 옵션을 통해 WIM 이미지를 작성하려면 어떻게 해야 합니까?
—Vasishta

Windows PE의 버전은 최신 릴리스의 OSDFP로 업데이트되지 않았으므로 여전히 버전 1.5(Windows PE 2004라고도 함)를 포함합니다. Windows PE가 업데이트되지 않았지만 Windows Vista 배포는 이제 OSDFP의 최신 릴리스에서 완전히 지원됩니다.
배포 가능한 데스크톱 이미지 작성에 사용할 수 있는 최선의 방법은 BDD(Business Desktop Deployment) Solution Accelerator를 사용하는 것입니다. 필요한 모든 구성 요소와 문서는 microsoft.com/technet/desktopdeployment/bdd/2007에서 구할 수 있습니다. 이번 호 TechNet Magazine에 Michael Niehaus가 기고한 기사 "BDD 2007을 사용한 Windows Vista 배포"도 참조하십시오.

Windows 2003 Server 포스터
TechNet Magazine 2007년 7월호를 금방 받았는데 두 장의 Windows Server® 2008 포스터가 들어 있어서 매우 기쁩니다. 제 친구는 지난 호에서 Windows 2003 Server 포스터를 받았습니다. Windows 2003 Server의 포스터를 인쇄물이나 PDF 형식으로 구할 수 있는 방법을 알려주시겠습니까?
—Jason

Windows Server 2008 포스터가 마음에 드셨다니 매우 기쁩니다. Windows Server 2003 포스터의 PDF 버전은 go.microsoft.com/fwlink/?LinkID=80428에서 온라인으로 구할 수 있습니다. Windows Server 2003 포스터는 PDF 버전 한 가지로만 제공됩니다.


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

SQL Server 데이터베이스 이동
xSQL Bundle Professional Edition
www.xsqlsoftware.com
운영 지원, 응용 프로그램 개발, 품질 보장 테스트, 구성 관리 등 전담하는 업무에 관계없이 IT 전문가라면 SQL Server™ 데이터베이스를 여기저기로 이동하는 작업이 일상화되어 있을 것입니다. TechNet Magazine을 읽고 있는 여러분도 아마 그런 IT 전문가 중 한 사람이겠지요. 이렇게 데이터와 데이터 스키마를 이동할 때에는 이동 전후의 데이터가 일치하도록 주의를 기울여야 합니다. 이동으로 인해 데이터 불일치 문제가 발생하지 않도록 하려면 스키마와 데이터를 비교하고 동기화하는 뛰어난 도구 집합이 필요합니다.
최근에 필자는 xSQL Software에서 제공하는 xSQL Bundle이라는 도구를 사용했습니다. 이 번들 소프트웨어는 xSQL Object, xSQL Data Compare 및 각각의 관련 명령줄 유틸리티, 이렇게 네 가지 응용 프로그램으로 구성되어 있습니다.
xSQL Object는 데이터베이스 스키마를 비교하고 동기화할 수 있도록 합니다. 데이터베이스 간에 비교할 개체의 유형과 인스턴스별로 다양한 비교 옵션을 제공하며 버전 기록을 유지 관리하는 데 유용한 스키마 스냅숏을 만드는 기능도 제공합니다. 이 기능을 사용하면 이전 스키마 상태로 손쉽게 롤백할 수도 있습니다. 뿐만 아니라 xSQL Object를 사용하여
데이터베이스 스키마를 전송하거나 패키지로 만들 수 있는 스키마 스크립트도 생성할 수 있습니다.
xSQL Data Compare에서는 두 개의 SQL Server 데이터베이스에 포함된 데이터가 일치하도록 동기화할 수 있습니다. 여기에서는 두 데이터베이스의 전체 내용을 비교하도록 선택하거나 비교할 테이블 집합을 선택할 수도 있습니다. 또한 테이블이 정확히 일치하지 않으면 사용자 지정 테이블 매핑을 정의하여 양쪽 테이블의 데이터가 일치하도록 할 수 있습니다. 많은 양의 데이터를 동기화할 때는 동기화 프로세스를 실행하는 데 걸리는 시간을 단축하기 위해 이 응용 프로그램이 대량 삽입 모드로 전환됩니다.
xSQL Data Compare와 xSQL Object에서는 반복적으로 비교 환경을 다시 만들지 않아도 되도록 작업 영역을 저장할 수 있습니다. 두 응용 프로그램에서는 모두 트랜잭션 동기화를 수행하므로 모든 작업을 성공적으로 커밋하거나 전체적으로 롤백할 수 있습니다. 번들에 포함된 응용 프로그램은 모두 SQL Server 2000 및 SQL Server 2005 데이터베이스 인스턴스를 지원하므로 두 버전 간에 관련 데이터와 개체를 비교하여 동기화할 수 있습니다.
xSQL Bundle에서 특히 강력한 기능으로는 사실상 모든 빌드, 프로세스, 모니터링 기능 또는 자동화된 작업 스케줄러를 통해 비교 및 동기화 작업을 실행할 수 있도록 하는 두 가지 명령줄 유틸리티를 들 수 있습니다. 개인적으로, 반복되는 작업을 자동화하는 것은 항상 업무의 편의성과 생산성에 도움이 된다고 생각합니다. 이 두 가지 명령줄 유틸리티는 주 응용 프로그램 UI에서 구성 마법사를 통해 만들 수 있는 XML 구성 파일을 사용하며, 각 유틸리티에는 다양한 텍스트 파일 로깅 옵션이 포함되어 있으므로 자동 실행되는 동안 프로세스를 추적할 수 있습니다.

가격: xSQL Bundle Professional Edition 단일 사용자 라이선스당 499달러~
두 개의 SQL Server 데이터베이스의 데이터를 동기화할 수 있는 xSQL Data Compare
두 개의 SQL Server 데이터베이스의 데이터를 동기화할 수 있는 xSQL Data Compare

보다 안전한 통신 구현
WinSSHD
www.bitvise.com
조직의 보안을 개선할 방안을 찾고 있다면 SSH2(Secure Shell Handling 2)와 SFTP(Secure FTP)를 고려해 볼 수 있습니다. 간단히 말해, SSH2 터널링은 원격 컴퓨터의 서비스에 안전하게 연결할 수 있도록 해 줍니다. 뿐만 아니라 방화벽에서 응용 프로그램에 직접 연결되는, 열려 있는 수신 포트의 수를 줄여 해커의 공격에 대한 노출 범위를 제한합니다. SFTP는 SSH2를 활용함으로써 데이터와 명령의 보안을 유지하는 기술로 표준 FTP 서버 대신 사용할 수 있습니다.
이러한 프로토콜에 관심이 있다면 Bitvise에서 제공하는 WinSSHD도 살펴볼 필요가 있습니다. WinSSHD는 Windows용으로 특별히 설계된 SSH2 서버입니다.
이 응용 프로그램은 매우 쉽게 설치할 수 있으며 WinSSHD 서비스를 관리하는 데 사용할 수 있는 사용이 쉬운 제어판도 제공합니다. 이 제어판에서는 기본적인 시작/중지 기능에서부터 WinSSHD 이벤트를 필터링할 수 있는 Windows® 이벤트 로그의 사용자 지정 보기에 이르기까지 모든 기능에 액세스할 수 있습니다. 또한 주요 설정 옵션을 구성할 수 있는 설정 패널도 이 제어판에서 실행할 수 있습니다. 여기에서 인터페이스 및 포트 바인딩을 설정하고, 로깅 구성을 수정하고, 사용할 SSH 세션 암호화 방법을 지정하고, 세션 시간 제한을 구성하고, 인증 방법을 선택하고, 프록시 구성을 지정하고, 인스턴스에 액세스할 수 있는 사용자를 제어할 수 있습니다. 또한 구성을 가져오거나 내보낼 수도 있습니다.
액세스 제어 설정에서는 서브넷 제어 마스킹 지원 기능을 활용하는 IP 규칙과 IP 규칙에 이어 처리되는 DNS 이름 규칙을 통해 액세스를 제한할 수 있습니다.
WinSSHD에서는 SFTP 구현에 더할 나위 없이 유용한 가상화를 지원합니다. 따라서 수천 명의 가상 사용자를 하나의 Windows 계정에 할당하여 계정 및 보안 설정을 단순화할 수 있습니다. 또한 이 응용 프로그램은 인증 및 액세스 제어에 Windows 그룹을 사용할 수 있도록 지원하므로 사용자별로 정책을 정의할 필요가 없습니다.
WinSSHD는 Kerberos 5 및 NTLM 인증에 대한 지원 기능을 바탕으로 Single Sign-On 환경에 통합될 수 있습니다. 이러한 작업을 수행하려면 Bitvise에서 제공하는 또 하나의 뛰어난 제품인 Tunnelier와 같은 GSSAPI 지원 SSH 클라이언트가 필요합니다. 물론 Tunnelier는 WinSSHD 서버와 완벽하게 호환되며, WinSSHD 서버를 원격으로 구성하는 데에도 사용할 수 있습니다.
SFTP 또는 SSH2 서버 환경이 업무 수행에 필수적이라면 WinSSHD를 클러스터링하여 고가용성을 확보할 수 있습니다. 이는 매우 간단한 작업이지만 도움이 필요한 경우 Bitvise의 웹 사이트에서 클러스터링 설치, 포트 전달, 원격 데스크톱 터널링 등에 대한 정보와 구성 지침을 참조할 수 있습니다.

가격: 99.95달러
SSH 세션 암호화 방법을 지정할 수 있는 WinSSHD
SSH 세션 암호화 방법을 지정할 수 있는 WinSSHD

USB 작동 모니터링
USB Monitor Professional
www.hhdsoftware.com
이제 모든 사용자에게 유용한 제품을 하나 소개하겠습니다. 여러분 중에는 USB 장치 드라이버를 만들거나 수정하기를 즐기는 DIY 소프트웨어 애호가도 있으리라 믿습니다. 아니면 실제로 USB 장치를 만드는 하드웨어 엔지니어도 있을 것입니다. 또는 USB 장치의 작동 표시등을 바라보면서 장치에서 왜 이렇게 많은 작업이 이루어지는지를 궁금해 하는 초보자들도 있을 것입니다. 이 중 어떠한 경우든 HHD Software에서 제공하는 USB Monitor Professional이 여러분에게 도움이 될 수 있습니다. 이 유틸리티를 사용하면 USB 호스트 컨트롤러를 통해 USB 장치와 Windows 기반 시스템 간에 전송되는 데이터를 기록, 표시 및 분석할 수 있습니다.
UI가 다소 복잡하긴 하지만 익숙해지고 나면 모니터링하는 USB 장치에서 주고받는 데이터에 대해 막대한 양의 정보를 얻을 수 있습니다. 이 응용 프로그램은 기본적으로 USB 장치로 전달되는 명령과 명령 집합 대부분을 기록합니다. 대용량 저장소와 같은 일부 장치의 경우 정보가 너무 방대할 수 있습니다. 다행히도 이러한 경우 응용 프로그램에서 대용량 저장 장치에 대해 기록할 데이터를 사용자 지정할 수 있습니다.
세션을 기록한 후에는 다양한 방법으로 데이터를 분석할 수 있습니다. 대용량 저장 장치의 경우 Mass Storage View가 표시됩니다. 통계 및 장치 처리량에 대한 선형 그래프, 원시 패킷 및 제어 요청 보기, 데이터 패킷 디코더 보기, HID 전용 보기, 지원되는 장치에서 사용할 수 있도록 USB Still Image 프로토콜을 디코딩하는 Still Image View 등을 표시하는 옵션도 있습니다.
이 응용 프로그램에서 기록되는 데이터의 양이 방대하기 때문에 USB 기록 세션을 너무 오래 실행 상태로 두어서는 안 됩니다. 그러나 활성 기록 세션에 허용되는 최대 디스크 공간을 제한하고 기록되는 데이터를 압축하여 필요한 공간을 줄일 수도 있습니다.

가격: 일반 라이선스 175.99달러~
USB 장치에 전달되는 명령을 기록하는 USB Monitor Professional
USB 장치에 전달되는 명령을 기록하는 USB Monitor Professional

가상 미디어 관리
Virtual CloneDrive
www.elby.ch/fun/software
실제 미디어를 관리하는 것은 매우 까다로운 작업일 수 있습니다. 운영 체제를 Windows Vista로 바꾸면서 Microsoft Virtual CD-ROM Control Panel이 호환되지 않게 된 후부터 필자는 CD 및 DVD 이미지를 탑재할 수 있는 대안을 찾고 있었습니다. 관심 있는 독자를 위해 소개하자면 Windows XP용 Microsoft® Virtual CD-ROM Control Panel은 go.microsoft.com/fwlink/?LinkId=94801에서 다운로드할 수 있습니다.
물론 Windows Vista에서 Virtual CD-ROM Control Panel을 실행할 수는 있지만 항상 관리자로 실행해야 하고 관리자 컨텍스트에서만 탑재된 드라이브를 볼 수 있다는 것이 문제입니다. 즉, 관리자 권한으로 실행 명령 프롬프트를 통해서는 탑재된 드라이브가 표시되지만 사용자의 Windows 탐색기 컨텍스트에서는 표시되지 않습니다. 결과적으로 도구가 원하는 대로 작동하지 않을 뿐만 아니라 보안 수준이 낮은 환경에서 응용 프로그램을 실행할 수 밖에 없습니다.
Windows Vista 사용자 컨텍스트에서도 정상적으로 작동하는 도구로,
Elaborate Bytes에서 제공하는 Virtual CloneDrive가
있습니다. 이 응용 프로그램은 장치 관리자에 표시되는 GUI 관리 응용 프로그램 및 저장소 컨트롤러로
설치되며, 설치된 후에는 세 가지 기본 설정을 제공합니다. 첫째,
사용할 가상 드라이브의 수를 지정할 수 있습니다. 이때 드라이브는 병렬로 최대 8개까지 지정할 수 있습니다. 둘째, 제가 가장 좋아하는 옵션 중 하나로 ISO 드라이브와 시스템의 실제 드라이브를 구분할 수 있도록 표준 CD/DVD 드라이브 아이콘을 화난 양 모양으로 바꾸는 Virtual Sheep을 설정하도록 선택할 수 있습니다. 마지막으로, 시작 시에 해당 가상 드라이브에 마지막으로 할당한 이미지를 자동 탑재하도록 선택할 수 있습니다.
Virtual CloneDrive에서는 ISO 파일뿐만 아니라 .ccd, .dvd, .img, .udf 및 .bin 파일도 탑재하고 읽을 수 있습니다. 또한 Windows 탐색기에 통합되므로 신속하게 이미지를 탑재 또는 분리할 수 있습니다. Virtual CloneDrive의 가장 큰 장점은 무료라는 점입니다. Windows Vista®로 바꾼 후 ISO 파일을 관리할 수 있는 새로운 솔루션을 찾고 있다면 이 도구를 고려해 보시기 바랍니다.

가격: 무료
Virtual CloneDrive의 화난 양 모양 아이콘
Virtual CloneDrive의 화난 양 모양 아이콘

서평
SharePoint Products and Technologies Administrator's Pocket Consultant
microsoft.com/MSPress/books/10623.aspx
최근에는 사무실에 종이 문서는 사라지고 점차 처리해야 할 전자 문서가 많아지고 있습니다. 이러한 전자 문서 자체와 문서의 공유 방법을 관리하는 것이 점점 더 중요한 문제로 대두되면서 Microsoft SharePoint® Services 및 SharePoint Server를 이에 대한 솔루션으로 고려하는 회사가 늘고 있습니다. Ben Curry의 Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant를 읽으면 많은 도움을 얻을 수 있습니다. 단순히 SharePoint를 고려하고 있는 경우든, 계획 단계가 상당히 진척된 경우든, 아니면 이미 SharePoint 인프라가 구축된 경우든, 이 책은 관리 기능 및 일상 업무에 유용한 참고 자료가 될 수 있습니다.
Administrator's Pocket Consultant 시리즈를 이미 읽은 독자라면 이 책도 상당히 친근하게 느껴질 것입니다. 내용의 수준이나 구성이 다른 시리즈와 동일하기 때문입니다. 이 책은 Windows SharePoint Services 3.0, SharePoint Server 2007 Standard 및 SharePoint Server 2007 Enterprise Edition에 대해 다루며, 4개의 섹션으로 이루어져 있습니다.
첫 번째 섹션인 "SharePoint Products and Technologies Fundamentals"에서는 SharePoint Server 제품의 구성 요소, 버전, 요구 사항 및 설치와 관련한 개요를 볼 수 있습니다. 이 섹션에서는 Windows SharePoint Services 3.0과 SharePoint Server Standard 및 Enterprise 버전과의 차이점에 대해 설명하고 각 제품의 설치 과정을 안내합니다. 또한 설치 프로세스 동안 만들어지는 SQL Server 데이터베이스 및 IIS 웹 사이트에 대해서도 자세히 설명합니다.
다음 섹션인 "SharePoint Core Administration"에서는 중앙 관리 UI에 대해 다루고, 새로운 사이트 컬렉션 및 사이트를 만드는 방법, 웹 파트 가져오기, 사용 및 편집 방법, 설치를 위한 그룹 및 전자 메일 설정을 구성하는 방법 등에 대한 참조 정보를 제공합니다. 뿐만 아니라 여러 가지 워크플로 기능을 관리하고 이러한 워크플로를 모니터링하는 방법에 대해서도 설명합니다.
세 번째 섹션인 "Working with SharePoint Server 2007"에서는 SharePoint Server Standard 및 Enterprise 버전의 고유한 기능을 심도 있게 살펴봅니다. 즉, 엔터프라이즈 콘텐츠 관리 구성 방법, SharePoint 포털 생성 및 구성 방법, 검색 및 인덱싱 설정 방법, Excel® 계산 서비스 구성 방법 등을 다룹니다. 특히 Excel 계산 서비스 부분에서는 다중 서버 환경에서 성능 및 가용성을 높이도록 서비스를 구성하는 방법도 소개합니다.
네 번째 섹션에서는 SharePoint Server 구현의 운영 측면을 자세히 조명하면서 SharePoint Server 2007을 서버 팜으로 확장하는 방법과 SharePoint Server 구현에 대해 가능한 여러 가지 구성을 소개합니다. 마지막으로 이 책에서는 백업 및 복원 작업과 관련한 기본 사항을 소개하고 성능 분석 방법과 SharePoint Server의 로깅 기능을 사용하여 사이트를 유지 관리하고 개선하는 방법을 설명합니다.
책 표지에는 관리자를 위한 일상 업무 참조용이라고 명시되어 있지만 계획 단계에 있는 독자나 단순히 SharePoint에 대해 궁금해 하는 독자들도 SharePoint를 빠르고 쉽게 이해하는 데 유용한 자료가 되리라 생각합니다. 이 책은 여러 가지 SharePoint 기술과 각각의 기능을 자세히 소개하는 매우 기본적인 내용으로 시작하여 Excel 계산 서비스 구성, 서버 팜 확장 등 점점 더 복잡한 주제로 넘어가도록 구성되어 있으므로 SharePoint 기술을 처음 접하는 독자뿐만 아니라 기본 지식을 갖춘 독자 모두에게 유용한 자료로 활용될 수 있습니다.

가격: 29.99달러

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


 SQL Q&amp;A: CPU 병목 현상, 데이터베이스 복원과 이동 및 추가 정보
SQL Q&A
CPU 병목 현상, 데이터베이스 복원과 이동 및 추가 정보
편집자: Nancy Michell

Q: SQL Server™의 CPU 사용량이 갑자기 늘어나기 시작했습니다. 새로운 사용자를 추가하거나 하드웨어가 다운되거나 새 테이블이 만들어진 것도 아닌데요. 왜 그런 것이지요?

팁: 인덱스 생성 중 액세스
시간이 많이 걸리는 대형 테이블에 대한 인덱스 생성 작업을 수행하려고 하는데 이 프로세스를 수행하는 동안 데이터를 사용해야 하는 경우가 있습니다. 어떻게 하면 두 가지 목표를 모두 달성할 수 있을까요?
클러스터형 인덱스를 만들거나 삭제하거나 다시 만들 때마다 SQL Server에서는 테이블에 대해 스키마 수정(SCH-M) 잠금을 설정하여 작업이 수행되는 동안 어떤 사용자도 기본 데이터에 액세스할 수 없게 만듭니다. 테이블에 대한 클러스터형 인덱스를 만드는 경우가 여기에 해당합니다. 반면 열에 대한 비클러스터형 인덱스를 만들 때는 SQL Server에서 테이블에 대한 공유(S) 잠금을 설정합니다. 이때도 기본 테이블의 데이터를 업데이트할 수는 없지만 SELECT 문을 실행하여 데이터를 읽을 수는 있습니다.
클러스터형 인덱스를 만드는 동안 테이블을 읽어야 하는 경우에는 테이블에 대한 인덱스를 만들어 온라인 작업으로 전환할 수 있습니다. 이 작업을 수행하는 명령은 다음과 같습니다.
CREATE UNIQUE CLUSTERED INDEX CLUST_IDX_SQLTIPS
ON SQLTips (tip) with (ONLINE=ON) Go;
테이블에 대해 온라인 인덱스 작업을 사용하는 경우에도 SQL Server에서 클러스터형 인덱스에 대해 SCH-M 잠금을 설정하고 기본 테이블에 대한 비클러스터형 인덱스에 대해서는 공유(S) 잠금을 설정합니다. 하지만 인덱스 작업이 시작될 때와 끝날 때만 이러한 잠금을 설정하므로 그 시간이 매우 짧습니다. 따라서 이 옵션을 사용하면 인덱스를 생성하는 동안 기본 테이블을 보다 쉽게 쿼리하고 테이블에 액세스할 수 있습니다. 온라인 인덱스 생성/작업은 SQL Server 2005 Enterprise Edition에서만 사용할 수 있습니다.

A: 서버의 로드가 추가되거나 어떤 것도 변경되지 않았는데 예기치 않게 갑자기 CPU 병목 현상이 발생하는 경우 근본적으로 몇 가지 이유가 있을 수 있지만 일반적으로는 쿼리 계획이 최적이 아니거나 SQL 서버 구성에 문제가 있거나 응용 프로그램/데이터베이스의 설계가 적절하지 않거나 하드웨어 리소스가 부족한 데서 원인을 찾을 수 있습니다.
이와 같은 상황이 발생하면 가장 먼저 서버가 CPU 바인딩 서버인지 확인하고 그럴 경우 로컬 SQL Server 시스템에서 CPU를 가장 많이 사용하는 문을 알아내야 합니다. 서버가 CPU 바인딩 서버인지는 성능 모니터를 실행하고 PROCESSOR:% PROCESSOR TIME 카운터를 보고 확인할 수 있습니다. CPU당 사용된 시간 값이 75%와 같거나 그 이상인 경우 CPU 병목 현상이 있음을 나타냅니다.
SYS.DM_OS_SCHEDULERS라는 시스템 DMV(동적 관리 뷰)를 쿼리하여 실행 가능 작업의 값을 확인함으로써 SQL Server 스케줄러도 모니터링해야 합니다. 0이 아닌 값은 작업이 실행되려면 얼마 동안 대기해야 함을 나타냅니다. 이 카운터의 값이 높은 경우 이것도 CPU 병목 현상이 있음을 나타냅니다.
다음 쿼리를 사용하여 스케줄러를 모두 표시하고 실행 가능 작업의 수를 검토할 수 있습니다.
SELECT
 Scheduler_ID,
 Current_Tasks_Count,
 Runnable_Tasks_Count
FROM
 SYS.DM_OS_SCHEDULERS
WHERE
 Scheduler_ID < 255
CPU를 많이 사용하는 상위 50개의 SQL 문을 보려면 그림 1에 나오는 쿼리를 사용합니다.
Figure 1 CPU를 많이 사용하는 상위 50개 항목 (Close Figure 1)
SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
 Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
 Total_Physical_Reads,
 SUBSTRING(b.text,a.statement_start_offset/2,
 (case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
 else
 a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
 dbname=Upper(db_name(b.dbid)),
 b.objectid AS 'Object_ID'
 FROM sys.dm_exec_query_stats a
 CROSS APPLY
 sys.dm_exec_sql_text(a.sql_handle) AS b
 ORDER BY
 [Avg_CPU_Time] DESC

Q: 테이프에서 SQL Server 2005 데이터베이스를 복구해야 했습니다. 복원을 수행한 후 데이터베이스에 대해 사용자에게 부여되어 있었던 대부분의 사용 권한이 없어졌습니다. 복원 중 무엇이 잘못되었는지 알 수 있을까요? 데이터에는 문제가 없는데 사용 권한이 엉망이 되었습니다.

A: 아마도 마스터 데이터베이스를 동일한 시점으로 복원하지 않았고 사용자 데이터베이스의 로그인 ID가 현재 마스터 데이터베이스와 일치하지 않기 때문일 것입니다. 이들을 동기화해야 합니다. "데이터베이스 이동 시 유용한 도움말을 제공하는 리소스" 추가 기사에는 데이터베이스를 복원하거나 이동할 때 발생하는 문제의 원인을 찾는 데 도움이 되는 리소스가 나와 있습니다.

Q: SQL Server 2005 SP1의 OpenXML을 통해 XML 데이터를 여러 조각으로 나눠 관계형 테이블로 가져오는 저장 프로시저를 사용하여 응용 프로그램을 하나 개발했습니다. XML 문서의 크기는 큰 것이 5KB이고 평균 크기는 2.5KB입니다. 저장 프로시저는 병렬로 최대 50번까지 호출됩니다.
그런데 심각한 잠금 경합 문제가 발생했습니다. OpenXML 때문인 것 같은데,. 어떻게 해야 할까요?

A: OpenXML은 노드를 이용할 때보다 단일 스레드에서 데이터를 여러 조각으로 나누거나 변환하는 속도가 빠르지만 일반적으로 노드를 이용할 경우, 특히 노드를 병렬로 사용할 경우 확장 성능이 보다 우수합니다. 그럼에도 불구하고 OpenXML을 사용하려는 경우에는 다음 지침에 따라 전반적인 OpenXML 성능을 개선해야 합니다.
앞에서 언급한 방법, 즉 동일한 행 패턴을 사용하여 OpenXML을 다섯 번 호출하는 방법 대신 행 패턴이 동일한 모든 데이터를 임시 테이블에 추출한 다음 임시 테이블에서 데이터를 선택하도록 해야 합니다. 가능하면 일찍 sp_xml_removedocument를 사용하여 메모리를 해제해 보십시오. * 및 //와 같은 와일드카드는 되도록 사용하지 않는 것도 좋은 방법입니다. 명시적 경로를 제공하면 쿼리 성능이 향상됩니다.

Q: 서버에서 DBCC SHRINKFILE을 실행하면 속도가 정말로 느립니다. 다중 프로세서 시스템을 사용하면 성능이 좋아질까요? 이 문제를 해결하려면 어떻게 해야 할까요?

A: DBCC SHRINKFILE은 단일 스레드에서 수행되는 작업이므로 여러 개의 CPU를 사용하지 않습니다. DBCC SHRINKFILE은 한 번에 한 페이지씩 파일의 맨 뒤에서 파일의 맨 앞으로 페이지를 이동합니다. 또한 소위 말하는 축소는 대부분의 경우에는 조각 모음을 수행하는 것이 아니라 논리적 조각화를 늘립니다.
축소 성능을 개선하는 방법 중 하나는 클러스터형 인덱스에서 페이지를 이동하는 것입니다. 힙이 여러 개 있고 힙에 비클러스터형 인덱스가 많은 경우 클러스터형 인덱스에 비해 속도가 눈에 띄게 느려집니다.
또한 LOB(Large Object Blob) 데이터의 경우 LOB 데이터의 루트를 찾기 위해 행 내부 데이터를 읽어야 하므로 페이지 이동 속도가 느립니다.
대부분의 인덱스/테이블 내용은 파일의 끝에 상주하므로 파일의 맨 앞으로 이동하기 위해 인덱스를 다시 만들 수 있습니다. 인덱스를 다시 만드는 작업의 경우 여러 개의 CPU를 사용하므로 bulk_logged 모드에서 작업을 수행할 경우 사용되는 로그 공간을 줄일 수 있습니다. 그런 다음 축소를 실행하면 속도가 훨씬 빠릅니다.
축소 작업에 대한 자세한 내용을 보려면 blogs.msdn.com/sqlserverstorageengine/archive/2007/03/29/how-does-your-schema-affect-your-shrink-run-time.aspx와 blogs.msdn.com/sql-serverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx의 항목부터 읽어보십시오.
데이터베이스 이동 시 유용한 도움말을 제공하는 리소스
  • SQL Server를 실행하는 컴퓨터 간에 데이터베이스를 이동하는 방법
  • INF: 분리/연결(Detach/Attach)을 사용하여 새 위치로 SQL Server 데이터베이스 이동
  • INF: RESTORE 문에서 WITH MOVE 옵션 사용
  • SQL Server를 실행하는 서버 사이에서 데이터베이스를 이동할 때 사용 권한 문제를 해결하는 방법
  • INF: SQL Server 인스턴스 간에 로그인 및 암호를 전송하는 방법
  • INF: SQL Server 2000의 데이터베이스 복사 마법사 이해 및 문제 해결
  • 데이터베이스 복원 후 데이터베이스에 대한 사용자 로그온 및 사용 권한이 올바르지 않을 수 있다
  • 다른 SQL Server 빌드에는 시스템 데이터베이스 백업을 복원할 수 없다
  • SQL Server의 데이터베이스 백업 또는 트랜잭션 로그 백업에서 특정 테이블 또는 행을 검색하는 방법

팁: 포트 변경
SQL Server에 친숙한 사용자라면 누구나 SQL Server의 기본 수신 포트 번호가 1433이라는 것을 잘 알 것입니다. SQL Server의 명명된 인스턴스는 동적 포트를 사용하도록 구성되지만, 즉 SQL Server 인스턴스가 시작될 때마다 사용 가능한 포트 중 아무 것이나 선택할 수 있지만 기본 SQL Server 인스턴스는 항상 포트 1433에서 수신합니다. 따라서 기본 포트에서 수신하는 서버에 보안 대비책이 충분히 마련되어 있지 않으면 서버가 위험에 노출될 수 있습니다. 기본 포트를 변경하여 공격을 막을 수 있습니다. 방법은 다음과 같습니다.
SQL Server 구성 관리자를 열고 SQL Server 2005 네트워크 구성과 프로토콜을 차례로 확장합니다. TCP/IP를 두 번 클릭합니다. 그러면 아래의 차트에 TCP/IP 속성 및 해당되는 기능 목록이 표시됩니다. 차트를 참조하여 적절하게 설정합니다.
SQL Server 데이터베이스 엔진의 경우 한 IP 주소가 여러 포트에서 수신할 수 있으므로 사용할 포트를 1433,1500,1501 형식과 같이 쉼표로 구분하여 지정합니다. 단일 IP 주소가 여러 포트에서 수신하도록 구성하려면 TCP/IP 속성 대화 상자의 프로토콜 탭에서 '모두 수신합니다.' 매개 변수도 아니요로 설정해야 합니다.
이제 각 주소를 마우스 오른쪽 단추로 클릭하고 속성을 클릭하여 구성할 IP 주소를 확인합니다. TCP 동적 포트 대화 상자에 데이터베이스 엔진이 동적 포트에서 수신하고 있음을 나타내는 0이 있으면 0을 삭제합니다. IP 속성 영역의 TCP 포트 상자에서 이 IP 주소가 수신하도록 할 포트 번호를 입력하고 확인을 클릭합니다. 콘솔 창에서 SQL Server 2005 서비스를 클릭하고 세부 정보 창에서 SQL Server(<instance name>)를 마우스 오른쪽 단추로 클릭한 다음 다시 시작을 클릭하여 SQL Server를 중지한 후 다시 시작합니다.
특정 포트에서 수신하도록 SQL Server를 구성한 후에는 세 가지 방법 중 하나로 클라이언트가 해당 포트에 연결하도록 설정할 수 있습니다. 서버에서 SQL Server Browser 서비스를 실행하여 이름을 기준으로 데이터베이스 엔진 인스턴스에 연결하거나, 포트 번호를 지정하여 클라이언트에 별칭을 만들거나, 사용자 지정 연결 문자열을 사용하여 연결하도록 클라이언트를 프로그래밍할 수 있습니다.

속성 | 설명
활성 | SQL Server가 지정된 포트에서 수신하고 있음을 나타냅니다. IPAll에는 사용할 수 없습니다.
사용 | 이 연결을 사용하거나 사용하지 않도록 설정합니다. IPAll에는 사용할 수 없습니다.
IP 주소 | 이 연결에 사용된 IP 주소를 보거나 변경합니다. 컴퓨터에 사용된 IP 주소와 IP 루프백 주소 127.0.0.1을 표시합니다. IPAll에는 사용할 수 없습니다.
TCP 동적 포트 | 동적 포트를 사용하지 않는 경우에는 비어 있습니다. 동적 포트를 사용하려면 0으로 설정합니다.
TCP 포트 | SQL Server가 수신하는 포트를 보거나 변경합니다. 기본적으로 기본 인스턴스는 포트 1433에서 수신합니다. 이 필드에는 최대 2047자까지 입력할 수 있습니다.

이 달의 질문과 답변 문서를 작성하는 데 도움을 주신 분들: Chad Boyd, Cindy Gross, John Hadden, Saleem Hakani, Stephen Jiang, Mahesh Nayak, Paul Randal과 Wayne Yu


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

일반적인 Windows® 조각 모음을 사용하면 하드 드라이브에 있는 대부분의 파일을 최적화할 수 있지만 일반적인 조각 모음 도구로는 처리할 수 없는 일부 항목이 있습니다. Windows 페이지 파일과 레지스트리 하이브처럼 열려 있거나 단독 사용을 위해 잠긴 파일은 일반적으로 Windows 기본 조각 모음이나 타사 유틸리티로는 처리되지 않습니다. 표준 Windows API는 이러한 파일이 사용 중일 경우 해당 파일의 조각 모음을 지원하지 않습니다. 다행히도 Sysinternals의 Mark Russinovich가 만든 PageDefrag 유틸리티를 사용하면 다른 도구로는 처리할 수 없는 항목에 대해 조각 모음을 수행할 수 있습니다.
PageDefrag는 Windows 페이지 파일, 레지스트리 하이브, 이벤트 로그 및 최대 절전 모드 파일(노트북이 최대 절전 모드로 전환될 때 메모리가 저장되는 디스크 영역)에 대해 조각 모음을 수행할 수 있습니다. 이 프로그램은 이러한 파일이 사용되기 전에 PC가 부팅되는 동안 최적화합니다.
PageDefrag를 실행하려면 pagedfrg.exe 파일을 두 번 클릭합니다. 그러면 조각 모음을 수행할 수 있는 각 대상 파일의 이름이 표시됩니다(그림 1 참조). 페이지 파일은 pagefile.sys입니다. 레지스트리 하이브는 DEFAULT, SAM, SECURITY, SOFTWARE 및 SYSTEM처럼 각 하이브마다 개별 파일로 나타납니다. 이벤트 로그도 개별 파일로 표시됩니다. 예를 들어 AppEvent.evt는 응용 프로그램 로그이고, SecEvent.evt는 보안 로그이며, SysEvent.evt는 시스템 로그입니다. 마지막으로, 최대 절전 모드 파일은 Hiberfil.sys입니다.
그림 1 처리할 수 있는 각 파일의 이름을 표시하는 PageDefrag
그림 1 처리할 수 있는 각 파일의 이름을 표시하는 PageDefrag
각 파일 이름 옆의 Clusters 열에는 파일에 할당된 디스크 클러스터의 수가 표시되고, Fragments 열에는 디스크에서 분산되어 있는 파일 조각이나 인접하지 않은 파일 조각의 수가 표시됩니다. 이 데이터를 기준으로 파일 조각 모음이 필요한지 여부를 결정할 수 있습니다.
다음 번에 부팅할 때 조각 모음을 수행하거나 부팅할 때마다 조각 모음을 수행하는 두 가지 옵션이 있습니다. 파일을 매우 많이 사용하거나 다시 부팅을 거의 하지 않는 서버 또는 기타 시스템인 경우를 제외하고는 다음 번에 부팅할 때 조각 모음을 수행하도록 선택하는 것이 좋습니다. 또한 PC가 시작될 때 카운트다운이 시작되도록 하여 조각 모음을 취소할 시간을 마련할 수도 있습니다.
다음 번에 컴퓨터를 다시 부팅하면 일반적인 chkdsk 명령이 실행된 다음 PageDefrag가 실행되어, 이미 인접한 클러스터로 정리된 파일은 건너뛰고 조각화된 파일은 하나씩 최적화합니다. PageDefrag는 조각 모음 중인 각 항목의 이름을 표시하고, 조각 모음 성공 여부를 알리며, 조각 모음 이전과 이후에 파일에 할당된 클러스터 수를 나열합니다.
PC의 빈 디스크 공간이 부족하거나 빈 디스크 공간 자체도 조각화된 경우에는 PageDefrag가 파일을 최적화하지 못할 수 있습니다. 이 경우 디스크 공간을 더 많이 확보하고 Windows의 조각 모음 도구를 실행하여 빈 공간을 최적화한 다음 PageDefrag를 다시 실행해야 합니다.
PageDefrag는 적은 수의 파일만 처리하므로 일반적으로 빠르게 실행됩니다. 하지만 파일의 조각화 정도가 심한 경우에는 처음 실행할 때 완료하는 데 시간이 더 걸릴 수 있습니다. PageDefrag 작업이 끝나면 Windows가 로드됩니다. 그러면 PageDefrag를 다시 열고 각 파일이 이제 하나의 조각으로 정리되어 있는지 확인할 수 있습니다.
PageDefrag는 명령줄을 통해 또는 pagedfrg.exe 파일에 -e(부팅 시 조각 모음), -o(한 번 조각 모음), -n(조각 모음 안 함) 및 -t(지정된 시간(단위: 초) 동안 카운트다운) 옵션을 사용하여 스크립트를 통해 비대화형 방식으로 실행할 수 있습니다.
이 유틸리티에 대한 자세한 내용을 확인하고 이 도구를 다운로드하려면 microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx를 참조하시기 바랍니다.

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


 The Cable Guy: 강력한 호스트 모델 및 취약한 호스트 모델
The Cable Guy
강력한 호스트 모델 및 취약한 호스트 모델
Joseph Davies

네트워크 인터페이스가 여러 개인 멀티홈 호스트 모델은 갈수록 보편화되고 있는 네트워크 호스트 구성입니다. 멀티홈 호스트는 인트라넷이나 인터넷과 같은 여러 네트워크에 동시에 연결함으로써 연결 성능을 개선합니다. 그러나 멀티홈 호스트에서 실행되는 서비스는
인트라넷과 인터넷에 모두 연결될 수 있으므로 공격을 받기가 쉽습니다. 이러한 공격을 방지하는 데 도움이 되도록, 그리고 멀티홈 호스트에 대한 IP 트래픽이 처리되는 방법을 쉽게 이해할 수 있도록 이 문서에서는 먼저 멀티홈 호스트의 취약한 모델과 강력한 모델을 비교해서 살펴보고 그런 다음 Windows®에서 이러한 모델을 지원하는 방법을 설명하겠습니다.
RFC 1122는 라우터 역할은 하지 않고 유니캐스트 IP 트래픽을 보내고 받기만 하는 두 가지 멀티홈 호스트 모델에 대해 설명하는 사양입니다. 강력한 호스트와 취약한 호스트라고 하는 두 모델은 보내고 받는 유니캐스트 트래픽을 트래픽이 경유하는 네트워크 인터페이스와 연결할지 여부를 정합니다. 이 두 모델은 호스트가 패킷을 보내고 받는 방식을 결정하며 호스트에서 실행되는 서비스의 취약성에 영향을 줍니다.
RFC 1122에서는 IPv4용으로 두 모델을 정의했지만 IPv6에도 적용됩니다. IPv6용 멀티홈 호스트의 예로는 인트라넷과 IPv6 터널링 인터페이스에 연결되는 네트워크 어댑터가 있으며 IPv4와 IPv6을 모두 사용하는 컴퓨터를 들 수 있습니다.

취약한 호스트 모델
취약한 호스트 모델에서는 IP 호스트(IPv4 또는 IPv6)가 보내는 패킷의 원본 IP 주소가 할당되지 않은 인터페이스에서 패킷을 보낼 수 있습니다. 이를 취약한 호스트 보내기 동작이라고 합니다. IP 호스트는 받는 패킷의 대상 IP 주소가 할당되지 않은 인터페이스에서 패킷을 받을 수도 있습니다. 이를 취약한 호스트 받기 동작이라고 합니다.
인터페이스가 여러 개 있는 멀티홈 IP 호스트를 사용하는 경우 인터페이스에서 취약한 호스트 받기 동작을 사용하면 호스트가 멀티홈 공격에 취약해질 수 있습니다. 예를 들어 그림 1에서는 인터넷과 인트라넷에 모두 연결된 호스트 A를 보여 줍니다. 호스트 A의 인터넷 인터페이스에는 공용 IPv4 주소 131.107.89.211이 할당되어 있고 인트라넷 인터페이스에는 개인 주소 192.168.17.48이 할당되어 있습니다.
그림 1 멀티홈 컴퓨터의 예
그림 1 멀티홈 컴퓨터의 예
인터넷 및 인트라넷 인터페이스 모두에서 취약한 호스트 보내기 동작을 사용하는 경우 호스트 A는 인터넷 인터페이스의 131.107.89.211, 인터넷 인터페이스의 192.168.17.48, 인트라넷 인터페이스의 131.107.89.211, 그리고 인트라넷 인터페이스의 192.168.17.48에서 패킷을 보낼 수 있습니다.
취약한 호스트 받기 동작을 사용하는 경우, 호스트 A는 인터넷 인터페이스의 131.107.89.211로 들어오는 패킷, 인터넷 인터페이스의 192.168.17.48로 들어오는 패킷, 인트라넷 인터페이스의 131.107.89.211로 들어오는 패킷, 그리고 인트라넷 인터페이스의 192.168.17.48로 들어오는 패킷을 받을 수 있습니다. 단, 이때는 들어오는 트래픽을 허용하도록 방화벽 규칙이 구성되어 있다고 가정합니다.
취약한 호스트 받기 동작을 사용하는 경우 인터넷의 악의적 사용자가 호스트 A의 인터넷 인터페이스로 패킷을 보내 호스트 A에서 실행되며 인트라넷의 호스트만 사용해야 하는 서비스를 공격할 수 있습니다. 이러한 종류의 공격은 192.168.17.48로 보내는 패킷을 호스트 A의 인터넷 인터페이스로 전달하도록 지원하는 인터넷 인프라에서 발생할 수 있습니다. 호스트 A의 인터넷 인터페이스에 적절한 방화벽 규칙을 설정하여 이러한 종류의 공격을 방지할 수 있습니다. 하지만 이렇게 하더라도 호스트 A에서 실행되며 인트라넷 클라이언트가 사용하는 서비스가 위험에서 완전히 벗어나는 것은 아닙니다.

강력한 호스트 모델
강력한 호스트 모델에서는 보내기 동작과 받기 동작이 각기 다릅니다. 강력한 호스트 보내기 동작을 사용하는 경우 보내는 패킷의 원본 IP 주소가 인터페이스에 할당된 경우에만 호스트가 해당 인터페이스에서 패킷을 보낼 수 있습니다. 강력한 호스트 받기 동작을 사용하는 경우에는 받는 패킷의 대상 IP 주소가 인터페이스에 할당된 경우에만 호스트가 해당 인터페이스에서 패킷을 받을 수 있습니다.
그림 1의 호스트 A는 인터넷 및 인트라넷 인터페이스에서 강력한 호스트 보내기 동작을 사용하므로 인터넷 인터페이스의 131.107.89.211과 인트라넷 인터페이스의 192.168.17.48에서만 패킷을 보낼 수 있습니다.
또한 호스트 A는 강력한 호스트 받기 동작을 사용하므로 인터넷 인터페이스의 131.107.89.211로 들어오는 패킷과 인트라넷 인터페이스의 192.168.17.48로 들어오는 패킷만 받을 수 있습니다.
그림 1에 나오는 호스트 A의 강력한 호스트 모델은 사용자가 방화벽 규칙을 별도로 구성하지 않아도 192.168.17.48 주소가 할당된 인터넷 인터페이스로 들어오는 모든 패킷을 삭제하여 호스트 A의 인트라넷 인터페이스를 인터넷과 격리시킵니다.
강력한 호스트 모델을 선택하는 경우 취약한 호스트 동작에 맞게 설계된 일부 연결 유형이 영향을 받을 수도 있습니다. 예를 들어 일부 부하 분산 구현에서는 취약한 호스트 받기 동작을 사용하여 임의의 인터페이스에서 패킷을 받은 다음 내부에서 이를 적절한 인터페이스로 라우팅할 수도 있습니다. 취약한 호스트 보내기를 사용하여 고속 연결용 인터페이스의 원본 주소에서 트래픽을 보내는 호스트도 영향을 받을 수 있습니다.

강력한 호스트 보내기 및 받기
지금부터는 인터페이스별로 강력한 호스트 보내기 및 받기를 사용하거나 사용하지 않도록 설정한 경우, IPv4 또는 IPv6용 일반 호스트에서 보내기 및 받기 프로세스가 어떤 방식으로 작동하는지에 대해 살펴보겠습니다.
보내는 패킷의 경우 IP가 먼저 원본 주소가 이미 지정되었는지 여부를 확인합니다. 주소가 지정되어 있지 않으면 IP가 라우팅 테이블에서 패킷의 대상 주소를 무제한 조회합니다. 무제한 조회의 경우 라우팅 테이블의 모든 라우터를 조회합니다. 대상에 선택된 경로를 기준으로 IP는 다음 홉 인터페이스(패킷을 링크 계층에 놓는 데 사용되는 인터페이스)와 다음 홉 주소를 결정합니다. 다음 홉 인터페이스를 기준으로 IP는 RFC 3484에 정의된 주소 선택 프로세스에 따라 가장 적합한 원본 주소를 결정합니다. 이제 IP는 패킷을 보내는 데 필요한 원본 및 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다.
원본 주소가 지정되어 있는 경우에는 원본 인터페이스를 알 수 있습니다. 원본 인터페이스에는 원본 주소가 할당됩니다. 이제 IP가 원본 인터페이스에서 강력한 호스트 보내기를 사용하는지 여부를 확인합니다.
강력한 호스트 보내기를 사용하지 않는 경우 IP는 라우팅 테이블에서 패킷의 대상 주소를 무제한 조회합니다. 찾은 경로 중 대상에 가장 적합한 경로를 기준으로 IP는 다음 홉 인터페이스와 다음 홉 주소를 결정합니다. 이제 IP는 원본과 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다. 원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하지 않는 경우 다음 홉 인터페이스가 원본 인터페이스와 같지 않을 수도 있습니다.
원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하는 경우 IP는 라우팅 테이블에서 제한 조회를 통해 패킷의 대상 주소를 조회합니다. 제한 조회의 경우 원본 인터페이스의 다음 홉 인터페이스가 있는 경로만 조회합니다. 대상에 선택된 경로를 기준으로 IP는 다음 홉 주소를 결정합니다. 이제 IP는 원본과 대상 주소, 다음 홉 인터페이스 및 다음 홉 주소를 모두 알고 있습니다. 원본 인터페이스에서 강력한 호스트 보내기 동작을 사용하는 경우 다음 홉 인터페이스가 항상 원본 인터페이스와 같습니다. 그림 2에서는 일반 IP 보내기 호스트 프로세스를 보여 줍니다.
그림 2 일반 IP 보내기 호스트 프로세스
그림 2 일반 IP 보내기 호스트 프로세스
원본 주소가 지정된 경우에는 제한 경로 조회 시 라우팅 테이블의 여러 경로 중에서 대상과 가장 일치하며 매트릭이 높은 경로를 선택할 수 있습니다. 예를 들어 그림 1의 호스트 A에는 매트릭이 10인 인터넷을 가리키는 경로와 매트릭이 20인 인트라넷을 가리키는 경로, 이렇게 두 개의 기본 경로가 있습니다. 또한 두 LAN 인터페이스에서는 모두 강력한 호스트 동작을 사용합니다.
호스트 A의 보내는 응용 프로그램에서 원본 주소를 지정하지 않는 경우 경로 조회 후 매트릭이 낮은 기본 경로가 선택됩니다. 호스트 A는 항상 원본 주소가 131.107.89.211인 인터넷 인터페이스에서 트래픽을 보냅니다. 하지만 호스트 A의 보내는 응용 프로그램에서 원본 주소 131.107.89.211을 지정하는 경우에는 조회 후 인터넷 인터페이스용 기본 라우터가 선택됩니다. 따라서 호스트 A는 해당 인터넷 인터페이스에서 트래픽을 보내게 됩니다. 호스트 A의 보내는 응용 프로그램에서 원본 주소 192.168.17.48을 지정하는 경우에는 조회 결과 인트라넷 인터페이스용 기본 경로가 선택되므로 호스트 A는 해당 인트라넷 인터페이스에서 트래픽을 보내게 됩니다. 제한 경로 조회를 사용하는 경우 IP는 매트릭이 높은 기본 경로를 사용하여 원본 주소 192.168.17.48을 통해 트래픽을 보냅니다.
받은 트래픽에 대해서는 먼저 IP가 해당 트래픽이 호스트로 보내진 것인지 여부를 확인합니다. 호스트로 보내진 것이 아니면 호스트가 라우터 역할을 하지 않으므로 IP가 패킷을 자동으로 삭제합니다. 그런 다음 IP는 수신 인터페이스(패킷을 받는 인터페이스)에서 강력한 호스트 받기를 사용하는지 여부를 확인합니다. 강력한 호스트 받기를 사용하지 않는 경우에는 IP가 패킷을 처리하고, 사용하는 경우에는 패킷의 대상 주소가 수신 인터페이스에 할당되었는지 여부를 확인합니다. 수신 인터페이스로 지정되어 있으면 IP가 패킷을 처리하고, 그렇지 않으면 패킷을 자동으로 삭제합니다. 그림 3에서는 일반 받기 호스트 프로세스를 보여 줍니다.
그림 3 받기 호스트 프로세스
그림 3 받기 호스트 프로세스

Windows의 취약한 호스트 동작 및 강력한 호스트 동작
Windows XP 및 Windows Server® 2003의 경우 모든 IPv4 인터페이스에 대해서는 보내기 및 받기에 취약한 호스트 모델을 사용하고 IPv6 인터페이스에 대해서는 보내기 및 받기에 강력한 호스트 모델을 사용합니다. 이 동작은 직접 구성할 수 없습니다. Windows Vista 및 Windows Server 2008에 포함될 차세대 TCP/IP 스택은 Teredo 호스트 릴레이용 Teredo 터널링 인터페이스를 제외한 모든 인터페이스에서 기본적으로 IPv4와 IPv6 모두에 대해 강력한 호스트 보내기 및 받기를 지원합니다. 그림 4에서는 인터페이스별로 IPv4 및 IPv6 모두에 대해 보내기 및 받기 동작을 구성하는 데 사용할 수 있는 명령을 보여 줍니다. InterfaceNameOrIndex는 네트워크 연결 폴더의 인터페이스 이름 또는 해당 인터페이스 인덱스입니다. 다음 명령의 출력에서 인터페이스의 인터페이스 인덱스를 확인할 수 있습니다.
Figure 4 강력한/취약한 보내기 및 받기 동작을 구성하는 명령 (Close Figure 4)

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
netsh interface ipv6 show interface
취약한 호스트 동작과 강력한 호스트 동작 및 RFC 3484
연결을 시도할 원본과 대상 IPv6 및 IPv4 주소를 선택하는 표준화된 방법을 제공하기 위해 RFC 3484는 두 가지 알고리즘을 정의합니다. 하나는 대상 주소에 사용할 최적의 원본 주소를 선택하는 원본 주소 선택 알고리즘입니다. 다른 하나는 가능한 대상 주소 목록을 우선 순위별로 정렬하는 대상 주소 선택 알고리즘입니다.
주어진 대상 주소에 대한 후보 원본 주소 목록을 결정할 때 강력한 호스트 동작과 취약한 호스트 동작의 효력이 발생하며 이는 최종적으로 정렬된 대상 주소 목록에도 영향을 줍니다. 강력한 호스트 보내기 동작을 사용하는 경우 후보 원본 주소 목록은 해당 대상에 대한 보내는 인터페이스에 할당된 유니캐스트 주소로 이루어집니다. 취약한 호스트 보내기 동작을 사용하는 경우 취약한 호스트 보내기를 사용하는 임의의 인터페이스에 할당된 주소가 후보 원본 목록에 포함될 수 있습니다. 원본 및 대상 주소 선택에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0206.mspx를 참조하십시오.

Teredo 호스트 릴레이용 Teredo 터널링 인터페이스를 제외한 모든 인터페이스에서는 IPv4와 IPv6 모두에 대해 기본적으로 취약한 호스트 보내기와 취약한 호스트 받기를 둘 다 사용하지 않습니다.
RFC 3484에 대한 자세한 내용은 "취약한 호스트 동작과 강력한 호스트 동작 및 RFC 3484" 추가 기사를 참조하십시오.

원격 액세스 VPN 연결에 기본 경로 사용 안 함
원격 액세스 VPN(가상 사설망) 클라이언트는 멀티홈 호스트의 또 다른 예입니다. 원격 액세스 VPN 클라이언트의 경우 인터넷에 연결되는 단일 LAN 인터페이스만 있더라도 클라이언트가 VPN 연결을 끝내면 멀티홈 호스트가 됩니다. 원격 액세스 VPN 클라이언트에는 자체의 LAN 인터페이스와 VPN 연결용 인터페이스 기반 PPP(Point-to-Point Protocol)라는 두 개의 인터페이스가 있습니다. 또한 이 클라이언트에는 IPv4 주소도 두 개 있습니다. 그 중 하나는 인터넷 서비스 공급자가 할당한 LAN 인터페이스용 IPv4 주소이고 다른 하나는 VPN 서버에서 할당한 PPP 기반 인터페이스용 IPv4 주소입니다.
VPN 클라이언트가 VPN 연결을 통해 인트라넷으로 기본 경로 트래픽을 보낼 수 있도록 Windows XP와 Windows Server 2003에서는 기존 기본 경로의 매트릭을 높이고 PPP 인터페이스를 사용하는 매트릭이 낮은 새로운 기본 경로를 추가하여 IPv4 라우팅 테이블을 수정합니다. 이와 같은 기본 동작을 통해 VPN 연결 중에는 인트라넷의 위치에만 연결할 수 있고 인터넷의 거의 모든 위치에는 연결할 수 없게 됩니다. VPN 연결용 기본 경로를 추가하지 않고 인트라넷 대상으로 향하는 특정 경로를 추가하여 VPN 클라이언트에 분할 터널링을 구성하면 VPN 클라이언트에서 인터넷과 인트라넷 위치에 동시에 액세스할 수 있습니다. 하지만 분할 터널링 VPN 클라이언트의 경우 인터넷과 인트라넷 사이에서 패킷을 라우팅할 위험이 발생합니다. 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg1003.mspx를 참조하십시오.
Windows XP와 Windows Server 2003의 기본 VPN 클라이언트 동작은 취약한 호스트 보내기 동작에 맞게 설계되었습니다. 경로 조회 후 VPN 연결에 항상 기본 경로를 사용하는데 이는 기본 경로의 매트릭이 가장 낮기 때문입니다. 하지만 강력한 호스트 보내기 동작을 사용하는 경우에는 패킷의 원본 IP 주소에 따라 보내는 트래픽에 사용되는 기본 경로가 달라집니다. ISP에서 할당한 IPv4 주소에서 보낸 트래픽에 대한 경로를 조회할 때는 LAN 인터페이스를 사용하는 기본 경로를 사용하므로 모든 인터넷 위치에 연결할 수 있습니다. VPN 서버에서 할당한 IPv4 주소에서 보낸 트래픽에 대한 경로를 조회할 때는 PPP 인터페이스를 사용하는 기본 경로를 사용하므로 모든 인트라넷 위치에 연결할 수 있습니다. 따라서 강력한 호스트 보내기 동작을 사용하는 경우 VPN 클라이언트는 분할 터널링 구성을 통해 인터넷과 인트라넷 모두에 동시에 액세스할 수 있으며 이는 IPv4 라우팅 테이블을 직접 수정할 수 있는 관리자 수준 권한이 없는 응용 프로그램의 경우에도 마찬가지입니다.
강력한 호스트 보내기 동작이 기본적으로 분할 터널링 구성을 만들 수 없도록 Windows Vista®와 Windows Server 2008의 VPN 클라이언트는 VPN 연결이 끝나면 LAN 인터페이스의 기본 경로를 자동으로 비활성화합니다. 이러한 동작을 통해 PPP 인터페이스를 사용하는 활성 기본 경로가 라우팅 테이블에 하나만 있게 됩니다. 또한 이 동작을 통해 관리자 수준 권한이 없는 응용 프로그램에서는 분할 터널링을 수행할 수 없게 됩니다.
VPN 클라이언트 컴퓨터의 트래픽은 VPN 서버에서 할당한 IPv4 주소에서 나와야 하므로 이 동작을 통해 인트라넷과 인터넷이 보다 확실하게 격리됩니다. VPN 연결이 종료되면 비활성화되었던 기본 경로가 활성화됩니다.
이 동작은 다음 명령을 사용하여 제어할 수 있습니다.
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

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


 Windows PowerShell: 셸 보안
Windows PowerShell
셸 보안
Don Jones

Windows PowerShell 팀이 새 셸 개발을 위해 모이고 여기저기서 "스크립팅"이라는 단어가 나왔을 때 당황의 신음소리가 꽤 크게 들렸을 것입니다. 결국 관리 스크립팅에 대한 Microsoft의 기존 노력(여기서는 VBScript를 말하는 것임)에 문제가 있었다고 할 수 있습니다.
과도하게 권한 지정된 실행 모델은 대부분의 사용자가 관리자로 로그온한다는 경향과 결합되어 재난이 발생할 기반을 형성했습니다.
Windows PowerShell™ 회의 첫 모임 참가자들은 이런 문제가 반복되지 않도록 해달라고 기도했어야 했을지도 모릅니다. 하지만 참가자들은 그렇게 하지 않았습니다. 결과적으로 보안에 대한 Microsoft의 평가는 크게 향상되었으며, 그 이유는 제품 개발 주기의 후반부가 아니라 첫 단계에서 보안에 대해 생각하기 시작했기 때문입니다. 이러한 철학은 Windows PowerShell에서 매우 확실하게 드러납니다.

내 스크립트가 왜 실행되지 않죠?
새로 설치한 컴퓨터에 Windows PowerShell을 설치하고 .ps1 파일을 두 번 클릭해 보십시오. 그러면 Windows PowerShell이 아니라 메모장이 열립니다. .ps1 파일 이름 확장자(Windows PowerShell 스크립트에 사용되는 확장자)가 셸과 연결되어 있지 않기 때문에 발생하는 현상입니다. 다른 말로 하면 스크립트를 두 번 클릭하여 실행할 수 없다는 의미입니다. 스크립트를 실행하는 유일한 방법은 Windows PowerShell을 열고 스크립트 이름을 입력한 다음 Enter 키를 누르는 것입니다.
실제로는 스크립트 이름을 입력하는 것만으로는 충분하지 않습니다. 그림 1에서 파일 Demo1.ps1이 현재 폴더에 존재하지만 demo1을 입력하고 Enter 키를 누르면 "The term 'demo1' is not recognized as a cmdlet, function, operable program, or script file."(용어 'demo1'이 cmdlet, 함수, 작동 가능한 프로그램 또는 스크립트 파일로 인식되지 않습니다.)이라는 오류가 나타납니다. 파일이 해당 위치에 있는데 왜 이런 오류가 나타날까요?
그림 1 명령 하이재킹을 피하기 위해 Windows PowerShell에서는 스크립트에 대한 경로가 필요함
그림 1 명령 하이재킹을 피하기 위해 Windows PowerShell에서는 스크립트에 대한 경로가 필요함
이것은 Windows PowerShell 보안 모델의 다른 측면입니다. 악의적 사용자가 다른 셸에서 시도하는 해킹 방법 중 하나는 기본 제공 명령과 파일 이름이 같은 스크립트를 만드는 것입니다. 예를 들어 사용자가 스크립트를 실행하도록 하려면 이름이 Dir.ps1인 스크립트를 만들어 폴더에 넣을 수 있습니다. 사용자가 Dir을 입력하고 Enter를 누르면 사용자가 기대한 Dir 명령이 아니라 이 스크립트가 실행될 수 있습니다. 이 방법을 명령 하이재킹이라고 합니다. 하지만 Windows PowerShell에서는 항상 이러한 스크립트에 대한 경로를 제공해야 하기 때문에 Windows PowerShell은 명령 하이재킹으로부터 적절하게 보호됩니다.
demo1을 실행하면 경로가 없기 때문에 작동하지 않지만 ./demo1을 실행하면 작동합니다. 경로(여기서는 현재 폴더)를 지정했기 때문입니다. 기본 제공 명령을 참조할 때는 경로를 입력하지 않기 때문에 이런 명령줄은 기본 제공 명령과 혼동될 가능성이 적습니다. 따라서 경로를 입력하도록 함으로써 명령 하이재킹을 방지하고 Enter 키를 눌렀을 때의 동작에 대한 혼동을 피할 수 있습니다.

스크립트 실행에 대한 정책
Windows PowerShell을 새로 설치하고 올바른 구문을 사용하여 스크립트 실행을 시도한다고 가정합니다. 하지만 이 경우에도 스크립트 실행이 허용되지 않음을 알리는 다른 오류 메시지가 나타납니다. 왜 그럴까요? 이것은 셸의 실행 정책 때문입니다.
셸에서 Get-ExecutionPolicy을 실행하여 현재 실행 정책이 무엇인지 확인할 수 있습니다. 기본적으로 실행 정책은 스크립트를 실행하지 않는 Restricted로 설정되어 있으므로 누구도 스크립트를 실행할 수 없습니다. Windows PowerShell은 기본적으로 스크립트를 실행하는 것이 아니라 대화식으로 사용하는 프로그램입니다. Set-ExecutionPolicy cmdlet를 사용하면 네 가지 가능한 실행 정책 설정 중 하나를 선택할 수 있습니다.
  • 기본 설정인 Restricted는 모든 스크립트의 실행을 허용하지 않습니다.
  • AllSigned는 신뢰할 수 있는 스크립트만 실행합니다.
  • RemoteSigned는 신뢰 여부에 관계없이 로컬 스크립트를 실행합니다. 하지만 인터넷에서 다운로드한 스크립트는 신뢰하는 경우에만 실행할 수 있습니다.
  • Unrestricted는 신뢰하지 않은 스크립트를 포함한 모든 스크립트의 실행을 허용합니다.
현실적으로는 AllSigned가 가장 낮은 설정이며 프로덕션 컴퓨터는 이것으로 설정해야 합니다. 필자의 경우 개발 및 테스트 환경에서는 RemoteSigned가 유용하다고 생각하지만 일반 사용자의 경우에는 그렇지 않을 수 있습니다. 또한 Unrestricted는 전혀 필요 없으며 향후 버전의 Windows PowerShell에서 이 과도하게 권한 지정된 설정을 제거해도 괜찮을 것입니다.

신뢰 문제
사용자의 컴퓨터는 특정 루트 인증 기관(CA), 즉 디지털 인증서를 발행하는 서버를 신뢰하도록 사전 구성되어 있습니다. 그림 2에서는 신뢰할 수 있는 루트 CA를 나열하는 인터넷 옵션 제어판 응용 프로그램을 보여 줍니다. Windows Vista®에서 이 목록은 꽤 짧으며 몇 개의 주요 상용 루트 CA만 포함합니다. 이와 반대로 Windows® XP의 기본 목록은 크며 들어본 적 없는 많은 루트 CA도 포함합니다. 루트 CA가 이 목록에 있다는 것은 루트 CA를 운영하는 회사가 누군가에게 디지털 인증서를 발행하기 전에 그 사람의 신원을 제대로 확인하는 것으로 신뢰한다는 의미와 같습니다.
Class III 디지털 인증서(보통 코드 서명 인증서라고 함)를 얻을 때 CA(상용 CA이거나 조직 내의 사설 CA일 수 있음)가 여러분의 신원을 검증해야 합니다. 이 디지털 인증서는 전자 여권 또는 신분증과 같습니다. 예를 들어 '저는 Don Jones입니다'라는 의미의 ID를 제공하기 전에 CA가 몇 단계를 거쳐 그 사람이 실제로 Don Jones인지 확인해야 합니다. 인증서를 사용하여 Windows PowerShell 스크립트에 디지털 서명하는 것은(Set-AuthenticodeSignature cmdlet를 사용하여) 스크립트에 이름을 서명하는 것입니다. 물론 다른 사람의 이름이 포함된 거짓 인증서를 얻을 수 있다면 스크립트에 그 사람의 이름을 서명할 수 있습니다. 바로 이런 이유 때문에 그림 2의 목록에 신뢰할 수 있는 CA만 표시되는 것이 중요합니다.
그림 2 Windows Vista에서 기본적으로 신뢰할 수 있는 루트 CA
그림 2 Windows Vista에서 기본적으로 신뢰할 수 있는 루트 CA
Windows PowerShell은 스크립트를 신뢰할 수 있는지 검사할 때(AllSigned 및 RemoteSigned 실행 정책 설정에서 수행됨) 다음 세 가지를 질문합니다.
  • 스크립트에 서명이 되어 있습니까? 서명이 되어 있지 않으면 스크립트를 신뢰하지 않습니다.
  • 서명이 변조되지 않았습니까? 다른 말로, 스크립트가 서명된 이후 변경되었습니까? 서명이 변조된 경우 스크립트를 신뢰하지 않습니다.
  • 신뢰할 수 있는 루트 CA가 발행한 디지털 인증서를 사용하여 서명이 생성되었습니까? 그렇지 않은 경우에는 스크립트를 신뢰하지 않습니다.
이 달의 CMDLET: Set-AuthenticodeSignature
Set-AuthenticodeSignature는 Windows PowerShell 스크립트에 디지털 서명하기 위한 키이며, 이를 통해 셸의 가장 안전한 실행 정책인 AllSigned를 사용할 수 있습니다. 이 cmdlet를 사용하려면 설치된 코드 서명 인증서를 인출하는 다른 Get-ChildItem으로 시작할 수 있습니다.
$cert = Get-ChildItem –Path cert:\CurrentUser\my –codeSigningCert
이 파일 경로를 설치된 인증서 경로로 바꿔야 합니다. 설치된 모든 인증서에는 cert: drive를 사용하여 액세스할 수 있습니다. 인증서가 로드된 후 다음을 실행하여 스크립트에 서명합니다.
Set-AuthenticodeSignature MyScript.ps1
–cert $cert
물론 실제 .ps1 스크립트 파일의 전체 경로를 지정해야 합니다. 그러면 셸은 파일에 서명 블록을 추가합니다.

그러면 신뢰는 어떻게 보안을 향상시킬까요? 물론 해커가 악성 스크립트를 작성하고, 이를 서명한 다음 다른 사용자가 이를 실행하도록 유도할 가능성도 있습니다. 이 경우 스크립트는 서명이 되어 있으므로 실행됩니다. 하지만 서명이 되었기 때문에 이 서명을 사용하여 작성자의 신분을 찾아서 법률 기관 신고 등과 같은 적절한 조치를 취할 수 있습니다. 하지만 악성 스크립트를 만들어서 자신의 실제 이름으로 서명하는 해커는 없을 것입니다.
물론 악성 사용자가 신원 확인 프로세스가 제대로 갖춰지지 않은 CA 등으로부터 다른 사람의 신원이 적용된 인증서를 얻을 수 있다면 서명을 사용하여 실제 용의자를 찾아낼 수 없을 것입니다. 바로 이런 이유 때문에 신뢰하는 루트 CA에서 만족스러운 신원 확인 프로세스를 사용하는지 확인해야 합니다.
AllSigned 실행 정책 설정을 사용하는 경우, 작성한 모든 스크립트를 실행하기 전에 해당 스크립트에 디지털 서명을 해야 합니다. Set-AuthenticodeSignature cmdlet는 사용법이 꽤 쉽지만 다소 번거로운 것도 사실입니다. 경우에 따라 타사 소프트웨어가 편리할 수 있습니다. 개인적으로, 작성한 스크립트를 지정한 인증서로 자동 서명하는 스크립트 편집기나 가상 개발 환경을 사용하는 것을 추천합니다. 이 방법을 사용하면 서명 사용이 투명하며 추가적인 작업이 필요 없습니다. 이를 지원하는 편집기 및 개발 환경에 대한 정보가 필요한 경우 온라인 스크립팅 포럼(예를 들어 SscriptingAnswers.com의 필자 사이트)을 방문하여 다른 Windows PowerShell 사용자들은 어떤 방법을 사용하는지 묻는 질문을 게시해 보십시오.
인증서를 얻은 뒤에는 다음을 실행하여 특정 위치의 모든 스크립트에 서명할 수 있습니다.
Get-Childitem *.ps1 | %{Set-AuthenticodeSignature $_.fullname $cert}

중앙 집중식 보안
Windows PowerShell 실행 정책은 컴퓨터 단위로 구성할 수 있습니다. 하지만 엔터프라이즈 환경에서는 이 방식이 적합한 솔루션이 아니므로 이 경우 정책 그룹을 사용할 수 있습니다. Windows PowerShell 관리 템플릿은 go.microsoft.com/fwlink/?LinkId=93675에서 다운로드할 수 있습니다. 전체 도메인에 영향을 주는 그룹 정책 개체(GPO)에 파일을 지정하고 Restricted로 지정합니다. 이렇게 하면 Windows PowerShell이 설치된 위치에 관계 없이 스크립트가 실행되지 않습니다. 그러면 자신의 워크스테이션처럼 스크립트를 실행해야 하는 컴퓨터에서만 추가적인 권한 설정(예: AllSigned)을 적용할 수 있습니다.

대체 자격 증명
기존의 Windows용 관리 스크립팅 언어와 달리 Windows PowerShell은 보안상 안전한 방식으로 대체 자격 증명을 다룰 준비도 되어 있습니다. 예를 들어 Get-WMIObject cmdlet에는 원격 WMI 연결에 대한 대체 자격 증명을 지정할 수 있는 -credential 매개 변수가 있습니다. 매개 변수는 사용자 이름을 받지만 암호는 받지 않음으로써 민감한 암호를 일반 텍스트 스크립트에 하드 코드하는 것을 방지합니다. 대신 사용자가 사용자 이름을 입력하면 Windows PowerShell은 대화 상자를 사용하여 암호를 묻는 메시지를 표시합니다. 대체 자격 증명을 다시 사용하려면 Get-Credential cmdlet를 사용하여 자동화 정보를 저장할 수 있습니다.
$cred = Get-Credential DOMAIN\USER
즉시 암호를 묻는 메시지가 나타나고 최종 자격 증명이 변수 $cred에 저장됩니다. 그러면 $cred 변수는 필요할 때마다 -credential 매개 변수로 전달될 수 있습니다. ConvertTo-SecureString 및 ConvertFrom-SecureString cmdlet를 사용하여 자격 증명을 암호화된 문자열로 변환하거나 이전에 암호화된 문자열을 다시 자격 증명으로 변환할 수도 있습니다.
여기서 문제는 암호화 키가 보안에 취약한 일반 텍스트 스크립트에 저장된다는 점입니다. 따라서 이 방법 대신 Get-Credential 호출을 Windows PowerShell 프로필에 추가할 수 있습니다. 이렇게 하면 Windows PowerShell을 실행했을 때 곧바로 사용자 이름과 암호를 묻는 메시지가 나타나며 이 두 정보는 $cred라는 변수에 저장됩니다. 이 방법을 통해 도메인 관리자 계정을 나타내는 셸에서 언제라도 $cred 변수를 사용할 수 있습니다. 또한 해당 자격 증명을 저장할 필요가 없습니다. 자격 증명은 셸을 열 때마다 다시 생성되므로 저장할 필요가 없습니다.

기본 보안
기본적으로 스크립팅을 지원하는 관리 셸에서 사용할 수 있는 가장 안전한 보안 설정으로 Windows PowerShell을 설치 및 구성할 수 있습니다. 이러한 설정을 변경한 경우 이외에는 Windows PowerShell은 가능한 최선의 보안을 유지합니다. 다른 말로 하면 Windows PowerShell에서 보안이 취약해지는 것은 사용자의 결정이나 작업이 원인입니다. 따라서 기본값을 변경하려면 파일 확장자를 다시 구성하고, 실행 정책을 변경하는 등의 작업을 해야 합니다. 작업의 결과를 확실히 알고 있으며 자신의 변경에 책임질 준비가 되었을 때만 기본값을 변경하십시오.

Don Jones는 SAPIEN Technologies의 수석 스크립팅 전문가이자 ScriptingTraining.com의 강사입니다. 문의 사항이 있으면 ScriptingAnswers.com을 통해 연락하십시오.


 Hey, Scripting Guy!: 이 관계를 저장할 수 있을까요?
Hey, Scripting Guy!
이 관계를 저장할 수 있을까요?
Microsoft Scripting Guys
이 기사의 코드 다운로드: HeyScriptingGuy2007_09.exe (150KB)

관계는 매우 중요합니다. 그러면 Scripting Guys는 이러한 관계의 중요성을 어떻게 알고 있을까요? 저희는 TV를 많이 보는데 TV에서는 항상 관계가 중요하다고 이야기합니다.
드라마나 주말의 TV 영화에만 국한되는 것은 아닙니다. 예를 들어 사람들에게 대출을 권유하는 대부업체 광고가 있습니다. 이러한 업체는 대출해서는 안 되는 사람들에게도 기꺼이 대출을 해주기 위해 광고를 하는 것일까요? 아닙니다. 그러면 대출 고객에게 연간 900%에 이르는 이자를 부과하려는 것이기 때문일까요? 물론 아닙니다. 광고를 통해 대부업체가 고객과 개인적 관계를 형성하기 때문입니다. 광고에서 말하듯이 "관계가 중요"한 것이지요.
저희는 대부업체와의 아픈 경험을 갖고 있지만 부끄럽지는 않습니다. 아무튼, 여러분은 사람과 대부업체를 결속하는 사소하지만 생각해 보면 깊고 질긴 관계가 파탄에 이르지 않도록 냉철하게 생각해야 합니다.
이렇게 말하면 "대부업체에게 관계가 중요하다면 데이터베이스와 상호 작용하는 스크립트를 작성하는 사람에게도 관계가 매우 중요하겠다"고 생각하는 분도 계실겁니다. 데이터베이스와 상호 작용하는 스크립트를 작성하는 사람에게 관계가 매우 중요하다는 점은 맞습니다. 하지만 이러한 스크립트 작성자가 항상 이러한 관계의 중요성을 알고 있는 것은 아닙니다. 어쨌든 괜찮습니다. 이번 달 칼럼에서 바로잡을 수 있으니까요.
하드웨어 인벤토리를 관리하는 용도로 데이터베이스를 사용하는 시스템 관리자가 많이 있습니다. 이 경우 문제는 이러한 데이터베이스의 상당수가 적절하지 않은 방식으로 설정되어 있다는 점입니다. 예를 들어 모든 컴퓨터에 장착된 디스크 드라이브를 관리하는 데이터베이스가 필요하다고 가정해 보겠습니다. 데이터베이스 디자인에 대한 기본 지식이 없다면 그림 1과 같은 단일 테이블로 구성된 데이터베이스를 만들 가능성이 큽니다.
그림 1 단일 테이블 데이터베이스
그림 1 단일 테이블 데이터베이스
그림에서 볼 수 있듯이 이 데이터베이스는 매우 단순합니다. 컴퓨터 이름 필드와 컴퓨터에 C: 드라이브 및 D: 드라이브가 있는지 여부를 나타내는 데 사용되는 Yes/No(예/아니요) 필드가 몇 개 있습니다. 이것이 전부입니다. 단순 명료합니다.
그렇다면 이 데이터베이스에는 어떤 문제가 있을까요? 사실, 거의 모든 것이 잘못되었습니다. 디스크 드라이브가 세 개 이상 있는 컴퓨터가 없다는 것이 확실하다면 이 디자인도 어느 정도는 제대로 작동합니다. 하지만 디스크 드라이브가 세 개인 컴퓨터가 있다면 어떻게 될까요? 이 경우에는 드라이브 E를 관리하는 필드를 더 추가해야 합니다. 그렇다면 디스크 드라이브가 11개인 컴퓨터가 있으면 어떻게 될까요? 또한 드라이브 각각의 속성을 관리해야 한다면 어떻게 될까요? 예를 들어 각 드라이브의 전체 크기를 관리하려고 한다고 가정해 보겠습니다. 이 경우 Drive_C_Size 필드, Drive_D_Size 필드, Drive_E_Size 필드가 필요합니다. 이것만 봐도 무엇이 문제인지 느낄 것입니다. 사용 가능한 디스크 공간, 디스크 커넥터 유형, 드라이브의 디스크 할당량 사용 여부 등을 관리하기는 거의 불가능해집니다.
염두에 두어야 할 것은 둘 이상의 항목이 있을 수 있는 엔터티(예를 들어 컴퓨터에는 둘 이상의 디스크 드라이브가 있을 수 있음)의 경우에는 "플랫 파일"(단일 테이블) 디자인이 그다지 적합하지 않다는 점입니다. 디스크 드라이브의 경우에는 그냥 두고, 한정된 수의 드라이브를 컴퓨터에 연결하려는 경우도 생각해 볼 수 있습니다. 하지만 데이터베이스를 쿼리하여 100GB 이상인 모든 디스크 드라이브의 목록을 가져와야 한다고 가정해 보겠습니다. 어떻게 해야 할까요? 먼저 Drive_C_Size 필드에서 100GB 드라이브를 찾은 다음 Drive_D_Size 필드, Drive_E_Size 필드 등에서도 같은 작업을 반복해야 합니다. 당연히 효율적이거나 효과적인 방법과는 거리가 멉니다. 그러면 대안은 무엇일까요? 플랫 파일 데이터베이스를 사용할 수 없다면 무엇을 사용할 수 있을까요?
이에 대한 대안이 바로 관계형 데이터베이스입니다. 관계형 데이터베이스는 한 컴퓨터에 여러 개의 디스크 드라이브가 있는 일대다 관계를 처리하기 위해 디자인되었습니다. 그렇다고 관계형 데이터베이스를 사용하기 위해 어떤 것을 새로 구입해야 한다는 것은 아닙니다. Microsoft® Access™, SQL Server™, Oracle 등의 데이터베이스가 있다면 이미 관계형 데이터베이스를 사용할 준비가 된 것입니다. 따로 구입할 것은 없으며 1) 데이터베이스의 두 테이블 사이의 관계를 설정하는 방법과 2) 이러한 관계를 활용할 수 있는 스크립트를 작성하는 방법만 알면 됩니다.
TV의 경우라면 관계를 이용하려고 하지도 말아야 하겠지만 이 경우는 다릅니다.
이 칼럼이 데이터베이스 디자인 전문가를 위한 것은 아니므로 데이터베이스 디자인에 지면을 할애하지는 않겠습니다. 대신 관계형 쿼리 작성에 도움이 되는 매우 간단한 관계형 데이터베이스 디자인을 소개하겠습니다. 이 데이터베이스에는 두 개의 테이블이 있습니다. 첫 번째 테이블의 이름은 Computers이고 ComputerName 및 SerialNumber 필드로 구성됩니다. ComputerName 필드에는 컴퓨터 이름을 저장하고 SerialNumber 필드에는 이름에서 알 수 있듯이 일련 번호를 저장합니다.
그러면 디스크 드라이브 정보는 어디에 넣을까요? 두 번째 테이블인 DiskDrives에 넣습니다. 이 테이블은 이름 자체로도 용도를 알 수 있는 SerialNumber, DriveLetter 및 DriveSize의 세 필드로 구성됩니다.
여기서 키 필드는 SerialNumber입니다. 이 필드가 낯익은가요? 그렇습니다. Computers 테이블에도 이 필드와 정확하게 동일한 필드가 있습니다. 이는 실수나 우연의 일치가 아니라 의도적인 것입니다. 이 두 테이블 간의 관계를 설정하려면 두 테이블 모두에 나타나는 하나의 필드가 있어야 합니다. 그래야 각 디스크 드라이브가 어떤 컴퓨터에 속하는지 알 수 있습니다.
컴퓨터 이름 등이 아니라 일련 번호를 사용하여 두 테이블을 연결한 이유는 무엇일까요? 그럴 만한 이유가 있습니다. 컴퓨터 이름은 자주 바뀔 수 있으며 실제로도 그렇기 때문입니다. 하지만 일련 번호는 일반적으로 변경되지 않습니다.
이제 이 두 테이블을 검색하여 각 컴퓨터에 속한 디스크 드라이브의 목록을 가져올 수 있는 스크립트인 그림 2를 살펴보겠습니다. 그림 3에서는 이 스크립트가 반환하는 데이터의 종류를 보여 줍니다.
Figure 3 검색 결과 (Close Figure 3)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-01
E:

atl-ws-02
C:

atl-ws-02
D:
Figure 2 테이블 검색 (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
 "Provider = Microsoft.Jet.OLEDB.4.0; " & _
 "Data Source = c:\scripts\test.mdb"

objRecordSet.Open "SELECT Computers.*, DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber " & _
 "ORDER BY Computers.ComputerName, DiskDrives.Drive", objConnection, adOpenStatic, _
  adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
 Wscript.Echo objRecordset.Fields.Item("ComputerName")
 Wscript.Echo objRecordset.Fields.Item("Drive")
 Wscript.Echo
 objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
이번 달 칼럼의 목적은 데이터베이스 연결 및 사용에 대한 기본 사항을 설명하려는 것이 아닙니다. 데이터베이스 스크립팅이 처음인 경우에는 Scripting Guys 웹캐스트 "시스템 관리자를 위한 데이터베이스 스크립팅"(go.microsoft.com/fwlink/?LinkId=22089)을 참조하십시오. 여기에서는 Access 데이터베이스(C:\Scripts\Test.mdb)에 액세스하여 Computers 및 DiskDrives라는 이름의 관계형 테이블로 작업할 것입니다. 스크립트에서 이 부분을 충분히 살펴볼 것입니다.
또한 Access 2007을 사용하여 작업할 때는 약간의 변경을 해야 한다는 점을 알아야 합니다. 다음과 같이 공급자를 Microsoft.Jet.OLEDB.4.0에서 Microsoft.ACE.OLEDB.12.0으로 변경하는 것이 중요합니다.
objConnection.Open _
 "Provider = Microsoft.ACE.OLEDB.12.0; " & _
 "Data Source = c:\scripts\test.accdb"
이게 다입니다. 여기서 좀 더 자세히 살펴볼 것은 다음과 같이 두 테이블에서 데이터를 검색하는 SQL 쿼리입니다.
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
복잡해 보입니까? 어느 정도는 그럴 수 있습니다. 그러면 더 쉽게 이해할 수 있도록 이 쿼리를 나눌 수 있는지 보겠습니다.
쿼리의 첫 번째 부분은 매우 쉽습니다. 두 테이블, 즉 Computers와 DiskDrives의 모든 필드를 선택해야 합니다. 따라서 이 부분의 SQL은 다음과 같습니다.
SELECT Computers.*, DiskDrives.*
여기서 별표(*)는 당연히 "모든 것"을 의미하는 와일드카드 문자일 뿐입니다.
SQL 쿼리를 작성해 본 적이 있거나 SQL 쿼리 언어의 하위 집합을 사용하는 WMI(Windows® Management Instrumentation) 쿼리를 작성해 본 적이 있으면 루틴을 이해할 것입니다. 선택할 항목을 지정한 후에는 이들 항목을 선택할 출처를 지정합니다. 따라서 쿼리의 다음 부분은 다음과 같습니다.
FROM Computers INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber
사실 일반적인 FROM 문보다 조금 복잡하지만 그럴 만한 이유가 있습니다. 일반적인 SQL 쿼리에서는 하나의 테이블에서만 데이터를 선택하지만, 이 경우에는 한 번에 두 테이블에서 데이터를 선택합니다.
구문을 좀 더 자세히 살펴보고 작동 방식을 알아보겠습니다. 여기서 볼 수 있듯이 Computers 테이블과 DiskDrives 테이블에서 데이터를 선택하도록 스크립트를 작성합니다. 하지만 "and"라는 단어가 아니라 INNER JOIN이라는 구문을 사용한다는 점을 주목하십시오. 이 구문은 관계의 유형을 정의하며 두 테이블의 정보를 하나의 레코드 집합으로 조인하는 방법을 설명합니다. 이외에도 다른 유형의 조인도 있는데 잠시 후 이에 대해 살펴보겠습니다.
두 테이블 사이에 존재하는 관계의 유형을 지정하는 것은 사용자의 몫입니다. 테이블이 서로 관련되는 정확한 방식을 지정하는 것도 사용자의 몫입니다. 다음 코드에서 이 작업을 합니다.
ON Computers.SerialNumber = DiskDrives.SerialNumber
이 코드에서는 테이블을 조인하는 방법을 정의합니다. 레코드는 Computers 테이블의 SerialNumber 필드가 DiskDrives 테이블의 SerialNumber 필드와 일치할 때마다 함께 그룹화됩니다. ComputerName과 같은 다른 필드를 필드 조인에 사용하면 어떻게 될까요? 이 경우 코드는 다음과 같습니다.
ON Computers.ComputerName = DiskDrives.ComputerName
자세히 본다면, 여기서 두 필드는 이름이 같을 필요는 없으며 같은 데이터만 포함되어 있으면 됩니다. 하지만 같은 이름을 사용하면 관계 필드를 더 쉽게 구분할 수 있습니다. 한 가지만 염두에 두면 됩니다. 이름이 같은 두 개의 필드가 있기 때문에 이들 필드 중 하나를 참조할 때 항상 TableName.FieldName 구문을 사용해야 합니다. 즉, Wscript.Echo obj- Recordset.Fields.Item("Computers.SerialNumber")와 같은 코드를 사용해야 합니다.
이것만 주의하면 됩니다. 쿼리의 나머지 부분은 데이터를 컴퓨터 이름별로 정렬하고 다시 드라이브별로 정렬할 뿐입니다.
ORDER BY ComputerName, Drive
그다지 어렵지 않죠? 여기서 잠시 조인에 대해 이야기하겠습니다. 쿼리에 왜 내부 조인을 사용했을까요? 간단합니다. 내부 조인은 각 테이블에 일치하는 값이 있는 레코드만 반환합니다. 121989라는 일련 번호가 있다고 가정하겠습니다. 이 일련 번호가 Computers와 DiskDrives 테이블 모두에 있는 경우에는 해당 레코드가 반환됩니다. 물론 일련 번호는 SerialNumber 필드 외에는 다른 어디에도 표시되어서는 안 됩니다. 이해가 되셨나요?
이제 일련 번호가 121989라는 컴퓨터가 있는데 이 일련 번호를 가진 디스크 드라이브는 없다고 가정해 보겠습니다. 이 경우에는 일련 번호가 121989인 컴퓨터에 대해 데이터가 반환되지 않습니다. 내부 조인은 조인된 각 테이블에서 값이 서로 일치하는 레코드가 있는 경우에만 정보를 반환하기 때문입니다.
즉, 내부 조인 쿼리는 하드 디스크가 있는 모든 컴퓨터를 반환합니다. 하드 디스크가 없는 컴퓨터 또는 컴퓨터에 설치되지 않은 하드 디스크는 반환하지 않습니다. 이러한 결과가 필요할 때도 있습니다. 하지만 하드 디스크가 없는 컴퓨터 또는 컴퓨터에 설치되지 않은 하드 디스크의 목록이 필요한 경우에는 어떻게 해야 할까요?
이런 경우에는 외부 조인을 사용할 수 있습니다. 일단, 외부 조인에는 왼쪽 우선 및 오른쪽 우선의 두 가지 유형만 있다고 간주하겠습니다. 예제 데이터베이스에는 Computers(마스터 테이블이므로 "왼쪽" 테이블로 간주됨)와 DiskDrives(마스터 테이블이 아니기 때문에 "오른쪽" 테이블로 간주됨)의 두 테이블이 있습니다. 반환되는 레코드 집합에 디스크 드라이브가 설치되지 않은 컴퓨터를 포함한 모든 컴퓨터가 포함되도록 하려는 경우를 예로 들겠습니다. 이 경우에는 LEFT OUTER JOIN 구문을 사용하여 다음과 같은 쿼리를 만듭니다.
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "LEFT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
왼쪽 우선 외부 조인은 오른쪽 테이블에 해당 레코드가 없더라도 왼쪽 테이블에 있는 모든 레코드를 반환합니다. 따라서 모든 컴퓨터가 반환되기는 하지만 오른쪽 테이블(디스크 드라이브)에서는 컴퓨터와 연관된 레코드만 반환됩니다.
또는 컴퓨터에 설치되지 않은 디스크 드라이브를 포함하여 모든 디스크 드라이브의 목록이 필요할 수 있습니다. DiskDrives 테이블은 관계에서 오른쪽 테이블이기 때문에 다음과 같이 RIGHT OUTER JOIN 구문을 사용합니다.
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "RIGHT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
DiskDrives가 관계에서 오른쪽 테이블이라면 Computers는 왼쪽 테이블이라기보다는 관계에 있어 남편 테이블이라고 해야 할 것입니다. Scripting Guys 중에는 남편은 관계에 있어 결코 오른쪽이 아니라는 것을 뼈저리게 경험한 사람도 있습니다.
오른쪽 우선 외부 조인을 사용하면 오른쪽 테이블의 모든 레코드(모든 디스크 드라이브)가 반환되지만 디스크 드라이브와 연관된 컴퓨터(왼쪽 테이블의 레코드)만 반환됩니다.
얼핏 보면 이상한 것 같지만 잠시만 테스트해 보면 작동 방식을 이해할 수 있을 것입니다. 테스트할 데이터베이스가 필요한 경우를 위해 microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx에 샘플을 게시해 두었습니다.
한 가지 중요한 것은, 외부 조인을 사용할 때 최소한 스크립트의 첫 번째 줄에는 On Error Resume Next 문을 지정해야 한다는 점입니다. 이유가 무엇일까요? 왼쪽 우선 외부 조인을 수행한다고 가정해 보겠습니다. 이 경우 하드 디스크가 설치되지 않은 컴퓨터가 반환될 가능성이 있습니다. 이 사실은 드라이브 문자를 표시하는 다음 코드 줄에 도달하기 전까지는 문제가 되지 않습니다.
Wscript.Echo objRecordset.Fields.Item("Drive")
이 특정 컴퓨터에는 Drive 필드가 없기 때문에 스크립트는 중지됩니다.
C:\Scripts\database.vbs(22, 9) Microsoft VBScript runtime error: Type mismatch
하지만 On Error Resume Next 문을 구현하면 스크립트는 컴퓨터에 디스크 드라이브가 없다는 사실을 무시하고 다음으로 넘어갈 수 있습니다. 또는 다음과 같은 코드를 사용하여 Drive 필드의 값을 검사한 다음 적절한 조치를 취할 수도 있습니다.
If IsNull(objRecordset.Fields.Item("Drive")) _Then
    Wscript.Echo "No disk drives installed."
Else
    Wscript.Echo _
      objRecordset.Fields.Item("Drive")
End If
이 코드를 사용하여 실제 드라이브 문자가 아니라 Null 값이 반환되는지 확인합니다. Null 값이 반환되면 "No disk drives installed"라는 메시지를 표시합니다. Null 값이 반환되지 않으면 Drive 필드의 값을 표시합니다. 출력 결과는 그림 4와 같습니다.
Figure 4 적절한 결과 표시 (Close Figure 4)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-02
C:

atl-ws-02
D:

alt-ws-03
No disk drives installed.
장황한 설명 대신 몇 가지 쿼리를 더 살펴보겠습니다. 디스크 드라이브가 50GB보다 큰 경우 컴퓨터 및 해당 컴퓨터에 설치된 디스크 드라이브의 목록을 반환하는 내부 조인 쿼리를 예로 들겠습니다. 드라이브 크기가 GB 단위로 저장된다고 가정하겠습니다.
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "WHERE DriveSize > 50 " & _
 "ORDER BY Computers.ComputerName, " & _
 "DiskDrives.Drive", objConnection, _
 adOpenStatic, adLockOptimistic
여기서 확실히 알 수 있듯이 원래의 쿼리에 표준 WHERE 절만 추가되었습니다.
WHERE DriveSize > 50
컴퓨터의 드라이브 E에 대한 정보만 필요한 경우에는 어떻게 해야 할까요? 문제 없습니다. 다음과 같이 적절한 Where 절만 추가하면 됩니다.
WHERE Drive = 'E:'
다음은 디스크 드라이브가 설치되지 않은 컴퓨터의 컬렉션을 반환하는 조금 더 복잡한 쿼리입니다.
objRecordSet.Open _
 "SELECT Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "FROM Computers LEFT JOIN DiskDrives " & _
 "ON Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "GROUP BY Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "HAVING (DiskDrives.Drive) Is Null " & _
 "ORDER BY Computers.ComputerName", _
 objConnection, adOpenStatic, adLockOptimistic
이 쿼리는 조금 더 복잡하며 지면 관계상 작동 방식은 설명하지 않겠습니다. 하지만 가장 중요한 점인 의도대로 작동한다는 것은 확실합니다.
다음으로 중요한 것은 '관계'입니다. 이것은 여러 번 언급했지요. 그렇다고 해서 관계가 항상 올바르다는 의미는 아닙니다. 영화 "애니 홀(Annie Hall)"에서 마지막에 Woody Allen이 말한 것처럼 말이지요. "관계... 이건 마치 상어와 같아요. 계속 앞으로 나아가지 않으면 죽거든요. 지금 우리 손에 놓인 건 죽은 상어라고 생각해요." Woody Allen이 내부 조인과 외부 조인에 대해서 알았더라면 좋았을 텐데요. 이 쿼리 방법을 사용하면 언제나 성공적인 관계를 유지할 수 있을 것입니다.

Microsoft Scripting Guys는 Microsoft에서 고용되어 일하고 있는 Microsoft의 직원들입니다. 이들은 좋아하는 야구 경기와 기타 여러 활동을 하는 시간을 제외하고는 항상 TechNet 스크립트 센터를 운영합니다. 자세한 내용은 www.scriptingguys.com에서 확인하십시오.


 Exchange Q&amp;A: 설치, 메시지 저널링, 저장소 옵션 및 기타 정보
Exchange Q&A
설치, 메시지 저널링, 저장소 옵션 및 기타 정보
KC Lemson and Nino Bilic

Q: Exchange Server 2007 설치 프로그램을 실행할 때 선행 조건 검사를 건너뛸 수 있습니까? 선행 조건 검사에서 발견된 모든 문제를 해결하는 데 시간을 허비하고 싶지 않습니다. 그냥 설치 프로그램을 실행하면 바로 설치 프로세스가 시작되도록 하고 싶습니다.

A: 간단히 대답하자면 불가능합니다. 선행 조건 검사에서 발견된 문제로 인해 설치가 계속 진행되지 않거나 장기적으로는 Exchange 환경에 악영향이 초래될 수도 있으므로 반드시 모든 문제를 해결해야 합니다.
일부 관리자들은 ExBPA.PreReqs.xml 파일(Exchange 2007 설치 관련 선행 조건이 수록된 파일)을 편집하여 설치를 차단하는 검사 항목을 제거하려고도 합니다. 그러나 이 XML 파일은 디지털 서명되어 있고 내용을 수정하면 서명이 무효화되므로 이러한 방법은 통하지 않습니다.
이런 식으로 정상적으로 작동하지 않는 설치는 수행되지 않도록 방지됩니다. Exchange 2007을 여러 환경에서 테스트한 결과 일부 구성 및 설정이 특정 환경에서 보다 효과적으로 작동할 뿐만 아니라 일부 환경에서는 중대한 문제가 발생한다는 사실을 알게 되었습니다. 선행 조건 검사는 이러한 경험과 테스트 결과를 바탕으로 설치 성공률을 최대한 높이기 위한 장치입니다.
Exchange 2007 선행 조건 검사 자체에 문제가 있어 설치가 차단되었다면 Exchange 지원 팀에 지원을 요청해야 합니다.

Q: 설치 로그는 어디에 있습니까? C: 드라이브의 루트에서는 찾을 수 없습니다.

A: 이제 모든 설치 로그는 %SYSTEMDRIVE%\ExchangeSetupLogs 디렉터리(대부분 설치의 경우 c:\ExchangeSetupLogs)에 저장됩니다. 이 디렉터리에는 여러 파일이 있는데 그 중 다음 두 가지 파일만 주로 보면 됩니다.
ExchangeSetup.log 설치 프로그램을 실행할 때 사용된 작업과 매개 변수에 대한 정보가 들어 있는 로그입니다. 서버 역할을 구성하기 위해 실행된 작업에 대한 정보도 이 로그에 기록됩니다. 또한 서버 설치와 관련한 대부분의 정보와 서비스 팩 설치 정보도 이 파일에서 확인할 수 있습니다.
ExchangeSetup.msilog 이 파일에는 설치 과정의 압축 풀기 단계에 대한 정보가 들어 있습니다. Microsoft® Installer가 임시 위치에서 대상 위치로 파일을 복사할 때 이 파일에 정보를 기록합니다. 따라서 설치 시 파일을 복사하는 기능이나 파일에 액세스하는 기능과 관련한 문제가 발생한 경우 이 로그가 문제 해결에 도움이 될 수 있습니다.

Q: 선행 조건 검사가 Exchange Server BPA(Best Practices Analyzer)를 기반으로 한다는 것은 알고 있지만 선행 조건에 대한 보고서는 어디에서 확인해야 합니까?
A: 선행 조건 검사를 수행하는 중에 BPA에서 생성된 보고서는 다음 폴더에 있습니다.
%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs
이 파일의 이름은 다음과 같은 표준 형식으로 지정됩니다.
ExBPA.<dateandtime>.data.xml
선행 조건 검사에서 찾은 항목을 확인하려면 표시된 오류 메시지가 들어 있는 XML 파일을 찾아 해당 메시지 바로 위에 나와 있는 테스트된 규칙 정의를 참조하면 됩니다.
Q: 설치 로그를 읽으려면 어떻게 해야 합니까? 어떤 방법이 있습니까?
A: 일반적으로 설치 로그는 두 가지 방법으로 읽을 수 있습니다. 즉, Exchange 관리 셸에서 Get-SetupLog를 실행하거나 메모장 또는 주로 사용하는 텍스트 편집기에서 설치 로그 파일을 열면 됩니다.
Get-SetupLog를 사용하는 경우 경고 또는 오류는 다음과 같은 방법으로 확인할 수 있습니다.
Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error
설치 오류를 보기 좋게 표시하려면 Exchange 2007 PowerShell Scriptacular 데모 팩에서 제공되는 Out-HTML.ps1 및 Out-IE.ps1 스크립트를 사용해야 합니다. 자세한 내용은 msexchangeteam.com/archive/2006/12/27/431998.aspx 블로그를 참조하십시오.
해당 스크립트를 구했으면 Exchange 스크립트 폴더(기본 위치: c:\program files\microsoft\exchange server\scripts)에 저장하고 다음을 실행합니다.
Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE
그러면 설치 중에 발생한 오류가 HTML 보기로 나타나는 탐색하기 쉬운 브라우저 창이 열립니다(그림 1 참조).
그림 1 설치 로그를 쉽게 읽을 수 있는 형식으로 보여주는 Out-HTML 및 Out-IE
그림 1 설치 로그를 쉽게 읽을 수 있는 형식으로 보여주는 Out-HTML 및 Out-IE
반면 메모장을 사용하여 exchangesetup.log를 읽을 경우에는 다음 팁을 참조하십시오.
  • 설치 프로그램 실행의 시작 부분을 찾으려면 [0] Starting Microsoft Exchange 2007 Setup을 검색합니다.
  • 설치 프로그램 실행의 끝 부분을 찾으려면 [0] End of Setup을 검색합니다.
  • 주요 설치 작업은 [0] **************로 구분됩니다.
  • 설치 프로그램을 실행한 계정을 찾으려면 [0] Logged on user를 검색합니다.
  • 설치 시에 사용된 도메인 컨트롤러를 확인하려면 [0] Setup will use the domain controller를 검색합니다.
일반적으로 메모장을 사용하여 설치 로그를 검토할 때에는 파일의 끝부분부터 시작하여 시간의 역순으로 문제를 확인해야 합니다. 대개 오류는 설치 로그의 맨 마지막에 기록되기 때문입니다.

Q: PBX에 Exchange 2007 통합 메시징을 사용할 수 있습니까?

A: 가능합니다. microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx에서 지원되는 VoIP 게이트웨이 및 PBX의 목록을 확인하시기 바랍니다. 지원되는 제품 목록이 변경되는 경우 변경 내용이 이 페이지에 추가됩니다.
Q: 클라이언트에서 Small Business Server 2003과 Exchange를 실행하고 있는데 회사 정책으로 인해 모든 메일을 모니터링해야 합니다. 모니터링을 수행하기 위해 모든 들어오는 메일과 나가는 메일의 복사본을 관리자 계정으로 보내려고 합니다. 어떻게 해야 합니까?
A: 특정 사서함 데이터베이스에서 보내고 받는 모든 메시지의 복사본을 별도의 저널링 사서함에 보관하는 메시지 저널링 기능을 사용해야 합니다. go.microsoft.com/fwlink/?LinkId=93725에서 저널링된 복사본의 세부 설정(예: 숨은 참조의 받는 사람을 캡처할지 여부)을 구성할 수 있는 다양한 방법을 알아보고, 고급 기능을 제공하는 추가 도구를 다운로드할 수 있습니다. Exchange 2003의 저널링 기능은 데이터베이스별 수준으로 작동하므로 해당 데이터베이스에 포함된 모든 사용자가 저널링됩니다. 저널링된 메시지를 보관할 사서함을 만든 후에는 Exchange System Manager에서 사서함 저장소의 속성으로 이동하여 해당 저장소의 사서함에서 보내고 받는 메시지 보관 관련 설정 확인란을 선택합니다. 비즈니스 정책에 따라 사서함 관리자가 저널 사서함에서 오래된 저널링된 복사본을 자동으로 정리하도록 설정할 수도 있습니다.
Exchange 2003에는 저널링과 유사한 보관 싱크라는 기능도 있습니다. Exchange에서 다른 사서함에 메시지 복사본이 저장되는 저널링과는 달리 보관의 경우 서버 하드 드라이브의 특정 폴더에 메시지가 저장됩니다. 그렇다면 이 두 방법 중 하나를 선택하는 기준은 무엇일까요? 저널링은 주로 규정 준수를 위해 사용되는 반면 보관 싱크는 인터넷을 통해 들어오고 나가는 모든 메시지를 캡처하려는 경우 등에 유용할 수 있습니다.
Exchange 2007을 사용하면 이러한 시나리오가 크게 단순화될 뿐만 아니라 사용자 또는 DL(메일 그룹)별로 손쉽게 저널링할 수 있습니다. 사용자가 메일이 저널링되는지 여부를 알 수 없도록 하려면 전체 주소 목록에서 해당 DL을 숨기거나(DL의 구성원을 숨기는 것과는 다름), 사용자에 대한 사용자 지정 특성을 설정하고 쿼리 기반 메일 그룹(동적 메일 그룹 또는 DDL이라고도 함)을 만들어 해당 사용자 지정 특성이 있는 사용자를 모두 키 오프하면 됩니다. 전체 조직의 모든 메일을 같은 위치에 저널링하려면 저널링 규칙을 만들 때 받는 사람 필드를 비워 둡니다. 또한 Exchange 2007에서 데이터베이스별 저널링 이외의 저널링 방식을 사용하려면 해당 사용자의 Enterprise CAL(클라이언트 액세스 라이선스)이 필요합니다. 자세한 내용은 microsoft.com/exchange/howtobuy/licensingFAQ.mspx를 참조하십시오. CAL 또는 다른 기능이 필요 없으면 Exchange 2003의 데이터베이스별 저널링 기능을 계속 사용해도 됩니다. 마지막으로, 2006년 12월호 TechNet Magazine에서 David Strome의 "Exchange 2007의 더욱 강력해진 저널링" 기사(technetmagazine.com/issues/2006/12/journaling)를 참조하십시오.

Q: 조직의 모든 사용자가 Microsoft Office 2003을 사용하고 있으며 2008년으로 예정된 하드웨어 교체 시점까지 2007 Office system으로 대체할 계획이 없습니다. 그러나 지금까지 읽은 내용으로 미루어 봤을 때 사용자들이 이로 인해 일부 기능을 활용하지 못하게 될까 봐 걱정됩니다. 이러한 상황에서 사용자가 통합 메시징을 사용할 수 있습니까?

A: 물론입니다. Office 2003에서 통합 메시징 기능을 사용하도록 설정된 사용자는 사서함을 통해 음성 메일 메시지와 팩스를 받을 수 있을 뿐만 아니라 전화를 통해 사서함에 액세스할 수도 있습니다. 단, Outlook 2007로 업그레이드하지 않을 경우 통합 메시징 기능 중 Outlook의 옵션 탭을 통해 음성 메일 설정을 구성하는 기능, Outlook의 음성 메일 메시지에 표시되는 특수한 사용자 지정 양식, 별도의 미디어 플레이어를 실행하지 않고 메시지를 즉시 재생하는 기능이 지원되지 않습니다. 또한 오디오 노트를 작성하여 음성 메일 메시지와 함께 저장하는 기능도 사용할 수 없습니다. 하지만 통합 메시징을 사용하는 사용자는 Outlook 2007 없이도 OWA 2007을 사용하여 OWA 옵션 페이지의 통합 메시징 설정에 액세스하고 OWA의 음성 메일에 사용자 지정 양식을 사용할 수 있습니다.

Q: 회사에 이미 SAN(저장 영역 네트워크)이 구축되어 있으며 Exchange 2007을 SAN에 연결하려고 합니다. 그런데 DAS(직접 연결된 저장소)에 대해서도 많이 들은 바가 있어서 어떤 솔루션을 사용해야 할지 모르겠습니다. 어떻게 해야 할까요?

A: 이 질문의 경우에는 정답이 없습니다. 특히 SAN이 이미 구축되어 있는 경우라면 회사의 정책과 상황에 따라 결정해야 합니다. 다만 SAN을 새로 구입 또는 추가하거나 업그레이드를 고려하고 있다면 DAS도 고려해 보는 것이 좋습니다. 결정에 도움이 될만한 정보를 소개하자면, 2007년 6월 현재 Microsoft IT에서는 40,000개의 사서함을 호스트하기 위해 할당량이 500M에서 10GB에 이르는 Exchange 2007 사서함 서버를 17대 배포했습니다. 이들 모두 DAS를 이용한 CCR(클러스터 연속 복제)을 사용합니다. 9월까지 Exchange 2007 사서함 서버를 35대로 확충할 계획이며 이러한 서버에서 호스트하는 사서함 152,500개를 모두 DAS에 구축할 예정입니다. 이 정도면 DAS가 엔터프라이즈 규모에 적합하고 원활히 작동하는지에 대한 대답이 되었으리라고 봅니다. DAS는 Microsoft IT에서 사용자 할당량을 늘리고 전반적인 저장소 비용은 줄이는 데 핵심적인 역할을 해오고 있습니다. 이 토폴로지 및 배포, 그리고 그에 따른 비용 절감 효과에 대한 자세한 내용은 microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx를 참조하십시오.
모든 서버를 동일한 SAN에 연결하면 초기에는 저장소 비용이 크게 절감되는 것 같지만 위험성이 존재합니다. 예를 들어 SAN에 연결된 소프트웨어가 여러 용도로 사용되는 데 따른 문제가 자주 발생합니다. 매일 오후 5:00시에 일괄 프로세스를 실행하는 HR 응용 프로그램이 SAN에 있다면 해당 I/O 스파이크로 인해 Exchange 사용자에 상당히 안 좋은 영향을 줄 수 있습니다. 공유 SAN 배포에서는 명확한 I/O가 부족하다는 문제가 주로 발생합니다.
DAS의 또 다른 장점으로는 전담 저장소 관리자나 특별한 장비가 필요 없기 때문에 관리하기가 용이하다는 점입니다. 또한 이는 증분 형태이므로 쉽게 구입하여 나중에 확장할 수 있으며 일반적으로 가격이 저렴하므로 비용을 절감할 수 있습니다.

Q: Exchange 2007 서버를 처음으로 설치했습니다. 현재 Outlook 2003을 사용하여 연결하려고 하면 관리자가 Outlook 버전을 차단했다는 오류 메시지인 "사용 중인 Outlook 버전을 Microsoft Exchange 관리자가 차단했습니다. 도움이 필요하면 관리자에게 문의하십시오."가 나타납니다. 하지만 제가 관리자인데 차단한 적이 없습니다. 왜 그런 것인지요?

A: 정상적인 동작입니다. Exchange 2007을 설치할 때 설치 마법사가 조직에서 Outlook 2003 및 그 이전 버전 또는 Entourage 클라이언트를 실행 중인지 묻습니다(그림 2 참조). 이때 No(아니요)를 선택한 경우 이 문제가 발생할 수 있습니다.
그림 2 Exchange 2007 설치 프로그램의 레거시 클라이언트 질문
그림 2 Exchange 2007 설치 프로그램의 레거시 클라이언트 질문
설치를 완료한 후에는 Exchange 관리 콘솔 또는 Exchange 관리 셸을 사용하여 공용 폴더 저장소를 만들고 정보 저장소 서비스를 다시 시작하는 방법으로 이 문제를 간단히 해결할 수 있습니다. 이 경우 정보 저장소 서비스를 반드시 다시 시작해야 하며, 서비스를 다시 시작할 때까지 레거시 클라이언트(Outlook 2003 이하 버전)를 서버에 연결할 수 없습니다.
또한 Exchange 2007의 무인 설치를 실행할 경우에는 /EnableLegacyOutlook 스위치를 사용하여 레거시 클라이언트에 대한 질문에 어떻게 대답할지를 지정할 수 있습니다.

Q: Exchange 2007에서 서버에 연결하는 데 이전 버전의 Outlook을 사용하는지 여부가 중요한 이유는 무엇입니까? 공용 폴더 저장소를 만들고 정보 저장소 서비스를 다시 시작하면 왜 이러한 문제가 해결되는 것입니까?

A: 이 질문에 대한 답은 공용 폴더 저장소의 존재 여부와 관련이 있습니다. 이전 버전의 Exchange에서 공용 폴더 저장소는 사용자의 약속 있음/없음 데이터를 저장하는 데 사용됩니다. MAPI 또는 RPC over HTTP를 사용하여 Exchange 서버에 연결한 레거시 Outlook 사용자가 일정에 항목을 게시하면 해당 사용자의 약속 있음/없음 상태 정보도 서버의 Schedule+ 폴더라는 특수한 공용 폴더에 게시됩니다. 이는 레거시 Outlook 클라이언트가 서버에 게시된 사용자의 약속 있음/없음 데이터를 인식할 수 있는 유일한 방법이며 레거시 Outlook이 다른 사용자의 약속 있음/없음 정보를 어떻게 읽는지 인식할 수 있는 사실상 유일한 방법입니다.
Exchange 2007에서도 이러한 사항이 인식됩니다. 따라서 공용 폴더 저장소가 없으면 Exchange 2007이 이전 버전의 클라이언트를 차단하는 것입니다. Exchange 2007에서 레거시 클라이언트 연결을 허용한다면 Outlook이 약속 있음/없음 데이터를 게시하기 위해 공용 폴더 저장소에 연결할 수 없으므로 오류가 발생하게 되고, 사용자가 다른 사람과의 모임 일정을 예약하려는 경우 등에 수행해야 하는 약속 있음/없음 조회 기능이 동작하지 않으므로 클라이언트 기능이 제한됩니다. 공용 폴더 저장소를 만들면 문제가 해결되는 것도 바로 이러한 이유 때문입니다. 즉, Exchange 2007 서버에서 레거시 클라이언트가 약속 있음/없음 게시 기능을 사용할 수 있다는 사실을 인식하게 되므로 사서함 로그온이 허용되는 것입니다.
이 모든 사항으로 미루어 보면 Outlook 2007 클라이언트에서는 약속 있음/없음 정보를 게시하는 데 공용 폴더 저장소가 필요 없다는 사실도 알 수 있습니다. 이는 사실이지만 조금 복잡합니다.
여기서는 이 내용에 대해 자세히 설명하지 않겠습니다. 단지 Exchange 2007 서버에 공용 폴더 저장소가 있으면 Outlook 2007 클라이언트도 사용자 약속 있음/없음 데이터를 해당 저장소에 게시한다는 점만 알면 됩니다. 이는 레거시 Outlook 클라이언트를 비롯한 다른 클라이언트가 Outlook 2007 사용자의 약속 있음/없음 정보를 조회할 수 있도록 하기 위한 동작입니다. 만약 공용 폴더 저장소 이외의 위치에 정보를 저장하면 공용 폴더 저장소에 정보를 채우는 클라이언트가 없으므로 레거시 클라이언트에서 Outlook 2007 사용자에 대한 정보를 확인할 수 없습니다. 그러나 공용 폴더 저장소가 없으면 Outlook 2007 클라이언트는 약속 있음/없음 데이터를 게시하려고 하지 않습니다. 공용 저장소가 없고 모든 클라이언트가 Outlook 2007 이상이면 다른 위치에 정보의 복사본을 만드는 대신 사용자의 사서함에서 직접 일정 데이터를 읽는 다른 약속 있음/없음 정보 조회 메커니즘이 사용됩니다. 이에 대한 자세한 내용은 서버의 도움말 파일 또는 온라인 Exchange 설명서(go.microsoft.com/fwlink/?LinkId=69434)에서 가용성 서비스에 대한 정보를 찾아보십시오.

Q: 레지스트리 키를 사용하여 MAPI 클라이언트를 차단하는 내용을 다룬 기술 자료 문서 288894(support.microsoft.com/kb/288894 참조)를 읽었습니다. 서버의 레지스트리를 확인했지만 이 키가 설정되어 있지 않습니다. 저장소에서는 이 레거시 클라이언트 버전을 어떻게 차단합니까?

A: 좋은 질문입니다. 사실 Exchange 2007 정보 저장소는 해당 기술 자료 문서에서 레거시 클라이언트를 차단하는 데 사용하는 것으로 언급한 "Disable MAPI Clients" 레지스트리 값을 사용하지 않습니다. 공용 폴더 저장소가 존재하지 않을 경우 해당 레지스트리 키를 수정하여 클라이언트 차단을 해제할 수도 있기 때문입니다.
Outlook 2007 이전 버전의 클라이언트를 차단하는 동작은 Exchange 2007 정보 저장소에 하드 코드되어 있습니다. 서비스 시작 시 저장소는 공용 폴더 저장소가 존재하는지 여부를 확인하여 Outlook 2007만 사서함에 연결하도록 허용할지 아니면 이전 버전도 사서함에 연결하도록 허용할지를 결정합니다. 이 검사 작업은 서비스 시작 시에만 수행됩니다. 때문에 공용 폴더 저장소를 만든 후에 변경 내용을 적용하려면 정보 저장소 서비스를 다시 시작해야 합니다.

KC Lemson은 Exchange Server 팀의 사용자 환경 관리자로, 현재 유명 비정규 대학에서 박사 학위 취득을 준비하고 있습니다.
Nino Bilic은 Exchange Server 팀의 지원 기능 프로그램 관리자로, Forza Motorsports 2에서 전문 카레이서가 되는 데 열중하고 있습니다.


 Security Watch: 사용자 계정 컨트롤의 장기적 영향
Security Watch
사용자 계정 컨트롤의 장기적 영향
Jesper M. Johansson

관리자로 실행하는 데 따른 문제점은 너무나 자명합니다. 바로 사용자를 공격하는 맬웨어나 이러한 사용자가 실행하는 응용 프로그램이 감염된 컴퓨터의 90% 이상에서 모든 권한을 가진다는 점입니다. Windows Vista의 UAC(사용자 계정 컨트롤) 기능은 보편적인 보안 문제, 즉
현재 Windows 플랫폼을 사용하고 있는 사용자 중 90% 이상이 관리자 권한으로 실행하는 데 따른 문제를 해결하기 위해 Microsoft에서 내놓은 방안이라고 할 수 있습니다. 필자도 그렇게 하고는 있지만 Windows® XP에서는 표준 사용자로 실행할 수 있다 해도 그에 따라 상당히 불편한 점도 있을 수 있습니다. 예를 들어 자주 이동하면서 Windows XP를 사용하는 경우 표준 사용자로 실행하면 시스템의 표준 시간대를 변경할 수 없습니다.
UAC는 이러한 모든 상황을 해결할 수 있는 기능입니다. 사실 UAC가 단순히 하나의 기능일 뿐이라는 것은 여러분이 첫 번째 가지는 잘못된 생각입니다. UAC는 다소 복잡한 여러 기능으로 구성된 기능 모음이라 할 수 있습니다. 여기서 UAC의 구현 세부 사항에 대해 자세히 분석하지는 않겠습니다. 자세한 기능 분석은 2007년 6월호 TechNet Magazine에서 Mark Russinovich의 기사(technetmagazine.com/issues/2007/06/UAC)를 참조하시기 바랍니다.
대신 이 기사에서는 UAC란 과연 무엇인지, 이에 대한 잘못된 생각으로는 어떤 것이 있는지, 그리고 UAC가 Windows Vista®를 실행하는 시스템의 관리 방식에 어떠한 영향을 미치는지를 객관적으로 살펴보도록 하겠습니다.

UAC 표시 방식
가장 명확하게 드러나는 UAC의 기능은 그림 1에 나와 있는 권한 상승 대화 상자입니다. 사실 Windows Vista 사용자에게 UAC가 무엇인지를 보여 주는 대표적인 예를 제시해 보라고 한다면 아마 대부분이 성가신 권한 상승 대화 상자를 꼽을 것입니다.
그림 1 관리 승인 모드의 UAC 관리자 승인 대화 상자
그림 1 관리 승인 모드의 UAC 관리자 승인 대화 상자
UAC는 확실히 가시적이고 이와 관련된 모든 의견을 참조하더라도 UAC에 대한 대부분의 논의가 UAC가 진정 무엇인지를 확실히 설명하지는 않는다고 봅니다. 사실 여기에는 혼란을 야기할 소지가 다분히 있습니다. 자칭 전문가라 하는 비평가들은 "Vista의 가장 성가신 기능"과 같은 제목으로 기사, 블로그 게시물, 뉴스그룹 항목을 작성하여 많은 사용자가 이 기능을 사용하지 않는다는 사실과 그 이유에 대해서 언급하고 있습니다.
이렇게 UAC의 이론을 이해하려는 사용자가 거의 없다는 현실을 감안하여 UAC가 과연 무엇인지를 먼저 살펴보도록 하겠습니다.

UAC란
UAC는 보다 많은 사람이 표준 사용자로 Windows를 실행하도록 하려는 노력의 일환이라고 할 수 있습니다. 이러한 맥락으로 볼 때 Windows Vista의 UAC는 버전 2.0에 해당합니다. 버전 1.0의 경우 Windows NT® 3.1에 최초로 도입되어 사용자가 관리자 이외의 사용자로 Windows를 실행할 수 있도록 하는 데 사용되었습니다. 이 버전은 16비트 Windows 3.1부터 Windows 3.11, Windows 95, Windows 98 및 Windows Me에까지 사용되었지만 어떤 제품에서도 낮은 권한의 사용자라는 개념은 없었습니다. 관리자 이외의 사용자는 실제로 수많은 요인에 따라 유용한 작업을 수행할 수 있는 경우도 있었지만 Windows XP 및 Windows Server® 2003 이상에서는 최소 사용자 권한이 불편하거나 아무 쓸모가 없는 경우가 잦아졌습니다. Windows Vista에는 대화형 사용자 권한과 관련하여 쉽게 적절한 작업이 수행될 수 있도록 하는 데 초점을 둔 일련의 기술이 처음으로 적용되었습니다.
UAC가 관리자로 실행되는 응용 프로그램을 그렇지 않은 응용 프로그램으로부터 보호하려는 목적으로 사용되는 것이 사실이기는 하지만 이것이 UAC의 주된 용도는 아닙니다. UAC의 주된 용도는 보다 많은 사용자가 표준 사용자로 실행하도록 유도하여 개발자가 표준 사용자로 작동되는 프로그램을 더 많이 작성하게끔 하여 사용자의 권한을 높여야 하는 상황을 줄이는 데 있습니다. 그리고 개발자들이 UAC 호환 응용 프로그램을 많이 만들수록 사용자에게 표시되는 대화 상자의 수가 줄고 사용자 환경이 개선될 것입니다. 이 과정에서 대부분의 사용자가 관리자로 실행하지 않게 되고 권한 상승 대화 상자가 표시될 경우 이에 대해 의문을 가지게 된다면 그야말로 이상적인 결과라고 할 수 있습니다. 그리고 대화 상자가 줄어들수록 사용자가 권한 상승을 허용할 때 신중을 기하게 될 가능성이 늘어납니다.
이 이론을 더 확대해 보면 맬웨어가 줄어든 것일 수도 있지만 사용자 환경 개선은 사용자가 UAC를 사용하는지 여부에 달려 있고, 이는 다시 개발자가 UAC를 사용하여 작동하도록 소프트웨어를 작성하고 사용자가 대화 상자를 아무런 생각 없이 클릭하여 무시해도 되는 것으로 여기지 않으며 권한 상승 요청이 적절한지를 실질적으로 고려하는지 여부에 달려 있습니다.
가능한 한 관리자 이외의 사용자로 실행할 수 있는 사용자 수를 늘리겠다는 주된 목표를 달성하기 위해 UAC는 다음과 같은 몇 가지 세부 목표를 만족하도록 디자인되었습니다.
  1. 관리자 계정으로의 권한 상승이 필요한 시나리오를 줄입니다.
  2. runas.exe를 사용하거나 현재 계정을 로그아웃하고 다른 계정으로 로그인하는 이전 시스템에서보다 권한 상승이 쉽도록 합니다(가능한 경우, 자동 권한 상승 구현). 즉, ISV에서 응용 프로그램을 수정할 때까지 공백이 생기지 않도록 합니다.
  3. 관리자로 실행되는 응용 프로그램에 대해 격리 기능을 제공하여 관리자로 실행되지 않는 응용 프로그램으로부터 보호합니다.
  4. 노출된 특정 응용 프로그램을 가능한 한 낮은 수준의 권한으로 실행할 수 있도록 합니다.
이 중 두 목표는 관리자 이외의 사용자로 실행되는 사용자 환경을 개선하는 데 초점을 두고 있으며, 나머지 둘은 특히 많이 노출되는 응용 프로그램을 보호하는 데 초점을 두고 있습니다.
흥미로운 것은 이러한 목표 중 두 가지만 사람들이 흔히 UAC의 기능으로 간주하는 것과 관련이 있으며 실제 권한 상승 작업과 관련이 있는 것은 하나뿐이라는 점입니다. 게다가 UAC를 구성하는 일련의 기술 중 사용자에게 명확하게 드러나는 경우는 응용 프로그램에서 추가 권한을 요청할 때의 권한 상승밖에 없으므로 이 기능이 사용자 사이에서 많이 입에 오르내려집니다. 그러나 첫 번째 중요한 목표는 권한 상승과는 아무런 관계가 없습니다. 단지 보다 많은 사용자가 가능한 한 관리자 이외의 사용자로 실행하도록 하는 데 그 의의가 있습니다. 사실 관점에 따라 이는 권한 상승 이벤트의 수를 줄이는 것과 같다고 할 수도 있습니다.
권한 상승 작업 자체와 관련 있는 목표는 두 번째와 세 번째입니다. 두 번째 목표는 Windows XP에서보다 권한 상승이 용이하도록 하는 것과 관련이 있고, 세 번째 목표는 상승된 권한으로 실행되는 응용 프로그램을 보호하는 것과 관련이 있습니다. 그리고 나머지 목표는 완전히 다른 문제와 관련된 것입니다. 하지만 이러한 목표 모두 달성하는 데는 운영 체제 변경 작업이 필요합니다. 이러한 변경 사항에 대해서는 앞서 언급한 Mark Russinovich의 기사에 자세히 설명되어 있습니다.
이미 설명한 바와 같이 UAC를 사용하지 않도록 충고하는 자료가 수없이 많습니다. 그리고 아마 많은 사용자가 한번 사용해 보지도 않고 UAC를 비활성화할 것이며 상점에서 이미 UAC가 비활성화된 Windows Vista가 설치되어 있는 컴퓨터를 구입하는 사용자도 많을 것입니다. 판매업자가 기본 배포 이미지를 만들 때 운영 체제의 중요한 보안 기능을 비활성화하여 판매하는 것은 매우 창피스러운 일입니다.
안타깝게도 UAC를 비활성화하도록 조언하는 많은 자료는 짧은 경험을 바탕으로 한 경우가 많습니다. 컴퓨터를 설정할 때 소프트웨어를 설치하거나 필요한 변경 작업을 수행하면서 상당히 많은 대화 상자를 접하게 됩니다. 컴퓨터를 구성하는 동안의 관리 환경과 컴퓨터가 이미 안정된 상태에 있는 관리 환경에는 큰 차이가 있기 마련입니다. 뿐만 아니라 컴퓨터 사용을 처음 시작한 몇 주와 몇 주가 지난 후에는 환경이 전혀 다르게 바뀝니다. 안정적인 상태의 컴퓨터에서 UAC를 사용해 보면 전혀 성가신 기능이 아니라는 것을 알 수 있습니다.

UAC에 대한 잘못된 생각
Windows의 역사상 가장 성가신 기능을 만들기 위해 일부러 UAC를 디자인한 것은 아닙니다. 이는 오히려 지금까지와 같이 잠재적인 악의적 코드에 시스템을 자주 노출시키지 않도록 하기 위해 디자인된 유용한 일련의 기술이라고 할 수 있습니다.
현재와 같은 상황에서는 기술이 탁월한 공격자나 그러한 공격자의 도움을 받는 공격자를 UAC로 막을 수 없습니다. 악의적인 사용자가 UAC를 무력화할 방법을 생각해내지 못하면 분명히 사용자에게 UAC를 무력화하도록 요청하는 방법을 사용할 것입니다. 보안이 얼마나 쉽게 무력화될 수 있는지 우리는 경험으로 잘 알고 있습니다. 즉, 이러한 대화 상자를 무시하도록 조언을 받아 온 사용자들은 그렇게 하지 않도록 교육할 때까지 대화 상자를 무시할 것입니다. 또한 경고 대화 상자가 너무 많이 표시되고, 이러한 대화 상자의 메시지가 유용하지 않고, 사용자가 구입하는 장치 설명서에 "보안 경고 대화 상자에서 예를 클릭하여 대화 상자를 닫으십시오."라는 설명이 있는 등의 여러 가지 요인도 이러한 결과에 일조합니다.
UAC가 완벽한 보안 기능을 제공하지는 않습니다. 사실상 예전의 로컬 권한 상승 방식을 사용하는 공격자에게는 좋은 기회를 다시 제공합니다. Windows에서 대부분의 사용자는 원래 관리자로 실행했기 때문에 다른 관리자 권한으로 상승할 필요가 없었으므로 이러한 공격 방식은 크게 줄었었습니다. 다시 말하면 UAC가 이러한 공격의 특성을 지난 20여 년 동안 UNIX에 만연했던 양상으로 다시 변화시키고 있다는 사실을 부정할 수는 없습니다.
UAC는 악의적인 사용자의 개인 데이터 도용을 막을 수 없습니다. 사용자의 개인 데이터는 사용자 권한에 관계없이 액세스할 수 있습니다. 따라서 악의적인 응용 프로그램을 비롯한 모든 응용 프로그램도 이 데이터에 액세스할 수 있습니다. UAC가 이러한 상황을 바꿀 수는 없습니다. 따라서 어쨌든 최종 사용자에게는 항상 경계하고 조심하고 주의하도록 교육해야 합니다.
UAC는 상승된 권한으로 실행되는 응용 프로그램을 같은 로그인 세션에서 보통 권한으로 실행되는 응용 프로그램을 통한 모든 공격으로부터 보호하도록 디자인되지 않았습니다. UAC가 일부 취약한 프로세스를 격리하기는 하지만 샌드박스 응용 프로그램을 서로 격리하지는 않습니다.

소문
Microsoft 자체도 UAC에 대한 소문과 오해를 불러일으키는 데 일조했다고 할 수 있습니다. 예를 들어 Windows Vista 보안 가이드의 "악성 프로그램 방어" 장에서는 UAC를 맬웨어에 대해 보호 기능을 제공하는 주요 기술로 소개하고 있습니다(microsoft.com/technet/windowsvista/security/guide.mspx). 나아가 대부분의 경우 UAC를 활성화한 상태로 Windows Vista를 실행할 것을 권장하고 UAC를 사용하여 맬웨어를 방어할 때 고려할 사항을 나열하고 있습니다. 그러나 정작 중요한 사항은 빠져 있습니다. 바로 UAC가 맬웨어를 막는 용도로 만들어지지도 않았고 그렇게 하지도 못한다는 점입니다.
오늘날 세계 최고의 Windows 보안 전문가라고 할 수 있는 사람들 중에 일부만 UAC의 기능을 완벽히 이해하고 있는데 그 중 하나가 Joanna Rutkowska입니다. 그녀는 2007년 2월 4일자로 게시한 블로그 게시물에서 UAC에 대해 "Vista에서 처음 선보이는 새로운 보안 메커니즘으로, 사용자가 관리자 대신 제한된 계정을 사용하여 작업하도록 강제하는 것이 이것의 주된 목적이다"(theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html)라고 설명했습니다. 거의 정확한 표현이지만 필자라면 "강제하는"이라는 표현 대신 "허용하는"이라는 표현을 사용했을 것입니다.
어쨌든 이는 Windows에 대한 일반적인 공격 특성에 큰 변화를 가져옵니다. 이 칼럼에서 앞서 언급한 것처럼 사용자가 로컬 표준 사용자에서 로컬 관리자로 권한을 상승할 수 있는 로컬 권한 상승의 취약점은 Windows 플랫폼에서 그다지 중요성을 가지지 않았습니다.
그러나 Windows Vista에서는 사용자가 관리자 대신 표준 사용자로 실행함에 따라 갑자기 로컬 권한 상승 문제가 중요하게 대두되었습니다. 아쉽게도 이와 관련해서 UAC는 한계를 가지고 있습니다. 즉, 효과적인 격리 방법이 없기 때문에 같은 데스크톱에서 여러 프로세스를 격리할 보안 경계가 존재하지 않습니다. OS에는 명백하고 불필요한 통신 통로를 차단하는 보호 수단이 몇 가지 포함되어 있지만 그러한 통신 통로를 모두 차단할 수는 없습니다. 따라서 Microsoft는 존재하지 않는 이러한 보안 경계에 대한 위반을 보안 위반으로 간주하지 않습니다. Mark Russinovich는 blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx의 블로그 게시물에서 이에 대해 자세히 지적했습니다.
Mark의 지적은 아주 정확합니다. Microsoft는 동일한 데스크톱에서 실행되는 낮은 권한 수준의 프로세스와 상승된 권한 수준의 프로세스 간에 보안 경계가 존재하지 않는다는 사실에 대해 잘 알고 있습니다. 동일한 데스크톱의 프로세스 간에 격리 기능을 구현하려 한 적이 아예 없으므로 동일한 데스크톱의 프로세스 간에 격리 기능이 존재하지 않는다는 사실을 보안 취약점이라고 부르는 것은 적절하지 않다고 할 수 있습니다. 물론 이 때문에 맬웨어를 방어하는 1단계 메커니즘으로서 UAC의 가치가 축소되기는 하지만 Microsoft에서 제공하는 문서를 포함하여 여러 자료에서 그렇게 소개를 하더라도 애초에 UAC는 이러한 용도로 만들어지지 않았다는 점을 유념해야 합니다.
이로 인해 보다 많은 사용자가 가능한 한 표준 사용자로 실행할 수 있도록 한다는 주된 목표와 관련하여 UAC의 가치가 축소되는 것일까요? 그렇지 않습니다. 낮은 수준의 권한으로 실행되는 악의적인 응용 프로그램과 상승된 권한으로 실행되는 응용 프로그램 간에 확실한 보안 경계가 존재하지 않는다고 해서 많은 사용자가 UAC를 효과적으로 사용하여 Windows Vista 컴퓨터를 표준 사용자로 실행할 수 있다는 사실이 변하는 것은 아니기 때문입니다. 몇몇 업계 관계자의 충고와는 반대로 필자는 Windows Vista 보안에 관한 서적과 이 기사를 Windows Vista에서 표준 사용자로 작성하고 있으며 아직까지 작성한 내용의 수락 여부를 묻는 UAC 대화 상자가 표시된 적은 없었습니다.
UAC가 일부 보안 문제를 완화하지 않거나 필자를 포함해서 많은 사용자가 원하는 속성(맬웨어에 대한 1단계 보호 기능)을 제공하지 않는다고 해서 보안 기술이 아니라고 할 수는 없습니다. 별도의 사용자 계정을 통해 사용자를 식별하는 기능 자체로는 시스템이 맬웨어에 감염되는 것을 막을 수 없지만 그렇다고 해서 사용자 계정이 보안 기술이 아니라고 억지 해석할 수는 없습니다. UAC가 사용자의 기대대로 모든 문제를 해결해 주지는 않는다고 해서 UAC로 해결되는 문제가 아무런 의미가 없는 것으로 치부할 수는 없으니까요.
UAC는 시스템으로부터 악의적인 코드를 차단하고 교묘한 프로그래밍 등을 통해 감염된 경우 이러한 코드가 실행되지 못하도록 하는 역할을 크게 개선된 Windows 방화벽, Windows Defender 및 기타 맬웨어 방지 프로그램에 맡깁니다. 이러한 보안 기술조차도 맬웨어를 100% 방지하지는 못하지만 모두 그 가치를 인정 받고 일정한 역할을 담당하고 있습니다. 그러나 이미 여러 번 밝혔듯이 아무리 모든 공격 통로를 차단하더라도 성공적인 보안은 결국 사용자의 손에 달려 있습니다. 키보드 앞에 앉은 사용자가 악의적인 코드 실행을 허용하도록 선택하면 세상에 존재하는 어떠한 보안 기술도 소용이 없게 됩니다.

최선의 방법
그렇다면 UAC는 어떻게 사용해야 할까요? 관리자 승인 모드에서 관리자로 실행해야 할까요? 여러 차례 언급했듯이 UAC는 낮은 권한 수준의 응용 프로그램을 통해 동일한 데스크톱에서 실행되는 권한 수준이 높은 응용 프로그램에 코드가 주입되는 것을 방지하지 않습니다. 따라서 관리자 승인 모드로 실행하거나, 표준 사용자로 실행한 후 세션 내에서 권한을 상승(자격 증명 입력을 통한 권한 상승)시키더라도 효과적으로 격리되지 않습니다. 그러나 두 가지 경우 모두 Windows XP에서 관리자로 실행하거나 UAC를 비활성화한 상태로 Windows Vista를 실행하는 것보다는 훨씬 바람직합니다. 어쨌든 결국 맬웨어는 대화형 데스크톱에서 권한이 상승된 응용 프로그램을 이용하도록 작성될 테니까요.
그러므로 실행 방법은 사용자의 위험 관리 방식에 따라 달라집니다. 표준 사용자로 실행하고 자격 증명 입력을 통한 권한 상승을 통해 응용 프로그램의 권한을 상승시키면 권한이 상승된 응용 프로그램의 사용자 환경이 일반 사용자 환경과 달라집니다. 이렇게 하면 권한이 상승되지 않은 악의적인 응용 프로그램이 권한이 상승된 응용 프로그램의 사용자 환경을 감염시키는 감염 공격의 위험을 줄일 수는 있지만 권한이 상승되지 않은 응용 프로그램에서 권한이 상승된 응용 프로그램을 제어할 가능성이 완전히 제거되지는 않습니다. 몇 주 전에 실행된 악의적인 응용 프로그램이 지금 실행하는 권한이 상승된 응용 프로그램을 쉽게 감염시킬 수는 없지만 현재 실행 중인 악의적인 응용 프로그램은 권한이 상승된 응용 프로그램을 제어할 수도 있습니다. 따라서 사용의 편의성과 관련하여 관리자 승인 모드 또는 자격 증명 입력을 통한 권한 상승을 사용하는 데 따른 위험성을 고려해야 합니다.
이러한 위험성이 고려된 몇 가지 최선의 UAC 사용 방법이 그림 2에 요약되어 있습니다. 필자의 개인적인 견해로는 가장 복잡한 옵션이 단연 최고라고 생각합니다. 그러나 위험성이 매우 높거나 공격에 크게 노출되어 있는 경우에는 표준 사용자로 실행하고 절대로 권한을 상승하지 않는 것이 제일 좋습니다. 어떤 면에서는 Windows XP에서 관리자로 실행하는 경우 일단 악의적인 코드를 실행했다면 컴퓨터가 100% 감염되었다고 봐야 합니다. Windows Vista의 경우에는 악의적인 코드를 실행한 후 해당 세션에서 권한을 상승한 경우 악의적인 코드에 감염될 가능성이 높습니다. 각자가 가장 효과적이라고 생각하는 방법을 골라 자신이 만족할 수 있는 보호 수준을 제공하는 방법이 최선입니다.
Figure 2 계정 권한 상승에 대한 최선의 방법 (Close Figure 2)

보호 수준 | 권한 상승 방법
매우 나쁨 | UAC 해제
나쁨 | 관리자로 자동 권한 상승
좋음 | 관리자 승인 모드로 실행
매우 좋음 | 표준 사용자로 실행한 다음 별도의 관리자 계정으로 권한 상승
가장 좋음 | 표준 사용자로 실행한 다음 UAC를 사용하여 권한 상승하는 대신 별도의 관리자 계정으로 사용자 전환
보안을 크게 우려한다면 응용 프로그램을 반드시 관리자로 실행해야 한다는 공급업체의 말을 그대로 믿지 마십시오. 이러한 주장이 사실이 아님을 잘 보여 주는 예로 Visual Studio® 2005 서비스 팩 1을 들 수 있습니다. Visual Studio를 실행하면 관리자로 실행해야 한다는 대화 상자가 나타납니다. 그러나 이는 특정 작업을 수행해야 하는 개발자에게만 적용되는 사항입니다. 자세한 내용은 msdn2.microsoft.com/en-us/vstudio/aa972193.aspx를 참조하십시오.

사용자 권한 부여
보다 많은 결정을 보다 현명하게 내리도록 사용자에게 권한을 부여해야 합니다. 보안 결정을 사용자가 내리도록 해서는 안 된다고 믿는 보안 전문가들도 있습니다. 이러한 그들의 주장 이면에는 사용자가 보안에 관심이 없을 뿐만 아니라 올바르게 보안을 유지하는 방법을 배울 만한 지식도 갖추지 못했다는 의식이 깔려 있습니다. 원하는 바이러스 백신 기술을 사용하도록 지시하는 것만이 제대로 보호할 수 있는 방법이라는 것입니다.
그러나 사용자를 목표로 삼은 공격으로부터 사용자를 완전히 보호할 수 있는 기술은 없습니다. 거의 모든 피싱 공격을 비롯하여 오늘날 이용되는 대부분의 공격 방식은 컴퓨터에 사용되는 기술이 아니라 주로 사용자와 사용자의 컴퓨터 실행 방식을 대상으로 합니다. 이러한 공격 방식 중 가장 효과적인 방법은 사용자에 대한 공격과 기술에 대한 공격이 결합된 형태지만, 이러한 공격 방식의 경우에도 실행을 위해서는 사용자의 개입이 필요한 경우가 많습니다. 기술을 대상으로 하지 않는 공격은 기술만으로는 막을 수 없습니다. 이에 대해서는 technetmagazine.com/issues/2006/07/SecurityWatch에서 오래 전에 자세히 다뤘습니다.
UAC는 이미 사용자가 보안 결정을 내리도록 유도하고 있지만 기술 공급업체에서는 이미 사용자가 이러한 결정을 내리지 못하도록 하는 솔루션을 제공하도록 서로 약속해 두었습니다. 사용자가 보안 결정을 성가시게 여기는 것은 사실입니다. 그러나 다른 소프트웨어의 용도를 인식할 수 있는 소프트웨어는 어디에도 없습니다. 즉, 어떠한 침입 방지 시스템도 웹 사이트에서 Windows Vista Security 제품을 판매하기 위해 사용자의 신용 카드 번호를 묻는지 아니면 베일에 가려진 범죄 조직에 제공하기 위해 묻는지를 알아낼 수 없다는 말입니다. 오직 최종 사용자만 올바른 정보를 제공 받았을 때만 이러한 사실을 판단할 수 있습니다. 소프트웨어 엔지니어는 정보를 바탕으로 보안 결정을 내려야 한다는 사실을 사용자에게 주지시키고, 그 방법을 알려 주고, 필요한 정보를 제공해야 합니다.
소프트웨어 엔지니어가 지금과 같이 사용자가 보안 결정을 내리지 못하도록 하는 방식을 고집하면 결국 사용자를 보호할 수 없다는 결론에 도달하게 될 뿐입니다. 결국 사용자는 해킹 공격과 개인 정보, 은행 계좌 번호, ID, 존엄성, 자존심이 침해 당하는 데 염증을 느끼게 될 것입니다. 이러한 상황이 발생한다면 사용자는 업계에서 판매하는 제품을 사용하지 않을 것이고 이로 인해 업계 자체가 존속되지 못하는 사태가 도래할 수도 있습니다. 첨단 기술 업계에서는 컴퓨터와 전자 상품에 보안 문제가 존재한다는 사실을 숨기기만 한다면 사용자가 업계에서 제공하는 제품을 무조건 사용할 것이라고 믿는 사람들도 있지만 이는 절대 사실이 아닙니다. 사용자가 결국에 그러한 사실을 알게 되면 더 이상 업계를 신용하지 않게 되고 업계에서 제공하는 제품을 외면하게 되어 그러한 사실을 숨김으로써 보호하려 한 업계가 오히려 무너지게 됩니다.
UAC는 사용자에게 시스템의 보안 역할을 일임하는 과정의 직접적인 단계라고 할 수 있습니다. 따라서 절대 완벽한 보안 솔루션이 될 수는 없지만 사용자가 최소한의 권한으로 실행하도록 유도하는 최초의 시도라는 점에서 올바른 방향으로 가기 위한 중요한 첫걸음이라는 점은 분명합니다.

Jesper M. Johansson 박사는 소프트웨어 보안 문제 분야의 수석 보안 엔지니어이며 TechNet Magazine의 객원 편집자로서, MIS 분야 박사 학위를 취득했고 컴퓨터 보안 분야에서 20년 이상의 경력을 보유하고 있습니다.


 The Desktop Files: Windows PE를 사용한 PC 복구
The Desktop Files
Windows PE를 사용한 PC 복구
Wes Miller

필자는 지난 칼럼에서 Windows PE의 초기 목표가 Windows PE를 배포 환경으로 만드는 것이었다는 점을 언급한 바 있습니다. 하지만 모든 훌륭한 제품이 그렇듯이 Windows PE는 배포 환경 그 이상으로 발전했습니다. 고객(초기에는 OEM)은 제조와 사용자 자동 복구를 위한 단일 솔루션을 구축하는 데 많은 노력을 기울였으며 몇몇 회사에서는
둘 모두에 사용할 수 있는 Windows® PE 솔루션을 개발하게 되었습니다.
최근 사용되고 있는 대부분의 복구 도구는 배포 프로세스를 미러링하여 시스템을 이전의 성공적 상태로 되돌리는 것에 기반을 두고 있습니다. Windows Vista®에서는 Windows XP보다 복구 작업이 훨씬 간편해졌으며 이미징 기능을 기본으로 지원합니다. 자세한 내용은 이번 호 TechNet Magazine에서 Christine Fok가 작성한 Windows Vista 백업 기술 문서를 참조하십시오.
이번 달 칼럼에서는 Windows PE를 기반으로 자체 복구 솔루션을 구축하는 방법에 대해 설명하겠습니다. 모든 Windows 라이선스 고객은 Windows PE 2.0을 Windows AIK(자동 설치 키트)의 구성 요소로 무료로 사용할 수 있습니다. 이 라이선스는 배포에만 적용되는 것이 아니라 복구 및 문제 해결을 위해 Wndows PE를 사용하는 경우에도 적용됩니다.
물론 사용자 지정 복구 솔루션을 만들고 필요에 맞게 조정하는 것을 고려해야 하겠지만 이 문서에서는 Windows XP나 Windows Vista를 배포할 때 유의해야 할 일반적인 사항에 대해 다루겠습니다. 이미징에 대해 잘 알고 있다면 사용자 지정 복구 솔루션을 만드는 것은 어렵지 않습니다.
Windows PE 복구 솔루션의 주요 구성 요소는 다음과 같습니다.
  • Windows PE
  • 이미징 유틸리티
  • 복구 솔루션을 결합하는 데 사용할 스크립트 또는 응용 프로그램
필요에 따라 SQL 지원 및 ADSI(Active Directory® 서비스 인터페이스) 지원을 포함할 수도 있습니다. SQL에 연결하면 설치에 필요한 항목을 정의하는 "BOM(제품 구성 정보)"을 시스템에 포함할 수 있는 솔루션을 간접적으로 만들 수 있습니다. 마찬가지로, Active Directory에 연결하면 컴퓨터별 계정 개체(MAO) 속성을 더 쉽게 처리할 수 있습니다.
Microsoft에서는 Windows PE에 ADSI를 포함하는 것을 지원하지 않습니다. 하지만 Windows PE에 ADSI를 포함하는 방법에 대해 설명하는 온라인 문서가 많이 있으며 올바르게 포함하기만 하면 문제 없이 작동합니다. ADSI를 포함하고 싶지 않으면 대신 SQL 지원을 추가한 다음 여기에 Windows PE 복구 도구용 워크플로를 만들 수 있습니다. ADSI 속성이 필요한 경우에는 예약된 작업이 있는 서버 시스템에서 동일한 SQL Server™를 쿼리한 다음 ADSI를 통해 Active Directory를 쿼리(통과 쿼리로 작동)하도록 할 수 있습니다.
이는 완벽한 솔루션도 아니고 몇 가지 스크립팅 또는 자동화 작업도 필요하지만 Windows PE에서 Active Directory와의 상호 작용을 가능하게 하는 방법입니다.
LDIFDE 유틸리티를 사용하여 Windows PE 내에서 Active Directory 정보를 읽을 수도 있습니다. 자세한 내용은 관련 기술 자료 문서(support.microsoft.com/kb/237677)를 참조하십시오. 예를 들어 다음 명령을 사용할 수 있습니다.
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
이 명령을 입력하면 지정한 컴퓨터 개체에서 x:\output.ldf로 특성을 가져오며, 이 파일에서 출력을 구문 분석할 수 있습니다.

SKU, 아키텍처 및 언어
배포할 Windows의 버전, 아키텍처 및 언어를 고려해야 합니다. 특정 로캘을 사용하는 소규모 조직에서는 Windows XP나 Windows Vista 중에서 한 가지 OS만 배포하거나 새 PC에 이미 설치되어 있는 OS를 사용하는 경우가 많습니다. x64 Windows 시스템은 아마도 아직까지는 많이 배포하지 않았을 것입니다. 그리고 대개는 한 가지 언어만 지원하면 됩니다. 하지만 여러 국가에서 활동하는 규모가 큰 조직에서는 고려해야 할 아키텍처, 버전 및 구성도 더 많습니다.
필자는 지난 칼럼에서 x64 및 x86 볼륨 이미지를 동일한 WIM(Windows Imaging Format) 파일에 저장할 수는 있지만 공간이 절약되지는 않는다는 점을 언급한 바 있습니다. 두 아키텍처를 모두 고려하여 복구 솔루션을 만들어야 하는 경우에는 각 이미지를 개별 WIM에 저장해야 합니다. 마찬가지로 Windows XP와 Windows Vista를 모두 배포하고 지원하는 경우 두 운영 체제를 동일한 이미지에 저장해도 공간이 절약되지는 않습니다. 두 배포 모두에서 2007 Microsoft® Office system과 같은 동일한 응용 프로그램의 인스턴스를 다수 포함하는 경우에만 공간 절약 효과를 볼 수 있습니다. 이 경우 응용 프로그램 파일을 여러 번 저장할 필요가 없지만 그렇다 하더라도 절약되는 공간이 많지는 않습니다.
Windows PE 부팅 방법
Windows PE 1.6
원격 설치에서 PXE 부팅
서비스(RIS)(RAMDisk 없음)
하드 디스크 드라이브
USB 플래시 드라이브
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB 플래시 드라이브
RAMDisk 하드 디스크 드라이브

Windows PE 2.0
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB 플래시 드라이브
RAMDisk 하드 디스크 드라이브

RIS에서 PXE 부팅 PXE가 필요한 경우에는 적합하지만, 이 방법을 사용할 경우 PXE RAMDisk를 사용할 때보다 부팅하는 데 시간이 많이 걸리고 네트워크 리소스도 더 많이 사용됩니다.
하드 디스크 드라이브 최소한의 메모리를 사용하지만 드라이브를 잠급니다. 이 방법은 이중 파티션 간을 전환하면서 복구하는 경우 사용하기에 적합합니다.
USB 플래시 드라이브 부팅이 간편합니다. 하지만 OEM이 해당 부팅 시스템을 UFD 부팅 가능한 것으로 검증하지 않았으며 UFD 부팅을 기본으로 지원함을 나타내는 Windows Vista Capable 로고가 없는 경우에는 RAMDisk 시나리오 및 RAMDisk를 사용하지 않는 시나리오 모두에 대해 UFD 부팅 후 예기치 않은 결과가 발생할 수 있습니다. UFD에서 부팅하려면 읽기/쓰기용 고성능 플래시 드라이브가 있어야 하고 USB 컨트롤러 및 BIOS에서 고속 USB를 지원해야 합니다.
RAMDisk 부팅 기본적으로 메모리를 많이 사용하기는 하지만 최상의 성능을 제공하며 Windows PE를 메모리의 RAMDisk에 배치하므로 Windows PE가 작업에 방해가 되지 않게 합니다. 일반적으로 Windows PE 1.6을 RAMDisk에서 부팅하려면 시스템에 최소한 256MB의 RAM이 있어야 합니다. 항상 RAMDisk WIM에서 부팅하는 Windows PE 2.0의 경우 RAMDisk에서 부팅하려면 시스템에 최소한 384MB의 RAM이 있어야 합니다.

하지만 특정 Windows 버전의 여러 SKU를 동일한 WIM에 저장하는 경우 상당한 공간을 절약할 수 있습니다. 예를 들어 Windows XP Professional과 Windows XP Tablet PC Edition을 결합하거나 Windows Vista Business Edition과 Windows Vista Ultimate Edition을 결합하는 경우 동일한 릴리스 및 서비스 팩 수준의 두 SKU가 대부분의 코드와 파일을 공유하므로 공간을 효율적으로 사용할 수 있습니다.
마지막으로 언어를 고려해야 합니다. 조직의 규모가 클수록 고려해야 할 언어도 다양해집니다. Windows XP의 경우 지역화된 빌드나 MUI(Multilingual User Interface)를 사용할 수 있습니다. 완벽하게 지역화된 Windows XP 빌드의 경우 세세한 문자열에 이르기까지 거의 모든 요소가 대상 언어로 지역화되어 있습니다. 반면 MUI 언어 팩(또는 언어 인터페이스 팩)을 통해 최대한 많은 언어 문자열이 변경되긴 했지만 MUI의 기본 언어는 영어입니다. MUI는 Windows 2000에서 좋은 결과를 보여 주었고 Windows XP와 Windows Server 2003에서는 더욱 향상되었습니다.
MUI를 사용하는 조직의 경우 동일한 WIM에 다양한 언어 버전을 결합하면 좋은 결과를 얻을 수 있는데, 이는 각 언어 버전이 기본적으로 모두 영어 바이너리를 사용하기 때문입니다. 하지만 Windows Vista 이전에 릴리스된 지역화 버전의 경우에는 문제가 다릅니다. 이러한 버전에서는 바이너리 자체가 지역화되어 있으므로 동일한 바이너리도 언어마다 서로 다릅니다. 즉, 언어마다 운영 체제의 거의 모든 부분과 지역화된 응용 프로그램을 저장해야 합니다.
Windows Vista에서는 지역화된 버전(리소스가 포함된 단일 바이너리의 지역화된 부분)이 더 이상 사용되지 않는다고 볼 수도 있습니다. Windows Vista에서는 영어를 비롯하여 각 언어에 .mui 리소스 파일을 사용합니다. 모든 언어 정보가 MUI 파일에 포함되어 있기는 하지만 Windows Vista는 기본적으로 언어에 독립적입니다. 따라서 동일한 WIM에 둘 이상의 Windows Vista 언어 버전을 저장하면 공간이 크게 절약됩니다. 둘, 넷 또는 그 이상의 언어를 하나의 WIM으로 저장하면 이미지 크기가 급격하게 증가하지 않습니다. 또한 나중에 필요에 따라 다른 언어로 전환하거나 언어를 추가할 수도 있습니다.
다시 말해 자체 솔루션을 만들 때는 일치하는 바이너리를 공유하는 Windows 버전 및 기타 응용 프로그램 버전을 신중하게 검토하여 이들 모두를 단일 파일 저장소 인스턴스에 저장할 수 있도록 해야 합니다. 이렇게 하면 조직 전체에 필요한 WIM 파일의 수를 쉽게 파악할 수 있습니다.

사용자 시나리오
일반적으로 조직의 규모가 클수록 시나리오도 복잡해집니다. 그 이유는 단순히 규모가 크기 때문만이 아니라 여러 가지 변수가 발생하기 때문입니다. 즉, 사용자와 업무 조직이 많을수록 구체적인 요구 사항이 더욱 많아집니다.
필자가 기억하는 한 다국적 기업의 경우 사용자가 만 명이나 되었는데 전체 배포 프로세스를 지리적으로나 업무 조직으로나 한 곳에서 모두 관리했습니다. 이 조직의 경영자는 매우 까다로운 문제를 제시하곤 했습니다. 예를 들어 네트워크 연결 상태가 썩 좋지 않은 아프리카 특정 지역에서 근무하는 원격 사용자에 대해 많은 고민을 했는데, 이들 직원 대부분의 근무지가 전화선이 있는 곳과도 수백 킬로미터나 떨어진 곳에 있었으니 이러한 염려가 지나치다고 할 수도 없었습니다. 이 경영자는 이들 사용자가 먼 거리를 이동하거나 며칠씩 시스템이 다운된 상태로 두지 않고 자체적으로 시스템을 복구할 수 있는 방법이 있는지 알고자 했습니다.
따라서 제품을 개발할 때는 사용자가 처할 수 있는 상황을 고려하여 복구 솔루션도 제품의 일부로 포함해야 합니다. 다시 말해, 제품을 개발할 때는 고유의 비즈니스 요구 사항뿐만 아니라 다양한 사용자 계층과 관련된 여러 가지 복잡한 문제도 고려해야 합니다. 간략한 설명을 통해 사용 사례를 포함함으로써 지원해야 할 각 최종 사용자 유형에 대해 설명해야 합니다. 이렇게 하면 복구 솔루션에서 우연히 빠트린 사용자를 쉽게 찾아낼 수 있으며 각 사용자 유형별 요구 사항을 반영할 수 있습니다.

알맞은 Windows PE 버전
요구 사항에 맞는 Windows PE 버전을 결정하는 것도 중요한 문제입니다. 이 칼럼의 이전 호를 읽으면 버전을 결정하는 데 도움이 될 것입니다. 여기서는 버전을 결정하는 방법을 좀 더 명확하게 설명하겠습니다. 다음 중 하나라도 해당한다면 Windows PE 1.6을 사용해야 합니다.
  • Windows XP(또는 Windows Server 2003)만 복구하려는 경우
  • ACPI(고급 구성 및 전원 인터페이스)를 지원하지 않는 시스템을 복구하려는 경우
  • RAM 크기가 512MB 미만인 시스템을 복구하려는 경우
  • RAM 크기가 256MB 미만이며 PXE(Pre-Boot eXecution) 부팅해야 하는 시스템을 복구하려는 경우
다음 중 하나라도 해당한다면 Windows PE 2.0을 사용해야 합니다.
  • Windows Vista(또는 Windows Server 2008)만 복구하려는 경우
  • Windows Vista와 Windows XP를 복구하려는 경우
  • BitLocker™를 사용하는 경우
ImageX("만들기, 업데이트 및 저장" 단원 참조)와 대부분의 타사 이미징 솔루션은 두 Windows PE 버전 모두에서 문제 없이 작동합니다.

Windows PE 부팅
다음으로 고려해야 할 사항은 Windows PE 부팅 방법입니다. 부팅 방법을 결정할 때는 사용자 시나리오가 중요한 역할을 합니다. 사용자가 복구용 CD나 DVD를 휴대하는 것이 가능한지, 출장 중에 랩톱에 CD나 DVD를 휴대하는 것이 가능한지, 그리고 이러한 복구 미디어를 최신 상태로 유지하는 방법은 무엇인지 등을 검토해야 합니다. 이동식 미디어에 저장된 복구 이미지는 얼마 되지 않아 쓸모가 없어집니다.
아직까지는 보조 하드 디스크 파티션을 이용하는 것이 가장 보편적인 방법이며, 또 다른 방법으로 PXE 부팅이 있습니다. 이 외에도 외부 USB 드라이브나 UFD(USB 플래시 드라이브)를 사용할 수도 있지만 이 경우 해당 하드웨어가 UFD 장치에서 부팅하는 것을 확실히 지원해야 합니다.
"Windows PE 부팅 방법" 추가 기사에서는 각 Windows PE 버전에서 지원되는 부팅 방법을 소개하고 각 방법을 사용할 때 고려해야 할 중요한 사항에 대해 설명합니다.
Windows PE 부팅의 목적은 다음과 같은 특정 조건을 만족하면서 복구 프로세스를 시작하는 데 있습니다.
  • 사용자의 작업이 최소화되어야 합니다.
  • 이동하는 부분(이동식 미디어 또는 이동식 장치)이 최소화되어야 합니다.
  • PC에서 네트워크에 연결할 수 없는 상황에서도 가능해야 합니다.
  • PC를 로컬로 부팅할 수 없어서 Windows를 부팅할 수 없는 경우에도 가능해야 합니다.
관리자들은 흔히 드라이브 오류를 염려하여 Windows PE를 그대로 또는 RAMDisk에 넣어서 하드 디스크에 저장하는 것은 현실적인 방법이 아니라고 생각합니다. 그러나 최근 출시되는 디스크의 안정성이 향상된 점, 그리고 실제 드라이브에서 물리적 오류가 발생하는 경우 어차피 사용자 스스로는 시스템을 복구할 수 없다는 점을 감안하면 이 방법은 현실적이라고 할 수 있습니다.
필자는 보조 파티션을 만들어 여기에 복구 이미지를 저장하는 방법을 좋아합니다. 파티션을 숨기는 것에 대해서는 그다지 찬성하지 않습니다. 이렇게 하면 사용자에게 혼동을 줄 뿐입니다. 파티션에 ACL(액세스 제어 목록)을 사용하는 것도 사용자가 로컬 관리자인 경우에는 쓸모가 없습니다.
Windows용 파티션을 축소("복구 파티션 만들기" 추가 기사 참조)하여 Windows PE와 복구 이미지를 저장하는 데 필요한 공간을 만들 수도 있습니다. Windows PE를 보조 파티션에 저장하려는 경우 복구 파티션에 적절한 부팅 섹터를 만든 다음 이 파티션에 Windows PE를 저장하기만 하면 됩니다. Windows AIK 및 이전 버전의 Windows PE에는 이 프로세스에 대한 설명서가 포함되어 있으므로 여기에서는 이에 대해 자세히 다루지 않겠습니다. 부팅에 사용되는 파티션은 활성으로 표시된 파티션이라는 것을 기억하고 있어야 합니다. Diskpart는 파티션을 활성 또는 비활성으로 설정하는 데 사용하는 명령입니다. Windows 내에서 또는 Windows PE 복사본 내에서 복구 파티션을 부팅하려면 diskpart를 사용하여 활성 파티션을 전환합니다(그림 1 참조). 다음은 단일 디스크, 이중 파티션 시스템을 전환하는 데 사용하는 diskpart 스크립트(diskpart /s nameofscript.txt 사용)의 예입니다.
SEL DIS 0
SEL PAR 1
INACTIVE
SEL PAR 2
ACTIVE
EXIT
그림 1 활성 파티션을 변경하는 Diskpart
그림 1 활성 파티션을 변경하는 Diskpart
이것은 대부분의 복구 도구에서 파티션을 전환하는 데 사용하는 프로세스이며, 숨겨진 OEM 파티션과 같은 특정 파티션 형식에 대해 Windows PE에서만 수행할 수 있습니다. 복구 도구가 OEM 파티션 형식의 숨김을 해제하는 경우도 있습니다.

만들기, 업데이트 및 저장
복구 파티션 만들기
Windows를 수정하지 않고 복구 파티션을 만드는 프로세스는 방법만 제대로 알면 그다지 어렵지 않습니다. 지금부터는 필요한 작업을 대략적으로 설명하겠습니다. 이 프로세스를 수행하려면 Windows PE 2.0이 필요합니다. 배포나 복구에는 Windows PE 2.0을 사용하지 않을 수도 있지만 복구 파티션을 만드는 작업에는 반드시 버전 2.0을 사용해야 합니다. 이 프로세스는 Windows Vista를 배포할 때도 사용할 수 있고 BitLocker 부팅 파일에 사용할 부팅 파티션을 만들 때도 사용할 수 있습니다. BitLocker를 사용하는 경우 부팅 파일에 사용할 파티션과 Windows 시스템의 나머지 부분에 사용할 파티션 등 최소한 두 개의 파티션이 필요합니다.
  1. 디스크 조각 모음을 수행합니다. 이렇게 하면 상당한 시간이 걸리는 축소 프로세스의 속도가 빨라집니다.
  2. Windows PE 2.0으로 부팅합니다.
  3. diskpart를 실행합니다. 필요한 경우 4-9단계에 대한 스크립트를 만들고 diskpart에 인수 /s name_of_your_script
  4. SEL VOL 1(또는 축소할 볼륨)
  5. SHRINK DESIRED=N MIN=N(MB 단위로 지정, DESIRED는 목표값이고 MIN은 필요한 절대 최소값)을 전달합니다.
  6. 축소가 끝나면 SEL DIS 0
  7. CRE PAR PRI(남은 디스크 크기가 아닌 다른 크기를 지정하려는 경우에는 SIZE=N 지정)
  8. ASSIGN LETTER=N: (이 문자는 Windows PE에서만 사용함)을 실행합니다.
  9. diskpart를 종료합니다.
  10. FORMAT N: /Q /Y /FS:NTFS(새 파티션을 NTFS로 포맷)
  11. bootsect N: /nt60(2.0의 경우), /nt52(1.x의 경우)를 실행합니다.
  12. 원하는 Windows PE 파일을 복구 파티션에 복사합니다.
  13. 시스템을 종료합니다.

ImageX는 무료로 사용할 수 있는 솔루션이지만 이미 사용하고 있는 다른 이미징 도구가 있을 수도 있으므로, 자신에게 편한 도구를 사용하면 됩니다. ImageX를 사용하려는 경우 가격 외에도 몇 가지 사항에 대해 미리 알고 있으면 좋습니다. ImageX는 압축 성능이 뛰어나고 이미지를 추가하고 편집하기가 비교적 쉽다는 장점이 있습니다.
또한 ImageX를 사용하면 하나 이상의 볼륨에 대한 이미지를 안전하게 만들 수 있습니다. 즉, 사용자 데이터를 다른 곳으로 옮겨 놓는 것만으로도 데이터를 안전하게 보존할 수 있습니다. 따라서 Windows를 복구할 때 볼륨 전체를 지울 필요가 없습니다.
그런 다음, 이미지를 저장할 위치를 결정해야 합니다. 솔루션에서 복구 파티션을 사용한다고 가정할 경우 WIM이나 다른 이미징 파일을 복구 파티션에 저장할 수 있습니다. WDS(Windows 배포 서비스)를 사용하여 표준 OS 이미지를 만들고 네트워크에 저장하는 방법도 고려할 수 있습니다. 이렇게 하면 인프라 전체에서 사용할 수 있는 공용 복구 솔루션을 만들 수 있습니다. 물론, 앞에서 언급한 바와 같이 원거리의 현장에서 근무하는 사용자가 있는 경우에는 사용자가 네트워크에 연결할 수 없을 때 자체적으로 사용할 수 있는 복구 솔루션도 마련해야 합니다.
DVD와 같은 미디어를 사용할 수도 있지만 필자가 이 방법을 선호하지 않는 많은 이유가 있음을 언급한 바 있습니다. 예를 들어 이미지 크기가 DVD의 크기보다 금방 커질 수 있으며 이러한 디스크는 업데이트도 쉽지 않습니다. 단, 광학 미디어를 전혀 사용할 수 없다는 말은 아닙니다. 사용자 유형에 맞는 가장 좋은 방법을 고려해야 한다는 것입니다. 아직까지 사용할 방법을 결정하지 못했다면 필자는 이미지를 복구 파티션, USB 하드 디스크 또는 USB 플래시 드라이브에 저장하거나 가능한 경우 WDS를 사용하여 네트워크에 저장할 것을 권장합니다.
WDS를 사용하면 중앙 집중화된 이미지를 쉽게 업데이트할 수 있어서 편리합니다. Windows 업데이트는 매달 제공되며 대부분 중요한 것들이라는 사실은 잘 알고 있을 것입니다. 가능하면 복구 이미지가 최신 상태로 유지될 수 있도록 솔루션을 설계하십시오. WDS를 사용할 경우 각 서버의 이미지를 업데이트할 수 있으며 그것만으로 작업을 끝낼 수 있습니다.

사용자 데이터 및 설정 고려 사항
복구 솔루션을 설계할 때 염두에 두어야 할 몇 가지 사항이 있습니다. 복구 솔루션을 계획할 때 가장 중요한 요소는 사용자 데이터를 안전하게 보존하는 것입니다. 현장의 사용자가 힘들게 복구를 수행했는데 복구 중 중요한 데이터가 모두 손실되는 상황이 발생해서는 안 되니까요. 시스템 복구가 처리되는 방식에 세심한 주의를 기울일 수 없다면, 가장 좋은 방법은 사용자 데이터를 C: 파티션이 아닌 다른 파티션에 저장하도록 하는 것입니다.
ImageX를 사용하면 디스크를 안전하게 복원할 수 있다는 점은 앞서 이미 언급한 바 있습니다. 예를 들어 ImageX를 사용하는 경우 기존의 Documents and Settings(또는 사용자) 디렉터리 트리가 다른 디렉터리로 이동되어 사용자나 스크립트는 복구가 완료된 후 수동으로 파일을 복구할 수 있습니다. 모든 파일을 자신의 프로필에 저장하거나 로밍 프로필을 사용하는 사용자는 대부분의 경우 사용자 데이터를 손실하지 않고 시스템을 복구할 수 있습니다. 하지만 신중에 신중을 기해 복구 솔루션을 만들거나 완벽한 백업 솔루션이 있는 경우가 아니면 이렇게 하더라도 사용자 데이터 중 일부는 손실될 수 있습니다.
사전의 모든 계획에도 불구하고 일부 사용자가 해당 프로필이 아닌 다른 위치에 정보를 저장할 수도 있습니다. 따라서 사전에 사용자에게 경고도 하지 않고 실수로 사용자 데이터를 지울 수 있는 가능성을 감안하여 이에 대비하는 방법을 솔루션에 포함해야 합니다.
EFS(파일 시스템 암호화)를 사용하는 경우, 복구 불가능한 암호화로 인해 데이터가 손실되는 일이 없도록 하려면 키 복구 계획을 실행했는지 확인해야 합니다. 마찬가지로, BitLocker를 사용하는 경우에도 BitLocker로 암호화된 불륨을 복구할 준비가 되어 있어야 합니다. 이는 곧 Windows PE 2.0을 사용한다는 것을 의미합니다. 1.x는 BitLocker와 호환되지 않습니다. BitLocker 복구에 대한 자세한 내용은 blogs.msdn.com/si_team을 참조하십시오.
마지막으로 일부 사용자는 자신이 사용자 지정한 내용이나 응용 프로그램이 사라질 경우 작업에 어려움을 겪을 수도 있으므로 이에 대해서도 대비해야 합니다. 응용 프로그램이든 Windows 자체든 사용자 지정한 내용은 사용자 프로필뿐만 아니라 다른 임의의 위치에도 저장됩니다. 전체 OS 파티션을 복원하는 경우 일부 사용자는 "이런저런 파일이 어디로 갔습니까?" 또는 "왜 Word에서 이것이 표시되지 않습니까?"와 같은 질문을 할 것입니다. 사용자가 던질 수 있는 질문을 미리 예상해 보고 새로운 환경이 이전과 완벽하게 동일하지는 않을 수도 있음을 미리 알려 주는 것이 좋습니다.
Windows PE를 사용하여 자체 복구 솔루션을 만드는 데는 시간이 걸립니다. 또한 솔루션에 대해 계획을 수립하고 설계할 때는 사용자를 고려해야 합니다. 복구 솔루션을 지나치게 복잡하게 만들 필요는 없습니다. 가급적 기술 전문가의 도움 없이 가장 짧은 시간 안에 사용자가 다시 업무에 복귀할 수 있도록 하면 되는 것입니다.

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


 Field Notes: 공짜 음식과 교육 팁
Field Notes
공짜 음식과 교육 팁
Michael Dragone

필자는 약 150명의 직원이 일하고 있는 소유권 보험 회사의 시스템 엔지니어로 일하고 있습니다. 사실 저희 회사의 경우 주로 사용하는 LOB(기간 업무) 응용 프로그램이 웹을 기반으로 하기 때문에 컴퓨팅 요구 사항은 상당히 간단한 편입니다. 다시 말해 저희 업무는 주로 Internet Explorer®나 Microsoft® Office와 상호 작용하는 작업입니다.
이와 같이 비교적 단순한 응용 프로그램 배포 시나리오에서는 사용자가 응용 프로그램을 사용하면서 일상적으로 직면하는 문제가 거의 없을 것이라고 생각하기 쉽습니다. 대부분의 경우에는 사실입니다. 또한 종종 발생하는 다양한 문제들도 일반 TechNet Magazine 독자라면 몇 초 안에 해결할 수 있는 것들입니다.
필자는 경험을 통해 문제를 최소화하기 위해서는 효과적인 사용자 교육이 필요하다는 사실을 알게 되었습니다. 여기서 사용자의 교육을 위해 저희 회사에서 시행했던 방법 중 여러분에게 도움이 될만한 두 가지를 공유할까 합니다.
첫 번째는 교육 강의입니다. 저희 회사에서는 새로 설치한 시스템, 롤아웃할 예정인 새로운 응용 프로그램 및 적용 중인 새로운 정책에 대해 다루는 강의를 자주 개최합니다. 마찬가지로 중대한 시스템 변경이 예정되어 있는 경우에도 해당 변경 사항에 대해 다루고 질문에 답변하는 특별 강의를 실시합니다. 이러한 강의는 사용자가 충분히 준비할 수 있도록 변경 전에 미리 실시합니다.
예를 들어 조만간 저희 회사에서는 전화 시스템에 대해 중대한 업그레이드를 롤아웃할 계획입니다. 업그레이드 후에도 사용자는 지금과 마찬가지로 Outlook®을 통해 음성 메일에 액세스할 수 있지만 사용하는 소프트웨어는 변경될 것입니다. 따라서 전화 시스템 공급업체에서 사용자에게 새로운 인터페이스를 시연하고 질문에 답하는 교육 세션을 실제 롤아웃 일정보다 훨씬 이전에 실시할 예정입니다.
교육 세션에서는 사용자가 문제를 겪고 있는 기존 주제에 대해서도 다룹니다. 사용하는 데 문제를 겪고 있는 티켓 시스템을 직접 살펴보는 것만큼 문제를 이해하는 데 좋은 방법은 없습니다. 예를 들어 저희 사용자 중에 시스템별로 서로 다른 암호를 사용해야 하는 이유를 모르는 사용자가 있었습니다. 말로는 설명을 아무리 많이 해도 이해를 못했지만 PowerPoint® 슬라이드를 보여 주면서 설명하자 비로소 "아하!"하고 이해했습니다.
필자의 경험으로는 어떤 사안이든 모임을 성공적으로 이끌어가는 데 가장 중요한 것은 공짜 음식을 제공하고 밝은 분위기를 유지하는 것입니다. 이렇게 분위기를 조성하면 사용자가 아무리 "바보" 같다고 생각하는 질문일지라도 쉽게 꺼내게 됩니다.
두 번째 방법은 사무실을 이리저리 둘러보는 것입니다. 필자는 매일 10분에서 15분 정도 사용자들을 만나는 시간을 가집니다. 그리고 잘못된 방법으로 작업을 수행하는 사람이 있으면 수행해야 할 작업과 그 이유에 대해 간단히 설명해 줍니다. 이러한 방법을 통해 훨씬 쉬운 대안을 제시해 줄 수 있는 기회가 많이 생깁니다. 예를 들어 계속해서 실수로 Outlook 도구 모음을 다시 정렬하고는 원래대로 되돌리는 방법을 모르는 사용자가 있었습니다. 이 사용자는 필자가 눈치채기 전까지 혼자 끙끙대고 있었습니다. 필자는 실수로 도구 모음을 다시 정렬했을 때 원하는 방식으로 복원할 수 있도록 변경하는 방법을 보여 주었습니다.
여러 가지 이유로 사용자가 헬프 데스크나 기술 지원 부서에 문제를 알리기를 꺼리는 경우가 있습니다. 너무 바보 같은 질문이라 IT 부서에 지원을 받을 만한 사안이 아니라고 생각하여 질문하기를 부끄럽게 여기는 경우도 있고, IT 부서에서 필요할 경우에 대비해 예비 물품을 준비해 두고 있다는 사실을 몰라서 제대로 작동하지 않는 키보드나 마우스를 그냥 사용하는 경우도 있습니다. 이러한 사용자를 돌아보는 데 몇 분만 투자한다면 많은 문제를 해결할 수 있을 뿐만 아니라 다음 교육 강의를 위한 아이디어를 얻을 수도 있습니다. 아, 그리고 공짜 음식을 잊지는 않았겠죠?
업무의 모든 측면에 있어서 항상 사용자를 고려해야 합니다. 항상 그렇지는 않지만 대부분의 경우 시스템, 정책 및 절차에 대한 변경 사항은 사용자에게 어느 정도 영향을 미치기 마련입니다. 또한 변경 사항에 대한 반응은 각 사용자마다 다르게 나타납니다.
우리처럼 기술에 익숙한 사람들은 기술에 대한 이해가 부족한 사용자를 적절히 지원하기가 어려울 때가 많습니다. 그러나 조금만 인내심을 가지고 사용자 교육을 실시한다면 사용자도 여러분처럼 컴퓨터를 친숙하게 여기는 데 큰 도움을 줄 수 있습니다. 물론 아주 적은 노력으로 말이죠.

Michael Dragone은 뉴욕 소재의 소유권 보험 회사에서 시스템 엔지니어로 일하고 있으며, MCDST 및 MCSE: Messaging 자격 보유자입니다. 여가 시간은 바닷가를 오랫동안 거닐거나 애견과 놀거나 완벽하게 패치된 서버를 다루며 보낸다고 합니다.


 Windows Confidential: 알려진 DLL 균형 조정 작업
Windows Confidential
알려진 DLL 균형 조정 작업
Raymond Chen

흔히 "알려진 DLL"이라고도 하는 이 Windows 기능은 커널의 모듈 로더가 특별하게 처리하는 DLL(동적 연결 라이브러리) 목록을 의미합니다. 로드 시 알려진 DLL에 동적으로 연결되는 프로그램을 로더가 발견하면 모듈 로드에 일반적으로 적용되는 검색 알고리즘이 무시되고 알려진 복사본이 즉시 사용됩니다. 이것을 다소 약한 보안 기능으로 간주하는 사람들도 있지만, 사실 이 기능의 본래 목적은 보안이 아닙니다. 알려진 DLL은 성능을 목적으로 개발된 것입니다.
알려진 DLL 기능의 메커니즘은 시간에 따라 변경되었습니다. 일부 Windows® 버전의 커널에서는 알려진 DLL 목록을 시작 지점으로 사용한 다음 이러한 알려진 DLL이 연결되는 모든 DLL을 찾은 후 다시 이 DLL이 연결되는 모든 DLL을 찾는 방식으로 작업을 실행합니다. 이러한 프로세스를 통해 모든 종속성의 이행적 폐쇄(Transitive Closure)가 구성되고 모두 알려진 것으로 처리됩니다. 다른 Windows 버전에서는 이러한 이행적 폐쇄가 구성되지 않으며, 대신 알려진 것으로 명시적으로 나열된 DLL만 알려진 것으로 처리됩니다. 일부 Windows 버전에서 알려진 DLL은 시스템 시작 시 커널을 통해 미리 로드됩니다. 다른 버전에서는 이러한 미리 로드가 실행되지 않고 커널이 목록만을 사용하여 DLL 경로를 검색하는 작업을 처리합니다.
알려진 DLL 목록에 대한 해석 외에도 버전에 따라 몇 가지 사항에 차이가 있습니다. 알려진 DLL 레지스트리 키의 내용도 이러한 변경의 영향을 받습니다. Windows 성능 팀은 응용 프로그램이 Windows를 사용하는 방식에 대한 이해를 바탕으로 알려진 DLL 목록과 이 목록이 DLL 집합으로 변환되는 규칙을 변경했습니다. 엔지니어링 분야에서 흔히 볼 수 있듯이 이러한 작업에는 절충이 필요합니다. 시스템 시작 시 알려진 DLL을 미리 로드하면 해당 DLL을 사용하는 응용 프로그램의 시작 속도가 빨라지는 이점이 있지만 그에 따른 단점도 있습니다. 즉, 해당 DLL이 실제로 사용되는지 여부에 관계없이 메모리에 남아 있기 때문에 시스템 시작 시간이 길어지고 메모리 소비가 증가합니다. 따라서 이 작업은 다른 어떤 것을 희생하고 일부 구성 요소의 성능을 향상시키는 것입니다. 이 두 가지 사이에서 균형을 유지하는 것은 쉽지 않으므로, 사용 패턴이 변화함에 따라 끊임없이 조정해야 합니다.
알려진 DLL에서 눈에 잘 띄지 않을 수 있는 한 가지 중요한 것은 알려진 DLL이 로컬에서 리디렉션된 DLL보다 높은 우선 순위를 가진다는 점입니다. 로컬에서 리디렉션된 DLL에 대해서는 필자의 2007년 1월호 칼럼에서 살펴보았습니다. 잘 생각해 보면 이것은 특이한 것이 아니라 실제로 예상되는 동작임을 알 수 있습니다. 결국 알려진 DLL 목록의 목적은 검색 경로를 우회하고 이를 통해 DLL 로드 속도를 높이는 것입니다. 커널이 로컬에서 리디렉션된 DLL을 찾아야 한다면 속도는 느려질 것입니다. 검색 경로에 디렉터리 하나를 추가한다고 해서 큰 문제가 되지는 않을 것으로 생각할 수도 있겠지만, 이 하나의 디렉터리가 지구 반대편의 네트워크 서버라고 가정한다면 심각한 성능 저하를 야기할 수도 있습니다.
사실 우리는 알려진 특정 DLL을 사용하는 프로그램을 본 적이 있습니다. 응용 프로그램 디렉터리에 있는 Version.dll이라는 파일을 사용하는 프로그램 하나가 있었습니다. 일반적인 규칙에 따르면 Version.dll의 이 복사본은 시스템 디렉터리의 해당 dll 파일을 무시하지만 Windows XP에서 Version.dll은 알려진 DLL로 나열됩니다. 즉, 응용 프로그램 디렉터리에 있는 복사본이 무시되고 시스템 디렉터리에 있는 버전이 사용됩니다.
Windows Vista®에서 Version.dll은 더 이상 알려진 DLL이 아닙니다. 아마 응용 프로그램에서 이 파일을 사용하는 데 따른 성능상의 이점이 이에 관련된 희생을 상쇄하지 않기 때문일 것입니다. 결과적으로 응용 프로그램 디렉터리에 설치된 DLL을 무시하는 커널을 응용 프로그램이 실제로 사용하기 때문에 이 프로그램은 Windows Vista에서는 작동하지 않습니다. 이 프로그램은 자의적으로 DLL을 해당 검색 경로에 설치한 다음 Windows가 이 DLL 파일을 무시하도록 합니다. Windows가 파일을 무시하도록 하는 것보다는 애초에 파일을 설치하지 않는 편이 오히려 효율적인 메커니즘일 것입니다. 문제는, 이 프로그램을 작성한 회사에서 보안상의 문제가 되는 버그를 발견했다고 주장한다는 점입니다.

Raymond Chen은 The Old New Thing 웹 사이트와 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 그는 이제 자신의 티셔츠 치수를 더 이상 모른다고 합니다.