 TechNet Magazine May 2007

TechNet Magazine May 2007

Communications: Exchange 2007의 새로운 모바일 메시징 기능 살펴보기

모바일 메시징으로 업무 방식이 변화함에 따라 모바일 장치에 대한 보안이 그 어느 때보다 큰 문제로 떠오르고 있습니다. Exchange Server 2007을 통해 사용자 환경을 개선하고 늘어가는 모바일 사용자를 효과적으로 관리하는 방법을 알아보십시오.

Yee-Chen Tjie Communications: Exchange Server 2007로 규정 준수 개선

기업의 자산 보호 및 규정 준수의 필요성이 대두됨에 따라 IT 부서에 막중한 책임감이 부여되고 있습니다. Exchange Server 2007의 새로운 기능을 통해 데이터를 안전하게 보호하고 규정 준수 현황을 유지 관리할 수 있는 방법에 대해 살펴보겠습니다.

Alan Maddison Identity Management: 한 단계 준비 워크플로 만들기

웹 기반 준비 시스템을 찾고 계십니까? 이 문서에서는 MIISWorkflow를 사용하여 Microsoft Identity Lifecycle Manager 2007(ILM 2007)을 기반으로 자동화된 한 단계의 사용자 준비 시스템을 만드는 방법에 대해 설명합니다.

Aung Oo Windows Administration: Windows PowerShell로 그룹 정책 관리 단순화

Windows PowerShell을 활용하면 작업이 훨씬 쉬워집니다. Windows Scripting Host 언어용으로 작성된 GPMC API를 Windows PowerShell에서 직접 사용함으로써 그룹 정책 관리 방법을 크게 단순화하는 방법을 살펴봅니다.

Thorbjörn Sjövold Windows Administration: 터미널 서비스 배포 가이드

조직의 응용 프로그램을 중앙 집중적으로 실행하면 매우 많은 장점을 얻을 수 있으며 이제 이러한 작업을 매우 쉽게 시작할 수 있습니다. 여기서는 Windows Server 2003에서 터미널 서비스를 설정하고 조직 전체에 터미널 서비스를 구현하는 데 알아야 할 내용을 설명합니다.

James D. Silliman From The Editor: 모바일 장치 보안

Joshua Trupin Letters: 질문에 대한 답변

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

Greg Steen SQL Q&A: Best Practices Analyzer, 다중 코어 프로세서 외

Edited by Nancy Michell Utility Spotlight: SharePoint 사이트 및 서식 파일용 업그레이드 도구 키트

Luis Câmara Manoel and Peter Skjøtt Larsen The Business of IT: 세부적인 비즈니스 계획 수립

Stephen Ibaraki The Cable Guy: Windows의 EAPHost

Joseph Davies Windows PowerShell: WMI 연결

Don Jones Hey, Scripting Guy!: 봄바람 속에 꽃은 피고, 대화 상자는 열리고

The Microsoft Scripting Guys Exchange Queue & A: OWA 제한 시간, Cmdlet 문제 해결 외

KC Lemson and Nino Bilic Security Watch: 네트워크 액세스 보호

John Morello The Desktop Files: Windows 배포 서비스 재검토

Wes Miller Field Notes: 최신 감각 유지하기

Joshua Hoffman Windows Confidential: 자주 사용하는 프로그램 목록

Raymond Chen


 Communications: Exchange 2007의 새로운 모바일 메시징 기능 살펴보기
Communications Yee-Chen Tjie

Exchange 2007의 새로운 모바일 메시징 기능 살펴보기
한 눈에 보기:
  • 모바일 장치 구성
  • 정책 적용
  • 고급 메시징
  • 모바일 파일 액세스

불과 몇 년 전까지만 하더라도 자신의 데스크톱 컴퓨터를 사용하지 않고 회사 전자 메일에 액세스한다는 것은 흔한 일도 아닌데다 상당히 복잡했습니다. 하지만 지금은 원격으로 전자 메일에 액세스할 수 있는 것이 당연한 일일 뿐 아니라
커피숍에서 모바일 메시징 장치를 사용하는 사람을 보는 것도 전혀 낯선 풍경이 아닙니다. 모바일 메시징은 업무 방식을 바꾸어 놓았습니다. 외근이 잦은 직원의 경우 사무실 밖에서도 효율적으로 업무를 처리할 수 있게 되었습니다.
하지만 최근 들어 모바일 메시징 기술이 발전하면서 모바일 장치의 보안이 새로운 관심사로 떠올랐습니다. 기업들은 모바일 장치에 저장되어 있는 중요한 비즈니스 데이터를 보다 안전하게 보호할 수 있는 방법을 찾고 있습니다.
Exchange Server 2003과 Exchange ActiveSync®라는 기술의 등장으로 Windows Mobile® 장치(Pocket PC 폰 또는 스마트 폰)에서 HTTPS를 사용하여 Exchange Server 2003에 안전하게 액세스할 수 있게 되었습니다. 그러나 모바일 장치 관리 기능은 여전히 부족했습니다. 하지만 Exchange Server 2003 서비스 팩 2(SP2)와 Windows Mobile 5.0의 메시징 및 보안 기능 팩(MSFP)이 릴리스되면서 Exchange에 연결되는 모든 Windows Mobile 장치에 영향을 주는 글로벌 정책을 설정하는 것이 가능해졌습니다. 이러한 정책은 지정된 길이의 필수 PIN 적용, PIN 입력 요청 전 비활성 시간 제한 및 실패한 PIN 입력 시도가 지정된 횟수를 초과한 후 장치 데이터 지우기 같은 기능을 지원합니다.
Exchange Server 2003 SP2에서는 그림 1과 같은 Exchange Mobile 관리 도구를 사용한 원격 데이터 지우기 기능도 지원합니다. 관리자는 이 도구를 사용하여 분실한 Windows Mobile 장치에 데이터 지우기 명령을 보낼 수 있습니다. 다음 번에 장치가 Exchange에 연결되면 완전히 재설정되어 장치 메모리에 있는 모든 내용이 지워집니다.
그림 1 장치 데이터를 지우는 데 사용되는 Exchange Mobile 관리 도구
그림 1 장치 데이터를 지우는 데 사용되는 Exchange Mobile 관리 도구
이 방법이 모바일 장치 관리 및 보안을 위한 좋은 출발점인 것은 사실이지만 이 외에도 해결해야 할 보안 요구 사항이 많습니다. Exchange Server 2007에서는 이러한 문제들을 효율적으로 해결할 수 있습니다.

장치 구성 및 실행
기본적으로 Exchange ActiveSync는 Exchange Server 2007의 모든 사서함 사용자가 이용할 수 있습니다. 일부 사용자만 이 기능을 사용할 수 있도록 하려면 먼저 모든 사용자가 이 기능을 사용하지 못하도록 설정해야 합니다. Exchange 관리 콘솔에서는 사용자 그룹이 ActiveSync를 사용하지 못하도록 할 수 없지만 다음과 같은 Exchange 관리 셸 명령을 사용하면 쉽습니다.
Get-mailbox –server <servername> | Set-CASMailbox –ActiveSyncEnabled $false
이 명령은 Exchange 2007 서버의 모든 사서함을 검색한 다음 이 정보를 Set-CASMailbox 명령으로 전달하여 기존의 모든 사서함에서 ActiveSync를 비활성화합니다.
다음 단계에서는 조직에 적용할 Exchange 사서함 ActiveSync 정책을 구성합니다. 구성할 정책의 수는 사용자의 보안 프로필에 따라 달라집니다. 예를 들어 전자 메일로 중요한 재무 정보를 받는 재무 분석가는 일반 사용자보다 엄격한 보안 장치 정책을 마련해야 할 수 있습니다.
ActiveSync 정책을 구성하려면 Exchange 관리 콘솔 탐색 트리의 Organizational Configuration(조직 구성) 컨테이너 아래에서 클라이언트 액세스를 선택하고, 작업 창에서 새 Exchange ActiveSync 사서함 정책을 선택합니다.
새 Exchange ActiveSync 사서함 정책 대화 상자에서는 첨부 파일을 장치에 다운로드할 수 있게 할 것인지 또는 지원 불가 장치를 허용할 것인지 여부를 설정하여 정책을 만들 수 있습니다(그림 2 참조). 지원 장치는 지정된 정책을 적용하고 실행할 수 있는 Windows Mobile 장치이고, 지원 불가 장치는 정책의 일부만 적용할 수 있거나 정책을 아예 적용할 수 없는 장치입니다.
그림 2 Exchange Server 2007 ActiveSync 사서함 정책
그림 2 Exchange Server 2007 ActiveSync 사서함 정책
다른 기능으로는 암호화 및 암호 복구 설정을 구성하는 기능이 있습니다. 장치에서 암호화 필요 옵션이 설정되어 있으면 장치 저장소 카드에 있는 모든 파일이 암호화됩니다. 암호 복구 사용 옵션을 사용하면 Outlook® Web Access 2007을 통해 장치 PIN을 검색할 수 있습니다.
장치에 암호 정책을 적용하기 전에 신중하게 고려하십시오. 길고 복잡한 PIN일수록 보안 효과는 높아지지만 장치를 사용하기가 어려워질 수 있습니다. 암호 강도와 PIN을 요구하기 전 제한 시간을 결정하는 데 있어 보안과 사용 편의성 간에 적절한 균형을 찾는 것이 중요합니다. 암호 만료 및 암호 기록 적용 옵션을 설정해도 보안 수준을 높일 수 있지만 암호 및 PIN을 추적하는 과정이 너무 복잡해질 경우 사용자가 불편을 겪을 수 있습니다.
Exchange Server 2007 ActiveSync 사서함 정책을 사용하면 장치 보안을 향상시키는 데 도움이 되지만 일부 기능은 Windows Mobile 6.0을 필요로 합니다. Windows Mobile 6.0은 릴리스 후 바로 장치에서 사용할 수 있습니다. 그림 2의 기능 중 장치에서 암호화 필요, 암호 기록 적용 및 암호 만료(일) 기능은 모두 새 버전을 필요로 합니다. 하지만 Windows Mobile 5.0이 설치된 장치의 사용자에게도 새로운 Exchange Server 2007의 유연한 정책을 사용할 수 있습니다.
정책을 정의한 후에는 사용자에게 적용할 수 있습니다. Exchange 관리 콘솔에서 받는 사람 구성으로 이동한 다음 사서함을 선택합니다. ActiveSync 정책을 적용할 사서함 사용자를 선택한 다음 작업 창에서 속성을 선택합니다. 사서함 기능 탭으로 이동하여 Exchange ActiveSync를 두 번 클릭합니다. Exchange ActiveSync 속성 상자에서 찾아보기 단추를 클릭하여 사용자에게 적용할 ActiveSync 정책을 선택합니다(그림 3 참조). 같은 단계를 반복하여 사용자별로 다른 정책을 적용하거나 다음의 Exchange 관리 셸 명령을 사용하여 사용자 그룹에 정책을 적용할 수 있습니다.
그림 3 ActiveSync 사서함 정책 적용
그림 3 ActiveSync 사서함 정책 적용
Set-CASMailbox –Activesyncmailpolicy
마지막 단계는 최종 사용자 및 지원 부서를 교육하는 것입니다. Exchange Server 2007에 연결할 때는 지정된 길이의 PIN을 장치에 입력해야 한다는 것을 최종 사용자에게 알려 주어야 합니다(그림 4 참조). 적용된 보안 정책에 대한 교육을 통해 최종 사용자가 일상 업무에서 이러한 변경 내용을 불편하게 여기지 않도록 해야 합니다.
그림 4 ActiveSync 사서함 정책에는 PIN이 필요합니다.
그림 4 ActiveSync 사서함 정책에는 PIN이 필요합니다.
Outlook Web Access 2007을 이용한 셀프 서비스 원격 데이터 지우기 기능과 같이 Exchange Server 2007에서 새롭게 선보이는 기능을 알려 줄 수도 있습니다. 사용자가 장치를 분실한 경우 지원 부서에 연락하지 않고 Outlook Web Access에 있는 옵션 링크를 통해 장치 데이터 지우기를 실행할 수 있습니다(그림 5 참조). 이 기능은 근무 시간이 아닐 때 장치를 분실한 경우 상당히 유용할 수 있습니다.
그림 5 Outlook Web Access를 통한 장치 관리
그림 5 Outlook Web Access를 통한 장치 관리
마지막으로, 원격으로 장치 데이터를 지우는 방법을 지원 부서에 알려 줍니다. Exchange 관리 콘솔을 열고 받는 사람 구성으로 이동한 다음 사서함을 선택하기만 하면 됩니다. 여기에서 데이터 지우기를 실행할 사용자를 선택하고 작업 창에서 모바일 장치 관리를 선택합니다. 모바일 장치 관리 인터페이스는 그림 6과 같습니다. 한 명의 사용자가 여러 개의 Windows Mobile 장치를 Exchange 2007에 연결할 수 있으므로 데이터 지우기를 실행할 때는 장치를 잘못 선택하지 않도록 주의해야 합니다.
그림 6 사용자 장치 데이터 원격 지우기
그림 6 사용자 장치 데이터 원격 지우기

전자 메일 처리 및 검색
Windows Mobile 6.0에서는 전자 메일을 HTML 형식으로 읽고 '부재 중' 알림을 설정할 수 있으며(그림 7) 전자 메일에 플래그를 지정할 수 있습니다. Windows Mobile 6.0 장치에서 전자 메일 메시지에 플래그를 지정하면 Outlook에서 전자 메일에 플래그를 지정할 때와 똑같이 처리됩니다. 이제는 전자 메일 메시지를 읽지 않은 메시지로 표시하여 처리하는 것이 아니라 플래그를 지정해 두었다가 업무로 복귀했을 때 Outlook의 고급 기능을 사용하여 처리할 수 있습니다. HTML 형식의 전자 메일은 모바일 장치 사용자에게뿐만 아니라 전자 메일 스레드의 다른 사용자에게도 유용합니다. Windows Mobile 6.0을 사용하여 전자 메일에 회신하면 전자 메일이 기본 텍스트로 변환되지 않으므로 Outlook을 사용하여 전자 메일을 받는 다른 사용자에게도 더 효율적입니다.
그림 7 '부재 중' 메시지
그림 7 '부재 중' 메시지
Windows Mobile 6.0의 일정 기능도 대폭 향상되었습니다. 이제는 일정 항목 내에서 전달, 회신, 전체 회신 기능을 모두 이용할 수 있을 뿐 아니라 전체 초대자의 수락 상태를 볼 수도 있습니다.
Windows Mobile 6.0을 Exchange Server 2007과 함께 사용하면 검색 및 모바일 문서 액세스와 관련된 새로운 두 가지 기능을 활용할 수 있습니다. 모바일 장치를 사용할 때의 문제점 가운데 하나는 저장 용량이 제한되어 있다는 점입니다. 이 때문에 많은 사용자들은 전자 메일을 1~3일 정도만 장치에 보관할 수 있습니다. 또한 받은 편지함 중 한 폴더에서만 전자 메일 메시지를 봐야 하는 경우도 많습니다. 이와 같은 제한 때문에 이전 메시지나 사서함의 다른 폴더에 저장된 메시지에 액세스할 때는 문제가 발생할 수 있습니다.
Windows Mobile 6.0에서는 Exchange Server 2007 검색 및 인덱스 엔진을 통해 전체 사서함에 대해 무선 검색을 실행할 수 있습니다. 키워드를 사용하여 여러 폴더에서 전자 메일을 검색할 수 있습니다(그림 8 참조). 그런 다음 검색 결과에서 전자 메일 메시지를 실시간으로 가져올 수 있습니다.
그림 8 무선 전자 메일 검색
그림 8 무선 전자 메일 검색

모바일 문서 액세스
SharePoint®와 같은 문서 공동 작업 소프트웨어가 확산되고 있는 가운데 사용자들은 전송 가능한 최대 전자 메일 크기 제한을 피하기 위해 전자 메일에 문서를 첨부하는 대신 파일 공유 및 SharePoint 사이트의 링크를 보내는 경우가 많아졌습니다. 이와 같은 상황에서 VPN(가상 사설망)을 통해 회사 네트워크에 연결할 수 없다면 모바일 장치를 통해 이러한 문서에 액세스하는 것도 불가능할 수 있습니다. 외근이 많은 작업자는 업무에 큰 지장을 받을 수 있습니다.
Windows Mobile 6.0과 Exchange Server 2007을 함께 사용하면 읽기 전용 모드로 액세스할 수 있는 UNC 파일 공유 및 SharePoint 사이트를 통해 데이터에 액세스할 수 있습니다. Exchange Server 2007은 Windows Mobile 장치를 대신하여 이러한 문서에 대한 요청을 처리할 수 있습니다(그림 9 참조). VPN을 통해 회사 네트워크에 연결하지 않고도 전자 메일 메시지에 첨부된 문서만이 아니라 파일 공유 및 SharePoint 사이트에 있는 모든 파일에 액세스할 수 있습니다.
그림 9 UNC 링크를 통한 문서 액세스
그림 9 UNC 링크를 통한 문서 액세스
모바일 문서 액세스를 관리하려면 Exchange 관리 콘솔을 열고 탐색 트리의 서버 구성 아래에 있는 클라이언트 액세스를 선택합니다. 그런 다음 ActiveSync 탭으로 이동하여 Microsoft Server ActiveSync 개체를 선택한 후 작업 창에서 속성을 클릭합니다. 원격 파일 서버 탭에서 SharePoint 사이트 및 파일 서버의 호스트 이름에 대한 허용 목록과 차단 목록을 구성할 수 있습니다.
이 작업이 완료되면 Exchange ActiveSync 사서함 정책으로 돌아가 Windows® 파일 공유 및 Windows SharePoint Services에 대한 확인란이 선택되어 있는지 확인합니다(그림 10 참조).
그림 10 문서 액세스 활성화
그림 10 문서 액세스 활성화
이제는 모든 Windows Mobile 장치 사용자들이 보다 쉽게 문서에 액세스할 수 있습니다.

요약
오늘날과 같이 원격 업무가 많은 환경에서는 Windows Mobile 장치와 같이 언제 어디서나 정보에 액세스할 수 있는 강력한 솔루션이 필요합니다. 이에 따라 모바일 장치의 보안 및 관리도 IT 부서의 중요한 문제가 되고 있습니다. Exchange Server 2007은 Windows Mobile 6.0과 함께 Windows Mobile 장치에 대한 정책 생성 및 대상 설정을 쉽게 수행할 수 있도록 하여 문제를 해결하고 원격 작업자에게 새로운 기능을 제공하는 기반이 되고 있습니다.
Windows Mobile 리소스
Exchange Server 2007 배포 및 Windows 모바일 메시징에 대하여 자세히 알아볼 수 있는 다양한 리소스가 있습니다.
  • Exchange Server TechCenter
  • Exchange 2007 모바일 액세스 기본 사항
  • Exchange ActiveSync 관리
  • Windows Mobile 가상 랩
  • Windows Mobile 6 SDK

Yee-Chen Tjie는 New England 지역의 Microsoft 기술 전문가로서, 모바일 및 통합 통신 솔루션을 담당하고 있습니다.
© 2007 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..


 Communications: Exchange Server 2007로 규정 준수 개선
Communications Alan Maddison

Exchange Server 2007로 규정 준수 개선
한 눈에 보기:
  • 관리되는 폴더
  • 전송 규칙
  • 메시지 분류
  • 저널링

분석가들은 기업 문서의 약 75%가 전자 메일을 통해 작성되고 교환되는 것으로 추산하고 있습니다. 두말할 여지없이 여러분의 조직에서도 방대한 양의 지적 재산을 메시징 서버에 저장하고 있을 것입니다. 따라서
기업의 중요한 데이터가 대량으로 보관되어 있는 메시징 서버를 관리하는 관리자의 어깨에는 막중한 책임감이 지워지고 있습니다. 또한 기업 데이터의 보관 및 저장에 대한 요구 사항을 규정하는 정부 법안과 지방 자치 법안이 점차 증가함에 따라 이러한 업무를 처리하는 과정이 점점 복잡해지면서 그 중요성이 더욱 부각되고 있습니다.
또한 기업의 자산 보호 및 규정 준수의 필요성이 대두됨에 따라 IT 부서에 막중한 책임감이 부여되고 있습니다. Microsoft는 Exchange Server 2007에 다양한 변경 사항과 새로운 기능을 구현하여 Exchange의 규정 준수 기능을 획기적으로 개선하는 동시에 실제 관리 작업은 보다 쉽게 수행할 수 있도록 하였습니다. 이번 기사에서는 규정 준수 기능을 개선하는 Exchange Server 2007의 주요 변경 사항을 살펴보겠습니다.

규정 준수에 대한 이해
Exchange Server 2007을 본격적으로 설명하기 전에, 몇 가지 요구 사항에 대해 설명하고자 합니다. 규정 준수 요구 사항은 크게 정보 저장, 액세스 제어, 데이터 무결성의 세 가지 영역으로 나눌 수 있습니다. 예를 들어 미국의 경우 SEC Rule 17A-4에서는 특정 주식 거래소 회원, 브로커 및 딜러에 대한 데이터 보존 정책을 명시하고 있어 금융 기관에서는 해당인의 전자 메일을 캡처, 인덱싱, 보관, 검색할 수 있습니다. 데이터 액세스 제어에 대해서는 HIPAA(Health Insurance Portability and Accountability Act), GLB Act(Gramm-Leach-Bliley Act), California Senate Bill 1386(SB 1386)을 비롯한 다양한 규정이 함께 적용되고 있습니다. HIPAA 및 GLB Act는 개인 정보의 보안 및 기밀 유지에 대해 규정하고 있는 반면, SB 1386은 기밀 데이터와 관련된 컴퓨터 보안 침해 사례의 공개를 규정합니다.
데이터 무결성 요구 사항은 Sarbanes-Oxley (SOX), PATRIOT Act, Basel II와 같이 잘 알려진 중요한 법규에서 규정합니다. 그러나 여기서 언급한 법안들은 시작에 불과합니다. 현재 전 세계에 걸쳐 약 3만 5천 개 이상의 관련 법안이 시행되고 있는 것으로 알려져 있습니다. 이러한 규제를 통해 기업은 정보 보존, 데이터 액세스 제어, 데이터 무결성 유지 방법과 관련된 위험을 통제할 수 있게 됩니다. 그렇다면 관리자로서 이러한 위험을 관리하면서 관련 요구 사항을 모두 충족하려면 어떻게 해야 할까요?
그 첫 번째 단계는 규정 준수 및 보관 정책을 문서화하는 것입니다. 다음 단계는 이러한 정책을 구현하고 지속적으로 관리하는 것입니다. Exchange Server 2007의 관리되는 폴더, 전송 규칙 에이전트, 메시지 분류, 저널링 에이전트를 통해 이러한 정책을 적용할 수 있습니다.

관리되는 폴더
데이터 보존(또는 레코드 관리)은 규정 준수의 뼈대가 되는 중요한 부분입니다. Exchange Server 2007은 관리자가 데이터를 관리하는 방식에 있어 획기적인 도약을 이루어 냈습니다. Exchange Server 2007의 레코드 관리는 쓸모없는 메시지는 제거하고, 필요한 메시지는 보존하며, 메시지를 분류할 책임은 해당 사용자에게 있다는 세 가지 원칙을 기반으로 합니다.
대부분의 Exchange 관리자는 사서함에 적용할 수 있는 정책인 Exchange Server 2003 사서함 관리자 정책에 대해 잘 알고 있습니다. Exchange Server 2007의 관리되는 폴더를 사용하면 관리자가 중앙에서 폴더를 관리할 수 있으므로 새로운 기본 폴더나 사용자 지정 폴더를 만들어 배포할 수 있으며 이렇게 만든 폴더는 이동하거나, 이름을 변경하거나, 대부분의 경우 삭제할 수 없습니다. 또한 SDK를 사용하면 사용자가 사서함에 추가할 폴더를 선택할 수 있는 웹 기반의 셀프 서비스 응용 프로그램을 만들 수 있습니다.
그림 1에서 볼 수 있는 것과 같이 Exchange 관리 콘솔에서는 마법사를 통해 폴더를 만들 수 있습니다. 이 기능은 Exchange 관리 셸 New-ManagedFolder cmdlet에서도 제공합니다.
그림 1 Exchange 관리 콘솔을 사용하여 새 폴더 만들기
그림 1 Exchange 관리 콘솔을 사용하여 새 폴더 만들기
그림 2와 같이 마법사가 시작됩니다. 폴더를 만드는 과정은 아주 간단합니다. 폴더 이름과 폴더에 대한 설명을 입력한 다음 새로 만들기 단추를 누르면 됩니다. 폴더 생성이 완료되면 확인 메시지가 나타납니다.
그림 2 사용이 편리한 마법사를 통해 간편하게 관리되는 폴더 생성
그림 2 사용이 편리한 마법사를 통해 간편하게 관리되는 폴더 생성
데이터 보존 정책이 마련되면 관리자는 사용자에게 메시지를 간편하게 정렬하고 저장할 수 있는 수단을 제공하여 조직의 요구 사항을 준수하는 방식으로 데이터를 보존할 수 있도록 해야 합니다. 사용자에게 3년, 5년 또는 7년 동안 데이터를 보존할 수 있는 세 가지 유형의 사용자 지정 폴더를 배포한다고 가정해 보십시오. 관리되는 폴더를 만든 다음에는 각 폴더에 콘텐츠 설정을 적용해야 합니다. 관리되는 내용 설정 마법사를 사용하여 이를 수행할 수 있습니다.
메시징 관리자는 일수로 계산되는 콘텐츠 만료 설정과 콘텐츠가 만료된 경우 취할 후속 작업을 제어할 수 있습니다. 다음의 다섯 가지 작업을 수행할 수 있습니다.
  • 삭제 및 복구 허용
  • 보존 기간이 지난 것으로 표시
  • 관리되는 사용자 지정 폴더로 이동
  • 지운 편지함 폴더로 이동
  • 영구 삭제
이 설정을 구성할 때는 세 가지 매개 변수에 각별한 주의를 기울여야 합니다. 첫 번째는 메시지 만료 값으로, 이 값은 일수로 계산되기 때문에 윤년은 따로 계산해야 합니다. 기업 관리에서는 만료일이 하루밖에 남지 않았다고 해도 예정일보다 앞당겨 콘텐츠를 삭제해서는 안 됩니다. 두 번째 매개 변수는 만료 기간이 시작되는 날짜입니다. 법률 팀의 특별한 지침이 없다면 일반적으로 만료 기간은 메시지가 사서함에 배달된 날짜를 기준으로 시작됩니다. 세 번째 매개 변수는 만료된 콘텐츠에 대해 수행하는 작업입니다. 가장 좋은 방법은 해당 항목을 영구 삭제하는 것입니다. 또한 콘텐츠 설정을 사용하면 메시지를 SMTP 주소로 전달하여 저널링할 수 있습니다.
관리되는 폴더 사서함 정책을 사용하여 관리되는 폴더를 사서함에 적용할 수 있습니다. Exchange 관리 콘솔에서는 이러한 정책을 만들 수 있는 다른 마법사를 제공합니다. 이 정책을 사용하면 여러 폴더를 선택하고 그룹화할 수 있으며 여러 폴더를 단일 정책에 연결할 수 있습니다.
일반적으로 사서함을 만드는 동안 관리되는 폴더 사서함 정책을 적용했을 것입니다. 그러나 대신 Exchange 관리 셸을 사용하면 Set-Mailbox cmdlet을 통해 기존 사서함에 정책을 적용할 수 있습니다. "retention"이라는 이름의 관리되는 폴더 사서함 정책을 USER1이라는 별칭을 가진 전자 메일 계정에 적용한다고 가정해 보겠습니다. 이 작업을 수행하려면 아래의 명령을 사용하십시오.
Set-Mailbox –Identity USER1
–ManagedFolderMailboxPolicy “retention”
관리되는 폴더 및 해당 콘텐츠 설정은 보존 및 규정 준수 과정을 관리하는 데 있어 강력한 메커니즘을 제공합니다. 사용자는 이를 통해 관련 전자 메일을 분류하고 중앙에서 관리하는 폴더에 데이터를 저장할 수 있을 뿐 아니라, 검색 요청이나 보존 명령이 있을 때는 이러한 항목을 저널링할 수 있으므로 법규를 준수하기가 용이합니다.

전송 규칙
Exchange Server 2007에는 두 가지 유형의 전송 규칙 에이전트가 있지만, 규정 준수가 목적이라면 허브 전송 서버에서 실행되는 에이전트에 보다 관심이 갈 것입니다. 이 에이전트를 사용하면 Exchange 조직을 통한 메시지 흐름에 정책 기반의 규정 준수 규칙을 보다 쉽게 적용할 수 있습니다. 반면 Edge 전송 서버 규칙 에이전트를 사용하면 스팸과 바이러스로부터 조직을 보호할 수 있습니다.
일반적인 규정 및 준수 요구 사항의 경우 관리자는 다음 사항에 대해 책임을 져야 합니다.
  • 여러 그룹으로 된 보낸 사람 그룹과 받는 사람 그룹 간의 상호 작용을 제한합니다.
  • 적절하지 못한 콘텐츠가 회사 안팎으로 이동하는 것을 제한해야 합니다.
  • 기밀 정보를 필터링합니다.
  • 특정 사용자 및 그룹에서 전송 또는 수신된 메시지를 추적 또는 보관합니다.
  • 배달 전에 인바운드 및 아웃바운드 메시지를 리디렉션하여 검사합니다.
  • 법적 고지 사항을 적용합니다.
허브 전송 서버가 Exchange 2007 토폴로지에서 수행하는 역할 때문에 이 에이전트에 대해 허브 전송 서버가 선택되었습니다. Exchange 2007에서 토폴로지의 변경 내용은 매우 중요한 의미를 지니며, 결과적으로 Exchange는 Active Directory® 토폴로지와 더욱 긴밀하게 통합되었습니다. 메일의 흐름이 조직을 통과하는 동안 특정 지점에서 허브 전송 서버를 통해 처리됩니다. 이 허브 전송 서버는 현재 전송 규칙 구성에 대해 Active Directory에 쿼리하고 서버에서 처리되는 모든 메시지에 대해 해당 규칙을 적용합니다.
허브 전송 서버에서 구성된 모든 전송 규칙은 Active Directory 서비스를 통해 다른 모든 허브 전송 서버에 복제됩니다. 관리자는 사이트 및 토폴로지가 복제에 영향을 미치는 영향을 인지하고 있어야 하며, 조직 전체에 적용되는 규칙을 얼마나 빨리 배포할 수 있는지 확인해야 합니다.
또한 허브 전송 서버에서는 받는 사람의 받는 사람 캐시 및 메일 그룹 조회를 유지 관리한다는 사실을 잘 알고 있어야 합니다. 새로 고침 간격은 기본 4시간으로 설정되어 있으며 이는 메시지에 규칙이 적용되는 시간에 영향을 미칩니다.
허브 전송 서버의 전송 규칙은 모든 모임 요청, 일반 메시지, 암호화된 메시지 및 인증된 사용자 간에 전송된 권한 보호 메시지를 평가합니다. 익명으로 전송된 모든 전자 메일 메시지는 메시지 유형, 보낸 사람, 받는 사람에 관계없이 평가됩니다.
각각의 전송 규칙은 조건, 예외, 작업과 같은 요소로 구성되어 있습니다. 조건은 메시지 확인 프로세스에 사용된 메시지 특성(예: 헤더, 받는 사람, 보낸 사람)을 나타내는 데 사용됩니다. 메시지가 특정 규칙에 대한 모든 조건을 충족하고 구성한 예외에 해당하지 않으면 작업이 적용됩니다. 예외는 선택적으로 사용되지만 예외가 구성되어 있는 경우 예외 조건에 하나라도 해당하는 메시지는 전송 규칙에서 처리되지 않습니다. 작업은 각 전송 규칙의 필수 구성 요소이며 메시지 처리 방법을 지정합니다. 그림 3에는 허브 전송 서버에서 구성된 전송 규칙을 기반으로 적용할 수 있는 작업이 나열되어 있습니다.
Figure 3 허브 서버의 전송 규칙에 사용할 수 있는 작업 (Close Figure 3)

작업 | 작업 이름 | 설명
메시지와 함께 이벤트 로깅 | LogEvent | 로컬 컴퓨터의 응용 프로그램 로그에 이벤트를 추가합니다.
제목 앞에 문자열 추가 | PrependSubject | 메시지 제목 필드의 맨 앞에 문자열을 추가합니다.
메시지 분류 적용 | ApplyClassification | 메시지에 메시지 분류를 적용합니다.
법적 고지 사항 텍스트 추가 | ApplyDisclaimer | 메시지에 법적 고지 사항을 적용합니다.
SCL(스팸 지수)을 값으로 설정 | SetScl | 메시지에 SCL(스팸 지수)을 설정합니다.
헤더를 값으로 설정 | SetHeader | 새 메시지 헤더 필드를 만들거나 기존 메시지 헤더 필드를 수정합니다.
헤더 제거 | RemoveHeader | 메시지에서 지정된 메시지 헤더 필드를 제거합니다.
받는 사람 필드 주소에 받는 사람 추가 | AddToRecipient | 메시지의 받는 사람 주소 목록에 받는 사람을 하나 이상 추가합니다. 실제 받는 사람은 추가된 주소를 볼 수 있습니다.
메시지에 참조 주소 추가 | CopyTo | 메시지의 참조(Cc) 필드에 받는 사람을 하나 이상 추가합니다. 실제 받는 사람은 실제 주소를 볼 수 있습니다.
메시지에 숨은 참조 추가 | BlindCopyTo | 전자 메일 메시지의 Bcc(숨은 참조) 주소 목록에 전자 메일 받는 사람을 하나 이상 추가합니다.
주소에 메시지 리디렉션 | RedirectMessage | 관리자가 지정한 하나 이상의 받는 사람에게 메시지를 리디렉션합니다. 메시지는 실제 받는 사람에게 배달되지 않으며 받는 사람이나 보낸 사람에게 알림이 전송되지 않습니다.
보낸 사람에게 확장 상태 코드와 함께 반송 메시지 보내기 | RejectMessage | 메시지를 삭제하고 보낸 사람에게 배달 못 함 확인 메일을 전송합니다. 받는 사람에게는 메시지 또는 알림이 전송되지 않습니다.
자동으로 메시지 삭제 | DeleteMessage | 메시지를 삭제합니다. 받는 사람이나 보낸 사람에게 알림이 전송되지 않습니다.
전송 규칙을 만들려면 그림 4와 같이 Exchange 관리 콘솔 및 규칙 전송 마법사를 사용합니다. 또는 규칙 생성을 스크립팅하려면 Exchange 관리 셸을 사용합니다.
그림 4 규칙 전송 마법사를 시작하여 허브 전송 서버에서 전송 규칙 구성
그림 4 규칙 전송 마법사를 시작하여 허브 전송 서버에서 전송 규칙 구성
SDK를 사용하여 Exchange 내의 SMTP 이벤트를 기반으로 메시지를 처리하는 사용자 지정 전송 에이전트를 작성할 수도 있다는 것을 기억해 두시기 바랍니다. 그러나 이 방법은 강심장이 아닌 분께는 권해 드리고 싶지 않군요.

메시지 분류
새로운 메시지 분류 도구에서는 메타데이터를 사용하여 특정 메시지의 본래 용도 또는 대상을 정의합니다. 클라이언트 쪽에서는 Outlook® Web Access(OWA) 또는 Outlook 2007에서 이 메타데이터를 사용하여 분류에 대한 설명을 사용자가 읽을 수 있는 형태로 표시할 수 있습니다. 서버 쪽에서는 전송 규칙 에이전트가 분류를 기준으로 메시지에 대한 작업을 수행할 수 있습니다.
Exchange Server 2007에는 기본적으로 'A/C 권한 있음, 첨부 파일이 제거됨, 회사 기밀, 회사 내부'와 같은 유형의 메시지 분류가 포함되어 있습니다. 그러나 많은 조직에서는 각각의 조직에 맞는 고유한 분류를 만들고자 할 것입니다. Exchange 관리 셸의 new-MessageClassification cmdlet을 사용하면 새 분류를 만들 수 있습니다. 예를 들어 금융 데이터에 대한 액세스를 제한하려면 Financial—Confidential(금융-기밀)이라는 이름의 메시지 분류를 만들면 됩니다.
new-MessageClassification –Name finance –DisplayName “Financial—Confidential”
-RecipientDescription “This message contains confidential financial data.”
–SenderDescription “Restricts recipients of messages that contain confidential financial data”
필수 매개 변수는 Name, DisplayName, SenderDescription의 세 가지이지만 기본적인 기능을 사용하려면 최소한 RecipientDescription을 추가해야 합니다. 그림 5에서 이 새 분류가 OWA 인터페이스에 나열되어 있는 것을 볼 수 있습니다.
그림 5 새로 만들어진 Financial Confidential(금융-기밀) 분류가 포함되어 있는 메시지 분류 목록
그림 5 새로 만들어진 Financial Confidential(금융-기밀) 분류가 포함되어 있는 메시지 분류 목록
이 명령은 로캘 매개 변수를 사용하지 않으므로 Exchange 조직 내의 모든 로캘에 적용됩니다. 그러나 글로벌 업무를 지원하는 경우에는 로캘별 사용자 지정 메시지 분류를 만들어야 합니다.
또한 분류에 대한 권한을 올바르게 설정해야 합니다. 기본적으로 새로 만들어진 모든 메시지 분류의 경우 인증된 사용자에게 읽기 권한이 부여됩니다. 그러나 관리자는 이러한 메시지 분류를 나누어 사용자가 자신의 역할에 맞는 메시지 분류에만 액세스할 수 있도록 해야 합니다. 또한 각 분류에는 다른 메시지 분류에 대한 상대적 우선 순위가 있습니다. 우선 순위는 설명 순서를 지정하며 그에 따라 전달된 메시지와 관련된 분류나 회신된 메시지와 관련된 분류 등이 결정됩니다.
필요한 분류를 만든 다음에는 분류를 사용할 전송 규칙을 만듭니다. 이러한 메시지 분류는 실제 작업과 연결되지 않고 정보 제공의 목적으로만 사용될 수 있습니다. 그림 6에서 볼 수 있듯이 메시지 분류를 다양한 방식으로 전송 규칙과 결합할 수 있습니다. 필자는 Financial(금융)로 분류된 메시지를 모니터링하는 전송 규칙을 만들었습니다. 메시지가 이와 같이 표시될 경우 전송 규칙 에이전트는 받는 사람을 검사합니다. 받는 사람 중 한 명이라도 Financial Dept(금융 부서) 메일 그룹의 구성원이 아닌 경우 해당 메시지는 사용자 지정된 배달 못 함 메시지와 함께 보낸 사람에게 반환됩니다.
그림 6 Financial(금융)로 분류된 메시지에 사용할 전송 규칙 만들기
그림 6 Financial(금융)로 분류된 메시지에 사용할 전송 규칙 만들기
또한 메시지 분류를 사용하여 조직에 "교신 차단 영역"을 설정할 수 있습니다. 예를 들어 특정 개인과 부서 간의 통신을 제한해야 할 때가 있습니다. 바로 이러한 경우 메시지 분류를 사용할 수 있습니다.

저널링 에이전트
규정 준수의 측면에서 볼 때 저널링은 매우 강력하지만 한편으로는 다루기 힘든 도구일 수 있습니다. 그렇지만 기쁘게도 Exchange Server 2007은 보다 유연한 저널링 기능을 제공합니다. 사서함 데이터베이스 수준에서 적용되는 표준 저널링과 함께, 받는 사람 수준에서 적용되는 새로운 고급 저널링을 지원합니다. 고급 저널링을 이용하면 개인 사용자 및 메일 그룹을 저널링할 수 있습니다. 이 같은 기능 덕택에 보관 요청이나 법원의 보존 명령 같은 요청을 보다 간단하게 처리할 수 있게 되었습니다. 또한 저널링이 저장소 및 성능에 미치는 영향을 보다 잘 제어할 수 있게 되었습니다.
예를 들어 가장 유연한 새 옵션 중 하나는 동적 메일 그룹을 기반으로 한 저널링 지원 기능입니다. 조직에서 특정한 개인의 전자 메일 메시지를 지속적으로 보관해야 하는 경우가 있을 수 있습니다. 이는 내부 HR 조사나 소송이 진행되는 경우에 해당합니다. 동적 메일 그룹을 사용하면 관리자는 이미 저널링되고 있는 그룹에 사용자를 추가하거나 제거할 수 있습니다. 이렇게 하면 쉽고 빠르게 특별 저널링을 제공할 수 있습니다.
Exchange 관리 콘솔 및 동적 메일 그룹 마법사를 사용하면 그림 7과 같이 사용자 컨테이너를 선택할 수 있으며, 특정 Active Directory 특성 값을 기반으로 하여 포함된 사서함을 필터링할 수 있습니다. 그림 7에서와 같이 사용자 지정 특성 중 한 가지를 선택하면 이 값을 추가하거나 제거함으로써 관리자가 저널링할 사용자를 제어할 수 있습니다.
그림 7 동적 메일 그룹 마법사를 사용하여 저널링 규칙 구성
그림 7 동적 메일 그룹 마법사를 사용하여 저널링 규칙 구성
Exchange 2007의 저널링에 대한 자세한 내용을 보려면 David Strome의 2006년 12월 기사 "Exchange 2007의 더욱 강력해진 저널링"을 참조하십시오. "저널링 개요"에서도 상세한 정보를 볼 수 있습니다.

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


 Identity Management: 한 단계 준비 워크플로 만들기
Identity Management Aung Oo

한 단계 준비 워크플로 만들기
한 눈에 보기:
  • MIISWorkflow 사용
  • 구현 및 구성
  • MIISWorkflow 확장

조직에서 계정을 요청하고 승인하는 웹 기반 인터페이스를 찾고 있고 Microsoft Identity Lifecycle Manager 2007(이전에는 Microsoft Identity Integration Server 2003)을 사용하고 있다면 MIISWorkflow 응용 프로그램을 통해 간단하면서도 효과적인 솔루션을 만들 수 있습니다.
MIISWorkflow는 MIIS 2003 Resource Tool Kit 2.0의 일부로, 2004년 12월부터 제공되고 있습니다. MIISWorkflow는 모든 환경에 적합한 솔루션이라고 말할 수는 없지만 조직의 필요에 맞는 사용자 지정 응용 프로그램을 만들기 위한 좋은 토대가 됩니다.
MIISWorkflow는 웹 응용 프로그램을 통합함으로써 ILM 2007에 승인 기반 준비 기능을 제공합니다. MIISWorkflow는 사용자의 요청을 수락한 다음 특정 요청과 관련하여 결정을 내릴 수 있는 권한이 있는 승인자(주로 관리자)에게 요청을 라우팅하는 한 단계의 워크플로 기반 준비 시스템입니다. 승인자의 결정이 내려지면 ILM은 이를 기반으로 ILM에 정의된 비즈니스 규칙을 사용하여 연결된 디렉터리에 사용자 계정을 준비하는 작업을 수행합니다.
이 응용 프로그램에서는 한 단계 워크플로만 사용할 수 있으며, 병렬 경로가 포함된 다단계 승인 프로세스나 그래픽 인터페이스가 포함된 워크플로 프로세스 같은 복잡한 워크플로 기능은 만들지 못합니다. 조직에 복잡한 워크플로 기능이 필요하지 않다면 MIIS Resource Tool Kit에 포함된 MIISWorkflow 샘플을 사용하여 솔루션을 구현할 수 있습니다.
이 문서에서는 가상의 회사에 있는 HR(인사 관리) 부서에 중점을 두고 설명하겠습니다. 일반적으로 HR 시스템은 조직 내의 모든 직원 정보가 저장되는 신뢰할 수 있는 소스입니다. 그러나 이러한 시스템에는 대개 정규 직원에 대한 자세한 데이터만 있고 계약 직원이나 인턴 사원 같은 임시직 직원에 대한 정보는 없는 경우가 많습니다. HR 시스템에 포함된 데이터를 통해서는 사용자 계정 정보를 비롯하여 사용자가 액세스할 수 있는 시스템을 추적할 수 없습니다. 지금부터 조직 내의 임시직 직원을 대상으로 간단한 추적 시스템을 만드는 방법을 살펴보겠습니다.

MIISWorkflow를 기반으로 시스템 만들기
조직에서 MIISWorkflow를 사용하여 얻을 수 있는 한 가지 이점은 기존 HR 시스템과 작동하는 응용 프로그램을 만들 수 있다는 것입니다. 신규 직원을 채용하면 HR 시스템에 해당 사용자의 정보가 추가됩니다. ILM에서 연결된 디렉터리에 계정을 준비하기 전에 먼저 이 정보를 MIISWorkflow 데이터베이스로 보낸 다음 워크플로 응용 프로그램을 사용하여 승인자에게 사용자 정보를 라우팅하도록 ILM 흐름을 설계할 수 있습니다.
조직에서 HR 시스템을 통해 임시직 직원을 추적하지 않는 경우에는 MIISWorkflow 응용 프로그램을 신뢰할 수 있는 데이터 소스로 사용하여 엔터프라이즈 디렉터리의 직원 계정을 관리할 수 있습니다. 워크플로 응용 프로그램은 승인을 얻는 데 필요한 서류 기반의 관리 작업을 줄여 주므로 사용자가 디렉터리와 응용 프로그램의 계정에 액세스하기 위해 며칠씩 기다리지 않아도 됩니다. 또한 MIISWorkflow를 사용하면 액세스 권한을 빠르게 취소하여 조직의 보안을 강화할 수도 있습니다.
사용자가 액세스할 수 있는 시스템의 수, 각 계정의 요청 날짜 및 종료 날짜, 각 계정의 요청자 및 승인자를 추적하는 감사 도구로 MIISWorkflow를 활용할 수도 있습니다. 또한 자세한 계정 기록이 포함된 보고서를 만들 수 있으므로 조직은 SOX(Sarbanes-Oxley) 및 HIPAA 같은 정부 규정을 쉽게 준수할 수 있습니다.
MIISWorkflow 응용 프로그램은 IIS에서 실행되며 ILM 2007의 디렉터리 통합 및 준비 기능을 사용하여 연결된 디렉터리에 계정을 준비하거나 준비 취소합니다. 워크플로 응용 프로그램의 구성 요소에는 ASP.NET 웹 페이지의 집합, SQL Server™ 데이터베이스, 관리 에이전트 및 권한 부여 정책 저장소가 포함됩니다(그림 1 참조). 워크플로 응용 프로그램은 데이터 저장을 위해 SQL Server를, 인증을 위해 Active Directory®를, 그리고 권한 부여를 위해 Windows® Authorization Manager(일반적으로 AzMan이라고 함)와 정책 저장소를 사용합니다.
그림 1 MIISWorkflow 응용 프로그램 아키텍처
그림 1 MIISWorkflow 응용 프로그램 아키텍처
C#과 ASP.NET을 사용하여 워크플로 응용 프로그램을 확장하고 사용자 지정할 수 있습니다. MIISWorkflow는 ContractorApproval, ContractorHistory, ContractorRequest, ContractorStatus 및 ContractorUpdate라는 다섯 개의 .aspx 페이지로 구성됩니다. 이 페이지를 통해 관리자는 시스템의 각 사용자 계정 상태를 요청, 업데이트, 승인 및 추적할 수 있습니다. 기본적으로 MIISWorkflow 응용 프로그램은 Kerberos를 이용하기 위해 IIS Windows 통합 인증을 사용하도록 설정됩니다.
워크플로 응용 프로그램에서는 승인자의 작업을 기반으로 ILM을 트리거하고 ILM에서는 정의된 규칙을 사용하여 연결된 디렉터리에 사용자 계정을 준비하거나 준비 취소합니다. 요청에 대해 작업이 수행되면 곧바로 이 응용 프로그램에서 ILM을 트리거하므로 연결된 디렉터리에서 준비 및 준비 취소를 위해 다음번 ILM 동기화 주기가 발생할 때까지 요청이 대기할 필요가 없습니다.
워크플로 응용 프로그램을 사용하려면 사용자 계정 정보를 저장할 MIISWorkflow 데이터베이스가 필요합니다. 이 데이터베이스는 ILM에서 메타버스(metaverse) 정보를 저장하는 데이터베이스와는 별개의 데이터베이스이지만 동일한 SQL Server 인스턴스에 구성됩니다. 권한 있는 사용자가 워크플로 응용 프로그램을 통해 계정을 요청하면 MIISWorkflow 데이터베이스에 해당 정보가 저장됩니다. 이 정보는 승인자가 해당 페이지에 액세스할 때 ASP.NET 웹 페이지를 통해 렌더링됩니다. 작업에 대한 기록 및 계정에 대한 기타 정보도 이 데이터베이스에 저장됩니다. ILM에서는 워크플로 응용 프로그램과 함께 제공되는 SQL Server 관리 에이전트를 사용하여 MIISWorkflow 데이터베이스에서 정보를 가져온 다음 필요에 따라 계정을 준비하거나 준비 취소합니다.
권한 부여를 위해 MIISWorkflow에서 사용하는 AzMan은 RBAC(역할 기반 액세스 제어)를 제공하므로 할당된 역할에 따라 각 사용자가 응용 프로그램에서 수행할 수 있는 관리 작업을 제어할 수 있습니다. RBAC에 대한 자세한 내용은 go.microsoft.com/fwlink/?LinkId=85825를 참조하십시오. Active Directory에서 사용자가 인증되어 액세스 권한이 부여되고 나면 워크플로 응용 프로그램에서 AzMan 권한 부여 저장소에 정의된 역할을 확인하여 사용자가 수행할 수 있는 작업에 대해 권한을 부여합니다. 워크플로 응용 프로그램에는 계약 직원 요청자와 계약 직원 승인자라는 두 개의 미리 정의된 역할이 있습니다. 계약 직원 요청자 역할이 할당된 사용자나 그룹은 응용 프로그램을 통해 요청 작업만 할 수 있습니다. 계약 직원 승인자 역할이 할당된 사용자나 그룹은 요청을 만들거나 요청을 승인 또는 거부할 수 있습니다.
MIISWorkflow 응용 프로그램 권한 부여 정책은 XML 파일에 저장됩니다. Windows 사용자 및 그룹이나 응용 프로그램 그룹을 정의된 역할에 할당할 수 있습니다. 응용 프로그램 그룹의 경우 LDAP 쿼리를 통해 특성 값을 기반으로 사용자의 Active Directory 또는 ADAM(Active Directory Application Mode) 계정 개체를 런타임에 조회할 수 있습니다. 예를 들어 department=‘marketing’이라는 쿼리에서 사용자가 해당 그룹에 있으면 true가 반환됩니다.

MIISWorkflow 사용
응용 프로그램 관리자는 AzMan을 통해 응용 프로그램에 대한 액세스를 제어합니다. 조직에서 응용 프로그램을 어떻게 사용하는지에 따라 모든 도메인 사용자 또는 선택한 그룹에게만 계약 직원 요청자 역할을 부여할 수 있습니다. 계약 직원 승인자 역할은 요청을 승인하거나 거부할 권한이 있는 사용자와 그룹에만 부여해야 합니다. 일반적으로 선별된 HR 관리자와 시스템 및 그룹 관리자가 이 역할을 보유합니다. 기본적으로 MIISWorkflow 응용 프로그램에서는 인증 방법으로 IIS Windows 통합 인증을 사용하므로 사용자의 Windows 데스크톱 로그온 자격 증명을 통해 사용자를 인증합니다. 따라서 사용자가 응용 프로그램에 대해 인증할 때 자격 증명을 제공하라는 메시지가 다시 표시되지 않습니다.
계약 직원 요청자 역할의 사용자는 브라우저에서 응용 프로그램의 Contractor Request(계약 직원 요청) 페이지로 이동할 수 있으며 계약 직원 정보를 제공하여 이 직원에 대한 계정을 요청할 수 있습니다. 그림 2는 Contractor Request(계약 직원 요청) 페이지를 보여 줍니다.
그림 2 New Contractor Request(새 계약 직원 요청) 페이지
그림 2 New Contractor Request(새 계약 직원 요청) 페이지
계약 직원 요청자 역할의 사용자는 관련 계약 직원의 정보를 채운 다음 요청을 전송합니다. 이 페이지에는 요청 승인을 위한 링크와 상태 확인을 위한 링크가 있지만 요청자는 계약 직원 승인자 역할에도 포함되어 있어야만 승인자 페이지에 액세스할 수 있습니다. 요청자는 Contractor Status(계약 직원 상태) 링크를 클릭하여 자신의 요청을 볼 수는 있지만 다른 사용자가 전송한 요청의 상태는 볼 수 없습니다.
계약 직원 승인자 역할의 사용자만 응용 프로그램의 Contractor Approval(계약 직원 승인) 페이지에 액세스할 수 있으며 여기에서 정보를 검토한 후 요청을 승인하거나 거부할 수 있습니다. 그림 3은 Contractor Approval(계약 직원 승인) 웹 페이지 인터페이스를 보여 줍니다.
그림 3 Contractor Approval(계약 직원 승인) 페이지
그림 3 Contractor Approval(계약 직원 승인) 페이지
계약 직원 승인자 역할의 사용자는 모든 요청자가 전송한 요청을 볼 수 있습니다. 또한 요청을 승인할 수 있으며, 한 번만 승인하거나 거부하면 다음 페이지로 요청을 라우팅할 수 있습니다. 승인자가 승인하거나 거부하고 나면 Contractor Approval(계약 직원 승인) 페이지에서 요청이 사라지므로 중복 승인 작업이 최소화됩니다.
MIISWorkflow 응용 프로그램에는 새로운 요청에 대해 알려 주는 알림 메커니즘이나 백로그가 별도로 없으므로 승인자는 조직의 요구 사항에 따라 새 요청을 검토하고 보류 중인 요청에 대해 작업을 수행하기 위해 정기적으로 Contractor Approval(계약 직원 승인) 페이지에 액세스해야 합니다. 승인자가 페이지에서 요청을 승인하거나 거부하면 곧바로 응용 프로그램에서 ILM을 트리거하고 승인자의 작업을 기반으로 연결된 디렉터리에 계정이 준비되거나 준비 취소됩니다.
그림 4 Contractor Status(계약 직원 상태) 페이지
그림 4 Contractor Status(계약 직원 상태) 페이지
보류 중인 요청의 상태와 완료된 요청에 대한 기록은 Contractor Status(계약 직원 상태) 페이지에서 추적할 수 있습니다(그림 4 참조). 요청자는 이 페이지에서 몇 가지 작업을 수행할 수 있습니다. 예를 들어 직원 ID, 이름, 성, 부서, 상태, 마지막으로 수정한 날짜 등의 정보를 비롯하여 자신의 요청을 볼 수 있습니다. 또한 기존 정보를 편집하거나 기록을 보고 계약 직원의 계정을 종료할 수 있습니다. 이름, 성 및 부서 정보를 수정하고 승인을 위해 정보를 다시 전송할 수도 있습니다. 마지막으로 Contractor History(계약 직원 기록) 페이지에서는 요청에 대해 수행된 작업 및 각 작업이 이루어진 날짜와 시간 등 작업에 대한 기록을 볼 수 있습니다(그림 5 참조).
그림 5 Contractor History(계약 직원 기록) 페이지
그림 5 Contractor History(계약 직원 기록) 페이지
MIISWorkflow 응용 프로그램에서는 요청자가 Contractor Status(계약 직원 상태) 페이지에서 계약 직원의 계정을 종료할 수 있으므로 계정을 원활하게 종료할 수 있습니다. 요청자는 Terminate(종료) 링크를 클릭하여 연결된 디렉터리에서 계약 직원 계정을 즉시 비활성화하거나 삭제할 수 있습니다. 워크플로 응용 프로그램에서 계약 직원 계정을 종료하는 이 기능 덕분에 시스템 관리자는 각 디렉터리에서 계약 직원 계정을 찾아 수동으로 삭제할 필요가 없습니다. MIISWorkflow 응용 프로그램은 즉시 ILM을 트리거하여 연결된 디렉터리에서 해당 계정을 준비 취소하므로 계정 삭제가 곧바로 이루어집니다.

MIISWorkflow 구성
MIISWorkflow 응용 프로그램 구성 작업에는 서비스 계정 설정, 응용 프로그램 데이터베이스 설정, 워크플로 응용 프로그램과 작동하도록 ILM 구성, IIS 구성, 정책 저장소 구성 등의 작업이 포함됩니다. 이 응용 프로그램에는 이러한 프로세스를 간소화하는 미리 작성된 스크립트와 구성 파일이 포함되어 있습니다.
또한 MIISWorkflow 응용 프로그램에는 T-SQL 쿼리 파일도 포함되어 있으므로 쉽게 MIISWorkflow 데이터베이스를 만들 수 있습니다. 쿼리 분석기에서 쿼리 파일을 로드한 다음 쿼리를 실행하면 데이터베이스가 자동으로 만들어집니다.
IIS 구성 작업에는 새 IIS 응용 프로그램 풀과 가상 디렉터리를 만들고 인증 및 액세스 제어를 설정하여 ASP.NET 페이지를 호스팅하는 작업이 포함됩니다. MIISWorkflow 응용 프로그램에는 권한 부여 정책 저장소를 구성하는 데 사용할 수 있는 미리 정의된 역할이 포함된 XML 파일도 함께 제공됩니다. 사용자와 그룹에 기존 역할을 할당하거나 AzMan MMC를 사용하여 새 역할을 만들 수 있습니다.
마지막 단계는 MIISWorkflow 데이터베이스에서 ILM으로 데이터를 가져올 수 있도록 ILM에서 관리 에이전트를 구성하는 것입니다. 이 작업은 XML 파일의 관리 에이전트 구성을 가져오고 SQL Server 관리 에이전트의 미리 작성된 확장 파일을 복사하여 수행할 수 있습니다. XML 파일과 관리 에이전트 확장 파일 모두 응용 프로그램에 포함되어 있습니다. 각 단계를 구성하는 방법에 대한 단계별 지침이 있는 추가 정보 파일도 제공됩니다.

MIISWorkflow 확장
MIISWorkflow 응용 프로그램은 MIIS와의 간단한 워크플로 통합을 개발하기 위한 토대만 제공하므로 몇몇 부분을 사용자 지정하여 응용 프로그램을 확장해야 할 수도 있습니다. 웹 페이지 변경 등의 간단한 수정 작업 외에도 여러 가지 방법으로 이 응용 프로그램을 확장할 수 있습니다.
보류 중인 요청이 있는 경우에 승인자에게 이에 대한 전자 메일 메시지를 보내는 알림 기능을 추가할 수 있습니다. 알림 기능은 요청에 대해 아무런 작업이 수행되지 않은 경우 지정된 날짜 내에 승인자에게 미리 알림 메시지를 보내는 데도 사용할 수 있습니다. 기본 페이지에서 제공하는 것보다 더 많은 사용자 정보가 필요한 경우에는 Contractor Request(계약 직원 요청) 페이지와 Contractor Update(계약 직원 업데이트) 페이지에 필드를 추가할 수도 있습니다. 사용자가 자신이 전송한 요청뿐만 아니라 모든 요청에 대한 기록을 볼 수 있도록 감사자 역할 등의 다른 역할을 응용 프로그램에 추가할 수도 있습니다.
다단계 워크플로 및 그래픽 디자이너를 사용한 워크플로 설계와 같은 복잡한 워크플로 기능은 이 응용 프로그램에서 다루지 않습니다. 그러나 Windows Workflow Foundation을 사용하면 복잡한 워크플로 기능이 있는 보다 강력한 응용 프로그램을 개발할 수 있습니다.
MIIS Resource Tool Kit는 go.microsoft.com/fwlink/?LinkId=85829에서 구할 수 있습니다. 지금 바로 다운로드하여 자신만의 고유한 ID 워크플로 솔루션을 만들어 보십시오.

Aung Oo는 MCS(Microsoft Consulting Services)의 ID 관리 부문 전문가로, Microsoft Identity Management가 처음 릴리스된 이후 기업 및 정부 고객을 위한 엔터프라이즈 디렉터리 및 ID 관리 솔루션의 설계, 개발 및 배포 작업을 담당해 왔습니다.


 Windows Administration: Windows PowerShell로 그룹 정책 관리 단순화
Windows Administration Thorbjörn Sjövold

Windows PowerShell로 그룹 정책 관리 단순화
한 눈에 보기:
  • Windows PowerShell이란?
  • 기존의 GPO 관리 방법
  • Windows PowerShell로 스크립트 마이그레이션

Microsoft 그룹 정책 기술은 처음에는 쉽게 받아들여지지 않았습니다. 이해하기가 다소 어려웠고 이를 사용하려면 한때 표준이었던 계정/리소스 도메인과 비슷한 점이 전혀 없어 보였던 생소하고 새로운 서비스인 Active Directory에 적응해야 했습니다. 하지만 이런 그룹 정책이 지금은
Windows® 인프라를 사용하는 거의 모든 조직의 핵심 관리 방법이 되었습니다. Microsoft의 최신 관리 기술인 Windows PowerShell™의 경우도 동일한 과정을 거칠 것으로 생각합니다. 사실 그룹 정책 관리자의 경우 Windows PowerShell을 이용하면 자신이 맡은 업무를 훨씬 쉽게 수행할 수 있습니다.
이 기사에서는 일반적인 COM 기반 스크립팅 언어인 VBScript와 같은 Windows Scripting Host 언어용으로 작성된 Microsoft® GPMC(그룹 정책 관리 콘솔) API를 Windows PowerShell에서 직접 사용하여 자신의 환경에서 그룹 정책을 관리하는 방식을 단순화하는 방법을 소개합니다.

그룹 정책 작업 스크립팅
몇 년 전 Microsoft에서 GPMC를 발표했을 때 그룹 정책 관리자는 갑자기 편리한 기능 여러 가지를 얻게 되었습니다. 그룹 정책 중심 MMC 스냅인은 특히 Active Directory® 사용자 및 컴퓨터와 비교했을 때 그룹 정책 관리를 위한 큰 발전으로 인식되었습니다. 게다가 관리자가 VBScript와 같은 COM 기반 언어를 사용하여 GPO(그룹 정책 개체)의 백업과 복원, 도메인 간의 GPO 마이그레이션, GPO와 링크에 대한 보안 설정 구성 및 보고 등과 같은 그룹 정책 관리 작업을 수행할 수 있도록 해주는 새로운 API가 선보였습니다.
하지만 GPMC는 그룹 정책 개체 안에서 실제로 구성된 설정을 편집하는 기능은 제공하지 않았습니다. 즉, GPO 컨테이너에 대해 GPO 버전 읽기, 수정 날짜 읽기, 새 GPO 만들기, 다른 도메인으로부터 GPO 복원/가져오기 등의 작업을 수행하는 것은 가능했지만, 새로 리디렉션된 폴더 추가나 새 소프트웨어 설치 등의 GPO 내용을 프로그래밍 방식으로 추가하거나 변경하는 작업은 수행할 수 없었습니다. 대신 그룹 정책 개체 편집기를 사용하여 GPO를 만들고 모든 설정을 수동으로 구성한 다음 이를 백업하고 테스트 환경으로 가져와야 했습니다. 모든 사항을 확인하고 이러한 사항이 제대로 작동하면 라이브 환경으로 가져왔습니다. 이렇게 기능은 부족했지만 GPMC API로 직접 작업하는 있는 대신 스크립트를 사용할 수 있기 때문에 일상적인 그룹 정책 관리 작업에 소요되는 시간, 노력 및 이와 관련하여 발생하는 오류는 크게 감소했습니다.

더 나은 수준
그렇다면 Windows PowerShell은 VBScript 같은 스크립팅 언어와 어떻게 다를까요? 우선 Windows PowerShell은 셸입니다. 최소한 이 글의 목적에서 보자면 셸은 명령줄 인터프리터로 생각할 수 있습니다. VBScript는 명령줄에서 실행할 수 있지만 VBScript 파일을 줄 단위로 실행할 수는 없습니다. 이와 반대로 Windows PowerShell 스크립트는 일련의 개별 명령으로 만들 수 있습니다. 또한 Windows PowerShell에는 VBScript의 서브루틴과 매우 비슷한 역할을 하며 Windows PowerShell 명령 프롬프트에서 실시간으로 만들 수 있는 함수들이 있습니다.
게다가 VBScript는 기존의 COM 기술에 의존하는 반면 Windows PowerShell은 Microsoft .NET Framework를 기반으로 합니다. 즉, 현재 생성되는 방대한 양의 .NET 코드를 Windows PowerShell 내에서 직접 사용할 수 있습니다.
따라서 Windows PowerShell을 사용하면 완전한 스크립팅이 가능할 뿐만 아니라 대화형 모드도 활용할 수 있습니다. 여기서 소개하는 예는 모두 명령줄 입력이기 때문에 직접 입력해도 되지만 Windows PowerShell 스크립트 파일에 넣어서 실행해도 동일하게 정상 작동합니다.

기존 스크립트를 Windows PowerShell로 다시 만들기
새 기술을 사용하려고 할 때 기존의 모든 작업을 버려야 하는 상황을 원하지는 않을 것입니다. GPMC API에서 COM 개체에 액세스하거나 기본적으로 이전 VBScript를 다시 사용하는 방법에는 세 가지가 있습니다. 다음 세 가지 옵션 중 하나를 선택할 수 있습니다.
  • C# 또는 Managed C++ 등의 프로그래밍 언어를 사용하여 Windows PowerShell cmdlet을 만듭니다.
  • Windows PowerShell을 사용하여 MSScript.ocx의 ScriptControl에 액세스하여 이전 스크립트를 래핑합니다.
  • 재사용 가능한 Windows PowerShell 함수에서 COM 호출을 래핑하거나 COM 개체를 직접 호출합니다.
여기서는 주로 세 번째 옵션에 대해 설명하겠지만 우선 세 옵션 모두를 간단하게 살펴보겠습니다.

Windows PowerShell Cmdlet 만들기
Microsoft는 Windows PowerShell에 파일 복사, 출력 서식 지정, 날짜 및 시간 검색 등의 작업을 할 수 있도록 여러 cmdlet을 추가했습니다. 하지만 필요한 경우 cmdlet을 직접 만들 수도 있습니다. cmdlet를 만드는 과정은 msdn2.microsoft.com/ms714598.aspx에서 자세히 설명합니다. 이 단계를 간단히 설명하자면 다음과 같습니다.
  • C#과 같은 .NET 프로그래밍 언어에서 클래스 라이브러리 DLL을 만듭니다.
  • 새 클래스를 만들고 기본 클래스 cmdlet에서 상속합니다.
  • 이름, 용도, 입력 매개 변수 등을 결정하는 특성을 설정하고 코드를 추가합니다.
Windows PowerShell은 .NET Framework를 기반으로 하기 때문에 매개 변수로 반환되거나 전달되는 문자열, 개체 등과 같은 모든 형식은 코드와 Windows PowerShell에서 정확하게 동일합니다. 따라서 별도의 형식 변환이 필요 없습니다.
이 방법의 진정한 장점은 마음대로 활용 가능한 완전한 프로그래밍 언어가 있다는 점입니다.

MSScript.ocx의 ScriptControl 개체를 사용하여 이전 스크립트 래핑
VBScript 파일을 실행하려면 당연히 VBScript 엔진이 필요합니다. 하지만 이 엔진은 COM 개체이며 Windows PowerShell에서 COM 개체를 사용할 수 있기 때문에 VBScript 엔진을 호출하기만 하면 됩니다. 다음과 같은 코드로 이러한 작업을 수행할 수 있습니다.
$scriptControl = New-Object -ComObject ScriptControl
$scriptControl.Language = ‘VBScript’
$scriptControl.AddCode(
    ‘Function ShowMessage(messageToDisplay)
    MsgBox messageToDisplay
    End Function’)
$scriptControl.ExecuteStatement(‘ShowMessage
    "Hello World"’)
이 코드를 Windows PowerShell CLI(명령줄 인터페이스)에 입력하면 VBScript 함수 ShowMessage가 호출되어 매개 변수와 함께 실행됩니다. 그 결과 Hello World라는 텍스트가 있는 메시지 상자가 표시됩니다.
이것만 보고 "좋았어. Windows PowerShell에서 COM을 사용하는 방법을 알았으니까 이제 이 기사는 그만 읽고 사용하고 있는 이전의 GPMC 스크립트 컬렉션을 ScriptControl 개체에 채워야겠다."고 생각하는 분들도 있을 것입니다. 하지만 그렇게 간단하지만은 않습니다. 이 기술은 금방 매우 복잡해지고 스크립트가 커질수록 디버그도 매우 까다로워집니다.

COM 개체 래핑
따라서 최선의 옵션은 세 번째인 재사용 가능한 Windows PowerShell 함수에서 COM 호출을 래핑하여 GPMC API에서 COM 개체를 사용할 수 있도록 만드는 방법입니다. 아래의 코드 줄을 보면 Windows PowerShell에서 직접 .NET 개체를 만드는 방법을 알 수 있습니다. 여기서는 파일 크기를 가져오는 데 사용할 수 있는 FileInfo 개체를 예로 들었습니다.
$netObject = New-Object System.IO.FileInfo(
"C:\boot.ini") # Create an instance of FileInfo
               # representing c:\boot.ini
# 기호는 Windows PowerShell에서 인라인 주석으로 사용됩니다. 새롭게 인스턴스화된 이 FileInfo 개체를 사용하면 다음 코드를 간단히 입력하여 boot.ini의 크기를 쉽게 가져올 수 있습니다.
$netObject.Length # Display the size in bytes of the
                  # file in the command line interface
여기서 잠깐 COM 개체와 VBScript 변환에 대해 설명하도록 하겠습니다. 다음 명령을 살펴보십시오.
$comFileSystemObject = New-Object –ComObject Scripting.FileSystemObject
앞에서 .NET Framework에서 네이티브 개체를 만드는 데 사용한 구문과 이 구문은 기본적으로 동일하나 다음 두 가지 차이가 있습니다. 우선 –ComObject 스위치를 추가하여 Windows PowerShell이 .NET이 아닌 COM을 지향하도록 했습니다. 두 번째로 .NET 생성자 대신 COM ProgID(이 경우 Scripting.FileSystemObject)를 사용합니다. ProgID는 지금까지 사용하던 것과 같은 이름입니다. VBScript에서는 다음에 해당합니다.
Set comFileSystemObject = CreateObject(
    "Scripting.FileSystemObject")
VBScript를 사용하여 파일 크기를 가져오려면 위의 코드 줄과 다음 코드를 파일에 추가합니다.
Set comFileObject = comFileSystemObject.GetFile(
    "C:\Boot.ini")
WScript.Echo comFileObject.Size
그런 다음 Cscript.exe 등을 사용하여 실행합니다. Windows PowerShell에서는 다음과 같이 합니다. 원하는 경우 Windows PowerShell 명령줄에서 직접 수행합니다.
$comFileObject = $comFileSystemObject.GetFile(
    "C:\boot.ini")
$comFileObject.Size
물론 파일 크기를 읽는 VBScript를 변환하려면 드라이브의 개체를 관리하는 Windows PowerShell cmdlet을 사용해도 되지만 Windows PowerShell에서 COM에 액세스하는 것이 얼마나 쉬운지 보여 주기 위해 이 방식을 사용했습니다. Windows PowerShell에게 COM 개체를 생성하라고 지시하지만 여기서 실제로 생성되는 개체인 $comFileSystemObject는 COM 개체를 래핑하고 인터페이스를 노출하는 .NET 개체입니다. 하지만 이 기사의 관점에서 보면 이는 문제가 되지 않습니다.

Windows PowerShell 실제 적용
지금까지 Windows PowerShell에서 COM에 액세스하는 방법을 살펴보았으므로 이제 그룹 정책에 대해 설명하겠습니다. 이 예제는 Windows PowerShell에서 GPMC API를 사용하는 방법의 개념을 보여 주기 위한 작은 코드 조각입니다. 이 기사와 관련된 코드 다운로드(technetmagazine.com/code07.aspx)에서 그룹 정책을 관리하는 전체 Window PowerShell 함수 집합을 다운로드할 수 있습니다. 그림 1은 이 다운로드에 포함된 함수 목록입니다.
Figure 1 다운로드에 포함된 사용자 지정 함수 (Close Figure 1)

함수 이름 | ¼³¸í
BackupAllGpos | 도메인의 모든 GPO를 백업합니다.
BackupGpo | 단일 GPO를 백업합니다.
RestoreAllGpos | 백업에 있는 모든 GPO를 도메인으로 복원합니다.
RestoreGpo | 백업에서 단일 GPO를 복원합니다.
GetAllBackedUpGpos | 지정된 경로에서 최신 버전의 GPO 백업을 가져옵니다.
CopyGpo | 한 GPO의 설정을 다른 GPO로 복사합니다.
CreateGpo | 빈 GPO를 새로 만듭니다.
DeleteGpo | GPO를 삭제합니다.
FindDisabledGpos | 사용자 및 컴퓨터 부분 모두가 비활성화된 모든 GPO를 반환합니다.
FindUnlinkedGpos | 링크가 없는 모든 GPO를 반환합니다.
CreateReportForGpo | 도메인에 있는 단일 GPO에 대한 XML 보고서를 생성합니다.
CreateReportForAllGpos | 도메인에 있는 각 GPO별로 별도의 XML 보고서를 생성합니다.
GetGpoByNameOrID | 표시 이름이나 GPO ID로 GPO를 찾습니다.
GetBackupByNameOrId | 표시 이름이나 GPO ID로 GPO 백업을 찾습니다.
GetAllGposInDomain | 도메인에 있는 모든 GPO를 반환합니다.
이 부분을 읽으면서 원하는 경우 Windows PowerShell 명령줄을 시작하고 명령을 입력해 보십시오. 다만 일부 명령은 이전 명령에 종속된다는 점을 유의하십시오. 즉, 처음에 만든 개체 일부를 나중에 사용하므로 동일한 Windows PowerShell 세션을 유지해야 합니다. 세션을 닫으면 모든 명령을 처음부터 다시 입력해야 합니다.
이제 Windows PowerShell을 사용하여 새 GPO를 만들어 보겠습니다. Microsoft의 그룹 정책 팀은 GPMC에서 완전하게 작동하는 여러 VBScript 샘플을 제공하므로 이를 이용하여 작업을 간단하게 수행할 수 있습니다. 이 샘플은 %ProgramFiles%\GPMC\Scripts 디렉터리에 있으며 여기에는 GPMC API 문서가 포함된 gpmc.chm이라는 파일도 있습니다. 이제 CreateGPO.wsf 스크립트를 분석해 보겠습니다.
윗부분에는 다음 줄이 있습니다.
Dim GPM
Set GPM = CreateObject("GPMgmt.GPM")
이 줄은 대부분의 GPMC 기능에 액세스할 수 있도록 해주는 GPMgmt.GPM 클래스를 인스턴스화하기 때문에 그룹 정책 관리 세션이나 스크립트의 시작점입니다. 이 작업을 Windows PowerShell에서 수행하는 경우 코드는 다음과 같습니다.
$gpm = New-Object -ComObject GPMgmt.GPM
그룹 정책 관리의 시작점을 만들었으므로 다음 단계에서는 이것으로 무엇을 할 수 있는지 알아 봅니다. 대개는 이런 정보를 얻기 위해 문서를 찾아보겠지만 Windows PowerShell에는 매우 멋진 기능이 있습니다. 다음 줄을 입력하면 그림 2와 같은 출력이 나타납니다.
그림 2 Get-Member 출력
그림 2 Get-Member 출력
$gpm | gm
여기서 볼 수 있듯이 매우 편리한 기능입니다. 즉, Get-Member(또는 gm) cmdlet을 이용하면 개체가 지원하는 속성과 메서드를 명령줄에서 직접 확인할 수 있습니다. 물론 문서를 읽는 것과 같지는 않지만 정확한 매개 변수 수, 정확한 이름 등을 기억하지 못하는 경우 이미 잘 알고 있는 개체를 쉽게 사용할 수 있습니다. 한 가지 중요한 사항은 GPMC 문서 노드 목록을 보는 경우 이러한 개체는 GPM 개체와 비슷하며 다른 모든 클래스 앞에는 문자 I가 접두사로 붙어 있다는 점입니다. 이는 COM의 내부 작동 방식 때문이며 여기서는 별로 문제가 되지 않습니다. 이는 네이티브 COM 코드를 작성하는 C++ 프로그래머를 위한 것이며 인터페이스와 해당 인터페이스를 구현하는 클래스 간의 차이를 표시합니다. 또한 GPMC API를 사용할 때는 GPMgmt.GPM이라는 개체만 이 방법으로 만들면 됩니다. 다른 개체는 모두 이 GPM 개체로 시작되는 메서드를 사용하여 생성됩니다.
계속해서 GPO를 만들어 보겠습니다.
그림 3을 보면 GPO를 만드는 것이 얼마나 간단한지 알 수 있습니다. 여기서는 GPO를 만들 수 없는 경우에 수행해야 할 작업 등과 같은 오류 처리를 포함하여 몇 가지 코드를 생략했으며 도메인 이름을 하드코드했지만 개념을 파악하는 데는 아무런 문제가 없습니다.
Figure 3 GPO 만들기 (Close Figure 3)
$gpmConstants = $gpm.GetConstants()
# This is the GPMC way to retrieve all
# constants
$gpmDomain =$gpm.GetDomain("Mydomain.local", "", $gpmConstants.UseAnyDC)
# Connects to the domain where the GPO should
# be created, replace Mydomain.local with the
# name of the domain to connect to.
$gpmNewGpo = $gpmDomain.CreateGPO()
# Create the GPO
$gpmNewGpo.DisplayName = "My New Windows PowerShell GPO"
# Set the name of the GPO
이제 GPO를 만드는 방법을 알았으므로 기존 GPO를 열겠습니다. 아직 도메인 $gpmDomain에 대한 참조가 있으므로 다음을 입력합니다.
$gpmExistingGpo = $gpmDomain.GetGPO(
  "{31B2F340-016D-11D2-945F-00C04FB984F9}")
# Open an existing GPO based on its GUID,
# in this case the Default Domain Policy.
$gpmExistingGpo.DisplayName
# Show the display name of the GPO, it
# should say Default Domain Policy
$gpmExistingGpo.GenerateReportToFile($gpmConstants.ReportHTML, ".\DefaultDomainPolicyReport.html"
이렇게 하면 기본 도메인 정책의 설정에 대한 전체 HTML 보고서를 얻을 수 있지만 GPO의 설정이 변경된 시점을 알 수 있도록 GPO의 마지막 수정 시점을 알려 주는 ModificationTime 등 원하는 속성과 메서드 또한 모두 사용할 수 있습니다.
이 기능은 매우 유용합니다. 컴퓨터가 이상하다고 불평하는 사용자들의 전화가 빗발치는 상황을 경험해봤을 것입니다. 이 상황의 원인이 GPO 설정의 변경, 추가 또는 삭제 때문이라는 의심은 가지만 어떤 GPO를 조사해야 할지 알아낼 단서가 없는 경우가 있습니다. 바로 이럴 때 Windows PowerShell을 사용하면 큰 도움이 됩니다. 그림 4에 나와 있는 스크립트를 Windows PowerShell 명령줄에 입력하면 지난 24시간 내에 변경된 모든 GPO를 알아낼 수 있습니다.
Figure 4 수정된 GPO 검색 (Close Figure 4)
$gpmSearchCriteria = $gpm.CreateSearchCriteria()
# We want all GPOs so no search criteria will be specified
$gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# Find all GPOs in the domain
foreach ($gpmGpo in $gpmAllGpos)
{
if ($gpmGpo.ModificationTime -ge (get-date).AddDays(-1)) {$gpmGpo.DisplayName}
# Check if the GPO has been modified less than 24 hours from now
}
여기서 크거나 같음을 의미하는 –ge 연산자에 주의하십시오. 다른 스크립팅 또는 프로그래밍 언어에서 < 및 > 연산자를 사용해 온 사용자에게는 생소해 보일 것입니다. 하지만 이러한 연산자는 출력을 파일로 리디렉션하는 경우와 같은 리디렉션에 사용되므로 Windows PowerShell에서 비교 연산자로 사용할 수 없습니다.

¿ä¾à
그림 5에 나와 있는 코드는 한 GPO의 설정을 다른 GPO로 복사하는 전체 스크립트입니다. 이제 이 새로운 기술을 그룹 정책에 활용하고 COM 개체를 사용하는 모든 COM 개체나 VBScript 코드를 다시 사용하는 방법을 이해했을 것입니다.
Figure 5 한 GPO의 설정을 다른 GPO로 복사 (Close Figure 5)
###########################################################################
# Function  : CopyGpo
# Description: Copies the settings in a GPO to another GPO
# Parameters : $sourceGpo     - The GPO name or GPO ID of the GPO to copy
#           : $sourceDomain   - The dns name, such as microsoft.com, of the domain where the original GPO is located
#           : $targetGpo      - The GPO name of the GPO to add
#           : $targetDomain   - The dns name, such as microsoft.com, of the domain where the copy should be put
#           : $migrationTable - The path to an optional Migration table to use when copying the GPO
# Returns   : N/A
# Dependencies: Uses GetGpoByNameOrID, found in article download
###########################################################################
function CopyGpo(
 [string] $sourceGpo=$(throw ‘$sourceGpo is required’),
 [string] $sourceDomain=$(throw ‘$sourceDomain is required’),
 [string] $targetGpo=$(throw ‘$targetGpo is required’),
 [string] $targetDomain=$(throw ‘$targetDomain is required’),
 [string] $migrationTable=$(""),
 [switch] $copyAcl)
{

 $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
 $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
 $gpmSourceDomain = $gpm.GetDomain($sourceDomain, "", $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC
 $gpmSourceGpo = GetGpoByNameOrID $sourceGpo $gpmSourceDomain
 # Handle situations where no or multiple GPOs was found
 switch ($gpmSourceGpo.Count)
 {
   {$_ -eq 0} {throw ‘No GPO named $gpoName found’; return}
   {$_ -gt 1} {throw ‘More than one GPO named $gpoName found’; return}
 }
 if ($migrationTable)
 {
   $gpmMigrationTable = $gpm.GetMigrationTable($migrationTable)
 }

 $gpmTargetDomain = $gpm.GetDomain($targetDomain, "", $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC

 $copyFlags = 0
 if ($copyAcl)
 {
   $copyFlags = Constants.ProcessSecurity
 }
 $gpmResult = $gpmSourceGpo.CopyTo($copyFlags, $gpmTargetDomain, $targetGpo)
 [void] $gpmResult.OverallStatus

}
기존에 그룹 정책이 그랬던 것처럼 Windows PowerShell은 Windows 관리 환경에서 자연스러운 한 부분으로 자리잡을 것입니다. 하지만 수백만 줄의 VBScript를 마이그레이션하거나 유지해야 할 수 있으며 이 경우 다행히 이 자습서가 도움이 될 것입니다.
다운로드에 포함된 Windows PowerShell 함수를 포함하여 이전에는 VBScript를 사용했던 여러 분야와 그룹 정책 관리를 개선하는 데 사용할 수 있는 다양한 소스가 있습니다. 또한 TechNet 웹 사이트의 VBScript - Windows PowerShell 변환 가이드에서 VBScript에서 해당 기능을 알고 있는 경우 많이 수행하는 작업을 Windows PowerShell로 수행하는 방법에 대한 힌트를 볼 수 있습니다. 이 가이드는 microsoft.com/technet/scriptcenter/topics/winpsh/convert에서 확인할 수 있습니다.
또한 GPMC API는 완전히 문서화되어 있으며 microsoft.com/grouppolicy의 그룹 정책 사이트에서 이러한 정보를 다운로드할 수 있습니다.
마지막으로 아직도 Windows PowerShell을 설치하지 않았다면 지금 바로 설치하십시오. Windows PowerShell은 microsoft.com/powershell에서 다운로드할 수 있습니다. Windows PowerShell의 재미에 빠져 보십시오.

Thorbjörn Sjövold는 그룹 정책 기반 시스템 관리 및 보안 확장 제품 공급 업체인 Special Operations Software(www.specopssoft.com)의 설립자 겸 CTO입니다. 문의 사항이 있으면 thorbjorn.sjovold@specopssoft.com으로 연락하십시오.


 Windows Administration: 터미널 서비스 배포 가이드
Windows Administration James D. Silliman

터미널 서비스 배포 가이드
한 눈에 보기:
  • 몇 가지 손쉬운 단계로 터미널 서비스 배포
  • TS 환경에서 Office 최적화
  • TS를 사용한 효율적인 사용자 관리

1998년 Microsoft는 코드명 "Hydra"인 Windows NT 4.0 Terminal Server Edition을 발표했습니다. 또한 Citrix Systems 기술에 대한 라이선스를 확보하여 최초의 씬-클라이언트/서버 구현 제품을
선보였습니다. 시스템 관리자에게 "Hydra" 배포는 어려운 일이었습니다. 하지만 몇 년 사이 터미널 서비스는 크게 바뀌었습니다. 커널에 완전히 통합되었고 별도의 CD나 인터넷 다운로드 없이 기본 제공 설치 마법사로 쉽게 설치할 수 있게 되었습니다. 설치가 비교적 쉽다는 점을 고려하면 조직에 터미널 서비스를 배포함으로써 얻을 수 있는 이점은 많습니다. 바로 실감할 수 있는 이점은 모든 응용 프로그램을 중앙 서버에서 실행하기 때문에 클라이언트 아키텍처와 하드웨어는 문제가 되지 않는다는 것입니다. 최종 사용자는 RDP(원격 데스크톱 프로토콜) 클라이언트만 있으면 중앙 서버에 연결할 수 있습니다. 이 RDP 클라이언트는 대부분의 최신 아키텍처에서 사용할 수 있습니다.
이 기사에서는 기존 Windows Server® 2003 설치에서 터미널 서비스를 설정하는 방법, 터미널 서비스 그룹 정책을 적용하는 방법, 사용자 지정 설치 마법사를 사용하여 Microsoft® Outlook® 프로필 설정을 자동화하는 방법을 소개합니다. 이 기사를 읽고 나면 사용자에게 응용 프로그램을 서비스하는 터미널 서버를 완벽하게 배포할 수 있을 것입니다.

시작
터미널 서비스를 설치하는 데 필요한 첫 번째 단계는 Windows Server 2003 관리 도구에 있는 기본 제공 서버 구성 마법사를 여는 것입니다. 그런 다음 터미널 서버를 선택하고 마법사가 완료될 때까지 다음을 클릭합니다. 그러면 설치 프로그램에서 변경 내용을 초기화하기 위해 시스템을 자동으로 다시 부팅해야 한다는 경고 메시지를 표시합니다. 다시 부팅하고 나면 서버는 터미널 서버 모드로 시작됩니다.
시작하기 전에 터미널 서비스 CAL(클라이언트 액세스 라이선스)을 미리 준비해야 합니다. 그렇지 않으면 배포에 성공하더라도 아무도 연결할 수 없습니다. 이제 터미널 서비스가 실행 중인 시스템을 Active Directory® 도메인에 참가시키고 도메인 관리자 권한이 있는 계정으로 로그인합니다. 도메인에 속해있지 않으면 그룹 정책을 적용할 수 없으므로 작업을 계속하기가 어렵습니다. 이 기사에서는 터미널 서비스를 설치할 서버의 이름을 TS01이라고 합니다.
다음 단계로 관리 도구에서 Active Directory 사용자 및 컴퓨터를 시작하여 터미널 서버를 배치할 새 OU(조직 구성 단위)를 만듭니다. 이해하기 쉽도록 OU에는 Terminal Servers라는 이름을 지정하겠습니다. 터미널 서버인 TS01을 찾아서 새 Terminal Servers OU로 옮깁니다.
그런 다음 microsoft.com/windowsserver2003/gpmc에서 GPMC(그룹 정책 관리 콘솔)를 다운로드하여 설치합니다. 이 관리 유틸리티에서는 새 그룹 정책을 설정하고, 여기에 사용 권한을 할당한 다음, 연결할 모든 사용자에 대해 적용 가능한 정책 설정을 설정하거나 해제할 수 있도록 정책을 편집할 수 있습니다. GPMC에는 사용자에게 적용되었거나 적용되지 않은 정책을 곧바로 반영하는 기본 제공 모델링 마법사가 있기 때문에 GPMC는 터미널 서비스 배포에 필수적인 도구입니다.
관리 도구에서 GPMC 콘솔을 시작하고 Group Policy Management(그룹 정책 관리) 창의 왼쪽에서 새 Terminal Servers OU를 찾습니다. 그림 1에 나와 있는 대로 OU를 마우스 오른쪽 단추로 클릭하고 Create and Link a GPO Here(여기에 GPO를 만들고 연결)를 선택한 다음 Terminal Server Policy #1과 같이 이해하기 쉬운 이름을 지정합니다.
그림 1 새 GPO 만들기 및 연결
그림 1 새 GPO 만들기 및 연결
GPMC 창 오른쪽의 Security Filtering(보안 필터링) 상자에 Authenticated Users 그룹이 나타나는 것을 볼 수 있습니다. 이 그룹은 모든 GPO(그룹 정책 개체)에 기본적으로 추가됩니다. 그룹을 클릭한 다음 Remove(제거) 단추를 클릭합니다. 사용자가 TS01에 로그온한 경우 GPO를 적용할 터미널 서비스 그룹을 Active Directory 트리에 설정해야 합니다. 여기서는 터미널 서비스 그룹을 BottleWashers라고 하겠습니다. 관리 도구의 Active Directory 사용자 및 컴퓨터를 사용하여 이 그룹을 Active Directory 구조에 추가합니다. 또한 BottleWashers를 TS01 및 설치하는 다른 모든 터미널 서버의 Remote Desktop Users 그룹에도 추가해야 합니다.
이제 Scope(범위) 탭으로 이동합니다. Security Filtering(보안 필터링) 상자에서 Add(추가) 단추를 클릭한 다음 BottleWashers를 그룹으로 추가합니다. BottleWashers에는 Terminal Server Policy #1에 대한 그룹 정책 읽기 및 적용 권한이 자동으로 부여됩니다. 이 두 권한은 기본 그룹 정책 권한이며 개체에 적용할 모든 정책에 필요합니다.
다음으로 Security Filtering(보안 필터링) 상자에 서버인 TS01도 추가합니다. 이 작업에는 추가 단계를 수행해야 합니다. 먼저 Add(추가)를 클릭한 다음 Object Types(개체 유형) 아래의 Computers(컴퓨터) 탭에 확인 표시가 있는지 확인합니다. 확인 표시가 없으면 GPMC가 Active Directory에서 TS01을 찾을 수 없습니다. 위 단계를 수행하면 그림 2와 같이 나타납니다.
그림 2 Security Filtering 아래에 TS01 추가
그림 2 Security Filtering 아래에 TS01 추가
마찬가지로 올바른 정책 권한을 Security Filtering(보안 필터링) 상자에 추가하면 해당 정책 권한이 TS01에 자동으로 적용됩니다. 이 단계에서 GPMC 화면 오른쪽 윗부분에 있는 Delegation(위임) 탭을 클릭한 다음 Domain Admins를 찾습니다. 이 그룹은 모든 새 정책에 기본적으로 나열됩니다. 화면 오른쪽 아래에서 Advanced(고급) 단추를 누릅니다.
이제 그룹 정책 개체의 보안 설정이 표시됩니다. 포커스가 Domain Admins에 있는지 확인한 다음 아래쪽에서 Apply Group Policy(그룹 정책 적용) 설정을 찾습니다. 오른쪽에서 Deny(거부) 옵션을 선택합니다. OK(확인)를 클릭하면 거부 권한을 설정할 때마다 나타나는 표준 경고 메시지가 표시됩니다. 이 단계를 통해 새 TS 정책이 Domain Admins에 적용되지 않도록 하여 바람직하지 않은 상황을 예방할 수 있습니다.
앞에서 Microsoft CAL을 미리 준비해 두라고 권장했습니다. 라이선스 서류 자료를 검토하여 구입한 터미널 서비스 CAL이 무엇인지 확인해야 합니다. 터미널 서버용 CAL에는 사용자 단위와 장치 단위의 두 유형이 있습니다. 라이선스에 대한 자세한 내용은 microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx에서 확인할 수 있습니다.
기본적으로 사용자 단위 라이선스에서는 사용자가 연결에 사용하는 장치(PC)의 수에 관계없이 한 명의 사용자가 하나의 터미널 서버 라이선스만 사용합니다.
도메인에 아직 터미널 서버 라이선스 서버가 없는 경우에는 이 역할을 할 수 있는 구성원 서버를 찾아야 합니다. TS01을 라이선스 서버로 설정할 수는 있지만 나중에 조직에 터미널 서버를 추가하는 경우 인프라에 대한 내결함성을 유지할 수 없으므로 이 방법은 권장하지 않습니다. 원하는 라이선스 서버에서 제어판을 엽니다. 프로그램 추가/제거 | Window 구성 요소 | 터미널 서버 라이센스를 열고 화면에 나타나는 지침에 따라 라이선스 서버를 활성화합니다. 완료되면 시작 | 실행을 클릭하고 다음을 입력합니다.
tscc.msc
그러면 터미널 서버 구성\서버 설정 트리가 열립니다. 여기에서 서버 설정 | 라이센스를 클릭하고 사용자 단위 또는 장치 단위를 선택합니다. 기본값은 장치 단위입니다. 도메인에 이미 터미널 서버 라이선스 서버가 있는 경우에는 Terminal Server Policy #1에 라이선스 서버의 역할을 하는 서버를 나타내는 설정이 있습니다. 이 작업을 완료했으면 다시 시작 | 실행을 선택하고 다음을 입력합니다.
licmgr.exe
이제 사용자가 연결할 수 있도록 CAL을 활성화해야 합니다. 상황에 맞게 전화나 웹을 통해 활성화할 수 있습니다. 활성화하고 나면 터미널 서버에 연결할 수 있지만 아직 적용된 정책이 없기 때문에 중요한 몇 가지부터 설정해 보겠습니다. 기술 자료 문서 "Windows Server 2003 또는 Windows 2000 터미널 서버 세션을 잠그는 방법"에서 몇 가지 Microsoft 권장 설정을 볼 수 있습니다.

정책 활성화
여기서 기억해야 할 점은 각 정책의 역할을 정확히 이해하기 전까지는 정책을 활성화하지 않아야 한다는 점입니다. 그렇지 않으면 원하지 않은 결과가 발생할 수 있습니다. 더 좋은 방법은 몇 개의 필수 정책을 테스트 환경에서 다양하게 테스트해보는 것입니다.
적용할 수 있는 첫 번째 정책은 루프백 정책입니다. 이 정책을 활성화하려면 GPMC를 시작하고 Terminal Server Policy #1을 찾아서 마우스 오른쪽 단추로 클릭한 다음 Edit(편집)를 선택합니다. Computer Configuration(컴퓨터 구성) | Admin Templates(관리 템플릿) | System(시스템) | Group Policy(그룹 정책)로 이동하여 User Group Policy loopback processing mode(사용자 그룹 정책 루프백 처리 모드) 설정을 활성화합니다. 이 정책을 활성화한 다음에는 Mode(모드) 값을 Replace(바꾸기) 또는 Merge(병합)로 설정합니다. 터미널 서비스에서 최상의 결과를 얻으려면 Replace(바꾸기)를 선택합니다.
활성화해야 하는 다른 터미널 서버 설정은 Computer Configuration(컴퓨터 구성)\Administrative Templates(관리 템플릿)\System(시스템)\User Profiles(사용자 프로필)에 있는 'Add the Administrators security group to roaming user profiles'(로밍 사용자 프로필에 관리자 보안 그룹 추가)입니다. 이 설정을 통해 관리자는 사용자 프로필 폴더에 대해 항상 모든 권한을 가질 수 있습니다. 사용자가 처음 로그인한 후 폴더가 이미 생성되어 있는 경우에는 이 설정이 적용되지 않으므로 미리 설정해야 합니다(그림 3 참조).
그림 3 관리자 보안 그룹 추가 값 활성화
그림 3 관리자 보안 그룹 추가 값 활성화
Computer Configuration(컴퓨터 구성)\Administrative Templates(관리 템플릿)\Windows Components(Windows 구성 요소)\Terminal Services(터미널 서비스)에서 전체 정책을 확인할 수 있습니다. 활성화를 고려할 정책은 다음과 같습니다.
  • Restrict Terminal Services users to a single remote session(터미널 서비스 사용자를 하나의 원격 세션으로 제한)
  • Set path for TS Roaming Profiles(TS 로밍 프로필에 경로 설정)
  • TS User Home Directory(TS 사용자 홈 디렉터리)
하지만 터미널 서비스 사용자를 하나의 원격 세션으로 제한하더라도 사용자가 두 번 이상 로그인하는 것을 막을 수 있는 것은 아닙니다. 대신 사용자가 두 번째 터미널 서비스 세션을 시작하려고 시도하면 첫 번째 로그온된 세션으로 돌아가게만 합니다.
로밍 프로필은 적절한 터미널 서버 작업에 필수적인 요소입니다. 기본적으로 사용자가 터미널 서버에 로그온하면 C: 드라이브를 숨긴 경우에도 터미널 서버 C: 드라이브에 로컬 프로필이 생성됩니다. 로밍 프로필은 기본적으로 사용자가 로그오프할 때 로컬 프로필을 네트워크의 로밍 프로필 공유로 동기화합니다. 사용자가 로그오프할 때 이 로컬 프로필을 삭제하도록 그룹 정책을 설정할 수 있습니다.
위에서 언급한 Set path for TS Roaming Profiles(TS 로밍 프로필에 경로 설정) 및 TS User Home Directory(TS 사용자 홈 디렉터리)의 두 터미널 서비스 정책은 로밍 프로필과 관련됩니다. 이 설정은 Active Directory 사용자의 터미널 서비스 프로필 경로 상자에 하드 코드되는 경우가 많습니다. 그룹 정책을 통해 터미널 서비스 경로를 설정하는 방법이 더 쉽고 바람직합니다. Active Directory 사용자 및 컴퓨터의 터미널 서비스 프로필 경로의 경우 새 사용자를 설정하거나 기존 사용자를 복사하면 매번 TS 서버 프로필 경로 정보를 수동으로 추가해야 하는 불편함이 있습니다. 따라서 이 경로를 네트워크 공유로 설정하고 GPO를 통해 구성하는 것이 더 효과적입니다.

폴더 리디렉션
이제 매우 중요한 다른 터미널 서비스 구성 요소인 폴더 리디렉션에 대해 간단하게 살펴보겠습니다. 폴더 리디렉션은 과도하게 긴 로그온과 로그오프를 방지함으로써 TS 환경을 최적화합니다. 리디렉션할 수 있는 폴더는 Application Data, 바탕 화면, 내 문서 및 시작 메뉴입니다. 이 네 개의 폴더는 네트워크 공유에 있어야 하며 특정한 ACL(액세스 제어 목록)이 필요합니다. 이 항목에 대한 자세한 내용은 기술 자료 문서 "Windows 2000과 Windows Server 2003에서 폴더 리디렉션을 사용하여 보안이 강화된 리디렉션 폴더를 동적으로 만드는 방법"을 참조하십시오.
폴더 리디렉션의 장점은 사용자가 로그온하거나 로그오프할 때마다 전체 사용자 프로필을 복사해야 할 필요가 없다는 점입니다. 터미널 서비스가 네트워크에 있는 해당 폴더를 인식하여 해당 폴더에 대한 포인터를 제공하기 때문입니다.
로밍 프로필과 폴더 리디렉션에 대해서는 DFS(분산 파일 시스템)를 검토하여 네트워크 공유에 대한 유지 관리를 단순화하는 방법을 확인하는 것이 좋습니다. 이 기사에서는 DFS에 대해 자세히 다루지 않지만 DFS 리소스 센터에서 자세한 내용을 볼 수 있습니다.
폴더 리디렉션 설정은 User Configuration(사용자 구성)\Windows Settings(Windows 설정)\Folder Redirection(폴더 리디렉션)에서 확인할 수 있습니다(그림 4 참조). 폴더 리디렉션 폴더 값은 매우 간단합니다. 각 폴더 리디렉션 설정에서 사용자에게 독점 권한을 부여한다는 내용의 옵션은 선택하지 않는 것이 좋습니다. 이 옵션을 선택하면 관리자가 폴더에 액세스할 수 없습니다.
그림 4 폴더 리디렉션 설정 위치
그림 4 폴더 리디렉션 설정 위치

Microsoft Office 설치
필수 정책을 설정했으므로 이제 Microsoft Office 2003 또는 2007 Microsoft Office 시스템의 설치를 시작하겠습니다. Microsoft Office는 터미널 서비스에 최적화되어 있으므로 설치 도중 변경할 내용은 그리 많지 않습니다. Office 제품군 중 높은 대역폭을 차지하는 항목은 기본적으로 해제되어 있습니다. 이 단계에서 Office 제품군 내에서 정책을 제어할 수 있도록 그룹 정책 관리 템플릿 파일(ADM 파일)을 다운로드하여 설치해야 합니다.
필요한 ADM 파일은 microsoft.com/office/orkarchive/2003ddl.htm에 있습니다. 이 기사의 목적상 Office 템플릿 파일(ORKSP2AT.exe)과 사용자 지정 설치 마법사의 두 파일만 다운로드하면 됩니다. 하지만 두 번째 파일은 Office 2003을 배포하려는 경우에만 필요합니다. 2007 Office system은 마법사를 사용하지 않습니다. 시작 | 실행을 클릭하고 Setup /a를 입력하기만 하면 자동으로 시작됩니다.
첫 번째 파일 ORKSP2AT.exe의 압축을 풀면 여러 개의 파일이 생깁니다. 이 중에서 office11.adm과 outlk11.adm 파일을 가지고 작업합니다(그림 5 참조).
그림 5 Office 템플릿 파일
그림 5 Office 템플릿 파일
Windows 탐색기를 시작하고 이 두 파일을 %systemroot%\inf로 복사합니다. 다시 GPMC 콘솔을 시작합니다. Group Policy Objects(그룹 정책 개체) 아래에서 Terminal Server Profile #1을 찾아 마우스 오른쪽 단추로 클릭한 다음 Edit(편집)를 선택합니다. 이제 정의된 정책 내에서 Computer Configuration(컴퓨터 구성)\Administrative Templates(관리 템플릿)로 이동합니다. 그림 6에서처럼 Administrative Templates(관리 템플릿)를 마우스 오른쪽 단추로 클릭하고 Add/Remove Templates(템플릿 추가/제거)를 선택합니다.
그림 6 관리 템플릿을 GPO에 추가
그림 6 관리 템플릿을 GPO에 추가
이제 두 파일을 사용할 수 있습니다. 이 두 파일을 한 번에 하나씩 추가합니다. User Configuration(사용자 구성)\Administrative Templates(관리 템플릿)\Microsoft Office 2003 및 User Configuration(사용자 구성)\Administrative Templates(관리 템플릿)\Microsoft Office Outlook 2003에 해당 템플릿 파일이 나타납니다. 이 템플릿 설정을 살펴보고 필요에 따라 설정하거나 해제할 수 있습니다.
여기에서는 많은 설정을 다루지 않지만 일반적으로 많이 제거하는 두 설정은 Office 길잡이 및 Outlook 자동 보관입니다. Exchange 캐시 모드 및 정크 메일 필터링과 같은 일부 설정은 터미널 서비스에서 기본적으로 해제되어 있으므로 이러한 정책을 해제할 필요가 없습니다.
자세한 내용은 "터미널 서비스에서 해제되는 Outlook 기능"을 참조하십시오. Office 길잡이는 그룹 정책에서 User Configuration(사용자 구성)\Administrative Templates(관리 템플릿)\Microsoft Office 2003\Assistant(길잡이)\Options(옵션)를 선택하여 쉽게 해제할 수 있습니다.
터미널 서비스 환경에서는 사용자에게 어떤 작업을 요청하는 메시지를 자주 표시하는 것이 바람직하지 않을 것입니다. 이렇게 귀찮은 메시지 중 하나가 Outlook의 메일 자동 보관 설정과 관련된 메시지입니다. 그룹 정책에서 이 설정을 무시하면 사용자에게 일정한 간격으로 자동 보관을 수행하라는 메시지가 표시됩니다. 이 설정을 해제하면 Outlook 기본 설정 메뉴에 아예 표시되지 않습니다. 물론 자동 보관이 필요한 경우도 있으므로 정책 User Configuration(사용자 구성)\Administrative Templates(관리 템플릿)\Microsoft Office Outlook 2003\Tools(도구) | Options(옵션)\Autoarchive(자동 보관)에서 설정을 조정할 수 있습니다.
성공적인 터미널 서비스 배포를 위해 수행할 다음 단계는 사용자에게 Outlook 설정을 수동으로 구성하라는 메시지가 표시되지 않도록 Outlook PRF 파일을 설정하는 작업입니다. 매우 복잡한 작업처럼 보이지만 그렇지 않습니다. OrkTools를 설치하고 사용자 지정 설치 마법사를 사용하여 Outlook 설치 마법사에게 동작 방식을 지시하는 PRF 파일을 만들면 됩니다. 2007 Office system의 메커니즘에서는 이 프로세스를 수행할 필요가 없지만 원하는 경우에는 여전히 Office에 PRF 파일을 사용할 수 있습니다.
CIW로 Outlook PRF 파일을 설정해 보겠습니다. 실제로 전체 CIW 루틴을 실행하는 것이 아니라 수정된 PRF 파일을 내보내는 데 필요한 부분만 실행합니다. 다음 몇 단계만 수행하면 됩니다.
먼저 앞에서 다운로드한 두 번째 파일인 사용자 지정 설치 마법사를 시작하여 압축을 풉니다. 시작 | 프로그램 | Microsoft Office 2003 Resource Kit에서 마법사를 시작하면 Office 2003 MSI 파일의 위치를 묻는 메시지가 나타납니다. Office 2003 디스크를 넣고 MSI 파일의 이름과 경로를 지정합니다.
이제 다른 CIW 부분은 건너뛰고 PRF 파일만 만들 수 있도록 CIW의 24페이지 중 17페이지로 이동합니다. 17단계에서 새 프로필을 선택하고 Outlook과 같은 이름을 지정한 후 다음을 클릭합니다. Exchange Server를 선택할 수 있는 화면이 나타납니다(그림 7 참조). Exchange Server의 이름을 입력하고 다음을 클릭하여 계속합니다.
그림 7 Exchange Server 연결 구성
그림 7 Exchange Server 연결 구성
작성하고 있는 프로필에 Outlook 주소록을 추가하는 것이 좋습니다. 이렇게 하면 사용자가 새 메시지를 작성할 때 연락처를 선택할 수 있습니다. 이 단계만으로도 많은 수동 작업을 줄일 수 있습니다. 또한 추가 단추를 선택하면 여기에서 다른 사용자 지정 기능도 구성할 수 있습니다. 이제 다음을 클릭하고 PRF 파일로 내보내기만 하면 됩니다.
이제 배치 파일을 만든 다음 이 파일을 TS01이 아닌 도메인 컨트롤러의 Netlogon 공유에 넣어야 합니다. 배치 파일은 필요한 모든 매핑을 실행하고 배포용으로 PRF 파일을 설치합니다. 편의를 위해 WMI 스크립트를 작성했습니다. 하지만 이 스크립트는 참고용으로만 사용하십시오. 각 상황에 맞는 정보를 추가해야 합니다. 원하는 경우 KiXTart와 같은 다른 스크립트 프로세서를 사용할 수 있습니다.
작성한 배치 파일(logon.bat)에는 다음 줄이 있어야 합니다.
REM Logon.bat
@echo off
wscript %0\..\clean.vbs
wscript %0\..\outlook.vbs
Clean.vbs 파일은 Outlook이 PRF 파일을 처리하도록 First-Run 레지스트리 키를 제거합니다.
' Clean.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
    sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\
    Outlook\Setup"
sValueName = "First-Run"
oRegistry.DeleteValue HKEY_CURRENT_USER, sKeyPath, _
    sValueName
Outlook.vbs는 각 터미널 서버 사용자에 대한 레지스트리에 적절한 Outlook 설정 키를 추가합니다. SValue= 설정에는 각자 상황에 맞는 경로를 지정해야 합니다. 또한 실제 사용자 지정된 PRF 파일을 실제 네트워크 디렉터리에 추가해야 합니다.
sValue = \\Serv01\PRF\Outlook.prf
이 경로를 바꾸고 Outlook.prf 파일을 해당 경로에 넣습니다.
' Outlook.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
  sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\Outlook\
    Setup"
oRegistry.CreateKey HKEY_CURRENT_USER, sKeyPath
sValue = "\\Serv01\PRF\Outlook.prf"
sValueName = "ImportPRF"
oRegistry.SetStringValue HKEY_CURRENT_USER, _
    sKeyPath, sValueName, sValue
배포의 다음 단계는 Office 2003 또는 2007 Microsoft Office 시스템을 TS01에 설치하는 것입니다. 앞서 언급했듯이 Microsoft Office는 터미널 서비스 환경에 최적화되어 있습니다. 따라서 사용자 지정 변환을 만들 필요가 없습니다. 사전 선택된 것 이외의 Office 기능도 해제할 수 있지만 필수 사항은 아닙니다. 이와 반대로 기능을 설정할 수도 있지만 이 경우 대역폭에 부정적 영향을 줄 수 있습니다. 실제 환경에 배포하기 전에 테스트 환경에서 설정한 모든 기능을 테스트하는 것을 잊지 마십시오.
Microsoft Office를 설치하기 전에 TS01을 적절한 사용자 모드로 전환하는 것이 좋습니다. 이 경우 설치 및 실행 중에서 선택할 수 있습니다. 소프트웨어를 설치할 때는 설치 모드에 있어야 합니다. TS01을 설치 모드로 전환하려면 명령 프롬프트에 다음을 입력하십시오.
C:>change user /install
설치가 끝나면 다음을 입력하여 TS01을 다시 실행 모드로 전환합니다.
C:>change user /execute
TS01에서 Setup.exe 또는 Install.exe 파일을 실행하면 자동으로 설치 모드가 실행됩니다. Microsoft 제품에는 모두 이러한 실행 파일이 있습니다. 하지만 일부 응용 프로그램에서는 이러한 파일을 사용하지 않으므로 안전을 위해 Change 명령을 사용하십시오. 현재 모드를 모르는 경우에는 어떻게 해야 하나요? 다음 명령만 실행하면 현재 모드를 알 수 있습니다.
C:>change user /query
지금까지 잘 따라 하셨으면 모든 것이 잘 작동할 것입니다. 이제 Windows 클라이언트 워크스테이션으로 가서 시작 | 실행을 클릭하고 다음 명령을 입력합니다.
mstsc
Windows 2000을 사용하는 경우 Microsoft 터미널 서비스 클라이언트(Mstsc) 유틸리티를 다운로드할 수 있습니다.
이제 원격 데스크톱 연결 화면이 나타납니다. 연결할 터미널 서버 이름이나 IP 주소를 입력합니다. 옵션 단추 아래에는 로컬 드라이브나 프린터 연결을 지정하거나 비디오 해상도를 변경하는 등의 작업을 할 수 있는 여러 옵션이 있습니다. TS01을 옵션 영역에 하드 코드한 다음 RDP 프로필을 데스크톱에 저장할 수도 있습니다. RDP 프로필의 기본 이름은 Default.RDP입니다.

관리 작업
TS01에서 일부 관리 작업을 수행하려는 경우 가장 좋은 방법은 이 명령을 사용하는 것입니다. 이렇게 하면 콘솔 앞에 직접 앉아있는 것처럼 작업할 수 있기 때문입니다.
Mstsc /console
여러 개의 서로 다른 터미널 서버를 관리할 때는 모든 원격 터미널 서버를 하나의 트리 형식에 추가할 수 있으므로 관리 도구의 원격 데스크톱 유틸리티를 사용하는 것이 좋습니다.
마지막으로 Tsadmin 명령도 알아두는 것이 좋습니다. 이 명령을 사용하면 터미널 서버에 연결된 사용자와 사용자가 연 Windows 프로세스를 볼 수 있습니다. 또한 관리자에게 가장 큰 이점인 사용자 추적 기능도 제공됩니다. 하지만 자신의 워크스테이션에서 TSadmin을 실행한 경우에는 사용자를 추적할 수 없습니다. 여기서는 연결만 볼 수 있습니다. 사용자를 추적하거나, 사용자에게 메시지를 보내거나, 사용자를 로그오프하려면 TS01에 직접 로그인해야 합니다.

결론
이제 터미널 서비스에 대해 확실하게 이해했으므로 터미널 서버를 쉽게 배포할 수 있을 것입니다. 이외에도 그룹 정책 설정이나 DFS와 같이 더 살펴볼 것들이 많지만 GPO 설정 시 극단적인 설정은 피하고 실제 사용자에게 선보이기 전에 철저한 테스트를 거치는 등의 기본 사항만 잘 기억하면 아주 훌륭하게 시작할 수 있습니다.

James D. Silliman은 MCSE이자 터미널 서버 배포를 전문으로 하는 DirectApps, Inc.의 수석 시스템 엔지니어입니다. DirectApps에서는 .NET 솔루션을 설계하고 호스팅과 ASP 서비스를 제공합니다. 문의 사항이 있으면 James@directapps.com으로 연락해 주십시오.


 From The Editor: 모바일 장치 보안
From The Editor
모바일 장치 보안
Joshua Trupin

오늘날 우리는 장소에 구애받지 않고 업무를 볼 수 있는 시대에 살고 있습니다. 지난 십 년에 걸쳐 "모든 곳을 사무실로"의 개념이 본격적으로 구체화되었습니다. 이제는 업무를 수행하기 위해 반드시 책상 앞에 앉을 필요가 없습니다. 모바일 기술 덕분에 도로 위나 집, 기차, 심지어 빨간 불 앞에 선 자동차 안에서도(주의가 필요하겠지만) 생산적인 활동을 할 수가 있는 것입니다. 정말 신나는 세상이죠? 그러나 쉽게 이동이 가능한 장치를 안전하게 보호하고 관리해야 하는 중대한 과제를 안고 있는 IT 전문가에게는 그다지 신나는 일만은 아니랍니다.
1980년대만 해도 보안이라 하면 신종 바이러스가 보고되었을 때 사람들에게 플로피 디스크를 다른 사람의 것과 섞이지 않도록 각자 잘 넣어 두라고 알리는 정도였습니다. 농담이 아니고, 실제로 필자가 전에 다니던 직장에서 이렇게 했을 때 한 대의 컴퓨터도 바이러스에 감염되지 않았답니다. 악의적인 프로그램이 시스템을 감염시켜도 누군가 감염된 플로피 디스크를 다른 자리로 가져가지 않는 한 바이러스를 쉽게 제어할 수 있었습니다. 가끔은 IT 전문가가 점심 시간에 사무실을 몰래 돌아다니면서 5.25인치 드라이브를 모두 제거하는 경우도 있었지요. 운 좋은 사람은 10MB 하드 드라이브를 사용하게 되기도 했었고요.
1990년대에는 바이러스가 웹을 통해 침투하기 시작하면서 누구의 컴퓨터가 감염되었는지 찾아내기가 점차 어려워졌습니다. 십 년 전처럼 직원들의 손에서 디스켓을 낚아채는 방법으로는 더 이상 컴퓨터를 제대로 보호할 수가 없게 된 것입니다.
오늘날에 들어서는 회사 전체에 대한 보안 유지와 그룹 정책 배포는 물론 방화벽, 검역 및 문제 발생 지점의 설정을 관리해야 합니다. 그리고 또 어떤 일이 벌어지고 있을까요? 회사 자체가 사무실 밖의 넓은 세상으로 이동하기 시작했습니다! 그렇다면 이제 어떻게 해야 할까요?
오늘날의 IT 환경에서 사내 자산을 보호하는 것은 보안 업무의 절반에 지나지 않습니다. 조직에 취약점이 있으면 조직의 보안 수준은 그만큼 약해지며 직원들이 회사 네트워크에 연결된 모바일 장치와 랩톱을 들고 다니면서 업무를 수행한다면 문제가 발생할 수밖에 없기 때문입니다. 이번 호에서는 지친 관리자가 밤에 편히 잠들 수 있도록 모바일 장치의 보안을 유지하는 방법을 집중적으로 다룹니다.
물론 그 외에도 많은 내용이 수록되어 있습니다. Exchange Server에서의 규정 준수 관리, 네트워크 액세스 보호, 터미널 서비스 배포, Windows PowerShell, SQL Server 등 모두 열거하자면 날이 샐지도 모릅니다.
여러분이 지금까지 겪었던 보안 관련 문제 중에서 가장 특이했던 상황은 어떤 것입니까? TechNet Magazine 블로그(blogs.technet.com/tnmag)에 들러 서로 경험담을 나누어 보세요. 편집자들이 항상 대기 중이랍니다! —Joshua Trupin

많은 Microsoft 기술 전문가들께서 도움을 주셨습니다. Alex Balcanquall, Tad Brockway, Anah Cameron, Jeroen de Borst, Michael Higashi, Ryan Hurst, Paul Limont, Sherman Lovell, Michael Murgolo, Shivakumar Seetharaman, John Speare, David Strome, 그리고 Jim Truher에게 감사의 인사를 전합니다.

Joshua Trupin


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

이미지 만들기
"Windows® PE 시작"이라는 2006년 9월호 기사에서 Wes Miller는 mkimg.cmd를 언급했습니다. 하지만 Windows 자동 설치 키트(WAIK)와 Business Desktop Deployment Solution Accelerator(BDD) 2007 모두가 설치된 Windows Vista™ 시스템에서 이 명령 파일을 찾을 수가 없습니다. 현재 배포에 mkimg_pe2004.cmd와 mkimg_pe2005.cmd가 있는데, 이 두 가지 모두 존재하지 않는 것으로 보이는 bldini.cmd 파일을 호출합니다. 이러한 파일들은 어디에서 찾을 수 있습니까?
—Jim A.

이 기사는 Windows Vista가 출시되기 전에 게시되었으며 Windows XP 및 Windows Server® 2003에 사용 가능한 Windows PE 버전(Windows PE 1.6)만을 대상으로 합니다. 2006년 11월호에 Windows Vista에서 사용할 수 있는 버전인 Windows PE 2.0에 대해 설명하는 후속 기사가 게시되었습니다. 이 기사는 웹 사이트에서 볼 수 있습니다.
Windows PE 2.0 이미지는 WAIK의 도구를 사용하여 빌드하고 사용자 지정할 수 있으며, 특히 "mkimg" 명령은 "peimg"로 대체되었습니다. Windows PE 2.0 이미지를 빌드하는 세부 단계는 WAIK 온라인 문서에서 볼 수 있습니다.

보안에 대한 오해
2006년 5/6월호 기사 "보안에 대한 공통적인 오해 해석"에서 긴 암호가 복잡한 암호보다 낫다고 권장했는데 이렇게 긴 암호를 생각해 내는 가장 좋은 방법은 무엇입니까? 긴 암호는 외우기가 쉽지 않습니다. 또한 액세스가 필요한 시스템마다 다른 암호를 사용하는 것이 좋다는 조언도 들었지만 이 역시 기억하고 생각해 내는 것이 어렵습니다.
— Ian R.

Steve Riley에게 문의한 결과 곧바로 다음과 같은 답변을 받았습니다.
기억 가능성에 대한 좋은 지적입니다. 저는 복잡한 암호에 사용된 무작위 문자들을 기억하는 것보다는 암호 구문으로 사용된 문장을 기억하는 것이 훨씬 쉽다고 생각합니다. 또한 연상 기법을 사용하면 여러 암호 구문도 기억할 수 있습니다. 예를 들어 Hotmail®의 암호 구문이 "My dog and I got the mail."인 경우 이 암호는 대상인 전자 메일 사이트에 대해 메일을 받는다는 연관성이 있기 때문에 기억하기 쉽습니다. 이렇게 연상 기법을 사용하면 eBay에는 "My dog and I went shopping."을, 사무실의 도메인 계정에는 "My dog and I went to work."를, 자주 찾는 그림 사이트에는 "My dog and I admired some art."를 암호 구문으로 사용할 수 있습니다.
이렇게 암호 구문은 제한 없이 원하는 데에서 따올 수 있습니다. 제가 아는 사람 중에는 "몬티 파이튼"이라는 영화의 대사만 사용하는 사람도 있습니다. 또한 키보드에서 연속되는 문자로 각 단어가 시작되는 5개 단어로 구성된 구문(예: "Queen willie eats rancid turnips."—QWERT)만 사용하는 사람도 있습니다. 조금만 창의성을 발휘하여 암호 구문을 만들면 암호와 관련된 거의 모든 문제를 해결할 수 있을 뿐만 아니라 개인 신분 입증에 사용되는 암호에 대한 보안도 더욱 강화할 수 있습니다.

"보안에 대한 공통적인 오해 해석" 기사를 재미있게 읽었으며 많은 도움이 되었습니다. 하지만 소프트웨어에서 고유한 문자 집합(Webdings®에 없는 문자, 즉 한 번도 본 적이 없는 문자)을 독립적 프로그램에서 만들고 사용하는 것을 허용한다고 가정해 보았습니다. 이 경우 가능한 모든 고유 문자 집합 전체를 갖고 있는 사람이 없을 것이며 해당 문자를 만들고 사용하는 사용자 자신만 알고 있기 때문에 이러한 복잡한 암호가 더 안전하지 않을까요? 즉, USB 키를 분실했다면 "War and Peace"라고 입력하는 것보다 이러한 고유 문자를 간단한 형식으로 다시 만드는 것이 좋겠다는 생각이 드는데요.
—H.D.

흥미로운 아이디어지만 그렇게 고유하며 이전에 본 적 없는 문자를 어떻게 기억할 수 있을까요?

Sysprep
2006년 5/6월호 "데스크톱 이미지 생성을 단순화하는 기법" 기사에서 Shelly Bird는 Sysprep 폴더를 만들 때 "프로세스는 기본적인 하드웨어를 갖춘 레거시 시스템에서 마스터 이미지를 빌드하는 것으로 시작한다..."고 말했습니다. 이 말의 정확한 의미는 무엇입니까? 지금 BDD를 확인하고 있지만 단일 이미지를 사용한 배포를 제안하는 내용은 찾지 못했습니다. 이 정보는 어떻게 얻을 수 있습니까?
— Jon S.

언급하신 기사에서 필자는 이미지를 캡처하여 다른 컴퓨터로 다시 배포할 수 있는 표준화된 참조 구성을 만드는 것에 대해 이야기하는 것입니다. 즉, 환경에서 가장 단순한 하드웨어를 최소 공통 분모로 선택하고 여기에 Windows를 설치한 다음 이 하드웨어를 조직 전체에 배포할 수정 사항을 포함한 기본 사양으로 구성합니다. 그리고 원하는 응용 프로그램도 모두 설치한 다음 Sysprep 도구를 사용하여 배포할 준비를 합니다. 이 도구에서는 이미지를 새 하드웨어에 다시 배포할 수 있도록 하드웨어 고유 정보를 제거합니다.
이 프로세스에 대한 가장 좋은 지침은 BDD에 포함되어 있는 컴퓨터 이미징 시스템 기능 팀 가이드에서 확인할 수 있습니다. BDD의 컴퓨터 이미징 시스템 구성 요소에는 이미지를 사용자 지정하고 준비하는 데 도움이 되는 다운로드 가능한 도구가 포함되어 있습니다. 자세한 내용은 microsoft.com/technet/desktopdeployment/bdd/standard/ComImgFea.mspx를 참조하십시오.

인증 변환
직장에서 SQL Server™ 2005를 사용하고 있습니다. 인증 방식을 Windows 인증에서 SQL Server 인증(sa 로그인 사용)으로 변경하려면 어떻게 해야 합니까?
— Sara J

SQL Server 온라인 설명서에서 관련 항목(msdn2.microsoft.com/ms188670.aspx)을 읽으면 문제 해결에 도움이 될 것입니다. 하지만 sa를 사용하면 특히 암호를 사용하지 않는 경우 보안 문제가 발생할 수 있으므로 Windows 인증을 사용할 것을 강력하게 권장합니다. Microsoft에서는 바로 이런 이유 때문에 코드 샘플에 더 이상 sa/nopass를 사용하지 않습니다.

칭찬의 글
매달 TechNet Magazine을 아주 재미있게 보고 있습니다. 기사를 인쇄해서 가방이나 차에 두고 회사나 집 등에서 시간이 날 때마다 읽습니다. 그러다 보니 잡지 전체를 Tablet PC나 Pocket PC Phone에 담을 수 있으면 좋겠다는 생각이 들었습니다. 또한 MP3 플레이어로 들을 수 있는 오디오 버전도 나왔으면 정말 좋겠습니다. 어쨌든 이 잡지는 너무나 유용합니다. 너무나도 좋아하는 잡지이며 제 모든 동료들에게 소개하면서 바이블과 같은 잡지라고 광고한답니다.
— Erasmo M.

오디오 버전을 원하십니까? 지금 사용할 수 있습니다. 매월 TechNet Magazine Podcast가 제공되고 있습니다. TechNet Magazine 사이트(www.technetmagazine.com)로 이동하여 왼쪽의 Podcast 링크를 클릭하십시오. 많은 청취 바랍니다.

Jigsaw Poster
2006년 3/4월호에서 소개된 Active Directory® Component Jigsaw 포스터는 Windows Server 2003에서 Active Directory가 작동하는 방식을 보여 주는 최고의 그림이었습니다. 저는 다국적 조직을 Windows 2000 및 Active Directory로 이전하는 프로젝트를 관리하고 있었는데 이 포스터를 통해 작업을 훨씬 수월하게 할 수 있었습니다. 아직도 저희 회사의 엔터프라이즈 관리자는 이 포스터에 명확하게 나와 있는 구성 요소에 동의하지 않고 있어 이러한 형태의 정보를 활용하면 작업을 더 일관되고 집중적으로 수행하는 데 도움이 될 것 같습니다. 이 포스터를 다운로드할 수 있습니까?
— Mike C.

이 포스터에 대해 매우 많은 요청을 받았습니다. 이런 문의 사항도 매우 많았습니다. 따라서 go.microsoft.com/fwlink/?LinkID=80428에서 포스터를 다운로드할 수 있도록 했습니다. 하지만 크기가 매우 크므로 Letter 크기의 용지에는 인쇄하지 마십시오.

Outlook 전자 메일 서명 설정
회사에서 시스템 관리자로 근무 중인데 도메인 내 모든 사용자의 Outlook® 서명을 표준화하기 위한 스크립트를 작성하고 있습니다. 2006년 10월호 "Outlook 전자 메일 서명 설정" 칼럼에 소개된 샘플 코드를 사용하고 있는데 약간의 문제가 있습니다. 다음 코드를 사용하여 서명의 글꼴 색을 설정하고 사용자 지정하려고 해도 글꼴 색이 검은색에서 바뀌지 않습니다.
objSelection.Font.Color = wdRed
글꼴과 글꼴 크기는 바꿀 수 있는데 글꼴 색은 바꿀 수 없습니다.
— Edison P.

직통 전화로 Scripting Guy에게 문의했더니 다음과 같은 답변을 받았습니다.
글꼴 색을 바꾸려면 wdColor 열거형을 사용해야 합니다. 다음과 같이 해보십시오.
  • 스크립트에서 다음 상수를 정의합니다.
wdColorRed = 255
  • 다음 코드를 사용하여 색을 지정합니다.
objSelection.Font.Color = wdColorRed
이렇게 하면 문제가 해결될 것입니다.

Windows PE 구하기
저희 회사는 Microsoft® Select 라이선스 계약을 체결하였습니다. 회사에서 사용할 제5세대 Windows PE를 얻으려면 누구에게 연락해야 합니까? 특히 USB 플래시 드라이브에서 부팅하는 기능을 사용하려고 합니다.
— Thom S.

Windows PE는 Software Assurance의 혜택 중 하나입니다. 혜택 비교 차트를 참조하여 귀사의 라이선스 프로그램에 이 혜택이 포함되어 있는지 확인할 수 있습니다. 포함되어 있으면 귀사의 Microsoft 볼륨 라이선스 서비스 계정(https://licensing.microsoft.com에서 로그인 가능)을 통해 Windows PE를 다운로드할 수 있습니다. 이 웹 사이트 액세스와 관련하여 도움이 필요한 경우 귀사의 라이선스 코디네이터 또는 Microsoft 라이선스 담당자에게 문의하십시오.


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

HTTP 트래픽 분석
HttpWatch Professional Edition
httpwatch.com

HTTP는 브라우저에서 웹 사이트 통신을 하기 위한 기반으로, 매우 유용한 계층 7 프로토콜입니다. 또한 웹 서비스가 도입되면서 대부분의 Windows® Forms 응용 프로그램에서는 HTTP를 사용하여 프로그램 업데이트를 다운로드하고 사용자 정보를 수집하는 기능을 제공하고 있습니다. HTTP를 통한 응용 프로그램 간 통신의 보안을 검증하거나 성능을 조정하거나 문제를 확인하는 것은 어려운 작업일 수도 있습니다. 그러나 HttpWatch Professional Edition을 사용하면 웹과 브라우저 사이에서 발생하는 문제를 쉽게 해결할 수 있습니다.
웹 요청과 관련된 모든 정보를 보여 주는 HttpWatch
웹 요청과 관련된 모든 정보를 보여 주는 HttpWatch
HttpWatch Professional은 Internet Explorer® 6.0 및 Internet Explorer 7과 통합되며 브라우저 아래쪽에 표시되거나 브라우저 옆에 독립 실행형 도구로 표시됩니다. Record 단추를 클릭하면 곧바로 트래픽이 캡처되고 기록되기 시작하여 웹 요청과 관련된 모든 정보가 표시됩니다. 원시 HTTP 스트림, 페이지 요청에 대해 발생한 리디렉션, 요청과 관련된 쿼리 문자열 키-값 쌍, HTTP 메서드, HTTP 압축 정보, 청크 분할 인코딩 정보 등을 볼 수 있습니다. 이 외에도 쿠키 값, 경로, 도메인, 만료 날짜 등 요청과 관련된 쿠키에 대한 자세한 정보를 확인할 수 있습니다.
또한 HttpWatch는 Internet Explorer의 플러그 인으로 실행되므로 해독된 HTTPS 요청에 대한 정보를 모두 볼 수도 있습니다.
HttpWatch는 밀리초 단위의 응답 시간, DNS 조회, TCP 연결, IP 주소 정보, 포트, 브라우저에서 보내고 받은 바이트 수 등을 보여 주므로 요청에 대한 네트워크 수준의 성능 데이터를 자세히 검토할 수 있습니다. 각 요청과 관련된 정보가 모두 표시된다면 어떨지 상상해 보십시오. 단일 HTML 페이지에 대한 각각의 요청에는 수많은 부분이 관련되어 있습니다. 그런데 HttpWatch에는 콘텐츠 형식, 응답 코드, URL, 헤더 또는 특정 콘텐츠 문자열을 기준으로 표시 내용을 필터링할 수 있는 옵션이 있으므로 걱정할 필요가 없습니다. 따라서 검토하려는 부분만 필터링하여 관심 있는 특정 정보만 빠르게 살펴볼 수 있습니다.
제품 웹 사이트에서는 이 도구를 사용하여 고객에게 발생한 문제를 해결하도록 장려하고 있습니다. 이 응용 프로그램을 사용하면 요청 정보를 저장할 수 있으므로 고객이 문제가 발생한 요청과 관련된 정보를 보낼 수 있습니다. 이는 문제 해결에 매우 유용합니다. 마우스 단추만 몇 번 클릭하면 전용 HWL 파일을 전자 메일로 보낼 수 있습니다. 고객으로부터 이 파일을 받은 후에는 설치 패키지에 포함된 독립 실행형 로그 파일 뷰어로 파일을 볼 수 있습니다. 또한 요청 데이터를 CSV와 XML로 내보내 다른 응용 프로그램에서 사용할 수도 있습니다.
HttpWatch에는 테스트 중 HTTP 수준 정보를 기록하여 성능 병목 현상을 찾는 데 도움이 되는 자동화 API가 포함되어 있습니다. 패키지를 설치하면 이 API의 사용 방법을 보여 주는 예 세 개가 설치됩니다. 그 중 하나는 Interop 라이브러리를 사용하여 C 언어로 작성된 예이고 나머지 둘은 COM을 사용한 JavaScript 및 Ruby용 예입니다. 테스트 목적으로 Watir과 함께 Ruby를 사용하는 경우 해당 제품 웹 사이트에서 테스트 플랫폼에 HttpWatch를 통합하는 방법을 알려 주는 자습서를 확인하십시오.
가격: 단일 사용자 라이선스당 $249

서평
Microsoft Solutions Framework Essentials
microsoft.com/mspress

성공적인 기술 솔루션을 제공하려면 조직에 효과적인 프로세스와 명확한 통신 체계가 갖추어야 있어야 합니다. Michael S. V. Turner는 자신의 저서 Microsoft Solutions Framework Essentials(Microsoft Press, 2006)에서 Microsoft® Solutions Framework(MSF) 버전 4.0의 기본 개념을 설명하고 이를 이용하여 검증된 프로세스와 통신 체계를 개발 및 구현하는 방법을 보여 줍니다.
이 책은 MSF 지침과 방법을 적용하는 과정에서 현재 프로세스와 조직 구조에 모든 것을 한꺼번에 포함하려 하지 말라는 값진 조언과 함께 시작됩니다. 그리고 MSF의 일부를 해당 제품이나 프로젝트 개발에 구현한 다음 그 결과가 성공적인지 평가하라는 대안을 제시합니다. 평가가 끝나고 결과가 성공적이면 프로젝트에 적합한 MSF의 다른 측면을 선택하여 표준 프로젝트 주기에 도입합니다. 이러한 방법을 이용하면 변경으로 인해 발생하는 예측 불가능한 문제를 줄이면서 해당 환경에 맞게 MSF를 응용할 수 있습니다.
이 책은 전문가를 비롯하여 기술 솔루션의 제공과 관련된 모든 독자를 대상으로 합니다. Building an MSF Team이라는 장에서는 성공적인 솔루션을 제공하기 위해 전문가와 비전문가가 어떠한 방식으로 협력해야 하는지 보여 줍니다. 그러나 이 과정에서 각자가 맡은 일상적인 업무가 변경될 수밖에 없으므로 이는 MSF를 구현하는 데 따르는 어려운 작업 중 하나라는 사실도 언급하고 있습니다.
구조 변경의 중심에는 변화를 지지하는 사람들로 팀을 구성하여 각 팀원이 프로젝트의 고유한 측면을 대표하는 동료로 협력함으로써 전체 프로세스에 일조할 것이라는 생각이 깔려 있습니다. 그렇다고 해서 권한 있는 의사 결정자가 필요하지 않다는 말은 아닙니다. 이 책의 설명대로 MSF 지지자는 고유한 구조와 책임이 있는 제품 관리, 프로그램 관리, 아키텍처, 개발, 테스트, 설치 환경, 릴리스/운영이라는 7개의 그룹으로 나뉩니다. 이 책에서는 그룹 수가 많은 조직의 경우 더 많은 팀과 그룹을 지원하도록 지지자 그룹의 개념을 확장하는 방법을 제시합니다.
모든 프로젝트에는 항상 위험이 따르며 여러분과 팀은 이러한 위험을 효과적으로 처리하는 데 도움이 되는 다양한 재구성 방법을 찾아낼 것입니다. 프로젝트의 위험을 최소화하는 것은 매우 중요합니다. 이를 실현할 수 있도록 위험 관리 프로세스는 위험 확인, 분석 및 우선 순위 결정, 계획 및 일정 수립, 추적 및 보고, 변경 관리, 과거의 경험을 통한 학습이라는 6개의 단계로 나뉩니다. 또한 위험은 프로젝트 주기 전체에 걸쳐 지속적으로 평가해야 합니다. 이 단원에서 설명하는 요점을 올바르게 파악하면 실패 가능성을 줄이는 데 많은 도움이 될 것입니다.
이 책에서는 솔루션을 구상, 계획, 빌드, 안정화 및 배포하는 솔루션 구현 단계를 비롯하여 솔루션 제공의 기본 과정에 대해 자세히 다루며 각 지지자 그룹이 각 단계에서 담당하는 업무를 정의합니다. 또한 이 책에서는 MSF 관리 모델도 소개합니다. 이 모델에서는 솔루션 제공 주기의 각 단계, 즉 솔루션 제공 과정을 안내하는 구상, 계획 수립, 빌드, 안정화, 배포, 관리에 대해 보다 자세히 설명합니다.
운영, 개발, 프로젝트 관리 등 자신이 조직에서 맡은 역할이 이 책에서 설명하는 도구나 프로세스와는 관련이 없다고 생각되어도 책을 한번 읽어 보는 것이 좋습니다. 그러면 현재 프로세스를 훨씬 새로운 시각으로 통찰할 수 있게 될 것입니다. 자신이 맡은 업무가 소프트웨어 개발과는 아무런 관련이 없더라도 이 책의 내용은 조직의 효율성 및 통신 채널을 향상시키기 위한 발판이 될 것입니다.
가격: $44.99

파일 편집
UltraEdit
ultraedit.com

열성적인 IT 전문가라면 자신의 도구 상자에 강력한 편집기를 갖추고 있어야 할 것입니다. 이러한 필수 편집기 중 하나가 바로 IDM Computer Solutions의 UltraEdit입니다. 이 편집기는 ASCII 문자 삽입, 매크로, 정규식 찾기 및 바꾸기, 외부 응용 프로그램 실행, UTF 지원, 큰 텍스트 파일의 고속 처리 등 강력한 텍스트 편집기가 제공하는 표준 기능을 모두 지원합니다. 이 외에도 UltraEdit에는 이 도구의 가치를 높여 주는 흔하지 않은 몇 가지 기능이 포함되어 있습니다.
기본 편집 모드에서 10만 단어에 이르는 다국어 통합 맞춤법 검사, 자동 완성, C#과 같은 표준 언어에 대한 코드 구문 강조 표시 기능을 사용할 수 있습니다. 하드 리턴을 통해 지정한 열에 자동 줄 바꿈을 설정할 수 있으며 이는 줄의 길이가 특정 길이 미만이어야 하는 텍스트 기반 전자 메일의 서식을 지정할 때 매우 유용합니다. 이 경우 마우스 단추만 몇 번 클릭하여 UltraEdit을 통해 전자 메일을 보낼 수 있습니다. 이 응용 프로그램은 Windows 탐색기와 통합되므로 파일을 마우스 오른쪽 단추로 클릭한 다음 마우스 왼쪽 단추를 클릭하기만 하면 편집할 파일을 열 수 있습니다.
UltraEdit의 코드 구문 강조 표시
UltraEdit의 코드 구문 강조 표시
UltraEdit은 다른 형식의 파일에도 사용할 수 있습니다. UltraEdit에서는 이진 파일을 처리할 수 있으며 16진 값, 줄 참조 및 가능한 ASCII 값을 표준 16진 편집기 보기로 제공합니다. 16진 편집 모드에서는 값을 잘라내거나 복사하거나 붙여 넣을 수 있고 표준 찾기 및 바꾸기 작업을 수행할 수 있습니다. UltraEdit에는 FTP 및 SFTP를 통한 연결을 모두 지원하는 통합 FTP 클라이언트가 포함되어 있습니다. 이 외에도 표준 SSH(Secure Shell) 또는 TELNET 연결을 열 수 있습니다.
웹 개발자는 이 응용 프로그램에 포함된 통합 HTML 유효성 검사 도구를 사용하여 웹 페이지를 검사할 수 있습니다. UltraEdit에는 텍스트 기반 데이터베이스 파일 및 구분 기호로 구분된 로그 파일 작업을 위한 열 모드가 제공됩니다. 이 모드에서는 데이터 간의 이동, 데이터 합계 및 편집이 용이하므로 데이터 편집이 간편합니다. UltraEdit에서는 일련의 파일을 프로젝트나 작업 영역으로 그룹화할 수 있으므로 마우스 단추를 한 번만 클릭하여 관련 파일을 한 번에 열 수 있습니다. 간단히 말해 UltraEdit은 IT 업무를 보다 효율적으로 쉽게 수행할 수 있게 해 주는 기능의 집합체라고 할 수 있습니다.
가격: 단일 사용자 라이선스당 $49.95

모바일 구성 관리
Net-Switch
net-switch.com

근래에 들어 데이터 센터에서 QA 환경으로 이동하는 경우와 같이 랩톱 컴퓨터를 가지고 다양한 환경으로 이동해야 하는 경우가 많아졌습니다. 그런데 이동할 때마다 랩톱의 정적 IP 주소와 기본 프린터를 다시 지정해야 합니다. 이미 이러한 문제를 경험한 적이 있다면 Net-Switch를 한번 사용해 보십시오. 간편한 이 유틸리티를 사용하면 자체 기본 프린터 지정을 포함한 다양한 네트워크 구성을 설정하고 저장할 수 있으므로 다른 환경으로 이동할 때마다 주소를 기억하거나 수동으로 입력할 필요가 없습니다.
Net-Switch로 랩톱 설정 처리
Net-Switch로 랩톱 설정 처리
이 응용 프로그램은 사용하기가 정말 쉽습니다. 구성에 이름을 지정하고 네트워크 어댑터를 선택한 다음 관련 마스크, 게이트웨이 및 DNS 서버로 정적 IP를 할당하고(또는 정적 IP 대신 DHCP 선택하고) 기본 프린터를 설정하기만 하면 됩니다. Net-Switch를 사용하면 저렴한 비용으로 일상의 번거로운 작업을 피할 수 있습니다.
가격: $19.95

Toolbox칼럼에 대한 의견 보내기
여기에서 다루었으면 하는 도구나 유틸리티가 있으면 tntools@microsoft.com 주소로 저자에게 알려 주십시오.

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


 SQL Q&amp;A: Best Practices Analyzer, 다중 코어 프로세서 외
SQL Q&A
Best Practices Analyzer, 다중 코어 프로세서 외
편집자: Nancy Michell

Q: 스키마 정규화 테이블/뷰의 사용과 관련된 BPA(Best Practices Analyzer) 규칙에 대해 몇 가지 질문이 있습니다. BPA 설명서에 따르면 이 규칙은 임시 테이블에 대해서는 스키마 정규화를 검사하지 않습니다. BPA 보고서 플래그가 저장 프로시저 내에 만들어진 임시 테이블을 참조하는데, 이 임시 테이블을 정규화해야 합니까? 정규화해야 한다면 어떤 스키마를 사용해야 합니까? 저는 임시 테이블도 다른 테이블과 마찬가지로 해당 소유자에 대해 정규화해야 한다고 생각합니다.
A: SQL Server™ 2005에서는 사용자와 스키마가 분리되어 이전 버전의 SQL Server에서 테이블/뷰 참조를 스키마로 정규화해야 하는 BPA 권장 사항이 더 이상 적용되지 않습니다. SQL Server 2000에서는 서로 다른 기본 스키마를 사용하는 여러 사용자가 쿼리 계획을 다시 사용하려면 스키마 정규화가 필요했습니다. 정규화하지 않고도 dbo 개체를 사용할 수는 있었지만 SQL Server에서 먼저 개체의 기본 스키마를 검사해야 했으므로 쿼리 계획을 다시 사용할 수가 없었습니다. 이제 사용자와 스키마가 분리되어 여러 사용자가 기본 스키마를 공유할 수 있으며, 대개의 경우 모든 데이터베이스 사용자가 자신의 기본 스키마에 있는 개체에 액세스할 수 있습니다. 따라서 정규화되지 않은 테이블 및 뷰 이름이 포함된 임시 계획을 여러 사용자가 정상적으로 공유하고 다시 사용할 수 있습니다. 저장 프로시저 내 정규화되지 않은 테이블 및 뷰 이름의 경우에는 처음부터 이러한 문제가 발생하지 않으므로 이 규칙이 더욱 더 필요하지 않습니다. SQL Server 2005의 BPA에는 T-SQL 구문 분석기가 없으므로 이와 같은 규칙이 포함되지 않습니다. 대신 적절하지 않은 구성 및 보안 설정이 있는지 검사합니다.

Q: SQL Server 2005 SP1에서 이상한 동작이 발생합니다. 한 테이블에서 레코드를 삭제하고 바로 삽입하려 하면 삭제 트랜잭션이 커밋될 때까지 테이블이 잠겨 삽입할 수 없습니다. 왜 차단되는지 이유를 알 수 있을까요?
A: 예. 그림 1의 DMV(동적 관리 뷰)를 실행하여 잠금과 차단의 원인을 알아낼 수 있습니다.
Figure 1 차단 및 잠금 찾기 (Close Figure 1)
-- script to show blocking and locks
SELECT
  t1.request_session_id AS spid,
  t1.resource_type AS type,
  t1.resource_database_id AS dbid,
  (case resource_type
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id)
   WHEN ‘DATABASE’ THEN ‘ ‘
   ELSE (SELECT object_name(object_id)
      FROM sys.partitions
      WHERE hobt_id=resource_associated_entity_id)
  END) AS objname,
  t1.resource_description AS description,
  t1.request_mode AS mode,
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address
GO

Q: 하이퍼스레딩 및 듀얼 코어 기술 외에도 CPU 공급업체에서는 더 많은 코어(4중, 8중 등)가 장착된 프로세서를 출시하기 시작했습니다. SQL Server 2005 Standard Edition 배포를 지원하기 위해 다중 코어 프로세서가 여러 개 장착된 새 서버를 구입하는 것을 고려 중입니다. 그런데 Standard Edition에서는 CPU가 4개로 제한되므로 4중 코어 프로세서를 사용할 경우 한 개의 실제 CPU만 사용할 수 있는 것인지 궁금합니다.
A: 라이선스 및 CPU 버전 지원을 위해 SQL Server에서는 프로세서의 코어 수에 관계없이 실제 소켓/CPU의 수만 고려합니다. 따라서 SQL Server 2005 Standard Edition에서 CPU를 최대 4개까지 지원한다는 것은 각 CPU에 포함된 코어 수에 관계없이 4개의 실제 CPU 소켓을 지원한다는 의미입니다. 예를 들어 각각 네 개의 코어가 포함된 실제 CPU가 네 개 있을 경우 Standard Edition 배포 환경에서는 16개의 논리적 CPU를 사용하게 됩니다. 또한 16개의 코어/논리적 CPU를 사용하더라도 16개의 코어가 아니라 4개의 실제 CPU에 대해서만 비용을 지불하면 라이선스를 얻을 수 있습니다. SQL Server 및 다중 코어에 대한 자세한 내용은 microsoft.com/sql/howtobuy/multicore.mspx를 참조하십시오.

Q:새 데이터베이스 서버를 구입하려고 합니다. 64비트를 사용해야 할까요, 아니면 검증된 기존의 32비트 버전을 고수해야 할까요?
A. 상황에 따라 다릅니다. 이는 공급업체들이 하드웨어를 x86에서 x64로 바꾸면서 자주 제기되고 있는 질문입니다. 이 질문에 앞서 데이터베이스 서버의 메모리 부담이 어느 정도나 될지를 고려해야 합니다. 하드웨어의 총 사용 기간(일반적으로 3년) 동안 SQL Server 인스턴스에서 사용하는 메모리의 양이 3GB 미만이면 32비트 x86이 적절합니다. 단, 이 경우 도메인 컨트롤러, DNS 서버, 응용 프로그램 서버, 웹 서버, 메일 서버 등에서도 환경이 동일해야 합니다. SQL Server 인스턴스의 메모리 사용량이 16GB를 초과하거나 각 서버(또는 클러스터)에 여러 개의 인스턴스가 있는 경우에는 64비트 기술로 전환하는 것을 진지하게 고려해 보아야 합니다. 프로세서가 8개를 넘으면 IA64가 표준 권장 사항입니다. 다만 x64 4중 및 8중 코어 CPU가 대중화되기 시작함에 따라 IA64 대신 x64를 도입하는 데 대한 비용 측면의 논란은 있을 수 있습니다.
x64(또는 IA64)로 전환할 때 개발, 테스트 및 운영 환경에 동일한 아키텍처를 배포하는 비용은 초기 예상 비용에 포함하지 않을 수도 있습니다. 그러나 하드웨어 총 사용 기간이 절반 정도가 지날 때까지 이전 기술을 계속 사용해야 할지를 검토해 보아야 합니다. 18개월 정도 되면 순전히 x86 하드웨어에만 의존한다는 것이 거의 불가능할 것입니다. 당장은 현재대로 유지하고 1, 2년 후에 업그레이드하는 경우 완전 교체해야 하므로 비용이 많이 들 것입니다. 지금 64비트 하드웨어로 전환한다면 향후 몇 년간 선택의 폭이 넓어질 것입니다.
따라서 새 하드웨어를 구입할 때, 코어 응용 프로그램 릴리스 주기가 시작될 때 또는 SQL Server 2000에서 SQL Server 2005로 업그레이드할 때가 64비트로 전환하기에 좋은 시기입니다.

Q: 두 서버 간에 로그가 전달되도록 설정해 두었는데, 주말에 주 서버에서 하드웨어 문제가 발생하여 로그 전달이 중지되었습니다. 로그 전달을 모니터링하기 위해 돌아왔을 때는 몇 시간 동안 시스템 작동이 중단되었음에도 불구하고 LS_backup_dbname이 제대로 실행되고 있었습니다.
그러나 보조 서버에서 복사 작업은 제대로 수행되는 것처럼 보였지만 복원 작업은 파일을 건너뛰어 결국 계속해서 실패하고 있었습니다. 복원 작업이 실행되기는 하지만 모든 파일을 건너뛰고 결국 실패하는 것입니다. 그 결과 마지막 복원 이후 지금까지 849분이 흘러갔습니다. 과거에 이와 비슷한 상황에서는 단순히 로그 전달 구성을 다시 시작했었습니다. 다시 말해 로그 전달을 해제하고 다시 설정하여 새 백업을 만들어 보조 서버에 복원하고 로그 전달을 다시 시작했습니다. 이 시나리오를 보다 효율적으로 관리할 수 있는 방법이 있습니까?
A: 백업 파일이 없어서 발생한 결과인 것 같습니다. 아시겠지만 로그 전달의 백업, 복사 및 복원 작업은 개별적으로 실행됩니다. 복사 위치의 이전 백업 파일은 지정된 일정에 따라 제거됩니다. 복원 작업이 실행되지 않은 기간이 있었다면 지정된 일정을 초과하여 백업 파일이 없어졌을 수 있습니다. 로그 전달 복원 작업에는 여러 가지 작업 조건으로 발생한 다양한 실패 유형에서 복구하려고 하는 논리가 사용됩니다. 기본적으로 이 논리는 오류가 발생할 경우 파일을 검색하여 올바른 백업 파일을 찾으려고 합니다. 올바른 백업 파일이 없다면 무언가로 인해 필요한 파일이 제거되었거나 로그 전달의 백업 부분이 다시 구성되었기 때문입니다.
이 문제를 해결하는 한 가지 방법은 다른 백업 작업에서 우연히 만들어진 트랜잭션 로그 백업을 통해 수동으로 복원하는 것입니다. 파일을 단순히 로그 전달 복사 위치로 복사할 때의 문제는 로그 전달에서 인식하는 이름 규칙에 있습니다. 그러나 수동으로 해당 지점에서 복원하고 나면 정상 복원 작업이 다시 시작되어 계속됩니다.

Q: T-SQL을 사용하여 실제 메모리의 총 크기와 사용 가능한 크기를 알고 싶습니다. 이 정보를 쉽게 구할 수 있는 방법이 있습니까?
A: 그림 2의 쿼리를 실행하십시오. 그러면 원하는 데이터를 얻을 수 있습니다.
Figure 2 메모리 정보 보기 (Close Figure 2)
With VASummary(Size,Reserved,Free) AS
(SELECT
  Size = VaDump.Size,
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 0 ELSE 1 END),
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 1 ELSE 0 END)
FROM
(
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
    AS Size,
    region_allocation_base_address AS Base
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address <> 0x0
  GROUP BY region_allocation_base_address
  UNION
  SELECT CONVERT(VARBINARY, region_size_in_bytes),
    region_allocation_base_address
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)

SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024
    AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0

Q: 응용 프로그램에서 데이터베이스를 쉽게 만들 수 있도록 sa(시스템 관리자) 암호를 대칭 키로 암호화된 파일에 저장하고 싶습니다. 가능합니까?
A: 먼저 응용 프로그램에서 sa를 사용해서는 안 된다는 것을 말씀드리고 싶습니다. 또한 SQL Server 인증 대신 Windows 인증을 사용해야 합니다.
응용 프로그램에서 많은 권한이 필요한 작업을 반드시 수행해야 하는 경우에는 먼저 작업을 수행하는 데 필요한 최소 권한을 정의한 다음 해당 권한이 포함된 데이터베이스 역할을 정의합니다. 그런 다음 사용자에게 해당 역할을 할당한 후 EXECUTE AS 절을 사용하여 해당 기능을 수행할 저장 프로시저를 만듭니다. Execute As 절에 대한 설명은 msdn2.microsoft.com/ms188354.aspx를 참조하십시오.
해당 계정이 sa 계정인지의 여부는 제쳐두고 Windows 인증을 항상 사용해야 한다는 점을 감안하면 암호를 사용할 응용 프로그램에서만 암호에 액세스할 수 있고 권한이 없는 사용자나 응용 프로그램에서는 액세스할 수 없도록 SQL Server 로그인 계정의 암호를 안전하게 저장할 수 있는 방법이 있느냐를 먼저 질문해야 합니다.
암호를 암호화하는 것까지는 좋습니다. 그러나 이는 암호를 보호하는 것에서 암호화 키를 보호하는 것으로 문제가 옮겨진 것일 뿐입니다.
해당 응용 프로그램이 Microsoft® .NET Framework 기반 응용 프로그램일 경우 엔터프라이즈 라이브러리(msdn2.microsoft.com/aa480453.aspx)와 MSDN®의 패턴 및 사용 방법 섹션의 권장 사항(msdn.microsoft.com/practices)을 살펴보십시오. 엔터프라이즈 라이브러리에는 구성 블록, 암호화 블록, 데이터 액세스 블록 등 유용한 몇 가지 응용 프로그램 블록이 포함되어 있습니다. 이러한 블록은 적어도 암호를 안전하게 저장하는 데 도움이 되며 더 나아가 전반적인 데이터 액세스를 관리하는 데도 유용합니다.
.NET Framework를 사용하지 않을 경우에는 엔터프라이즈 라이브러리가 적절하지 않으므로 CryptoAPI(msdn2.microsoft.com/aa380255.aspx)에 익숙해져야 합니다. 여기에는 OS와 함께 배포되며 사용자 이름 또는 컴퓨터에 암호화 키를 연결하여 키 관리를 단순화하는 데 사용할 수 있는 핵심 암호화 기능이 포함되어 있습니다. 암호를 암호화하고 나면 키 관리가 중요해집니다.

Q: SQL Server 2000 2노드 클러스터 서버(64비트 하드웨어의 활성/활성)를 동일한 포리스트 내의 도메인 A에서 도메인 B로 이동하려고 합니다. SQL Server 데이터베이스는 SAN에 있습니다. Active Directory® 아키텍처에서는 두 개의 자식 도메인(도메인 A와 도메인 B)이 있는 빈 루트 도메인이 필요하며, 도메인 B에 모든 인프라 구성 요소를 넣으려고 합니다. 실행 환경은 Windows Server® 2003 Enterprise이고 Windows 2000을 실행하는 추가 도메인 컨트롤러가 있습니다.
SQL Server 클러스터 서버의 도메인 구성원 자격을 도메인 A에서 도메인 B로 변경하는 것이 가능합니까?
A: SQL Server 초보자는 "SQL Server 2000 장애 조치 클러스터의 도메인을 변경하는 방법" 및 "한 도메인에서 다른 도메인으로 Windows 클러스터 서버를 이동하는 방법"을 읽어 보십시오. 다중 인스턴스 클러스터에도 동일한 프로세스가 적용됩니다. 다중 인스턴스 클러스터의 경우 필요에 따라 각 인스턴스에 대해 단계를 반복해야 한다는 점만 다릅니다. 클러스터의 도메인 변경에 따르는 복잡함을 감안하면 절대로 권장하고 싶지 않지만 여러 차례 이러한 작업이 수행된 사례가 있습니다. 유일하게 선택할 수 있는 다른 방법은 질문자가 제시한 대로 새 인스턴스를 병렬로 다시 빌드한 다음 데이터를 마이그레이션하는 것입니다.
프로젝트마다 성격이 다르며 실제 도메인 수준의 변경 작업(보안 고려, 계정 마이그레이션, sid 매핑 등)을 수행하는 데는 매우 다양한 도구가 사용됩니다. 대개 이러한 부분이 실제 변경보다 더 어렵습니다.

기술적 자문을 주신 Microsoft IT 전문가: Sunil Agarwal, Laurent Banon, Steve Bloom, Chad Boyd, Matt Burr, Shaun Cox, Cindy Gross, Bobby Gulati, Matt Hollingsworth, Arnost Kobylka, Mikhail Shir, Fernando Pessoa Sousa, Stephen Strong, Ramu Veeraraghavan


 Utility Spotlight: SharePoint 사이트 및 서식 파일용 업그레이드 도구 키트
Utility Spotlight
SharePoint 사이트 및 서식 파일용 업그레이드 도구 키트
Luis Câmara Manoel and Peter Skjøtt Larsen
이 기사의 코드 다운로드: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

최근 Windows SharePoint Services(WSS) 3.0이 출시되면서 대부분의 관리자는 기존의 WSS 2.0 사이트와 데이터를 새로운 WSS 3.0 환경으로 업그레이드해야 하는 문제에 직면하게 되었습니다.
WSS 3.0은 적절히 사이트 데이터를 마이그레이션하고 사이트 구조를 업그레이드할 수 있는 광범위한 도구를 제공하지만, 사용자 지정 사이트나 사이트 서식 파일의 구조를 업그레이드하기 위해서는 추가 작업이 필요할 수 있습니다.
다행히 Microsoft® Solution Accelerator 팀에서 이러한 작업에 도움이 되는 지침과 도구를 제공하는 Windows® SharePoint® Services 사이트 및 서식 파일용 업그레이드 도구 키트를 출시했습니다. 이에 대한 자세한 내용은 "WSS 리소스" 추가 기사를 참조하십시오. 이 칼럼에서는 사용자 지정 사이트를 WSS 3.0 환경으로 업그레이드하는 것과 관련된 몇 가지 문제와 이에 대한 해결 방법을 설명합니다. 본 내용에 앞서 칼럼을 쉽게 이해할 수 있도록 몇 가지 일반적인 용어를 정의한 "WSS 용어" 추가 기사를 참조하면 좋습니다.

업그레이드 프로세스
업그레이드는 왜 필요할까요? WSS 3.0에는 사이트 소유자가 업그레이드해야만 사용할 수 있는 다음과 같은 많은 새로운 기능이 포함되어 있기 때문입니다.
  • 휴지통. 사용자가 실수로 삭제한 문서를 복구할 수 있습니다.
  • 폴더 항목 수준 보안. 사이트 관리자가 폴더에 액세스할 수 있는 사용자나 그룹을 제어할 수 있습니다.
  • 전자 메일로 목록에 콘텐츠 추가. SharePoint 사이트의 블로그 게시물 목록과 같은 목록에 전자 메일을 통해 콘텐츠를 추가할 수 있습니다.
  • 사이트 작업 단추. 사용자가 사이트와 페이지를 쉽게 만들고, 페이지를 편집하고, 사이트 설정을 관리할 수 있습니다.
  • 탐색 경로. 사용자에게 즉각적인 탐색 컨텍스트를 제공합니다.
  • 모바일 보기. 모바일 사용자가 편리한 오프라인 동기화 기능을 사용할 수 있습니다.
  • RSS 피드. Internet Explorer 7.0 및 Outlook® 2007과 같은 RSS 사용 프로그램에서 목록의 정보를 검색할 수 있습니다.
  • 문서 라이브러리의 버전 관리. 편집 전 문서 체크 아웃을 위해 부 버전 관리 및 제어 기능을 제공합니다.
사이트 및 서식 파일 업그레이드 프로세스는 서버를 실제로 WSS 3.0으로 업그레이드하기 전이나 후에 특정 단계를 수행했는지 여부에 따라 달라지므로(그림 1 참조) 사이트 및 서식 파일의 업그레이드 요구 사항을 정의하는 것은 전반적인 WSS 3.0 업그레이드 전략에서 매우 중요한 단계입니다. 사이트 소유자와 서버 관리자는 긴밀하게 협력하여 인스턴스를 생성하고 WSS 3.0 환경으로 업그레이드할 사이트 및 서식 파일을 결정해야 합니다. 업그레이드할 사용자 지정 사이트를 선택하고 나면 업그레이드 작업을 시작할 수 있습니다.
그림 1 WSS 사이트 및 사이트 서식 파일 업그레이드 워크플로
그림 1 WSS 사이트 및 사이트 서식 파일 업그레이드 워크플로

사용자 지정 사이트 서식 파일 확인
사이트가 사용자 지정 사이트인지는 어떻게 확인할 수 있을까요? WSS 3.0에서는 팜 전체의 사이트 서식 파일에서 변경된 내용에 관한 보고서를 생성하는 업그레이드 전 검사 도구를 제공합니다. 특별한 주의가 필요한 사이트 서식 파일을 선별하려면 마이그레이션을 시작하기 전에 이 도구를 실행해야 합니다.
이 도구는 그림 2와 같이 XML 형식의 보고서를 제공합니다. unghostedPage 요소는 사이트가 사용자 지정되었음을 나타냅니다.

사용자 지정 사이트 정의
업그레이드하려고 하는 대부분의 사용자 지정 WSS 2.0 사이트는 표준 WSS 사이트 정의에서 생성된 서식 파일을 사용하여 만들어진 것입니다. 그러나 일부 사용자 지정 서식 파일은 사용자 지정 사이트 정의를 기반으로 만들어졌을 수도 있습니다. 조직의 개발자가 사용자 정의 사이트 정의를 만들었거나 조직에서 사용자 지정 사이트 정의를 기반으로 만들어진 타사 응용 프로그램이나 서식 파일을 구입한 경우를 예로 들 수 있습니다. 이 칼럼에서는 표준 사이트 정의 시나리오만 다룹니다. 사용자 지정 사이트 서식 파일 시나리오에 대한 자세한 내용은 "WSS 리소스" 추가 기사를 참조하십시오.
.stp 파일과 사이트가 표준 사이트 정의에서 만들어졌으면, 이는 WSS 3.0에 업그레이드 사이트 정의가 있음을 의미하므로 사이트를 설치하고 인스턴스를 생성할 수 있습니다.
특정 WSS 2.0 사이트 서식 파일을 업그레이드하려면 먼저 WSS 2.0 서버에 해당 서식 파일을 설치해야 합니다(그림 1의 1단계 참조). 그런 다음에는 설치한 각 서식 파일을 기반으로 사이트를 만들어야 합니다.
여러 개의 .stp 파일을 설치하고 여러 사이트의 인스턴스를 생성하며 업그레이드 프로세스 완료 후 서버에서 임시 파일을 제거하는 프로세스를 효율적으로 수행할 수 있도록 Solution Accelerator 팀은 Stsadm.exe 명령을 이용하는 일련의 스크립트를 제공합니다. 자세한 내용은 "솔루션 스크립트" 추가 기사를 참조하십시오. Stsadm.exe는 SharePoint 서버 및 사이트 관리에 필요한 전체 WSS 작업 집합을 제공하는 명령줄 응용 프로그램입니다. 솔루션 스크립트를 사용하면 설치와 인스턴스 생성을 일괄 처리하거나 순서대로 수행하도록 프로세스를 자동화할 수 있습니다. 설치해야 할 .stp 파일의 수와 인스턴스를 생성해야 할 사이트 수가 많은 경우 이 스크립트를 통해 시간을 상당히 절약할 수 있습니다.
솔루션 스크립트
설치 및 사이트 생성 프로세스에는 Stsadm.exe를 실행하는 두 개의 스크립트가 사용됩니다.
  • MigInstStp.cmd는 Stsadm.exe addtemplate 작업을 통해 사이트 서식 파일을 설치합니다. 이 작업에는 _SOURCEFILELOCATION, _SOURCEFILENAME 및 _FILETITLE이라는 매개 변수가 포함됩니다.
  • MigMakeSite_1.cmd는 새 사이트를 만듭니다. MigMakeSite_1.cmd는 Stsadm.exe createweb 작업을 실행합니다. 이 작업에는 _SERVERURL, _SITENAME, _SITETEMPLATENAME 및 _SITETITLE이라는 매개 변수가 포함됩니다.
저장된 사이트 서식 파일(.stp) 위치에 액세스할 수 있는 로컬 WSS 2.0 서버에서 이 두 스크립트를 실행합니다. 이 스크립트를 실행하려면 서버의 로컬 관리자 그룹 구성원이거나 사이트 만들기 권한이 있는 WSS 관리자 그룹 구성원이어야 합니다. Windows SharePoint Services 사이트 및 서식 파일용 업그레이드 도구 키트 가이드에서는 이 스크립트를 최대한 이용할 수 있는 방법을 매우 자세히 설명합니다. .stp를 설치하고 사이트의 인스턴스를 생성하면 서버를 업그레이드할 수 있습니다. WSS 3.0으로 업그레이드하는 방법은 “Windows SharePoint Services 3.0으로 업그레이드”에 자세히 설명되어 있습니다(“WSS 리소스” 추가 기사에 나오는 링크 참조).

WSS 용어
Windows SharePoint Services에는 고유한 용어가 사용됩니다. 다음은 일반적으로 사용되는 몇 가지 용어입니다.
사이트 정의. 특정 사이트 유형을 정의하는 파일 모음입니다. 사이트 정의에는 xml, .aspx, .ascx 및 마스터 페이지 파일과 함께 프런트 엔드 웹 서버의 특수 폴더에 저장된 목록 서식 파일 및 콘텐츠 파일이 포함됩니다. WSS에서는 팀 사이트, 새 사이트, 문서 작업 영역 등 곧바로 사용할 수 있는 표준 사이트 정의 모음을 기본 제공합니다. 처음에는 이러한 사이트 정의만 사이트 서식 파일 갤러리에 저장되어 있으며 새 SharePoint 사이트의 서식 파일 선택 목록에서 사용할 수 있습니다.
사이트 서식 파일. 사이트 서식 파일은 SharePoint 사이트의 인스턴스를 생성하는 방법을 정의합니다. 새 SharePoint 사이트를 만들려면 사이트의 기반으로 사용할 사이트 서식 파일을 선택해야 합니다. 예를 들어 표준 "새 사이트" 서식 파일을 기반으로 "운영 위원회"라는 새 사이트를 만들 수 있습니다. 그런 다음 인스턴스가 생성된 사이트에 목록, 라이브러리, 웹 파트, 기타 사용자 지정 항목을 추가할 수 있습니다. "새 사이트" 사이트 정의를 기반으로 하는 "운영 위원회"라는 이름의 서식 파일로 사이트를 저장하면 사용자 지정 항목을 다른 사용자가 사용할 수 있습니다. 사용자 지정 사이트 서식 파일은 .stp 파일(사이트 서식 파일)로 사이트 서식 파일 갤러리에 저장되며 새 SharePoint 사이트의 "서식 파일 선택" 목록에 표시되므로 사용자가 나중에 이를 기반으로 새 사이트를 만들 수 있습니다. 사이트 서식 파일에는 .xml, .aspx, 이미지, 기타 파일 등 일련의 사이트 구성 파일이 포함되며 이들은 .cab 파일과 기능이 유사한 단일 .stp 파일로 압축됩니다. 이 중에서 가장 중요한 파일은 Manifest.xml 파일이며, 여기에는 사이트 구조와 탐색, 목록과 라이브러리, 웹 파트 배치, 사용자 지정 목록 정의, 사용자 지정 사이트 서식 파일의 기반이 되는 사이트 정의 등의 중요한 정보가 포함됩니다.
응용 프로그램 서식 파일. 특정 비즈니스 프로세스 또는 작업 요구 사항에 맞게 개발된 Windows SharePoint Services 사이트 서식 파일입니다. 이러한 서식 파일은 Microsoft에서 게시하며 WSS 고객은 무료로 다운로드할 수 있습니다.
사용자 지정 사이트. 수정된 사용자 인터페이스가 있는 SharePoint 사이트입니다.
마스터 페이지. 사이트 전체에 일관된 인터페이스를 제공하기 위해 배너, 탐색 컨트롤, 기타 메뉴 등 기본 레이아웃 정보를 저장할 수 있는 영역입니다.
고스트 페이지(Ghosted Pages). 콘텐츠가 WSS 콘텐츠 데이터베이스에 저장되지 않는 페이지입니다. 콘텐츠는 사이트 정의 파일에서 읽습니다. 고스트 페이지는 사용자 지정되지 않은 페이지입니다.
언고스트 페이지(Unghosted Pages). 사이트 정의 파일에서 수정된 페이지이며 콘텐츠가 WSS 콘텐츠 데이터베이스에 저장됩니다.

서버 업그레이드 후 - 사이트 검사
이제 업그레이드 워크플로의 2단계를 수행할 차례입니다(그림 1 참조). 사이트 및 서식 파일 업그레이드의 2단계에는 다음과 같은 작업이 포함됩니다.
  1. 업그레이드된 사이트 열기 및 확인
  2. 기본 마스터 페이지 적용
  3. 새 사이트의 기능 및 레이아웃 문제 해결
  4. 수정된 사이트를 새 WSS 3.0 사이트 서식 파일로 저장
  5. 새 WSS 3.0 사이트 서식 파일을 서버에 다시 배포
  6. 다시 배포한 사이트 서식 파일을 사용하여 사이트 만들기
  7. 새 사이트를 열고 예상대로 작동하는지 확인
  8. 정리 프로세스 시작

사이트 정의로 다시 설정
업그레이드한 사이트를 보면 처음 WSS 2.0 사이트와 그다지 달라 보이지 않습니다. WSS 3.0 사이트처럼 보이게 만들려면 먼저 새 WSS 3.0 사이트의 사이트 정의로 다시 설정해야 합니다. 이렇게 하면 웹 파트에 사용자 지정한 내용이 그대로 유지되면서 대부분의 레이아웃 문제가 해결됩니다. 단, 해당 웹 파트가 사이트 정의 페이지에 있는 웹 파트 영역에 있어야 합니다. 또한 사이트의 모든 페이지에 기본 마스터 페이지가 적용됩니다.
마스터 페이지는 이름에서 알 수 있듯이 일관된 모양을 유지하기 위해 배너, 탐색 컨트롤, 기타 메뉴 등 기본 레이아웃 정보를 저장할 수 있는 영역입니다. 따라서 마스터 페이지를 변경하면 사이트 전체에 변경 내용을 전파할 수 있습니다. 마스터 페이지를 적용하면 업그레이드된 사이트에서 WSS 3.0의 모든 기본 기능이 활성화됩니다.
이제 사이트의 모양과 기능이 기본 WSS 3.0 사이트와 비슷해졌습니다. 그러나 토론 게시판, 사용자 지정 웹 파트, 하이퍼링크, 테마 등 여전히 문제가 있는 영역이 있을 수 있습니다.

문제가 있는 부분 해결
업그레이드한 사용자 지정 사이트에서는 많은 문제가 발생할 수 있습니다. 다음은 가장 일반적인 문제와 이를 해결할 수 있는 몇 가지 간단한 방법입니다.
WSS 2.0 기본 스타일시트가 계속해서 사이트에 적용되는 경우. SharePoint Designer에서 이전 스타일시트를 제거합니다.
웹 파트가 없거나 잘못된 위치에 있는 경우. SharePoint Designer를 사용하여 웹 파트를 이동하거나 삽입합니다.
웹 파트가 올바르게 작동하지 않는 경우. WSS 3.0과 호환되지 않는 웹 파트는 제거하고 해당 웹 파트가 WSS 3.0 환경에 맞게 제작된 것인지 웹 파트 개발자에게 문의합니다.
사용자 지정 목록 및 라이브러리의 모양이 적절하지 않은 경우. 기존 데이터를 저장하고 사용자 지정 목록이나 라이브러리를 다시 만든 다음 저장한 데이터를 가져옵니다.
활성화한 WSS 3.0 기능을 사용할 수 없는 경우. 팀 공동 작업 기능은 사이트 기능에서 명시적으로 활성화해야 할 수도 있습니다.
하이퍼링크가 더 이상 작동하지 않는 경우. 하드코드된 하이퍼링크는 수동으로 업데이트해야 할 수도 있습니다.
테마가 변경된 경우. 적절한 WSS 테마를 적용합니다.

마무리 작업
프로세스가 끝나가고 문제를 모두 해결한 후에는 사이트를 마지막으로 확인해야 합니다. 이때는 수정된 사이트를 WSS 3.0 사이트 서식 파일로 저장하고 새 .stp 설치 및 사이트 인스턴스화를 수행해야 합니다. 이 작업도 간단한 스크립트를 통해 수행할 수 있습니다. 마지막으로 사이트를 열어 모든 문제가 해결되었는지 확인하고 향후 작업 환경에 배포할 수 있도록 업그레이드된 사이트와 .stp가 준비되었는지도 확인해야 합니다.

업그레이드 대안
이 문서에서 설명한 자동화 도구와 프로세스를 이용하여 서식 파일을 업그레이드하는 방법이 최선의 방법이 아닐 때도 있습니다. 복잡하게 사용자 지정된 타사 서식 파일을 사용하는 경우에는 직접 서식 파일을 업그레이드하는 것이 매우 어려울 수도 있습니다. 이럴 때는 서식 파일의 새 버전이 제공될 때까지 기다리는 것이 낫습니다. WSS 3.0에서 새 서식 파일을 만든 다음 이전 서식 파일의 기능을 구현하는 것이 최선일 때도 있습니다.

응용 프로그램 서식 파일
Microsoft에서는 WSS 2.0과 WSS 3.0용 응용 프로그램 서식 파일 집합을 개발하여 제공하고 있습니다. 새로운 WSS 3.0 응용 프로그램 서식 파일에는 WSS 2.0 응용 프로그램 서식 파일 중 일부 파일의 업그레이드된 버전이 포함되어 있습니다. 이러한 서식 파일을 사용하고 있는 경우 업그레이드된 WSS 3.0 버전을 WSS 3.0 환경에 업로드할 수 있습니다.
WSS 3.0용으로 업그레이드되지 않은 WSS 2.0 응용 프로그램 서식 파일을 사용하고 있는 경우에는 Solution Accelerator 팀에서 WSS 3.0 환경에서 작동하도록 업그레이드한 WSS 2.0 응용 프로그램 서식 파일 집합을 제공하고 있으므로 이 서식 파일을 사용하면 됩니다.

요약
Windows SharePoint Services 사이트 및 서식 파일용 업그레이드 도구 키트는 3.0 환경에서 2.0 서식 파일, 사이트 및 사용자 지정 항목을 유지하는 데 많은 도움이 될 것입니다. 이 항목에 대한 자세한 내용을 보고 도구 키트를 구하려면 "WSS 리소스" 추가 기사에 나오는 사이트를 방문하십시오.
이번 칼럼을 작성하는 데 도움을 준 Betty Houser와 Solution Accelerator 팀에 깊은 감사를 드립니다.
WSS 리소스
  • 업그레이드 전 검사 도구
  • Windows SharePoint Services 사이트 및 서식 파일용 업그레이드 도구 키트
  • Windows SharePoint Services 3.0으로 업그레이드(Windows SharePoint Services 3.0 기술 라이브러리)
  • 업그레이드 정의 파일 및 새 사이트 정의 배포

Luis Câmara Manoel은 Microsoft Solution Accelerator 그룹의 프로그램 관리자로, Microsoft에서 근무한 지는 1년 되었으며 이전에는 유타 프로보의 Novell Inc와 Volera에서 프로젝트 관리자 겸 프로그램 관리자로 근무했습니다. 문의 사항이 있으면 luiscam@microsoft.com으로 연락하시면 됩니다.
Peter Skjøtt Larsen은 Microsoft Solution Accelerator 그룹의 제품 관리자로, Microsoft에서 4년 넘게 개발 및 마케팅 업무를 담당하고 있으며 이전에는 금융, 엔지니어링 및 텔레커뮤니케이션 업계를 위한 클라이언트 및 서버 소프트웨어를 개발했습니다. 문의 사항이 있으면 petela@microsoft.com으로 연락하시면 됩니다.


 The Business of IT: 세부적인 비즈니스 계획 수립
The Business of IT
세부적인 비즈니스 계획 수립
Stephen Ibaraki

많은 독자 여러분들은 이미 알고 계시겠지만 오늘날에는 그 정당성을 충분히 입증하지 않고는 IT 관련 구매나 투자를 하기가 어렵습니다. 단순히 혁신적인 최신 컴퓨팅 기술을 보유하기 위한 목적으로 구매를 하던 시대는 이미 지났습니다. 한때는 틀에 얽매이지 않은 무계획적인 기술이 시장 점유 및 성장을 위한
수단으로 여겨지기도 했습니다. 하지만 이러한 개념은 닷컴 기업의 몰락과 함께 막을 내렸고 IT 분야의 긴축이라는 결과를 가져왔습니다. 지금은 기업이 IT 프로젝트를 통해 회수할 수 있는 실질적인 가치가 분명히 있어야 합니다.
예산이 넉넉하지 않은 상황에서 IT 투자의 정당성을 주장하려면 어떻게 해야 할까요? 그 답은 포괄적이고 통합된 기술 솔루션을 포함하는 비즈니스 사례를 만드는 데 있습니다. 그렇다면 이렇게 통합된 모습은 어떨까요? 비즈니스 사례를 만드는 데 핵심적인 요소는 무엇일까요? IT 프로젝트의 정당성을 입증하기 위해서는 비즈니스 계획 모델을 어떻게 사용해야 할까요? 비즈니스 사례 안에 적절한 기술 솔루션을 통합할 때 고려해야 할 점은 무엇일까요? 지금부터 비즈니스 사례를 만들 때 고려해야 할 몇 가지 사항에 대해 이야기해 보겠습니다.

비즈니스 구축
성공적인 기업 또는 조직은 직원, 고객, 파트너, 공급업체, 소유자를 포함한 모든 이해 관계자에게 수량화할 수 있는 가치를 제공해야 합니다. 그리고 이 가치는 지속적인 조정과 개선을 통해 명확하게 정의되고 측정되어야 합니다.
고도로 네트워크화된 비즈니스 환경에서 기업은 내부 및 외부 작업자와 효율적인 공동 작업을 수행하여 관계의 상호 작용을 실시간으로 극대화할 수 있어야 합니다. 서비스나 질문에 대한 대답, 제품 배송 등을 기다리는 것을 좋아하는 사람이 있을까요? 통신 장애로 인해 프로젝트가 지연되거나 중단되는 일을 원하는 사람도 없겠지요. 인터넷의 등장과 빠른 속도로 진행되는 세계화의 추세에 따라 당장 우리 눈 앞에서 경쟁이 벌어질 수도 있고 저 멀리 다른 대륙에서 경쟁이 벌어질 수도 있습니다. 따라서 기업은 이처럼 경쟁적인 환경에서 차별화된 전략을 세워야 합니다. 어떻게 하면 다른 기업과 구별되는 기업이 될 수 있을까요?
또한 기업은 민첩해야 합니다. 내부 및 외부 환경을 항상 주시하고 있어야 하며 여러 가지 옵션 중에서 적절한 비즈니스 이니셔티브를 빠르게 선택하고 구현할 수 있어야 합니다. 기업은 이러한 과정에서 강점은 적극적으로 활용하고 약점은 보완함으로써 새로운 기회를 모색하게 됩니다. 그리고 이 기회를 통해 새로운 시장, 새로운 고객, 새로운 상품, 새로운 서비스와 함께 성장할 수 있습니다. 기업은 또한 경쟁업체의 압력을 비롯한 여러 위협 요소를 평가하고 이를 완화해야 합니다. 이 모든 것은 운영 비용과 위험을 관리하면서 생산성과 효율성 향상에 중점을 둘 때에 가능합니다.
기업은 기술 투자를 통해 이러한 능력을 키움으로써 조금이라도 빨리 시장에 진출하고 고객의 요구에 즉각적으로 대응할 수 있어야 하며, 경쟁업체의 위협을 예측하고 생산성과 효율성을 높이고 운영 비용과 위험을 줄일 수 있어야 합니다.
지금까지 성공적인 비즈니스를 위한 요소는 무엇인지, 어떤 방식으로 IT를 활용하여 해당 요소를 지원하고 보조 역할을 수행해야 하는지 알아보았습니다. 위와 같은 가정이 실현되지 않는다면 사실상 IT 비용은 정당성을 입증할 수 없는 불필요한 지출이 되고 맙니다. 비즈니스 계획 방식을 따르면 비즈니스 사례를 통해 성공적인 비즈니스를 수행할 수 있으며 이는 곧 IT 전략의 성공으로 이어집니다.

비즈니스 계획 수립
차별화, 비용 절감, 시장의 관심 분야, 공동 작업, 혁신과 같이 증대된 비즈니스 가치와 IT 투자를 연관 짓는 일은 무엇보다 중요합니다. 비즈니스 계획을 사용하여 접근하면 이러한 요구를 충족할 수 있습니다.
그림 1에는 IT 비즈니스 계획의 기본적인 요소가 설명되어 있습니다. 계획의 목표는 무엇입니까? 임무와 비전은 기업이 현재 어떤 모습을 하고 있으며 앞으로 어떤 모습이 되길 원하는지 설명하는 것입니다. 여러분은 IT 프로젝트가 이러한 목표를 어떻게 뒷받침하는지 명확하게 설명할 수 있어야 합니다. IT 투자와 비즈니스 목표 사이의 관계, 구체적으로는 IT 목표가 비즈니스의 전략적 방향을 어떻게 뒷받침하는지 하나하나 설명해야 합니다. 말하자면 IT와 비즈니스의 방향이 잘 맞아야 한다는 것입니다.
Figure 1 비즈니스 계획의 요소 (Close Figure 1)

요소 | 설명
목적 | 투자와 비즈니스 목표 사이의 관계 설명
비전 | 비즈니스 성과 및 IT를 통해 이러한 목표를 뒷받침하는 방법
임무 | 현재 비즈니스 및 IT를 통해 이러한 비즈니스 임무를 향상시키는 방법
비즈니스 기회 | 목표 시장과 비즈니스 가치
비즈니스 모델 | 비즈니스 기회를 잡기 위해 IT에서 제공되는 제품 또는 서비스
목표 시장 | 서비스를 제공할 고객 또는 잠재 고객
IT 통합 | 제품 및 서비스와 기술 리소스 간의 조화
경쟁력 분석 | 경쟁업체 및 강점과 약점이 나열된 목록
SWOT 분석 | 강점, 약점, 기회, 위협
리소스 분석 | 기존 인프라 및 필요할 것으로 예상되는 리소스
IT 전략의 성공을 가늠하는 척도 | 계획 중 측정 가능한 부분
재무 계획 | ROI 회수 기간
비즈니스 기회를 언급하는 부분에서는 IT를 통해 어떻게 새로운 비즈니스 기회를 창출 또는 지원할 수 있는지, 어떤 가치를 환원할 수 있는지 설명해야 합니다. 구체적인 비즈니스 모델은 무엇입니까? 매출이 증가하면 그에 대한 보답으로 어떤 제품과 서비스를 제공합니까? 잠재 시장의 규모는 얼마나 크고 IT 투자 개선으로 얻을 수 있는 효과는 얼마나 큽니까? IT로 인해 이 비즈니스 모델을 성장시킬 수 있는 방법은 무엇입니까? 언급된 비즈니스 모델 내에서 IT 투자를 통해 어떻게 워크플로 및 비즈니스 프로세스를 개선할 수 있는지 설명해야 합니다(운영 효율 개선, 비용 절감, 효율성 향상, 공동 작업 가능, 효율적인 통신, 일정 관리 및 메시징 등). 이 모두가 비용을 절감하고 생산성을 높이는 요소가 될 수 있습니다. IT를 활용하여 비즈니스 운영에 혁신을 이룰 수 있다는 사실을 강조해야 합니다.
더 나아가 목표 시장에 대해서도 설명해야 합니다. IT 계획을 통해 기존 목표 시장의 점유율을 높이거나 새로운 시장을 개척할 수 있는 방법을 생각해 보십시오. 어떤 시스템을 통해 제품과 서비스를 제공할 것인지, 어떤 방식으로 IT 지원을 활용하여 시장에 더 나은 제품과 서비스를 제공할 수 있을 것인지 논의하십시오.
이러한 논의는 곧 기업의 제품 또는 서비스가 IT 기술과 얼마나 효율적으로 통합되어 있는지 평가하는 과정으로 이어져야 합니다. 통합되고 단일화된 기술 플랫폼에 구체적으로 어떤 제품과 서비스가 결합됩니까? IT를 통한 제품 또는 서비스 지원은 어떤 방식으로 이루어집니까? 비즈니스 목표와는 어떻게 연결됩니까? 이러한 질문들은 IT를 통해 서비스 관리, 프로젝트 제공, 내부 및 외부 관계를 개선하는 방법을 제시할 수 있는 발판이 됩니다. IT는 기업을 변화시킬 수 있습니다. 서비스 수준에 대한 기대치를 높이고 관리, 우선 순위 설정, 규정 준수, 개인 정보 보호, 보안의 효과를 높일 수 있습니다. 이 모든 사항은 비즈니스 계획에서 언급되어야 합니다.
경쟁력 분석에는 기업이 처한 경쟁 환경에 대한 전반적인 분석이 포함되어야 합니다. 경쟁 상대는 누구입니까? 경쟁 상대의 강점과 약점은 무엇입니까? 경쟁업체는 어떻게 기술을 활용하는지, 어떻게 시장 점유율을 높이고 있는지 알아내십시오. IT로 인해 경쟁업체보다 유리한 위치를 차지하고 있습니까? 어떻게 하면 IT를 활용하여 기업의 민첩성을 높이고, 성장을 촉진하고, 새로운 시장에 빠르게 진출하고, 신규 고객을 지원하고, 기존 고객에 대한 서비스를 개선할 수 있는지 그 방법을 설명하십시오. 기술을 활용하여 기업을 차별화하고 경쟁력을 높일 수 있는 방법은 무엇입니까? IT를 통해 경쟁업체의 진입 장벽을 높이는 방법은 무엇입니까?
SWOT 분석은 기업의 강점, 약점, 기회 및 위협을 일정한 형식으로 보여 줍니다. 기업의 외부에 존재하는 기회 및 위협은 무엇입니까? IT를 통해 기업 내부의 강점을 개선하고 외부의 새로운 기회를 활용할 수 있는 방법은 무엇입니까? IT를 통해 기업 내부의 약점을 극복하고 이러한 노력의 결과로 새로운 기회를 획득할 수 있는 방법은 무엇입니까? IT 투자를 통해 외부의 위협을 줄이거나 완화할 수 있는 방법은 무엇입니까?
IT 투자를 실행하기 전과 그 후는 물론, 실행하는 과정에서도 IT 투자에 대한 리소스 요구 사항을 고려해야 합니다. 여기에는 인력, 하드웨어 및 인프라가 포함됩니다. 기존 지식 또는 인프라 중에서 활용할 수 있는 것은 무엇이고 추가로 예산을 확보해야 할 부분은 무엇입니까? 새로운 교육 또는 장비에 투자한 비용을 회수하는 데 드는 시간은 얼마입니까? 정해진 비즈니스 계획에는 포함되지 않는 내용이지만 새로운 투자로 인한 다른 이점을 알고 있는 경우 이에 대해서도 언급해야 합니다.
자신의 비즈니스 계획이 생각했던 기대치에 부합하는지 알아보려면 성공을 평가할 수 있는 기준을 미리 생각해 두어야 합니다. 계획에서 측정할 수 있는 부분은 무엇입니까? 성공 여부의 평가 빈도는 어느 정도이며, 목표를 효과적으로 뒷받침하지 못할 경우에는 어떤 조치를 취할 예정입니까? 예기치 않게 계획 데이터가 파괴될 경우에 대비해 어떤 백업 계획을 세워 놓았습니까?
재무 계획이 없는 비즈니스 계획은 결코 완벽할 수 없습니다. 총 소유 비용은 얼마이며 새로운 비즈니스 기회에서 그 비용의 정당성을 어떻게 입증할 수 있습니까? 그리고 이러한 기회의 가치는 얼마나 됩니까? 성공적인 비즈니스를 달성하는 과정에서 어디서 어떤 방법으로 ROI를 회수할 계획입니까? ROI 회수에 소요되는 기간은 얼마로 예상합니까? IT를 통해 매출과 수익성을 높이고 비용을 절감하여 기업의 재무 목표를 달성할 수 있는 방법은 무엇입니까?

결론
계획이 항상 실효를 거둘 것이라고 보장할 수는 없습니다. 하지만 비즈니스 계획에 대해 생각하고 개발하려는 노력만으로도 이미 여러분은 주도권을 쥐고 있는 것입니다. 앞으로 일어날 수 있는 문제에 대해 모두 생각해 본 다음 계획을 수정하거나 예기치 않은 상황에 대비하게 될 것입니다. 또한 계획을 추진하지 않을 때의 비용을 포함하여 계획과 관련된 모든 비용 및 이점을 명확하게 파악하게 될 것입니다. 마지막으로, 결과를 평가하는 데 사용할 일정한 기준이 없다면 계획이 성공한 것인지 형편없이 실패한 것인지 알 길이 없습니다. 정해진 평가 기준을 사용하면 상사에게 여러분의 계획이 비즈니스에 얼마나 긴요한 역할을 했는지 편리하게 검증할 수 있습니다.
IT 비즈니스에 대해 어떤 현안이 논의되고 있는지 살펴보려면 blogs.technet.com/cdnitmanagers의 IT Managers Connection을 참조하십시오. 또한 Microsoft 웹 사이트에서도 다양한 비즈니스 계획 관련 리소스를 이용할 수 있습니다. Small Business Center에서는 비즈니스 계획 작성에 관한 자습서(microsoft.com/smallbusiness/resources/startups/business_plans_ entities/how_to_write_a_business_plan.mspx)를 제공하고 있으며, Office Online(office .microsoft.com/en-us/templates)에서는 다양한 비즈니스 계획 템플릿과 2007 Microsoft Office system에 포함되어 있는 비즈니스 계획 템플릿을 제공하고 있습니다.

Stephen Ibaraki는 수상 경력을 자랑하는 비즈니스 테크놀로지 담당 교수로, 비즈니스와 IT 분야에서 35년 이상의 경력을 쌓은 베테랑이며 현재 국제 NPA(Network Professional Association) 부의장으로 재직 중입니다. 문의 사항이 있으시면 www.StephenIbaraki.com으로 연락하십시오.


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

보호되는 네트워크에 연결하는 액세스 클라이언트는 협상된 인증 방법을 사용하여 인증 서버의 확인을 받아야 합니다. 예를 들어 액세스 클라이언트와 인증 서버는 MS-CHAP v2(Microsoft Challenge Handshake 인증
프로토콜 버전 2)와 같은 특정 암호 인증 프로토콜을 사용하는 데 동의할 수 있습니다. 하지만 액세스 클라이언트와 인증 서버가 하드코드된 기본 제공 인증 방법을 사용하는 경우 새 프로토콜을 추가하기가 어렵습니다.
EAP(확장할 수 있는 인증 프로토콜)는 전화 접속 및 VPN과 같은 PPP(지점 간 프로토콜) 연결과 IEEE 802.1X 기반 무선 네트워크 등 많이 사용되는 보호되는 네트워크 액세스 기술의 인증 방법에 확장성을 제공하는 아키텍처 프레임워크입니다. EAP는 MS-CHAP v2와 같은 인증 방법이 아니라 네트워크 공급업체가 EAP 방법이라고 하는 새로운 인증 방법을 개발하고 쉽게 설치할 수 있게 하는 액세스 클라이언트 및 인증 서버의 프레임워크입니다. EAP에 대한 자세한 내용은 Microsoft EAP 웹 페이지(microsoft.com/eap)를 참조하십시오.
EAP는 Windows 2000부터 Microsoft® Windows®에서 지원되었으나 Windows XP 및 Windows Server® 2003에 포함된 EAP 아키텍처에는 특정 유형의 링크 계층에 EAP를 사용할 수 있는 소프트웨어 구성 요소인 신청자와 EAP 방법에 대한 확장성의 제한이 있었습니다. 그러나 Windows Vista™와 Windows Server의 차기 버전인 코드명 "Longhorn"에 포함된 EAPHost 아키텍처에서는 이러한 제한이 해결되어 타사 네트워크 공급업체가 새로운 신청자와 EAP 방법에 맞게 Windows를 더욱 쉽게 확장할 수 있습니다.

Windows Server 2003 및 Windows XP의 EAP 지원
Windows Server 2003과 Windows XP에서는 802.1X로 인증하는 유무선 연결과 전화 접속, VPN 기반 원격 액세스, 사이트 간 연결 등의 PPP 기반 연결에 EAP를 사용합니다. 특히 이러한 운영 체제는 RFC 2284를 준수하는 EAP의 구현을 포함하며 IEEE 802.1X 및 PPP 신청자를 포함합니다. 그림 1에서 Windows XP 및 Windows Server 2003의 EAP 및 신청자 아키텍처를 볼 수 있습니다. 하지만 Windows XP 서비스 팩 2(SP2)와 Windows Server 2003 SP1의 EAP 구현에서는 RFC 3748(EAP의 현재 인터넷 표준) 및 기타 EAP RFC를 지원하지 않습니다.
그림 1 Windows XP 및 Windows Server 2003의 EAP 및 신청자 아키텍처
그림 1 Windows XP 및 Windows Server 2003의 EAP 및 신청자 아키텍처
EAP API를 사용하면 Windows XP와 Windows Server 2003에서 인증을 확장할 수 있습니다. 타사 공급업체는 새 EAP 방법을 개발하고 설치할 수 있지만 기본 제공 PPP와 802.1X 신청자에서 이렇게 설치된 EAP 방법 중 일부를 사용하지 못할 수도 있습니다. 예를 들어 공급업체가 새로운 지문 인식 EAP 인증 방법을 만들어도 이 방법을 무선 연결에 사용하지 못할 수 있습니다.
기본 제공 신청자에는 이러한 제한이 있기 때문에 일부 타사 소프트웨어 및 하드웨어 공급업체에서는 일반적으로 기본 제공 신청자와 전체 EAP 아키텍처를 바꾸고 해제하는 자체 신청자를 개발합니다. 하지만 이러한 방법은 몇 가지 문제를 수반합니다. 우선 기본 제공 신청자와 EAP 아키텍처를 바꾸게 되면 개발 비용 문제가 생기므로 작업이 지연될 수 있습니다. 또한 기업 고객이 자체 신청자를 개발하지 않으면 라이선스에 대해 사용자 단위로 비용이 부과되고 타사 제품을 설치해야 할 수 있습니다.

EAPHost의 기능
EAPHost는 다음과 같은 새 기능을 제공합니다.
추가 EAP 방법 지원. EAPHost는 www.iana.org/assignments/eap-numbers의 EAP Registry에 나와 있는 모든 EAP 방법과 Cisco Systems, Inc에서 개발하여 공급하는 LEAP(Lightweight EAP) 등의 다른 유명 인증 방법의 설치와 사용을 지원합니다.
네트워크 검색. EAPHost는 RFC 4284의 정의에 따라 네트워크 검색을 지원합니다.
RFC 3748 준수. EAPHost는 EAP 상태 시스템을 준수하며 RFC 3748에 명시된 여러 보안 취약점을 해결합니다. 이전에는 신청자가 자체 상태 시스템을 구현해야 했습니다. 또한 EAPHost는 확장 EAP 유형(공급업체별 EAP 방법 포함)과 같은 기능을 지원합니다.
EAP 방법 공존. EAPHost에서는 동일한 EAP 방법의 여러 구현이 동시에 존재할 수 있습니다. 예를 들어 Microsoft 버전의 PEAP(Protected EAP)와 Cisco Systems, Inc. 버전의 PEAP를 모두 설치하여 선택할 수 있습니다.
모듈식 신청자 아키텍처. EAPHost는 이전 버전에서처럼 전체 EAP 구현을 바꿀 필요 없이 새로운 신청자를 쉽게 추가할 수 있는 모듈식 신청자 아키텍처를 지원합니다.
EAP 방법 공급업체의 경우 EAPHost를 사용하여 Windows XP 및 Windows Server 2003용으로 이미 개발된 EAP 방법을 지원할 수 있으며 Windows Vista 및 Windows Server "Longhorn"용의 새로운 EAP 방법을 더욱 쉽게 개발할 수 있습니다. 또한 EAPHost를 사용하면 EAP 유형을 더욱 정확하게 분류할 수 있으므로 기본 제공 IEEE 802.1X 신청자가 EAP를 사용할 수 있습니다.
신청자 공급업체의 경우 EAPHost를 사용하여 새 링크 계층에 대한 추가 신청자를 제공할 수 있습니다. EAPHost는 NAP(네트워크 액세스 보호)와 통합되어 있으므로 새 신청자에 NAP 인식 기능이 없어도 됩니다. 새 신청자는 연결 식별자를 등록하고 신청자에 다시 인증하도록 알리는 콜백 함수를 등록하기만 하면 NAP에 참가할 수 있습니다. NAP에 대한 자세한 내용은 TechNet Magazine의 이번 호에서 John Morello가 기고한 Security Watch 칼럼과 microsoft.com/nap의 NAP 웹 페이지를 참조하십시오. EAPHost용 신청자나 EAP 방법을 개발하는 방법에 대한 자세한 내용은 msdn2.microsoft.com/aa364249.aspx에서 Extensible Authentication Protocol Host를 참조하십시오.

EAPHost 및 EAP 인프라 아키텍처
EAPHost 아키텍처는 EAPHost의 EAP 인프라 아키텍처, EAP 피어(인증 클라이언트)의 EAPHost 아키텍처 및 인증 서버의 EAPHost 아키텍처로 구성됩니다. 그림 2에서는 Windows Vista 또는 Windows Server "Longhorn" 컴퓨터의 EAPHost에 대한 EAP 인프라 아키텍처의 구성 요소를 보여 줍니다. 이들 운영 체제의 경우 EAP 피어에는 신청자 계층(예: 802.1X용 기본 제공 신청자), EAP 피어를 위한 새로운 EAPHost 아키텍처(신청자와 EAP 방법의 통신과 관리 지원) 및 인증을 수행할 EAP 방법 계층이 있습니다.
그림 2 EAPHost의 EAP 인프라 아키텍처
그림 2 EAPHost의 EAP 인프라 아키텍처
Windows Server "Longhorn"용 인증 서버에는 인증 서버를 위한 새로운 EAPHost 아키텍처인 NPS(네트워크 정책 서버)와 EAP 방법 계층이 있습니다. Windows Server 2003에서 인터넷 인증 서비스(IAS)로 알려진 NPS는 RADIUS(Remote Authentication Dial-In User Service) 서버와 프록시 및 NAP용 정책 서버입니다.
EAP 피어의 신청자는 PPP 또는 802.1X와 같은 링크 계층 기술을 사용하여 EAP 피어와 통과 인증자(무선 액세스 지점 또는 원격 액세스 서버와 같은 네트워크 액세스 서버) 간의 링크에서 EAP 메시지를 보내고 받습니다. 통과 인증자와 인증 서버의 NPS는 RADIUS를 사용하여 통과 인증자와 NPS 사이의 IP 기반 네트워크를 통해 EAP 메시지를 보내고 받습니다.
EAP 피어와 인증 서버가 특정 EAP 방법의 사용을 협상한 후 논리적 통신은 EAP 피어의 협상된 EAP 방법과 인증 서버 사이에 전송되는 EAP 메시지로 이루어집니다.
그림 3에서는 Windows Vista 또는 Windows Server "Longhorn"이 실행되는 EAP 피어의 EAPHost 아키텍처를 보여 줍니다. 이 아키텍처는 신청자, EAPHost 구성 요소, EAP 방법 관리 구성 요소 및 NAP 구성 요소로 구성됩니다.
그림 3 EAP 피어의 EAPHost 아키텍처
그림 3 EAP 피어의 EAPHost 아키텍처
Windows Vista 및 Windows Server "Longhorn"에는 802.1X 기반 유무선 연결을 위한 802.1X 신청자가 포함되어 있습니다. 전화 접속이나 VPN 기반 원격 액세스 또는 사이트 간 연결을 위한 PPP 신청자는 이 두 운영 체제의 향후 업데이트를 위해 계속 연구 중입니다. 타사에서 개발된 다른 신청자가 추가될 수도 있습니다. EAPHost API를 사용하면 이러한 신청자가 연결에 EAP를 사용할 수 있습니다. 자세한 내용은 msdn2.microsoft.com/aa364249.aspx의 기사를 참조하십시오.
EAPHost 구성 요소에는 EAP 피어 상태 시스템(RFC 3748 참조)을 유지 관리하고 EAP 메시지의 유효성을 검사하는 EAP 클라이언트 상태 시스템/프로토콜 유효성 검사기가 포함되어 있습니다. 또한 EAPHost 호환 여부에 관계없이 여러 EAP 방법을 관리하며 응용 프로그램과 서비스에서 EAP 방법을 사용할 수 있도록 돕는 EAP 방법 관리자도 포함되어 있습니다. 마지막으로 EAP 방법 라이브러리를 쉽게 로드하고 언로드할 수 있도록 도와 주는 EAP 라이브러리 관리자도 있습니다.
EAP 방법 구성 요소는 다음과 같습니다.
기본 제공 EAP 방법. 여기에는 PEAP, EAP-TLS(전송 계층 보안) 및 EAP-MS-CHAP-V2 등이 있습니다.
두 개의 호스트 API. EAPHost 비호환 EAP 방법(레거시 EAP API)과 타사 EAPHost 호환 EAP 방법(EAPHost 방법 API)을 호스트합니다.
레거시 변환기 방법. 레거시 EAP API에 기록되어 있는 EAPHost 비호환 EAP 방법과 EAPHost 방법 API 간을 변환합니다.
EAP 방법 프록시 관리자 . EAPHost와 호환되는지 여부에 관계없이 타사 EAP 방법을 호스트합니다.
EAP 방법 API는 EAPHost 호환 EAP 방법을 위한 새로운 API입니다. EAP 방법은 EAP 방법 API에 정의되어 있는 API를 내보냅니다. EAPHost에서는 EAP 방법을 로드하고 내보낸 API 함수를 호출합니다.
NAP 구성 요소에는 다음 항목이 포함되어 있습니다.
EAP NAP EC 메신저 . 이 구성 요소를 사용하면 EAPHost NAP EC(적용 클라이언트)와 기타 EAPHost 구성 요소 간에 상태 설명 및 이벤트 등과 같은 NAP 관련 데이터를 쉽게 주고받을 수 있습니다.
EAPHost NAP EC . 이 구성 요소는 다른 NAP 구성 요소와 상호 작용하여 802.1X로 인증된 연결이 NAP 시스템 상태 요구 사항을 충족하지 못하는 경우 상태 유효성 검사와 제한된 액세스 적용 기능을 제공합니다.
NAP 에이전트. 클라이언트의 현재 상태를 유지 관리하는 구성 요소로 이 구성 요소를 사용하면 설치된 NAP EC 및 SHA(System Heath Agent) 계층 간에 원활하게 통신할 수 있습니다. 각 SHA는 하나 이상의 시스템 상태 요구 사항에 대해 정의됩니다.
그림 3에 나와 있는 것과 같이 타사 공급업체에서는 신청자와 EAPHost 호환 EAP 방법을 새로 개발할 수 있습니다. 또한 Windows Server 2003이나 Windows XP용으로 개발된 기존 EAP 방법도 사용할 수 있습니다.
그림 4에서는 Windows Server "Longhorn" 및 NPS가 실행되는 인증 서버의 EAPHost 아키텍처를 보여 줍니다. 이 아키텍처는 EAP 방법을 지원하기 위한 EAP 피어의 아키텍처와 동일합니다. 인증 서버에는 EAPHost API를 사용하여 EAP 방법을 사용하고 구성하는 NPS가 신청자 대신 존재합니다. EAP 구성 요소 내에서 EAP 서버 상태 시스템/프로토콜 유효성 검사기는 EAP 인증 서버 상태 시스템의 유지 관리와 수신 EAP 메시지의 유효성 검사 작업을 수행합니다.
그림 4 인증 서버의 EAPHost 아키텍처
그림 4 인증 서버의 EAPHost 아키텍처
타사 소프트웨어 공급업체는 인증 서버의 EAPHost를 사용하여 새로운 EAPHost 호환 EAP 방법을 개발 및 설치하고 Windows XP와 Windows Server 2003용으로 이미 개발된 EAP 방법을 지원할 수 있습니다.
또한 EAPHost는 EAP 피어와 인증 서버 모두에 EAPHost UI 프록시 API(그림 3과 4에는 나와 있지 않음)를 제공합니다. EAPHost 호환 방법에서 이 API를 사용하여 사용자 상호 작용이 필요한 대화 상자를 표시할 수 있습니다. 타사 공급업체는 보다 원활한 사용자 환경을 위해 EAPHost UI 프록시 API를 사용하여 자체적인 대화 상자를 추가할 수 있습니다.

°á·Ð
Windows Server "Longhorn"과 Windows Vista의 EAPHost는 최신 인터넷 표준에 맞게 Windows의 EAP 구현을 업데이트하며 EAP 인증 방법과 신청자를 사용하여 Windows를 확장하기 위한 새로운 모듈식 아키텍처를 제공합니다. 네트워킹 공급업체는 EAPHost API에 기록되는 새로운 신청자와 EAPHost 방법 API에 기록되는 새로운 인증 방법을 개발하여 전체 Windows EAP 구현을 바꾸지 않고도 Windows의 기존 사용자 환경을 확장할 수 있습니다. 또한 EAPHost는 Windows Server 2003과 Windows XP용으로 개발된 기존 EAP 방법도 지원합니다.
Windows XP용 EAPHost
Microsoft는 EAPHost 아키텍처, RFC 3748 지원 및 유선 802.1X 연결을 위한 EAPHost 기반 신청자가 포함된 Windows XP SP2용 업데이트를 발표할 계획입니다. 이 업데이트를 통해 Windows Vista용으로 개발된 EAPHost 신청자가 Windows XP SP2에서도 작동하게 됩니다. 이 업데이트에 대한 최신 정보는 blogs.technet.com/nap의 NAP 제품 팀 블로그를 참조하십시오.

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


 Windows PowerShell: WMI 연결
Windows PowerShell
WMI 연결
Don Jones

필자가 VBScript에서 가장 많이 의존한 기술 중 하나는 WMI(Windows Management Instrumentation)였습니다. 그런데 흥미롭게도 Windows PowerShell은 WMI에 강력하게 연결되며 이는 기술적인 이유 때문만은 아닙니다. Windows PowerShell을 설계한 Jeffrey Snover는
WMI로 작업할 때 사용하는 Windows Server® 2003 명령줄 도구인 Wmic.exe의 개발에도 큰 역할을 했습니다. Wmic.exe는 작동 방식이 비슷하다는 측면에서 Windows PowerShell™의 전신이라고 할 수 있습니다. WMIC에 대한 자세한 내용은 John Kelbley가 TechNet Magazine 2006년 9월호에 게재한 기사(microsoft.com/technet/technetmag/issues/2006/09/WMIData)를 참조하십시오.
Windows PowerShell의 WMI 지원은 이 셸의 다른 기능과 마찬가지로 일관된 개체 지향적 방식에 따라 제공됩니다. 이런 이유 때문에 WMI는 VBScript와 같은 이전 기술보다 쉽게 배우고 사용할 수 있습니다. 특히, 애드혹 환경에서는 더욱 그렇습니다.

WMI 기초
스크립팅 서적이나 기사를 읽다 보면 거의 빠짐없이 WMI가 언급됩니다. 하지만 실제로 WMI를 사용할 때는 혼동하기 쉽기 때문에 내부적인 구성 방식을 잊어버리는 경우가 많습니다. 이 구성 방식은 Windows PowerShell에서 작동하는 방식에 있어서 특히 중요합니다.
WMI는 기본적으로 Windows® 운영 체제와 기타 Windows 기반 하드웨어 및 소프트웨어 제품의 관리 정보를 나타내는 클래스로 구성된 시스템입니다. 클래스는 실제로 특정 소프트웨어나 하드웨어 구성 요소의 속성과 기능에 대한 요약 설명일 뿐입니다. 예를 들어 논리 디스크 클래스는 일련 번호, 고정된 저장 용량, 사용 가능한 용량 등이 있는 장치를 설명할 수 있습니다. 또한 Windows 서비스를 설명하는 클래스는 서비스의 이름 유무 여부, 시작 및 중지 가능 여부 및 현재 상태 등을 지정할 수 있습니다.
WMI에서 클래스는 WMI가 관리할 수 있는 모든 대상을 나타냅니다. 특정 대상에 대한 클래스가 없으면 WMI는 해당 구성 요소를 관리할 수 없습니다. 핵심 Windows WMI 클래스에 대한 문서는 msdn2.microsoft.com/aa394554.aspx에서 볼 수 있으며 인터넷 정보 서비스, SQL Server™ 등과 같은 다른 제품에서는 자체 WMI 클래스에 대한 별도의 문서를 제공합니다.
클래스는 매우 많기 때문에 WMI에서는 클래스를 네임스페이스의 계층 구조로 구성합니다. 예를 들어 핵심 Windows OS 클래스를 포함하는 네임스페이스는 root\cimv2이지만 Microsoft IIS 6.0에서는 자체 클래스를 root\MicrosoftIISv2에 저장합니다. 편의상 root\cimv2 네임스페이스가 WMI 기본 네임스페이스로 사용되며 이 설정은 Windows PowerShell에서 공유됩니다. 따라서 이를 통해 해당 코어 클래스를 쉽게 사용할 수 있습니다.
"인스턴스"는 클래스의 실질적인 실제 발생을 나타냅니다. 예를 들어 두 개의 논리 디스크가 있는 컴퓨터에는 Win32_LogicalDisk 클래스의 인스턴스가 두 개가 있습니다. 컴퓨터에서 실행 중인 서비스가 50개이면 WMI는 50개의 Win32_Service 클래스 인스턴스를 인식합니다. WMI를 사용하는 작업은 기본적으로 WMI에 하나 이상의 인스턴스를 요청한 다음 해당 인스턴스의 속성을 검사하여 필요한 관리 정보를 찾거나 해당 인스턴스의 메서드를 실행하여 서비스 시작이나 중지 등의 관리 변경을 수행하는 방식으로 수행됩니다.
WMI는 클라이언트-서버 아키텍처를 사용합니다. Windows 2000 이후에 나온 모든 버전의 Windows에서는 WMI를 기본 제공하기 때문에(이후 버전에서는 사용 가능한 클래스 수가 늘어났음) WMI 클라이언트와 WMI 서버 소프트웨어 모두를 사용할 수 있습니다. WMI를 사용할 때는 실제로 관심 있는 컴퓨터에서 실행 중인 WMI 서비스에 요청을 전송합니다. 그러면 사용자가 지정한 WMI 인스턴스를 해당 WMI 서비스가 검색한 다음 사용자가 작업할 수 있도록 반환합니다. 이 단계에서 Windows PowerShell이 개입하여 인스턴스를 요청하고 가져와서 이를 사용하여 작업하는 프로세스를 단순화합니다.

WMI 개체 가져오기
WMI 클래스 인스턴스는 넓은 의미에서 개체라고도 합니다. 이를 감안하면 Windows PowerShell에서 이러한 인스턴스를 검색하는 방법이 Get-WMIObject cmdlet라는 점을 납득할 수 있습니다. 이 cmdlet에는 사용하기 편리한 별칭인 gwmi가 있는데 이 기사의 예제 대부분에서 이 별칭을 사용합니다. 가장 간단한 형식을 예로 들자면, 검색할 WMI 클래스 이름을 지정한 다음 결과를 보기만 하면 됩니다(그림 1 참조). gwmi win32_service를 실행한 경우 여기에는 별도로 지정된 컴퓨터나 네임스페이스가 없기 때문에 Windows PowerShell은 사용자 로컬 컴퓨터의 WMI 서비스에 연결되어 root\cimv2 네임스페이스에 연결됩니다. Windows PowerShell은 지정된 클래스의 모든 인스턴스를 검색하며, 해당 인스턴스에 대해 수행할 작업을 지정하지 않았으므로 이를 텍스트 표현으로 변환합니다. 즉, Windows PowerShell이 해당 개체를 가져와서 사람이 읽을 수 있는 텍스트로 변환합니다.
그림 1 gwmi win32_service를 실행하는 경우 Windows PowerShell은 지정된 클래스의 모든 인스턴스를 사람이 읽을 수 있는 텍스트 형식으로 반환합니다.
그림 1 gwmi win32_service를 실행하는 경우 Windows PowerShell은 지정된 클래스의 모든 인스턴스를 사람이 읽을 수 있는 텍스트 형식으로 반환합니다.
특히, Windows PowerShell은 선택된 클래스 속성의 이름과 값을 읽고 표시하는 방식으로 WMI 개체를 텍스트로 변환합니다. Win32_Service 클래스의 경우에는 6개 속성 집합을 선택합니다.
실제로 Windows PowerShell은 이런 방식으로 모든 개체를 텍스트로 변환합니다. 표시를 위해 선택하는 속성은 대부분 Windows PowerShell 설치 폴더에 있는 .format.ps1xml 파일 집합에서 정의됩니다. 이러한 형식 정의 파일에는 Microsoft의 디지털 서명이 되어 있습니다. 자체 형식 지정 파일을 제공할 수도 있지만 이러한 파일은 변경하지 않는 것이 좋습니다. 이 내용에 대해서는 이후의 칼럼에서 자세히 다루겠습니다.
gwmi cmdlet를 사용하면 컴퓨터에서 사용 가능한 클래스를 찾아낼 수 있습니다. 예를 들어 gwmi –namespace "root\cimv2" –list를 실행하면 해당 네임스페이스에 있는 전체 클래스 목록을 가져올 수 있습니다. 하지만 컴퓨터에 있는 클래스는 자신의 컴퓨터를 관리하는 경우에만 유용하다는 점을 유의하십시오. 즉, 원격 컴퓨터를 관리할 때는 해당 시스템에서 사용 가능한 클래스를 찾아야 합니다. 이렇게 하려면 gwmi의 –computer 매개 변수를 사용하여 원격 컴퓨터에 연결하면 됩니다. 예를 들어 gwmi –namespace "root\cimv2" –list –computer ServerA를 사용하면 ServerA라는 원격 컴퓨터에 있는 root\cimv2 네임스페이스의 모든 클래스가 나열됩니다.

원격 WMI
Windows PowerShell 버전 1.0에서 gwmi는 원격 관리를 직접 지원하는 유일한 cmdlet입니다. 이에 대한 주된 이유는 원격 제어가 기본 WMI 아키텍처에 내장되어 있기 때문입니다. 또한 Windows PowerShell은 기존 아키텍처를 단순히 활용하기 때문에 해당 아키텍처의 보안 기능에 종속됩니다. 다음 예제를 보십시오.
C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>
이 인스턴스에서는 액세스 권한이 없는 원격 컴퓨터인 MediaServer로의 연결을 시도합니다. 관리자는 이 컴퓨터의 WMI 서비스를 사용할 수 있는 권한을 갖고 있어야 하지만 로컬 워크스테이션 자격 증명이 충분하지 않을 수 있습니다. 예를 들어 신뢰되지 않은 다른 도메인에 로그인되어 있거나 권한이 낮은 계정으로 로그온했을 수 있습니다. 다행히 gwmi에서는 WMI 연결에 사용할 대체 사용자 자격 증명을 지정할 수 있는 –credential 매개 변수를 지원합니다. 아래의 간단한 예제를 살펴보겠습니다.
gwmi win32_service –credential mydomain\administrator –computer mediaserver
여기서 자격 증명, 더 구체적으로 말해 사용자 이름은 도메인\사용자 이름 형식으로 지정됩니다.
암호를 입력할 수 있는 방법은 없으며 Windows PowerShell이 암호 입력 메시지를 표시하게 됩니다. 명령줄에 암호를 입력할 수 있으면 암호를 스크립트 파일에 하드 코딩하여 보안 위험을 초래할 수 있기 때문에 Windows PowerShell에서는 의도적으로 명령줄에서 암호를 입력하는 방법을 제공하지 않습니다. 하지만 PSCredential이라고 하는 일종의 자격 증명 개체를 미리 만들어 이 –credential 매개 변수를 사용할 수도 있습니다. 여기서의 핵심은 Get-Credential cmdlet입니다.
$cred = get-credential mydomain\administrator
이 코드를 실행하더라도 암호를 묻는 메시지는 여전히 나타납니다. 하지만 이 경우에는 생성되는 자격 증명 개체가 $cred 변수에 저장됩니다. $cred의 내용을 보면 이름은 보이지만 암호는 보이지 않습니다.
PS C:\> $cred

UserName
--------
mydomain\adminstrator
위 코드를 실행한 후에는 아래 코드를 사용하여 이 자격 증명 개체를 필요할 때마다 다시 사용할 수 있습니다.
gwmi win32_service –credential $cred –computer mediaserver
이렇게 하면 재사용 가능한 자격 증명 개체를 미리 정의하여 원격 컴퓨터로의 반복적인 WMI 연결을 단순화할 수 있습니다. 하지만 현재 Get-WMIObject cmdlet는 VBScript에서 지원하는 것과 동일한 방법의 인증 수준 지정은 지원하지 않는다는 점을 유의해야 합니다. 자세한 내용은 msdn2.microsoft.com/aa389290.aspx를 참조하십시오.

자체 검색
Windows PowerShell의 장점 중 하나는 모든 항목에 대해 검색이 가능하다는 점입니다. Windows PowerShell이 사용자가 쿼리한 Win32_Service 클래스에 대한 속성 집합만 선택하는 방법에 대해 앞에서 살펴봤습니다. 하지만 이 경우에도 셸은 여전히 모든 속성에 액세스할 수 있으며 이러한 속성에 대해 보여 줍니다. 이렇게 하려면 그림 2에서처럼 개체를 Get-Member cmdlet(또는 별칭인 gm)에 연결하기만 하면 됩니다.
그림 2 개체를 Get-Member cmdlet에 연결하면 액세스할 수 있는 메서드와 속성이 표시됩니다.
그림 2 개체를 Get-Member cmdlet에 연결하면 액세스할 수 있는 메서드와 속성이 표시됩니다.
또한 셸은 속성 이외 사용 가능한 메서드의 목록도 나열하기 때문에 문서를 찾아보지 않아도 클래스의 역할을 알 수 있습니다. 따라서 인스턴스의 구성을 변경하고, 서비스를 일시 중지 및 중지하는 등의 작업을 수행할 수 있는 방법을 클래스 자체에서 제공합니다.
이러한 메서드를 사용하거나 다른 속성을 표시하려면 인스턴스를 변수에 넣는 것이 가장 쉬운 방법일 때가 많습니다.
$server = gwmi win32_operatingsystem
$server.reboot()
이 샘플에서는 Win32_OperatingSystem 클래스(컴퓨터당 하나의 인스턴스만 있는 클래스)의 유일한 사용 가능 인스턴스를 검색하여 $server 변수에 저장합니다. 그런 다음 $server 변수를 사용하여 인스턴스의 Reboot 메서드에 액세스함으로써 컴퓨터를 재부팅합니다. 이 샘플을 사용하실 때는 주의하시기 바랍니다.

풍부한 쿼리 언어
VBScript나 다른 기술을 통해 WMI를 사용해온 사용자는 WQL(WMI Query Language)로 작성한 쿼리를 사용하여 WMI 클래스 인스턴스를 검색하는 것에 익숙할 것입니다. 이 경우 구문이 SQL과 비슷하기 때문에 특정 클래스의 모든 인스턴스를 검색하는 대신 특정 서비스 같은 특정 인스턴스를 쉽게 검색할 수 있습니다. 다행히 gwmi에서는 다음과 같이 쿼리를 지정할 수 있습니다.
gwmi –query “select * from win32_service where name=’alerter’”
Windows PowerShell이 정식 발표되기 직전에 추가된 gwmi의 이 구문은 매우 유용하며 이 구문을 사용하면 다른 용도로 개발한 복잡한 WMI 쿼리를 아주 쉽게 마이그레이션할 수 있습니다. 또한 Windows PowerShell은 자체 속성과 메서드가 있는 풍부한 개체를 반환하기 때문에 WMI의 관리 기능을 완전히 액세스할 수 있습니다.

WMI 진행 상황
WMI는 Windows 차기 버전용으로 계속 개발되고 있으며 새로운 클래스와 기능이 추가되고 있습니다. 또한 새로운 Microsoft 제품에 계속 추가되고 있습니다. 아직 Windows PowerShell을 기반으로 개발된 Microsoft 제품 버전이 많지는 않지만 WMI 연결 기능은 Windows PowerShell의 가장 유용한 이점 중 하나입니다.
지금까지 WMI로 할 수 있는 여러 작업 중 극히 일부만 소개했습니다. 이 글을 통해 Windows PowerShell에 관심을 가지고 직접 이용하면서 어떤 기능을 사용할 수 있는지 알아보는 계기가 되었으면 좋겠습니다.

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


 Hey, Scripting Guy!: 봄바람 속에 꽃은 피고, 대화 상자는 열리고
Hey, Scripting Guy!
봄바람 속에 꽃은 피고, 대화 상자는 열리고
Microsoft Scripting Guys

드디어 봄이 왔습니다. 이렇게 반가울 수가 없네요. 지난 겨울 미국에는 기록적인 폭우와, 진눈깨비, 눈보라, 폭풍 등이 할퀴고 지나갔습니다. 한 Scripting Guy의 집에서도 뒷마당의 큰 나무가 쓰러졌는데, 다행히 건물을 살짝 빗나가긴 했지만 Scripting Guy가 키우는 개가 놀라 소파 밑으로 피하기도 했지요. 그런데 이제 봄이 온 것입니다. 태평양 북서쪽에서 후덥지근한 비가 몰려 오는 여름이 되기 전에 지금은 다소 시원한 비를 만끽하고 있답니다.
창밖에 내리는 이슬비를 보면서 저희 팀은 이번에 스크립팅에서 다소 모험심을 발휘하여 HTA(HTML 응용 프로그램)를 다루면 좋겠다는 생각을 했습니다. 여기서 모험심이란 절대 빈말이 아닙니다. 무언가 새로운 것을 소개하지는 않겠습니다. 여기에서는 독자 여러분이 HTA의 정의와 생성 방법을 이미 알고 계신 것으로 간주하겠습니다. 혹시 HTA를 잘 모르신다면 스크립트 센터의 HTA 개발자 센터를 확인해 보시기 바랍니다. 특히 HTA 초보자 섹션에 있는 두 개의 기사는 매우 유용할 것입니다. 문서를 다 읽은 후 여기로 다시 돌아오면 됩니다.
이 칼럼에서는 대화 상자를 생성하는 방법을 설명합니다. 뿐만 아니라 기본 HTA와 대화 상자 간에 정보를 주고받는 방법에 대해서도 설명할 것입니다. 상큼한 봄바람 덕분에 저희 팀 모두 의욕이 넘치는 것 같습니다. 언제까지 계속될지는 모르지만 당분간은 마음껏 즐겨 보세요!
이미 알고 계신 분도 있겠지만 대화 상자는 모달 방식과 모덜리스 방식으로 구분됩니다. 모달 방식 대화 상자의 경우 대화 상자를 열었던 기본 창으로 돌아가려면 해당 대화 상자를 닫아야 하지만, 모덜리스 방식의 대화 상자의 경우에는 여러 창 간에 자유롭게 이동할 수가 있습니다. 그러나 기본 창을 닫으면 모덜리스 대화 상자도 닫힙니다.
모달 대화 상자를 생성하는 방법은 모덜리스 대화 상자를 생성하는 방법과 똑같습니다. 유일한 차이점은 모달 대화 상자를 생성할 때는 ShowModalDialog 함수를 호출하지만 모덜리스 대화 상자를 생성할 때는 ShowModelessDialog 함수를 호출한다는 점입니다. 그러나 두 함수 모두 동일한 매개 변수를 사용합니다. 우선 모달 방식의 대화 상자를 여는 간단한 HTA부터 살펴보겠습니다(그림 1 참조).
Figure 1 간단한 시작용 대화 상자 (Close Figure 1)
<html>
<head>
<title>Modal Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”MainModal”>
</head>

<script language=”VBScript”>
Sub ShowDialog
 intReturn = _
    ShowModalDialog(“modaldialog.hta”)
 textbox.Value = intReturn
End Sub
</script>

<body>
<button onclick=”ShowDialog”>
 Show Dialog Box</button> <p>
<input type=”text” name=”textbox”>
</body>
</html>
여기서는 Modal Example이라는 제목의 HTA를 만들어 보았습니다. 이 HTA의 <본문> 영역에는 Show Dialog Box라는 단추와 textbox라는 입력란을 추가했습니다. 이 두 요소 모두 그림 2에 나와 있습니다. 이제 단추를 클릭하면 ShowDialog 서브루틴이 실행됩니다.
그림 2 실제 HTA 모달 대화 상자
그림 2 실제 HTA 모달 대화 상자
ShowDialog 서브루틴은 매우 간단합니다. ShowModalDialog 함수를 호출하여 모달 대화 상자로 표시하려는 HTA 파일의 이름(여기서는 modaldialog.hta)을 매개 변수로 전달하는 것입니다.(여기서 modaldialog.hta는 이 HTA와 같은 폴더에 있는 것으로 간주됩니다. 같은 폴더에 있지 않으면 전체 파일 경로를 여기에 포함해야 합니다.)
이제 ShowModalDialog의 반환 값(intReturn)을 캡처하여 입력란에 표시합니다. 이 반환 값을 가져오는 방법은 잠시 후에 설명하겠습니다. 한 가지 명심할 사항은 ShowModalDialog에 대한 호출이 반환되도록 하려면 모달 대화 상자를 닫아야 한다는 사실입니다. 즉, 대화 상자를 닫아야 반환 값이 입력란에 할당됩니다.
이번에는 호출하는 HTA가 여는 대화 상자인 modaldialog.hta를 살펴보겠습니다(그림 3 참조). 이 HTA에서는 listbox라는 목록 상자와 OK라는 레이블이 있는 단추를 만들었습니다(그림 4 참조). 그리고 이 목록 상자에 Option 1, Option 2 같은 이름의 항목을 네 개 추가하고 각 항목에 1에서 4까지 값을 지정했습니다. OK 단추를 클릭하면 CloseWindow 서브루틴이 실행됩니다.
Figure 3 modaldialog.hta (Close Figure 3)
<html>
<head>
<title>Modal Dialog Box</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModalDialog”>
</head>

<script language=”VBScript”>
Sub CloseWindow
  window.returnValue = listbox.Value
  window.Close
End Sub
</script>

<body>
<select size=”3” name=”listbox”>
 <option value=”1”>Option 1</option>
 <option value=”2”>Option 2</option>
 <option value=”3”>Option 3</option>
 <option value=”4”>Option 4</option>
</select>
<p>
<input type=”button” id=”idBtn” value=”OK” onclick=”CloseWindow”>
</body>
</html>
그림 4 모달 방식 대화 상자를 나타내는 HTA
그림 4 모달 방식 대화 상자를 나타내는 HTA
CloseWindow 서브루틴도 매우 간단합니다. 우선 목록 상자에서 선택된 항목의 값을 읽어 window.returnValue 속성에 이 값을 지정합니다. 예를 들어 사용자가 Option 2를 선택한 경우 값 2가 window.returnValue에 지정되는 것입니다. 그런 다음 window.Close 메서드를 호출하여 대화 상자를 닫으면 됩니다.
바로 이때 컨트롤이 기본 HTA로 반환됩니다. ShowModalDialog에 대한 호출을 기억하시죠?
intReturn = _
  ShowModalDialog(“modaldialog.hta”)
intReturn에 지정된 반환 값은 대화 상자 HTA의 window.returnValue에 지정한 값입니다. 따라서 대화 상자에서 Option 2를 선택하면 값 2가 window.returnValue에 지정되고 intReturn은 2가 됩니다. 그리고 다음과 같은 코드 줄이 해당 값을 입력란에 표시합니다.
textbox.Value = intReturn
지금까지 대화 상자에서 값을 가져오는 방법을 살펴보았으니 이제 대화 상자로 값을 가져오는 방법을 설명하겠습니다. 이번에는 모덜리스 대화 상자(그림 5 참조)를 사용할 것입니다. 모달 방식과 모덜리스 방식 모두 작동 방식이 같기 때문에 모달 대화 상자에서 사용한 것과 동일한 프로세스를 적용할 수 있습니다.
Figure 5 모덜리스 방식 (Close Figure 5)
<html>
<head>
<title>Modeless Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModelessMain”>
</head>

<script language=”VBScript”>
Sub ShowDialog
  intReturn = _
    window.ShowModelessDialog _
    (“modelessdialog.hta”, _
    lstServers.Value, _
    “dialogHeight:400px;dialogWidth:300px”)
End Sub
</script>

<body>
<select size=”1” name=”lstServers”>
 <option value=”server1”>Server1</option>
 <option value=”server2”>Server2</option>
 <option value=”server3”>Server3</option>
 <option value=”server4”>Server4</option>
</select>
<p>
<input type=”button” value=”Retrieve Processes” onclick=”ShowDialog”>
</body>
</html>
그림 7 모덜리스 대화 상자에 전달된 데이터
그림 7 모덜리스 대화 상자에 전달된 데이터
이번에는 lstServers라는 이름의 한 항목 드롭다운(크기가 1과 같으므로 한 항목 드롭다운이라고 할 수 있음) 목록 상자를 만들었습니다. 여기에는 Retrieve Processes라는 레이블이 있는 단추도 있습니다. 이 단추를 클릭하면 ShowDialog 서브루틴이 실행됩니다. 이 ShowDialog 서브루틴에는 아래와 같이 window.ShowModelessDialog 함수에 대한 호출 한 줄만 있습니다.
intReturn = _
  window.ShowModelessDialog _
  (“modelessdialog.hta”, _
  lstServers.Value, _
  “dialogHeight:400px;dialogWidth:300px”)
이 함수에 전달하는 첫 번째 매개 변수는 대화 상자에서 실행하려는 HTA의 이름(여기서는 modelessdialog.hta)입니다. 두 번째 매개 변수는 목록 상자의 Value 속성입니다. Value 속성에는 목록 상자에서 선택한 옵션의 값이 포함되어 있습니다. 따라서 사용자가 목록 상자에서 Server2를 선택하면 Value는 server2가 됩니다. 이 매개 변수를 통해 대화 상자에 정보를 전달하게 됩니다. 값을 여러 개 전달하려는 경우 이 매개 변수에서 배열 또는 컬렉션의 형태로 전달할 수 있습니다.
대화 상자가 이 매개 변수의 값을 받는 방식은 잠시 후에 살펴보겠습니다. 지금은 우선 세 번째 매개 변수를 설명하겠습니다.
“dialogHeight:400px;dialogWidth:300px”
이 매개 변수에는 만들려는 대화 상자의 높이와 너비를 지정하는 문자열이 들어 있습니다. 여기서는 높이를 400픽셀(400px), 너비를 300픽셀로 지정했습니다. 모달 방식 예에서도 보았듯이 이 매개 변수는 비워 둘 수 있습니다. 그러면 대화 상자는 해당 컴퓨터에서 사용되는 기본 크기로 표시됩니다.
이제 modelessdialog.hta(그림 6 참조)를 살펴보고 이 대화 상자가 전달된 값을 읽는 방식을 확인하겠습니다.
Figure 6 modelessdialog.hta (Close Figure 6)
<html>
<head>
<title>Modeless Dialog</title>
<HTA:APPLICATION
  APPLICATIONNAME=”Processes”>
</head>

<script language=”VBScript”>
Sub window_onLoad
  strComputer = window.dialogArguments
  Set objWMIService = GetObject(“winmgmts:” _
    & “{impersonationLevel=impersonate}!\\” _
    & strComputer & “\root\cimv2”)
  Set colProcesses = objWMIService.ExecQuery   _
    (“Select * from Win32_Process”)

  strHTML = “<h1>” & strComputer & “</h1><p>”
  For Each objProcess in colProcesses
    strHTML = strHTML & objProcess.Name & _
       “<br>”
  Next

  DataArea.InnerHTML = strHTML
End Sub
</script>

<body>
<span id=”DataArea”></span>
</body>
</html>
이 HTA에서 지정한 유일한 요소는 범위이며 범위에는 대화 상자의 전체 영역이 포함됩니다. 또한 스크립트 섹션에서 window_onLoad 서브루틴을 정의했습니다. 이 서브루틴은 HTA가 열리는 즉시(여기서는 ShowModelessDialog에 대한 호출을 통해) 실행됩니다. 이 서브루틴의 첫 번째 줄을 확인해 보십시오.
strComputer = window.dialogArguments
이제 변수 strComputer에 window.dialogArguments 속성의 내용을 지정합니다. 이 속성의 내용이 무엇으로 생각되시나요? 자, 잠에서 깨십시오. 맞습니다. 속성의 내용은 ShowModelessDialog에 대한 호출의 두 번째 매개 변수를 통해 전달된 값입니다. 기본 창에서 Server2를 선택한 경우 strComputer는 이제 server2 값을 포함합니다.
서브루틴의 나머지는 단순히 strComputer에서 모든 프로세스를 검색하여 범위 영역에 표시합니다. 그림 7에서 이 작업의 결과를 확인할 수 있습니다.
이제 여러분은 다가오는 여름 내내 HTA 대화 상자와 함께 즐거운 시간을 보낼 수 있습니다. 물론 곧 겨울을 맞게 될 남반구 지역의 독자들은 제외하고 말이죠. 지난 겨울 저희 팀은 잦은 정전으로 인해 고생이 많았답니다.

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


 Exchange Queue &amp; A: OWA 제한 시간, Cmdlet 문제 해결 외
Exchange Queue & A
OWA 제한 시간, Cmdlet 문제 해결 외
KC Lemson and Nino Bilic

Q: 최근에 Exchange Server 2003에서 Exchange Server 2007로 마이그레이션했습니다. 그런데 Outlook® Web Access(OWA) 2007에 로그인할 때 "개인 컴퓨터입니다." 옵션을 선택한 Restricted Users 그룹 사용자로부터 OWA의 제한 시간이 초과된다는 불만이 접수되고 있습니다. 개인 컴퓨터의 제한 시간을 확인하는 데 사용할 수 있는 Exchange 관리 셸 명령은 무엇입니까?
A: 잠시 생각해 보겠습니다. 먼저 개인 컴퓨터와 공개 컴퓨터라는 별도의 두 옵션이 제공되는 이유에 대해 설명한 다음(그림 1 참조) 두 옵션이 어떻게 서로 다르게 작동하는지 알려드리겠습니다. 두 옵션이 제공되는 이유는 OWA에 액세스하는 데 공항의 공용 키오스크를 이용하는지 또는 가정의 컴퓨터를 이용하는지에 관계없이 사용자가 필요한 보안 수준을 Exchange에 지정할 수 있도록 하기 위해서입니다. Exchange 관리자는 이러한 세션 유형을 다르게 취급하도록 선택할 수 있습니다. 예를 들어 공개 컴퓨터에서는 인증된 세션의 제한 시간이 개인 컴퓨터(최대 3일)보다 빨리 단 몇 분만에 초과되도록 설정할 수 있습니다. 관리자는 사용자의 선택에 따라 그 밖의 설정도 다르게 구성할 수 있습니다. 예를 들어 개인 로그온에 대해서만 SharePoint® 문서 라이브러리와 Windows® 파일 공유에 대한 액세스를 허용하도록 설정할 수 있습니다. 물론 이는 사용자가 적절한 옵션을 지정한다는 가정하에서입니다. 사용자가 올바른 결정을 내릴지 확신할 수 없을 때는 관리자가 각 옵션에 대해 제한 시간 값 및 기타 구성 옵션을 동일하게 지정할 수 있습니다.
그림 1 다양한 제한 시간 설정 및 기타 구성 옵션을 허용하는 공개 및 개인 컴퓨터 세션 유형
그림 1 다양한 제한 시간 설정 및 기타 구성 옵션을 허용하는 공개 및 개인 컴퓨터 세션 유형
문제의 옵션은 OWA에 폼 기반 인증이 처음 도입되었을 때 Exchange 2003에서 가져온 것입니다. 잠시 폼 기반 인증의 배경에 대해 부연하자면, 이 인증의 최초 구현은 뛰어난 어떤 프로그램 관리자를 통해 일부 설계되었습니다. 여기서 이 프로그램 관리자가 누구인지는 밝히지 않겠지만, TechNet Magazine에 격월로 칼럼을 기고하면서 부와 명성을 쌓았다는 사실을 알려드리고 싶습니다.
설정은 실제로 레지스트리에 저장되지만, Windows PowerShell™에는 레지스트리를 업데이트할 수 있는 인터페이스가 있으므로 Exchange 관리 셸을 사용하여 이 설정을 구성할 수 있습니다. 다음 예에서는 사용자가 로그온 중 개인 컴퓨터 옵션을 선택하는 경우 제한 시간을 1440분 또는 1일로 설정합니다.
set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout
-value 1440 -type dword
물론 이 설정은 레지스트리에 저장되므로 원한다면 regedit를 사용하여 키를 직접 업데이트할 수 있습니다.
#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>
어떤 방법을 사용하든 IIS를 다시 시작하여 OWA에 새 설정을 적용해야 합니다. 이렇게 하려면 시작 | 실행을 선택한 다음 iisreset /noforce를 실행합니다.

Q: 전체 MAPI Outlook 클라이언트를 사용하는 회사의 모든 사용자에게 긴급하지 않은 필수 항목을 개인 폴더 파일(.pst)에 보관하도록 권장하고 있습니다. 그런데 사용자가 집에서 Outlook Web Access에 로그인할 경우 보관된 항목을 사용할 수 없는 문제가 발생합니다. OWA 인터페이스를 통해 이러한 .pst 파일을 사용하려면 어떻게 해야 합니까?
A: 안타깝게도 OWA에서는 .pst 파일에 액세스할 수 없습니다. OWA는 원래부터 온라인 전용 클라이언트로 만들어졌습니다. Exchange Server 팀은 컴퓨터에 개인 데이터가 조금이라도 남아 있지 않도록 하기 위해 많은 노력을 기울였습니다. 이러한 노력의 일환으로 Exchange 2003에서는 보안 로그오프 메커니즘이 도입되었으며 Exchange 2007에서는 첨부 파일의 캐시된 복사본이 하드 드라이브에 남지 않도록 WebReady 문서 보기 같은 기능도 제공하고 있습니다. 따라서 OWA에서 .pst 파일에 액세스하는 것은 OWA를 배포하기 쉬운 온라인 전용 클라이언트로 만들려는 목적에 부합되지 않습니다.
일반적인 .pst 사용은 기꺼이 논의해 보고 싶은 흥미로운 시나리오입니다. Exchange Server 팀은 사서함 할당량이 200MB 정도이고 거의 모든 사용자가 최소한 하나 이상의 .pst 파일을 보유하고 있는 고객과 만났습니다. 이 회사에서는 최소한의 노력으로 사용자 컴퓨터를 정리하고 교체할 수 있는 정책을 사용하고 있었으므로 모든 사용자가 자신의 .pst 파일을 네트워크 공유에 저장해야 했습니다. 그리고 네트워크 공유는 중앙 시스템에 백업되었습니다.
우선 네트워크 공유에서 .pst 파일에 액세스할 때 알려진 문제가 발생했습니다. OWA가 처음부터 온라인 전용으로 설계된 것처럼 .pst 파일도 원래부터 로컬에 저장되도록 만들어졌습니다. 네트워크 성능이 아무리 우수하더라도 대기 시간이나 여타 문제가 발생할 수 있으며 이는 동시에 수많은 사용자가 액세스해야 하는 원격 데이터 저장소에 많은 문제를 가져올 수 있습니다.
또한 이 회사는 Exchange에 모든 데이터를 보관할 경우 데이터를 모두 백업해야 하므로 이러한 번거로움을 피하기 위해 좀 작은 크기의 사서함을 사용했습니다. 요즘에는 회사 사서함의 크기가 2GB에 이를 정도로 큰 데도 말입니다. 그런데 사용자가 백업된 네트워크 공유의 .pst 파일에 데이터를 저장하고 있음에도 불구하고 관리자의 작업이 실제로는 줄어들지 않았습니다. 사실 여러 가지 요인으로 인해 작업이 오히려 늘어난 것 같습니다. .pst 파일에 대한 단일 인스턴스 저장소의 부재, 암호를 잊는다거나 일반적인 네트워크 오류와 같은 pst 파일로 인한 문제를 해결하는 데 드는 헬프 데스크 비용, 바이러스 공격 후 .pst 파일의 메시지 정리에 따르는 어려움, 법적 문제가 발생할 경우 .pst 파일의 메시지 검색에 따르는 어려움, 다른 백업 시스템의 유지 관리에 따르는 오버헤드 등으로 인해 작업이 증가되었을 수 있습니다.
따라서 구성을 결정할 때는 먼저 구성과 관련된 모든 비용을 고려해 보아야 합니다. 처음에 결정한 구성으로 인해 비용이 오히려 추가되고 다른 구성이 더 적합하다는 사실을 발견하게 될 수도 있습니다.

Q: Exchange 관리 셀 명령을 사용하는 데 문제가 있습니다. 명령이 작동하지 않습니다. 무엇이 문제일까요?
A: 이 질문에 대해 솔직히 어떻게 대답해야 할지 정확히 모르겠습니다. 이러한 경우에는 Windows PowerShell의 기본 제공 cmdlet인 start-transcript를 사용하여 해당 명령과 그 결과를 기록하는 것이 좋습니다. 이렇게 하면 전자 메일 메시지나 블로그 게시물에 정확한 정보를 붙여 넣거나 포럼에서 질문을 제기할 수 있습니다.
Exchange 관리 셸 세션을 열고 그림 2와 같이 start-transcript를 입력합니다. 그러면 Exchange 관리 셸에서 앞으로 실행되는 모든 명령을 그림 3과 같은 텍스트 파일에 자동으로 기록하기 시작하며 이 텍스트 파일의 위치도 보여 줍니다. 기록을 중지하려면 stop-transcript만 입력하면 됩니다.
그림 2 start-transcript cmdlet으로 사용한 명령과 그 결과 기록
그림 2 start-transcript cmdlet으로 사용한 명령과 그 결과 기록
그림 3 Windows PowerShell에서 사용한 명령에 대한 기록을 .txt 파일에 저장
그림 3 Windows PowerShell에서 사용한 명령에 대한 기록을 .txt 파일에 저장
사용한 명령의 전체 목록과 명령에 대해 반환된 결과가 있으면 문제를 해결하는 데 상당히 도움이 됩니다. 그러나 알지 못하는 사용자나 신뢰할 수 없는 사용자와 로그를 공유하려면 반환된 데이터에 기밀 정보나 중요한 데이터가 있는지 먼저 확인하는 것이 좋습니다.

Q: Exchange 2007 설치 프로그램에서 루트 도메인에 새 OU(조직 구성 단위)를 만듭니다. 이 OU의 이름은 Microsoft Exchange 보안 그룹이고 이 안에는 다섯 개의 새 Exchange 2007 보안 그룹이 있습니다. 이러한 그룹을 다른 OU로 이동할 수 있습니까? 혹시 다른 도메인으로 이동할 수 있을까요?
A: 이 문제는 Active Directory 준비 단계 중 루트 도메인에 만들어지는 다섯 개의 USG(유니버설 보안 그룹)와 관련이 있습니다. 이러한 그룹은 다음과 같습니다.
  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop
Exchange 2000 및 Exchange 2003에서는 Exchange Domain Servers와 Exchange Enterprise Servers 등의 기본 보안 그룹을 이동하는 것이 제한되었습니다. 더 정확히 말하면, 기본 보안 그룹을 이동할 수는 있었지만 이로 인해 무언가가 잘못되었습니다. 이 문제에 대한 자세한 내용은 support.microsoft.com/kb/260914를 참조하십시오. 결론적으로 이전 버전에서는 기본 보안 그룹 이동이 매우 제한되었습니다.
Exchange 2007에서는 상황이 달라졌습니다. 다섯 개의 기본 보안 그룹을 이동할 수 있으며, 동일한 도메인 내의 다른 OU 또는 완전히 다른 도메인으로 그룹을 이동할 수 있습니다.
이 다섯 그룹이 없어졌는데 그룹을 어느 OU나 도메인으로 이동했는지 모를 경우에는 다음 컨테이너에서 otherWellKnownObjects 특성 값을 확인하면 정확한 위치를 알 수 있습니다.
CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com
그룹이 이동되면 이 특성에서 그룹 위치가 업데이트되어 언제든지 그룹이 어디에 있는지 알 수 있습니다. 정말 편리하지 않습니까?

Q: 도메인에 "Exchange Install Domain Servers"라는 글로벌 보안 그룹이 있습니다. 이 그룹의 용도는 무엇입니까?
A: Active Directory®의 내용을 굉장히 자세히 살펴보신 것 같습니다. 사실 Exchange 2007 서버가 설치된 모든 도메인에는 Exchange Install Domain Servers 그룹이 있습니다. 이 그룹은 MESO(Microsoft Exchange System Objects) OU에 만들어집니다. 이 그룹을 면밀히 들여다보면 유니버설 보안 그룹인 루트 도메인의 Exchange Servers 그룹 구성원인 것을 알 수 있습니다.
간단히 말해 Exchange Install Domain Servers는 하위 도메인 중 하나에서 Exchange 2007 설치 프로그램을 실행하는 경우 Active Directory 복제 주기가 길어지는 문제를 해결하기 위해 사용하는 그룹입니다. 예를 들어 Root라는 루트 도메인과 Child라는 자식 도메인, 그리고 Grandchild라는 Child 도메인의 자식 도메인이 있다고 가정해 보겠습니다. 이름을 너무 단순하게 지정했는데, 이런 방식이라면 암호도 쉽게 추측하실 수 있겠습니다.
이 조직에서 Exchange 2007 설치를 시작하려면 먼저 스키마를 확장하고 Root 도메인을 준비해야 합니다. 이렇게 하면 앞의 질문에 대한 설명에서 다룬 다섯 개의 USG가 만들어집니다.
그런 다음에는 Grandchild 도메인에서 설치 프로그램을 실행해야 합니다. 로컬 도메인에서 Exchange 2007 서비스를 시작할 수 있도록 설치 프로그램에서는 Root 도메인의 Exchange Servers 그룹에 Exchange 2007 컴퓨터 계정을 저장합니다. 그러나 Grandchild 도메인에서 설치 프로그램을 실행하고 있기 때문에 Exchange Servers 그룹 구성원이 복제되는 데 시간이 걸릴 수 있습니다.
Exchange Servers는 유니버설 그룹이므로 그룹 구성원이 포리스트 전체에 복제됩니다. 복제 대기 시간이 발생하면 설치 프로그램이 완료되었을 때 서비스 시작 권한이 복제되지 않을 수 있기 때문에 Grandchild 도메인의 설치 프로그램이 서비스를 시작하지 못할 수 있습니다. 바로 이런 이유 때문에 처음으로 도메인에 Exchange 2007 서버를 설치할 때 로컬 도메인에 Exchange Install Domain Servers 그룹이 만들어지는 것입니다.
설치 중 Exchange 컴퓨터 계정이 이 그룹의 구성원으로 저장됩니다. 이 그룹의 구성원은 설치 프로그램이 끝날 때 서비스를 시작하는 데 충분한 권한을 제공하며, 이는 Exchange Servers 그룹의 구성원이 Root 도메인에서 아직 복제되지 않은 경우에도 마찬가지입니다. 로컬 도메인 복제는 일반적으로 도메인 간 복제보다 빠르다는 점을 기억하십시오.

Q: Exchange 2007 설명서에서는 Exchange 2007에 대한 스키마를 확장하기 전에 /PrepareLegacyExchangePermissions 스위치를 사용하여 설치 프로그램을 실행해야 한다고 설명하고 있습니다. 그 이유가 무엇입니까? 그리고 이 스위치의 이름을 조금 짧게 만들 수는 없었습니까?
A: 설치 프로그램을 실행하기 전에 설명서를 읽어 보셨다니 기분이 좋습니다. 설명서의 내용에 만족하셨습니까?
/PrepareLegacyExchangePermissions(또는 /pl)는 Exchange 정보 및 개인 정보 속성 집합에 쓸 수 있는 권한을 Exchange 2000 및 Exchange 2003 RUS(받는 사람 업데이트 서비스)에 제공하는 스위치입니다. Exchange 2007 스키마 확장 프로세스 중 프록시 주소 같은 몇 가지 특성은 Active Directory 공용 정보 속성 집합에서 Exchange 정보 속성 집합으로 이동됩니다. 기본적으로 Exchange 2000 및 Exchange 2003 RUS에는 Exchange 정보 속성 집합에 쓸 수 있는 권한이 없습니다. 실제 환경에서 이것은 Exchange 2007 스키마 확장을 먼저 실행하면 새 받는 사람을 만들 수 없기 때문에 Exchange 2000 및 Exchange 2003 RUS가 제대로 작동하지 않는다는 것을 의미합니다. 이러한 속성 집합에 대한 자세한 내용은 msexchangeteam.com의 블로그를 참조하십시오.
이러한 이유 때문에 Exchange 2007에 대한 스키마를 확장하기 전에 반드시 /pl 스위치를 실행해야 하는 것입니다. 또한 이 변경 내용을 Exchange 2000 또는 Exchange 2003 받는 사람이 있는 모든 도메인에 복제하여 해당 도메인에 RUS가 있도록 해야 합니다. 나중에 새 도메인이 포리스트에 추가되어 이 도메인에 Exchange 2000 또는 Exchange 2003 RUS를 설치해야 해야 할 경우에는 해당 도메인에서 /pl 스위치를 실행하면 됩니다.
또한 /pl 스위치를 처음 실행할 때 엔터프라이즈 관리자 권한이 있는 계정으로 스위치를 실행하면 이후의 작업이 한결 수월해집니다. 이 경우 루트 도메인의 설치 프로그램이 /pl을 실행해야 하는 도메인을 식별하여 해당되는 모든 도메인에서 /pl 스위치를 실행합니다. 엔터프라이즈 관리자 계정을 사용하지 않을 경우에는 각 도메인에 대해 도메인 관리자 계정을 사용하여 /pl 스위치를 실행해야 합니다. Exchange 2007 설명서에서는 모든 권한 요구 사항을 자세히 보여 줍니다.
마지막으로 이 스위치의 이름을 짧게 만들 수는 없었냐고 질문하셨는데 /PrepareLegacyExchangePermissions라고 세 번만 빨리 말해 보십시오.
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
이 스위치의 이름을 /PrepareLegacyExchangePermissionsWOW로 지을까도 생각했었습니다. 정말 길지요. 하지만 좀 더 친숙하고 짧은 /PrepareLegacyExchangePermissions를 선택했습니다.
이렇게 해서 스위치 이름이 만들어진 것입니다. 원한다면 언제든지 훨씬 짧은 /pl을 사용할 수 있습니다. 정말입니다.

KC Lemson은 Exchange Server 팀의 설치 환경 관리자로, 자녀의 대학 학자금을 운용할 투자처 정보가 있는 전자 메일을 읽는 게 취미입니다.
Nino Bilic은 Exchange Server 팀의 기술 팀장으로, 평일 근무 시간에 몰래 Halo 게임을 얼마나 많이 할 수 있는지 생각하느라 분주한 시간을 보내고 있습니다.


 Security Watch: 네트워크 액세스 보호
Security Watch
네트워크 액세스 보호
John Morello
이 칼럼에 나와 있는 Windows Server "Longhorn"에 대한 시험판 정보는 변경될 수 있습니다.

오늘날 기업들이 그 규모에 관계없이 직면하고 있는 최대 보안 위협 중 하나는 네트워크 밖에 존재하는 악의적인 장치들입니다. 인터넷을 통해 들어오는 외부 위협을 차단하는 보안 시스템이 아무리 잘 구축되어 있어도 직원이 자기도 모르는 사이에 의도하지 않게 웜이나 트로이 목마를 통해 맬웨어를 전송하는
매개체가 되어 조직의 보안이 위험에 노출될 수 있습니다. 특히 직원들이 한 대의 랩톱을 사용하여 개인 용무와 회사 업무를 처리하고 비용 부담이 크고 배포하기가 복잡하다는 이유로 네트워크 액세스 제어 기술을 제대로 갖추지 않은 중소 기업의 IT 환경이 가장 심각합니다. 하지만 시스템 중단으로 인해 높은 비용을 지불하는 것도 대부분 이러한 중소 기업들이기 때문에 이러한 위협을 차단하는 것이 무엇보다 중요합니다.
Microsoft의 NAP(네트워크 액세스 보호) 기술을 이용하면 모든 규모의 기업들이 네트워크에 액세스할 때 미리 컴퓨터의 상태를 확인하고 네트워크에 연결되어 있는 동안 정상적인 상태를 유지할 수 있습니다. NAP은 유연한 정책 기반 아키텍처로서, 기업들은 이 기술을 통해 고의로든 실수로든 직원, 공급업체, 방문객들에 의해 정책에 맞지 않는 컴퓨터가 네트워크에 액세스하는 것을 차단할 수 있습니다. NAP은 정책 유효성 검사, 격리, 치료, 지속적인 규정 준수라는 네 가지 기본 요소를 중심으로 구축되었습니다.

NAP 개요
NAP을 통해 제공되는 첫 번째 핵심 서비스는 정책 유효성 검사입니다. 정책 유효성 검사란 NAP 기술을 사용하여 관리자가 정의해 둔 규칙을 기준으로 시스템을 평가하고 시스템의 상태를 분류하는 과정을 말합니다.
IT 관리자는 컴퓨터가 네트워크에 접속하려고 할 때 비교를 목적으로 NAP에서 사용할 정책 요소들을 지정합니다. 정책 요소와 부합되는 컴퓨터는 정상적인 것으로 간주되지만 관리자가 지정한 하나 이상의 검사에서 실패하는 컴퓨터는 정상적이지 않은 상태로 간주됩니다. 이러한 정책을 통해 바이러스 백신 및 스파이웨어 방지 소프트웨어 설치 여부, 호스트 방화벽 활성화 여부, 컴퓨터 보안 업데이트 누락 여부 등을 검사할 수 있습니다. 또한 NAP은 확장이 가능한 독립 소프트웨어로 구축되므로 공급업체는 자체적으로 NAP용 플러그인을 만들어 응용 프로그램별로 검사를 실시할 수 있습니다.
NAP을 통해 제공되는 또 다른 핵심 서비스는 네트워크 연결 제한입니다. 관리자가 정의해 둔 정책에 따라 NAP은 시스템을 다양한 네트워크 연결 상태로 설정합니다. 예를 들어 시스템에 중요한 보안 업데이트가 없어서 위험한 것으로 판단되면 NAP에서 이 시스템을 차단 네트워크로 옮겨 정상적인 상태가 될 때까지 다른 환경과 격리시킬 수 있습니다. NAP을 사용하지 않는 경우 정상적이지 않은 상태의 클라이언트는 회사 네트워크에 마음대로 액세스할 수 있습니다. 중요한 보안 업데이트를 설치하지 않아 발생한 보안 허점을 통해 맬웨어가 시스템을 손상시킬 수 있으면 네트워크에 있는 다른 시스템도 감염시키려고 계속 시도할 것입니다. 그림 1은 NAP 아키텍처의 일반적인 모습입니다.
그림 1 일반 NAP 아키텍처
그림 1 일반 NAP 아키텍처
하지만 단순히 연결을 제한해서만은 정상적이지 않은 상태의 시스템을 효율적으로 처리할 수 없습니다. 어쨌거나 사용자는 여전히 할 일이 있기 때문입니다. 따라서 NAP은 관리자가 개입하지 않고도 격리된 정상적이지 않은 시스템의 상태 문제를 해결할 수 있는 치료 서비스도 제공합니다. 위 예에서는 제한된 네트워크에서 감염된 컴퓨터가 누락된 업데이트를 설치하는 데 필요한 특정 네트워크 리소스(예: 조직의 Windows Server® Update Services(WSUS) 컴퓨터)에만 액세스할 수 있습니다. 다시 말해, NAP이 구현된 환경에서는 정상적이지 않은 상태의 컴퓨터가 감염을 치료할 수 있는 네트워크 리소스에만 액세스할 수 있기 때문에 완전히 치료될 때까지 네트워크의 다른 시스템으로 트래픽을 보낼 수 없습니다.
NAP의 마지막 요소인 지속적인 정책 준수는 컴퓨터가 처음 네트워크에 연결될 때뿐만 아니라 네트워크에 연결되어 있는 동안 지속적으로 상태 정책이 적용되도록 하는 것입니다. 지금까지 설명한 예를 바탕으로 컴퓨터가 자동 업데이트를 통해 정상적인 상태가 되고 그 결과 네트워크에 자유롭게 액세스할 수 있다면 어떤 이점을 얻을 수 있을지 생각해 보십시오. Windows 방화벽 비활성화 등의 이유로 나중에 컴퓨터가 정책을 준수하지 못하더라도 NAP이 자동으로 그 컴퓨터를 다시 격리할 수 있습니다. 또한 관리자가 자동 치료 기능을 구성할 수 있으므로 초기 네트워크 연결이 완료되고 오랜 시간이 지난 후에도 별도의 사용자 개입 없이 비준수 상태를 자동으로 해결할 수 있습니다.
NAP에서는 네트워크 액세스를 제어할 때 몇 가지 기술을 사용할 수 있습니다. 관리되는 네트워크 스위치가 있는 기업의 경우, 802.1X를 사용하여 네트워크 하드웨어 계층에서 포트를 기반으로 액세스를 제어할 수 있습니다. 또한 보안 네트워크가 IPsec 연결을 통해 만들어지고 실제 네트워크를 통해 계층화되는 IPsec 기반 정책을 적용할 수도 있습니다. IPsec 기반 정책을 적용하면 NAP이 IPsec 엔진에서 사용되는 인증서를 동적으로 만들고 제거하는 방식으로 보안 영역에 대한 액세스를 제어합니다. 마지막으로 NAP을 사용하면 DHCP 기반 정책을 적용할 수 있습니다. 이 경우 DHCP 서버는 제한된 풀에서 가져온 IP 리스를 정상적이지 않은 상태의 클라이언트에 제공합니다. 이러한 리스는 별도의 DNS 접미사와 IP 경로를 사용하여 제한된 클라이언트가 액세스할 수 있는 리소스를 제어합니다.
NAP 서버 구성 요소는 코드명이 "Longhorn"인 차세대 Windows Server, 더 구체적으로 말하자면 인터넷 인증 서비스의 뒤를 이어 한층 더 향상된 모습으로 등장한 새로운 NPS(네트워크 정책 서버)에 통합되었습니다. 802.1X 기반 정책을 적용하는 기업의 경우, 네트워크 하드웨어가 802.1X 인증 및 동적 VLAN 기능을 지원해야 합니다. "NAP 리소스" 추가 기사의 네트워크 액세스 보호 파트너 사이트에 특정 하드웨어 공급업체에 대한 자세한 정보가 나와 있습니다. DHCP 기반 정책을 적용하는 경우, Windows Server "Longhorn"에서 사용할 수 있는 것과 같은 NAP 사용 DHCP 서비스가 필요합니다. 클라이언트의 경우 Windows Vista™에서 기본 제공되는 NAP을 이용할 수 있습니다. NAP은 또한 Windows XP에 802.1X를 적용하는 새로운 802.1X 신청자와 함께 Windows® XP에 추가 기능으로도 제공될 예정입니다.
뿐만 아니라 NAP은 상태 정보를 보고하는 Windows 보안 센터를 비롯한 타사 상태 에이전트에 통합됩니다. 따라서 NAP은 보안 센터를 통해 노출된 데이터를 바탕으로 정책 유효성 검사 결과를 결정할 수 있습니다.
NAP은 엔터프라이즈 수준의 뛰어난 정책 관리 솔루션이므로 하나의 기사에서 모든 기능과 배포 전략을 설명한다는 것은 불가능합니다. 따라서 이 기사에서는 IT 직원의 시간이 많이 부족하고 NAP 배포를 간소화하여 배포에 필요한 투자 효과를 빠르게 얻을 수 있는 중소 규모 기업을 대상으로 한 배포에 초점을 맞추고자 합니다. 하지만 대부분의 지침과 일반 안내 정보는 기업의 규모에 관계없이 모든 NAP 설계에 동등하게 적용됩니다. 단, 여기서 예로 든 내용은 단계별 설치 가이드라기보다는 성공적인 DHCP 기반 NAP 배포를 위해 알아야 할 중요한 분야를 소개하는 개요의 성격이 강합니다. 자세한 설치 가이드는 "NAP 리소스" 추가 기사에 있는 링크를 참조하십시오.

Contoso의 문제
NAP이 중소 규모 기업만이 지닌 요구 사항을 어떻게 해결할 수 있는지 자세히 알아보기 위해 Contoso, Inc.의 예를 살펴보겠습니다. Contoso는 세 개의 본사에 250대의 컴퓨터를 두고 있는 중간 규모의 가상 기업입니다. Contoso는 많은 직원들이 재택 근무를 하고 외부 고객 회사에서 본사의 컴퓨터에 접속하여 업무를 처리하는 등 인력의 이동량이 매우 많습니다. 따라서 컴퓨터를 사용하는 전 직원의 절반 가량이 랩톱과 Tablet PC를 사용합니다. 직원들의 이동량이 늘어나면서 Contoso도 다른 여러 기업들처럼 보안 문제에 직면하게 되었습니다. 모바일 컴퓨터를 사용하는 일부 사용자가 고객 회사에서 작업하거나 재택 근무 중에 맬웨어에 감염된 컴퓨터를 그대로 내부 Contoso 네트워크에 연결한 경우가 있었습니다.
Contoso는 이러한 원격 컴퓨터를 항상 최신 상태로 유지해야 하는 문제로도 고민해 왔습니다. 사용자가 오랜 기간 고객사에서 일하다가 Contoso 사무실로 돌아오는 경우가 많기 때문입니다. 이런 경우 몇 달 동안 시스템에 보안 업데이트를 설치하지 않기도 하기 때문에 Contoso 네트워크에 연결되어 있는 나머지 시스템까지 위험에 빠뜨릴 가능성이 높습니다. 따라서 Contoso에는 원격으로든 로컬로든 네트워크에 연결된 모든 시스템을 안전하게 보호할 수 있는 솔루션이 필요합니다.
NAP은 Contoso의 목표를 달성하는 데 어떤 도움을 줄 수 있을까요? NAP의 기본 요소를 떠올려 보십시오. NAP은 정책 유효성 검사를 통해 Contoso 네트워크에 연결된 모든 시스템의 상태를 확인할 수 있습니다. 정책 유효성 검사를 통해 시스템에 최신 바이러스 백신 서명이 설치되어 있는지, 모든 보안 업데이트가 완벽하게 패치되었는지 확인할 수 있습니다. NAP 정책 유효성 검사 결과 정상적이지 않은 상태의 시스템이 확인되면 NAP이 이러한 호스트에 대한 네트워크 연결을 제한합니다. 따라서 외부 사이트에서 사용되어 맬웨어에 감염된 컴퓨터가 네트워크의 다른 컴퓨터에 문제를 퍼뜨릴 수 없습니다. NAP이 정상적이지 않은 컴퓨터의 연결을 제한하면 이 컴퓨터는 Contoso의 IT 관리자가 정의해 둔 업데이트 관리 리소스에만 액세스할 수 있습니다. 예를 들어 정상적이지 않은 상태의 컴퓨터는 Contoso WSUS 서버와 바이러스 백신 서명을 호스팅하는 서버에 액세스할 수 있습니다. 마지막으로 NAP은 시스템이 치료된 후 지속적으로 정상적인 상태를 유지하도록 합니다. 여기서 보여준 예에서는 재택 근무자가 VPN을 통해 정상적이지 않은 상태의 호스트를 사용하고 이 사용자가 호스트 방화벽을 해제한 경우 NAP이 자동으로 문제를 해결합니다. 방화벽이 해제되면 그 즉시 NAP 인프라가 컴퓨터를 격리하고 방화벽을 다시 활성화한 다음 시스템 상태를 다시 확인하여 정상이라고 판단한 경우에만 시스템을 제한되지 않은 네트워크에 다시 추가합니다. NAP의 네 가지 기본 요소가 동적이고 이동량이 많은 Contoso 컴퓨팅 환경의 주요 보안 요구 사항을 직접 해결하는 것입니다.

NAP 설계
많은 중소 규모 기업에게는 DHCP 기반 정책 적용을 통해 NAP을 구현하는 것이 가장 빠르고 쉬운 방법입니다. DHCP 정책 적용에는 별도의 네트워크 변경이나 DHCP와 NPS 외의 추가 서비스가 필요하지 않기 때문입니다. IPsec 및 802.1X 적용 옵션이 보다 유연하기는 하지만 이 옵션을 사용하려면 네트워크를 추가로 변경해야 하고 새로운 서비스를 배포해야 합니다. 덜 복잡한 환경에서는 DHCP를 사용함으로써 구현 비용도 훨씬 낮추고 운영 부담도 줄이면서 NAP의 주요 혜택을 모두 얻을 수 있습니다.
Contoso의 환경에서는 Windows Server "Longhorn"을 실행하는 컴퓨터가 NAP 배포의 핵심 요소로 사용됩니다. NAP에는 Windows Server "Longhorn" NPS가 필요하기 때문에 이전 Windows Server 릴리스에는 NAP을 배포할 수 없습니다. DHCP 기반 적용을 통해 NAP을 구현하려는 경우에도 Windows Server "Longhorn" DHCP 서버가 필요합니다. 서비스를 통합하기 위해 NPS와 DHCP를 모두 동일한 서버에 배포하는 것이 좋으며 이렇게 해도 아무런 문제 없이 실행됩니다. 따라서 Contoso에 필요한 기본적인 NAP 서버 인프라는 상당히 단순합니다. Windows Server "Longhorn"이 있는 한 대의 컴퓨터가 정책 구성 요소와 적용 구성 요소를 모두 실행하기 때문입니다.
클라이언트 쪽에서는 Windows Vista를 실행하는 Contoso의 컴퓨터가 이미 NAP을 지원하는 데 필요한 기능을 갖추고 있습니다. 클라이언트 쪽에서 Windows Vista를 실행하는 시스템에 유일하게 수행해야 하는 변경 작업은 NAP 기능을 활성화하는 것입니다. 이 작업은 그룹 정책을 통해 수행할 수 있습니다. Windows XP를 실행하는 Contoso 컴퓨터의 경우, NAP 클라이언트 패키지를 별도로 설치해야 합니다. 도메인에 가입된 Windows XP를 실행하는 컴퓨터는 기본적으로 Windows 보안 센터 기능이 비활성화되어 있습니다. NAP 정책이 보안 센터의 상태 정보를 사용하여 컴퓨터 상태를 평가하는 경우 보안 센터를 실행해야 NAP이 제대로 작동됩니다. 따라서 Windows XP를 실행하는 Contoso 컴퓨터의 경우에는 관리자가 그룹 정책을 통해 보안 센터를 활성화했습니다. 이러한 변경 작업을 제외하면 클라이언트 쪽에서 NAP을 지원하는 데 수행해야 할 별도의 작업은 없습니다.

Contoso NAP 배포
앞서 언급한 그룹 정책 변경을 모두 완료한 후 Contoso가 수행해야 할 다음 NAP 배포 단계는 Windows Server "Longhorn"을 설치하는 것입니다. Windows Server "Longhorn"의 모든 버전에는 필요한 NAP 구성 요소가 포함되어 있으므로 Contoso는 어떤 버전을 사용해도 요구 사항을 충족할 수 있습니다. 설치가 완료되면 IT 관리자는 서버 관리자 도구를 사용하여 시스템에 새 역할을 추가합니다. Contoso가 사용하는 DHCP 기반 적용의 경우 필요한 역할은 네트워크 액세스 서비스와 DHCP 서버입니다. 관리자는 역할 추가 마법사를 사용하여 종속성을 처리하고 서버에 필요할 수 있는 추가 기능을 포함합니다. 역할을 추가했으면 이제 NAP을 구성할 준비가 된 것입니다.
Contoso의 관리자는 서버 관리자 도구를 사용하여 MMC(Microsoft Management Console)의 DHCP 스냅인에 액세스하여 새 범위를 추가합니다. Windows Server "Longhorn"을 DHCP 서버로 구성하면 서버가 호스팅하는 IP 세그먼트에 있던 기존의 모든 DHCP 서비스가 대체됩니다. 범위가 생성되고 Contoso의 네트워크를 기반으로 올바른 옵션이 채워지면 NAP을 그 범위에서 활성화해야 합니다. 이 작업은 범위 속성의 네트워크 액세스 보호 탭에서 수행할 수 있습니다(그림 2 참조).
그림 2 NAP 활성화
그림 2 NAP 활성화
NAP은 새로운 NAP 사용자 클래스 범위 옵션을 사용하여 동일한 범위 내에서 시스템의 네트워크 액세스를 제한하거나 제한을 해제합니다. 이처럼 특수한 범위 옵션(DNS 서버, 기본 DNS 접미사 등)은 정상적이지 않은 상태의 클라이언트에 리스를 제공할 때 사용됩니다. 예를 들어, 정상적인 클라이언트에는 "contoso.com"이라는 기본 DNS 접미사가 제공되지만 정상적이지 않은 상태의 클라이언트에는 "restricted.contoso.com"이라는 접미사가 지정됩니다(그림 3). DHCP 범위 옵션이 구성되면 네트워크 정책 서버를 설정하고 규칙을 생성할 수 있습니다.
그림 3 제한된 액세스
그림 3 제한된 액세스
NPS 정책은 네 가지 주요 구성 요소로 구성되어 있습니다. SHV(시스템 상태 검사기)는 컴퓨터의 상태를 평가하기 위해 수행할 검사를 정의합니다. 업데이트 관리 서버 그룹에는 정상적이지 않은 상태의 시스템이 치료를 받기 위해 액세스할 수 있는 시스템(예: WSUS)이 포함됩니다. 시스템 상태 검사기 템플릿 구성 요소는 실제 상태를 정의하는 데 사용됩니다. 예를 들어, Windows 보안 SHV를 통과하지만 클라이언트가 바이러스 백신 공급업체에서 제공하는 또 다른 SHV 검사를 통과할 수 없게 하는 시스템을 "정책 준수" 컴퓨터로 지정할 수 있습니다. 마지막으로 이러한 구성 요소는 시스템 상태에 따라 시스템에 어떤 조치를 적용할지 결정하는 논리가 포함된 네트워크 정책에 통합됩니다.
시스템 상태 검사기는 NPS 에이전트가 NPS의 상태를 검사하여 보고하는 항목 목록입니다. 기본 NAP 배포에는 Windows SHV가 포함되는데, 이 Windows SHV가 Windows 보안 센터에 연결되어 보안 센터를 통해 보고되는 모든 보안 구성 요소의 상태를 NAP이 확인할 수 있게 해줍니다. 여기에는 방화벽, 바이러스 백신, 자동 업데이트, 스파이웨어 방지 구성 요소 등이 있습니다.
NAP은 확장이 가능하며 타사에서도 자체 SHV를 만들어 개별 구성 요소를 보다 세부적으로 검사할 수 있도록 설계되었다는 점을 기억하십시오. 자세한 내용은 microsoft.com/windowsserver2003/partners/nappartners.mspx를 참조하십시오. 예를 들어 NAP은 Windows 보안 SHV를 통해 바이러스 백신 프로그램이 활성화되어 있는지, 최신 상태인지 등을 확인할 수 있습니다. 그러나 Windows 보안 SHV는 시스템 검사 횟수나 다른 응용 프로그램 옵션 등 보다 자세한 바이러스 백신 응용 프로그램 검사는 수행할 수 없습니다. 하지만 바이러스 백신 공급업체는 응용 프로그램에 더 깊이 연결되어 기본 Windows SHV보다 더욱 구체적인 응용 프로그램 검사를 제공하는 자체 SHV를 만들 수 있습니다. 이 SHV는 Windows SHV 및 다른 SHV(있는 경우)에 연결되어 작동할 수 있으므로 NAP 배포 시 여러 SHV가 동시에 사용될 수 있습니다(그림 4 참조).
그림 4 Windows 보안 SHV
그림 4 Windows 보안 SHV
업데이트 관리 서버 그룹은 정상적이지 않은 상태의 시스템이 액세스할 수 있는 리소스를 지정할 때 사용됩니다. 이 그룹에는 WSUS 서버나 SMS(Systems Management Server), 바이러스 백신 업데이트 서버가 종종 포함됩니다. 서버 자체뿐만 아니라 클라이언트가 서버를 찾을 때 사용하는 이름 확인 서버도 추가하는 것이 중요합니다. Contoso의 클라이언트는 자동 업데이트에 wsus.contoso.com이라는 서버를 사용하도록 그룹 정책을 통해 구성되었으므로 업데이트 관리 서버 그룹에는 WSUS 서버의 IP 주소뿐만 아니라 클라이언트가 FQDN(정규화된 도메인 이름)을 숫자 IP 주소로 변환할 때 사용하는 DNS 서버의 IP 주소도 포함해야 합니다. 클라이언트가 이러한 이름 확인 리소스(클라이언트가 구성된 방식에 따라 DNS와 WINS 모두 될 수 있음)에 액세스하지 못하면 업데이트 관리 리소스의 IP 주소를 확인할 수 없기 때문에 결과적으로 업데이트 관리 리소스에 액세스할 수 없습니다. 그림 5는 DNS 및 IP 설정의 예입니다.
그림 5 DNS 이름과 IP 주소
그림 5 DNS 이름과 IP 주소
시스템 상태 검사기 템플릿은 정상적인 컴퓨터의 요건을 정의하는 데 사용됩니다. 검사기 템플릿은 SHV 검사 결과를 받아서 시스템이 이러한 검사를 통과했는지 또는 실패했는지에 따라 시스템의 상태를 판단합니다(그림 6 참조).
그림 6 정책 준수 검사
그림 6 정책 준수 검사
대부분의 중소 규모 배포 환경과 마찬가지로 Contoso 환경에서는 두 가지 상태만 정의됩니다. 정상적인 컴퓨터는 모든 SHV 검사를 통과하는 컴퓨터이고 비준수 컴퓨터는 이러한 검사를 통과하지 못한 컴퓨터입니다. 역할, 부서, 위치 등에 따라 사용자마다 다른 정책 준수 표준을 생성하는 것처럼 필요한 경우 좀더 복잡한 논리를 구현할 수도 있지만 그럴 경우 문제 확인 및 해결이 어려워지고 그에 따른 소요 시간도 늘어날 수 있다는 점에 유의해야 합니다.
이러한 구성 요소에는 모두 네트워크 정책이 적용됩니다. 네트워크 정책은 관리자에 의해 정의되며 컴퓨터 상태에 따라 컴퓨터를 어떻게 처리할지 NPS에게 알려줍니다. 이러한 정책은 NPS UI에 표시된 대로 위에서 아래로 평가되며 정책 규칙과 부합하면 프로세스가 중단됩니다.
다시 말하지만 Contoso 네트워크에서는 단순성이 목표이기 때문에 몇 가지 정책만 있으면 됩니다. 첫 번째는 Compliant-FullAccess(준수-모든 액세스) 정책입니다. 이 정책은 모든 SHV 검사를 통과한 시스템에게 네트워크에 무제한 액세스할 수 있는 권한을 주는 것입니다. 특히 시스템 상태를 평가한 결과 모든 검사에 통과하면 NPS가 DHCP 서버에게 "normal"(표준) 범위 옵션이 있는 IP 리스를 시스템에게 제공하라고 명령합니다. 검사 시 대부분의 시스템이 정책을 준수하므로 일반적으로 이 Compliant-FullAccess(준수-모든 액세스) 정책이 처리 순서에서 가장 먼저 나옵니다. 이 정책을 먼저 표시해야 NPS에서 처리 로드와 시간을 줄일 수 있습니다.
다음으로 사용되는 정책은 Noncompliant-Restricted(비준수-제한) 정책입니다. Contoso 환경에서는 SHV 검사에 실패하여 결과적으로 비준수 시스템 상태 검사 템플릿과 일치하는 모든 시스템이 이 정책에 해당됩니다. 이 정책과 부합하는 클라이언트가 발견되면 NPS가 DHCP 서버에게 특수 NAP "restricted"(제한) 범위 옵션이 있는 IP 리스를 클라이언트에게 제공하라고 명령합니다. 따라서 비준수 컴퓨터는 Contoso 업데이트 관리 서버 그룹에 정의되어 있는 리소스에만 액세스할 수 있습니다.
세 번째로 사용되는 정책은 이전 버전과의 호환성을 위한 정책입니다. 기본적으로 NAP 지원은 Windows XP 이후 운영 체제에서 사용할 수 있다는 점을 기억하십시오. 단, 독립 소프트웨어 공급업체에서 직접 NAP 클라이언트를 개발하여 이전 버전의 Windows나 Windows 이외의 운영 체제에 사용할 수는 있습니다. Contoso 프로덕션 환경에서 여전히 Windows 2000이 사용되고 있다면 NAP을 인식하지 못하는 시스템이 네트워크(DHCP 서버에 의해 기본 범위 옵션이 지정됨)에 액세스할 수 있는 권한을 받을 수 있도록 허용하는 규칙을 만들 수 있습니다. 이 예에서는 Downlevel-Full-Access(이전 버전-모든 액세스)를 만들었습니다. 이 정책은 마지막에 평가되어야 하며 이전 버전 시스템이 네트워크에 액세스해야 하는 경우에만 만들어 활성화해야 합니다(그림 7 참조).
그림 7 이전 버전 시스템의 액세스 설정
그림 7 이전 버전 시스템의 액세스 설정
Contoso 네트워크에 프린터나 다른 하드웨어처럼 NAP을 인식할 수 없는 리소스가 있는 경우에는 어떻게 해야 할까요? 더 나아가, NAP을 인식할 수는 있지만 영구적으로 또는 일시적으로 정책 검사에서 제외하고 싶은 시스템이 있는 경우에는 어떻게 해야 할까요? 이러한 시스템을 쉽게 제외할 수 있는 방법은 MAC 주소를 사용하는 것입니다. 이러한 시스템에서 NAP 검사를 건너뛰려면 Contoso 관리자가 모든 네트워크 액세스 권한을 부여하는 새로운 정책인 Exempt by MAC(MAC에 의한 제외)을 만들면 됩니다. 이 정책은 Calling Station ID의 RADIUS 클라이언트 속성이 NAP 검사를 건너뛰어야 하는 장치의 MAC 주소와 일치하는지 비교하는 조건문을 사용합니다. 시스템이 이 정책의 조건문과 일치하면 NPS가 DHCP에게 "normal"(표준) 범위 옵션을 리스에 제공하라고 명령합니다. 평가 순서에서 이 정책을 가장 먼저 표시해야 NPS에서 전체 처리 시간과 로드를 줄일 수 있습니다. 이 정책과 일치하는 시스템은 SHV 평가를 받을 필요가 없으므로 NPS에서 이러한 시스템을 검사하기 위해 추가로 시간을 투자하지 않아도 됩니다(그림 8 참조).
그림 8 특정 시스템 무시
그림 8 특정 시스템 무시
이러한 정책들을 통합하면 Contoso의 NPS가 네트워크에 연결된 시스템을 빠르고 정확하게 평가할 수 있습니다. 또한 이전 버전 컴퓨터와 장치에 필요한 경우나 일시적으로 NAP 인식 장치를 건너뛰어야 하는 경우에 예외를 적용할 수 있습니다.

결론
NAP은 다양한 기술을 통합적으로 사용하므로 특히 복잡한 시나리오에서는 철저한 계획과 테스트가 필요합니다. 이 기사에서는 덜 복잡한 시나리오를 중심으로 설명했지만 NAP 웹 사이트에는 다양한 규모의 기업에 적합한 배포 지침이 자세히 나와 있습니다. 또한 경우에 따라서는 DHCP 기반 적용보다 기업에 더 잘 맞는 802.1X 및 IPsec 기반 적용 기술을 계획하는 데 대한 정보도 나와 있습니다.
NAP은 네트워크에 연결된 컴퓨터의 상태를 평가할 수 있는 유용하고 확장 가능한 플랫폼입니다. 중소 규모 기업의 경우, DHCP 기반 적용을 통해 구현 및 관리 비용을 절감할 수 있으므로 많은 혜택을 얻을 수 있습니다. NAP은 Windows Server "Longhorn"의 가장 중요한 장점으로 기업의 보안 및 정책 준수 효과를 높여줄 수 있습니다.
NAP 리소스
  • 네트워크 액세스 보호
  • 테스트 환경에서 네트워크 액세스 보호를 위한 동적 호스트 구성 프로토콜 적용 설정
  • 네트워크 액세스 보호 파트너
  • "네트워크 액세스 보호 소개" 백서 웹 캐스트

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


 The Desktop Files: Windows 배포 서비스 재검토
The Desktop Files
Windows 배포 서비스 재검토
Wes Miller

필자는 최근 몇 차례의 칼럼에서 Windows Vista 및 차기 버전의 Windows Server(코드명 "Longhorn")와 관련된 배포 기술에 대해 설명했습니다. 소프트웨어에서 한 가지 확고부동한 사실이 있다면 바로 그것이 변화한다는 것입니다. 이에 따라 필자는 Windows Server® "Longhorn"에서 제공될 WDS(Windows 배포 서비스)와 관련하여 약간의 업데이트 내용을 준비했습니다.
또한 지난 몇 달 동안 토론에 참여하며 수집한 질문과 독자들이 제기한 질문 중에서 ImageX, WDS, Windows® PE와 관련된 몇 가지 질문에 대해 본 칼럼을 통해 답변을 드리고자 합니다.

새로운 기능과 향상된 기능
WDS를 처음으로 구상했을 때는 Windows Server 2003에 추가 기능으로 제공된 WDS와 추후 Windows Server "Longhorn"에 제공될 WDS가 기능면에서 거의 같았으면 좋겠다고 생각했습니다. 그러나 Windows Server "Longhorn"의 WDS 개발 팀이 부지런히 작업하는 과정에서 향후 서버 플랫폼의 WDS에 독보적인 세 가지 새로운 핵심 기능을 개발하게 되었습니다.
멀티캐스트 배포, 향상된 TFTP 다운로드 성능, x64 시스템에 대한 EFI(Extensible Firmware Interface) 네트워크 부팅 지원이 바로 그것입니다. 이러한 기능은 WDS 사용자 및 관리자 모두에게 중요하고 매우 유익한 기능입니다. 지금부터 무엇이 새로운지 하나하나 살펴보도록 하겠습니다. 그런데 이 기능은 다음 버전의 Windows Server 2003용 WDS에는 포함되지 않을 예정이므로 참고하시기 바랍니다.

멀티캐스트
필자가 Windows 팀에 합류하기 꽤 오래전부터 멀티캐스트는 RIS(원격 설치 서비스)를 위해 가장 활발하게 논의되고 요구되는 사항 중의 하나였으며, 심지어 Windows 배포에서도 일반적으로 필요한 기술이었습니다. 다른 회사의 배포 기술을 사용하고 있던 고객들은 멀티캐스트 배포가 어떤 역할을 하는지 이미 알고 있었습니다. Microsoft에서는 몇몇 특정 경우에 맞는 배포 기술, 그 중에서도 특히 ADS(자동 배포 서비스)에서 멀티캐스트를 구현했지만 OEM 및 엔터프라이즈 배포에는 이를 제공하지 않았습니다. 따라서 배포 관련 상담을 할 때마다 OEM 고객이나 엔터프라이즈 고객으로부터 이 기능을 자주 요청받게 되었습니다.
멀티캐스트의 가장 큰 장점은 여러 대의 컴퓨터가 동시에 통신 내용을 받을 수 있다는 것입니다. 즉, 보내는 쪽(이 경우에는 WDS 서버)에서 정보를 단 한 번만 보내면 되는 것입니다. 정보를 받기 위해 각 클라이언트는 전체 통신 내용을 수신해야 합니다. 모든 클라이언트는 동시에 하나의 특정 네트워크 주소에서 보내는 정보만 수신하므로 두 가지 이점을 얻을 수 있습니다. 첫째는 여러 대의 클라이언트가 같은 작업을 수행하므로 네트워크 병목 현상이 감소되어 배포 속도가 향상되며, 둘째는 모든 클라이언트가 하나의 스트림을 수신하므로 네트워크 정체가 줄어듭니다.
멀티캐스트의 단점은 예전부터 지금까지 멀티캐스트 자체의 인프라에 있다고 할 수 있습니다. 우리가 어린 시절 즐겨 하던 "전화" 놀이를 한번 떠올려 보십시오. 아마도 이 놀이의 단계는 다음과 같을 것입니다.
  1. 옆에 있는 두 번째 사람에게 말을 건넵니다.
  2. 두 번째 사람이 그 말을 듣습니다.
  3. 그리고 두 번째 사람은 세 번째 사람에게 이 말을 반복하여 전합니다.
  4. 놀이에 참여한 모든 사람에게 이 순서가 반복됩니다.
멀티캐스트가 지닌 고유의 문제는 네 명의 사람에게 전체 말을 전하기 위해서는 이 네 사람이 모두 같은 방에 있어야 하고 동시에 같은 말을 들어야 한다는 데 있습니다. 만약 다섯 번째 사람이 방으로 들어오고 바로 그때 말을 듣지 못했을 경우에는 말 전체를 다시 반복해야 할 것입니다.
멀티캐스트도 대체로 같은 방식으로 작동합니다. 말을 건네는 대신 바이너리 이미지(일반적으로 섹터 기반 디스크 이미지)를 네트워크를 통해 보낼 뿐입니다. 이미지를 받아야 하는 모든 클라이언트는 이미지가 처음 브로드캐스트되었을 때 바로 준비되어 있지 않으면 큐에 대기하고 있어야 합니다. 더욱 성가신 일은 클라이언트가 네트워크 문제나 성능 문제로 다량의 데이터를 손실할 경우 전체 디스크 이미지를 받았는지 확신할 수 없으므로 통신 큐에서 완전히 제거되거나, 클라이언트에 발생한 문제의 요구 사항에 맞추기 위해 전체 그룹의 속도를 낮춰야만 한다는 점입니다. 수백 개의 시스템을 동시에 배포한다고 가정할 경우 모든 클라이언트가 동시에 부팅되고 한 클라이언트의 속도 저하가 다른 클라이언트에는 영향을 주지 않아야 한다는 점이 멀티캐스트 시스템 설계에서 주로 중점을 두어야 하는 부분이었습니다.
그러나 WDS 팀에서 새로운 멀티캐스트 엔진을 제공함에 따라 상황이 완전히 달라졌습니다. 이 엔진은 파일 기반 WIM(Windows 이미징 형식) 인프라의 장점을 활용하면서 매우 특별한 몇 가지 기능을 제공합니다. 다른 회사에서 제공하는 멀티캐스트 소프트웨어를 통해서도 같은 수준의 멀티캐스트 시나리오를 수행할 수 있지만, WDS용 멀티캐스트 솔루션을 사용하면 훨씬 다양한 이점을 얻을 수 있습니다.
첫째, 전송 중에 언제든지 클라이언트 컴퓨터가 참가할 수 있습니다. 멀티캐스트 브로드캐스트는 파일 스트림을 "라운드 로빈" 방식으로 브로드캐스트하여 모든 클라이언트 컴퓨터의 요구 사항이 충족될 때까지 계속합니다. 따라서 클라이언트가 언제 온라인이 되는지는 문제가 되지 않습니다. 클라이언트는 WDS 서버를 수신하며, 서버에서 이미지 파일 브로드캐스트를 완료하면 처음부터 다시 브로드캐스트가 시작됩니다. 파일을 놓칠 경우 클라이언트는 해당 파일이 다시 제공될 때까지 수신하면 됩니다. 회전목마의 원리를 생각해 보십시오.
둘째, 완전히 새로운 프로토콜로 정체 및 흐름 제어 기능을 제공합니다. 즉, 기존의 네트워크 통신을 방해하지 않고도 프로덕션 네트워크에서 제대로 작동합니다. 일부 멀티캐스트 솔루션에서 입증된 것처럼 네트워크 관리자가 일반적으로 우려하는 것은 실제로는 보다 효율적으로 통신하기 위해 멀티태스크 솔루션을 사용하지만 이로 인해 네트워크에 트래픽이 쇄도하게 되는 것입니다.
셋째, 이 솔루션은 WDS 및 Active Directory®와 독립적으로 설계되었다는 점입니다. 이는 이 솔루션을 활용하는 데 Active Directory가 필요하거나 활성 WDS 구현이 필요하지 않다는 것을 의미합니다. ImageX 멀티캐스트는 독립적으로 수행될 수 있으며 그 자체로 다양한 시나리오에 사용될 수 있습니다. 멀티캐스트 클라이언트는 Windows Server "Longhorn"(및 Windows PE 관련 릴리스), Windows Vista™, Windows XP SP2(서비스 팩 2), 또는 최근에 릴리스된 Windows Server 2003 SP2에서 실행할 수 있는 명령줄 응용 프로그램입니다.
WDS MMC 및 WDSUtil 응용 프로그램에는 멀티캐스트를 설정하고 구성할 수 있는 여러 가지 새로운 관리 작업이 있습니다. 또한 멀티캐스트가 사용되고 있음을 알려 주도록 WDS 클라이언트의 사용자 인터페이스가 변경되었습니다.
WDS 관리 도구를 사용하면 관리자가 전송에서 제거되는 클라이언트를 비롯하여 클라이언트로의 전송 과정을 실시간으로 모니터링할 수 있습니다. 또한 이 관리 도구는 전체 로깅 및 보고 기능을 제공하는데, 관리자는 이를 통해 설치 환경을 로깅할 수 있습니다. 이 기능은 RIS에서는 전혀 제공되지 못했던 기능입니다.
Windows Server "Longhorn" WDS의 멀티캐스트는 최근 필자가 들은 가장 반가운 소식 중 하나입니다. OEM 및 엔터프라이즈 고객들이 자주 요청했던 바람을 충족시킬 수 있게 되어, 그것도 아주 충분히 충족시킬 수 있게 되어 정말 기쁩니다.

향상된 TFTP 다운로드 성능
TFTP(Trivial File Transfer Protocol)는 PXE(Pre-boot eXecution Environment)의 핵심 구성 요소이며 그 자체로 RIS 및 현재의 WDS에 모두 중추적인 역할을 하는 요소입니다. TFTP를 선택한 가장 큰 이유는 네트워크 효율성이나 견고성 때문이 아니라 그 크기가 매우 작기 때문입니다. TFTP는 안전하지 않은 UDP 기반 상태의 비저장 프로토콜로, 시스템이 네트워크에서 PXE 부팅하기 위해 부팅 ROM에 캡슐화됩니다.
Windows Server "Longhorn"의 경우 TFTP 다운로드 시간을 크게 향상시킬 수 있도록 TFTPD(TFTP Daemon)가 완전히 새로 작성되었습니다. 이는 가장 큰 개선점이라고 할 수 있으며 이제 모든 WDS 배포가 RAM 이미지에서 Windows PE 부팅을 기반으로 이루어집니다. 이러한 사실은 Windows Server 2003에서 RIS 또는 WDS를 통해 Windows PE를 다운로드하는 성능이 개선되기를 바랬던 고객들에게 희소식이 될 것 같습니다.
PC 체제가 오늘날 x86 PC의 백본인 유비쿼터스 BIOS에서 EFI로 옮겨감에 따라, Microsoft에서는 BIOS가 아닌 EFI를 사용하여 부팅하는 새로운 x64 서버 시스템과 연동될 수 있도록 WDS를 준비했습니다. WDS에 포함된 기능을 사용하면 x64 클라이언트 시스템이 WDS 서버에서 PXE 부팅을 수행할 수 있습니다.

질문
지금까지 약간의 WDS 업데이트 내용을 살펴보았는데, 본 칼럼의 나머지 부분에서는 필자가 전자 메일을 통해 받은 독자들의 질문이나 최근 온라인에서 논의된 질문에 답변해 드리고자 합니다. 이 질문들은 본 칼럼의 독자들도 일반적으로 관심을 가질 만한 것들이라고 생각됩니다.

Q: DHCP가 아닌 환경에서도 WDS를 사용할 수 있습니까? 제가 사용하고 있는 네트워크에서는 DHCP나 PXE 트래픽이 허용되지 않습니다.
A: 예. DHCP가 아닌 환경에서도 WDS를 사용할 수는 있습니다. 그러나 지원할 각 설치마다 고유의 IP 주소가 있어야 하고 고유의 CD 미디어를 만들어야 하므로 WDS 솔루션을 확장하기 어렵습니다. 설치에는 DVD 미디어를 사용하시는 편이 좋을 것 같습니다. DHCP 없이 WDS를 통해 설치해야 하는 경우에는 다음 단계를 수행하십시오.
  1. 정적으로 정의된 서버로 WDS Discover 이미지를 만듭니다(설치하려는 특정 WDS 서버를 가리킴).
  2. 이 대상 WDS 서버에서 DHCP 트래픽을 포트 4011로 허용합니다. DHCP를 사용하지 않더라도 이 방식으로 WDS 클라이언트가 서버와 핸드셰이크하므로 이를 허용해야 합니다.
  3. DHCP 대신 고정 IP 주소로 고유한 Windows PE 미디어를 만듭니다.
IP 주소 충돌을 피하기 위해 클라이언트 미디어가 고유해야 하며 네트워크의 특정 WDS 서버를 가리켜야 하기 때문에 이 방법은 사용하기 매우 까다롭습니다. WDS의 백본인 PXE는 그 자체가 DHCP를 기반으로 하기 때문에 WDS는 DHCP가 허용된 환경에서 훨씬 더 잘 작동합니다.

Q: WDS가 아닌 PXE 서버에서 Windows PE 2.0를 PXE 부팅하고자 합니다. 어떻게 해야 합니까?
A: 기술 자료 문서 support.microsoft.com/kb/926172의 지침을 참조하여 WDS가 아닌 PXE 서버에서 Windows PE 2.0을 작동시킬 수 있지만, Microsoft에서는 이를 제한적으로 지원하고 있음을 참고하시기 바랍니다.

Q: BDD란 무엇입니까? WAIK(Windows Automated Installation Kit)도 여기에 포함됩니까?
A: BDD(Business Desktop Deployment) 솔루션 액셀러레이터는 WAIK와 같은 Windows 배포 도구를 관리가 용이하고 반복할 수 있는 방식으로 사용하는 방법을 안내하는 프레임워크라고 할 수 있습니다. WAIK가 직접적으로 BDD에 포함되어 있지는 않지만, BDD는 WAIK를 비롯한 모든 필요한 도구를 모두 통합하여 해당 도구가 아직 설치되지 않은 경우 이러한 도구를 설치할 수 있도록 합니다. 따라서 엄밀히 말하자면 BDD는 WAIK를 포함하고 있지 않지만 제대로 작동하기 위해서는 WAIK를 필요로 합니다. BDD에 대한 자세한 내용은 microsoft.com/desktopdeployment를 참조하십시오.

Q: Windows Server 2003 시스템용 WDS는 어디에서 얻을 수 있습니까?
A: WDS는 WDS 디렉터리에 있는 WAIK 다운로드의 일부로 제공됩니다. go.microsoft.com/fwlink/?LinkId=85377을 참조하시기 바랍니다.

Q: 고정 IP 주소로 부팅하고 DNS 구성을 지원하려면 Windows PE 2.0을 어떻게 구성해야 합니까?
A: 고정 IP를 구성하려면 먼저 그림 1의 unattend.xml 샘플을 CD, USB 플래시 드라이브 또는 기타 부팅 가능한 미디어의 루트에 넣어 인식할 수 있도록 합니다. DNS를 지원하려면 다음 명령도 실행해야 합니다.
Figure 1 그림 1 unattend.xml (Close Figure 1)
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component
   name="Microsoft-Windows-TCPIP"
   processorArchitecture="x86"
   publicKeyToken="31bf3856ad364e35"
   language="neutral"
   versionScope="nonSxS"
   xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)"
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

Q: 파이버 채널 컨트롤러에서 Windows PE를 부팅할 수 있나요?
A: 예. 파이버 채널 HBA가 Int13을 통한 부팅 볼륨 등록을 지원해서 BIOS에 Windows PE의 부팅 가능한 볼륨으로 나타나면 가능합니다. 다른 기본 저장 컨트롤러 드라이버를 추가하는 것처럼 파이버 채널 컨트롤러 드라이버도 추가해야 합니다.

Q: Windows PE 2.0은 항상 RAMDisk에서 부팅됩니다. 제 시스템에 이렇게 부팅할 정도로 충분한 RAM이 없는데, RAMDisk를 사용하지 않고 Windows PE 2.0을 부팅할 수는 없을까요?
A: 예. 가능합니다. 특히 RAM이 256MB 미만인 시스템의 경우 Windows PE를 부팅하려면 RAMDisk를 사용하지 않도록 구현해야 합니다. Microsoft 기술 지원 문서에는 이러한 부팅 방법에 대한 설명이 수록되어 있습니다. 몇 가지 주의해야 할 사항이 있다면 RAMDisk를 사용할 때처럼 미디어를 교환할 수 없으며 RAMDisk 기반 버전의 Windows PE 2.0보다 느리게 부팅된다는 점입니다.

Q: DVD 이외의 미디어에서 Windows PE 2004 및 Windows PE 2005(1.5 또는 1.6)를 부팅하고 DVD의 이미지나 다른 데이터를 복사하려고 시도해 보았습니다. DVD에서 부팅하려는 게 아니라, 단지 데이터만 복사하려고 하는데 잘 되지 않습니다. Windows 전체 설치 환경에서는 DVD를 읽을 수 있지만, Windows PE에서는 볼륨이 손상되었거나 읽을 수 없다는 오류 메시지가 표시됩니다. 이 문제를 해결할 수 있을까요?
A: 예. 해결할 수 있습니다. 기본적으로 Windows PE 1.x에서는 UDF 형식의 미디어를 지원하지 않습니다. DVD는 원래부터 ISO 브리지 지원(ISO 및 UDF의 이중 형식) 또는 단순 UDF 형식으로 되어 있습니다. 이 문제를 해결하려면 Windows PE 설치 환경에 UDF 드라이버를 추가해야 합니다. 드라이버는 이미 내장되어 있으며, 단지 설치되지 않았을 뿐입니다. 드라이버를 설치하려면 다음을 수행하십시오.
  1. 메모장에서 I386(또는 Windows PE의 하드 디스크 설치 환경에서는 MiniNT) 디렉터리의 txtsetup.sif 파일을 엽니다.
  2. [CdRomDrivers.Load]라는 섹션을 찾고 cdfs.sys라는 드라이버 이름이 있는 줄을 찾습니다. 줄 아래에 udfs = udfs.sys 줄을 추가합니다. 입력 값이 다음과 같아야 합니다.
[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys
3. [CdRomDrivers]라는 섹션에서 cdfs라는 줄을 찾습니다. 줄 아래에 udfs = "Universal Disk File System" 줄을 추가합니다. 입력 값이 다음과 같아야 합니다.
[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"
4. txtsetup.sif를 저장한 다음 닫고, 필요한 경우 Windows PE 이미지를 다시 만듭니다. 이제 Windows PE에서 모든 UDF 형식의 DVD 미디어를 읽을 수 있습니다.

Q: 오래된 몇 대의 시스템에서 Windows XP를 실행하고 있는데 ACPI가 지원되지 않습니다. Windows Vista로 마이그레이션하거나 Windows XP를 다시 설치하기 위해 이들 시스템에서 Windows PE 2.0을 사용할 수 있을까요?
A: 아니요. 사용하실 수 없습니다. Windows PE 2.0은 ACPI(고급 구성 및 전원 인터페이스) 호환 시스템만 지원하며 현재 보유하고 계신 시스템에서는 부팅할 수 없습니다. 현재 시스템에서 Windows PE를 사용해야 한다면 Windows PE 1.6 이전 버전을 사용하시기 바랍니다.

Q: Visual Studio® 2005를 사용하여 Windows PE(1.x 또는 2.0)에서 실행할 응용 프로그램을 작성했습니다. 프로그램이 작동할 수 있을까요?
A: 응용 프로그램을 어떻게 작성했는지에 따라 달라집니다. 관리되지 않는 C++를 사용했다면 응용 프로그램이 작동되지만, C# 또는 J#과 같은 관리되는 코드 언어를 사용했거나 관리되는 C++ 코드로 작성한 경우에는 프로그램이 작동하지 않습니다. Microsoft® .NET Framework(모든 버전)는 Windows PE에서 사용할 수 없으므로 관리되는 코드는 실행되지 않습니다.

Q: Windows PE 2.0에서 사용할 저만의 응용 프로그램을 작성하고 있는데 도움이 필요합니다. 무엇을 참고하면 좋을까요?
A: Windows PE 개발자 가이드 백서부터 보시는 것이 좋겠습니다.

Q: CD에서 Windows PE 2.0을 몇 번이나 부팅했는데 RAMDisk 드라이브 문자가 항상 X로 표시됩니다. 실제로 부팅된 드라이브 문자가 무엇인지 알 수 있을까요?
A: 레지스트리를 보면 아래의 키에서 Windows PE가 처음에 부팅된 실제 드라이브 문자를 확인하실 수 있습니다.
HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
Windows PE 내에 타사 셸이 사용되어 이 키에 값이 없을 경우 다음 명령을 실행하면 정확한 값으로 업데이트됩니다.
start /w wpeinit UpdateBootInfo

Q: ImageX 및 WIM 파일을 사용하여 시스템을 백업할 수 있습니까?
A: 이론상으로는 가능하지만 권장하고 싶지는 않습니다. ImageX는 진짜 백업 도구처럼 잠긴 파일이나 열린 파일을 백업할 수 없습니다. 열린 파일과 잠긴 파일을 보호하려면 현재 사용하고 계신 진짜 백업 유틸리티를 계속 사용하시기 바랍니다.

Q: 압축하지 않은 WIM 파일을 캡처하면 압축된 동일한 볼륨 이미지보다 빨리 배포할 수 있습니까?
A: 그렇게 크게 시간이 단축되지는 않습니다. 압축으로 인해 캡처 작업이 오래 걸리기 때문입니다. 그러나 대상 시스템에 이미지를 적용하는 작업은 사용된 압축 유형(none, XPress, 또는 LZX)에 관계없이 시간이 특별히 오래 걸리지는 않습니다. 따라서 실제 필요한 이미지 크기와 캡처에 할애할 시간을 기준으로 압축 옵션을 선택하시는 것이 좋습니다.

Q: WIM 이미지를 디스크에 적용하려면 디스크의 파티션을 다시 나누고 포맷을 해야 하나요?
A: 예. 그렇습니다. 시스템의 빈 이미지를 적용하려면 우선 Diskpart 도구를 사용하거나 대상 파티션을 삭제하고 다시 만들어 디스크 볼륨을 정리해야 합니다. 또는 이미지를 적용하기 전에 디스크 볼륨을 완전히 포맷할 수도 있습니다.
또한 Windows Vista 이전의 Windows 버전에서 다른 부팅 섹터를 사용했고, 따라서 Windows PE 2.0을 사용하여 Windows Server 2003 이전 버전을 배포하는 경우에는 Windows PE 내에서 다음 명령을 실행하여 Windows 설정이 시작되거나 해당 WIM이 적용되기 전에 Windows Server 2003 이전 버전에서 부팅할 수 있는 섹터로 부팅 섹터를 설정해야 합니다.
bootsect /nt52 sys C: /force

결론
WDS 업데이트 내용과 여러 질문에 대한 답변이 흥미롭고 유익했기 바랍니다. 여러분의 모든 질문에 감사드리며 앞으로도 본 칼럼에서 기회가 되면 언제든지 답변을 드릴 수 있도록 최선을 다하겠습니다. 제 소개에 나와 있는 전자 메일 주소로 계속해서 많은 질문을 보내 주시기 바랍니다.
Windows Vista Hardware Assessment
Baldwin Ng

지금부터 한 달 전에 여러분이 제출한 건의 사항에 대해 마침내 상사가 좋은 반응을 보였다고 가정해 보겠습니다. 상사는 조직 전체에 Windows Vista를 보급하자는 여러분의 건의안을 심각하게 고려하고 있는 것이 분명하며, 단일 운영 체제를 관리함으로써 얻을 수 있는 이점과 비용 절감에 대해서도 인식하기 시작했습니다. 그러나 Windows Vista를 설치하기 위해 PC를 모두 교체하는 것이 과연 재정적으로 합당한 일인지 완전히 확신하지 못하고 있습니다. 따라서 상사는 현재 당장 Windows Vista로 마이그레이션할 수 있는 PC와, 시스템 메모리나 하드 디스크 공간을 늘리는 약간의 업그레이드만으로 마이그레이션할 수 있는 PC를 구체적이고 자세하게 알려 주는 정보를 원하고 있습니다. 그것도 이번 주 내로 말입니다. 자, 그럼 무엇부터 시작해야 할까요? 회사에 정통한 정보 제공자도 없고 정교한 네트워크 관리 도구도 없는 상황에서 어떻게 단 며칠 만에 답을 알아내야 할까요? 더욱이 회사에서 현재 보유하고 있는 네트워크 자산에 대한 정보도 충분히 전달하지 않은 채 선임자가 떠나버린 경우라면 문제가 더욱 심각해지겠지요.
Microsoft는 바로 얼마 전에 조직에서 Windows Vista에 대한 준비 현황을 파악하는 데 도움이 되는 Windows Vista Hardware Assessment라는 솔루션 액셀러레이터를 출시했습니다(microsoft.com/technet/wvha 참조). 이 도구는 네트워크를 통해 PC에 소프트웨어 에이전트를 설치할 필요 없이 네트워크의 모든 PC를 신속하게 평가하여 중간 규모 조직의 경우 불과 몇 시간 안에 하드웨어와 장비 호환성에 대한 세부적인 준비 현황 보고서를 생성합니다.
Windows Vista Hardware Assessment는 이전에 Microsoft ADS(Assessment and Deployment Solution)를 위해 개발된 강력한 인벤토리 수집 및 보고 기술을 기반으로 하며 다음 세 단계 프로세스를 통해 일련의 준비 현황 보고서를 만듭니다.

1. 하드웨어 인벤토리
이 도구는 WMI(Windows Management Instrumentation), Active Directory® 및 NetServerEnum과 같은 Windows 네트워킹 프로토콜을 사용하여 도메인의 컴퓨터와 작업 그룹 컴퓨터를 검색합니다. 인벤토리가 완료되면 모든 시스템 리소스 및 장치 정보가 SQL Server™ 2005 Express 데이터베이스에 저장됩니다. 이 도구의 최신 릴리스에서는 최대 5천 대의 컴퓨터에 대한 네트워크 검색을 지원하고 있습니다. 다음 릴리스에서는 보다 큰 규모의 네트워크를 지원하도록 확장될 예정입니다.

2. 호환성 분석
Windows 팀에서 가장 최신에 업데이트한 장치 및 BIOS 데이터베이스를 통해 이 도구는 하드웨어 및 장치 호환성과 관련하여 각 PC의 Windows Vista에 대한 준비 현황을 분석합니다. 또한 정기적으로 업데이트되는 웹 서비스에서 드라이버 정보를 가져오므로 도구를 실행할 때마다 최신 정보를 받을 수 있습니다.

3. 준비 현황 보고
마지막 단계는 준비 현황 보고서를 Microsoft Word 문서 및 Excel® 스프레드시트 양식으로 자동 생성하는 것입니다. 이 보고서에서는 준비 현황 정보와 함께 각 PC에 맞는 업그레이드 권장 사항을 제공합니다.
Windows Vista Hardware Assessment는 Business Desktop Deployment 2007 및 Windows Vista 보안 가이드를 비롯한 다른 Windows Vista 솔루션 액셀러레이터를 보완합니다. 자세한 내용은 Solution Accelerators 홈 페이지를 참조하십시오.

Baldwin Ng는 Microsoft 솔루션 액셀러레이터 팀에서 제품 관리자로 근무하고 있으며, 일반 고객이나 컨설턴트가 보다 신속하고 효과적인 방식으로 Microsoft를 적용할 수 있도록 자동화된 소프트웨어 도구를 만드는 데 주력하고 있습니다. 문의 사항이 있으면 Baldwin.Ng@microsoft.com으로 연락하시면 됩니다.

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


 Field Notes: 최신 감각 유지하기
Field Notes
최신 감각 유지하기
Joshua Hoffman

필자도 한때는 IT 현장의 전문가였습니다. 약 2년 전 지금의 역할(이 멋진 TechNet Magazine의 기술 편집자)을 맡기 전에는 현장에서 열심히 활동했었지요. Microsoft Consulting Services에서 5년을 보내고 다양한 Fortune 100대 기업의 IT 부서에서 수년을 근무했던 필자는 지금의 이 자리로 이끌려 오게 되었습니다. 절대 불평하는 것은 아닙니다. 여기서 함께 일하는 사람들도 정말 좋고, 게다가 독자 여러분과 함께 할 수 있게 되었으니까요! 그리고 월요일 아침 6시에 출근을 위해 비행기를 타야 할 일이 다시 없다면 더욱 좋을 것입니다.
그런데 이 새로운 일에도 아쉬운 점이 있답니다. 많은 IT 전문가들이 공감하겠지만, 이 분야에서 새로운 것을 배우고 늘 최신 지식을 보유하기 위해서는 실제로 경험해 보는 것이 최상의 방법입니다. 현장에서 직접 체험하는 것이 가장 효과적인 교육 수단인 셈이지요. 그러나 경력이 쌓이고 직무가 변하다 보면 언젠가는 더 이상 직접 시스템이나 인프라를 관리하지 않는 IT 전문가가 됩니다. 그리고 상황은 매우 빠르게 변해갑니다. 필자가 이 새로운 역할을 맡은 이후 새로운 배포 프레임워크, 새로운 보안 인프라, 새로운 네트워크 스택 및 몇 가지 새로운 기능이 추가된 새로운 버전의 Windows®가 개발되었습니다. Office도 새로운 버전이 나왔고 Exchange Server, SQL Server™ 및 Microsoft® Operations Manager의 새 버전은 물론 몇 가지 새로운 도구도 등장했습니다. 게다가 Windows PowerShell™, MMC 3.0 및 Windows 자동 설치 키트도 새 버전이 출시되었습니다. 혹시 빠진 것이 있나요?
단 2년 만에 실로 많은 변화가 생길 수 있는 것입니다. 그런데 최상의 학습 방법이 직접 해보는 것이고 자신의 직무가 더 이상 "직접 경험"할 수 없는 상황이라면 어떻게 항상 최신 정보를 얻을 수 있을까요?
우선 이 TechNet Magazine이 큰 도움이 될 것입니다. 필자에게는 분명 그렇습니다. TechNet Magazine은 자신의 분야에서 진정한 전문가인 많은 기고가들을 보유하고 있으며 필자 자신도 이들의 전문 지식으로부터 꾸준히 도움을 얻고 있습니다. 그러나 가끔은 정말로 실제 경험이 필요할 때가 있습니다. 그래서 필자는 주로 Microsoft 웹 사이트에서 무료로 다운로드할 수 있는 Virtual PC 또는 가상 서버를 사용합니다. 다운로드 섹션에서 필요한 링크를 찾아보실 수 있습니다. 가상화 기술을 사용하여 Active Directory®를 간단히 구축하거나 랩톱에서 바로 Windows Vista™ 배포를 사용자 지정할 수도 있습니다. 별도의 하드웨어는 필요 없습니다. 이렇게 프로세스를 직접 수행해 보면 기능의 작동 방식을 이해하는 데 큰 도움이 됩니다.
Virtual PC의 유일한 문제는 가상 환경을 실제로 구축(OS를 설치하고 모든 요소를 적절히 구성하는 등)해야 한다는 점입니다. 이런 과정을 배우고 싶다면 아주 좋은 기회가 되겠지요. 그런데 제품의 특정 기능만 살펴보고 싶다면 어떻게 할까요? 예를 들어 Exchange Server 2007의 새로운 규정 준수 기능을 확인하고 싶다면 어떻게 해야 할까요? Windows Server®, Active Directory 및 Exchange Server를 처음부터 설치 및 구성하려면 보통 어려운 일이 아닐 것입니다. 이런 경우에는 TechNet 가상 랩을 이용하십시오. 필자의 소견으로는 이 가상 랩이 앞으로 꽤 오랫동안 최고 수준의 교육 리소스 역할을 할 것으로 생각됩니다. 가상 랩 팀은 이미 까다로운 작업도 마쳤습니다. 즉, 20여 가지 제품을 다양한 방식으로 결합하여 사전 설치 및 구성을 완료한 180대 이상의 가상 시스템을 갖춘 것입니다. 각 시스템은 사용자에게 일반적인 작업과 새로운 기능을 안내하는 일련의 교육용 연습 환경도 제공합니다. 그리고 가장 좋은 점은 전체 프로세스가 Microsoft 관리 서버에서 호스팅되는 브라우저 환경에서 실행되기 때문에 사용자 자신의 하드웨어 리소스를 사용할 필요가 없다는 것입니다.
더 이상 현장에서 활동하지 않는다면 최신 감각을 유지하기가 어렵지만, 아주 불가능한 것은 아닙니다! 필자가 자주 사용하는 리소스 몇 가지를 이렇게 설명해 보았습니다. 필자의 좋은 친구인 Edward Dake가 몇 달 전 칼럼에서도 언급했듯이 가장 좋은 리소스는 역시 서로의 경험과 지식을 나누는 것입니다. 도움이 필요하면 언제든지 말씀해 주십시오.

Joshua Hoffman은 TechNet Magazine의 기술 및 감수 편집자입니다.


 Windows Confidential: 자주 사용하는 프로그램 목록
Windows Confidential
자주 사용하는 프로그램 목록
Raymond Chen

시작 단추를 클릭하십시오. 그러면 시작 메뉴가 나타나고 왼쪽에 프로그램 목록이 표시됩니다. 이 프로그램 목록은 어떻게 선택된 것일까요? 이 목록은 사용자가 최근에 가장 자주 실행한 프로그램이 시작 메뉴의 첫 부분에 나타나야 한다는 원칙에서 시작되었습니다. 이 원칙에는 보다 섬세한 조정이 필요하다는 것을 곧 깨닫게 되었지만요.
기본 규칙은 사용자가 프로그램을 실행할 때마다 포인트가 적립되는 것입니다. 반대로 프로그램을 오랫동안 실행하지 않으면 포인트를 잃게 됩니다. 시작 메뉴는 이 포인트가 가장 높은 프로그램을 보여 줍니다. 간단하지요? 그런데 사용자들이 혼란을 느끼는 선택 알고리즘은 이것이 아닙니다. 기본 규칙을 적용한 다음에는 세부 조정 작업이 수행되는데 바로 이것이 까다로운 부분이지요.
세부 조정 작업을 시작하기 전에 먼저 기본 규칙에서 몇 가지 사항을 명확히 해 둘 필요가 있습니다. 여기서 규칙은 바로 가기가 아니라 프로그램 실행에 적용되는 것입니다. 일부 프로그램의 경우 바로 가기를 여러 개 설치하며, 프로그램 실행에 어떤 바로 가기를 사용하는지는 문제가 되지 않습니다. 여러 개의 바로 가기가 모두 같은 실행 파일로 연결된다면 이러한 바로 가기를 사용할 때마다 해당 프로그램의 포인트가 적립됩니다.
시작 메뉴
이것은 또한 프로그램을 실행할 때 반드시 시작 메뉴를 사용하지 않아도 탐색기에서 실행하기만 하면 포인트가 적립된다는 뜻이기도 합니다. 예를 들어 폴더를 열고 실행 파일을 두 번 클릭하여 프로그램을 직접 실행하더라도 포인트가 적립되어 결국 시작 메뉴의 첫 페이지에 표시될 수 있는 것입니다.
프로그램이 충분한 포인트를 얻어 시작 메뉴의 첫 페이지에 표시될 수 있고 프로그램에 해당하는 바로 가기가 여러 개인 경우 Windows®는 여러 개의 바로 가기 중에 어떤 바로 가기 아이콘을 표시할지 결정해야 합니다. 이 경우 당연한 일이지만 가장 자주 사용되는 바로 가기를 제외하고 나머지 연결은 끊어집니다.
세부 조정을 수행하는 도중 일부 프로그램은 목록에서 필터링됩니다. 예를 들어 사용자가 직접 시작 메뉴에 포함한 프로그램이 더 이상 나타나지 않을 수 있습니다. 같은 프로그램의 아이콘을 두 개나 표시할 필요는 없으니까요. 어쨌든 사용자는 자주 실행하는 프로그램을 시작 메뉴에 포함하기 때문이지요.
또 다른 세부 조정 단계에서는 필터링을 통해 노이즈를 제거합니다. 추가 정보 파일을 표시하기 위한 바로 가기의 예와 같이 메모장이나 워드패드와 같은 일반적인 도우미 프로그램에 대한 바로 가기가 표시되는 경우가 많았습니다. 이러한 바로 가기는 일종의 메모장 대표로 선택되지 않도록 필터링을 통해 제거해야 했습니다. 또한 응용 프로그램 등록 시 NoStartPage 값을 생성하여 시작 메뉴의 첫 부분에 포함될 자격이 없는 프로그램으로 등록할 수도 있습니다.
기본 규칙에서는 한번 시작하여 오랫동안 계속 실행하는 프로그램도 고려되지 않았습니다. 규칙을 엄격하게 해석할 경우 이런 프로그램은 처음 실행될 때 포인트가 적립되고 이후에는 포인트를 잃게 됩니다. 그렇지만 여기서 "자주"란 "끊임없이 계속"의 의미이기도 하지요! 따라서 다른 규칙을 추가했습니다. 즉, 프로그램이 계속 실행되는 일수마다 포인트가 적립됩니다. 이렇게 하면 실제로 실행되는 다른 프로그램보다 과도하게 많지 않은 적정한 수준으로 프로그램에 포인트가 계속 적립됩니다. 따라서 항상 실행하는 프로그램을 포인트 적립을 위해 자주 다시 시작할 필요가 없는 것입니다.
Windows Vista™에서는 몇 가지 세부 조정 규칙이 추가되었습니다. 예를 들어 한 번도 시작 메뉴에서 실행한 적이 없는 프로그램의 바로 가기를 선택할 때 이제 명령줄 매개 변수가 없는 바로 가기가 우선적으로 선택됩니다. 또한 포인트에 상관없이 가장 최근에 실행한 프로그램은 항상 목록에 표시됩니다.

Raymond Chen은 자신의 웹 사이트 The Old New Thing 및 동명의 저서(Addison-Wesley, 2007)에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있습니다. 궁금한 사항은 전화를 주시면 선착순으로 답변해 드립니다.