The Desktop FilesWindows 배포 서비스 사용자 지정

Wes Miller

목차

기존의 배포 기술 대체
배포 단계 살펴보기
네트워크 부팅 프로그램
WDS PXE 공급자
TFTP Daemon
부팅 구성 데이터 저장소
Windows PE
전송 서버
사용자 지정 멀티캐스트
요약

지난 3개월에 걸쳐 WDS(Windows 배포 서비스)의 기원, 개요에 대해 차례로 살펴본 후 WDSUtil, 멀티캐스팅과 같은 일부 고급 항목에 대해서도 자세히 설명했습니다. 연재물의 마지막인 이번 호에서는 조직의 필요에 맞게 WDS를 사용자 지정하고 구성할 수 있는 위치와 방법에 대해 알아보겠습니다. 대부분의 Microsoft 도구는 어느 정도 구성이 용이하게 만들어져 있습니다. 그러나 실제로 사용할 시점이 되면 도구가 요구 사항에 맞는지, 아니면 여러분의 시나리오에 사용하기 위해 약간의 수정이 필요한지(후자가 더 흔함)를 확인해야 합니다.

기존의 배포 기술 대체

최근 독자들로부터 많이 받는 질문은 "x(기존의 배포 기술)를 사용하고 있는데 WDS를 사용해도 될까요? x만큼 다양한 기능을 제공하나요?"입니다. ADS(자동 배포 서비스)가 더 이상 사용되지 않으면서 대량의 서버를 신속하게 배포하거나 다시 구축하려면 어떻게 해야 하는지, 그리고 WDS로 이 작업을 수행 가능한지가 사람들의 주 관심사가 되었습니다.

WDS는 ADS를 1:1로 대체하기 위한 기술이 아니고 사실 대체에 필요한 주요 구성 요소 몇 가지가 빠져 있지만 약간의 작업만 거치면 WDS로 ADS를 대체할 수 있습니다. 마찬가지로 WDS의 기본 상태가 요구 사항에 맞지 않는다면 많은 구성 요소를 필요에 따라 대체할 수 있습니다. 물론 이를 위한 작업의 복잡성과 필요한 기술 수준은 그때그때 상당히 다릅니다. 그러면 WDS를 통한 배포에 대해 살펴보고 사용자 지정해야 할 부분과 그 방법에 대해 알아보겠습니다.

배포 단계 살펴보기

그림 1에서는 WDS 배포 프로세스의 구성 요소를 보여 줍니다. 이러한 각 단계는 어느 정도까지 사용자 지정할 수 있습니다. 각 단계는 해당 단계의 대체 또는 사용자 지정 작업에 수반되는 복잡성(일반적으로 개발 기술)에 따라 색으로 구분되어 있습니다. 파란색이 어두울수록 사용자 지정하기가 더 어려운 단계입니다.

그림 1 WDS 사용자 지정 작업의 복잡성

물론 각 단계별 사용자 지정 작업의 난이도는 팀의 기술(개발 또는 스크립팅) 수준, 그리고 WDS, WIM(Windows 이미징 형식), Active Directory 또는 기타 통합하려는 다른 기술(예: SQL 또는 ADSI)에 대한 이해도에 따라 달라집니다. 이러한 각 단계를 살펴보고 이를 사용자 지정할 방법과 여기에 사용할 방법에 대해 생각해 보십시오.

네트워크 부팅 프로그램

WDS에서 기본 제공하는 NBP(네트워크 부팅 프로그램)를 대체하는 사용자 지정 NBP를 만들 일은 사실 거의 없겠지만 어쨌든 가능하긴 합니다. WDS에는 헤드리스 시스템(일반적으로 서버) 또는 F12 입력을 요구하거나 요구하지 않는 시스템 등에서 사용할 수 있는 NBP가 포함되어 있습니다. 이러한 NBP를 WDSUtil을 사용하여 Active Directory에 사전 준비해 넣거나 사전 준비되지 않은 모든 시스템에 대해 Startrom.com을 원하는 NBP로 대체할 수 있습니다(예: 모든 시스템이 헤드리스 시스템인 경우 또는 F12 입력을 요구하지 않으려는 경우).

아쉽게도 사용자 지정 NBP를 만드는 방법에 대한 문서는 그리 많지 않습니다(msdn.microsoft.com/library/bb870970.aspx 참조). NBP는 매우 작은 16비트 실행 파일이며 매우 제한적이고 특정 프로그래밍 기술을 요구합니다. 특정 요구 사항을 충족해야 하고 적절한 기술을 갖춘 개발팀이 있는 경우를 제외하면 일반적으로 WDS에 제공되는 기존 NBP를 사용하는 것이 좋습니다.

WDS PXE 공급자

RIS(원격 설치 서비스)와 관련하여 고객들로부터 많이 받은 의견은 Active Directory 외의 다른 데이터 저장소를 사용하여 클라이언트 시스템 정보를 저장하고 싶다는 것이었는데, 그중에서 SQL Server를 사용하고 싶다는 의견이 가장 많았습니다. WDS의 경우 디자인에 PXE(Pre-Boot eXecution Environment) 공급자용 플러그형 인프라가 포함되어 있습니다. 이는 개발 작업에서 Active Directory 외의 다른 지원 저장소에 PXE 정보를 저장할 수 있음을 의미합니다.

WDS에는 Active Directory를 사용하는 고유한 공급자가 기본 제공됩니다. 또한 이제 SCCM(System Center Configuration Manager)도 WDS에 연결되고 자체 공급자를 구현합니다. 고유한 공급자를 작성하는 방법에 대한 문서는 극히 드물고 샘플 코드도 많지 않으므로(Windows SDK에서 일부 문서와 몇 가지 샘플을 제공하긴 하지만) 작업이 쉽지는 않습니다. 다시 한 번 말하지만 부팅 프로세스의 이러한 측면에 대해 특정 요구 사항이 있는 경우를 제외하면 사용자 지정 PXE 공급자는 시도하지 않는 편이 좋습니다.

TFTP Daemon

WDS가 나오기 전에 일부 고객은 고유의 TFTPD(Trivial File Transfer Protocol Daemon)에 투자했습니다. PXE 서버 여러 대는 매끄럽게 동작하지 않으므로 많은 경우 이는 한 대에만 의존하게 됨을 의미합니다.

필자의 경험상 일반적으로 이를 위해서는 기존 TFTPD(일반적으로 Linux 기반 TFTPD)를 가져와 다른 OS를 부팅하도록 손을 써야 합니다. RIS가 사용했던 원래의 인프라에서는 이렇게 할 수 없습니다. 그러나 RAMDisk 부팅이 표준이 된다면 이렇게 할 수 있습니다. 또한 WDS 기반 부팅 이미지를 사용하는 방법도 여전히 가능합니다.

한 가지 염두에 두어야 할 점은 이로써 여러분은 Microsoft에서 기술적으로 지원하지 않는 영역, 또한 진단하기 어려운 문제를 유발할 가능성이 높은 영역으로 들어가게 된다는 점입니다. 또한 WDS의 향상된 TFTPD를 사용하면 성능 개선과는 동떨어진 결과를 얻을 수 있습니다. 이상적으로 보면 기존 서버를 수정하는 대신 기존 WDS TFTPD를 사용하고 PXE 시간 제한, 사전 준비 및/또는 네트워크 경계를 사용하여 어떤 클라이언트가 어떤 PXE 서버에서 부팅될지를 정의하는 것이 좋습니다.

부팅 구성 데이터 저장소

RIS의 경우 부팅 수준에서 부팅해야 할 대상을 지정할 수가 없었습니다. 항상 OS 선택기를 사용하여 옵션(설치 프로그램, Windows PE(Windows 사전 설치 환경) 등)을 선택해야 했습니다. WDS는 완벽한 네트워크 부팅 로더를 사용하므로 클라이언트에게 제공되는 BCD(부팅 구성 데이터) 저장소의 사용자 지정도 지원합니다. 각 아키텍처의 기본 BCD는 RemoteInstall\Boot\<arch>\Default.bcd 아래에 위치하며 여기서 <arch>는 부팅되는 시스템의 특정 아키텍처입니다.

각 클라이언트별로 이러한 BCD를 사용자 지정할 수 있으며 클라이언트는 부팅 시에 이를 사용하게 됩니다. 예를 들어 한 BCD 항목은 설치를 시작하도록 설정하고, 다른 항목은 WinRE(Windows 복구 환경)를 실행하도록 설정하고, 또 다른 항목은 메모리 테스트를 실행하도록 설정할 수 있습니다. 또는 완전히 자동화된 설치 항목을 기본값으로 두고 수동(또는 사용자 지정 설치 환경)을 사용자가 선택 가능한 옵션으로 설정할 수 있습니다. 자세한 내용은 "Bcdedit를 사용하여 BCD 저장소를 수정하는 방법"(go.microsoft.com/fwlink/?LinkId=115267)을 참조하십시오.

물론 WDS의 주요 작업 대부분은 Windows PE에서 수행되므로 필요에 맞게 Windows PE를 조정하는 작업이 사용자 지정 환경에서 가장 중요한 부분일 수 있습니다. WDS는 기본적으로 완전한 설치 환경이 포함된 극히 표준적인 설치 템플릿을 제공합니다. 배포 요구 사항에 따라 이러한 템플릿을 사용할 수 없는 경우도 있습니다. 이러한 경우 사용자 고유의 Windows PE 부팅 이미지를 만들 수 있습니다. 그러면 기본적인 것부터 시작해 보겠습니다.

BCD를 통해 사용할 이미지를 지정하는 것 외에도 Active Directory에서 컴퓨터에 대해 MAO(컴퓨터 계정 개체)를 사용자 지정하는 방식으로 이미지를 지정할 수도 있습니다. RIS에서는 특정 MAO 특성이 각 항목(사용할 Startrom 및 Unattend(SIF) 파일)을 저장했습니다. WDS에서는 이러한 항목이 netBootMirrorDataFile 항목에 이름-값 쌍으로 저장됩니다. 예를 들어 특정 컴퓨터에서 사용할 부팅 이미지와 Unattend 파일이 이 항목에 저장됩니다. 이러한 항목의 형태는 세미콜론으로 구분된 이름-값 쌍 목록입니다. 부팅 이미지와 Unattend 파일을 수정하는 항목은 각각 BootImage와 UnattendFilePath입니다.

물론 기존의 설치 환경을 완전히 삭제하고 사용자 고유의 환경을 구축해야 할 수도 있습니다. 더 높은 수준의 구성 용이성과 더 많은 자동화 기능이 필요하거나 SQL Server에 의해 자동화된 빌드가 필요한 경우가 있습니다. 초기에 일부 고객이 RIS 및 Windows PE를 사용하여 했던 것처럼 설치를 위한 사용자 고유의 프런트 엔드를 구축할 수도 있습니다. 어떤 설치 환경을 작성하든 관계없이 수행해야 할 주요 작업은 다음과 같습니다.

• 컴퓨터별 또는 사용자별 정보 확인. 이 정보는 사용자 입력, SQL Server 또는 텍스트 파일 등에서 확인할 수 있습니다.
• 클라이언트 시스템에 설치 이미지 복사 및 적용. 이 작업을 수행하려면 직접 설치 프로그램을 사용하거나 ImageX를 사용하여 네트워크 공유에서, 또는 멀티캐스트를 통해 이미지를 적용하면 됩니다(ImageX를 통해 이미지를 복사하고 적용하기만 하면 됨).
• Unattend 파일(배포 중인 Windows 버전에 따라 Unattend.xml 또는 sysprep.inf)을 제공하여 설치를 완료합니다.
• 수행할 모든 설치 후 마이그레이션 단계(Windows Server 2008의 경우 역할을 적용하기 위한 모든 단계)를 자동화합니다.

ADS는 한 대 이상의 컴퓨터에 반복 가능한 단계를 할당할 수 있는 작업 시퀀스 개념을 도입했습니다. ADS는 Windows XP에서 사용하도록 디자인되지 않았고 지원되지도 않으므로 OS를 배포하는 데 사용할 수 없습니다. 그러나 ADS 작업 시퀀스는 사실 구조화된 스크립트일 뿐이며 사용자 지정 설치 프로세스를 사용하면 이와 동일한 단계를 수행할 수 있습니다.

필자는 오래 전부터(SQL Server 6.5 릴리스 이후부터) Microsoft SQL Server의 팬이었으므로 이러한 구조를 작성할 때 습관적으로 SQL을 사용합니다. 물론 이렇게 하려면 Windows PE 빌드에 SQL 기능을 추가해야 합니다. 이를 기반으로 고유의 GUI(HTA(HTML 응용 프로그램) 또는 컴파일된 실행 파일)를 작성하거나 WSH(Windows 스크립트 호스트)를 사용하여 가장 간단한 명령줄 전용 설치 환경을 구축할 수 있습니다. HTA 또는 WSH 역시 사용하려면 Windows PE에 추가해야 합니다.

고유의 설치 환경을 설계하는 데 따르는 복잡성은 전적으로 사용자의 기술 수준과 구상에 따라 달라집니다. 필자는 SQL 및 WSH 또는 HTA만 사용하여 정의된 상당히 훌륭한 시스템을 여럿 보았습니다. 이러한 기술은 비교적 익히기 쉽습니다. 그러나 필자가 이전 칼럼에서 언급했던 제한 사항을 반드시 염두에 두어야 합니다.

• Windows PE에서는 WOW(Windows on Windows) 하위 시스템을 제공하지 않으므로 지원하려는 각 아키텍처에 대해 한 번씩 컴파일을 수행해야 합니다.
• x64 또는 IA64 Windows PE를 통해 배포해야 하는 경우에는 Visual Basic 6.0을 사용할 수 없습니다.
• Visual Studio 2005 또는 2008을 사용하여 응용 프로그램을 구축할 수 있지만 Windows PE에서 지원되는 Microsoft .NET Framework 버전이 없으므로 관리되지 않는 Visual C++ 응용 프로그램을 작성해야 합니다.
• .NET Framework를 사용할 수 없으므로 자동화에 Windows PowerShell을 사용할 수도 없습니다.

물론 사용자 고유의 설치 환경을 작성하려는 경우에는 WDS를 통해 타사 이미징 유틸리티를 사용할 수 있습니다. 필자는 WIM 형식과 ImageX가 대부분의 배포 시나리오를 충족할 수 있다고 생각하지만 사용 중인 기존 이미징 도구가 충족하는 특정 요구 사항이 있을 수 있습니다.

마찬가지로 사용자 지정 파티션 분할이 필요한 시나리오가 있을 수 있습니다. 예를 들어 BitLocker를 사용하여 Windows Vista를 배포하는 경우, 또는 Windows XP 시스템을 구축하고 두 번째 볼륨에 프로필 데이터를 저장하는 경우, 또는 Windows Server 시스템을 배포하고 동일한 디스크에 로깅을 위한 별도의 볼륨을 만들려는 경우가 있습니다. 이러한 시나리오에서는 DiskPart를 자동화해야 합니다. 이렇게 하려면 이전 버전에서와 마찬가지로 실행하려는 명령이 포함되어 있고 DiskPart를 종료하는 exit 명령으로 끝나는 스크립트(파일 형식 무관)를 DiskPart에 제공하면 됩니다.

고유한 설치 환경을 만드는 작업은 결코 간단하지 않습니다. 기본적으로 이를 위해서는 설치 실행 파일을 재작성(또는 적어도 그 기능을 미러링)해야 하고 여기에 상당히 많은 디자인 및 구축 작업이 필요할 수 있기 때문입니다. 그러나 이는 기본적으로 구축해 넣으려는 기능이 얼마나 많고, 무엇(HTA 또는 WSH 또는 컴파일된 프로그래밍 언어)을 사용하여 구축하느냐에 따라 달라집니다.

전송 서버

WDS의 기본 기능(예: Active Directory) 대부분을 거의 사용하지 않거나 사용자 고유의 솔루션 일체를 작성하려는 경우에는 전송 서버가 불필요한 요구 사항을 수반하지 않으면서 필요한 사항을 충족할 수 있습니다. 그림 2의 표(원본은 go.microsoft.com/fwlink/?LinkID=115298의 "전송 서버 사용")에서는 WDS 전송 서버 역할의 일부로 포함된 항목을 설명합니다.

그림 2 배포 서버와 전송 서버 비교

전송 서버가 구현하기 복잡한 항목이라는 말은 역할 그 자체가 어렵다는 의미는 아닙니다. 물론 배포하기도 쉽습니다(그림 3 참조). 어려운 부분은 바로 전송 서버를 중심으로 한 사용자 지정 설치 구현입니다. 전송 서버 역할을 사용하면 역할로서 WDS에 기본 제공되는 사용의 용이함이 사실상 대부분 제거됩니다.

그림 3 사용자 지정 배포 시나리오에 유용한 전송 서버(더 크게 보려면 이미지를 클릭하십시오.)

사용자 지정 멀티캐스트

전송 서버 역할을 사용하는지 여부에 관계없이(그러나 사용하는 경우에 특히) 다중 시스템 배포를 수행할 때는 멀티캐스트를 사용할 만한 충분한 이유가 있습니다. ADS에서 제공했던 매우 강력한 멀티캐스트 기능을 WDS에서 멀티캐스트를 사용하여 그대로 모방할 수 있습니다. WDS도 자체적으로 멀티캐스트 기능을 제공하지만 고유한 사용자 지정 솔루션을 구축하고 있는 경우 필자가 지난 호에서 언급한 WDSMCast를 사용하여 멀티캐스트를 활용할 수 있습니다(그림 4 참조). 유의해야 할 점은 배포할 이미지 파일을 먼저 전송한 다음 적용해야 한다는 것입니다. 이는 보통 로컬 디스크에 이미지를 저장하고 적용하기에 충분한 공간이 있어야 함을 의미합니다.

그림 4 WDSMCast 실행(더 크게 보려면 이미지를 클릭하십시오.)

요약

WDS는 자체로도 상당히 강력한 기능을 제공하므로 많은 조직의 요구 사항을 충족하는 데 충분합니다. 그러나 WDS의 경계를 뛰어넘는 사용자 고유의 솔루션을 구축하고자 한다면 얼마든지 그렇게 할 수 있습니다. 여러분의 구상, 일정, 그리고 기술 수준 외의 다른 제한은 없습니다.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(CoreTrace.com)에서 기술 제품 수석 관리자를 맡고 있으며, 이전에는 Winternals Software에서 근무했고, Microsoft에서 프로그램 관리자로도 일했습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시기 바랍니다.