7월 2008 7월 2008
IIS: 새로워진 IIS 7.0으로의 이전
인터넷 정보 서비스 7.0은 새로운 표준을 설정하고 근본적으로 개선된 성능을 제공하며 웹 환경 통합을 위한 새 기능을 도입했습니다.가장 주목할 만한 향상된 성능을 살펴보고 웹 응용 프로그램을 테스트, 스테이징, IIS 7.0으로 마이그레이션하는 방법에 대해 자세히 알아 보십시오. Fergus Strachan
통신 및 공동 작업: 통합 메시징으로 마이그레이션 계획
마이그레이션 계획을 충실히 마련해 둔다면 최종 사용자의 업무 중단을 최소화하면서 기존 음성 메일 시스템을 통합 메시징 플랫폼으로 전환하는 작업을 매우 쉽게 수행할 수 있습니다.이 칼럼에서는 조직 내에서 마이그레이션을 계획하고 새 시스템을 테스트하고 통합 메시징을 구현할 경우 알아야 할 사항에 대해 알아봅니다. Jeff Goodwin
통신 및 공동 작업: OCS 2007의 강력한 음성 기능
Microsoft Office Communication Server는 기업의 전화 통신에 중요한 변화를 가져옵니다.음성 통화를 위해 전화를 거는 방법을 단계별로 알아보고, 다양한 끝점에 통화를 연결하는 방법을 배웁니다. 그리고 OCS 통신에서 대화의 중요성에 대해 살펴봅니다. Rajesh Ramanathan
통신 및 공동 작업: Groove와 SharePoint로 만드는 강력한 연결
Microsoft Office Groove와 SharePoint Server는 모두 강력한 공동 작업 기능을 제공합니다.두 제품이 어떤 점에서 다르고 어떤 점에서 서로 보완하는지 비교해 보고, Groove와 SharePoint를 통합하여 서로 다른 위치에 있는 사용자를 지원하는 쉽고 유연한 공동 작업 솔루션을 제공하는 방법에 대해 알아 보십시오. Alan Maddison
Windows 관리: Windows Server 2008 Failover Clustering 소개
수년간 사용자들은 Windows Server의 클러스터링이 너무 복잡하다는 불만을 호소해 왔으나 이제Windows Server 2008의 출시와 함께 클러스터링이 완전히 다시 태어났습니다.새 장애 조치(failover) 클러스터링에서 가장 괄목할 만한 사항을 몇 가지 살펴보고 어떻게 이 새 구현을 통해 클러스터 설치 및 유지 관리가 더 쉬워졌는지 알아봅니다. Chuck Timon
Columns
From the Editor: 인쇄의 시대는 갔다.: | Letters: 독자의 목소리: | Toolbox: IT 전문가를 위한 신제품:
Exchange Queue & A: 부하 분산, Edge 전송 및 기타 정보: Exchange와 관련하여 궁금한 점이 있으십니까?이번 달 기사에서는 Exchange를 SharePoint와 함께 사용하는 방법, 대기 연속 복제 관련 작업, Windows Server 2008에 Exchange 2007 사서함 서버를 설치하는 방법 등에 대한 질문에 답합니다.Henrik Walther | Utility Spotlight: Microsoft SharedView: 다른 도시에 있는 사람과 빠르게 공동 작업할 수 있는 방법을 찾고 계십니까?소규모 그룹의 구성원과 물리적 경계를 넘어서 문서와 화면을 쉽게 공유할 수 있게 해주는 무료 유틸리티인 Microsoft SharedView에 대해 알아보십시오.Greg Steen | Inside SharePoint: Office 응용 프로그램 통합: Microsoft Office 응용 프로그램과 SharePoint를 통합하고 서로 통신하는 방법을 확인하고, 동일한 방법을 통해 타사 응용 프로그램과 SharePoint를 통합하는 방법에 대해서도 살펴보시기 바랍니다.Pav Cherny
Windows PowerShell: 드롭 상자: Don Jones가 필터링 함수, 파이프라인, 사용자 지정 개체에 대해 설명하며 Windows PowerShell의 이해를 돕도록 탁구공을 이용하여 설명합니다.Don Jones | Hey, Scripting Guy!: 짜릿한 흥분: Scripting Guy로부터 흥미로운 스크립팅에 대해 들어보고 스크립트를 사용하여 Windows Vista 및 Windows Server의 2008새 부팅 구성 데이터 저장소에 액세스하는 방법을 알아봅니다.Microsoft Scripting Guys | The Desktop Files: 네트워크 부팅 Windows: 원격 설치 서비스(RIS)의 변천 과정과 Microsoft에서 사용하는 그 밖의 PXE 관련 기술에 대해 알아봅니다.Wes Miller
Security Watch: 암호와 신용 카드 - 제1부: 3부작으로 구성된 이 시리즈의 1부에서는 일반적인 보안 관련 권장 사항 및 관행이 얼마나 시대에 뒤떨어지는지, 실제로 보안을 유지하는 데 어떤 식으로 방해가 되는지 알아봅니다.Jesper M. Johansson | Field Notes: 선거의 정확성 확보: 오늘날 미국 선거 시스템의 취약성을 살펴보고 완전히 검증할 수 있는 선거 결과를 보장하기 위해 암호화를 사용하는 방법에 대해 알아봅니다.Josh Benaloh | Windows Confidential: 공간을 차지하는 이전 도구: Microsoft Bob은 여러분이 생각하는 것보다 훨씬 널리 퍼져 있습니다.Raymond Chen이 Microsoft Bob이 수백만 가정에 어떤 식으로 침투되었는지에 대해 설명합니다.Raymond Chen


IIS
새로워진 IIS 7.0으로의 이전
Fergus Strachan
한 눈에 보기:
  • 웹 팜 환경에 IIS 7.0 배포
  • 향상된 보안 및 성능
  • IIS 6.0에서 IIS 7.0으로 ASP.NET 웹 응용 프로그램 마이그레이션
  • IIS 7.0으로 PHP 웹 응용 프로그램 마이그레이션

목차
준비, 설치, 테스트
테스트 설정
IT 관리자를 위한 중요 향상
IIS 아키텍처
통합 모드와 클래식 모드
모듈 및 기능
웹 응용 프로그램 마이그레이션
맺음말
Microsoft의 IIS 팀에 따르면 IIS(인터넷 정보 서비스) 7.0은 IIS 역사상 가장 큰 릴리스입니다.이 버전은 새로운 표준을 설정하고 근본적으로 개선된 성능을 제공하며
웹 환경 통합을 위한 새로운 기능을 도입했습니다.Windows Server® 2008 및 Windows Vista® SP1에 포함된 IIS 7.0은 이미 Microsoft.com을 구동하고 있으며, 다수의 웹 호스팅 기업이 기존 웹 응용 프로그램을 새 웹 서버 플랫폼에 이식하려는 웹 디자이너 및 개발자에게 IIS 7.0 호스팅 서비스를 제공하기 시작했습니다.
이번 기사에서 필자는 IT 전문가에게 가장 중요한 IIS 7.0의 주요 향상된 기능에 대해 살펴본 후 ASP.NET 및 PHP 웹 응용 프로그램을 마이그레이션하는 방법에 대해 자세히 설명하려고 합니다.그러나 기본 프로덕션 환경과 비슷한 테스트 환경에 대해 먼저 간략히 짚고 넘어가겠습니다.
이는 중요한 단계입니다.시간이 걸리더라도 IIS 7.0을 프로덕션 서버에 배포하기 전에 웹 응용 프로그램이 새 웹 서버에서 순조롭게 실행될 수 있도록 테스트 환경에서 철저한 테스트를 수행할 필요가 있습니다.

준비, 설치, 테스트
필자의 테스트 환경에는 Windows Server 2003 및 IIS 6.0(ASP.NET 응용 프로그램 호스팅)을 실행 중인 시스템과 Ubuntu 7.10 Linux 배포 및 Apache HTTP Server 2.2(PHP 기반 웹 응용 프로그램 호스팅)를 실행 중인 서버가 있습니다.테스트의 궁극적인 목표는 스테이징 및 프로덕션 시스템에 Windows Server 2008을 배포한 다음 IIS 6.0 및 Apache 인스턴스를 IIS 7.0으로 교체하기 위해 복잡한 웹 응용 프로그램으로 전환하는 것입니다.
두 가지 주요 웹 응용 프로그램으로DotNetNuke 4.7 및 osCommerce 3.0a4가 있습니다.DotNetNuke는 ASP.NET 2.0과 Microsoft® SQL Server®에 기반한 웹 응용 프로그램 프레임워크이고,osCommerce는 PHP와 MySQL을 기반으로 하며 모든 기능을 갖춘 전자 상거래 솔루션의 최신 알파 버전입니다.이제 이 고급 응용 프로그램들을 IIS 7.0으로 옮겨 보겠습니다.
여기서 소프트웨어 버전이나 제품 또는 플랫폼을 비교하려는 의도는 없음을 분명히 말씀드리고 싶습니다.하지만 Windows Server 2008 및 IIS 7.0 표준에 맞출 경우 많은 이점이 있다는 점을 강조하고 싶습니다.이를테면, 관리의 복잡성이 줄어들고 실행 중인 전체 웹 서버 수를 최소화할 수 있습니다.
그림 1은 이 글에 사용된 테스트 환경을 간략하게 보여 줍니다.자신의 테스트 환경에서 필자의 설명 내용을 따라 하려면 TechNet Magazine 웹 사이트(technetmagazine.com)의 코드 다운로드 섹션에서 구할 수 있는 첨부 자료에서 필수 소프트웨어 구성 요소에 대한 링크 및 자세한 단계별 설치 지침을 볼 수 있습니다.
그림 1 IIS 7.0 신규 도입을 위한 테스트 환경(크게 보려면 이미지 클릭)
본 기사를 마무리할 무렵 Microsoft에서 IIS 6.0 및 7.0으로의 웹 응용 프로그램 배포, 동기화 및 마이그레이션을 지원하기 위한 명령줄 도구(MSDeploy.exe)를 출시했으며,필자는 이 도구를 권하는 바입니다.Microsoft 웹 배포 팀 블로그(go.microsoft.com/fwlink/?LinkId=118272)에서 자세한 내용을 볼 수 있습니다.

테스트 설정
본 기사를 집필하는 동안 Windows Server 2008이 시험판이어서 도메인 컨트롤러나 데이터베이스 서버에서 Windows Server 2003을 교체하지 못했습니다.공식 Windows Server 2008 버전이 출시되면서 Active Directory® 인프라의 마이그레이션도 고려하고 계실 수 있겠지만,SQL Server® 2005 및 MySQL 데이터베이스를 SQL Server 2008로 마이그레이션하는 방법은 이 글에서 논외로 합니다.
필자는 SQL Server 2005(서비스 팩 2 포함)보다 더 설치하기 쉽다는 이유에서 SQL Server 2008을 스테이징 서버에 배포했습니다.DotNetNuke는 SQL Server 2008 데이터베이스와 함께 실행하는 데 문제가 없었고Windows Server 2008에 MySQL 5.0을 설치하는 데에도 별다른 어려움이 없었습니다.
IIS 7.0은 Server Core에서 사용 가능하지만, 필자는 테스트의 특정 요구 사항 때문에 Server Core 설치를 사용하지 않았습니다.필자의 스테이징 서버에는 주 테스트 시스템으로서 전체 설치가 필요하기 때문입니다.게다가, Server Core에서는 Microsoft .NET Framework를 사용할 수 없습니다.
PHP는 Server Core에서 잘 실행되지만 ASP.NET 및 PHP 응용 프로그램의 통합이라는 이 테스트의 목적상 Server Core는 선택 범위에서 제외하기로 했습니다..NET Framework가 Server Core에서 지원되기 전까지는 ASP.NET 응용 프로그램을 지원하기 위해 전체 설치를 수행해야 합니다.테스트 환경 설치에 대한 자세한 단계별 지침은 첨부 자료의 01_install_testlab.htm 파일을 참조하십시오.
필자는 기존 서버에서 업그레이드하지 않고 Windows Server 2008을 완전히 새로 설치하기로 했습니다.무엇보다도, 새로 설치할 경우 그림 2의 시나리오와 같은 단계적 마이그레이션 시나리오를 구현하기가 더 쉽습니다.모든 관련 웹 응용 프로그램 구성 요소를 스테이징 서버에서 성공적으로 테스트한 후 새 IIS 7.0 웹 팜으로 이동할 때까지 기존 웹 팜 실행을 유지한다는 전략입니다.
그림 2 IIS 7.0으로의 단계적 전환(크게 보려면 이미지 클릭)
환경의 복잡도에 따라 기존 웹 응용 프로그램을 모두 한 번에 옮기거나 단계적으로 이동할 수 있습니다.각 웹 응용 프로그램 또는 사이트별로 새 웹 팜에 대한 최종 수용 테스트를 수행한 후에 브라우저를 새 IIS 7.0 웹 팜으로 지정하도록 해당 DNS 레코드를 변경함으로써 전환할 수 있습니다.이렇게 하면 가동 중지 시간 및 중단을 최소화할 수 있습니다.

IT 관리자를 위한 중요 향상
MSDN® Magazine에서 Mike Volodarsky의 "Windows Vista 및 그 이상의 웹 서버를 위한 탐색(msdn2.microsoft.com/magazine/cc163453.aspx)"이라는 기사를 참조하면 IIS 7.0의 향상된 기능에 대해 빠르게 살펴볼 수 있습니다.
Microsoft.com 팀의 블로그 게시물인 "최상의 기능 소개(go.microsoft.com/fwlink/?LinkId=117436)"도 유익한 참고 자료가 될 수 있습니다.이 게시물은 팀 구성원들의 초기 IIS 7.0 환경에 대해 간략히 설명하고 있습니다.가장 주목할 만한 향상된 기능을 요약하여 다음 순위에 따라 나열하고 있습니다.
  1. 간편한 설치
  2. 뛰어난 호환성
  3. 메타베이스가 필요 없음
  4. UNC 공유에 있는 applicationHost.config 파일을 통한 중앙 집중식 구성
  5. 응용 프로그램 디렉터리의 web.config 파일을 통해 위임된 구성
  6. 향상된 관리 도구
  7. 실패한 요청 추적
  8. URLScan이 필요 없는 요청 필터링
  9. UNC 공유를 통해 간소화된 콘텐츠 동기화 사용
  10. 동적 콘텐츠의 출력 캐싱
간소화된 설치는 필자가 꼽는 목록에도 포함됩니다.Microsoft.com 팀은 블로그 게시물에서 단일 명령줄을 사용하여 IIS 7.0의 모든 기능(또는 원하는 기능만)을 배포하는 방법을 보여 주고 있습니다.그림 3에 표시된 명령줄을 사용하는 이러한 접근법을 필자의 테스트 환경 설치 지침에도 포함하였습니다.
이 명령은 다소 긴 편입니다.이 명령을 복사하려면 손으로 다시 입력하지 말고 TechNet Magazine 웹 사이트에서 복사하여 붙여넣는 것이 좋습니다.이 명령은 사용 가능한 모든 모듈을 IIS 7.0 컴퓨터에 설치하지만 PHP가 빠져 있습니다.IIS 7.0에는 PHP가 포함되어 있지 않으며, 인터넷을 통해 Debian 패키지를 다운로드하여 설치한다는 것은 Windows® 패키지 관리자(pkgmgr.exe)에는 낯선 개념입니다.이제 Windows AIK(자동 설치 키트)가 등장합니다.
그림 3 단일 명령줄을 사용한 IIS 7.0 기능 배포
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
AIK를 사용하면 IIS 7.0과 PHP 5가 포함된 Windows Server 2008용 사용자 지정 설치 DVD를 만들 수 있습니다.배포에 필요한 MySQL, 웹 응용 프로그램 파일 및 기타 구성 요소들도 여기에 포함할 수 있습니다.모든 구성 요소를 Windows Server 2008 설치의 일부로 포함하는 방법을 통해 사용자 지정 내용을 모든 웹 서버에 일관되게 적용할 수 있습니다.명령줄이나 구성 파일을 편집할 필요가 없습니다.
심지어 완전 무인 설치가 가능한 사용자 지정 DVD를 만들 수도 있습니다.AIK에는 AutoUnattend.xml 파일을 만들어 DVD의 루트 폴더에 저장할 수 있는 설명서와 도구가 포함되어 있습니다.첨부 자료의 Custom Image Deployment.htm 파일에서 단계별 지침을 제공합니다.
호환성도 많은 관리자들이 핵심 개선 사항으로 손꼽았습니다.테스트로 돌아가서, 필자는 DotNetNuke와 osCommerce에서 몇 가지 호환성 문제가 발생할 것으로 예상했지만 이 두 가지 웹 응용 프로그램 모두 폼 인증 및 검색 엔진에 친화적인 URL 등과 같은 고급 기능을 포함하고 있음에도 불구하고 IIS 7.0으로의 전환은 생각보다 순조로웠습니다.
DotNetNuke의 경우 64비트 플랫폼의 UNC 콘텐츠 공유를 사용하는 복잡한 웹 팜 시나리오로 이전하기 전까지 전혀 문제가 없었습니다.발생한 문제도 아주 미미한 수준이었습니다.이러한 호환성 개선은 결국 IIS 7.0에서 웹 응용 프로그램을 실행하기까지 시간이 더 적게 소요됨을 의미합니다.
웹 응용 프로그램에서 호환성 문제가 발생할 경우 기본 제공되는 진단 및 추적 지원 기능을 사용하면 큰 도움이 됩니다.의미있는 상세한 진단 정보가 제공되며, 제안된 솔루션 경로는 실제로 효과가 있으며 유용합니다.
그림 4는 IIS 7.0의 통합 모드에서 DotNetNuke 4.7을 실행하여 얻은 진단 정보입니다.이 예에서는 세 가지 선택 사항이 있습니다("가능한 해결 방법" 섹션에 표시됨).응용 프로그램에서 통합 모드를 지원하도록 변경하는 것이 DotNetNuke 개발자에게 최선의 선택이 될 것입니다.오류를 무시하는 것은 좋은 방법이 아닙니다.필자의 경우 IIS 7.0에서 수정하지 않은 DotNetNuke 4.7을 실행할 생각이므로 웹 응용 프로그램을 클래식 .NET AppPool로 전환하여 클래식 모드를 활성화하는 세 번째 방법을 선택했습니다.
그림 4 통합 모드에서 실행 중인 DotNetNuke 의 진단 정보(크게 보려면 이미지 클릭)

IIS 아키텍처
이쯤에서 이러한 통합 모드와 클래식 모드에 각각 어떤 기능이 있으며 PHP 응용 프로그램(osCommerce)에는 영향을 주지 않고 ASP.NET 응용 프로그램(DotNetNuke)에만 영향을 주는 이유가 궁금해질 것입니다.이해를 돕기 위해 먼저 IIS 7.0의 아키텍처를 살펴보겠습니다.이전 버전에서는 ASP.NET 런타임을 주로 ISAPI 확장(aspnet_isapi.dll)을 통해 핵심 웹 서버로 통합합니다.반면 IIS 7.0에서는 ASP.NET 지원 DLL(webengine.dll)을 IIS 7.0 요청 처리 파이프라인에 로드하는 ManagedEngine이라는 전역 수준 HTTP 모듈을 통해 ASP.NET 모듈이 핵심 웹 서버에 직접 연결됩니다.
네이티브 모듈은 IIS 웹 서버 핵심 API를 사용하여 BeginRequest, AuthenticateRequest, AuthorizeRequest 및 ExecuteRequestHandler와 같은 특정 이벤트를 파이프라인에 등록합니다.ManagedEngine도 ASP.NET 모듈을 요청 파이프라인으로 통합하기 위해 필요한 지원을 제공합니다.IIS 7.0은 이런 새 아키텍처를 기반으로, 요청된 콘텐츠 형식에 관계없이 요청 처리 과정의 임의의 단계에서 네이티브 및 ASP.NET 모듈을 호출할 수 있습니다.
예를 들어 ASP.NET 사용자 인증을 생각해 보겠습니다.IIS 6.0에서는 ASP.NET 기반 HTTP 모듈을 FormsAuthentication.OnAuthenticate, WindowsAuthentication.OnAuthenticate 등과 같은 OnAuthenticate 이벤트에 등록하여 현재 HttpContext에서 사용자의 ID를 설정하는 것이 가능합니다.이것은 ASP.NET 런타임 내부에서는 훌륭하게 작동하지만 이 ASP.NET 코드로는 PHP 기반 웹 응용 프로그램을 통해 노출된 리소스를 보호할 수 없습니다.
IIS 6.0은 그 스크립트맵 구성에 따라 ASP.NET 콘텐츠 형식에 대한 요청을 aspnet_isapi.dll로 전달하지만 PHP 콘텐츠 형식에 대한 요청은 ASP.NET을 위한 ISAPI 확장으로 전달하지 않습니다.결국, ASP.NET이 PHP 코드를 처리하지 않으며, 이것은 PHP 페이지가 요청될 경우 ASP.NET 인증 코드가 실행되지 않음을 의미합니다.따라서 IIS 6.0에서는 PHP 응용 프로그램을 위한 고유한 인증 메커니즘을 구현해야 하므로 인증 로직을 복제해야 합니다.
IIS 7.0은 요청 파이프라인의 개별 모듈에 대한 혼합 및 일치를 지원하는 이벤트 중심의 처리 모델을 사용합니다.다른 구성 요소 중에서 IIS 7.0은 요청 파이프라인에서 AuthenticateRequest 이벤트가 발생했을 때 OnAuthenticate 이벤트를 트리거하는 관리 WindowsAuthentication 및 FormsAuthentication 모듈을 함께 제공합니다.이제 RequestFilteringModule이나 IpRestrictionModule과 같은 네이티브 모듈이 제공되고, 조기에 중요한 요청을 거부하도록 BeginRequest 이벤트를 처리할 수 있으며, AuthenticateRequest 이벤트에서 사용자 지정 ASP.NET 인증 코드를 실행할 수 있고, ExecuteRequestHandler 이벤트에서 FastCgiModule이 PHP 스크립팅 엔진(php-cgi.exe)을 실행하여 PHP 페이지를 처리하도록 할 수 있습니다.
이러한 통합 아키텍처로 인해 웹 개발자가 공통 비즈니스 논리를 구현하기 위해 코드를 복제할 필요가 없게 되었습니다.사용자 지정 ASP.NET 인증 코드를 사용하면 PHP 응용 프로그램을 비롯한 모든 IIS 리소스를 보호할 수 있습니다.ASP.NET 모듈을 통해 URL 다시 쓰기, 사용자 지정 추적, 오류 로깅 등의 기타 전처리 및 후처리 작업을 수행할 수 있습니다.

통합 모드와 클래식 모드
새로 도입한 이 아키텍처의 부작용은 기존 ASP.NET 응용 프로그램이 요청 파이프라인에서 변경 내용으로 인한 모듈 충돌을 방지하기 위해 응용 프로그램 개발자에게 코드 및 구성 변경을 요구할 수 있다는 것입니다.이렇게 기존 웹 응용 프로그램을 즉시 이식할 수 없는 경우 작업자 프로세스에서 웹 응용 프로그램을 실행할 때 사용되는 응용 프로그램 풀에서 클래식 모드를 활성화할 수 있습니다.IIS 7.0은 ManagedEngine을 클래식 모드의 작업자 프로세스로 로드하지 않으며, 이 경우 요청 파이프라인에서 ASP.NET 모듈을 확인하거나 호출할 수 없음을 의미합니다.그 대신 IIS 7.0은 IsapiModule(aspnet_isapi.dll)에 기반한 다양한 ISAPI 처리기를 활성화하여 IIS 6.0과 유사한 ASP.NET 콘텐츠 형식을 처리합니다.applicationHost.config 파일(기본적으로 %WinDir%\System32\InetSrv\Config 폴더에서 찾을 수 있음)의 system.webServer 아래에 있는 처리기 섹션을 분석해 보면 이를 알 수 있습니다.
예를 들어 문자열 aspx를 검색하면 PageHandlerFactory-Integrated(preCondition="integratedMode" 설정에 의해 통합 모드 응용 프로그램 풀 작업자 프로세스에 로드됨)를 나타내는 한 가지 항목과 PageHandlerFactory-ISAPI-2.0 및 PageHandlerFactory-ISAPI-2.0-64(preCondition="classicMode" 설정에 의해 클래식 모드 응용 프로그램 풀 작업자 프로세스에 로드됨)를 나타내는 다른 항목들을 볼 수 있습니다.
파이프라인 모드가 응용 프로그램 풀 수준에서 설정되기 때문에 IIS 7.0은 웹 응용 프로그램을 통합 모드와 클래식 모드에서 동시에 실행할 수 있습니다.그리고 작업자 프로세스는 서로 다른 응용 프로그램 풀에서 실행하기만 하면 되고 동일한 서버에서 호스팅할 수 있습니다.
하지만 통합 모드와 클래식 모드는 IIS 7.0이 ASP.NET을 요청 파이프라인에 통합하는 방법에만 영향을 준다는 점에 유의해야 합니다.이러한 파이프라인 모드는 PHP 응용 프로그램에 직접 영향을 주지는 않습니다.FastCgiModule 및 기타 모든 네이티브 모듈은 통합 모드와 클래식 모드 모두에서 파이프라인 모드에 대한 전제 조건 없이 로드합니다.FastCGI는 IIS 7.0에서 PHP 스크립팅 엔진을 실행하는 기본 인터페이스이며,FastCGI 대신 CGI를 통해 PHP 스크립팅 엔진의 처리기 매핑을 만들거나 IsapiModule을 PHP-ISAPI(php4isapi.dll)와 함께 사용할 수 있습니다.
하지만 FastCGI가 상당히 향상된 성능 및 안정성을 제공하므로 이러한 IIS 6.0식 구성 옵션은 이제 오래된 방식에 속합니다.FastCGI가 여러 요청에 대한 CGI 프로세스를 다시 사용하는 반면 CGI는 IIS에서 HTTP 요청마다 새 CGI를 초기화해야 하므로 속도가 더 느립니다.ISAPI에는 스레드로부터 안전한 PHP 구축이 필요하며, 이 경우에는 스레드로부터 안전하지 않은 PHP를 실행하는 경우보다 오버헤드가 큽니다.
더욱 중요한 점은 일부 PHP 확장을 스레드로부터 안전한 버전으로 사용할 수 없다는 것입니다. ISAPI와 함께 스레드로부터 안전하지 않은 확장을 실행하는 것은 서버의 안정성 문제를 유발할 수 있으므로 좋지 않습니다.반면 FastCGI는 CGI와 같은 단일 동시성 환경입니다.스레드로부터 안전하지 않은 PHP를 실행하는 데 사용되는 FastCGI는 안정적이면서 빠른 특성을 가지며 IIS 7.0에서 PHP 5를 함께 사용하는 확실한 방법이라고 할 수 있습니다.IIS 7.0으로 전환할 준비가 되지 않은 경우에는 IIS 6.0에서도 FastCGI를 사용할 수 있습니다.

모듈 및 기능
IIS 7.0은 섬세하게 모듈화된 아키텍처가 특징입니다. IIS 개발자의 표현에 따르면 구성 요소별로 구분된 기능 집합이라고도 할 수 있습니다.IIS 7.0의 메모리 공간을 최대로 유지하면서 공격 대상 영역을 최소화하려는 웹 관리자들에게는 반가운 소식일 것입니다.여러 모듈을 활성화하거나 표준 모듈을 사용자 지정 모듈로 교체하는 등, 사용 중인 웹 서버에서 IIS 7.0 기능을 완전하게 제어할 수 있습니다.
동일한 서버에서 통합 모드 또는 클래식 모드로 PHP 응용 프로그램뿐만 아니라 ASP.NET도 실행하려면 요청 처리, 서버 구성, ASP.NET, ISAPI 및 CGI(FastCGI 모듈 포함)를 지원하기 위해 웹 서버 역할 및 핵심 모듈을 최소 수준으로 설치해야 합니다.다음 명령줄을 통해 이를 실행할 수 있습니다.
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
필자는 일반적으로 스테이징 서버에 IIS 7.0을 설치할 때 웹 응용 프로그램을 신속하게 실행하는 데 모든 구성 요소와 관리 도구를 사용할 수 있도록 가능한 모든 옵션을 사용합니다.필자의 전략은 작동하게 만드는 것이므로, 역할 서비스를 제거하고 모듈을 비활성화하여 구성 범위를 좁히고웹 응용 프로그램이 활성화되면 제거했던 역할 서비스 또는 모듈을 다시 추가했습니다.
패키지 관리자(pkgmgr.exe) 또는 IIS 7.0 명령줄 도구(appcmd.exe)를 사용하거나 applicationHost.config 파일에서 직접 globalModules 섹션을 편집하는 방법 중 선택할 수 있지만, 필자의 경험으로는 그래픽 도구가 매우 편리합니다.RequestFilteringModule 및 StaticCompressionModule과 같은 일부 모듈은 엄격히 말해서 응용 프로그램을 실행하는 데 반드시 필요한 모듈은 아니지만 매우 유용합니다.응용 프로그램 풀에 필요한 모듈을 제거하면 웹 응용 프로그램에 액세스할 때 그림 5와 같은 HTTP 오류를 수신하게 됩니다.
그림 5 IsapiModule이 없어서 ASP.NET 응용 프로그램이 클래식 모드로 실행되지 않음(크게 보려면 이미지 클릭)
참고:가장 좋은 방법은 모든 IIS 7.0 서버에 동일한 모듈 집합을 설치하여 활성화하는 것입니다.설치된 구성 요소를 확인하려면 HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\로 이동하여 레지스트리 키를 확인합니다.NetFxEnvironment나 CGI 같은 레지스트리 값에서 REG_DWORD 값이 0000 0001이면 해당 구성 요소가 설치되어 있음을 나타냅니다.

웹 응용 프로그램 마이그레이션
이론은 이것으로 마치고, 이제 실제로 웹 응용 프로그램을 IIS 7.0으로 이동해 보겠습니다.앞서 언급했듯이 필자의 스테이징 서버에는 사용 가능한 모든 구성 요소가 포함된 IIS 7.0과 스레드로부터 안전하지 않은 PHP 5(FastCGI로 등록됨)가 실행 중입니다.시작하기 전에 몇 가지 기본적인 질문을 던져 보겠습니다.
  • 웹 응용 프로그램에 SQL Server나 MySQL과 같은 데이터베이스 관리 시스템이 필요합니까?
  • ODBC 연결, COM 개체, SSL 인증서와 같은 추가 구성 요소를 설치하거나 구성해야 합니까?
  • 웹 응용 프로그램에 특수 서비스 계정과 파일 공유 및 기타 리소스에 대한 관리자 권한의 로컬 또는 원격 액세스 권한이 필요합니까?
  • Apache 모듈의 URL 다시 쓰기(mod_rewrite)에 대한 종속성과 같이 IIS 7.0에서 사용할 없는 플랫폼 특정 기능에 대한 종속성이 있습니까?
이와 같은 질문들은 IIS 7.0에서 웹 응용 프로그램을 더 빨리 가동하는 데 도움이 될 것입니다.예를 들어 Apache 2.2에서 mod_rewrite를 사용하는 PHP 응용 프로그램을 마이그레이션하려는 경우(예: 검색 엔진 친화성을 위해 또는 인라인 연결 이미지를 통한 대역폭 가로채기를 방지하기 위해), IIS 7.0에서 호환되는 사용자 지정 URL 다시 쓰기 솔루션을 구현하기 전에는 문제가 발생하게 됩니다.다행히 osCommerce의 경우 IIS 7.0에서 mod_rewrite 기능이 요구되지 않지만, 일부 검색 엔진 최적화 패키지에서는 필요할 수 있습니다.
스테이징 서버에 필요한 추가 구성 요소를 결정하여 설치했으므로 이제 웹 응용 프로그램을 실행할 준비가 되었습니다.여기서 또 다시 다음과 같이 자문해 보겠습니다.
  • 웹 응용 프로그램을 지원하기 위해 사용할 수 있는 가장 단순한 구성은 무엇입니까?
  • 프로덕션 환경에서는 현재 어떤 구성을 사용 중입니까?
  • 새 플랫폼에서 웹 응용 프로그램 구성을 최적화할 수 있습니까?
  • 웹 응용 프로그램이 원하는 구성으로 작동하기 위해 필요한 최소한의 역할 서비스와 모듈은 무엇입니까?
가장 단순한 구성으로 웹 응용 프로그램을 실행하는 것이 가장 빠르게 가동하는 방법입니다.다른 문제가 없어 보이면 이제 기존 프로덕션 환경과 유사한 구성을 적용하고 프로덕션 데이터를 테스트 테이터베이스로 가져옵니다.물론, 일부 문제가 발생할 수 있지만 고급 구성에서만 해당합니다.
테스트 환경의 프로덕션 구성을 미러링할 때 이미 느끼셨는지 모르겠지만applicationHost.config 파일을 UNC 공유에 배치하면 여러 웹 서버의 구성을 한 곳으로 집중시킬 수 있는 훌륭한 방법이 될 수 있습니다.중복과 콘텐츠 동기화를 통해 내결함성을 향상시키려면 Windows Server 2003 R2 및 Windows Server 2008에서 사용할 수 있는 상태 기반 다중 마스터 복제 엔진인 DFS(분산 파일 시스템) 복제를 구현하십시오.또한, UNC 공유에 웹 응용 프로그램 콘텐츠 파일을 배치하여 웹 프런트 엔드의 저장소 요구 사항을 최소화할 수도 있습니다.
다른 잠재적 최적화에 보안 또는 동적 캐싱이 수반될 수 있습니다.필자는 이 테스트 환경에서 보안 및 성능 최적화에 대한 내용은 논외로 하고 설명하지 않았으며서버 추가 설치를 피하기 위해 DFS를 구성하지도 않았습니다.첨부 자료의 단계별 지침에서는 applicationHost.config 파일과 웹 콘텐츠를 UNC 공유에서 호스팅하는 방법을 예를 들어 보여 줍니다.또한 그림 6은 DFS를 사용하여 UNC 기반 웹 팜을 구현하는 방법을 보여 줍니다.
그림 6 applicationHost.config 파일 및 웹 콘텐츠가 UNC 공유에 배치된 상태에서 웹 팜 배포(크게 보려면 이미지 클릭)

맺음말
IIS 7.0은 놀라운 웹 서버 플랫폼입니다.새롭게 설계된 핵심 아키텍처를 갖추면서 동시에 이전 버전인 IIS 6.0과 거의 완벽에 가까운 호환성을 유지하는 것이 그 특징입니다.대부분의 기존 ASP.NET 웹 응용 프로그램을 따로 수정하지 않고 실행할 수 있지만아키텍처 변경 정도에 따라 호환성 문제가 발생할 수도 있습니다.
IIS 7.0으로 마이그레이션할 대상이 ASP.NET 웹 응용 프로그램이든 아니면 PHP 웹 응용 프로그램이든 어느 경우에도 적절한 계획과 준비, 테스트, 코드 및 구성 변경 문서화 등에 초점을 두어 단계적으로 접근하는 것이 가장 좋습니다.
IIS 7.0은 이러한 노력을 들일 만한 가치를 제공합니다.보안, 성능, 구성 용이성, 유연성 면에서 다수의 향상된 기능을 볼 수 있습니다.이러한 기능에 대해 모두 논하려면 족히 책 한 권은 될 것입니다.UNC 공유에 기반한 중앙 집중식 구성 및 콘텐츠 공유, 응용 프로그램 디렉터리의 web.config 파일을 통한 구성 위임, 향상된 관리 도구, 상세한 진단 정보 및 실패한 요청 추적, 동적 출력 캐싱 등이 웹 관리자가 반길 만한 기능입니다.
요청 처리 파이프라인에서 네이티브 모듈과 관리되는 모듈을 혼합할 수 있는 기능은 ASP.NET 개발자에게 유용하며,IIS 7.0의 FastCGI와 함께 제공되는 성능 및 안정성 향상은 PHP 응용 프로그램 개발자에게 희소식이 될 것입니다.
IT 전문가가 IIS 7.0을 성공적으로 사용하는 데 도움이 되는 중요한 부분이 한 가지 더 있습니다.바로 Microsoft IIS 커뮤니티 포털(www.iis.net)입니다.아키텍처에 대한 상세한 설명이 수록된 기사들과 C++용 소스 코드 및 IIS 7.0 모듈을 만드는 방법에 대한 ASP.NET 개발자의 설명 그리고 PHP 응용 프로그램을 실행하기 위한 단계별 지침 등 모든 필요한 정보를 여기서 찾아볼 수 있습니다.이 사이트가 필요한 상황이 있을 것입니다.이 사이트는 IIS 관련 질문에 대한 해답을 찾기 위해 맨 먼저 활용할 수 있는 훌륭한 자료입니다.

Fergus Strachan은 전문 IT 인프라 설계 및 프로젝트 관리 지원 컨설팅 전문 기업으로서 영국의 국제적인 은행 및 교육 기관에 서비스를 제공하고 있는 Maestra Ltd London의 설립자 겸 이사입니다.Fergus는 Microsoft의 서버 기술에 대한 기사를 연재하고 있으며 Integrating ISA Server 2006 with Microsoft Exchange 2007의 저자이자Microsoft Exchange Server 2003 Resource Kit의 공동 저자이기도 합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC.All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다.


Communications and Collaboration
통합 메시징으로 마이그레이션 계획
Jeff Goodwin
한 눈에 보기:
  • 음성 메일의 간략한 역사
  • 마이그레이션 계획 시 고려해야 할 사항
  • 마이그레이션 전략
  • 다중 사이트 문제

목차
음성 메일의 간략한 역사
마이그레이션 계획
실제 마이그레이션 전략
마이그레이션 연습
계획 준수의 중요성
기존 음성 메일 시스템에서 통합 메시징 플랫폼으로 마이그레이션하는 작업은 까다로운 프로젝트가 될 수 있습니다.그러나 몇 가지 적절한 계획을 마련한다면 최종 사용자가 겪을 수 있는 모든 장애를 최소화하면서 이러한 마이그레이션 작업을 매우 간편하게 수행할 수 있습니다.실제로
이러한 유형의 마이그레이션 프로젝트를 진행할 때는 서비스 장애 최소화를 가장 우선적인 목표로 삼는 것이 중요합니다.
마이그레이션 진행 중 무엇을 계획해야 할지 파악하기 위해서는 먼저 각 기업에서 음성 메일을 업무에 매우 중요한 응용 프로그램으로 여기는 이유를 이해해야 합니다.이러한 기본 정보를 토대로 통합 메시징으로 마이그레이션할 때 구현해야 할 기능에는 무엇이 있으며 그러한 기능이 관리자에게 중요한 의미를 갖는 이유를 이해할 수 있습니다.

음성 메일의 간략한 역사
여행을 시작할 지점을 모르는 상태에서 목적지에 도달하기 위한 방법을 계획할 수는 없는 법이기 때문에 필자는 기존 음성 메일 시스템의 기원과 아키텍처를 되짚어 보면서 이를 간략히 설명하고자 합니다.누가 최초로 음성 메일 시스템을 창안했는지에 대해서는 논란이 있는 것이 사실입니다.다만 최초의 상용 음성 메일 시스템은 VMX(Voice Message Exchange)로 명명되었습니다.
VMX는 오늘날 흔히 전자 메일을 주고받는 것처럼 원래 회사 내 다른 직원들에게 음성으로 의사를 전달할 방법을 제공하도록 설계되었습니다.이 시스템에는 메시지 보내기, 전달, 회신 등의 명령이 있었습니다.새로운 메시지가 수신되면 메시지 알림이 사용자에게 전달됩니다.알림 방법으로는 외부 호출(사용자의 특정 전화 번호 호출), 메시지 대기 표시(사용자 전화기의 표시등) 등 여러 가지가 있었습니다.
VMX 사용자가 계속 증가하자 여러 조직에서는 음성 메일 시스템 네트워크를 구축하기 시작했습니다.그 결과 기업 전체를 범위로 하는 음성 메일 솔루션이 개발되었으며 이 솔루션을 통해 직원들은 회사 전체 메일 그룹에 브로드캐스트 메시지를 보낼 수 있었습니다.
물론 음성 메일 시스템과 상호 작용하기 위한 방법을 제공하기 위해 TUI(누름 단추식 사용자 인터페이스)를 개발해야 했습니다.이러한 TUI는 세월이 흐르면서 변화했지만 아쉽게도 음성 메일의 표준 인터페이스는 없는 실정입니다.휴대폰에서 음성 메일을 받는 경우 "음성 메시지 청취는 1번을 누르세요." 같은 안내를 들어 본 적이 있을 것입니다.그러나 VUI(음성 사용자 인터페이스)를 사용하는 음성 기반의 음성 메일 시스템이 보편화되면서 TUI의 비중은 예전보다 더 줄어들었습니다.어쨌든 사용자가 특정 인터페이스에 대해 가질 수 있는 선호도를 과소 평가해서는 안 됩니다.
오늘날의 엔터프라이즈 음성 메일 시스템에는분산형 아키텍처와 중앙 집중식 아키텍처라는 두 가지 아키텍처가 사용됩니다.그림 1에서 시애틀, 뉴욕 및 오스틴 지점은 분산형 음성 메일 아키텍처를 갖추고 있는데, 여기서 음성 메일 시스템은 이들 각 지점에 배치되어 있습니다.이와는 달리 런던, 파리 및 글래스고 지점은 중앙 집중식 모델을 갖추고 있는데, 여기서 PBX 인프라는 서로 네트워크로 연결되어 있으며 모든 호출은 런던의 중앙 지점으로 다시 라우팅됩니다.두 모델은 각각 장단점이 있습니다.그러나 분산형 모델에서도 사이트 간에 메시지를 배달할 목적으로 음성 메일 시스템을 서로 네트워크로 연결할 수 있다는 점에 유의해야 합니다.
그림 1 일반적인 2가지 음성 메일 아키텍처 모델 (더 크게 보려면 이미지를 클릭하십시오.)
조직에서 분산형 모델을 사용하기로 결정하는 이유는 크게 3가지를 들 수 있습니다.즉, 로컬 가용성이 필요하고 네트워크로 연결할 수 없는 서로 다른 PBX 시스템을 사용하고 있으며 UDP(Uniform Dial Plan) 제약이 있다는 것이 바로 그 이유입니다.
몇몇 조직에서는 네트워크 연결이 끊긴 경우 로컬 PBX와 음성 메일 시스템이 계속 정상적으로 작동하여 사이트의 모든 시스템 기능을 제공하도록 하는 음성 메일 시스템을 필요로 합니다.IVR(대화형 음성 응답) 시스템은 계속 작동되며 외부 호출자들은 메시지를 계속 남길 수 있습니다.실제로 최종 사용자에게 미치는 영향은 없으며 작업은 계속 정상적으로 진행됩니다.익숙하게 느껴질 수 있는 이러한 이유로 많은 조직에서 Microsoft® Exchange Server를 실행하는 서버를 지역화하고 있는 것입니다.각 조직에서는 이러한 지역화된 서비스 제공 능력이 필요한지 여부를 판단하기 위해 위험 평가를 수행할 수도 있습니다.
기업 인수를 통해 성장하고 있는 조직의 경우 원격 사이트에는 인프라의 나머지 부분과 네트워크로 연결할 수 없는 PBX 플랫폼이 있는 경우가 많습니다.이 경우 조직에서는 많은 비용이 소요될 수 있는 PBX 전면 교체 프로젝트를 진행하거나 사이트를 그대로 유지하고 음성 메일 플랫폼을 네트워크로 연결하여 완벽한 음성 메시징 교환 기능을 제공할 수 있습니다.또한 타사 서버를 활용하여 조직 내 서로 다른 음성 메일 시스템을 네트워크로 연결할 수도 있습니다.
여러 PBX를 네트워크로 연결하기 위해서는 UDP(Uniform Dial Plan)가 필요합니다.UDP에서는 전화기와 음성 메일 내선 번호가 겹칠 수 없습니다.그림 1을 살펴보면 시애틀, 뉴욕 및 오스틴의 내선 번호 범위가 서로 겹쳐 있음을 알 수 있습니다.그 이유는 미국 지역에 있는 사이트에 대한 UDP가 없기 때문입니다.내선 번호 범위를 7자리 또는 10자리로 늘려 UDP를 만들 수도 있지만 이 경우 다른 문제점들이 나타납니다.
즉, 전화기마다 전화 걸기 템플릿을 바꿔야 하고 PBX에서 모든 사용자의 내선 번호를 변경해야 하며 시스템과 통합되는 모든 응용 프로그램을 변경해야 하는 문제가 발생할 수 있습니다.또한 내선 번호 범위를 늘리면 직원들이 다른 곳에 있는 누군가에게 연락하기 위해 7자리 또는 10자리의 번호를 기억하고 눌러야 하는 불편을 겪을 수 있습니다.
이러한 기본 기능과 구조적 문제점들은 지난 수년 동안 개선되었지만 음성 메일의 기본적인 사항은 달라지지 않았습니다.메시지 교환, 네트워킹, 알림 방법, 사용자 인터페이스 및 아키텍처는 모두 마이그레이션을 계획할 때 반드시 고려해야 할 중요한 요소들입니다.

마이그레이션 계획
통합 메시징은 사용자가 음성 메일을 사용하는 방법, 아키텍처 설계 방법 그리고 관리자들이 관리 업무를 수행하는 방법에 이르기까지 조직의 모든 부분에 걸쳐 변화를 가져옵니다.이러한 모든 차이점들은 통합 메시징 시스템으로 마이그레이션할 때 반드시 해결해야 합니다.마이그레이션 계획 시 고려해야 할 사항을 검사 목록으로 나열하면 다음과 같습니다.
메시지 네트워킹 기존 음성 메일 플랫폼에서 Exchange 통합 메시징으로 전환하는 조직은 일정 기간 동안 두 가지 방식을 병용해야 합니다.사용자 조직에서 서로 다른 음성 메일 시스템을 상호 운용할 시스템인 메시지 네트워킹을 이미 배포한 경우에는 기존 시스템 목록에 통합 메시징 시스템을 추가하기만 하면 됩니다.여러 위치에 개별 음성 메일 또는 PBX 시스템이 있는 조직의 경우 메시지 네트워킹을 구축할 것을 적극 권장합니다.
인프라 통합 메시징을 위한 인프라를 설계할 때는 네트워킹 요구 사항, 전화 통신 통합, 서버 배치 등을 결정해야 합니다.기본 배포 전략을 충분히 숙지하지 못한 경우에는 필자의 이전 기사인 "Exchange Server 2007을 사용한 통합 메시징 배포"(technet.microsoft.com/magazine/cc137737)를 참조하시기 바랍니다.
AA(자동 전화 교환) 많은 시스템에서 주간, 야간 및 각 부서별로 서로 다른 다양한 자동 전화 교환 기능을 제공합니다.기존 음성 메일 시스템에서 자동 전화 교환 기능을 사용하려면 해당 조직의 통신 팀과 협력해야 합니다.
MWI(메시지 대기 신호) 솔루션에서 메시지 대기 신호 없이도 기능을 수행하도록 할 수도 있지만 흔히 사용자들에게는 이러한 기능이 필요할 수 있습니다.따라서 빨간색 표시등 알림에 대한 사용자들의 선호도를 간과해서는 안 됩니다.다행히도 몇몇 업체에서 Exchange Server용 메시지 알림 표시등 응용 프로그램을 제공하고 있습니다.
팩스 지원 많은 수의 기존 음성 메일 플랫폼에서 수신 팩스를 지원합니다.또한 Exchange 통합 메시징에서도 수신 팩스 기능을 지원하기 때문에 새로 배포할 때 이 기능을 지원하도록 계획할 수 있습니다.
IVR(대화형 음성 응답) 일부 기존 음성 메일 플랫폼에서는 Exchange 통합 메시징에서는 사용할 수 없는 IVR(대화형 음성 응답) 응용 프로그램을 지원합니다.적절한 대안을 찾을 때까지는 이러한 시스템을 그대로 유지할 수도 있습니다.
관리 Exchange 통합 메시징에서는 Active Directory® 및 Exchange 사서함 서버 역할을 사용합니다.통합 메시징 배포가 관리, 시스템 요구 사항 등에 어떤 영향을 미치는지 계획해야 합니다.
사용자 인터페이스 새 UI를 배포할 경우 사용자를 대상으로 교육을 실시해야 합니다.Exchange 통합 메시징에서는 대부분의 휴대폰 공급업체들이 제공하는 것과 매우 유사한 인터페이스를 사용합니다. 따라서 인터페이스는 대부분의 사용자들이 쉽게 사용할 수 있어야 합니다.또한 음성 인식 기능이 지원되므로 사용자들은 누름 단추를 사용할 필요가 없습니다.Exchange Server에서는 이러한 기능을 Outlook® Voice Access라고 합니다.
교육 통합 메시징은 사용자들이 통신하고 음성 메일을 사용하는 방식에 대한 패러다임을 바꾸고 있습니다.UI 교육 외에도 사용자들에게 최선의 사용 방법과 보다 효율적인 새로운 통신 방법을 제시하기 위한 교육도 함께 실시해야 합니다.예를 들어 사용자들은 받은 편지함에서 음성 메일을 사용하는 방법 또는 일부 고급 통합 메시징 설정을 구성하는 방법을 잘 모를 수도 있습니다.

실제 마이그레이션 전략
대규모 조직에서 통합 메시징 솔루션으로 마이그레이션하는 과정에는 흔히 여러 문제점들이 나타날 수 있습니다.그러나 필자는 지난 10년간 통합 통신 분야에서 일하면서 매우 구체적인 요구 사항이 있는 상당히 복잡한 조직에서도 성공적으로 마이그레이션을 수행한 것을 목격했습니다.
단일 사이트 조직이든, 다중 사이트 조직이든 관계없이 다음 5가지 기본 단계를 중심으로 마이그레이션 전략을 수립한다면 도움이 될 것입니다.
  1. 솔루션을 계획 및 설계합니다.
  2. 통합 메시징 서버 역할을 설치 및 구성합니다.
  3. 파일럿 그룹을 마이그레이션합니다.
  4. 파일럿 그룹에서 수렴한 의견을 토대로 설계를 수정합니다.
  5. 사용자를 마이그레이션합니다.
물론 다중 사이트 조직은 단일 사이트 시나리오에서는 잘 발생하지 않는 몇 가지 문제를 겪고 있습니다.자세한 내용은 "다중 사이트 문제" 추가 기사에서 별도로 살펴보겠습니다.
솔루션을 계획 및 설계하는 일은 마이그레이션 과정에서 가장 중요한 단계에 해당합니다.이 작업에는 통합 메시징 팀을 배정하는 것이 좋습니다.통합 메시징 팀은 통신, Active Directory, Exchange, 네트워킹, 보안, 교육 및 프로젝트 관리 분야에 대한 전문 지식을 갖춘 조직 내 여러 부서의 담당자들로 구성해야 합니다.또한 조직의 기존 PBX, 음성 메일 및 전자 메일 인프라에 대한 상세한 아키텍처 도면을 확보해야 합니다.
설계가 완료되면 통합 메시징 서버 역할을 설치 및 구성할 수 있습니다.기존 음성 메일 시스템과 병행하여 통합 메시징 서버를 설치하는 것을 주저하지 말아야 합니다.문서에 수록된 최선의 방법을 따라야 합니다.
이제 통합 메시징 서버를 평가해 볼 준비가 되었습니다.사용자들로 구성된 소규모 파일럿 그룹을 지정하여 새 시스템으로 마이그레이션합니다.그룹은 25~50명의 사용자로 구성하면 됩니다.사용자를 신중하게 선별한 다음, IT 및 통신 담당자에서 부장 및 영업 사원에 이르기까지 다양한 사용자 그룹으로 구성된 파일럿 그룹을 만듭니다.이처럼 다양한 유형의 사용자들을 참여시킴으로써 시스템이 대상에 맞게 설계되었는지 여부, 고려해야 할 특정 요구 사항, 사용자들에게 필요한 교육 항목 등을 보다 정확하게 파악할 수 있습니다.
파일럿 그룹의 의견을 수렴한 후에는 테스트 과정에서 밝혀진 모든 문제를 해결할 수 있도록 시스템 설계를 수정해야 합니다.특히 "고려해야 할 사항" 섹션에서 필자가 설명한 항목을 다시 살펴본 후 그러한 사항들을 해당 조직에 맞게 적절히 처리했는지 확인해야 합니다.여기서 수행한 가장 일반적인 변경 사항은 주로 교육과 관계가 있다는 것에 유의하십시오.
마지막 단계에서는 사용자를 마이그레이션합니다.시스템을 프로덕션 환경으로 전면 마이그레이션하는 방법에 대해서는 다양한 의견과 전략이 있습니다.그 중에서 많이 사용되는 두 가지 방법은 점진적 마이그레이션과 일괄 전환(flash-cut)입니다.
수주 또는 수개월의 기간 동안 사용자 커뮤니티를 점진적으로 마이그레이션할 경우 기존 사용자와 통합 메시징 사용자 간에 음성 메일이 단절됩니다.이로 인해 사용자들은 음성 메일을 통해 서로에게 메시지를 전달할 수 없게 됩니다.또한 시스템 설계에 메시지 네트워킹 솔루션을 포함하지 않을 경우 비즈니스 통신 중 일부가 중단됩니다.따라서 이 마이그레이션 방법을 사용할 경우에는 최초 설계 단계에서 메시지 네트워킹 솔루션을 포함하는 것이 좋습니다.
일괄 전환(flash-cut) 마이그레이션에서는 모든 사용자를 한 번에 이동합니다.일반적으로 조직에서는 주말 동안에 이러한 유형의 마이그레이션을 수행하기 때문에 중대한 장애가 발생할 경우 시스템을 테스트하고 구성을 변경하며 마이그레이션을 취소할 수 있는 시간적 여유가 있습니다.
어떤 방법을 선택하든 파일럿 그룹으로부터 수집한 일반적인 질문과 답변을 바탕으로 지원 센터 직원들을 교육해야 합니다.또한 지원 센터 담당자들이 사용자 활성화, 사용자 활성화 여부 검증, 암호 변경 등 주요 작업을 능숙하게 수행할 수 있도록 해야 합니다.

마이그레이션 연습
예제 마이그레이션을 진행할 경우 통합 메시징으로의 마이그레이션을 성공적으로 수행하기 위해서는 내부 및 외부 사용자의 업무 중단을 가능한 최소화하면서 기존 음성 메일 플랫폼에서 통합 메시징으로 사용자의 음성 메일 사서함을 이동하는 데 1차적인 목표를 두어야 합니다.
그림 2에서는 조직의 아키텍처를 자세히 보여 줍니다.이 조직은 이러한 혼합된 Exchange 아키텍처를 변경할 계획이 없습니다.미국에 소재한 지점의 주 데이터 센터는 시애틀에 있습니다.오스틴 지점의 모든 IT 응용 프로그램은 시애틀에서 제공되며 뉴욕 지점은 지역화된 Exchange 서비스를 보증합니다.미국에 소재한 지점들의 음성 메일은 서로 다른 PBX 인프라로 인해 분산되어 있습니다.기술적 측면에서 중앙 집중식 음성 메일을 제공할 목적으로 PBX 인프라를 네트워크로 연결할 수는 없습니다.이와는 달리 유럽에 소재한 지점들의 중앙 집중식 데이터 센터는 런던에 있습니다.유럽에서 운용되는 모든 IT 및 통신 응용 프로그램은 이 중앙 데이터 센터에서 제공됩니다.
그림 2 마이그레이션 이전의 아키텍처 예제 (더 크게 보려면 이미지를 클릭하십시오.)
전체 음성 메일 인프라는 Octel(현재 Avaya) 플랫폼을 기반으로 합니다.모든 음성 메일 시스템은 OAN(Octel Analog Networking)을 통해 네트워크로 연결되어 있습니다. OAN은 아날로그 전화선과 시외 전화를 사용하여 네트워크로 연결된 음성 메일 메시지를 보내는 전용 네트워킹 프로토콜입니다.이 아키텍처에서는 사이트 간의 회사 전체 음성 메시징을 처리할 수 있습니다.
다중 사이트 문제
다중 사이트 조직에서는 통합 메시징을 배포할 때 여러 가지 문제점에 직면합니다.다행스러운 점은 다른 조직에서 이미 발생한 몇 가지 문제점으로부터 교훈을 얻을 수 있다는 것입니다.이 기사에서 모든 문제점을 다룰 수는 없지만 다양한 조직과 함께 작업을 수행하면서 필자가 경험했던 문제점 중 가장 일반적인 몇 가지를 살펴보겠습니다.
"중앙 집중식 Exchange Server 아키텍처와 혼합된 전화 통신 환경을 보유하고 있습니다."
분산 환경은 설계하기 쉽습니다.통합 메시징 서버를 배치하고 이를 각 사이트의 로컬 PBX와 통합하면 됩니다.하지만 중앙 집중식 또는 혼합된 환경이라면 어떨까요?생각해 볼 문제는 바로 "해당 사이트에서 로컬 통합 메시징 서비스가 지속적으로 제공되어야 하는지 여부"입니다.로컬 통합 메시징 서비스가 지속적으로 제공되는 경우 해당 사이트는 중앙 집중식 Exchange 서버와 연결이 끊어질 수 있지만 자동 전화 교환 기능은 계속 제공할 수 있으며 외부 호출자(주로 고객)들은 메시지를 남길 수 있습니다.이 문제에 대한 해답은 해당 사이트가 얼마나 업무에 중요하며 솔루션은 어느 정도 관리가 가능한지에 따라 달라질 수 있습니다.
사이트에서 로컬 통합 메시징 서비스를 지속적으로 제공해야 한다면 해당 사이트에는 원격 통합 메시징 서버가 좋은 해결책이 될 수 있습니다.이러한 경우가 아니라면 로컬 사이트에 SIP 게이트웨이를 설치하면 됩니다.Exchange 통합 메시징은 융통성이 있으므로 PBX 인프라를 네트워크로 연결할 필요가 없고 UDP(Uniform Dialing Plan)에 대한 요구 사항도 없습니다.
"현재 Exchange 아키텍처를 업그레이드하는 중입니다."
많은 고객들이 자신의 Exchange 인프라를 업그레이드하면서도 통합 메시징 마이그레이션을 시작하는 데는 주저하고 있습니다.통합 메시징으로 전환하기로 이미 결정했다면 Exchange 서버가 업그레이드되는 동안 마이그레이션을 진행하는 것이 좋습니다.업그레이드 계획에 따라 마이그레이션을 진행하면 되며 이로 인해 프로젝트가 많이 복잡해지지는 않습니다.
"10명 이하의 직원들이 근무하는 소규모 사이트를 다수 운영하고 있으며 이 사이트 중 일부에는 PBX가 없습니다."
PBX가 배치되어 있는 비교적 작은 규모의 사이트에서는 로컬 사이트에 SIP 게이트웨이를 설치하기만 하면 됩니다.PBX가 없는 사이트의 경우 통합 메시징 시스템으로의 호출 라우팅을 위해 전화를 중앙 PBX로 전달하는 데는 몇 가지 전화 통신 방법을 사용할 수 있습니다.즉, 조직 내부의 규모가 작은 원격 사이트에 매우 저렴한 비용으로 통합 메시징 서비스를 배포할 수 있습니다.
이러한 소규모 사이트는 마이그레이션 수행에 대한 실험실 역할을 한다는 점에 유의해야 합니다.일반적인 마이그레이션 전략 중 하나는 네트워크의 경계에서 시작하여 중심부로 이동하는 것입니다.먼저 소규모 사이트부터 마이그레이션한 다음, 통합 메시징 팀과 사후 검토를 실시하여 성공적으로 진행된 사이트와 문제가 발생한 사이트를 파악하도록 합니다.그런 다음 이 과정에서 얻은 유용한 정보를 또 다른 사이트를 마이그레이션할 때 활용하면 됩니다.
통합 메시징 팀은 네트워크의 경계에서 중심부로 마이그레이션을 진행하기로 결정했습니다.모든 지점에서 통합 메시징 서버는 최선의 Exchange 서버 아키텍처 구축 방법에 따라 배치됩니다.통합 메시징 팀은 "고려해야 할 사항" 섹션에서 설명한 항목들을 염두에 두면서 각 사이트에 해당하는 계획 문서를 작성합니다.이러한 문서는 서버 설치 및 구성, 사용자 교육 그리고 마이그레이션 전략 계획에 사용됩니다.
각 사이트에서 통합 메시징 팀은 사용자들을 통합 메시징 시스템으로 일괄 전환한 후 대안을 찾을 때까지 계속 사용할 IVR 응용 프로그램을 지원하도록 기존 플랫폼을 유지할 계획을 마련합니다.통합 메시징 팀은 마이그레이션을 수행한 후 30일 동안 기다린 다음 또 다른 지점의 마이그레이션 작업을 수행하기로 결정했습니다.이러한 대기 기간은 더 많은 사용자들을 전환하고 지원 센터에 도움을 요청하기 전에 각 사이트가 새 플랫폼에 맞게 조정되었는지 확인하는 데 목적이 있습니다.
조직에서는 오스틴 지점부터 먼저 마이그레이션하기로 결정합니다.오스틴 지점의 전자 메일 서비스는 시애틀에서 제공되므로 통합 메시징 팀은 시애틀에 통합 메시징 서버 역할을 설치하고, 오스틴 지점에는 SIP 게이트웨이를 설치하여 PBX를 통합합니다.기존 음성 메일 플랫폼은 네트워크로 서로 연결되어 있으므로 통합 메시징 팀은 메시지 네트워킹 서버를 설치하여 통합 메시징 플랫폼을 네트워크로 연결해야 하는 문제를 해결해야 합니다.사용자들은 새 시스템에 관한 교육을 받고 마이그레이션은 순조롭게 진행되므로 통합 메시징 팀은 다음 지점인 뉴욕을 마이그레이션하기로 결정합니다.
뉴욕 지점에는 자체 사서함 및 허브 전송 서버가 있습니다.따라서 최상의 방법은 통합 메시징 서버를 뉴욕에 설치하는 것입니다.통합 메시징 팀은 마이그레이션 계획 문서에 따라 서버를 설치합니다.이 서버는 음성 메일 네트워크에 포함될 메시지 네트워킹 서버의 노드 목록에 추가됩니다.사용자들은 교육을 받고 통합 메시징으로 순조롭게 마이그레이션됩니다.
오스틴 지점의 마이그레이션 과정에서 시애틀 지점에는 이미 통합 메시징 서버가 배포되었습니다.통합 메시징 팀은 시애틀과 오스틴 지점 모두를 지원하는 데 충분한 수의 음성 메일 포트가 이 서버에 있는 것을 확인합니다.시애틀 지점의 사용자들은 교육을 받고 통합 메시징으로 마이그레이션됩니다.
유럽의 아키텍처는 설계하기가 훨씬 더 수월합니다.PBX 인프라는 네트워크로 연결되어 있으며 Exchange는 중앙 집중화되어 있습니다.통합 메시징 서버는 런던에 배포되어 있고 가장 작은 사이트를 시작으로 각 사이트가 마이그레이션됩니다.그림 3에서는 최종 아키텍처를 보여 줍니다.
그림 3 마이그레이션 이후의 아키텍처 예제 (더 크게 보려면 이미지를 클릭하십시오.)

계획 준수의 중요성
필자는 통합 메시징 마이그레이션 실패 문제를 해결해달라는 요청을 여러 번 받았습니다.이들 조직 중 많은 수가 핵심 규칙을 하나 이상 어겼습니다.
첫째, 통합 메시징은 단순히 음성 메일 시스템을 의미하는 것은 아니라는 점을 기억하십시오.이것은 업무 수행에 중요한 응용 프로그램이며 또 그렇게 여겨야 합니다.사용자들은 음성 메일 기술을 사용하여 정보를 교환합니다.이는 비즈니스 응용 프로그램이라는 점을 염두에 두어야 하며 본 기사에서 설명한 모든 고려 사항이 반영될 수 있도록 마이그레이션을 계획해야 합니다.
통합 메시징으로 마이그레이션을 진행할 때는 절대적으로 통신 팀과 함께 작업을 진행해야 합니다.통신 팀은 회사 인프라에 통합되는 전화 통신 응용 프로그램을 누구보다도 잘 알고 있습니다.
통합 메시징으로 마이그레이션을 수행할 때 엔터프라이즈 솔루션에 대해 계획하십시오.초기 단계에서는 단일 사이트만 구현할 수도 있지만 항상 전체 네트워트에 관한 청사진을 마련해 두어야 합니다.예를 들어 메시지 네트워킹을 다른 사이트에는 제공하지 않고 단일 사이트를 구현하면 사용자 간 통신이 영향을 받게 됩니다.이러한 작업은 결코 수월하지 않을 수 있으므로 모든 IT 응용 프로그램을 고려하는 아키텍처를 설계할 때는 전문가와 상의해야 합니다.
마지막으로 교육의 중요성을 간과해서는 안 됩니다.통합 메시징은 사용자들이 통신하고 음성 메일을 사용하는 방식에 대한 패러다임을 바꾸고 있습니다.언뜻 단순하게 보이는 것도 다른 사람들에게는 간단한 문제가 아닐 수 있습니다.올바른 교육은 원활한 전환을 가능하게 하는 지름길입니다.

Jeff Goodwin은 VIA Group의 수석 기술자이자 Exchange 및 통합 메시징 설계 및 배포 분야의 전문가입니다.문의 사항이 있으면 jgoodwin@theviagroup.com으로 연락하십시오.


통신 및 공동 작업
OCS 2007의 강력한 음성 기능
Rajesh Ramanathan
한 눈에 보기:
  • OCS 2007에서 전화 걸기
  • 보안 통화
  • OCS의 다중 모드 대화
  • 음성 메일 지원을 위한 Exchange UM과의 통합

목차
기본 음성 통화
전화 번호 사용
보안 통화
NAT 및 방화벽 트래버스
전화 번호 라우팅
인바운드 라우팅
품질 보고 및 문제 해결
전체 과정
다중 모드 동작 및 대화
음성 메일
맺음말
이 시리즈의 첫 번째 부분에서는 Microsoft Office Communication Server(OCS)가 Live Communication Server(LCS) 2005의 강점을 바탕으로
기업 수준의 인스턴트 메시징(IM), 상태 표시 기능, 그리고 고급 미디어 및 전화 기능을 제공하기 위해 어떻게 설계되었는지 설명하였습니다(TechNet Magazine 2008년 2월호 참조 - technet.microsoft.com/magazine/cc194409).이번에는 이전 내용에 이어서 VoIP 측면을 자세히 설명하려고 합니다.OCS 시스템에서 음성 통화가 얼마나 간단히 이루어지는지 설명하고, 이러한 기술에 대해 차례대로 논의하는 방식으로 각각의 구성 요소를 해당 기능에 따라 추가적으로 설명합니다.
이전 기사에서 밝혔듯이 OCS는 다음과 같은 다양한 구성으로 사용자에게 전화 통신을 제공합니다.
Enterprise Voice PBX 없이 Microsoft® Mediation 서버와 함께 OCS를 사용하는 완전한 통합 통신 솔루션입니다.이 시스템에서는 Exchange UM(통합 메시징)을 사용하여 음성 메일 기능을 제공합니다.이 글에서는 이 서비스를 사용하는 사용자를 "UC 사용자"라고 하고,이 구성을 사용하는 클라이언트를 "UC 끝점"이라고 하겠습니다.
PBX와 통합된 Enterprise Voice 이 구성에서 사용자는 기존 PBX 전화를 그대로 사용하면서 통합 통신의 혜택을 누릴 수 있습니다.OCS와 PBX의 병렬 설치가 가능하므로 Office Communicator와 PBX 끝점에서 동시에 전화를 받을 수 있습니다.PBX는 여전히 통화 라우팅을 담당하고 음성 메일 서비스도 제공합니다.
원격 통화 제어 이 기능은 PBX 전화를 기본 전화로 사용하며 Office Communicator 클라이언트를 통해 전화를 제어할 수 있습니다.

기본 음성 통화
여기서는 Enterprise Voice 사용자의 입장에 초점을 맞추어 설명하겠습니다.OCS 시스템에서는 RFC 3261에 기술된 SIP INVITE 방식을 사용하여 간단한 음성 통화를 설정합니다.OCS 서버는 클라이언트(또는 끝점) 사이에 메시지를 중계하는 전자 메일 관리자와 비슷한 프록시 역할을 담당합니다.통화나 인스턴트 메시징 세션 등의 실시간 세션이 생성될 때마다 새로운 SIP INVITE가 클라이언트에서 발생합니다.INVITE가 응답과 함께 승인되면(원격 끝점에서 200 OK 응답을 보내면), 통화가 연결됩니다(그림 1 참조).
그림 1 INVITE 형식과 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
그림 2에서, Alice가 Office Communicator(OC) 2007에서 Communicator 통화를 선택하여 Bob에게 전화를 걸면 OC 2007은 Bob의 SIP URI(Uniform Resource Identifier) sip:bob@example.com으로 INVITE를 보냅니다.이 INVITE에는 Alice가 음성을 수신할 수 있는 미디어 끝점에 대한 오디오 세션 설명자인 SDP(Session Description Protocol)가 들어 있습니다.OCS는 INVITE를 Bob에게 등록된 여러 SIP 끝점(예: Communicator Phone Edition 및 Communicator 데스크톱)으로 나누어 보냅니다.INVITE에는 sip:alice@example.com이라는 From 헤더가 포함되어 있으며, Bob의 클라이언트 끝점은 RNL(역방향 이름 조회)에서 이 정보를 사용하여 이름 Alice를 찾고 수신 전화 알림에 표시합니다.
그림 2 여러 끝점에 통화 라우팅(크게 보려면 이미지 클릭)
각 끝점에는 Globally Routable User Agent URI(GRUU)가 표시됩니다.SIP 끝점은 GRUU를 통해 고유하게 식별되며, 이것은 OCS 서버에 등록할 때 부여됩니다.GRUU 주소는 SIP 메시지 라우팅에 사용됩니다. 끝점이 응답하고 나면 통화 중간의 다른 작업을 위한 이후의 SIP 신호는 끝점 간에 GRUU 주소를 사용하여 직접 전달할 수 있습니다.
그림 3은 Bob이 Communicator 데스크톱에서 응답한 경우의 프로세스를 보여 줍니다.Bob의 OC에서 200 OK 메시지가 전송되어 어디서 음성을 수신할 수 있는지 알립니다.OCS 프록시가 한 끝점의 응답을 감지하면 즉시 다른 Communicator Phone Edition 끝점으로의 통화를 취소합니다.200 OK 응답이 Alice의 Communicator 끝점에 도달하면 두 끝점은 미디어를 시작하기 위한 충분한 정보(IP 포트, 암호화 매개 변수 등)를 갖게 됩니다.
그림 3 한 쪽 끝점에서 응답할 경우(크게 보려면 이미지 클릭)

전화 번호 사용
지금까지 사용자가 Communicator 통화를 클릭하여 초대를 만드는 경우를 살펴보았습니다.사용자가 전화 번호를 선택하거나 직접 입력하는 경우에는 처리 과정이 다음과 같이 약간 달라집니다.
  • 우선 클라이언트는 전화 번호를 정규화하여 TEL URI로 표현합니다. 이는 전화 번호로 식별되는 리소스를 기술하는 방법으로서 RFC 3966에 지정되어 있습니다.
  • OCS 서버가 SIP URI만 인식할 수 있기 때문에, 클라이언트는 TEL URI에 도메인 접미사와 user=phone 태그를 추가하여 SIP URI로 변환합니다.
  • 내부 사용자 번호인 경우 OCS가 직접 초대를 보내고외부 번호인 경우에는 가까운 SIP-PSTN 게이트웨이로 초대를 보냅니다.
PSTN(공중 전화망)의 번호로 전화를 걸 때 상대방의 안내 멘트를 듣거나 연결을 위해 숫자를 더 입력해야 하는 경우와 같이 응답을 받기 전에 미디어 경로가 설정되어야 하는 경우가 있습니다.이런 경우에는 PSTN 게이트웨이가 음성 SDP와 함께 183 세션 진행률 표시기를 전송합니다.Communicator는 이 정보를 사용하여 상대방이 전화에 응답하기 전에 대상 끝점과 양방향 미디어 경로를 설정합니다.
초기 미디어 경로가 모두 설정되고 나면 Communicator에서 Dual-Tone Multi-Frequency 또는 DTMF(전화기 신호음) 키패드를 사용할 수 있게 되어 원격 시스템에서 요구하는 추가적인 숫자를 사용자가 입력할 수 있습니다.입력된 DTMF 숫자는 미디어 경로를 통해 RFC 2833 패킷으로 전송되고,PSTN 게이트웨이는 PSTN 쪽에서 해당 DTMF 신호음을 생성합니다.
Bob이 휴대 전화에 동시 신호 울림을 설정한 경우 OCS 프록시는 전화를 게이트웨이와 Bob의 다른 Communicator 끝점에 동시에 보냅니다.이런 경우 OCS 프록시는 183 세션 진행 상태 응답에서 여러 개의 통화 경로가 있음을 나타내며, 이에 따라 Communicator에서 PSTN 게이트웨이를 사용하는 수신 전용 미디어 채널을 설정하게 됩니다.

보안 통화
미디어는 기본적으로 RFC3711에 정의된 SRTP(Secure Real-Time Transport Protocol)로 암호화되며, 이것은 OC에 설정된 음성 통화의 주요 기능 중 하나입니다.SRTP는 RTP 트래픽에 기밀성, 메시지 인증 및 재생 보호 기능을 제공합니다.통화 설정 과정에서 클라이언트 간에 보안 협상이 이루어지며 INVITE 메커니즘의 일부로 암호화 키가 교환됩니다.
OC의 기본 암호화 설정은 "선택적"이며 OC 끝점 사이에 암호화된 미디어 채널을 설정할 수 있습니다.이 설정은 관리자가 조직의 규정 준수 요구 사항에 맞게 조정할 수 있습니다.예를 들어, 모든 통화가 암호화되도록 설정할 수도 있고 암호화를 전혀 사용하지 않을 수도 있습니다.

NAT 및 방화벽 트래버스
OCS 시스템의 클라이언트는 ICE(Interactive Connectivity Establishment) 기술을 사용하여 기존 NAT(Network Address Translation) 구성 요소를 변경하지 않고 NAT 장치 및 방화벽 안쪽에 있는 사용자에게 미디어를 연결할 수 있습니다.ICE 기술은 현재 IETF(Internet Engineering Task Force)에서 표준화를 진행하고 있습니다.각각의 클라이언트는 대역 내 프로비전 메커니즘을 통해 서비스를 제공하는 A/V(오디오/비디오) 에지 서버를 인식하며 로그인하는 동안 A/V 에지 서버와의 인증된 연결을 유지합니다.
클라이언트는 전화를 걸기 전에 A/V 에지 서버(미디어 중계용), NAT, 또는 호스트 클라이언트 자체의 가능한 연결 지점(주소 및 포트, 후보라고도 함)에 리소스를 할당합니다.SIP(Session Initiation Protocol) INVITE를 전송할 때 이 연결 정보도 그 일부로 전송됩니다.마찬가지로 200 OK 응답을 통해 피어의 후보 정보가 전달됩니다.각 끝점에 피어 후보 목록이 전달되면 세심한 순위 지정 및 점검 과정을 통해 두 피어 사이에 미디어를 성공적으로 전송할 수 있는 최적의 경로를 선택하게 됩니다.

전화 번호 라우팅
전화 번호 라우팅은 다음과 같은 요소로 인해 기본 전화 메커니즘을 복잡하게 만듭니다.
  • 단축 다이얼을 위해 내부적으로 사용하는 다이얼 플랜이 조직마다 서로 다를 수 있습니다.
  • 전화 번호가 비표준 형식으로 저장될 수 있습니다(예: Microsoft Office Outlook®에서 7자리 번호를 저장할 수 있음).
  • 외부 전화 번호마다 다른 정책이 적용될 수 있습니다.예를 들어 특정 사용자에게 국제 전화가 금지될 수 있습니다.
OCS 시스템에서 전화 번호 라우팅이 올바르게 동작하려면 전화 번호가 RFC 3966 TEL URI 형식이어야 합니다.이 형식이 아닌 번호는 클라이언트가 INVITE를 실행하기 전에 변환됩니다.그림 4는 OCS 시스템에서 이러한 변환이 어떻게 일어나는지 보여 줍니다.
그림 4 전화 번호 라우팅(크게 보려면 이미지 클릭)
클라이언트에서 사용 가능한 전화 번호는 다양한 출처에서 제공됩니다.미리 정규화된 번호의 출처는 번호를 정규화된 E.164 형식으로 변환할 때 사용하는 관리자가 지정한 정규화 규칙을 가지고 있는 주소록 서비스(ABS)입니다.클라이언트가 SIP INVITE를 정규화된 번호로 보내면 OCS는 내부 사용자와 일치하는 번호가 있는지 알아보기 위해 변환 프로세스를 적용합니다.
  • 1단계는 시스템에 들어오는 번호가 고유하거나(정규화되고 E.164 번호 형식을 따름) 위치를 식별하는 전화 컨텍스트가 있는지 보여 줍니다.이러한 번호는 SIP INVITE의 일부로 서버에 전송됩니다.OCS는 이 INVITE를 변환 프로세스로 라우팅합니다.
  • 변환 프로세스(2단계)에서는 서버 쪽 RNL을 사용하여 전화 번호를 UC 끝점에 매핑하려고 시도합니다.변환 프로세스에서 해당 번호에 대한 경로는 아웃바운드 라우팅이나 UC 사용자로 식별되고, 번호가 올바르게 변환될 수 없는 경우 4xx 코드와 함께 통화가 실패하게 됩니다.
  • 변환된 번호가 UC 사용자가 아니거나 외부 번호인 경우 아웃바운드 라우팅 구성 요소로 전송되며, 번호에 발신자와 관련된 정책을 적용한 후에 INVITE를 적절한 SIP-PSTN 게이트웨이로 재지정합니다(3A단계).아웃바운드 라우팅은 게이트웨이 간의 통화 부하를 분산하며 장애 발생 시 필요한 경우 대체 게이트웨이로 전환하는 역할을 합니다.아웃바운드 라우팅 프로세스는 실패할 수 있으며 또는 특정 번호에 대해 액세스가 금지될 경우 통화 거부를 일으키며 SIP 403 응답 코드를 반환할 수 있습니다.아웃바운드 라우팅은 발신자가 UC 사용자인 경우만 적용됩니다.그렇지 않은 경우 OCS는 해당 URI에 대해 설정된 고정 경로를 사용하여 게이트웨이에 접근을 시도합니다.
  • 변환된 전화 번호가 UC 사용자 번호인 경우 INVITE는 해당 사용자의 SIP URI로 전송됩니다(3B단계).인바운드 라우팅은 UC 사용자와 SIP URI가 목적지인 통화에만 적용되는 OCS의 기능입니다.앞으로 자세히 살펴보겠지만 인바운드 라우팅에는 UC 사용자에 대해 벨 울림 시간 제한, 착신 전환 및 음성 메일 전달 규칙이 적용됩니다.
정규화 과정을 거친 번호는 클라이언트의 위치에 따라 달라질 수 있습니다.관리자는 위치 프로필을 구성하고 특정 위치에 맞는 번호 변환 규칙을 지정할 수 있습니다(예: 해당 지역에서 네 자리 다이얼이 작동하는 방식).각 UC 사용자에게는 지정된 위치 프로필이 있으며 시스템의 모든 클라이언트는 각자의 위치 프로필에 맞는 규칙을 대역 내 프로비전을 사용하여 다운로드합니다.다음으로는 인바운드 라우팅에 대해 자세히 알아 보겠습니다.

인바운드 라우팅
인바운드 라우팅 규칙은 시스템에 등록된 클라이언트가 있거나 없을 때 통화를 사용자에게 전달하는 방법을 지정합니다.인바운드 라우팅은 수신 전화에 대해 사용자의 현재 상태에 따라 다른 규칙을 적용합니다. 예를 들어 사용자가 현재 상태를 방해 금지로 설정했다면 수신 전화를 음성 메일로 보냅니다.인바운드 라우팅은 현재 상태 컨테이너 수준을 알고 있고 차단된 컨테이너에 있는 사용자의 전화를 자동으로 거부합니다.그림 5는 OCS 인바운드 라우팅 구성 요소에서 지원하는 선택 사항을 요약해서 보여 줍니다.
그림 5 인바운드 라우팅 기능
기능 | 설명
벨 울림 횟수 | 20초가 기본값입니다.사용자는 이 시간을 최대 60초로 변경할 수 있습니다. 이 시간이 경과하면 응답하지 않은 전화를 처리하는 곳으로 보냅니다.
응답하지 않은 전화를 음성 메일로 보내기 | 사용자에게 음성 메일이 활성화된 경우 기본으로 설정됩니다.통화가 인바운드 라우팅 규칙에 따라 전달됩니다.
음성 메일로 가기 전에 발신자가 끊은 경우 부재 중 전화 알림 생성 | Exchange UM에 부재 중 전화를 알립니다.
전화 차단 | 차단된 발신자의 전화를 거부합니다(SIP ID가 있는 사용자의 전화만 차단 가능).
방해 금지 | 전화를 음성 메일로 보냅니다.사용자가 이 모드로 설정되어 있으면 동시 수신 대상도 벨이 울리지 않습니다.
방해 허용 목록 | 발신자가 팀 컨테이너에 속해 있으면 사용자가 방해 금지 상태에 있더라도 전화를 걸 수 있도록 허용합니다.
동시 수신 | 수신 전화를 PSTN 전화와 Communicator 및 Communicator Phone Edition 클라이언트에서 모두 받을 수 있게 구성합니다.
즉시 착신 전환 | 수신 전화를 다른 사용자, PSTN 전화 또는 음성 메일로 즉시 전환합니다.
응답하지 않은 전화 착신 전환 | 응답하지 않은 전화를 다른 사용자, PSRN 전화 또는 음성 메일로 전환합니다.
작업 시간 | Outlook 일정에 구성된 작업 시간을 사용하여 사용자의 착신 전환 설정을 활성화합니다.
인바운드 라우팅 규칙은 XML 스키마이며 사용자의 자체 프로비전 정보의 일부로 서버에 업로드됩니다.그림 6은 인바운드 라우팅의 작동 방식을 보여 줍니다.OCS 시스템에서 사용자에게 걸려오는 전화는 사용자에게 전달되는 것이 기본값입니다("나"로 표시됨).벨 울림 횟수 안에 전화를 받지 않으면, 기본적으로 응답하지 않은 전화가 음성 메일로 보내집니다.사용자는 기본 구성을 수정하여 직접 다른 번호, 다른 사람 또는 음성 메일로 즉시 착신이 전환되도록 선택할 수 있습니다.
그림 6 통화 라우팅(작업 시간 내)(크게 보려면 이미지 클릭)
다른 사람이나 번호로 즉시 착신 전환된 전화는 해당하는 사람이나 번호의 인바운드 라우팅 규칙에 따라 처리됩니다.또한 사용자는 응답하지 않은 전화를 다른 번호나 사람으로 전환하도록 설정할 수 있습니다.
사용자가 착신 전환 규칙에서 Outlook 작업 시간에만 적용 옵션을 선택한 경우 그림 6에 있는 규칙은 작업 시간에만 적용되며, 그 외의 시간에는 등록된 끝점에 전화를 걸 때의 기본 동작이 적용됩니다.이러한 동작을 위해서는 Microsoft Exchange Server 2007과 Outlook 2007 클라이언트가 조직에 배포되어 있어야 합니다. Communicator는 작업 시간 정보를 Exchange 2007 가용성 웹 서비스에서 얻으며 이 서버의 위치를 얻기 위해 Outlook 2007 자동 검색 지원을 활용하기 때문입니다.

품질 보고 및 문제 해결
OCS 2007 시스템의 클라이언트는 차세대 오디오 코덱인 RTAudio를 사용하므로 지터, 패킷 손실 등과 같은 불완전한 네트워크 조건을 허용할 수 있지만, 관리자가 잠재적인 문제점을 발견하고 수정할 수 있도록 모니터링은 여전히 필요합니다.OCS 2007 시스템의 클라이언트는 모든 통화의 품질을 보고하고, 매 통화가 끝날 때마다 대역폭, 손실, 지터, 평균 평가점(사용자가 느끼는 기준), 사용된 장치 등을 포함하는 자세한 통계를 중앙 QoE(체감 품질) 서버에 제공합니다.이 과정은 SIP SERVICE 요청 페이로드를 QoE 서버에 전송하여 이루어지며, 서버의 주소는 대역 내 프로비전 메커니즘을 통해 설정됩니다.
모든 클라이언트 끝점은 통화 품질에 대해 독립적으로 QoE 서버에 보고합니다.신호에 오류가 생겨 통화가 실패하면 클라이언트는 OCS에도 보고하며, 이러한 OCS는 클라이언트에서 발생한 모든 오류에 대한 리포지토리를 제공합니다.﻿

전체 과정
지금까지 번호 입력, 인바운드 및 아웃바운드 라우팅, 연결 확인을 포함하여 통화를 설정하는 여러 측면을 살펴보았습니다. 이제 전체 프로세스를 설명하겠습니다.그림 7은 사용자가 전화를 거는 과정을 시간 순서대로 요약해서 보여 줍니다.OCS 시스템의 클라이언트는 통화 설정에서 중요한 역할을 하며 통화 설정 과정 전체를 관리합니다.OCS는 통화의 초기 라우팅에 관여하며 에지 서버는 최적의 미디어 경로를 찾도록 도와줍니다.다음으로, 대화에 대해 살펴보겠습니다.
그림 7 종단 간 통화 흐름(크게 보려면 이미지 클릭)

다중 모드 동작 및 대화
대화는 OCS 시스템에서 중심 개념입니다.대화는 다수의 사람들 사이에 형성된 다중 모드 세션으로서 음성, 비디오, IM이 동시에 포함될 수 있으며 세션 중의 파일 전송, Outlook 전자 우편, Microsoft Office OneNote®에 저장된 메모 등도 포함될 수 있습니다.
OCS 클라이언트 시스템의 설계에 영향을 줄 수 있는 요인으로 다음과 같은 대화의 측면이 있습니다.
  • 대화에 관련된 모든 형식은 같은 창을 사용합니다.인스턴트 메시지가 음성 대화에 추가되는 경우 같은 창에 연결됩니다.
  • 대화는 장치를 넘나들며 발생할 수 있습니다.예를 들면 사용자는 Communicator Phone Edition에서 음성을 선택하고 IM은 Communicator 데스크톱에서 선택할 수 있습니다.
  • 모든 모드는 하나의 전화 회의로 에스컬레이션됩니다.에스컬레이션이 발생하면 해당 형식이 현재 적용 중인 장치에 상관없이 대화의 모든 형식은 함께 에스컬레이션되어야 합니다.예를 들어, Communicator Phone Edition에서 음성 모드를 사용할 수 있고 동일한 대화의 IM 모드를 Communicator 데스크톱에서 사용할 수 있는 경우, 전화 회의로 에스컬레이션되면 음성과 IM 모두 해당 대화와 동일한 참가자를 개입시키게 됩니다.
  • 개별 세션에는 해당하지 않지만 대화는 로그가 기록됩니다.통화 로그에는 대화 중에 작성된 메모, 교환된 인스턴스 메시지, 음성의 길이 등을 포함하여 대화에 대한 세부 정보가 포함됩니다.사용자가 Outlook에서 통화 로그를 열어보면 전체 대화와 관련하여 유용한 통합 정보를 얻을 수 있습니다.
  • 대화 로그에 이어서 대화를 진행할 수 있습니다.OCS 클라이언트는 장치와 응용 프로그램에서 대화를 고유하게 식별할 수 있는 번호인 대화 ID를 사용하여 대화를 서로 묶습니다.이전의 대화 기록 로그에서 새로운 대화가 시작되면 대화 사이의 차이를 계산하는 복잡한 메커니즘이 사용됩니다.또한 동일한 대화 ID가 Outlook의 전자 메일 ID로 저장됩니다.
대화 ID는 SIP INVITE에 있는 사용자 지정 속성인 Ms-Conversation-Id의 일부로서 전달됩니다.그림 8은 음성이 추가되고, 그 다음에 IM이 추가될 때 트랜잭션을 보여 줍니다.다중 모드 대화가 종료될 때 Outlook에 저장되는 기록 로그도 동일한 대화 ID를 갖게 됩니다.
그림 8 다중 모드 대화와 대화 ID(크게 보려면 이미지 클릭)

Exchange UM은 OCS 2007의 음성 메일 시스템입니다.OCS는 UC를 사용하는 전화만 Exchange UM으로 라우팅합니다.OCS는 Exchange UM과의 통합을 위해 다음과 같은 다양한 기능을 제공합니다.
  • Communicator의 전화 UI (그림 9 참조)에 있는 음성 메일 호출 옵션을 사용하면 UM 사서함 관리 및 인사말 변경과 같은 작업을 할 수 있으며, 사용자가 이미 인증되었기 때문에 PIN을 입력할 필요가 없습니다.
  • Communicator UI(그림 10 참조)에 있는 메시지 대기 표시기를 통해 사용자가 Outlook에서 음성 메일 폴더를 열 수 있습니다. 반면 Communicator Phone Edition에서는 사용자가 전화에서 직접 음성 메시지를 재생합니다.
  • Communicator UI를 통해 전화를 음성 메일로 전달할 수 있습니다.
  • 통화를 거부하면 자동으로 음성 메일로 연결됩니다.
  • Outlook에 있는 음성 메일 항목에서 전화에서 재생을 선택하면 Office Communicator 클라이언트에서 직접 들을 수 있습니다.
그림 9 Communicator의 음성 메일 호출 옵션
그림 10 Communicator의 메시지 대기 표시기
OC에서 음성 메일 알림이 수신되는 방식은 Communicator Phone Edition과 다릅니다.OC는 Outlook에 있는 음성 메일 검색 폴더에 새로운 메일 알림을 등록하고 이 폴더에 새 메시지가 있음을 알립니다.또한 Communicator는 부재 중 대화 및 통화 로그도 사용합니다.

맺음말
OCS 2007의 음성 통화는 몇 가지 RFC를 활용하는 SIP에 기반을 둔 시스템이며 지금까지 그 동작 방식에 대해 살펴보았습니다.OCS에서 클라이언트 끝점은 통화를 관리하는 중심 역할을 담당합니다.모든 음성 통화는 기본적으로 안전하게 암호화됩니다.OCS는 전화 번호를 조작하고 시스템상에서 전화 번호의 흐름을 관리하는 유연한 구성 요소를 제공합니다.
대화는 OCS의 중심 개념으로서 음성, IM, 비디오를 포함합니다.OCS는 Exchange UM과 통합되며, 이를 통해 Communicator 끝점에서 음성 메일에 대한 알림을 수신할 수 있고 Outlook을 통해 음성 메일에 액세스하거나 서버에서 직접 액세스할 수 있습니다.

Rajesh Ramanathan은 통신 분야에서 14년간 일해왔으며 Office Communicator 2007의 음성 프로토콜, 사용자 환경, 음성 및 회의 기능을 설계했습니다.현재 Microsoft에서 Office Communicator 팀의 수석 프로그램 관리자로 재직 중입니다.문의 사항이 있으면 rajeshra@microsoft.com으로 연락하시기 바랍니다.


통신 및 공동 작업
Groove와 SharePoint로 만드는 강력한 연결
Alan Maddison
한 눈에 보기:
  • SharePoint 문서 라이브러리 만들기
  • Groove 작업 영역 만들기
  • Groove와 SharePoint 동기화
  • 작업 영역 액세스 권한 부여

목차
Groove와 SharePoint의 조합
시작
승인 제어 설정
Groove 작업 영역 만들기
Groove와 SharePoint 동기화
작업 영역 액세스 권한 부여
맺음말
IT 전문가들은 종종 Microsoft Office Groove 2007(Groove)과 Microsoft Office SharePoint Server 2007(SharePoint)의 확연한 유사성에 대해 의아해하며
이들이 각기 어떤 환경에서 사용되는지 잘 구분하지 못합니다.얼핏 보기에는 두 제품 모두 공동 작업 기능을 제공한다는 점에서 매우 비슷해 보이지만구성을 자세히 살펴보면 차이점을 알 수 있습니다.
SharePoint®는 견고하고 확장 가능한 콘텐츠 관리 프레임워크와 공동 작업 도구 집합을 제공하여 구조화된 워크플로를 지원합니다.반면에, Groove™는 IT 오버헤드를 거의 발생시키지 않으면서 신속한 작업 영역 배포를 가능하게 하는 공동 작업 도구 집합입니다.문서 공동 작업, 토론 스레드, 기능들 간 일정 작성을 지원함으로써 Groove는 동적이고 안전한 임시 공동 작업을 위한 이상적인 프레임워크를 제공합니다.따라서 대부분의 사용자는 기본적으로 이 두 제품을 서로 다른 방법으로 사용하게 됩니다.
뿐만 아니라, Groove 2007 릴리스에서는 SharePoint 파일 도구로 SharePoint와 통합되는 기본 제공 지원이 추가되었습니다.이 도구를 사용하면 Groove 작업 영역을 SharePoint 문서 라이브러리와 동기화할 수 있습니다. 기본 제공 통합이란 간편하게 두 제품을 최대한으로 활용할 수 있다는 의미입니다.실제로, Groove의 유연하고 유동적인 특성에 SharePoint의 기능과 정교함이 합쳐지면 다양한 측면에서 상당한 장점이 있습니다.
Groove와 SharePoint의 조합
오늘날 IT 업계에서는 조직과 협력업체, 공급업체 간에서 공동 작업에 대한 요구가 어느 때보다 증가하고 있습니다.하지만 SharePoint와 같은 제품을 사용하여 구현되는 강력한 공동 작업 솔루션은 대부분 조직 내부 팀을 대상으로 하거나 조직 전체에서 정보를 공유할 수 있도록 하는 데 치중하는 경향이 있습니다.이러한 경우 조직 외부의 사용자에게 액세스 권한을 부여하는 과제는 관리와 보안이라는 두 가지 측면에서 큰 문제가 될 때가 많습니다.이럴 때는 사용자가 그때그때 외부 협력업체와 연결할 수 있게 하는 것이 목표가 됩니다.
Groove와 SharePoint의 조합은 바로 이를 위한 솔루션을 제공합니다.SharePoint가 조직 내 공동 작업, 콘텐츠 검색 및 워크플로 프레임워크를 제공하는 한편, Groove에서는 간편한 조직 간 공동 작업까지 포함하도록 이러한 기능을 확장합니다.Groove를 사용하면 기업 간 경계를 넘어 신속하게 공동 작업 영역을 마련할 수 있습니다.뿐만 아니라, 192비트 AES(Advanced Encryption Standard) 대칭 키 지원을 통해 공동 작업의 보안을 보장합니다.실제로, Groove의 보안은 기본 제공 방식이고 항상 작동하므로 구성에 신경 쓸 필요가 없습니다.
Groove의 보안 아키텍처는 이러한 작업 영역과 그 콘텐츠에 대해 로컬에 저장되거나 네트워크 전송 중에 강도 높은 보호를 제공합니다.SharePoint 파일 도구는 이러한 정보가 SharePoint 문서 라이브러리와 양방향으로 동기화되도록 하여 간편한 내부 액세스가 가능하며 중앙에서 사용할 수 있는 정보로 만듭니다.실제로 이러한 과정이 어떻게 진행되는지 알아보기 위해 구체적인 예를 들어 살펴보겠습니다.
시작
조직은 일상의 비즈니스 활동에서 많은 기업과 공동으로 작업을 진행합니다.여기에는 대개 외부 조직만이 아니라 재무, 홍보, 법무 등 정기적으로 함께 일할 필요가 없는 부서의 직원도 포함됩니다.따라서 이러한 조직에서는 공동으로 작업할 임시 내부 팀을 구성하고, 이러한 공동 작업의 결과물을 공동 작업 프로세스에 참여하지 않았지만 최종 납품을 위해 액세스할 필요가 있는 사용자가 사용할 수 있어야 합니다.SharePoint와 Groove를 사용하면 이러한 목표를 손쉽게 달성할 수 있습니다.
Groove 작업 영역과 동기화할 SharePoint 문서 라이브러리가 아직 없으면 우선 이 라이브러리를 만들어야 합니다.이렇게 하려면 SharePoint에 접속하여 모든 콘텐츠 보기 링크를 선택합니다.이 페이지가 로드되고 나면 만들기를 선택하고 그림 1과 같이 라이브러리 열에서 문서 라이브러리를 선택합니다.
그림 1 SharePoint 문서 라이브러리 만들기(크게 보려면 이미지 클릭)
새 문서 라이브러리 페이지를 구성하려면 라이브러리 이름과 설명, 빠른 연결 섹션에 라이브러리를 포함할지 여부, 버전 관리 사용 여부, 라이브러리에서 직접 만든 새 문서의 기본 형식 등 다양한 요소를 설정해야 합니다.문서 버전 기록 옵션은 기본적으로 비활성화되어 있지만 버전 관리를 사용하는 환경에서는 이 기능을 활성화해야 합니다.또한, SharePoint에서 사용할 수 있고 Groove와 SharePoint 구현의 일부로 활용할 수 있는 몇 가지 고급 기능에 대해서도 고려해야 합니다.다음과 같은 향상된 기능이 포함됩니다.
  • 버전 기록
  • 승인 제어
  • 체크 아웃 절차
  • 워크플로 제어
  • 문서 보존 정책
  • 감사
  • RSS(Really Simple Syndication)
Groove에서 작업할 때 SharePoint를 통해 사용할 수 있는 이러한 추가적인 기능은 굉장한 가치를 제공합니다.지금 소개하는 예에서 이러한 추가 기능은(여기서는 승인 제어) 그 유용성이 명확히 드러납니다.예를 들어, 팀 구성원들이 Groove에서 공동으로 문서 초안을 작성할 경우최종 문서가 완성되어 검토 준비가 되면 SharePoint와 동기화하여 승인 프로세스를 진행할 수 있습니다.

승인 제어 설정
이 기능을 구성하려면 문서 라이브러리에서 설정 메뉴를 선택한 다음 설정 항목을 선택합니다.그러면 모든 구성 및 사용자 지정 옵션이 표시됩니다.승인 구성을 위해 사용 권한 및 관리 섹션에서 워크플로 설정 링크를 선택하여 워크플로 추가 페이지로 이동합니다.이제 워크플로 템플릿을 선택하고(이 예에서는 Approval 템플릿 선택) 워크플로 이름을 입력합니다.그 다음은 기존 작업 목록을 사용할 것인지 새 목록을 만들 것인지 결정해야 합니다.새 작업 목록을 사용하는 것이 기밀 유지 차원에서 낫지만 여기서는 논의 대상이 아니므로 기본값을 선택합니다.
작업 목록을 선택하고 나면 승인 프로세스 시작 방식을 결정해야 합니다.올바른 권한이 있는 임의의 인증된 사용자가 프로세스를 시작할 수 있는 수동 프로세스로 설정합니다.다른 옵션은 이 프로세스를 자동화하여 해당 문서 라이브러리에서 버전 관리가 사용되는 경우 버전 관리를 기반으로, 또는 새 문서가 추가되거나 기존 문서가 변경될 때마다 시작되도록 합니다.
다음을 눌러 구성 옵션을 수락한 다음에는 몇 가지 최종 구성 정보를 입력해야 합니다.맨 처음 구성할 옵션은 작업 할당 방법입니다.승인 프로세스에 여러 사람이 개입될 수 있으므로 한 사람이 항목을 승인하고 나면 다음 사람에게 이동하는 방식으로 승인자를 직렬로 지정하거나, 누구든지 언제든지 승인하는 방식으로 병렬로 지정할 수 있습니다.그 다음은 승인자가 다른 사람에게 작업을 할당할 수 있도록 허용할 것인지, 그리고 작업이 완료되기 전에 승인자가 변경을 요청할 수 있게 할 것인지 결정해야 합니다.
그 다음 단계는 실제 승인자를 선택하고 작업 완료 기한을 정합니다.마지막으로, 워크플로의 완료 시점을 결정합니다.모든 작업이 완료되면 워크플로가 완료되는 것이 기본 옵션입니다.마지막 구성 옵션에서 워크플로가 완료되었을 때 승인 상태를 업데이트할 것인지 여부를 지정합니다.확인 단추를 누르면 승인 프로세스가 만들어지고 문서 승인 프로세스를 시작할 수 있습니다.

Groove 작업 영역 만들기
SharePoint 문서 라이브러리를 만든 후 다음 단계는 Groove 작업 영역을 만드는 것입니다.이렇게 하려면 먼저 Groove 계정과 ID가 하나 이상 있는지 확인합니다.ID는 Groove에서 상태 표시와 의사 소통을 위한 기반이 됩니다.Groove 계정 하나에 여러 ID에 연결할 수 있고 이러한 ID는 각각 고유한 연락처 파일과 연결되어 사용하는 각 ID에 대한 연락처 정보를 사용자 지정할 수 있습니다.Groove 계정 및 연결된 ID를 내보내서 여러 컴퓨터에서 사용할 수도 있습니다.
계정과 ID를 만들었으면 시스템 트레이에서 Groove 아이콘을 두 번 클릭하여 Groove 실행창을 엽니다.새 작업 영역 옵션을 클릭하고 작업 영역 이름을 입력한 다음 표준 작업 영역 유형을 선택합니다.Groove 표준 작업 영역은 작업 영역 구성원에게 현재 상태, 경고 및 역할 할당을 제공합니다.확인을 클릭하면 작업 영역이 만들어지고 열립니다.그림 2는 파일 도구에 몇 가지 파일이 추가된 새 작업 영역의 모습을 보여 줍니다.이제 작업 영역의 기능이 작동하며, 알림을 구성하거나 원하는 도구를 추가하여 설정을 마칠 수 있습니다.
그림 2 새 Groove 작업 영역(크게 보려면 이미지 클릭)
알림은 도구, 작업 영역 또는 개별 파일 수준에서 구성할 수 있습니다.없음, 보통, 높음, 그리고 자동의 네 가지 알림 수준이 있습니다.높음 및 자동 알림은 오디오 파일을 재생하는 반면, 보통 수준은 새 콘텐츠를 강조 표시합니다.또한, 사용자가 특정 작업 영역에 들어갔을 때 알려주도록 구성할 수도 있습니다.알림을 구성하려면 옵션 메뉴에서 알림 설정을 선택합니다.개별 파일 수준의 경고는 파일 자체 속성에서 설정하며 작업 영역에서 파일을 마우스 오른쪽 단추로 클릭하고 속성을 선택하면 됩니다.
문서 공동 작업용 파일 도구와 기본 표준 작업 영역의 일부인 토론 스레드용 토론 도구 외에도 일정, 양식, 문제점 처리 보고서, 모임, 스케치북 및 SharePoint 파일 도구 등 많은 도구가 있습니다.이 도구들은 유용한 공동 작업 관련 기능을 추가로 제공합니다.도구를 선택하려면 작업 영역 오른쪽 아래에서 이 작업 영역에 도구 추가 단추를 선택한 다음 그림 3과 같이 추가할 도구를 선택합니다.또한, 언제든지 손쉽게 도구를 삭제할 수도 있습니다.
그림 3 Groove 작업 영역에 도구 추가(크게 보려면 이미지 클릭)

Groove와 SharePoint 동기화
SharePoint 파일 도구를 추가한 다음에는 동기화할 문서 라이브러리가 있는 SharePoint 사이트의 URL을 설정해야 합니다.이렇게 하려면 그림 4와 같이 Groove 작업 영역 화면 맨 아래에 있는 SharePoint 파일 탭을 선택한 다음 작업 영역에서 설정 단추를 누릅니다.
그림 4 SharePoint 파일 도구 설정(크게 보려면 이미지 클릭)
URL을 입력하고 나면 SharePoint 사이트에서 사용할 수 있는 모든 라이브러리가 표시됩니다.그러면 그림 5와 같이 사용할 라이브러리를 선택합니다.Groove에서 연결하여 자동으로 동기화를 시작합니다.이렇게 동기화하면 현재 SharePoint 라이브러리에 있는 모든 문서가 Groove 작업 영역을 통해 다운로드되어 사용할 수 있게 됩니다.그림 6에 그 예가 나와 있습니다.
그림 5 URL 설정 후 Groove에 SharePoint 라이브러리가 표시됨(크게 보려면 이미지 클릭)
그림 6 Groove와 SharePoint 동기화(크게 보려면 이미지 클릭)
지금 막 다운로드했기 때문에 Groove 작업 영역에서 문서가 읽지 않음으로 표시됩니다.SharePoint와 동기화된 모든 파일에는 SharePoint 체크 인/체크 아웃 기능을 사용할 수 있습니다.뿐만 아니라, 파일을 체크 아웃하면 문서를 편집하는 동안 다른 사용자가 수정할 수 없습니다.
또한 SharePoint 파일 도구는 양방향 동기화를 지원하므로, Groove를 통해 SharePoint 파일 도구에 파일을 추가하면 SharePoint 문서 라이브러리에 동기화됩니다.기본적으로 동기화는 자동으로 실행되도록 설정되어 있지만 지금 동기화 단추를 눌러 수동으로 시작할 수 있습니다.이렇게 하면 그림 7과 같이 동기화 및 관련 작업이 필요한 모든 파일의 변경 내용이 요약되어 표시되며, 이러한 파일을 SharePoint에서 가져오거나 SharePoint에 보냅니다.
그림 7 수동 동기화 후 표시되는 변경 내용 요약 정보(크게 보려면 이미지 클릭)
한 가지 유의할 점은 Groove 표준 작업 영역의 일부분으로 배포되는 파일 도구가 SharePoint 파일 도구와 다르다는 것입니다.Groove 파일 도구는 SharePoint와 동기화를 수행하지 않으므로 필요에 따라 제거할 수 있습니다.하지만 SharePoint와 동기화되지 않기 때문에 이 도구는 실제로 팀에서 프로젝트를 진행하면서 액세스해야 하는 임시 파일을 저장하는 위치로 사용할 수 있습니다.여기에 저장된 파일도 작업 영역 구성원 간에 동기화됩니다.

작업 영역 액세스 권한 부여
공동 작업을 위한 기본 인프라가 배포되었으므로 이제 사용자에게 작업 영역에 대한 액세스 권한을 부여할 수 있습니다.하지만 먼저, 전자 메일이나 Groove 인스턴트 메시징을 사용하여 사용자를 초대해야 합니다.아니면 Groove에서는 초대를 파일로 내보낼 수도 있습니다.확장명이 .grv이며 기본적으로 Groove 응용 프로그램과 연결된 이 파일은 웹 사이트에 게시하여 받는 사람이 초대를 다운로드하도록 하는 등 여러 가지 방법으로 전달할 수 있습니다.
Groove 인스턴트 메시징에는 지정된 받는 사람만 초대를 읽을 수 있도록 하는 보안 검사 기능이 포함되어 있습니다.전자 메일이나 초대 파일을 사용하여 초대할 때 수락 확인 필요 옵션을 선택하면 작업 영역에 참가하는 사람이 해당 사용자인지 이중으로 확인할 수 있으므로 이 옵션을 선택하십시오.이러한 기능은 작업 영역에 보안 계층을 추가로 제공합니다.또한, 보류 중인 초대를 취소할 수도 있습니다.
사용자를 작업 영역에 초대할 때 초대를 받는 사람 각자에 대해 역할을 선택해야 합니다.관리자, 참가자, 방문자의 역할이 있으며 기본적으로 참가자 역할이 할당됩니다.각각의 역할은 작업 영역 내에서 특정 권한을 가지며, 대개 관리자 역할은 작업 영역에서 도구 삭제를 비롯하여 실제로 모든 작업 권한이 필요한 사람으로 제한해야 합니다.기본적으로 작업 영역을 만든 사람에게 관리자 역할이 할당되며 지정된 역할은 언제든지 변경할 수 있습니다.
이 글에서 논의하는 프로젝트가 임시적이라는 특성을 고려했을 때 마지막 작업은 모든 작업을 완료한 뒤 Groove 작업 영역을 삭제하는 일이 될 수 있습니다.SharePoint 라이브러리와 작업 영역의 동기화를 수행했는지 확인한 다음 작업 영역을 열고 파일 메뉴로 가서 작업 영역 삭제를 선택합니다.그리고 이 컴퓨터에서 삭제 옵션과 모든 구성원에 대해 삭제 옵션 중에 선택합니다.모든 구성원에 대해 삭제하지 않는 경우, 각 사용자의 시스템에 해당 작업 영역의 복사본이 생성되어 영구적으로 저장됩니다.
프로젝트의 완료는 Groove와 SharePoint의 상호 보완적 속성을 활용할 수 있는 또 다른 기회입니다.문서의 최종 동기화가 실행되고 나면 SharePoint의 정보 관리 정책 설정을 활용할 수 있는 최적의 여건이 됩니다.특히, 데이터 만료 기능을 활성화하여 보관된 데이터를 자동으로 관리하는 수단으로 사용할 수 있습니다.
만료를 사용하면 데이터를 보존할 기간을 지정할 수 있습니다.이 보존 기간이 끝나면 SharePoint에서 자동으로 데이터를 삭제하거나 워크플로 프로세스를 시작할 수 있습니다.이 기능은 Groove 데이터를 기업의 정보 수명 주기 관리 정책에 통합하는 훌륭한 수단입니다.데이터 보존 정책은 언제든지 구성할 수 있습니다.라이브러리를 처음 구성할 때 이 정책을 구성하지 않았으면 지금 구성할 수 있습니다.
만료를 활성화하려면 문서 라이브러리에서 설정 메뉴를 선택하고 문서 라이브러리 설정 메뉴 항목을 선택합니다.그러면 페이지의 사용 권한 및 관리 섹션에서 정보 관리 정책 설정 메뉴 옵션을 볼 수 있습니다.정보 관리 정책 설정 링크를 클릭한 다음 새 사용자 지정 정책을 정의하거나 문서 라이브러리에서 사이트 수준에서 정의된 정책을 사용하도록 선택할 수 있습니다.
사용자 지정 정책을 정의하려면 몇 가지 구성 정보를 입력해야 합니다.따라서, 위의 예에서는 만료를 활성화한 다음 보존 기간 및 이 보존 기간 만료 시 수행할 작업을 선택합니다.
Groove는 동적이고 직관적이며 안전한 임시 공동 작업용 프레임워크를 제공하도록 개발된 풍부한 기능의 공동 작업 클라이언트입니다.다양한 도구 집합을 지원하는 Groove는 가볍고 융통성있는 공동 작업 플랫폼으로서, 조직 내부나 여러 조직 사이에서 편리하게 사용할 수 있습니다.
SharePoint의 견고하고 강력한 콘텐츠 관리 프레임워크와 공동 작업 도구 집합을 이미 사용하고 있다면 Groove를 추가하여 비교할 수 없는 강력한 솔루션을 얻을 수 있습니다.이 두 제품은 상호 보완성이 뛰어나 함께 사용하면 공동 작업 팀의 생산성을 크게 향상시킬 수 있습니다.

Alan Maddison은 Brocade의 Strategic Business Systems 사업부 선임 컨설턴트로서 재직 중입니다.


Windows 관리
Windows Server 2008 Failover Clustering 소개
Chuck Timon
한 눈에 보기:
  • 장애 조치(failover) 클러스터 관리 스냅인
  • 새 기능 및 강화된 기능
  • 백업 및 복원 기능
  • Windows Server 2003에서 마이그레이션

목차
새 관리 인터페이스
향상된 구성 프로세스
포함된 유효성 검사 절차
새 쿼럼 모델
강화된 보안 기능
확장된 네트워킹 기능
저장소와의 상호 작용에서 향상된 안정성
기본 제공 복구 프로세스
새 백업 및 복원 기능
Windows Server 2003 서버 클러스터에서 마이그레이션
Windows NT 4.0 Enterprise Edition에서 클러스터링이 처음 도입된 이후 설치가 너무 어렵고 유지 관리는 더욱 어렵다는 사용자들의 불만이 제기되어 왔습니다.클러스터 관리에서
관리자에게는 단순한 클러스터링 자체에 대한 이해 그 이상의 지식이 필요했습니다. 예를 들어 저장소 기술 및 클러스터 서비스가 다양한 저장소 솔루션과 상호 작용하는 방식에 대한 해박한 지식이 추가로 요구되었습니다.따라서, 많은 조직에서 고가용성 솔루션을 설치하고 실행하며 유지 관리하는 데 필요한 이런 포괄적인 기술을 확보하기가 어려웠습니다.
클러스터링은 수년간 향상되어 왔지만 Microsoft가 Windows Server® 2008을 개발하기 시작한 당시에도 여전히 만족스럽지 못한 점이 많았습니다.Microsoft 개발 팀에서는 이런 점을 염두에 두고 단순성을 기본 목표로 클러스터링을 재설계하기 시작했습니다.Windows Server 2008에서 Microsoft® Cluster Services(MSCS)는 완전히 새 단장을 하여 이제 장애 조치(failover) 클러스터링이라는 이름으로 사용됩니다.
그렇다고 해서 새로운 장애 조치(failover) 클러스터링 구현이 오직 단순성만을 제공하는 것은 아닙니다.수년간 클러스터링 솔루션에 기대하는 개선점에 대해 여러 조직에서 제공한 귀중한 의견을 통해 Microsoft는 많은 교훈을 얻었습니다.새로운 장애 조치(failover) 클러스터링 기능에서는 사용자들이 보고한 주요 문제점을 다수 해결했으며 흥미로운 새 기능을 다수 도입하여 개선했습니다.이 기사에서는 Windows Server 2008 Failover Clustering의 멋진 새 기능을 몇 가지 소개하겠습니다.

새 관리 인터페이스
장애 조치(failover) 클러스터링을 설치한 후 관리 도구를 이용하거나 Cluadmin.msc를 실행하여 장애 조치(failover) 클러스터 관리 인터페이스에 액세스할 수 있습니다.Windows Server 2008의 다른 관리 인터페이스와 마찬가지로 장애 조치(failover) 클러스터 관리 스냅인도 역시 MMC(Microsoft Management Console) 3.0입니다.노련한 클러스터 전문가라도 장애 조치(failover) 클러스터 관리 스냅인을 처음 열면 지도 없이 낮선 외국 땅에 떨어진 것처럼 느낄 것입니다.
새 인터페이스는 그림 1과 같이 별개의 세 개 창으로 나뉩니다.왼쪽 창에는 조직 내의 Windows Server 2008 장애 조치(failover) 클러스터를 모두 나열한 목록이 나타납니다.가운데 창은 왼쪽 창에서 선택한 클러스터 구성 세부 정보를 표시하고, 오른쪽 창은 실행할 수 있는 작업을 보여 줍니다.
그림 1 장애 조치(failover) 클러스터 관리 스냅인(크게 보려면 이미지 클릭)
왼쪽 창에서 Storage를 선택한 경우를 예로 설명하겠습니다.가운데 창에는 클러스터에서 구축된 저장소와 현재 사용 가능한 저장소(있는 경우)에 대한 세부 정보가 표시됩니다.그림 1에서 볼 수 있듯이 클러스터에 감시 디스크를 지원하는 저장소, 파일 서버용으로 구축된 저장소 및 사용 가능한 저장소가 포함되어 있습니다.오른쪽 창은 저장소 추가와 같은 관련 작업 목록을 보여 줍니다.장애 조치(failover) 클러스터 관리 스냅인은 이전 버전의 Microsoft Clustering Services를 관리하는 데 사용할 수 없습니다.

향상된 구성 프로세스
장애 조치(failover) 클러스터를 구성하는 것은 매우 쉽습니다.클러스터를 구성, 재구성 및 유지 관리하는 많은 작업에 마법사가 제공됩니다.마법사 덕분에 관리자는 리소스가 제대로 구성되었는지 또는 온라인에서 올바른 순서로 나타나는지 여부에 대해 더 이상 신경 쓸 필요가 없습니다.
그림 2는 고가용성 마법사를 보여 줍니다.이 예에서는 파일 서버를 구성하였습니다.왼쪽에는 마법사에서 관리자가 작업을 수행하는 단계 목록이 표시됩니다.프로세스가 완료되면 요약 페이지가 표시되고 보고서를 검토할 수 있습니다.
그림 2 고가용성 마법사(크게 보려면 이미지 클릭)

포함된 유효성 검사 절차
이전 버전의 Windows Server에서는 해당 하드웨어 구성이 Windows Server 카탈로그의 클러스터 솔루션 목록에 포함되어 있어야 지원되는 클러스터 솔루션으로 간주되었습니다.지리적으로 분산된 클러스터 범주에 따로 나열된 멀티 사이트 클러스터의 경우도 마찬가지였습니다.카탈로그 목록에 포함되려면 하드웨어 공급업체가 일련의 WHQL(Windows Hardware Quality Lab) 테스트를 수행하고 결과를 Microsoft에 제출해야 했습니다.이는 공급업체에게 비용이 많이 드는 일이었으므로 Windows Server 카탈로그 데이터베이스를 유지 관리하기가 어려웠습니다.
Windows Server 2008에서는 기본 제공 유효성 검사 프로세스가 장애 조치(failover) 클러스터링에 포함되어 있습니다.이 프로세스는 그림 3과 같이 네 개의 주 범주로 나뉜 일련의 테스트로 구성되어 있습니다.
그림 3 장애 조치(failover) 클러스터 유효성 검사 테스트 범주(크게 보려면 이미지 클릭)
네트워크 범주가 확장되어 수행되는 테스트를 볼 수 있습니다. 각 범주는 일련의 테스트를 포함합니다.네 범주 중 가장 중요한 저장소 범주에는 저장소 솔루션이 Windows Server 2008 장애 조치(failover) 클러스터를 위해 마련된 새 요구 사항을 준수하는지 확인하는 테스트가 포함됩니다.
특히, 하드웨어 공급업체는 이제 Microsoft Storport 드라이버 기반의 드라이버를 사용해야 하며 SCSI-3 영구 예약을 지원해야 합니다.또한 다중 경로 소프트웨어 장치별 모듈이 사용되면 Microsoft 다중 경로 입출력 표준을 따라야 합니다.
유효성 검사 프로세스가 통합되어 지원 모델이 변경되었습니다.모든 하드웨어에는 Windows Server 2008 로고가 있어야 하며 모든 유효성 검사 테스트를 통과해야 합니다.단, 각 사이트에 하나씩 별도의 두 저장소 영역이 있는 멀티 사이트 클러스터의 경우 및 공유 저장소를 사용하지 않는 Exchange Server 2007 클러스터 연속 복제의 경우는 예외입니다.

새 쿼럼 모델
쿼럼 모델 또한 Windows Server 2008 Failover Clustering에서 변경되었습니다.이전 시스템에서 쿼럼이라는 단어를 들으면 관리자는 클러스터 구성과 복제된 파일이 있는 공유 디스크를 떠올렸습니다.이것이 클러스터의 단일 실패 지점입니다.쿼럼 디스크에 오류가 생기는 경우 클러스터 서비스는 종료되고 고가용성을 잃어버립니다.
Windows Server 2003 서버 클러스터는 주 노드 집합 쿼럼이라는 제2의 쿼럼 유형을 도입했습니다.이 쿼럼 유형은 일반적으로 멀티 사이트 클러스터에서 구현되었으며 공유 저장소가 필요 없습니다.주 노드 집합 쿼럼은 각 클러스터 노드의 시스템 드라이브에 있는 파일 공유로 구성되어 있습니다.이 쿼럼 유형에 연결하려면 서버 메시지 블록(SMB) 연결을 사용했습니다.이 역시 클러스터가 작동하려면 노드의 과반수가 참여하고 있어야 했습니다.
이후 Exchange Server 2007이 도입되면서 클러스터 연속 복제(CCR) 및 파일 공유 감시(FSW) 기능이 Windows Server 2003 서버 클러스터에 추가되었습니다.이 기능 덕분에 FSW 연결이 과반수를 충족하기만 하면 단일 Exchange 2007 CCR 클러스터 노드(또는 임의의 멀티 사이트 클러스터)에서 서비스가 계속 제공될 수 있습니다.
Windows Server 2008 Failover Clustering에서 쿼럼의 개념은 이제 진정한 의미의 합의입니다.이제 클러스터를 서비스하기에 충분한 표를 얻어서 쿼럼 또는 합의에 도달합니다.쿼럼 구성에 따라 충분한 표를 얻는 방법은 여러 가지가 있습니다.그림 4와 같이 Windows Server 2008 장애 조치(failover) 클러스터에는 네 가지 쿼럼 모드가 있습니다.네 가지 중 처음 두 가지 모드(노드 과반수, 노드 및 디스크 과반수)만 클러스터 만들기 프로세스에서 자동으로 선택될 수 있으며다음과 같은 논리가 사용됩니다.
  • 클러스터에서 구성될 노드가 홀수인 경우 노드 과반수 모드를 선택합니다.
  • 클러스터에서 구성될 노드가 짝수이고 공유 저장소가 연결되어 있으며 액세스 가능한 경우 노드 및 디스크 과반수를 선택합니다.
그림 4 클러스터 쿼럼 구성 마법사의 쿼럼 모드(크게 보려면 이미지 클릭)
사용 가능한 저장소에서 감시 디스크를 선택하려면 크기가 500메가바이트 이상이고 NTFS 파티션이 구성된 첫 번째 디스크를 선택합니다.나머지 쿼럼 모드는 클러스터 쿼럼 구성 마법사를 실행하여 수동으로만 선택할 수 있습니다.멀티 사이트 클러스터 구성 또는 Exchange 2007 CCR 클러스터에서는 일반적으로 노드 및 파일 공유 과반수 옵션을 사용합니다.마지막 옵션인 과반수 없음:디스크만 사용 모드는 레거시 클러스터에서의 공유 쿼럼 모델에 해당합니다.이는 단일 실패 지점이며 일반적으로 사용해서는 안 됩니다.
합의 도출을 돕기 위해 구성할 수 있는 감시 리소스는 실제 디스크와 파일 공유, 이 두 가지 유형뿐입니다.
감시 디스크는 클러스터 서비스가 온라인으로 가져올 수 있는 저장소입니다.이 디스크는 클러스터 네트워크 이름과 관련 IP 주소 리소스와 함께 클러스터 핵심 리소스 그룹에 있습니다.감시 디스크가 구성되면 클러스터 폴더가 디스크에 배치되고 클러스터 구성의 전체 내용(클러스터 하이브 또는 복제본)은 디스크에 배치됩니다.
FSW는 네트워크상에서 클러스터에 속하지 않은 서버(이상적인 위치)에 있는 네트워크 공유입니다.SMB가 FSW에 연결되며, FSW는 클러스터 구성에 대한 버전 관리 정보가 들어 있는 감시 로그 파일의 복사본을 유지 관리합니다.
클러스터에는 감시 리소스를 하나만 구성할 수 있습니다.클러스터에서 쿼럼을 충족하기 위해 필요한 경우 이 리소스는 여분의 표를 제공합니다.다시 말해서 클러스터에서 합의를 도출하는 데 한 표, 즉 노드 하나가 부족한 경우 감시 리소스를 온라인으로 가져와서 쿼럼을 충족할 수 있습니다.클러스터가 쿼럼을 충족하는 데 두 표 이상이 부족한 경우 감시 리소스는 그대로 두고 클러스터는 다른 클러스터 노드의 참가를 기다리면서 유휴 상태를 유지합니다.

강화된 보안 기능
장애 조치(failover) 클러스터는 여러 가지 새로운 기능으로 보안을 강화했습니다.가장 괄목할 만한 점은 클러스터 서비스 계정(CSA)에 대한 요구 사항이 제거되었다는 것입니다.이전 버전의 Microsoft 클러스터 서비스에서는 구성 프로세스에서 도메인 사용자 계정이 필요했습니다.클러스터 서비스를 시작하는 데 사용되는 이 계정은 클러스터의 각 노드에 로컬 관리자 그룹으로 추가되어 클러스터 서비스가 올바르게 작동하는 데 필요한 로컬 사용자 권한을 부여 받았습니다.CSA는 도메인 사용자 계정이므로 클러스터 노드에 적용할 수 있는 다수의 도메인 수준 정책을 준수해야 합니다.이러한 정책은 클러스터 서비스 실패를 야기할 수 있어 고가용성을 저해할 수 있습니다.
이제 클러스터 서비스는 로컬 클러스터 노드에서 제대로 작동할 수 있도록 특정 권한을 가진 로컬 시스템 계정으로 실행됩니다.클러스터의 보안 컨텍스트는 클러스터 이름 개체(CNO)로 전환되었으며, 이 개체는 클러스터를 처음 만들 때 Active Directory®의 컴퓨터 컨테이너에 기본적으로 만들어지는 이 컴퓨터 개체입니다.클러스터가 성공적으로 만들어졌으며 Active Directory에 CNO가 있으면 클러스터 설치 및 구성에 사용한 사용자 계정은 더 이상 필요가 없습니다.
Active Directory의 컴퓨터 컨테이너에 만드는 추가 컴퓨터 개체는 장애 조치(failover) 클러스터와 연관되어 있습니다.가상 컴퓨터 개체(VCO)라고 하는 이 개체는 클러스터의 클라이언트 액세스 지점(CAP)의 일부로 만들어진 클러스터 네트워크 이름 리소스와 동등합니다.클러스터의 모든 VCO 만들기를 담당하는 CNO는 Active Directory에 있는 개체에 대한 시스템 액세스 제어 목록(SACL)에 추가됩니다(그림 5 참조).
그림 5 Active Directory의 VCO에 대한 보안(크게 보려면 이미지 클릭)
CNO는 또한 자신이 만든 모든 VCO의 도메인 암호를 동기화하는 역할도 합니다.이 프로세스는 암호 교체에 대해 구성된 도메인 정책에 따라 이루어집니다.또한 CNO는 클러스터에 있는 VCO와 관련된 모든 컴퓨터 개체를 만드는 일을 담당하므로 CNO(컴퓨터 계정)는 VCO가 만들어지는 컨테이너(기본적으로 컴퓨터 컨테이너)에서 컴퓨터 개체를 만들 수 있는 도메인 수준 권한을 가져야 합니다.
이제 기본 인증 방법으로 Kerberos를 사용하도록 변경되었습니다.Active Directory에 컴퓨터 계정이 있으므로 이러한 강화된 보안 기능이 가능합니다.그러나 Kerberos를 인증에 사용할 수 없는 응용 프로그램에서 클러스터 리소스에 액세스해야 하는 경우 클러스터에서는 NTLM(NT LAN Manager) 인증을 사용할 수 있습니다.
클러스터 프로세스를 직접 처리하는 클러스터 노드 간의 통신도 보안이 강화되었습니다.기본적으로 클러스터 내 모든 통신에 서명이 사용됩니다.cluster.exe 공용 언어 인터페이스(CLI)를 사용하면 모든 노드 간 통신을 암호화하여 추가 보안 수준을 제공하도록 이 클러스터 속성을 변경할 수 있습니다.

확장된 네트워킹 기능
장애 조치(failover) 클러스터의 새 네트워킹 기능은 고가용성 및 재해 복구 솔루션을 설계할 때 더 나은 유연성을 제공합니다.동시에 향상된 네트워킹은 클러스터의 노드 간 연결을 더 안정적으로 만듭니다.
분리된 네트워크에 있는 클러스터 노드의 위치를 파악하는 기능은 고객들이 가장 많이 요청했던 기능입니다.이제 이러한 기능이 가능합니다.각 노드가 개별적으로 라우팅되는 둘 이상의 분리된 네트워크에 연결된 경우 클러스터 노드 간에 매우 안정적이며 내결함성 있는 통신을 제공하도록 클러스터 네트워크 드라이버를 완전히 다시 작성했습니다.
클러스터 네트워크 드라이버는 클러스터 시작 프로세스 중에 제공된 연결 정보를 바탕으로 자체 내부 라우팅 테이블을 만듭니다.이 테이블에는 로컬 연결 정보와 클러스터 구성 데이터베이스(클러스터 레지스트리 하이브)에서 제공되는 정보가 포함됩니다.
클러스터 유효성 검사 프로세스의 일부에는 네트워크 연결 검색 프로세스가 포함되어 있습니다.라우팅된 다른 네크워크에서 클러스터 노드의 위치를 알 수 있어서 멀티 사이트 클러스터의 네트워킹 요구 사항이 완화되었기 때문에조직에서 더 저렴한 비용으로 손쉽게 배포할 수 있습니다.또한 iSCSI 저장소는 장애 조치(failover) 클러스터에서 사용하기에 더욱 좋은 저장소 솔루션이 되었습니다.
또한, 클러스터 노드는 DHCP(Dynamic Host Configuration Protocol)를 통해 IP 주소 정보를 얻을 수 있습니다.각자의 환경에서 서버에 대해 동적 주소 할당을 사용하도록 허용할 수 있는 경우 네트워크 관리자의 부담을 줄일 수 있습니다.
클러스터 노드의 네트워크 인터페이스 구성에 따라 어느 네트워크에서 정적 IP 주소나 동적 IP 주소를 사용할지 결정됩니다.클러스터의 IP 주소 리소스를 DHCP 서버에서 구한 경우에도 장애 조치(failover) 클러스터 관리 스냅인에서 정적 IP 주소로 변경할 수 있습니다.
이전에는 모든 클러스터 통신이 UDP(User Datagram Protocol) 브로드캐스트를 사용했고 가끔 멀티캐스트도 사용했습니다.멀티캐스트 기능은 더 이상 사용되지 않으며 이제 클러스터 통신은 UDP 유니캐스트를 사용합니다.단, 포트 3343은 공통 포트로 여전히 Microsoft 클러스터에서 사용됩니다.많은 네트워크 관리자는 더 이상 브로드캐스트가 사용되지 않는 것을 반길 것입니다.그러나 클러스터에서 정말 큰 혜택은 클러스터 서비스 내부의 새 메시징 프로세스와 관련이 있습니다.하지만 이것은 이 글의 범위를 벗어나므로 다루지 않겠습니다.이제 클러스터 내 통신은 UDP를 전송 메커니즘으로 사용하기는 하지만 더욱 안정적인 TCP 통신의 특성을 갖습니다.

저장소와의 상호 작용에서 향상된 안정성
장애 조치(failover) 클러스터가 저장소와 상호 작용하는 방식이 크게 달라졌습니다.클러스터 디스크 드라이버(clusdisk.sys)가 완전히 다시 작성되어 이제 진정한 플러그 앤 플레이(PnP) 드라이버라고 할 수 있습니다.또한, 드라이버가 저장소와 상호 작용하는 방식도 바뀌었습니다.
Windows Server 2003에서 클러스터 디스크 드라이버는 저장소로 연결되는 직접 경로에 있었습니다.Windows Server 2008에서는 클러스터 디스크 드라이버가 저장소와 상호 작용하기 위해 파티션 관리자(partmgr.sys) 드라이버와 통신합니다.이러한 두 가지 접근 방식을 그림 6에서 볼 수 있습니다.
그림 6 Windows Server 2008에서 변경된 저장소 스택(크게 보려면 이미지 클릭)
파티션 관리자는 클러스터 디스크 리소스를 보호하는 일을 주로 담당합니다.공유 저장소 버스에 연결된 모든 디스크는 처음 클러스터 노드에 매핑될 때 자동으로 오프라인 상태가 됩니다.이에 따라 클러스터가 만들어지기 전이라도 저장소가 클러스터의 모든 노드에 동시에 매핑될 수 있습니다.이제 노드를 한 번에 하나씩 부팅할 필요가 없고, 노드에 디스크가 준비되면 그 노드를 종료하고 다른 노드를 부팅할 필요도 없으며, 디스크 구성을 확인하지 않아도 됩니다.
하지만 저장소 테스트는 여전히 클러스터 유효성 검사 프로세스의 일부로 수행해야 하며 디스크 초기화도 필요합니다.이런 작업을 유효성 검사 프로세스 실행 전에 클러스터의 노드에서 수행할 수 있습니다.저장소가 클러스터에 추가되고 나면 디스크 관리 인터페이스에 디스크가 예약 상태로 표시되며 보호 해제 상태로 되지 않습니다.
다른 변경 내용은 SCSI 명령과 관계가 있습니다.Windows Server 2003에서는 클러스터 디스크 드라이버에서 디스크 섹터에 쓸 때 SCSI-2 예약/해제 명령을 사용했습니다.Windows Server 2008에서는 SCSI-3 영구 예약(PR) 명령이 필요합니다.클러스터 노드가 저장소에 예약을 배치하려면 먼저 등록을 해야 하며, 클러스터 노드는 등록 보호 프로토콜을 사용하여 주기적으로 예약을 보호합니다.
이 기능은 유효성 검사 프로세스의 저장소 테스트의 일부로 확인됩니다.따라서 저장소 솔루션이 SCSI-3 PR 명령을 지원하지 않는 경우 장애 조치(failover) 클러스터에서 지원되지 않습니다.
많은 조직에서 저장소 연결 시 중복 확인을 위해 다중 경로 소프트웨어를 사용하고 있으며,이는 지원될 뿐만 아니라 모범 사례로 권장되는 사항입니다.그러나 타사의 다중 경로 소프트웨어 솔루션 또는 장치별 모듈이 장애 조치(failover) 클러스터에서 지원되려면 Microsoft 다중 경로 입출력 표준에 따라 다시 작성되어야 합니다.이렇게 하면 경로 활성화 여부에 관계없이 모든 SCSI-3 PR 명령이 모든 경로를 통해 동시에 저장소로 전송됩니다.이 기능 역시 유효성 검사 프로세스의 일부로 확인됩니다.
저장소 개선 사항은 이외에도 강화된 디스크 검사(chkdsk.exe) 프로세스, 기본 제공 디스크 복구 기능(이전에는 클러스터 서버 복구 유틸리티의 일부), 자동 복구 디스크 등이 있습니다.장애 조치(failover) 클러스터에서는 클러스터 디스크 리소스를 식별할 때 디스크 서명과 LUN ID를 모두 사용합니다.둘 중 하나라도 변경되면 클러스터 구성이 업데이트됩니다.이런 기능 덕분에 실제 디스크 리소스의 단순한 특성 변경으로 인한 오류가 줄어들고 결과적으로 고가용성이 향상됩니다.

기본 제공 복구 프로세스
위에서 언급한 디스크 복구는 기본 제공 복구 기능 중 하나입니다.다른 기능으로 Active Directory 복구 기능이 있습니다.CNO를 나타내는 컴퓨터 개체가 삭제된 경우 클러스터 CAP와 관련된 컴퓨터 개체를 더 이상 만들 수 없게 됩니다.하지만 처음 접하게 되는 문제는 보안 토큰을 구할 수 없어서 고가용성 응용 프로그램 또는 사용자가 클러스터 외부 리소스에 액세스할 수 없는 일일 것입니다.
삭제된 CNO 복구는 두 단계로 이루어진 프로세스입니다.우선 도메인 관리자가 DeletedObjects 컨테이너에서 삭제된 컴퓨터 개체를 Active Directory에 복구합니다.그런 다음 개체가 복원되고 다시 활성화되고 나면 장애 조치(failover) 클러스터 관리 스냅인에서 Active Directory 개체 복구 프로세스를 실행합니다.
Windows Server 2003 서버 클러스터에서는 %systemroot%\cluster 하위 디렉터리에 있는 클러스터 구성 파일이 손상되어 교체해야 하는 경우가 있을 수 있습니다.장애 조치(failover) 클러스터에서는 자동 복구 기능이 도움이 됩니다.노드에서 클러스터 서비스를 시작할 때 구성 데이터베이스가 손상된 경우 HKLM\System\CCS\Services\ClusSvc\Parameters 레지스트리 키에 포함된 정보를 사용하여 최소 구성 템플릿이 로드됩니다.노드는 이미 구성된 클러스터에 참가를 시도하며 성공하는 경우 클러스터 레지스트리 하이브의 새 복사본을 노드에 넣습니다.노드가 클러스터에 참가할 수 없는 경우 클러스터 서비스는 종료됩니다.

새 백업 및 복원 기능
장애 조치(failover) 클러스터링에는 자체 볼륨 섀도 복사본 서비스 기록기가 있습니다.이것이 클러스터 데이터베이스와 실제 디스크 리소스에 있는 데이터를 백업하고 복원하는 데 중요한 역할을 합니다.클러스터 구성을 백업하는 작업은 매우 간단합니다.시스템 상태가 백업의 일부인 경우 클러스터 구성을 복원할 수 있습니다.그러나 클러스터에 쿼럼이 있는 경우에만 클러스터를 백업해야 합니다.이렇게 하면 가장 최신의 클러스터 구성이 백업됩니다.
클러스터 복원에는정식 복원과 권한 없는 복원의 두 가지 유형이 있습니다.권한 없는 복원은 Windows Server 백업 또는 타사 백업 응용 프로그램을 사용하여 선택한 백업에서 복원을 실행합니다.반면 클러스터 노드의 정식 복원은 Windows Server 백업 CLI(wbadmin.exe)만을 사용하여 수행할 수 있습니다.
정식 복원은 기본적으로 클러스터 구성을 백업이 수행된 "과거 시점으로" 돌려 놓습니다.정식 복원을 수행하려면 복원을 수행할 노드를 제외한 모든 노드에서 클러스터 서비스를 중지합니다.복원이 완료되고 복원된 노드에서 클러스터 서비스가 시작되면 클러스터의 복원된 구성은 새 클러스터 구성으로 결정됩니다.그런 다음 클러스터의 나머지 노드에서 클러스터 서비스가 다시 시작되면 복원된 구성이 참가 프로세스 중에 적용됩니다.
복원 기능을 사용하면 특정 시나리오에서 많은 시간과 비용을 절약할 수 있습니다. 예를 들어, 하나 당 프린터 1,500대를 지원하는 인쇄 스풀러 리소스를 여러 개 호스팅하는 인쇄 클러스터에서 인쇄 스풀러 리소스 중 하나를 실수로 삭제했다고 가정해 보겠습니다.이제 다수의 사용자가 인쇄를 할 수 없게 되었습니다.삭제된 모든 프린터를 수동으로 클러스터 구성에 추가하는 것보다 클러스터 구성에서 정식 복원을 수행하면 훨씬 빠릅니다.물론 이것은 완전한 백업 및 복원 전략이 마련되어 있는지 여부에 따라 달라집니다.

Windows Server 2003 서버 클러스터에서 마이그레이션
Windows Server 2008 Failover Clustering의 이러한 모든 아키텍처 변경으로 인해 Windows Server 2003에서의 사용 중 업그레이드 또는 롤링 업그레이드가 지원되지 않습니다.Windows Server 2000 클러스터에서 Windows Server 2003으로 업그레이드할 때 많은 조직에서 시스템을 통해 클러스터에서 각 노드를 제거하고 운영 체제를 완전히 새로 설치한 다음 노드를 다시 클러스터에 추가했습니다.Windows Server 2003과 Windows Server 2008의 클러스터 노드는 동일한 클러스터의 일부가 될 수 없으므로 이런 접근 방식은 Windows Server 2008로 마이그레이션하는 데 사용할 수 없습니다.
다행히 마이그레이션을 돕기 위한 마법사 기반의 마이그레이션 프로세스가 포함되어 있습니다.하지만 그렇더라도 Windows Server 2008 장애 조치(failover) 클러스터로 마이그레이션하려면 계획이 필요합니다.다음과 같은 세 가지 마이그레이션 시나리오가 있습니다.
  • 동일한 서버와 저장소 사용
  • 동일한 서버와 새 저장소 사용
  • 새 서버와 새 저장소 사용
이러한 시나리오 모두에서 하드웨어가 Windows Server 2008 로고 프로그램 인증을 받았는지, 장애 조치(failover) 클러스터 유효성 검사 프로세스를 실행하여 모든 테스트를 통과했는지 확인이 필요합니다.이 단계를 완료하면 다음 마이그레이션 단계로 넘어갈 수 있습니다.
Windows Server 2003 서버 클러스터의 리소스 중 일부는 마이그레이션할 수 없습니다.네트워크 이름, IP 주소, 물리적 디스크, 파일 공유, DFS(분산 파일 시스템) 루트, DHCP 및 WINS를 마이그레이션할 수 있습니다.또한 일반 서비스, 일반 응용 프로그램, 일반 스크립트 리소스를 제한된 범위에서 마이그레이션할 수 있습니다.
한편, Microsoft Exchange 및 SQL Server®와 같은 응용 프로그램은 장애 조치(failover) 클러스터로 마이그레이션하는 자체 절차가 있습니다.프린터는 인쇄 관리 스냅인(인쇄 서버 역할과 함께 설치됨)을 사용하여 먼저 프린터를 내보낸 다음 새롭게 구성된 고가용성 프린터 서버로 가져오기를 수행하여 Windows Server 2008로 마이그레이션할 수 있습니다.타사 리소스 유형은 마이그레이션할 수 없습니다.
마이그레이션 프로세스는 데이터를 마이그레이션하지 않으며클러스터 구성 설정을 Windows Server 2003에서 Windows Server 2008로 마이그레이션하는 일에만 관여합니다.
마이그레이션 프로세스가 완료되면 마이그레이션된 모든 리소스는 처음에 오프라인 상태가 됩니다.추가로 필요한 단계가 있을지 모르기 때문입니다.그러므로 클러스터에서 서비스로 가져오기 전에 마이그레이션 후 보고서를 검토하여 어떤 추가 단계가 필요한지(새 저장소로 마이그레이션한 경우의 데이터 마이그레이션 제외) 확인해야 합니다.예를 들어, DHCP 서버를 마이그레이션하는 경우 DHCP 서버 역할을 클러스터의 모든 노드에 설치해야 합니다.WINS 서버를 마이그레이션하는 경우에는 WINS 서버 기능을 클러스터의 모든 노드에 설치해야 합니다.

Chuck Timon은 클러스터 및 설치 기술을 지원하는 Microsoft 지원 향상 엔지니어로서 Windows Server 2008 장애 조치(failover) 클러스터 교육 자료를 저술한 바 있으며 현재 Hyper-V 교육 자료를 집필 중입니다.


From the Editor 인쇄의 시대는 갔다
Joshua Hoffman

인쇄의 시대는 끝난 것 같습니다. 많은 독자 여러분께서도 같은 생각을 하실 것입니다.무수하게 쏟아지는 근사한 장치에서 언제 어디서나 온갖 형태의 정보를 접할 수 있는 무차별적 정보화 시대 속에서 아교로 붙여 만든 종이 뭉치를 누가 필요로 하겠습니까?이제 그런 시대는 가버린 것일까요?잡지와 신문은 박물관 전시장의 유물로 남아, 그 옛날 "우리가 잉크 묻은 나무 펄프 뭉치를 들고 다니곤 했었지"라고 향수에 잠겨 이야기하는 그런 날이 오게 되는 걸까요?
너무 감상적인가요?네, 인정합니다.하지만 독자 여러분께서는 제가 이러한 가정에 전혀 동의하지 않는다는 사실을 눈치 채셨으리라 생각합니다. 단순히 제 직업의 안전을 위해 드리는 말씀이 아닙니다. Microsoft에는 아직도 제가 할 수 있는 많은 일들이 있답니다.인쇄된 글은 형태는 비록 간소하지만 놀라울 정도로 깊고 풍부한 지식을 제공합니다. 이는 어쩌면 오히려 그 간소함에 기인하는 것인지도 모르지요.자리에 앉아 장문의 기사를 읽다 보면 컴퓨터 화면이 아니라 인쇄물을 직접 손에 들고 읽었으면 하는 생각을 매번 하곤 합니다.제게 있어서는 그게 훨씬 친근한 일이거든요.너무 구시대적인 생각인가요?그럴지도 모릅니다. 하지만 최근의 독자 설문 조사에 따르면 90%에 달하는 독자 여러분께서도 저와 같은 생각을 갖고 계십니다.
그러나 이제는 고전적인 방법만을 고집해서는 안되겠지요.저는 누구보다 최신 기술에 관심이 많고 이에 몰두하는 사람입니다.하지만 TechNet Magazine과 같은 발행 작업은 총체적인 경험이 될 수 있으며 또 그래야만 합니다. 온라인, 오프라인 및 직접 전달 방식 등 여러 형태로 이루어질 수 있는 작업이기 때문입니다.만약 제가 Mark Russinovich의 길고도 전문적인 기사를 읽는다면 당연히 인쇄해서 읽고 싶을 겁니다.그러나 이와 동시에 Mark의 강의를 들으면서 기사에 설명하는 기술을 시연하는 데모를 시청하고 싶기도 합니다.
이러한 생각은 곧 TechNet Magazine을 이끄는 원칙이 되었습니다.저희는 매달 매거진을 발행한다는 것에 자긍심을 갖고 있기도 하지만 지금까지 인쇄물로 발행한 모든 콘텐츠는 인터넷에서도 제공됩니다.또한 조만간 고유의 플랫폼을 활용하여 인터넷에서 보다 다양한 콘텐츠를 제공할 예정입니다.예를 들어 지난호에는 Don Jones의 Windows PowerShell 컬럼과 함께 하는 스크린캐스트 시리즈가 시작되었습니다.이제부터는 Don의 비디오를 시청하면서 이달의 컬럼 주제를 설명하는 내용을 보실 수 있습니다.아울러 본 웹 사이트에서는 지속 가능한 컴퓨팅에 대한 새로운 컬럼도 업데이트되었습니다. 이 컬럼에서는 IT 산업이 환경에 미치는 영향을 검토하고, IT 전문가들이 글로벌 시민으로서의 책임감을 갖고 수행할 수 있는 자구책에 대해서도 논의하고 있습니다.
독자 여러분의 의견은 언제나 TechNet Magazine을 풍부한 미디어 환경의 초석이 되게 하는 소중한 밑거름이 됩니다.의견이 있으시면 tnmag@microsoft.com으로 연락 주시기 바랍니다.
—Joshua Hoffman

도움을 주신 Microsoft 기술 전문가: Ed Banti, Avronil Bhattacharjee, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Elden Christensen, Trina Gorman, Scott Landry, Michael Murgolo, Sanjeev Nair, Hugh Pyle, Amritansh Raghav, Jez Sadler, Jim Truher


Letters 독자의 목소리

Active Directory 도메인 서비스
지난 TechNet Magazine 2008년 3월호를 아주 재미있게 보았습니다.적어도 12번은 읽은 것 같더군요.특히 Gil Kirkpatrick의 "Active Directory 도메인 서비스의 새로운 기능" 기사를 흥미롭게 읽었습니다.이 기사에서 저자가 Microsoft® Audit Collection Services라는 제품을 언급했는데요,이 제품은 현재 사용할 수 있는지, 독립 실행형 응용 프로그램으로 작동하는지 궁금합니다.
— Erasmo M.

Microsoft Audit Collection Services(ACS)는 이전에 Microsoft Operations Manager(MOM)라고 불리던 관리 소프트웨어인 System Center Operations Manager(SCOM)에 포함되어 있습니다.이 제품은 독립 실행형 제품으로 사용할 수 없으며 SCOM의 일부로만 사용 가능합니다.
— Gil Kirkpatrick, NetPro CTO 및 TechNet Magazine 저자

서명
지난 2008년 4월호 TechNet Magazine에 수록된 Windows PowerShell 칼럼("여기 서명해 주세요", technet.microsoft.com/magazine/cc434702)의 두 번째 단락에서 저자 Don Jones는 "서명이라는 단어는 여기서 다루려는 내용에 알맞은 기술 용어이지만 그 자체로는 실제 기능을 제대로 나타내지 못합니다.스크립트에 서명한다고 해서 계약서 또는 신용 카드 전표의 경우처럼 스크립트를 승인하거나 인증하는 것은 아니기 때문입니다."라고 했습니다.
그러나 제 생각으로는 계약서나 신용 카드 전표에 서명하는 것도 반드시 해당 항목을 승인하거나 인증하는 것은 아닌 것 같습니다.이러한 서명 행위는 그 당시 상황의 전후 관계가 폭넓게 반영된 경우에만 그 의미를 갖습니다.예를 들어 제가 어렸을 때 아버지의 주유소에서 신용 카드 전표를 갖고 놀았던 적이 있는데 아무도 제가 실수로 저지른 거래에 대해 청구하지는 않았던 것과 마찬가지로 말입니다.
"올바르게 구성된" Active Directory® 네트워크 구현의 의미에서 보자면 서명이란 스크립트가 작동하도록 승인하는 것입니다.서명이라는 것은 서명자가 서명한 사항에 대해 책임을 진다는 의미를 나타내며, 서명이 있다는 것으로 인해 추가적인 작업이 발생할 수 있습니다. 예를 들어 신용 카드 회사에서 대금을 청구하거나 네트워크에서 코드가 인증된 것으로 승인할 수 있습니다.
계속해서 좋은 내용을 실어 주시기 바랍니다. TechNet Magazine은 매우 유용한 잡지입니다.
— Jeremy P.

의견을 보내 주셔서 감사합니다.TechNet Magazine에 이처럼 깊은 관심을 가져 주시고 중요한 점을 세부적으로 지적해 주신 독자 여러분께 감사드립니다.

SharePoint Services
Microsoft Office SharePoint Server가 아닌 Windows® SharePoint® Services(WSS)를 실행할 때 웹 사이트 인터페이스/URL을 통해 액세스하려면 추가 CAL 라이선스가 필요한가요?
— Douglas M.

이 주제와 관련하여 참조할 수 있는 몇 가지 문서가 있습니다.다음 링크를 참조하시기 바랍니다.msmvps.com/blogs/cgross/archive/2005/04/02/40723, microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx 및 windowsserver/sharepoint/bb684457
— Pav Cherny, Inside SharePoint 칼럼니스트, TechNet Magazine

Inside SharePoint 의견
최근 2008년 5월호 TechNet Magazine에서 SharePoint 칼럼(technet.microsoft.com/magazine/cc462809)을 읽었습니다.독자들에게 주제 추천을 받는다고 하셨는데요,제 생각에는 Project/Project Server와 SharePoint 통합에 대한 특집 기사가 나오면 좋을 것 같네요.
— Phil H.

Project/Project Server와의 통합이라는 매우 좋은 주제를 알려 주셨네요.이 주제에 대해서는 이후의 칼럼에서 반드시 다루도록 하겠습니다.의견을 주셔서 감사합니다.

Inside SharePoint 관련 기타 의견
웹에서 표준 SharePoint UI 또는 SharePoint Designer를 사용한 사이트 사용자 지정에 대한 문서는 많이 찾아볼 수 있지만, 사이트 정의에 대한 문서는 적은 것 같습니다. 그리고 관련 기사가 있더라도 너무 기본적인 내용만 다루고 있어 실제 발생하는 문제를 해결하는 데 활용하기에는 무리가 있습니다.사이트 정의는 많은 사람들이 관심을 갖기 시작한 분야이지만 대다수의 방법 문서에서는 SharePoint를 도입하는 방법에 대해서만 도움을 얻을 수 있습니다.특히 저희 회사에서는 아래와 같은 문제를 해결하는 데 고심하고 있습니다.
  1. 사이트 정의 내에 나열되도록 사용자 지정 권한 설정
  2. 사이트 정의 내의 사용자 지정 목록 항목 양식
  3. 사이트 정의 내에서 웹 파트 연결
  4. 사이트 정의를 점진적으로 배포하는 방법
— Adam C.

의견을 주셔서 감사합니다.이러한 의견이야말로 TechNet Magazine에 수록할 내용을 구상할 때 큰 도움이 됩니다.


Toolbox IT 전문가를 위한 신제품
Greg Steen

관리 작업 자동화
Automise 2
automise.com/automise.aspx
아무 생각 없이 반복하는 작업은 힘들고 지루하며 실수하기 쉽습니다.이런 반복적인 작업을 자동화하는 일은 성공적인 관리를 위한 핵심으로서, 업무에 대한 만족감도 높일 수 있습니다.작업을 자동화하는 단순한 배치 파일이나 사용자 지정 VBScript 외에도, 매크로와 비슷한 수많은 Windows®용 유틸리티와 사용자 지정 스크립트 언어를 배워야만 사용할 수 있는 유틸리티도 있습니다.하지만 여기에는 다른 방법도 있습니다.VSoft Technologies의 Automise 2를 사용하면 스타일 GUI를 끌어서 놓기 방식으로 사용자 지정하여 자동화 루틴을 생성할 수 있습니다.
이 응용 프로그램은 인터페이스가 마치 간단한 프로그래밍 IDE처럼 보이며 제공하는 옵션 또한 비슷합니다.항목을 디자이너 화면으로 끌어 놓을 수 있는 도구 상자와 코드를 단계별로 실행할 수 있는 디버깅 컨트롤, 다수의 프로젝트를 볼 수 있는 뷰, 출력 실행 로그, 기록 및 속성 창 등이 제공됩니다.그러나 Automise에서 자동화된 작업의 워크플로를 실제로 시각적으로 나타내는 것은 "코드"입니다.
Automise의 도구 상자는 각각 자동화 프로세스의 한 단계를 수행하는 작업들로 구성되어 있습니다..zip 파일 만들기부터 IIS 다시 시작에 이르기까지, 가능한 모든 작업 범위를 아우르는 380개의 작업이 제공됩니다.
작업을 설계할 때 주기적으로 실행하는 다수의 관리 프로세스를 처리할 수 있도록 이러한 작업을 계층적으로 구조화할 수 있습니다.또한, try/catch 블록, 예외 발생, if-then-else 문, 루프, 전환, 지연, 비동기 작업 그룹 등의 흐름 제어 작업을 사용하여 이러한 작업들을 연결할 수도 있습니다.
각각의 자동화 프로젝트에는 다른 프로젝트를 포함할 수 있어서 제어의 주 흐름을 그 하위 작업과 분리할 수 있습니다.문자열과 XML 데이터를 조작하고 변수를 설정하며 프로세스 및 명령에 대기하는 등, 다른 작업도 다수 있습니다.이 모든 제어 흐름 관련 옵션을 이용하면 복잡한 작업도 자동화할 수 있습니다.
Automise를 사용하면 예정된 작업을 생성하고, 실행하며, 편집하고 삭제할 수 있습니다.다시 말해서, 기존 프로세스도 Automise를 사용하여 관리할 수 있습니다.가능한 작업을 여기 모두 나열할 수는 없지만 몇 가지 주목할 만한 작업으로GAC(전역 어셈블리 캐시)에 DLL 등록, SQL Server® 인덱스 다시 작성, chkdsk 실행, 레지스트리 편집, 이벤트 로그 백업, Active Directory® 사용자 편집, 볼륨 탑재, 복원 지점 생성 및 가상 디렉터리 생성 등을 들 수 있습니다.Automise는 기본 제공 작업만으로 부족한 경우에 사용할 수 있도록 사용자 지정 스크립트, 명령 및 임시 SQL 실행 작업도 제공합니다.
무엇보다 가장 큰 장점은 원하는 대로 손쉽게 사용할 수 있는 도구라는 점입니다.네트워크 인프라 자동화가 아닌, 단순히 개인 Windows 워크스테이션의 자동화 방법을 찾고 있다면 많은 기능을 제거하고 개인이 고급 사용자로서 필요로 하는 요구를 처리할 수 있도록 구성된 Automise Lite를 사용할 수 있습니다.
가격: 단일 사용자 사용권의 경우 195달러부터입니다(직판가).
Automise 2를 이용한 작업의 시각적 자동화(크게 보려면 이미지 클릭)

실시간 로그 모니터링
BareTailPro
baremetalsoft.com/baretailpro
어디에서나 로그 파일이 넘쳐나고 있습니다.하지만 이러한 로그 파일을 사용하는 일은 쉽지 않습니다.응용 프로그램에서 트랜잭션 로그가 기록되는 것 자체는 좋지만로그 집계 도구를 사용하는 방법 외에, 실시간으로 기록되고 있는 내용을 실제로 볼 수 있는 방법이 있을까요?Bare Metal Software에서 개발한 BareTailPro가 그 해답입니다.이 단순한 유틸리티는 2006년 이후로 업데이트되지 않았지만 여전히 이전의 콘솔 *nix 명령인 'tail -f'와 유사한 향상된 Windows 유틸리티로 사용되고 있습니다.
단순한 GUI를 통해 파일 크기에 관계없이 여러 개의 로그 파일을 동시에 볼 수 있으며 이 파일에 기록되는 내용을 그대로 지켜볼 수 있습니다.파일 간에 전환하려면 탭을 클릭하면 됩니다.또한 매우 유용한 기능으로서 각 탭에 로그 파일별 상태를 나타내는 아이콘이 표시되며, 이는 파일에 쓰고 있는 중인지 아니면 "마지막 기록"이 중지되었는지를 보여 줍니다.
대부분의 응용 프로그램이 로그를 기록하지만, 일반적으로 기록 방식은 상당히 다릅니다.BareTailPro에서는 Unicode, UTF-8, ANSI 및 ASCII 파일을 읽을 수 있고 줄이 CR/LF 쌍, 단일 LF 및 null로 끝나는 경우도 처리할 수 있습니다.줄 바꿈과 탭 확장을 손쉽게 구성하여 특정 유형의 로그 파일을 가장 보기 쉬운 상태로 표시할 수 있습니다.그 외에도, 로그 파일의 가독성을 향상시키기 위해 글꼴 크기, 종류, 간격 및 줄 높이 등을 구성할 수 있습니다.
또 다른 휼륭한 기능으로서 이 응용 프로그램에서 로그 뷰에 적용할 강조 표시를 구성할 수 있습니다.텍스트 문자열을 기반으로 전경/배경 색 지정 규칙을 원하는 수만큼 설정할 수 있습니다.예를 들어 오류는 빨간색, 경고는 노란색으로 표시하거나 특정 IP 주소 또는 호스트 참조가 있는 줄을 모두 강조 표시하도록 선택할 수 있습니다.행에 굵게 또는 기울임꼴을 지정할 수 있으며 텍스트 문자열의 대소문자를 무시하도록 선택할 수도 있습니다.
하지만 이러한 텍스트 강조 표시 기능에도 불구하고 로그 파일은 엄청난 로그 양으로 인해 로그 추적 뷰를 가득 채워서 찾으려는 이벤트의 위치를 파악하기 어려운 경우가 있습니다.BareTailPro에는 이럴 때 유용한 기능이 있습니다.정규식과 텍스트 검색 기능을 사용하면 신속하게 로그 뷰를 정리하여 대상 행 인스턴스를 관리 가능한 하위 집합으로 분리할 수 있습니다.BareTailPro에서 사용되는 정규식 구문은 Java, Perl 및 PHP에 사용되는 표준 표기법의 하위 집합으로 구성됩니다.이러한 구문 사용법에 익숙하지 않은 사용자를 위해 제품 웹 사이트에서 빠른 참조를 제공합니다.
이 유틸리티는 필터 결과를 표 형식으로 표시하며, 타임스탬프, 줄 번호 및 줄 원본과 함께 정의한 경우 해당 캡처 그룹의 결과 등 몇 가지 유용한 열이 추가되어 있습니다.필터링된 보기에서 이러한 열을 정렬할 수도 있습니다.
필자의 경우 원하는 결과를 정확히 보여 준 "환상의" 정규식 구문은 없었던 것으로 기억합니다.그래서 이 도구의 패턴 저장 기능이 더욱 고맙게 느껴집니다.이 기능을 사용하면 다시 사용할 수 있도록 패턴의 이름을 지정하고, 편집 및 저장할 수 있습니다.필터링된 보기에서 중요한 행을 발견하면, 각 결과 열에 대한 너비, 맞춤, 접두사 및 접미사 등 형식을 원하는 대로 지정하여 파일이나 클립보드로 내보낼 수 있습니다.
놀라운 점은 이 아담한 유틸리티가 작은 실행 파일 하나에 들어 있어서 이식성이 뛰어나고 사용자의 환경에 미치는 영향이 적다는 것입니다.로그 파일을 검토해야 하며 여기에 정규식 필터링이나 검색 패턴 저장, 검색 및 필터링 결과 내보내기와 같은 기능이 필요하지 않다면, BareTail이라는 무료 버전을 사용하여 로그 파일을 감시할 수 있습니다.
가격: 개별 사용권의 경우 35달러부터입니다.
BareTailPro를 이용한 네트워크 모니터링(크게 보려면 이미지 클릭)

시스템 자산 관리
Total Network Inventory
softinventive.com
사용하는 환경 전체에서 시스템에 대한 자세한 정보에 빠르게 액세스하는 것은 성공적인 시스템 관리의 핵심이 되는 부분입니다.이러한 정보를 스프레드시트로 공급업체 목록을 만들어 작성하면 추적이 어렵고, 완벽하게 유지하기 힘들며, 최신 내용을 적절히 업데이트하지 못하기 마련입니다.
누가 무엇을 설치했는지, 어떤 하드웨어를 실행 중인지에 대한 정보를 수집하여 "원하는 대로" 보여 주는 동적 도구를 사용하면 크게 도움이 될 수 있습니다.이러한 도구는 사용자가 기본적으로 세팅된 시스템에 가외로 사용하는 제품에 대한 목록을 작성할 수 있는 좋은 수단입니다.(그룹 정책에서 설치 권한이 제한되지 않거나, 특정 소프트웨어 패키지에 대해 설치 기준을 기반으로 필요한 사용권 수를 빠르게 확인할 수 없는 경우)이러한 요구에 맞는 도구로 Softinventive Lab의 Total Network Inventory를 소개합니다.
Total Network Inventory를 설치하고 나면 검사 마법사를 통해 재고 자산 관리 프로세스를 시작할 수 있습니다. 이 마법사는 네트워크의 노드 검색 과정을 안내합니다.지정된 IP 주소 범위 또는 네트워크 위치 컴퓨터 검색을 통해 바로 검색을 실행하거나, 도메인의 시스템 로그 정보를 수집할 수 있는 로그온 스크립트 검색 기능을 사용할 수 있습니다.
Total Network Inventory는 WMI(Windows Management Instrumentation)(IPC$\ADMIN$ 또는 RPC/DCOM)과 전형적인 로컬 계정 공유 방식에 의존하여 검색을 수행합니다.따라서, 관리자 계정 컨텍스트에서 실행해야 합니다.
검색이 완료되면 시스템 전체에서 또는 특정 컴퓨터를 검색하여 그 자산 목록을 작성할 수 있습니다.Total Network Inventory는 수집한 재고 자산 정보를하드웨어, 소프트웨어 및 기타 정보의 세 가지 그룹으로 구분합니다.하드웨어 부분에는 프로세서, 마더보드 및 칩셋, 메모리, 비디오 하위 시스템, 저장소(물리적 장치 및 논리적 장치), 네트워크 어댑터 유형 및 구성, 주변 장치, 시스템에 설치된 기타 장치에 대한 세부 정보가 포함됩니다.
소프트웨어 부분에서는 제품 키, 일련 번호, 시스템 디렉터리 및 설치된 서비스 팩을 비롯한 OS 정보가 제공됩니다.여기에는 핫픽스(기술 자료 문서 번호 포함)와 설치할 수 있는 모든 바이러스 백신 응용 프로그램 및 데이터베이스 응용 프로그램에 대한 세부 정보가 포함됩니다.또한, 설치된 모든 프로그램에 대한 목록(Program Files 디렉터리 뷰가 함께 제공되므로 기본 프로그램 추가/제거 목록에 나타나지 않은 응용 프로그램도 볼 수 있음)과 자동 실행 응용 프로그램 목록도 제공됩니다.
마지막으로, "기타 정보" 섹션에서는 사용자 및 시스템 변수, 공유 리소스, 실행 중인 프로세스, 설치된 서비스 및 로컬 사용자 계정 등 시스템 환경에 대한 세부 정보를 요약해서 보여 줍니다.
Total Network Inventory는 자산 감사, 사용권 확인, 업그레이드 계산 및 성능 평가 등을 수행하는 데 실질적으로 필요한 정보를 제공합니다.이 도구의 가장 훌륭한 기능 중 하나는 Report Builder 구성 요소입니다.Report Builder는 빠른 참조에서부터 감사 보고서 추적에 이르기까지 모든 사항에 대한 여러 가지 훌륭한 구성의 상세한 보고서를 제공합니다.여러 시스템의 보고서를 집계하거나 단일 시스템에 대한 보고서를 볼 수 있습니다.그리고, 소프트웨어 및 사용권 계정 관리 탭 보기 기능이 특히 유용합니다.여기에서는 공급업체와의 계약을 정확히 준수할 수 있도록 환경 전체에 설치된 소프트웨어의 수를 종류별로 집계하여 표시합니다.
가격: 25개 노드 사용권의 경우 95달러부터입니다.
네트워크 노드 검색 과정을 안내하는 검사 마법사(크게 보려면 이미지 클릭)

서평
Mastering Microsoft Exchange Server 2007
sybex.com
원하든 원하지 않든, 전자 메일은 조직의 원활한 운영을 위해 필요한 핵심 구성 요소입니다.그렇지만, 사용자가 효과적인 문서 의사 소통을 위한 과정을 이수해야 전자 메일을 사용할 수 있도록 했으면 하는 바람이 드는 것은 사실입니다.지난 수년간 음성 통신, 일정, 리소스 예약, 단일 클라이언트 액세스, 메일 필터링(스팸, 바이러스 등) 등의 기능 통합에 대한 요구가 너무나 명백해졌습니다.Microsoft® Exchange Server 2007은 이러한 배경에서 출시되었습니다.
최신 버전의 Exchange는 이러한 모든 구성 요소가 통합된 확장 가능한 견고한 솔루션입니다.그러나 관리자, 설계자 및 지원 담당 직원이 모든 기능을 제대로 사용하려면 이 동적인 전자 메시징 솔루션을 계획하고 배포하며 관리하고 유지하기 위해 참조할 좋은 관련 서적이 필요합니다.
지난번 Toolbox 칼럼에서 필자는 Microsoft Exchange Server 2007 Administrator's Companion이라는 서적에 대해 언급한 바 있습니다.이번에는 또 하나의 유용한 서적으로 Barry Gerber와 Jim McBee가 공동 저술한 Mastering Microsoft Exchange Server 2007(Sybex, 2007)을 소개하겠습니다.이 책에는 Exchange Server의 수명 주기 전반에 대해 명쾌하게 짚고 있습니다.
이해 및 계획에 대해 논한 처음 세 개의 장에서는 Exchange Server 2007의 기본 구성 요소 및 구현 요구 사항에 대해 설명합니다.이 단원은 이전 버전의 Exchange에 익숙한 사용자에게 유용한 더 이상 강조되거나 구현되지 않은 기능들에 대한 설명과,모든 사용자에게 유용한 Exchange Server 2007 배포를 구성하는 다양한 서버 역할과 구성 요소에 대한 설명이 제공됩니다.이러한 복합적인 서버를 배포하기 위해서는 당연히 사전에 고려할 사항이 있게 마련이므로 서버 증가, 디스크 공간 요구 사항 및 Active Directory 통합 계획에 대한 단원을 세심하게 살펴볼 필요가 있습니다.
다음 단원은 실제 설치로 넘어가서 완전히 새로 설치하거나 Exchange Server 2000 또는 Exchange Server 2003(Exchange Server 5.5에서 바로 업그레이드할 수 없음)에서 업그레이드하는 방법에 대해 설명합니다.여기서는 Edge 전송, 클라이언트 액세스, 허브 전송, 사서함, 통합 메시징, 관리 도구를 비롯하여 각 Exchange Server가 담당할 수 있는 다양한 역할에 대해 자세한 설명이 제공됩니다.
그 다음에는 확장성으로 화제를 옮겨 성능 모니터링 방법, 사서함 저장소 추가 등을 설명합니다.여기서는 메일 저장소의 최신 로컬 백업을 유지할 수 있는 로컬 연속 복제라는 멋진 새 기능에 대해 살펴볼 수 있습니다.기본 데이터베이스에 이상이 생기면 가용성 및 정보의 최신 상태를 보장할 수 없는 다른 백업으로부터 복구할 필요 없이 이 백업으로 빠르게 전환할 수 있습니다.
다음 단원에서는 Exchange Server 2007 배포에서 사용할 수 있는 다양한 관리 작업과 도구에 대해 간략히 알아봅니다.여기에는 Windows PowerShell™ 기반의 Exchange 관리 셸, Windows PowerShell 엔진 기반의 Exchange 관리 콘솔 GUI와 같은 도구가 포함됩니다.이 단원에서는 사서함, 주소 목록 및 사용자 계정 관리 방법뿐만 아니라메시지 분류, 저널링 및 전송 규칙 관리와 함께 메시징 레코드 관리에 대해서도 다룹니다.
네 번째 단원에서는 가용성과 안정성에 대해 심도 있게 설명합니다.기업들이 전자 메시징에 의존하게 된 상황에서 이 단원은 깊이 살펴볼 만한 부분입니다.
여기서는 부하 분산, 서버 중복, 저장소 중복, 네트워크 중복 및 클러스터링의 기본적인 사항에 대해 배우게 됩니다.예약된 유지 관리, 백업 실행 및 재해 복구 시나리오 등 문제가 발생했을 때에도 기업의 전자 메시징 시스템 기능을 효과적으로 유지하기 위해 기본적으로 필요한 작업에 대한 모범 사례를 간략하게 알아봅니다.
그 다음 두 단원에서는 Microsoft Office Outlook® 2007, Outlook Web Access, IMAP 및 POP3 등의 클라이언트 액세스에 대해 설명합니다.그리고 Exchange 관리자에게 중요한 내용인 보안 및 감사에 대한 마지막 단원에서는 원하는 대로 사용할 수 있는 다양한 감사 도구와 함께 기본 보안 수단 및 예방 조치에 대해 설명합니다.하지만 무엇보다도, 심도 있는 내용을 다룬 이 책의 가장 큰 매력이라면 신속하면서도 올바르게 Exchange를 배포하는 데 도움이 된다는 것입니다.
가격: 49.99달러(직판가)

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


Utility Spotlight Microsoft SharedView
Greg Steen

지구 반대편에 있는 팀원과 함께 작업하는 경우가 많은 필자는 모든 사람이 동일한 데스크톱을 함께 보고 작업할 수 있다면 서로의 의견을 훨씬 더 효과적으로 표현하고 전달할 수 있을 거라며 아쉬워하는 상황에 항상 접합니다.
현장에 나가 있는 영업 팀이 신속하게 모여 정보를 공유하고 견적을 확인하며 이중 작업을 줄이도록 협의해야 한다고 가정해 보겠습니다.모든 팀원이 동기화율이 떨어지기 쉬운 "라이브 문서"를 전자 메일로 주고 받는 방법을 통해서가 아니라 하나의 Microsoft® Office Excel® 스프레드시트나 Word 문서를 거의 동시에 보면서 편집할 수 있다면 생산성이 얼마나 더 클지 상상해 보십시오.바로 이런 기능을 제공하는 경량 공동 작업 도구인 Microsoft SharedView 1.0을 소개합니다.
Microsoft SharedView를 사용하면 최대 15명까지 모임 주최자의 데스크톱을 동시에 공유하여 마치 같은 데스크톱을 보는 것처럼 작업할 수 있습니다.15명의 사용자가 동시에 하나의 데스크톱을 제어한다면 혼란만 따를 것이라고 생각할 수 있겠지만, 실제로는 데스크톱의 제어권이 사용자 간에 오가는 것입니다.
지금 내게 제어권이 있는 경우 함께 작업하는 공동 작업자의 마우스 움직임을 볼 수 있으므로(모든 사람에게 개인 포인터가 있음) 문서나 응용 프로그램에서 항목을 적절히 가리킬 수 있습니다.아쉬운 점은 SharedView에 오디오 기능이 통합되지 않았다는 것인데, Windows Live™ Messenger의 오디오 클라이언트나 흔히 이용되는 VoIP 클라이언트를 사용하면 데스크톱을 공유하면서 회의를 진행할 수 있습니다.
Microsoft SharedView를 통해 모임 주최자의 데스크톱 동시 공유(크게 보려면 이미지 클릭)
SharedView는 설치가 간단하고 클라이언트가 직관적이어서 기술적 지식이 부족한 사용자도 빠르게 설치하고 실행할 수 있습니다.Windows Live 계정으로 로그인한 다음 몇 번만 클릭하면 SharedView 세션을 시작할 수 있습니다.세션에 참가할 때도 연결할 세션 이름(일반적으로 주최자의 Live ID)과 암호만 입력하면 됩니다.초대장은 전자 메일을 사용하거나 생성된 초대 텍스트를 IM 클라이언트에 붙여 넣어 전송합니다.
그 밖에도 SharedView에는 원격 복사 및 붙여넣기 활성화 또는 비활성화(세션 사용자가 로컬 워크스테이션의 텍스트를 주최자의 시스템에 추가할 수 있음), Word의 변경 내용 추적 즉시 활성화(다른 사람들이 공유 문서에서 현재 변경하고 있는 내용을 볼 수 있음), 명시적 차단 목록(특정 Windows Live ID가 참가하지 못하도록 제외함) 등의 기능이 있습니다.이 응용 프로그램에는 또한 세션 참가자에게 추가 파일을 제공할 수 있는 유인물 기능이 있으며, 이를 통해 세션당 총 200MB까지 최대 25개 파일을 사용할 수 있습니다.
뿐만 아니라, 참가자에게 보내는 브로드캐스트 메시지를 입력하여 참가자들의 연결된 세션 맨 위에 표시되도록 할 수 있습니다.원하는 모든 내용을 공유할 수도 있고, 모임이 진행되는 동안 일부 데이터를 비공개로 유지하려는 경우에는 신속하고 손쉽게 호스트 컴퓨터의 공유 창을 시작 및 중지할 수 있습니다.무엇보다도, 쉽고 빠른 공동 작업 도구를 찾고 있다면 Microsoft SharedView가 제격입니다.
Microsoft SharedView를 시작하려면 TechNet Magazine 웹 사이트(technetmagazine.com)의 코드 다운로드 섹션에서 다운로드할 수 있습니다.

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


Inside SharePoint Office 응용 프로그램 통합
Pav Cherny

목차
Office 응용 프로그램 통합
SharePoint UI 확장
Office OpenDocuments 컨트롤 사용
SharePoint와 통신
사용자 지정 OpenControl 솔루션 구현
요약
Microsoft Windows SharePoint Services(WSS) 3.0과 Microsoft Office SharePoint Server(MOSS) 2007은 2007 Microsoft Office system의 데스크톱 응용 프로그램과 완벽하게 통합되어 문서, 스프레드시트, 일정, 연락처 정보 등에 대한 공동 작업의 효율성을 향상시킵니다.실제로 완벽하게 통합이 이루어지기 때문에
2007 Office system은 하나의 통합된 사무용 솔루션 플랫폼이라 할 수 있습니다.
따라서 정보 근로자의 생산성을 높이기 위해 Microsoft® Office 기술에 역점을 두고 있는 조직에 안성맞춤입니다.그러나 상이한 포트폴리오의 Office 응용 프로그램을 구축한 조직에서는 동일한 수준의 상호 운용성을 즉시 이용할 수는 없습니다.2007 Office system은 필요한 통합 기능을 제공하지만, 인터페이스와 구성 요소가 모든 상황에서 작동하지는 않으며 관련 설명서도 최소한으로 제공됩니다.이로 인해 타사 공급업체는 SharePoint® 기술을 자신의 응용 프로그램에 통합하기가 쉽지 않으며 해당 고객들이 정보 근로자들에게 통합된 환경을 제공하는 것은 더욱 더 어렵습니다.
이 칼럼에서 필자는 Office 응용 프로그램과 SharePoint를 통합하고 서로 통신하는 방법을 소개하는 한편, 동일한 방법을 통해 타사 응용 프로그램과 SharePoint를 통합하는 방법에 대해서도 설명하고자 합니다.먼저 완벽한 통합을 구현하는 데 사용되는 서버 구성 설정, 클라이언트 쪽 구성 요소 및 통신 프로토콜에 대해 간략히 살펴보겠습니다.
그런 다음 SharePoint의 기본 지원 기능 없이 이루어지는 응용 프로그램 통합에 대해 살펴보겠습니다.이러한 과정에서 필자는 SharePoint 서버에서 검색 기능을 확장하고 사용자 지정 아이콘을 추가할 수 있도록 IFilter 구성 요소 구현에 중점을 두는 일반적인 수준과는 다른 접근 방법을 사용할 것입니다.적절한 아이콘을 이용해 검색을 확장하고 결과를 반환한다고 해서 응용 프로그램이 완벽하게 통합되는 것은 아닙니다. 또한 사용자는 SharePoint 사용자 인터페이스 내에서 직접 이러한 문서를 열어야 할 수도 있습니다.
이것은 매우 복잡한 양상으로 나타납니다.워크스테이션에 Office를 배포하지 않은 경우에는 즉시 이용할 수 없는 클라이언트 쪽 구성 요소가 필요할 수 있습니다.그러나 Office를 배포했더라도 SharePoint의 사이트 토폴로지와 구성에 따라서는 이 구성 요소가 안정적으로 작동하지 않는 경우도 있을 수 있습니다.
이러한 문제를 해결하기 위해 필자는 Office 배포 요구 사항 없이 메모장, Adobe Reader 또는 Autodesk AutoCAD 등 응용 프로그램을 통합할 수 있는 사용자 지정 솔루션을 만들었습니다.또한 이러한 사용자 지정 솔루션을 통해 표준 Office 구성 요소를 기반으로 한 응용 프로그램 통합이 상황에 따라 실패하는 이유를 설명할 수 있습니다..com의 코드 다운로드 섹션에서 얻을 수 있는 이 칼럼의 첨부 자료에서 이 솔루션은 물론, 단계별 배포 및 구성 지침도 확인할 수 있습니다.

Office 응용 프로그램 통합
사용자 입장에서 볼 때 SharePoint 메뉴는 Windows® 시작 메뉴와 비슷하게 작동하는 것처럼 보입니다.문서 라이브러리에서 새 문서를 작성하는 것은 간단합니다.새로 만들기를 클릭하고 새 문서를 클릭하면 Microsoft Office Word 2007이 시작됩니다.기존 문서를 편집하는 것도 마찬가지로 간단합니다.문서에 마우스를 놓고 ECB(편집 컨트롤 상자) 드롭다운 메뉴를 연 다음 Word에서 편집을 클릭합니다.사용자는 JavaScript를 통해 웹 페이지에서 Word 2007을 시작했고, SQL Server® 데이터베이스에서 멀리 떨어진 위치에 해당 문서가 있는 상태에서 응용 프로그램을 로컬로 실행하고 있으며, 웹 서버는 그림 1과 같이 데이터 액세스 경로 내에 존재한다는 사실을 잊어버리기 쉽습니다.
그림 1 SharePoint에서 Word 문서로 작업 (더 크게 보려면 이미지를 클릭하십시오.)
이러한 복잡성에도 불구하고 2007 Office system이 설치된 Windows 워크스테이션에서 사용자는 원활한 작업을 수행할 수 있습니다.SharePoint 라이브러리에서 여러 문서로 작업하는 일은 로컬 파일 또는 네트워크 공유상의 파일로 작업하는 것과 상당히 비슷합니다.
그러나 Office 2003 또는 2007 Office system이 설치되어 있지 않은 Windows 워크스테이션의 경우 UI에는 차이가 있습니다.새 문서 또는 Word에서 편집을 클릭하면 Windows SharePoint Services 호환 응용 프로그램을 사용할 수 없다는 내용의 대화 상자가 나타납니다.
이것은 결코 놀라운 것이 아닙니다.Office 사용자들이 이용하는 통합된 환경을 제공하기 위해 함께 작동해야 할 몇 가지 요소가 있습니다.SharePoint에서는 새로 만들기 및 ECB 메뉴에서 원하는 명령을 실행할 수 있도록 문서 라이브러리에서 유지되는 콘텐츠 형식을 알고 있어야 합니다.이들 명령을 마우스로 클릭하면 JavaScript 코드가 실행되어 연결된 응용 프로그램을 시작한 후 문서 경로를 따라 이동해야 합니다.이 부분은 워크스테이션 구성과 상관없이 독립적으로 진행되지는 않는데 그 이유는 JavaScript 코드가 로컬로 실행되기 때문입니다.그뿐만 아니라 연결된 응용 프로그램은 파일을 읽고 쓰기 위해 SharePoint와 통신해야 합니다.이것은 SharePoint와 응용 프로그램을 통합하려는 경우 함께 고려해야 할 요소들입니다.
반면에 SharePoint와 데이터베이스 서버 간 통신은 응용 프로그램에는 드러나지 않게 수행되고, 검색 효율성을 높이기 위한 웹 서버상의 인덱싱 프로세스도 마찬가지로 투명하게 실행됩니다.따라서 본 칼럼에서는 이러한 측면들을 자세히 다루지는 않지만, Microsoft 기술 자료 문서 "Windows SharePoint Services 3.0에 Microsoft Filter Pack을 등록하는 방법"(support.microsoft.com/kb/946338)에 설명된 Microsoft Filter Pack 관련 내용을 살펴보는 것이 좋습니다.이제 명령 추가, 필요한 클라이언트 쪽 구성 요소 구현 및 응용 프로그램 통신 효율화에 대해 더 자세히 살펴보겠습니다.

SharePoint UI 확장
SharePoint의 사용자 인터페이스와 기능을 확장하는 데 사용할 수 있는 옵션은 매우 많습니다.사이트 디자인을 변경하고 ASP.NET 페이지를 사용자 지정하며 웹 파트를 개발하거나 WSS 및 MOSS에 포함된 JavaScript 코드를 변경하여 응용 프로그램을 직접 시작할 수 있습니다.
텍스트 편집기에서 Ows.js 파일을 열고(이 파일은 사용 중인 SharePoint 프런트 엔드 서버의 COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 폴더에서 확인할 수 있음) createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI 및 DispDocItem 함수가 작동하는 방식을 얼마든지 변경할 수 있습니다.다만 지원되지 않는 방식으로 WSS 코드 베이스를 변경할 필요가 없는 더 좋은 방법도 있는데 바로콘텐츠 형식와 문서 형식 매핑을 사용하는 방법이 그것입니다.
"사용자 지정 콘텐츠 형식을 이용한 데이터 관리의 표준화"(2008년 2월호 TechNet Magazine, technet.microsoft.com/magazine/cc194408.aspx 참조) 칼럼에서 필자는 SharePoint 문서 라이브러리와 목록에서 다양한 문서 및 기타 콘텐츠를 관리하기 위해 전역 및 사이트별 콘텐츠 형식을 작성하는 방법을 설명했습니다.또한 이 칼럼의 첨부 자료에서 Text Content Type.pdf 워크시트를 확인할 수도 있는데, 이 자료에서는 .txt 파일을 위한 새로운 콘텐츠 형식을 작성해 이 콘텐츠 형식을 문서 라이브러리와 연결하는 방법에 대해 설명합니다.그 결과, Word 문서에 대해 문서 명령을 사용하는 것과 마찬가지로 새로 만들기 메뉴에서 텍스트 콘텐츠 명령을 선택할 수 있습니다(그림 2 참조).
그림 2 SharePoint UI의 사용자 지정 콘텐츠 형식 (더 크게 보려면 이미지를 클릭하십시오.)
ECB 메뉴도 마찬가지로 확장이 가능합니다.사용자들은 ECB 메뉴에서 콘텐츠 형식이 인식될 것으로 기대할 수도 있지만 이는 최신 WSS 버전에서 이 메뉴를 구현하는 방식은 아닙니다.대신 사용자는 Docicon.xml에서 해당 문서 형식을 등록해야 합니다(Docicon.xml 파일은 모든 SharePoint 프런트 엔드 서버의 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml 폴더에서 확인할 수 있습니다).
예를 들어 Docicon.xml의 <ByExtension> 섹션에 다음과 같은 문서 형식 매핑을 추가하면 SharePoint에서는 메모장에서 편집 명령을 표시합니다(자세한 지침은 Text Content Type.pdf 파일 참조).
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Key 매개 변수는 파일 이름 확장명을 나타내고, Value 매개 변수는 사용자 인터페이스에 표시할 문서 아이콘을 정의하며, EditText 매개 변수는 SharePoint가 "다음 응용 프로그램에서 편집" 명령에 추가하는 문자열을 정의하고, OpenControl 매개 변수는 클라이언트 쪽 COM 구성 요소의 ProgID를 지정합니다.이것은 SharePoint JavaScript 함수가 COM 개체를 인스턴스화하기 위한 ActiveXObject 호출로 전달하는 ProgID이며(자세한 내용은 Ows.js 참조), 여기서 COM 개체는 그 자체가 응용 프로그램이거나 연결된 파일 형식을 기반으로 응용 프로그램을 시작하는 도우미 컨트롤일 수 있습니다.
SharePoint 제품 및 기술 웹 사이트

  • SharePoint 제품 및 기술 웹 사이트
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services 개발자 센터
  • Microsoft SharePoint 제품 및 기술 팀 블로그
SharePoint.OpenDocuments라는 이름의 OpenControl은 최신 버전의 Office와 함께 제공되는 ActiveX® 컨트롤(%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll)을 가리킨다는 사실에 유의하십시오.이 파일이 사용자의 워크스테이션에 존재하며 지정된 문서 아이콘(Value 매개 변수)이 사용자의 SharePoint 서버에 있는 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images 폴더에 있을 경우 필요한 통합 작업은 대부분 완료된 것으로 볼 수 있습니다.
Windows SharePoint Services 3.0 SDK에는 OpenDocuments 컨트롤을 비롯하여 2007 Office system과 함께 제공되는 클라이언트 쪽 API에 관한 몇 가지 정보가 포함되어 있습니다.자세한 내용은 msdn2.microsoft.com/ms440037의 "클라이언트 쪽 API 참조" 섹션을 참조하십시오.

Office OpenDocuments 컨트롤 사용
OpenDocuments 컨트롤은 중요한 응용 프로그램 통합 작업의 대부분 처리하지만 Office 2003 또는 2007 Office system이 있어야 하며 그 기능은 다소 제한됩니다.새로 만들기 메뉴에 있는 명령들은 항상 작동하는 것은 아니며 간혹 사용자가 오해할 수도 있는 내용을 표시하기도 합니다.
그림 3에서 볼 수 있는 것처럼 OpenDocuments 컨트롤은 필수 응용 프로그램이 제대로 설치되지 않았거나 서식 파일을 열 수 없다는 것을 사용자에게 알려 줍니다.다음 응용 프로그램에서 편집 기능에도 몇 가지 문제가 있습니다.그림 3의 포그라운드에 표시되는 두 번째 오류 메시지는 자주 볼 수 있습니다.이 메시지는 필자도 늘 경험하는 것인데 그 이유는 SharePoint 전문가들조차도 오해하게 되기 때문입니다. 잠시 후 이 메시지에 대해 자세히 설명하기로 하겠습니다.
그림 3 OpenDocuments 컨트롤의 잘못된 오류 메시지 (더 크게 보려면 이미지를 클릭하십시오.)
그럼에도 불구하고 OpenDocuments 컨트롤은 모든 워크스테이션에 최신 버전의 Office가 설치된 환경에서 유용하게 사용할 수 있습니다.무엇보다도, 문서 라이브러리 설정을 표시하고 새로 만들기 단추 순서 및 기본 콘텐츠 형식 변경을 클릭한 다음, 문제가 되는 모든 콘텐츠 형식에 대해 표시 확인란의 선택을 취소하는 방법을 사용하여 새로 만들기 메뉴에서 콘텐츠 형식을 숨길 수 있기 때문에 사용자들에게는 첫 번째 오류 메시지가 표시되지 않게 됩니다.또한 사이트 토폴로지를 간단하게 유지하여 WebDAV(Web-based Distributed Authoring and Versioning) 통신 문제를 피할 수도 있습니다. 이렇게 하면 두 번째 오류 메시지도 나타나지 않습니다.

SharePoint와 통신
지금까지 필자는 OpenDocuments 컨트롤을 이용해 SharePoint UI를 확장하고 응용 프로그램을 시작하는 것까지 해 봤습니다. 다만 필자의 응용 프로그램에는 SharePoint와 통신하여 데이터에 액세스할 방법이 여전히 필요합니다.SharePoint에서는 이러한 작업을 수행하기 위해 Microsoft Office FrontPage® Server Extensions, WSS RPC(원격 프로시저 호출), WebDAV, 웹 서비스 등 다양한 방법을 지원합니다.실제로 Word 2007과 같은 Office 응용 프로그램에서는 문서에 액세스하는 방법(웹 폴더를 통한 액세스, 매핑된 네트워크 드라이브를 통한 액세스 또는 SharePoint UI를 통한 액세스)에 따라 이러한 통신 방법 중 일부 또는 전체를 사용할 수 있습니다.
SharePoint 클라이언트/서버 통신에는 HTTP가 기본 프로토콜로 사용됩니다.예를 들어 FrontPage와 WSS RPC는 모두 SharePoint 서버의 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI 폴더 및 해당 하위 폴더에 있는 ISAPI 확장을 대상으로 하는 HTTP POST 및 HTTP GET 요청을 사용합니다.
가장 중요한 ISAPI 확장 중 하나는 Owssvr.dll인데 이 파일은 무엇보다도 목록 및 문서 라이브러리와 함께 작동하는 기능을 구현합니다.그림 4에서는 URL 요청(http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx)을 통해 직접 열리는 브라우저(오른쪽) 및 Word 2007(왼쪽)에서의 SharePoint 저장 대화 상자를 보여 줍니다.두 스크린 샷은 여러 면에서 확실히 비슷합니다.
그림 4 Word 2007 및 Internet Explorer의 SharePoint 저장 대화 상자 (더 크게 보려면 이미지를 클릭하십시오.)
그 밖의 중요한 ISAPI 확장으로는 Author.dll을 들 수 있는데, 이 파일은 문서의 업로드, 이름 바꾸기, 삭제와 같은 클라이언트 쪽 편집 작업을 위해 FrontPage 및 WSS RPC를 구현합니다. Admin.dll은 사이트를 관리하고 수많은 관리 작업을 수행하는 데 사용되며, Shtml.dll은 HTML 양식 제출을 지원하는 데 사용됩니다.
일반적으로 소스 코드에 액세스하지 않은 상태에서 FrontPage 및 WSS RPC 지원 기능을 기존 응용 프로그램(예: 메모장 또는 Adobe Reader)에 추가할 수는 없지만,Windows에 포함된 웹 클라이언트 기능을 이용해 필요한 통신 기능을 제공할 수는 있습니다.
또한 SharePoint는 %WINDIR%\System32\Inetsrv\ 폴더에 있는 Httpext.dll을 통해 WebDAV를 지원하지만 여기서는 클라이언트 쪽을 중심으로 살펴보겠습니다.Windows Server® 2008 또는 Windows Vista®를 실행하는 컴퓨터에는 웹 클라이언트 기능이 기본으로 설치됩니다.제어판의 관리 도구에 있는 서비스 애플릿에서 해당 WebClient 서비스를 찾을 수 있습니다.Windows XP와 Windows Server 2003에서는 웹 클라이언트를 명시적으로 설치해야 합니다.어떤 경우든 WebClient 서비스가 시작되었고 서비스 시작 유형이 자동으로 설정되어 있는지 확인해야 합니다.
그림 5에서는 웹 클라이언트의 아키텍처를 보여 줍니다.WebClient 서비스는 서비스 제어 관리자가 Svchost.exe 호스트 프로세스에 로드하는 사용자 모드 DLL(Webclnt.dll)에서 구현됩니다.Webclnt.dll은 I/O가 아닌 작업(예: WebDAV 액세스에 대한 사용자 인증, SharePoint 사이트를 네트워크 드라이브로 탑재, SharePoint 사이트, 목록 및 문서 라이브러리를 네트워크 리소스로 열거, 탑재된 드라이브 분리 등)에 대한 네트워크 공급자 인터페이스를 제공합니다.
그림 5 WebDAV 클라이언트 리디렉터 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
이 작업을 수행하기 위해 Webclnt.dll은 실제 리디렉터 기능을 제공하는 커널 모드 파일 시스템 드라이버와 통신합니다.WebDAV 클라이언트 리디렉터 드라이버(Mrxdav.sys)는 원격 파일 시스템의 서비스를 제공하기 위해 I/O 관리자 및 다른 커널 구성 요소와 통합되는 RDBSS(Redirected Drive Buffering Subsystem)를 기반으로 합니다.Mrxdav.sys는 SharePoint 사이트 및 문서 라이브러리에 대한 파일 시스템 수준의 액세스를 지원하기 위해 WebDAV 통신 기능을 구현합니다.
네트워크 리디렉터를 통해 SharePoint 사이트 및 문서 라이브러리에 액세스할 경우 사용자 응용 프로그램에서 FrontPage 및 WSS RPC를 지원할 필요가 없습니다.네트워크 드라이브는 문서 라이브러리(예: net use x:http://wss/doclib/Shared%20Documents)에 매핑할 수 있으며 UNC 경로를 통해서도 SharePoint 리소스에 액세스할 수 있습니다.
URL http://wss/doclib/Shared%20Documents는 \\wss\doclib\Shared%20Documents로 매핑됩니다.따라서 응용 프로그램에서 문서를 열 수 있는 것입니다.예를 들어 HTTP 경로인 http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt 또는 UNC 경로인 \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt를 이용해 메모장에서 문서를 열 수 있습니다.
웹 클라이언트 기능은 아쉽지만 몇 가지 제약이 있습니다.사용자 지정 TCP 포트를 사용하는 사용자 지정 속성 또는 웹 응용 프로그램에는 액세스할 수 없습니다.또한 첨부 자료의 WebDAV Access.pdf에 설명된 것처럼 계층 구조 내의 상위 사이트에 대한 액세스 권한이 사용자에게 없는 경우 Windows Vista와 함께 제공되는 웹 클라이언트는 작동하지 않습니다.
http://sharepoint/HR/Administration/Shared%20Documents/ 경로에는 존재하지 않는 루트 사이트(즉, http://sharepoint)가 포함되며, 웹 클라이언트는 루트에 액세스하지 않은 상태에서는 웹 서버의 기능을 확인할 수 없습니다.웹 서버는 상태 코드가 401인 웹 클라이언트의 OPTIONS 요청을 거부하는데, 이 코드는 액세스가 허용되지 않음을 의미하므로 결과적으로 웹 클라이언트는 사용자가 사이트 모음 SharePoint/HR 및 모든 해당 하위 사이트에 대한 관리 권한을 갖고 있더라도 그림 6에 설명된 것처럼 사용자 자격 증명을 요청하는 메시지를 계속 표시합니다.
그림 6 실패한 WebDAV 액세스 (더 크게 보려면 이미지를 클릭하십시오.)
OpenDocuments 컨트롤을 사용할 경우 웹 클라이언트가 문서를 열지 못하면 그림 3과 같은 오류 메시지가 표시됩니다.응용 프로그램은 사용할 수 있으며 문서 형식 매핑은 올바릅니다.이 문서는 WebDAV 리디렉터를 통해 액세스할 수 없는 문서입니다.

사용자 지정 OpenControl 솔루션 구현
일반적으로 웹 클라이언트의 단점을 해결하는 방법은 2가지가 있습니다.즉, Microsoft에서 웹 클라이언트의 업데이트 버전을 제공할 때까지 기다리거나 현재 상황을 해결할 수 있는 사용자 지정 OpenControl 솔루션을 구현하면 됩니다.사용자 지정 OpenControl을 구현하는 것은 결코 간단한 작업은 아니지만, 이 방법을 활용할 경우 사용자의 워크스테이션에서 Office를 사용할 필요가 없고 새로 만들기 명령과 다음 응용 프로그램에서 편집 명령을 보다 유용하게 처리할 수 있으며 웹 클라이언트가 작동하지 않을 때 문제를 해결할 수 있습니다.
이러한 문제점들을 해결하기가 어려울 경우 첨부 자료에 수록된 AppStart 소스 코드를 확인하십시오.이 코드를 통해 Microsoft .NET Framework 어셈블리에서 SharePoint JavaScript 코드가 호출할 수 있는 OpenControl COM 인터페이스를 제공하는 방법을 확인할 수 있습니다.또한 AppStart 소스 코드에서 WebDAV를 통해 직접 액세스를 할 수 없는 경우 파일 액세스 가능 여부를 확인하고 HTTP를 통해 로컬 컴퓨터로 파일을 다운로드하는 방법을 확인할 수 있습니다.마지막으로 AppStart 소스 코드는 콘텐츠 형식에 연결된 서식을 로컬 컴퓨터에 다운로드하여 새로 만들기 명령에 응답하기 때문에 사용자는 문서 작업을 시작할 수 있습니다.워크시트인 Text Content Type.pdf와 Adobe Reader Support.pdf에는 이러한 OpenControl 솔루션을 배포하는 방법이 간략히 정리되어 있습니다.
그림 7에 표시된 다이어그램에서는 AppStart 아키텍처를 보여 줍니다.필자의 사용자 지정 OpenControl 구성 요소(Biblioso.dll)는 SharePoint JavaScript가 새 문서를 작성하거나 편집할 기존 문서(Biblioso.AppStart.2 및 Biblioso.AppStart.3)를 열기 위해 호출하는 2개의 동일한 COM 인터페이스를 제공합니다.
그림 7 AppStart 아키텍처 (더 크게 보려면 이미지를 클릭하십시오.)
편집할 문서가 열려 있는 경우 Biblioso.dll은 해당 파일이 존재하는지 여부를 확인하며 WebDAV를 통해 파일에 직접 액세스할 수 있는 경우 해당 문서의 경로와 함께 관련 응용 프로그램을 시작합니다.파일에 액세스할 수 없는 경우 Biblioso.dll은 OpenDocsUtility.dll을 로드하는 Out-of-Process COM 서버를 시작하여 HTTP를 통해 파일을 다운로드하고 다운로드된 문서의 경로와 함께 응용 프로그램을 시작합니다.
이 솔루션에서는 Out-of-Process COM 서버를 사용함으로써 보호 모드에서 임시 인터넷 폴더로 다운로드를 제한하는 Internet Explorer® 프로세스로부터 벗어날 수 있습니다.사용자는 보호 모드의 제약 없이 파일을 다운로드할 수 있어야 하며, 응용 프로그램 중개자 역할을 담당하는 Out-of-Process COM 서버는 그 방법을 제공합니다.
.NET에서의 Out-of-Process COM 서버 개발은 지원되지 않기 때문에 필자는 이 실행 파일에 대해 C/C++로 전환했습니다.필자는 꼭 필요한 내용으로만 구성된 다른 이름으로 저장 대화 상자를 C++로 구현했습니다.가능한 한 솔루션을 간단하게 유지하고 개발 비용 부담을 낮추기 위해 .NET 어셈블리로 실제 다운로드 코드를 배치했는데(OpenDocsUtility.dll), 이후 이 코드는 다른 COM 인터페이스를 통해 호출됩니다.
좀 더 쉽게 배포하기 위해 솔루션에 설치 프로젝트를 추가했습니다.무엇보다도, 설치 루틴은 모든 COM 구성 요소를 등록하고 응용 프로그램 관련 설정을 HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart에 기록합니다.AllowedApps 및 AllowedFileTypes는 가장 중요한 매개 변수입니다.AppStart 솔루션은 이들 매개 변수에서 사용자가 명시적으로 지정해야 하는 응용 프로그램 및 파일 형식만 이용해 작업을 수행합니다.
또한 설치 루틴은 Out-of-Process COM 서버에 대해 권한 상승 정책을 만들기 때문에 Internet Explorer 프로세스에서 Biblioso.dll은 보안 경고를 트리거하지 않고 AppBrokerEngine.exe를 실행할 수 있습니다.Internet Explorer 보호 모드에 관한 자세한 내용과 응용 프로그램 개발 과정에서 이 모드를 처리하는 방법에 대해 알고 싶은 경우 Marc Silbey와 Peter Brundrett의 기사인 "보호 모드의 Internet Explorer 이해 및 작업"(msdn2.microsoft.com/bb250462)을 읽어볼 것을 추천합니다.
AppStart 구성 요소를 검사할 때는 이 솔루션이 단지 수행 가능한 작업만 표시하도록 개발되었다는 점에 유의하십시오. 이 솔루션은 프로덕션 환경에 대비해 설계되지는 않았고,소스 코드 주석는 차치하더라도 코드를 최적화하고 솔루션을 철저히 테스트하거나 기능을 문서화할 만한 시간적 여유가 부족했습니다.
이 솔루션을 사용하는 데 따른 모든 책임은 해당 사용자에게 있습니다.자신만의 고유한 솔루션을 만들기 위해 소스 코드를 공부하고 싶다면 Biblioso 코드 프로젝트에서 AppStart.cs로 시작하십시오.이 파일은 OpenControl COM 인터페이스 및 Ows.js에서의 JavaScript 호출을 위한 진입점을 구현합니다.
요약
WSS 3.0 및 MOSS 2007은 SharePoint 문서 라이브러리 및 목록에 있는 문서 및 기타 항목을 이용해 작업할 때 완벽한 사용자 환경을 제공하기 위한 광범위한 응용 프로그램 통합 기능을 제공합니다.2007 Office system의 데스크톱 응용 프로그램은 이러한 기능을 매우 생생하게 보여 주며 Office 이외의 다른 응용 프로그램에서도 동일한 수준의 통합 및 유용성을 실현할 수 있습니다.
응용 프로그램 통합 아키텍처의 중심에는 COM 구성 요소가 있으며 SharePoint JavaScript 함수는 이러한 COM 구성 요소를 문서 경로와 함께 사용해 응용 프로그램을 시작합니다.2007 Office system은 Office 고유의 응용 프로그램 요구에 맞게 최적화된 몇 가지 COM 구성 요소를 제공하며, 타사 응용 프로그램을 통합하도록 Office OpenDocuments 컨트롤을 다시 사용할 수도 있습니다.OpenDocuments 컨트롤은 가장 기본적인 요구 사항을 충족합니다.보다 높은 수준의 응용 프로그램 통합 요구 사항에 대해서는 사용자 지정 컨트롤을 구현할 수 있습니다.
SharePoint와 응용 프로그램을 완전히 통합하려면 검색 및 표시 기능을 확장하기 위해 IFilter 구성 요소와 문서 아이콘을 설치해야 할 뿐만 아니라 SharePoint 서버에서 사용자 지정 콘텐츠 형식과 문서 형식 매핑을 만들어서 SharePoint 사용자 인터페이스에 적절한 새로 만들기 및 다음 응용 프로그램에서 편집 명령을 제공해야 합니다.이러한 명령은 OpenControl 구성 요소를 통해 제공되는 메서드를 호출하는 JavaScript 함수를 호출합니다.OpenControl 구성 요소는 워크스테이션에서도 사용할 수 있어야 합니다.
한편, Windows Vista에 포함되어 있으며 기본적으로 설치되는 웹 클라이언트도 중요한 부분을 차지합니다.웹 클라이언트는 WebDAV 리디렉터 및 원격 파일 시스템 드라이버를 구현하기 때문에 모든 응용 프로그램은 네트워크에서의 파일 공유와 마찬가지로 SharePoint 목록 및 문서 라이브러리의 리소스에 액세스할 수 있습니다.Windows Vista와 함께 제공되는 웹 클라이언트는 여러 가지 단점을 갖고 있지만 응용 프로그램 통합에서는 없어서는 안 될 중요한 부분을 차지합니다.
또한 WebDAV 지원은 타사 워크스테이션 및 SharePoint에서 실행되는 응용 프로그램들 간의 차이를 좁히는 역할을 합니다.COM 및 ActiveX 제어 기술은 일반적으로 이러한 운영 체제에서는 사용할 수 없기 때문에 응용 프로그램을 자동으로 시작하는 데 OpenControl 구성 요소를 사용할 수는 없습니다. 그러나 대부분의 운영 체제에는 WebDAV 리디렉터가 포함되어 있으므로 사용자들은 로컬 워크스테이션에 파일을 다운로드하지 않고도 최소한 문서 라이브러리에서 문서에 직접 액세스할 수 있습니다.
WSS 3.0 및 MOSS 2007은 2007 Office system의 성공을 위한 초석이며 타사 Office 기반 응용 프로그램의 사용자들은 SharePoint의 장점을 동일한 방법으로 활용할 수 있습니다.통합 기능은 Office 그 이상의 범주에까지 적용됩니다.SharePoint의 장점을 십분 활용함으로써 Office 및 타사 소프트웨어에 대해 동일한 사용자 환경을 제공하는 통합 사무용 솔루션 플랫폼을 구축할 수 있으며, 그 결과 정보 근로자들의 생산성은 증대됩니다.

Pav Cherny는 공동 작업 및 통합 커뮤니케이션을 위한 Microsoft 기술을 전문으로 하는 IT 전문가이자 저술가입니다.IT 운영과 시스템 관리를 주로 다루는 백서, 제품 설명서 및 서적 등을 출간한 Pav는문서 관리 및 지역화 서비스를 전문으로 하는 Biblioso Corporation의 사장입니다.


Windows PowerShell 드롭 상자
Don Jones

목차
Cmdlet가 되어 보기
필터링 함수
실제 물체를 통해 생각해 보기
실제 응용 프로그램
시연해 보기
필자가 최근에 진행한 Windows PowerShell 강좌에서 일부 학생들은 셸 파이프라인의 모든 항목을 머릿속으로 그려보는 데 어려움을 겪었습니다.파이프라인은 전혀 간단한 개념이 아니기 때문에 파이프라인이 어떤 식으로 전개되는지 정확하게 그려보는 것이 학생들에게는 매우 어려울 수 있습니다.파이프라인에서 직접 작동하는 필터링 함수에
대한 개념을 설명할 때 이 내용이 정말 어려운 것이었음을 몇몇 학생들이 짓고 있던 난감한 표정에서 읽을 수 있었습니다.
어려워하는 학생들의 이해를 돕기 위해 다음 날 상자 하나, 몇 개의 이름표 스티커와 탁구공을 가지고 다시 설명했습니다.물론 Windows PowerShell®이 재미있겠느냐고 말하는 사람은 아무도 없었습니다만다음 명령줄을 통해 시연해 보기로 했습니다.
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Cmdlet가 되어 보기
여러분도 알다시피 학교 동창회나 이와 비슷한 큰 규모의 행사에서 항상 착용하는 "안녕하세요. 제 이름은 ...입니다."와 같은 이름표 스티커를 사용하여 각 학생에게 cmdlet 이름을 나눠 주었습니다.탁구공이 Windows® 프로세스 개체(더 구체적으로 말하자면 System.Diagnostics.Process 형식의 개체)를 나타낸다고 설명한 다음 학생들에게 프로세스 개체를 생성할 수 있는 것으로 보이는 cmdlet 이름을 얘기해 보도록 했습니다.
학생들은 서로가 가진 이름표를 둘러본 후 망설임 없이 Get-Process를 선택했습니다.이것이 필자가 Windows PowerShell에 cmdlet 이름을 사용하기 좋아하는 주된 이유 중 하나입니다.즉, 이름은 해당 성격을 바로 나타내기 때문입니다.
따라서 Get-Process를 맡은 학생이 모든 탁구공을 주워 상자에 넣었습니다.상자는 셸의 파이프라인을 나타내고 학생이 수행한 작업이 바로 cmdlet에서 수행하는 작업입니다.즉, cmdlet는 하나 이상의 개체를 생성한 다음 파이프라인에 넣습니다.
그러면 파이프라인의 다음 cmdlet가 그 다음 작업을 수행합니다.이 예제에서는 Where-Object cmdlet 이름표를 받은 학생이 탁구공을 모두 집어 들어 한 번에 하나씩 각 탁구공의 VM 속성이 1,000보다 큰지 확인했습니다.셸에서 "VM"은 가상 메모리를 나타냅니다. 이 실습을 위해 필자는 각 탁구공에 다양한 가상 메모리 크기를 마커로 적어 두었습니다.
VM이 1,000 이상인 모든 공(프로세스)은 다시 상자(파이프라인)에 넣고 VM 값이 그보다 낮은 나머지 공은 다시 볼 수 없도록 쓰레기통에 버렸습니다.솔직히 말하자면 실제로 공을 버린 것은 아니고 다음 수업 시간에 다시 사용했습니다.
그런 다음 Sort-Object를 맡은 학생이 상자에 담긴 탁구공을 해당 VM 속성을 기준으로 순서대로 배치했습니다.사실 이 작업은 제대로 계획하지 못한 실습 중 하나였습니다. 공이 이곳저곳으로 굴러다니지 않도록 하는 데는 약간 문제가 있었습니다.따라서 다음 수업에는 탁구공 역할을 할 주사위를 준비하거나 달걀 상자 몇 개를 바로 쓸 수 있도록 준비해 둬야겠습니다.
마지막으로 Export-CSV 역할을 맡은 학생이 공을 집어 들고 CSV 파일에 해당 정보를 적었습니다.실제로는 프로세스 속성을 플립 차트에 기록했고 이 플립 차트를 CSV 파일이라고 가정했습니다.

필터링 함수
다음으로 간단한 파이프라인을 통해 좀 더 복잡한 필터링 함수를 살펴보기로 했습니다.그림 1에 표시된 필터링 함수와 명령줄을 예로 들었습니다.
그림 1 필터링 함수 및 명령줄 예제
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
우선 필터링 함수가 수행하는 작업이 무엇인지 간단히 설명하겠습니다.핵심은 이 함수에는 BEGIN, PROCESS, END라는 세 가지 스크립트 블록이 있다는 것입니다.
BEGIN 스크립트 블록은 파이프라인에서 함수가 사용될 때 처음 실행되며데이터베이스 연결 열기와 같은 설정 작업을 수행할 수 있습니다.
그런 다음 PROCESS 스크립트 블록이 파이프라인을 통해 함수로 전달된 개체마다 한 번씩 실행됩니다.PROCESS 스크립트 블록 내에서 $_ 변수는 현재 파이프라인 개체로 자동으로 채워집니다.따라서 10개의 개체가 파이프라인을 통해 전달되면 PROCESS 스크립트 블록이 10번 실행됩니다.
마지막으로 파이프라인을 통해 전달된 개체가 모두 실행되면 END 스크립트 블록이 실행되어 데이터베이스 연결 닫기와 같은 필요한 정리 작업을 수행합니다.
이러한 스크립트 블록 내에서 Write-Output을 사용하여 작성된 모든 항목은 다음 cmdlet를 위해 파이프라인에 저장됩니다.Write-Output을 통해 작성되지 않은 항목은 모두 삭제됩니다.
이 예제에서 명령은 Get-Process로 시작되므로 Get-Process를 맡은 학생이 강의실 여기저기에 굴러다니고 있던 모든 탁구공을 찾아서 파이프라인 상자에 넣을 동안 우리는 잠시 기다리게 되었습니다.작업을 마친 후에는 "Do-Something" 필터링 함수를 맡은 학생이 작업을 이어서 수행했습니다.
이 학생은 먼저 BEGIN 스크립트 블록을 실행했습니다.비어 있으므로 특별히 수행할 작업이 없었습니다.그 다음 모든 탁구공(파이프라인 개체)을 주워 한 번에 하나씩 살펴보았습니다.공이 약 12개였는데 이 학생이 모든 공을 무릎 위에 놓으려고 애쓰는 모습이 조금 우스꽝스러웠습니다. 여러분이 그 광경을 보았어야 했는데요.
어쨌든 한 번에 하나씩 프로세스 개체를 주은 다음 PROCESS 스크립트 블록을 실행했습니다.즉, PROCESS 스크립트 블록을 통해 새 사용자 지정 개체를 만들었습니다.필자는 특별히 노란색 탁구공을 사용자 지정 개체로 사용했으며 노란색 탁구공은 가까운 스포츠 용품 가게에서 쉽게 구할 수 있었습니다.이러한 새 탁구공에 현재 살펴보고 있는 프로세스 개체의 이름과 함께 현재 날짜와 시간을 기록했습니다.
그런 다음 이 새로운 사용자 지정 개체를 파이프라인에 기록했습니다. 즉, 노란색 탁구공을 상자에 넣은 것입니다. 원래 프로세스 개체를 나타내는 탁구공은 버렸습니다.상자에 있는 약 12개의 각 프로세스 개체를 나타내는 탁구공에 대해 이 작업을 수행했습니다.이 작업을 통해 모든 흰색 탁구공이 노란색 탁구공(사용자 지정 개체)으로 교체되었습니다.마지막으로 END 스크립트 블록을 실행했습니다. 이 스크립트 블록은 비어 있으므로 아무런 작업도 수행하지 않았습니다.
마무리를 위해 Format-Table을 맡은 학생이 다음 작업을 수행했습니다.이 학생은 상자에 있는 모든 탁구공(노란색 "사용자 지정" 개체)을 꺼낸 후 각 공에 적힌 속성을 이용하여 표를 만들었습니다.그 결과 플립 차트에 TimeStamp와 ProcessName이라는 두 개의 열과 약 12개의 행이 있는 표가 그려졌습니다.

실제 물체를 통해 생각해 보기
이 실습은 강좌를 듣는 모든 학생들이 파이프라인 및 필터링 함수를 제대로 이해할 수 있도록 진행되었습니다.탁구공은 셸에 대해서만 설명하는 경우 다소 추상적인 개념으로 느껴질 수 있는 개체를 나타내는 데 정말 효과적이었습니다.
모든 학생들은 cmdlet가 이러한 개체를 처리하는 방법, 파이프라인에서 결과가 저장되는 방법 및 다음 cmdlet가 이러한 결과를 선택하여 이후 개체를 처리하는 방법을 파악할 수 있었습니다.필터링 함수의 이벤트 시퀀스는 PROCESS 스크립트 블록이 한 번에 하나의 입력을 처리하는 방법이라는 점에서 보다 파악하기 쉬웠습니다.
여기서는 또한 새 사용자 지정 개체를 만들어 파이프라인에 저장하는 방법에 대해서도 직접 시연해 보였습니다.이러한 실습은 새 사용자 지정 개체가 Format-Table과 같은 다른 cmdlet에서 사용될 수 있으므로 보다 유연한 방식으로 데이터를 사용하거나 나타낼 수 있다는 단순한 설명과는 달리 사용자 지정 개체를 만듦으로써 얻을 수 있는 이점을 구체적으로 설명하는 데도 도움이 되었습니다.

실제 응용 프로그램
학생들이 궁금해 하는 주된 질문은 파이프라인 및 우리가 시연해 본 이러한 필터링 함수를 실제 응용 프로그램에서 어떻게 사용할 수 있는지에 대한 것이었습니다.최근 컨퍼런스 세션에 사용하기 위해 몇 가지 예제를 만들어 두었기 때문에 이에 대해 답해 주는 것은 쉬운 일이었습니다. 이러한 예제는 scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples에서 다운로드할 수 있습니다.
이 중 한 가지 예제는 여러 컴퓨터의 WMI(Windows Management Instrumentation)에 포함된 Win32_UserAccount 클래스에서 여러 속성을 나열하기 위한 것입니다.컴퓨터 이름이 C:\Computers.txt에 표시되어 있다고 가정할 경우 다음과 같은 간단한 명령으로 이 작업을 수행할 수 있습니다.
Gwmi win32_useraccount –comp (gc c:\computers.txt)
문제는 어떤 컴퓨터에서 각 인스턴스가 생성되었는지 나타내는 속성이 Win32_UserAccount 클래스에는 없다는 것입니다. 즉, 결과 목록은 여러 컴퓨터의 계정을 두서없이 표시하므로 유용하지 않습니다.필자는 원본 컴퓨터 이름을 포함하고 필자가 필요로 하는 클래스 속성을 선택하는 새 사용자 지정 개체를 만들어 이 문제를 해결했습니다. 이 사용자 지정 개체에 대한 코드는 그림 2에 나와 있습니다.
그림 2 사용자 지정 개체를 사용하여 컴퓨터 이름을 수집하고 속성 선택
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
마지막 명령줄에서는 사용자 지정 개체를 생성하는 필터링 함수에 모든 컴퓨터 이름을 전달합니다.다음으로 PasswordRequired 속성이 False인 사용자를 제외한 모든 사용자를 필터링했습니다. 이 방법은 문제가 발생한 계정에 대한 감사 보고서를 만들기 위한 것입니다.그런 다음 Computer 및 Name 속성을 유지하기만 하면 됩니다. 그러면 만료되지 않는 암호를 사용하므로 주의가 필요한 계정 이름과 컴퓨터 이름이 수록된 최종 보고서를 얻을 수 있습니다.필터링 함수를 사용하면 확인할 속성만 선택하는 과정에서 원본 컴퓨터 이름을 출력에 추가할 수 있으므로 이러한 여러 컴퓨터에 대한 보고서를 얻을 수 있습니다.
이 작업을 수행할 수 있는 다른 유사한 방법이 여럿 있지만 이 방법이 가장 간단할 것입니다.또한 중요한 개념과 기술을 파악하기에도 좋습니다.

시연해 보기
파이프라인에 대해 잘 안다 하더라도 여기에는 한 가지 더 배울 점이 있습니다.실제 물체를 대입하여 생각해 보면 수행하고자 하는 것이 무엇인지 쉽게 파악할 수 있습니다.
따라서 이후에 Windows PowerShell 개념을 익히는 데 어려움을 겪게 되면 컴퓨터에서 바로 작업하기 보다는 일상 생활에서 사용하는 물체를 통해 작업을 시연해 보는 것이 도움이 될 수 있습니다.이를 위해서는 탁구공(또는 구할 수 있는 경우 주사위)을 넣은 작은 가방을 언제든지 이용할 수 있도록 준비해 두는 것이 좋습니다.
이달의 Cmdlet:Out-File
> 기호를 사용하여 cmdlet 출력을 파일에 연결한 적이 얼마나 됩니까?이것은 Get-Process > Processes.txt와 같습니다.여러분은 외면만 약간 바뀐 Out-File cmdlet를 사용하고 있다는 것을 알고 있습니까?정확한 함수를 수행하는 명령은 다음과 같습니다.Get-Process | Out-File Processes.txt.
물론 여기에는 입력 작업이 약간 더 필요하지만 전체 Out-File cmdlet를 입력해야 하는 이유는 무엇일까요?한 가지 이유는 Out-File을 입력한 경우 이를 읽을 때 그 의미를 더 명확하게 이해할 수 있기 때문입니다.6개월 후에 누군가가 여러분이 작성한 스크립트 중 하나를 살펴보고 > 기호가 무엇을 의미하는지 궁금해 할 수도 있습니다. 결국 이것은 여러분이 설명해야 할 일이 됩니다.
그와 반대로 Out-File에서는 파일이 매우 명확한 방식으로 생성되고 작성됩니다.또한 Out-File에서는 -force 및 -noClobber 매개 변수와 함께 -append 매개 변수(>> 기호와 매우 유사함)를 사용할 수 있으므로 기존 파일을 덮어쓸지 여부를 제어할 수 있습니다.마지막으로 Out-File을 입력하면 -whatif 매개 변수도 사용할 수 있습니다.이 유용한 매개 변수는 Out-File의 작업 결과를 실제 수행 없이 보여 줍니다.위험을 최소한으로 줄이면서 복잡한 명령줄을 테스트할 수 있는 최고의 방법이지 않습니까?
비디오
Don Jones가 이러한 cmdlet를 어떻게 사용하는지 살펴보십시오.

Don Jones는 Windows PowerShell:TFM의 공동 저자이며 Windows PowerShell 강좌(www.ScriptingTraining.com)를 진행하고 있습니다.


Hey, Scripting Guy! 짜릿한 흥분
Microsoft Scripting Guys

저희는 매달 TechNet Magazine에 기고하는 것만큼 흥분되는 일은 없다고 생각합니다. 그리고 마침내 게시되었을 때는 큰 보상을 얻은 느낌이죠.(물론 실제로 금전적인 보상을 받는다면 금상첨화겠지만, 뭐 어쩔 수 없죠.)얼마나 멋진 직업입니까?이렇게 말하고 싶군요.아마 지금 전 세계 어린이들은 잠자리에 들면서 엄마에게 "엄마, 난 이 다음에 크면 매달 TechNet Magazine에 스크립팅 칼럼을 연재할래요."라고 할 겁니다.
참고 물론 세계 곳곳에는 지금도 이 칼럼을 어린이가 연재하고 있는 게 아닌지 의심하는 분들이 있습니다.하지만 뭐, 그것도 어쩔 수 없죠.
Scripting Guy가 TechNet Magazine의 칼럼에 대한 대한 독자들의 칭찬에 얼마나 약한지는 이미 잘 알려져 있습니다. 사인을 부탁하며 몰려드는 팬들과 파파라찌에게도 항상 웃음을 잃지 않을 정도니까요.하지만 사실은 이런 명예나 명성보다는 시스템 관리 스크립트를 작성할 때 느껴지는 짜릿한 흥분 때문에 이 일을 그만 두지 못하는 것입니다.
물론 똑같은 상황이라도 짜릿한 흥분이라든가 시스템 관리 스크립팅이라는 표현을 사용하는 사람은 거의 없겠죠.(무슨 의미인지도 모르고 사용한다면 모를까요.)
일반인들은 대개 시스템 관리 스크립팅이 매우 유용하긴 하지만 그다지 재미있지는 않으며 오히려 따분한 일로 치부합니다.그건 그 사람들이Windows Vista®나 Windows Server® 2008에서 부팅 구성 데이터 스크립트를 작성해본 적이 없기 때문입니다.
이런 이야기를 들으니 슬슬 흥분되지 않나요?이 기사를 읽는 독자라면 아마 대부분 이미 알고 있겠지만 부팅 프로세스 관리와 관련하여 향상된 유연성과 기능을 제공하는 새로운 부팅 구성 데이터 저장소가 도입되면서 Windows Vista와 Windows Server 2008에서 기존 boot.ini 파일은 더 이상 사용되지 않습니다.
이러한 변화도 괜찮은 일이긴 하지만정말 멋진 것은새로운 WMI(Windows® Management Instrumentation) 공급자 덕분에 스크립트를 사용하여 BCD(부팅 구성 데이터) 저장소를 손쉽게 액세스하고 완벽하게 관리할 수 있게 되었다는 점입니다.
지금쯤 등골이 짜릿한 이상한 기분이 들지 않습니까? 그런 느낌이 바로 저희가 말하는 짜릿한 흥분입니다.BCD 스크립트를 사용하여 작업하다 보면 그런 기분을 자주 느끼게 될 겁니다.
본론으로 들어가기 전에 BCD 공급자의 모든 용도를 이 칼럼에서 모두 다룰 수는 없다는 점을 알아두시기 바랍니다.(Magazine 편집자들에게 부팅 구성 데이터 스크립트 작성에 대해서 심도 있게 다루는 특집 기사를 실을 수 있는지 묻는 전자 메일을 보냈지만 아무런 반응이 없습니다.)
따라서 자세한 내용을 알아보려면 BCD WMI 공급자 설명서(go.microsoft.com/fwlink/?LinkId=116953)를 참조하시기 바랍니다.이 칼럼에서는 운영 체제가 두 개 이상 설치된 멀티부팅 컴퓨터용 샘플 코드를 몇 가지 소개하겠습니다.
참, 여기서 소개하는 스크립트는 Windows Vista와 Windows Server 2008에만 적용됩니다.앞에서도 설명했듯이 현재 BCD를 지원하는 운영 체제가 이 두 가지밖에 없기 때문입니다.
그러면 먼저 현재 컴퓨터에서 사용 중인 OS를 확인하는 스크립트부터 살펴보겠습니다.물론 Win32_OperatingSystem이라는 WMI 클래스를 사용하면 현재 컴퓨터에서 사용 중인 OS를 확인할 수 있으므로 이것이 BCD 공급자만의 특별한 기능이라고 할 수는 없습니다.그러나 적어도 BCD 스크립트만 놓고 이야기한다면 이 스크립트는 꽤 간단하면서도 BCD 작업에 필요한 기본적인 기술을 잘 보여 줍니다.(어떻게 보면 좀 특이한 방법이긴 하네요.)
여담이지만, 칼럼을 보다 흥미진진하게 쓸 수 없어서 아쉽습니다.TechNet Magazine 측에서는 지나치게 열성적인 Hey, Scripting Guy! 팬들이 너무 흥분하여 발생하는 사고에 대한 책임은 전적으로 저희에게 있다고 경고하기도 했습니다.정규식에 대한 칼럼이 게재된 후에 전 세계에 걸쳐 나타났던 격렬한 반응과 같은 일이 다시 일어나서는 안 되니까요.
참고 비틀즈가 팬들에게 에워싸이는 비디오나 존, 폴, 조지, 링고가 나타나자 울면서 까무러치는 소녀들의 사진을 본 적이 있습니까?저희가 새 칼럼을 게시할 때마다 그와 비슷한 일이 발생하곤 합니다.
예, 예, 조금 과장된 비유라는 점은 인정하죠.하지만 남자든, 여자든, 많은 사람들이 저희 칼럼을 읽으면서 감동의 눈물을 흘리는 건 분명합니다.
아무튼 BCD 공급자를 사용하여 컴퓨터에서 현재 사용 중인 OS를 확인하는 그림 1의 스크립트를 눈여겨보십시오.이 스크립트는 관리자 권한으로 실행하지 않으면 실패한다는 사실을 명심하십시오.
그림 1 현재 운영 체제 가져오기
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
그렇다고 관리자 권한이 있는 계정으로 로그온해야 한다는 뜻은 아닙니다.시작 메뉴에서 명령 프롬프트를 마우스 오른쪽 단추로 클릭하여 명령 프롬프트 창을 열고 관리자 권한으로 실행을 선택해야 합니다.그러면 명령 프롬프트에서 이 스크립트를 실행할 수 있습니다.
이제 이 스크립트가 어떻게 작동하는지 살펴보겠습니다.사실 스크립트 작동 방식을 쉽게 설명할 수 있을지 걱정이 되지만최대한 노력해보겠습니다. (잠시 흥분을 가라앉히고 좀 따분한 이야기를 해야 할 것 같군요.)
먼저BcdLibraryString_Description과 Current라는 상수를 정의합니다.BcdLibraryString_Description은 검색할 개체를 나타냅니다. 이 예에서는 현재 운영 체제의 Description(이름)이 들어 있는 개체입니다.
여기서 BCD 공급자를 사용하는 것의 진가가 발휘됩니다.일반적으로 속성의 값은 단순히 검색하면 되는 것이 아니라, 이러한 상수 값 중 하나와 GetElement 메서드를 사용하여 다른 개체를 검색한 다음 해당 개체에 속한 속성의 값을 출력해야 합니다.물론 다소 복잡한 면이 있지만,여행의 즐거움 중 절반은 목적지까지 가는 과정에 있다는 말도 있지 않습니까?
참고 흠, 이 속담을 들을 때마다 "대체 어디를 가길래?"라는 생각이 들지 않습니까?
Current 상수는 현재 사용 중인 운영 체제를 나타내는 GUID에 불과합니다.아래의 값은
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
"잘 알려진" GUID로 간주됩니다. (이런 걸 보면 Microsoft에서 일하는 사람들도 유머 감각이 꽤 있는 것 같습니다.)
이 값이 잘 알려진 GUID이기는 하지만 일단 이 값을 포함하도록 하겠습니다. 다음과 같이 비슷한 두 값이 나타나면 어떤 것이 맞는지 혼동하는 독자도 있을 것이기 때문이지요.
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
참고 혹시 궁금해하는 독자를 위해 덧붙이자면, GUID는 "gwid(그위드)" 또는 "goo-id(구-아이디)"로 읽을 수 있습니다.또한 세 번째 숫자 그룹이 4로 시작하므로 위의 GUID는 V1 GUID입니다.이외에도 설명할 내용이 많지만 기사를 최대한 자중해서 쓰기로 약속했기 때문에이 정도로 하겠습니다.
이미 파악한 독자도 있겠지만 BCD 공급자를 사용하여 작업을 수행할 때는 상수, 16진수 값 및 GUID를 꽤 자주 사용하게 됩니다.이번 달 칼럼에서 이러한 항목을 모두 다룰 수는 없지만 앞서 언급한 MSDN®의 BCD 페이지(go.microsoft.com/fwlink/?LinkId=116953)에서 자세한 내용을 확인할 수 있습니다.그 흥미진진한 내용이 주는 흥분을 이겨낼 수 있다면 말입니다.
2개의 상수를 정의한 후에는 로컬 컴퓨터에서 WMI 서비스에 연결합니다.이 스크립트를 사용하여 원격 컴퓨터의 부팅 구성 데이터를 검색할 수 있을까요?물론이죠.
사실, 원격 컴퓨터의 부팅 구성 데이터를 검색할 수 없다면 이 BCD 스크립트는 효용성이 낮다고 할 수 있겠지요.원격 컴퓨터(Windows Vista 또는 Windows Server 2008을 실행하는 원격 컴퓨터의 경우)에서 부팅 구성 데이터를 검색하기 위해서는 strComputer라는 변수에 해당 컴퓨터의 이름을 할당하기만 하면 됩니다.
strComputer = "atl-fs-001"
WMI 연결 문자열에서도 몇 가지 중요한 사항을 살펴볼 필요가 있습니다.첫째로, 연결 문자열에 백업 및 복원 권한이 포함되어 있는 것을 알 수 있습니다. {(Backup,Restore)}가 바로 이러한 역할을 합니다.이것이 중요하냐고요?스크립트가 제대로 작동하기를 바란다면 매우 중요하죠.이 두 권한을 명시적으로 포함하지 않으면 스크립트가 실패합니다.
둘째로, 시스템 관리 스크립트에 가장 많이 사용되는 네임스페이스인 root\cimv2 네임스페이스에 연결하지 않은 것을 알 수 있습니다.그 대신 root\WMI 네임스페이스에 연결하고 BCDStore 클래스에 직접 바인딩합니다.다음 코드에서 이 작업을 합니다.
"\root\wmi:BcdStore"
정말로 흥미로운 부분은지금부터입니다.
한두 가지 예외는 있겠지만 여러분이 작성하는 BCD 스크립트는 대부분상수를 정의하고 WMI 서비스에 연결한 다음 BCD 저장소를 여는 세 단계로 시작됩니다.위에서 이미 1단계와 2단계는 완료했고, 3단계를 처리하는 코드는 다음과 같습니다.
objStoreClass.OpenStore "", objStore
여기서는 모든 부팅 구성 정보가 저장되는 운영 체제 엔터티인 BCD 저장소를 엽니다.저장소를 열려면 OpenStore 메서드를 호출하여 이 메서드에 다음 두 가지 매개 변수만 전달하면 됩니다.
  • 빈 문자열("").스크립트에 기본 저장소를 열 것임을 알리는 역할을 합니다.
  • objStore.스크립트에 제공하는 "출력" 매개 변수입니다.메서드에 변수 이름을 제공하면 메서드는 이에 대한 응답으로 해당 변수 이름을 개체 참조로 사용하는 개체(이 예의 경우 BCD 저장소를 나타내는 개체)를 반환합니다.
저장소가 열리면 OpenObject 메서드를 사용하여 다른 개체(objDefault 출력 매개 변수에 저장되어 있음)를 검색할 수 있습니다.
objStore.OpenObject Current, objDefault
이 새 개체의 정체는 무엇일까요?그렇습니다.바로 현재 사용 중인 운영 체제입니다.OpenObject에 현재 운영 체제를 나타내는 잘 알려진 GUID인 Current 상수를 전달했으므로 이것을 알 수 있는 것입니다.
자, 이제 컴퓨터에서 현재 사용 중인 운영 체제는 알게 되었습니다.정확히 말하면 거의 알게 된 거죠.해당 정보를 가져오기 위해서는 GetElement를 사용하여 해당 운영 체제의 Description을 나타내는 개체를 검색해야 합니다.
objDefault.GetElement _
  BcdLibraryString_Description, objElement
자, 이제부터 너무 흥분해서 격렬하게 반응하는 일은 없을 거라고 약속할 수 있습니까?그렇다면이제 String 속성의 값을 출력하여 컴퓨터에서 현재 사용 중인 운영 체제를 확인할 수 있다는 사실을 알려드려도 되겠군요.
Wscript.Echo "Current operating system: " _
  & objElement.String
진정하시고조금 전 했던 약속을 생각하여너무 흥분하지는 마십시오.흥분을 가라앉히기 힘들다는 것은 잘 알고 있습니다.다만 최대한 마음을 가라앉히도록 해보십시오.숨을 한번 깊이 들이쉬십시오. 저희도 BCD 스크립트를 작성하다가 너무 흥분되면 그렇게 한답니다.
앞서 설명했듯이 단지 컴퓨터에서 사용 중인 운영 체제를 확인하기 위한 것치고는 작업이 너무 복잡합니다. 같은 작업을 보다 쉽게 수행할 수 있는 방법도 많습니다.그러나 BCD 스크립트의 작동 방식을 이해하는 데는 도움이 되었으리라 생각합니다. BCD 스크립트의 작동 방식만 이해하면 이전에는 스크립트 작성자가 생각도 못했던 여러 가지 기능을 구현할 수 있습니다.(부디 진정하시길...)예를 들어 멀티부팅 컴퓨터에서 특정 운영 체제에 항상 "기본"으로 태그를 지정할 수 있습니다. 이 경우 컴퓨터가 다시 부팅될 때 누군가가 다르게 지정하지 않는다면 컴퓨터가 자동으로 해당 기본 운영 체제를 로드합니다.Windows Vista와 BCD 공급자가 개발되기 이전에는 스크립터가 컴퓨터에서 기본 운영 체제를 확인할 방법이 없었습니다.그러나 이제는 그림 2와 같은 스크립트만 실행하면 간단히 확인할 수 있습니다.
그림 2 기본 운영 체제 확인
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
어떻습니까?또 흥분되지 않습니까?하지만 흥분을 조금 자제해 주시기 바랍니다.이 스크립트를 자세히 설명하지는 않겠습니다. 위의 10~12개 단락을 제대로 읽었다면 개념은 충분히 이해할 수 있을 것입니다.단, 기본 운영 체제까지 도달하려면OpenObject 메서드를 사용하여 부팅 관리자 개체의 인스턴스를 여는 중간 단계가 필요합니다.부팅 관리자를 연 후에는 DefaultType 상수를 사용하여 기본 운영 체제를 나타내는 개체를 검색할 수 있습니다.
지금부터가 더 흥미롭습니다.이제 현재 운영 체제와 기본 운영 체제를 확인할 수 있습니다.하지만 정말 멋진 것은컴퓨터에 설치된 모든 운영 체제의 목록을 검색할 수 있다는 사실입니다.이제는 정말 흥분되는 수준이죠.자, 마음을 가다듬고 그림 3을 눈여겨보십시오.
이 스크립트는 어떤 역할을 하는 것일까요?먼저 2개의 새 상수를 정의합니다.그 중 WindowsImages는 BCD를 지원하는 모든 OS(Windows Vista 및 Windows Server 2008)의 인스턴스를 검색할 수 있도록 하고 LegacyImages는 컴퓨터의 "레거시" 운영 체제 인스턴스를 검색할 수 있도록 합니다.BCD 저장소에 연결한 후에는 EnumerateObjects 메서드를 사용하여 컴퓨터에 설치된 BCD 지원 운영 체제의 모든 인스턴스를 검색할 수 있습니다.
objStore.EnumerateObjects _
  WindowsImages, colObjects
그림 3 컴퓨터의 모든 운영 체제 찾기
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
EnumerateObjects 메서드의 작업이 끝나면 해당 컬렉션의 모든 운영 체제에 대해 반복하는 For Each 루프를 설정합니다.이 루프 내에서는 두 줄의 코드를 사용하여 운영 체제 Description을 검색하여 표시합니다.
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
그런 다음 컴퓨터에 설치된 모든 레거시 운영 체제에 대해 프로세스를 반복합니다.
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
참고 흥분되는 마음은 이해가 되지만 너무 심하게 흥분하면 인체에 해가 되므로 BCD 스크립트를 실행할 때는 주의를 기울여야 합니다.임산부나 임신할 가능성이 있는 여성, 전혀 임신 계획이 없는 여성, 예전에 임신했던 여성 또는 남성이라도 반드시 의사와 상담한 후에 BCD 스크립트를 실행하시기 바랍니다.
의사와 먼저 상담해야 한다는 말은 좀 과장된 부분이 있지만,의사에게 BCD 스크립트 실행에 대해서 문의하면 뭐라고 말할지 궁금하지 않습니까?
자, 이제 정말 말도 안 될 정도로 놀라운 작업을 시도해 보겠습니다. 기본 운영 체제를 변경할 수 있을지 한번 해보는 겁니다.예를 들어 Windows Vista와 Windows Server 2008을 모두 실행하는 이중 부팅 컴퓨터가 있다고 가정합니다.그리고 Windows Vista를 기본 운영 체제로 설정하려고 합니다.어떻게 해야 할까요?그림 4를 한번 보십시오.이 스크립트는 이 작업을 수행하는 한 가지 방법을 보여 줍니다.
그림 4 기본 운영 체제 변경
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
이 스크립트에서는 다시 한 번 BCD 저장소를 연 다음 EnumerateObjects 개체를 사용하여 컴퓨터에 설치된 모든 BCD 인식 운영 체제의 컬렉션을 검색합니다.그리고 각 운영 체제의 Description을 검색하기 위해 이제 친숙하게 느껴지는 다음 코드 줄을 사용하여 컬렉션의 모든 항목에 대해 반복하는 For Each 루프를 설정합니다.
objObject.GetElement _
  BcdLibraryString_Description, objElement
지정된 운영 체제의 Description이 검색되면 InStr 함수를 사용하여 해당 값에 Vista라는 단어가 있는지 확인합니다.
If Instr(objElement.String, "Vista") Then
맞습니다. 다소 번거로운 감이 있죠.이보다는 컴퓨터의 모든 운영 체제를 열거하고 루프를 실행할 필요 없이 Windows Vista의 GUID를 사용하여 해당 운영 체제를 바로 여는 것이 낫습니다.
아쉽게도 이 방법을 사용하려면 Windows Vista의 GUID를 알아야 합니다.그 대신 이 방법을 사용하면 다른 정보는 필요가 없습니다. (Scripting Guy에게는 좋은 보너스죠.) 이름에 Vista라는 단어가 있는 운영 체제를 찾을 때까지 검색하기만 하면 됩니다.
참고 컴퓨터에 Windows Vista의 인스턴스가 여러 개 설치되어 있으면 어떻게 될까요?이 경우 Vista Ultimate나 Vista Enterprise 같은 문자열을 검색해야 할 수 있습니다.
Windows Vista를 찾으면 다음 두 줄의 코드를 사용하여 Windows 부팅 관리자를 연 다음 기본 운영 체제를 Windows Vista로 설정합니다.
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
이번 달에 준비한 내용은 여기까지입니다. Scripting Guy도 일주일 내내 극도의 흥분 상태를 견디어 낼 수는 없으니 이정도만 하겠습니다.하지만 걱정하지 마십시오. 다음 달에 흥미로운 다른 Hey, Scripting Guy! 칼럼으로 다시 찾아뵙겠습니다.그때까지 마음을 좀 진정시켜 두시기 바랍니다.
Dr. Scripto의 Scripting Perplexer
매달 퍼즐 풀이 실력뿐만 아니라 스크립팅 능력까지 시험해 볼 수 있는 문제입니다.

2008년 7월:VBScript 정사각형
예, 제목과는 달리 정사각형이 아니라 직사각형입니다. 하지만 그건 별로 중요하지 않습니다.이 퍼즐을 풀려면 오른쪽에 있는 사각형을 왼쪽에 있는 빈 사각형에 맞추어 VBScript 함수의 이름을 만들어야 합니다.각 사각형은 한 번씩만 사용할 수 있습니다.다음은 퍼즐 풀이 예제입니다.
이 예제를 올바르게 풀려면 OU 사각형(직사각형)을 첫 단어의 빈 사각형으로 이동하고 MS와 OX를 두 번째 단어의 빈 사각형으로 이동해야 합니다.그러면 다음과 같이 VBScript 함수 UBound와 MsgBox라는 함수 이름이 됩니다.
이제 퍼즐을 풀어보십시오.

답:
Dr. Scripto의 Scripting Perplexer
답:VBScript 정사각형, 2008년 7월

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


The Desktop Files 네트워크 부팅 Windows
Wes Miller

목차
PXE의 작동 방식
RIS에 대해
WDS의 시작
기타 기능
맺음말
앞으로 몇 개월에 걸쳐 설명할 Windows 배포 서비스(WDS)는 Windows Server 2003에서 사용할 수 있으며 Windows Server 2008의 경우 기본적으로 제공됩니다.WDS는 배포 인프라에서 매우 중요한 구성 요소가 될 수 있기 때문에 앞으로 논의할 내용에 대한 기본적인 바탕이 될 요소들에 대해 먼저 설명하려고 합니다.먼저,
이 첫 번째 칼럼에서는 PXE(Preboot Execution Environment, 픽시라고 읽음)의 아키텍처와 원격 설치 서비스(RIS)의 변천사, Microsoft에서 사용하는 다른 PXE 관련 기술 등에 대해 알아 보겠습니다.
RIS는 2001년 필자가 Windows 핵심 OS 그룹으로 전직했을 때 전수 받은 기술 중 하나였는데, 그 복잡도와 BIOS 구현 및 하드웨어 종속성으로 인해 다소 사용하기 부담스럽기도 했지만Windows® PE와 함께, 프로그램 관리자로서 가장 애용했던 기술 중 하나입니다.
Windows 3.0을 처음 설치할 때 3.5" 디스켓을 사용해서 설치했던 일이 기억납니다.시간이 지나면서 일부 WIndows 98 버전에 포함된 부팅 가능 CD가 나온 덕택에 설치하기가 더 쉬워졌지만,문제는 항상 로컬 하드 디스크와 특정 유형의 로컬 미디어가 있어야만 설치가 가능하다는 것이었습니다.
이후 수년간 Windows 네트워크 부팅(하드 디스크 없이 네트워크를 통해 부팅) 기능은 많은 고객이 요청하는 사항이 되었습니다.일부 초기 Windows 버전에서는 이러한 기능이 지원되었지만 Windows NT®에는 전혀 적용되지 않았습니다.근래의 Windows Server® 2003과 Windows Server 2008 버전에서는 iSCSI 초기자를 통한 부팅이 가능하지만, 부팅 드라이브가 실제 로컬이 아니고 원격 드라이브에 계속 의존해야 한다는 점에서 프로세스가 상당한 차이가 있습니다.
클라이언트 사전 준비
  • RIS 클라이언트 사전 준비 프로세스 평가
  • 클라이언트 사전 준비를 통한 네트워크 보안 향상 계획
  • 클라이언트 컴퓨터 사전 준비
  • 원격 운영 체제 설치
Windows 2000을 시작으로, Microsoft는 네트워크 기반 설치를 가능하게 하는 기술을 개발하기 시작했으며 이것은 이름 변경을 거듭하여 최종적으로 RIS라고 불립니다.RIS의 목표는 비교적 단순한 것으로서, PXE를 사용하는 대상 컴퓨터의 로컬 디스크에 운영 체제 이미지를 로드하는 것이었습니다.

PXE의 작동 방식
그림 1은 PXE의 부팅 시퀀스를 보여 줍니다.PXE는 Intel 및 기타 공급업체가 WfM(Wired for Management) 방식의 일부로 개발한, 비교적 간단한 프로토콜입니다.PXE는 BootP에서 파생된 DHCP(Dynamic Host Configuration Protocol)에서 파생되었으며 대개 NIC(네트워크 인터페이스 카드)에 구현되어 있습니다.간단히 표현하면 다음과 같습니다.
그림 1 PXE 부팅 시퀀스(크게 보려면 이미지 클릭)
1단계 시스템 BIOS가 부팅되어 부팅 순서를 확인합니다.
2단계 PXE의 부팅 순서가 하드 디스크나 플래시 드라이브, 또는 CD-ROM 앞에 오는 경우 또는 이러한 장치가 없을 경우 NIC의 UNDI(범용 네트워크 드라이버 인터페이스)가 로드됩니다.NIC는 매우 작은 규모의 네트워크 장치 드라이버로서 TFTP(Trivial File Transfer Protocol) 구현이 특징입니다.일부 BIOS 구현에서는 PXE 부팅을 위해 사용자가 F12 키를 눌러야 하지만이는 표준이 아니며 이 기능을 비활성화할 수 있습니다.
3단계 시스템에서 간단한 UDP(User Datagram Protocol) 브로드캐스트를 시작하여 DHCP 서버를 찾습니다.이 단계는 PXE 부팅 시퀀스의 실질적인 첫 단계로서 검색(Discover) 단계라고도 합니다.여기서 UDP 프로토콜을 사용한다는 것은 PXE 통신에서 라우터와 스위치가 이를 모두 통과시키도록 조정이 필요함을 의미합니다(아직 조정하지 않은 경우).
4단계 DHCP 서버에서 브로드캐스트를 수신하면 IP 주소를 가지고 응답합니다.이 단계를 제공(Offer) 단계라고 합니다.여기서 중요한 점은 PXE가 상태 비저장 방식이이며 이 시점에서 클라이언트가 제공해야 하는 시스템 고유 상태 정보가 MAC 주소와 사용 가능한 경우 시스템 관리 BIOS GUID(SMBIOS GUID) 등과 같이 그 양이 지극히 제한적이라는 점입니다.
5단계 IP 주소가 포함된 패킷을 수신한 클라이언트가 추가 정보(PXE 서버 주소)를 요청합니다.처음 응답한 DHCP 서버의 정보를 포함한 또 다른 브로드캐스트가 시작되고클라이언트에서 DHCP 서버에 "네트워크 부팅 프로그램(NBP)의 위치 정보가 추가로 필요함"을 알립니다.이 단계를 요청(Request) 단계라고 합니다.
6단계 PXE 서버가 PXE 서버의 주소와 NBP(32KB 미만의 아주 작은 부팅 실행 파일)의 위치를 가지고 응답합니다.이 단계를 승인(Acknowledge) 단계라고 합니다.이 단계까지 오면서 이미 떠올렸을지 모르겠지만 각 단계의 머리글자어를 딴 DORA(Discover, Offer, Request, Acknowledge)를 생각하면 이러한 단계를 쉽게 기억할 수 있습니다.
Microsoft DHCP와 WDS를 설치한 경우(또는 일부 다른 공급업체의 기술을 사용할 경우)에는 실제로 요청 단계가 발생하지 않고 DHCP 서버가 처음에 제공한 패킷에 이미 PXE 서버와 NBP 프로그램의 위치가 포함되어 있습니다(따라서, 이 두 단계와 그에 따른 시간이 생략됨).
7단계 앞서 언급한 소규모 TFTP 프로토콜 스택이 있는 클라이언트가 PXE 서버에서 지정한 네트워크 위치에서 NBP를 다운로드합니다.TFTP는 상태 비저장 방식의 매우 작은 규모의 프로토콜로서 오래 전에 소개되었습니다.TFTP는 보안이나 성능 측면에서 선택된 것이 아니기 때문에 많은 라우터 관리자들이 기본적으로 이 기능을 비활성화하고 있지만PXE가 작동하게 하려면 활성화해야 합니다.
RIS를 비롯한 많은 PXE 구현에는 이 시점에서 사용자가 F12 키를 눌러 계속할 수 있도록 하는 기능이 포함되어 있지만 일반적으로 PXE 서버 관리자가 이를 비활성화할 수 있습니다.다음 달에 WDS에 대해 자세히 설명할 때 Microsoft에서 Windows Server 2008의 WDS에 포함한 TFTPD(TFTP Daemon)를 통해 향상된 몇 가지 성능에 대해 알아보기로 하겠습니다.
8단계 NBP가 초기화됩니다.RIS의 경우 배포 프로세스를 시작하는 Windows 부팅 로더가 시작됩니다.PXE(실제 부팅 수준 이상의 프로토콜)는 이제 이 프로세스의 구성 요소가 아닙니다.
RIS, WDS 또는 다른 모든 인프라를 막론하고 PXE는 느린 링크(대량의 데이터를 전송하는 경우가 있음)나 위성과 같은 고지연 링크(통신이 잘 수행되지 않으며 연결 유지조차 어려움)을 통해 제대로 작동하지 않는다는 점을 기억해야 합니다.
PXE 부팅 프로세스에서, 클라이언트가 요청을 보낼 때 다른 서버가 상위인지 여부를 묻는 사항이 없다는 것을 알 수 있는데,이는 어느 방향으로든 파악할 PXE 서버 상태 정보가 그리 많지 않기 때문입니다.이로 인해 일반적으로 경합 상태가 발생하게 되는데, 이 경우 클라이언트 요청에 맨 처음 응답하는 서버 쪽이 먼저 처리됩니다.다음과 같은 몇 가지 방법으로 이러한 문제의 발생을 줄일 수 있습니다.
  • PXE 서버나 다른 서버의 응답 속도를 조정합니다.네트워크 대기 시간과 서버 성능은 서버의 응답 속도에 영향을 줍니다.실제로, Microsoft에서는 Microsoft IT 부서에서 사용하는 서버가 매우 뛰어나서 PXE 서버가 작업자의 사무실에 있는 경우라도 이 IT 서버가 경합에서 이기곤 했습니다.이 경우 작업자는 사전 준비 클라이언트를 설정하여 로컬 PXE 서버에 시간 초과가 발생하지 않도록 하면 됩니다.
  • 클라이언트에서 사전 준비를 수행합니다.작업자의 PXE 서버가 다른 기업용 IT 서버보다 먼저 응답하도록 조정하려면 이 작업은 매우 중요합니다.클라이언트를 사전에 준비함으로써 Active Directory®에서 상위 서버임을 WDS나 RIS에 알리도록 할 수 있습니다.Active Directory에서 시스템의 고유 식별자로 SMBIOS GUID를 사용하는 것이 훨씬 좋지만 SMBIOS GUID가 시스템에 구현되지 않은 경우에는(대개 구형 하드웨어) MAC 주소에 기반한 GUID를 사용할 수 있으며 그래야 합니다.자세한 내용은 보충 항목 "클라이언트 사전 준비"를 참조하십시오.
  • PXE 통신이 스위치나 라우터를 방해하지 않도록 PXE 서버를 각 측에 배치합니다.이 방식은 서버가 각기 고유한 이미지를 유지해야 하므로 구현과 유지 모두에 비용이 많이 든다는 단점이 있습니다.
Microsoft DHCP 서버와 같은 RIS(현재 WDS) 서버는 연결된 Active Directory 구현에 대해 인증받아야 합니다.이는 Rogue PXE 서버가 Active Directory에 이러한 서버를 모두 인식시켜 발생할 수 있는 문제점(예: PXE 브로드캐스트 스톰)을 줄이기 위한 것입니다.
하지만 Active Directory에서 인식된 서버에 대해서만 이러한 보호가 적용되며고유 도메인이나 Microsoft 이외의 PXE 서버를 설치한 경우에는 해당하지 않습니다.
Microsoft에서 지나치게 열정적인 한 직원이 "완전 자동" 배포되는 RIS 이외의 PXE 서버를 구성한 적이 있습니다.이 구현은 하드 디스크를 완전히 지우고 새 이미지를 로드하는 방식으로 작동했습니다.이 배포가 네트워크와 단절된 연구실 환경에서 수행되었다면 좋았겠지만 불행히도 그렇지 못했고 부팅 순서에서 하드 디스크보다 PXE가 우선 설정되어 있던 한 Microsoft 임원의 디스크를 삭제하는 결과를 초래하게 되었습니다.
사실 Microsoft IT 부서에서는 PXE 부팅을 사용하려면 항상 F12 키를 눌러야 했기 때문에 이전까지는 문제가 발생하지 않았지만, 이 PXE 서버는 그러한 일체의 지연 없이(F12 메시지나 어떤 알림 메시지도 없이) 작동하고 말았습니다.그 임원은 사실상 컴퓨터를 잃어버린 것과 같았으며 따라서 어떠한 데이터도 로밍 사용자 프로필로 보호되지 못했습니다.
이 이야기를 염두에 두어 "완전 자동" 방식 또는 적어도 F12 키를 눌러야 하는 방식을 사용할 때는 PXE 서버 격리의 필요성을 떠올리십시오.

RIS에 대해
필자는 Windows 2000이 채용된 후에 RIS를 인계 받았습니다.RIS에 관한 한 Windows 2000은 많은 우여곡절을 겪어 테스팅, 성능 및 기타 제약 조건으로 인해 Windows 2000 Professional 배포에만 사용되는 Windows Server 2000용 RIS가 나타나게 되었습니다.안타깝게도 서버 제품은 RIS를 통해 배포할 수 없었습니다.x86 시스템에서만 Windows 2000을 사용할 수 있어서 아키텍처 하나에 제품 하나가 관련되는 특징 덕분에 RIS에 대한 좋은 시험대가 되었습니다.RIS는 Active Directory와의 완전한 통합이 필요했고, 실제로 이를 포함했으며, Microsoft DHCP 서버와 훌륭하게 통합되었고 고유 TFTPD를 포함했습니다.
RIS는 NBP를 사용하여 TFTP 다운로드를 계속하며 설치 프로세스를 시작할 수 있도록 Windows 커널을 다운시킵니다.특정 시점에 Windows가 TFTPD에서 서버 메시지 블록(SMB) 기반의 서버 연결로 전환되고 나면 Windows 2000 또는 Windows XP의 기존 플로피 디스크 시작 설치와 리터럴 코드 경로가 실제로 공유됩니다.기본 모드 Windows가 초기화되고 나면 Windows 설치에서 RIS OS 선택기(OSC) 마법사를 시작합니다.
OSC 화면은 일부 구성이 가능한 HTML 2.0과 비슷한 페이지로서제약이 심하고 이미지 등을 포함할 수 없습니다. 실제로, ANSI 외의 문자를 포함할 수 없기 때문에 Windows의 특정 로캘 배포를 복잡하게 만드는 요소이기도 합니다.
RIS는 최종적으로 RIS 서버에서 txtsetup.sif 파일을 생성합니다.OSC 마법사가 완료되면 클라이언트가 "소프트 재부팅"되지만 소프트 재부팅 뒤에도 RIS 서버와 txtsetup.sif 파일의 위치가 그대로 보존되어 다시 로드됩니다.이 txtsetup.sif 파일은 unattend.txt 파일과 기본적으로 동일하며, RIS의 설치 프로세스 완료를 지원하는 몇 가지 필드가 추가로 포함되어 있습니다.
그 밖에도 RIS는 기존 무인 설치(RISetup)와 매우 흡사한 설치를 수행할 수도 있고 Sysprep(RIPrep)과 유사한 복제 기반 인프라를 갖고 있으며 실제로 그와 코드를 공유했습니다.단, RIPrep의 경우 RIS 서버에 자신의 이미지를 업로드할 수도 있었습니다.
물론 RIS에는 몇 가지 명백히 드러난 근본적인 한계가 있었는데,그 첫 번째가 서버 배포를 지원하지 않는다는 점입니다.Code Red, Sasser와 같은 익스플로잇은 다수의 주요 고객이 9/11 직후 복구 과정에서 겪은 IT 복잡성과 함께 Microsoft가 기존 Windows 2000 RIS 서버에서 Windows Server 배포를 가능하게 하는 솔루션을 서둘러 개발하게 된 계기가 되었습니다.이것은 Windows Server 2003용으로 개발하던 것이었지만 그 이전까지는 정식으로 출시되지 않았습니다.
PXE 관련 기술 상세 정보
  • PXE 클라이언트, DHCP, RIS 서버 간 PXE 상호 작용 설명
  • PXE 시작 방식 운영 체제 배포 계획
  • PXE 아키텍처
  • 원격 설치 서비스
  • 원격 운영 체제 설치
  • 단계별 원격 OS 설치 가이드
  • WDS PXE 공급자
  • 원격 설치 서비스란?
  • Windows Server 2003 Automated Deployment Services
둘째로, RIS는 OSC 마법사를 완전히 자동화하는 기능이 없었으며 이 기능은 나중에 Windows Server 2003에서 <META ACTION="AUTOENTER"> 요소를 통해 사용할 수 있게 되었습니다.끝으로, OSC는 ANSI 외의 문자로는 제대로 작동하지 않았으며 이것은 미국 외 몇몇 고객들이 지적한 주요한 단점이었습니다.
예를 들면, 프랑스어로 된 키보드로 RIS 설치를 완료할 수 없었습니다.ANSI 외의 문자가 전 세계 PC의 BIOS 수준에서 안전하게 작동하도록 하는 작업은 매우 복잡했고 달성하기 어려운 과제였습니다.
Windows Server 2003에 이르러서야 공식적으로 Intel Itanium 아키텍처와 함께 Windows 2000 및 Windows Server 2003의 모든 서버 유형을 추가로 지원하게 되었습니다.Windows Server 2003은 x64 아키텍처에 대한 지원으로 한 걸음 더 나아갔습니다.
또한 RIS는 성능 향상을 위해 상당 부분 다시 작성된 TFTPD를 사용하게 되었습니다.Windows Server 2003은 최대 75대까지 클라이언트 동시 부팅을 지원하며, 여기서 이 상한선은 SMB 파이프가 클라이언트에 대한 네트워크 트래픽으로 가득 찰 때 도달하게 됩니다.

WDS의 시작
"Longhorn"(Windows Server 2008의 코드명)용 RIS 작업을 시작했을 때 한 걸음 뒤로 후퇴할 필요성이 명백해졌습니다.이전에 필자의 칼럼에서 언급했듯이 우리는 이미 Windows PE의 WIM(Windows 이미지) 기반 설치에 많은 투자를 했기 때문에WDS의 기반 핵심 원리는 Windows PE의 PXE 부팅 인스턴스로부터의 이미지 기반 배포 방식을 따르게 되었습니다.
우리는 Windows Server 2003이 Windows Vista®를 배포하는 일반적인 플랫폼이 될 것과 WDS 하위 수준용 "대역 외" 솔루션이 필요할 것이란 사실을 알고 있었습니다.그 결과 WDS를 Windows Server 2003 SP1에서 실행할 수 있게 되었고 Windows Server 2003 SP2에 기본 제공하게 되었습니다.
RIS 서버(레거시 모드), 혼합형 서버(혼합 모드) 또는 WDS 전용 서버(기본 모드)로서 작동할 수 있으므로 WDS를 사용하면 보증되는 공식 WDS식 배포로 마이그레이션할 수 있습니다.Windows Server 2003 SP2 시스템에 RIS를 설치하는 방법이 있는지에 대한 고객의 문의가 들어옵니다.네, 방법이 있습니다. WDS를 설치하고 레거시 모드로 실행하면 됩니다.그림 2는 지원되는 운영 체제를 보여 줍니다.
그림 2 배포 지원 플랫폼
운영 체제 | RIS(Windows 2000) | RIS(Windows Server 2003)** | WDS(Windows Server 2003)**** | WDS(Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X(x86 및 IA64)*** | X | X
Windows Server 2003 |  | X(x86 및 IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508과 support.microsoft.com/kb/313069에서 RIS를 통한 Windows 2000 Server 지원이 추가되었습니다. ** WDS 레거시 및 혼합 모드에서 레거시 설치에 이와 동일한 매트릭스를 지원합니다. *** Windows Server 2003 SP1에서 x64 기반 시스템에 대한 지원이 추가되었습니다.IA64 시스템에서는 RISetup 기반 설치만 지원됩니다. **** 기본 모드를 지원합니다.
Windows Server 2003 SP1과 SP2에서 WDS는 WDS로의 마이그레이션 프로세스 시작을 모색했습니다.앞서 언급했듯이, Windows Server 2008에서는 수정된 TFTPD와 EFI(Extensible Firmware Interface) 부팅 지원 그리고 멀티캐스트 기반 배포가 WDS 핵심 기능으로서 추가되었습니다.

기타 기능
ADS(Automated Deployment Services)는 신속한 서버 프로비전을 주된 목적으로 하여 Microsoft 내부의 또 다른 팀에서 구축했습니다.ADS는 공식 섹터 기반 이미징, 고유 부팅 에이전트(Windows PE보다 작으며 일부 기능만 작동), 고유 TFTPD, 고급 멀티캐스트와 같은 기능을 제공했습니다.ADS에 기본 제공된 기능은 완벽히 동일한 기능이라고는 할 수 없지만 SCCM(System Center Configuration Manager)에서 상당 부분 사용할 수 있게 되었습니다.﻿
Windows XP Embedded에는 고유 TFTPD를 통해 RAMDisk로의 전체 PXE 부팅 기능이 있었지만 이 방식으로는 원격 배포가 불가능했습니다.이 기술은 PXE를 통해 하나의 디스크 이미지로부터 많은 시스템을 동시에 부팅할 수 있도록 개발되었습니다.

맺음말
간단하게 이러한 변천사를 겪었습니다.자세한 내용은 "PXE 관련 기술 상세 정보"를 참조하십시오.다음 달에는 WDS의 기초에 대해 설명한 뒤 멀티캐스트를 비롯한 WDS 고급 기능에 대한 칼럼으로 넘어가려고 합니다. 그리고 WDS를 사용하지 않고 WDS를 사용하는, 즉 기존 WDS/설치 환경을 뛰어 넘어 고유한 배포 기술을 사용하는 방법으로 연재를 마무리할 계획입니다.

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


Security Watch 암호와 신용 카드 - 제1부
Jesper M. Johansson

목차
실용성 없는 보안 권장 사항
실용성 없고 잘못된 권장 사항
납득하기 어려운 권장 사항
이미지 기반 사이트 인증의 보이지 않는 함정
필자는 최근 미네소타 주립대학의 학보에 실릴 기사 인터뷰 요청을 받았습니다.학교 측에서는 당연히 성공한 동문의 이야기를 싣고 싶어했지만 적절한 인사를 찾지 못했던 걸까요. 미력한 저에게 넘어오게 되었습니다.인터뷰 진행자는 저의 업무 분야에 대해 물어 보았고 저는 몇 분에 걸쳐 보안
인프라 소프트웨어에 대한 설명을 하고 있었습니다.그러자 인터뷰를 진행하던 그녀가 "너무 복잡한 얘기 같아요!저한테 보안이라 하면 암호와 신용 카드만 떠오르는 걸요."라고 소리치는 것이었습니다.
저는 이러한 반응에 잠시 동안 생각하다가 그녀가 사실 매우 좋은 점을 지적해 주었다는 사실을 깨달았습니다.보안이라는 건 사실 암호와 신용 카드에 대한 것이 맞습니다.최소한 최종 사용자에게는 이 이야기가 그대로 해당됩니다.업계에 종사하는 보안 전문가들이 생각하는 보안이란 암호화 알고리즘입니다. 여기에는 Kerberos가 TLS 또는 NTLMv2보다 더 나은지, WS*의 이점은 무엇인지, 암호 해시를 솔트해야 하는지를 비롯하여 보안 전문가들이 논의하기 좋아하는 기타 심오한 모든 주제들이 포함됩니다.물론 이러한 전문가들은 최종 사용자에 비해 다양하고 심층적인 견해를 갖고 있습니다. 그러나 대체적으로 전문가들이 놓치고 있는 가장 근본적인 한 가지가 있다면서비스 제공 대상인 최종 사용자에게 있어 보안이란 암호와 신용 카드에 대한 것이라는 점입니다.
맞습니다. 보안 전문가들이 논쟁을 벌이기 좋아하는 심오한 문제도, 개발하기 좋아하는 새로운 기술도 사실 알고 보면 모두 최종 사용자의 데이터를 보호하기 위한 것입니다.하지만 보안 전문가들은 아직도 올바른 방향을 잡지 못하고 있는 것 같습니다.IT 세계의 보안 전문가들은 해당 고객들의 특정 요구 사항을 지원하기 위해 존재합니다. 이 요구 사항이란 바로 데이터를 안전하게 보존하는 것입니다.여기에는 물론 IT 자산을 안전하게 활용하는 것 역시 포함됩니다.이것은 정말 중요합니다.
필자는 이전 칼럼에서 바이러스 백신 프로그램을 실행하기 위해 컴퓨터를 구입하는 사용자는 하나도 없음을 지적한 바 있습니다.사용자는 온라인 뱅킹을 이용하고, 컴퓨터 게임을 즐기고, 전자 메일을 작성하고, 과제를 수행하고, 기타 중요한 업무를 수행하기 위해 컴퓨터를 구입합니다.이와 마찬가지로 회사의 경우에도 단순히 NTMLv2 구현을 위해 IT 보안 부서에 투자하지는 않습니다.회사에서 IT 보안 부서에 투자하는 이유는 조직의 자산을 보호하여 전체 사업부에서 해당 IT 리소스를 안전하게 사용하고 비즈니스 목표를 달성할 수 있도록 하기 위함입니다.
보안 전문가의 역할은 올바른 서비스를 제공하는 것입니다.
그렇다면 필자는 오늘날의 보안 전문가들이 정말로 훌륭한 "서비스"를 제공하고 있는지 질문을 던지고 싶습니다.보안 전문가들이 도움이 되기보다는 실제로 방해가 되고 있지는 않을까요?또한 입법 관련자들이나 규정자들이 보안 전문가들이 방해가 되고 있는 데 일조를 하고 있지는 않은가요?필자는 현재 적용되고 있는 모든 최신 기술이 실제로 최종 사용자에게 유용한지에 대해 의문을 가지고 있습니다.따라서 전 세계 IT 공급업체가 실제로 도움이 되기보다 해를 끼치는 몇몇 부분에 대해 알아보도록 하겠습니다.
보안 전문가들이 제공하는 대부분의 보안 권장 사항 및 많은 보안 기술이 실용적이지 않거나, 잘못되었거나, 납득하기 어렵거나, 이 세 가지가 한꺼번에 뭉뚱그려진 상태(대부분의 경우)인 것처럼 보이는 경우가 더러 있습니다.본 3부작 시리즈에서는 이러한 세 가지 잘못된 사항 중 한 가지 이상에 해당하는 권장 사항을 알려 주거나 기술을 배포하여 사용자에게 혼란을 야기한 사례에 대해 알아보려고 합니다.

실용성 없는 보안 권장 사항
보안 전문가들이 사용자를 혼란스럽게 하는 가장 주된 요인 중 하나는 바로 실용성 없는 보안 권장 사항을 제공하는 것입니다.여기에 보너스로, 보안 전문가가 이러한 권장 사항을 잘못 만들기도 합니다.그림 1에서는 보편적으로 제공되어 왔으며 오랜 사용을 거쳐 검증되고 이론적으로 문제없는 것처럼 보이지만 전혀 유용하지 않은 권장 사항을 보여 줍니다.
그림 1 실용성 없는 보안 권장 사항 (더 크게 보려면 이미지를 클릭하십시오.)
보유하고 있는 각 온라인 계정마다 다른 암호를 사용하라는 부분이 보이십니까?이런 권장 사항은 30년 전에나 통하던 얘기입니다.인터넷을 사용하는 사람들의 수가 몇백 명 정도에 불과하고 특별히 좋은 암호를 선택하는 사람이 없던 그런 시절 말입니다.안타깝게도 이러한 권장 사항은 계속 유지되고 되풀이되고 있습니다. 뿐만 아니라 이를 오늘날의 컴퓨터 사용 실태에 맞게 조정하려는 노력이 전혀 보이지 않고 있습니다.
현재 몇 개의 온라인 계정을 보유하고 계십니까?필자는 개인적으로 115개의 계정이 있으며 이 중에는 아무런 관리 없이 주고받은 계정도 몇 개 있습니다.그림 1의 권장 사항에 따르자면 필자는 115개의 암호를 만들어야 하고 그것도 매번 30일에서 60일마다 변경해야 합니다.바꿔 말하면 매일 2~4개의 암호를 변경해야 한다는 말이 되는 것입니다.수학적으로 설명하자면일 년에 690~1380개의 암호를 사용하는 꼴이 됩니다.
이러한 권장 사항을 제공하는 일부 사이트의 기술 담당자라면 매일 4개씩 좋은 암호를 생각해 내고 115개의 현재 암호를 단기 메모리에 저장할 수도 있겠지만, 아마 99.99%의 일반 웹 서핑 사용자들은 이러한 작업을 절대로 감당할 수 없을 것입니다.
30~60일마다 모든 암호를 변경하도록 하는 권장 사항과 마찬가지로 모든 사이트마다 다른 암호를 사용하도록 하는 권장 사항도 순수하게 이론적인 관점으로 보면 사실상 일리가 있고 문제가 없습니다.그러나 실제로는 이러한 방법이 실용적이지 않습니다.오늘날 사용자들이 보유하고 있는 암호의 개수를 고려할 때 모든 암호를 종이에 기록해 두거나 특정 소프트웨어를 설치하여 도움을 받지 않는 한 이 권장 사항을 그대로 따를 수 없습니다.다음 사례로 넘어가 보겠습니다.

실용성 없고 잘못된 권장 사항
그림 2에 표시된 권장 사항은 세계적으로 규모가 가장 큰 은행의 웹 사이트에서 발췌한 것으로, 실용성이 없을 뿐만 아니라 잘못되기까지 한 사례입니다."Read our password advice(암호 권장 사항을 숙지해 주십시오.)"라는 제목 아래에는 "different passwords everywhere(모든 사이트마다 다른 암호 사용)"라는 문구가 있습니다.뿐만 아니라 "never write them down(절대 암호를 적어 두지 마십시오.)"이라는 권장 사항도 있습니다.
그림 2 실용성 없고 잘못된 권장 사항 (더 크게 보려면 이미지를 클릭하십시오.)
자, 이제 필자에게는 115개의 암호가 있으며, 매일 4개의 암호를 새로 만들어야 하고, 이것을 따로 적어 놓아서도 안 됩니다.잠시 필자는 암호를 다 기억하지 못하는 자신이 바보라고 느껴졌습니다.그러나 다른 사람도 이와 마찬가지라는 점을 깨달았습니다.사람은 115개의 암호를 쉽게 기억해낼 수가 없습니다.우리는 정보를 7개의 덩어리로 기억하고 처리할 수 있습니다. 이것이 인간의 프로그래밍 방식이기 때문이지요.인터넷에서 찾을 수 있는 대부분의 암호 권장 사항에 따르면 인간의 처리 능력으로는 암호를 한 개만 사용하는 경우에도 사실상 부족하다는 결론이 나옵니다. 자세한 내용은 "The Magical Number Seven, Plus or Minus Two:Some Limits on Our Capacity for Processing Information"(George A. Miller 지음, musanim.com/miller1956에서 확인할 수 있음)을 참조하십시오.
매우 안타깝게도 보안 업계에서는 암호에 대한 권장 사항을 통해 일반적으로 사용자를 잘못된 방향으로 이끌고 있습니다.보안 전문가들이 사용자에게 모든 사이트마다 다른 암호를 사용해야 한다고 권장할 경우에는 사용자에게 이러한 암호를 기록하고 안전한 다른 곳에 보관하는 방법에 대해서도 알려 주어야만 합니다.사용자는 암호를 종이에 직접 적어 두거나, 안전한 문서에 기록해 두거나, PasswordSafe(sourceforge.net/projects/passwordsafe)와 같은 전문 도구를 사용하여 보관해야 합니다.보안 전문가들도 모두 암호를 기록해 두거나 모든 사이트에서 동일한 암호를 사용하고 있는 것이 현실입니다.사실 최근 설문 조사에 따르면 88%의 사용자가 인증이 필요한 모든 시스템에서 동일한 암호를 사용하고 있다는 결과가 나왔습니다(msnbc.msn.com/id/24162478 참조).
암호를 적어 두지 말라는 권장 사항이 이러한 추세에 영향을 미치는 분명한 요인입니다.보안 전문가들이 사용자에게 알려야 할 사항은 암호 및 기타 중요한 데이터를 효율적으로 관리하는 방법이지 이러한 정보를 아예 관리하지 말라는 것이 아닙니다.사용자가 정보를 관리할 수 있게 되면 자격 증명이 손상되는 경우도 매우 적어질 것입니다.

납득하기 어려운 권장 사항
처음 소개한 두 개의 그림에서는 6, 70년대 및 80년대에나 통하던 낡은 방법이 반복적으로 사용되고 있음을 보여 주었습니다. 그 당시는 주요 사용자들이 온라인이나 웹 기반 서비스를 사용하지 않는 시대였지요.그때까지만 해도 이러한 권장 사항이 일반적으로 현명한 방식으로 받아들여졌기 때문에 이에 대해 큰 불평을 하는 사람은 없었습니다.
그러나 이러한 권장 사항은 사용자에게 혼란을 주며 어딘가에 암호를 저장해 두는 것에 대해 일말의 죄책감마저 들게 합니다.보안 전문가들이 이런 권장 사항을 제공하는 것은 사용자의 편의를 도모하는 것이 아니라 오히려 해를 끼치는 것입니다.사용자의 보안을 관리하는 방법을 찾아내는 것은 사용자의 몫이 아닙니다.그것은 바로 보안 전문가에게 달린 문제입니다.보안 전문가는 사용자가 보유한 모든 온라인 계정을 관리할 수 있는 적절한 해법을 찾아내야 합니다.그러나 대부분의 지침이 이러한 구시대적인 권장 사항을 되풀이하는 것이기 때문에 사용자들은 스티커 메모나 스프레드시트에 다량의 암호를 기록하여 관리하는 성가신 방법에 의존하고 있습니다.
암호는 하나의 인증 메커니즘으로서 많은 것을 제공합니다.그러나 암호의 가장 주된 문제는 사용자가 암호를 잊어버릴 수 있다는 점입니다.사람의 자연적 한계를 해결하려는 노력 대신 IT 업계에서는 암호를 바꾸거나 더 악화시키는 방법인 암호를 늘리기 위한 모든 종류의 새로운 메커니즘을 지속적으로 개발하고 있습니다.이러한 방법은 사용자를 더욱 혼란스럽게 할 뿐입니다.
필자는 지난 번 어느 금융 서비스 사이트에 방문했다가 로그온 화면에 사용자 이름 텍스트 상자만 덩그러니 표시된 것을 보고 놀라움을 금치 못했습니다(그림 3 참조).
그림 3 암호는 어디에 입력해야 할까요?
처음에는 웹 사이트에 악성 코드가 심어져 있는 줄 알았습니다.그리고 재빨리 사이트를 확인해 본 결과 제대로 된 사이트가 맞다는 걸 깨달았습니다. 사이트에서 인증서를 제공했으므로 간단히 확인할 수 있었지요.문제는 사람들이 사이트에 로그인할 때 사용자 이름과 암호를 입력할 수 있는 두 텍스트 필드가 함께 표시되는 화면에 익숙해져 있다는 것입니다.수년간 이런 공통적인 워크플로가 사용되어 왔습니다.그런데 어느날 갑자기 사용자 이름 하나만 물어보는 사이트가 있다고 생각해 보십시오. 순간 잠시 망설이게 될 것입니다.이 사이트의 경우 나중에 알고 보니 해당 서비스 업체에서 피싱 공격을 방지하기 위해 사진을 사용하여 사용자에게 사이트를 확인시키는 기술을 구현했던 것으로 밝혀졌습니다.이 기술의 취지에 따라 사용자 이름을 입력하면 그림 4와 같이 확인을 위한 사진이 사이트 화면에 나타납니다.
그림 4 최근 일부 사이트의 경우 사용자에게 사이트를 인증하기 위해 이미지를 사용함(더 크게 보려면 이미지를 클릭하십시오.)
이 이론은 사용자가 어떤 사이트에 어떤 이미지가 표시되는지 알고 있다는 것을 전제로 합니다.만약 올바른 이미지가 표시되지 않을 경우 사이트가 위조된 것인지 확인할 수 있습니다.이 방식은 그 자체만 보면 일리가 있는 개념입니다.사용자가 어떤 사이트에 어떤 이미지가 나오는지 알고 있다는 가정을 전제로 한다면 이 전략은 꽤나 훌륭하다고 할 수 있습니다.
물론 눈치 빠른 독자 여러분께서는 그림 4의 초록색 주소 표시줄을 눈여겨보셨을 겁니다.이것은 이 사이트가 SSL 및 EV(확장 유효성) 인증서를 사용하는 사이트임을 나타내며 따라서 주소 표시줄이 초록색으로 표시되는 것입니다.이는 곧 이미지를 사용하여 사이트를 확인한다는 대전제가 더 이상 특별한 가치가 없음을 의미하기도 합니다.오히려 이미지로 인해 일부 최종 사용자에게 혼란을 가중시킬 수도 있습니다.이 사이트는 이미 사용자에게 확인이 된 상태입니다. 회사 이름, 웹 사이트 주소, 신뢰할 수 있는 발급자 이름이 포함된 인증서를 제공하고 있기 때문입니다.게다가 주소 표시줄이 초록색으로 표시된다는 사실은 이 회사가 EV 인증서를 위해 3배 이상의 비용이 드는 별도의 단계를 수행했음을 알려 줍니다.
게다가 사진 역시 조작될 수 있습니다.사용자가 본인의 고유 사진을 제출할 수 있는 경우 공격자는 여러 가지 방법을 통해 어떤 이미지가 사용되는지 알아낼 수 있습니다.또한 해당 사용자가 모든 사이트에서 같은 사진을 사용할 가능성도 매우 큽니다. 이 경우 모든 공격자는 사용자가 관심 있어할 만한 콘텐츠가 포함된 사이트를 만든 후 - 이 예제는 스스로 생각해 보도록 할 것입니다. - 사용자에게 사이트 확인에 사용할 사진을 요청합니다.사용자가 모든 사이트에서 동일한 사진을 사용하는 경우 이 새로 만든 사이트는 사용자가 은행 등의 사이트에서 사용하는 이미지에 액세스하게 됩니다.
일부 사이트에서는 사용자에게 사용자 고유의 이미지를 선택하도록 하지만, 다른 사이트에서는 대중 사진 라이브러리를 사용하기도 합니다.예를 들어 그림 4에 표시된 사이트의 경우에는 선택할 수 있는 318개의 대중 사진이 있습니다.사용자가 자신의 고유 사진을 제출할 수 없는 사이트에서는 앞서 이야기한 수법이 통하지 않습니다. 그러나 사용자가 고유 이미지를 선택할 수 없다면 자주 방문하지 않는 사이트의 경우 그 사이트에 어떤 사진을 사용했는지 잊어버릴 수가 있습니다.필자는 솔직히 그림 4에 있는 사이트에 어떤 사진을 사용했는지 전혀 기억이 나지 않습니다. 스크린샷에 보이는 저 사진이 아닌 것만은 분명하지만 말입니다.
이러한 이미지 기반 사이트 인증의 문제점은 공격자가 318개의 사진 중 아무 사진이나 보여 주거나 Flickr에서 무작위로 사진을 선택할 수 있으므로 많은 사용자들이 막연히 이러한 이미지를 맞는 것으로 생각할 수 있다는 점입니다.많은 사람들이 어떤 사이트에 어떤 사진을 사용했는지와 같은 사항을 모두 기억한다면 오늘날의 피싱이나 보안 관련 문제는 일어나지도 않았을 것입니다.
그렇다면 이미 인증서를 통해 인증된 사이트에서 사진을 사용하여 사용자에게 사이트를 인증하는 이유는 무엇일까요?간단하게 인증서만 사용하고 사용자에게 이러한 인증서의 유효성 검사 방법을 알려 주는 것만으론 안 되는 걸까요?인증서는 그 자체로 이미 해당 사이트의 정체성을 사용자에게 검증해 주는 역할을 하니까요.
인증서를 받는 프로세스는 사용자의 사이트 인증 이미지를 받는 프로세스보다 훨씬 안전합니다.인증서가 EV 인증서이고 Internet Explorer® 7 또는 Firefox 3을 사용하는 경우에는 브라우저의 주소 표시줄에 관련 인증서 정보도 강조 표시됩니다.그러나 아쉽게도 이러한 강조 표시 기능은 고가의 EV 인증서에서만 작동합니다.

이미지 기반 사이트 인증의 보이지 않는 함정
사진 인증 기술은 여러 가지 문제점을 안고 있습니다.우선 사이트에서 사용자 이름을 수집하는 것이 무척 쉽다는 점입니다.잘못된 사용자 이름을 입력할 경우 그림 4의 사이트에는 그림 5와 같은 메시지가 표시됩니다.비밀 이미지를 선택한 사용자에 해당하는 사용자 이름을 올바르게 입력하면 이 사용자의 비밀 이미지를 볼 수 있습니다.당연히 이러한 정보는 공격자가 사용자에 대한 정보를 수집하려고 할 때 매우 유용하게 사용될 것입니다.
그림 5 사용자 이름을 손쉽게 수집할 수 있는 이미지 인증 사이트
여기에 나온 방법들은 사실 보안상 효과적이지 않습니다.공격자는 위조 사이트에서 간단히 로그온 워크플로를 복제할 수 있습니다.위조 사이트에서는 사용자 이름을 요청하고 이를 실제 사이트에 전달합니다.보다 멋진 디자인을 위해 실시간으로 양식을 업데이트할 수 있도록 클라이언트에 AJAX를 사용하기까지 하는 보안 관리자도 있습니다.더군다나 실제 사이트에서 로그온 양식에 대한 사이트 간 요청 위조 공격을 방지하지 않고 브라우저에서도 사이트 간 XML-HTTP 요청을 방지하지 않는 경우 AJAX 코드는 해당 요청을 실제 사이트에 바로 제출해 버릴 수도 있습니다.
이를 통해 비밀 사진이 표시되면 공격자가 데이터를 구문 분석하여 사진을 빼내온 다음 최종 사용자에게 표시합니다.다시 말하면 위조 로그인 사이트를 사용자에게 표시할 수 있는 공격자라면 누구나 사용자의 비밀 사진도 표시할 수 있습니다.결론적으로, 이미지 기반 사이트 인증은 아무런 득이 없다고 할 수 있습니다.이러한 사진은 사용자가 사이트에 대해 인증을 받기 전에 표시되므로 사용자 이름을 갖고 있거나 수집할 가능성이 있는 공격자도 해당 사진을 볼 수 있습니다.
양식을 제출하기 전에 인증서를 확인하는 법을 전혀 알지 못하는 사용자가 있다고 가정할 경우(이는 이미지 기반 사이트 인증 사용 자체가 이와 동일한 가정을 기반으로 한다고 간주할 때 매우 안전한 가정임), 이 사용자의 사용자 이름을 수집하는 것은 매우 간단합니다.또한 많은 이미지 기반 사이트 인증 스키마는 유효한 사용자 이름과 유효하지 않은 사용자 이름에 각각 다르게 응답하므로 사용자 이름을 수집하기가 쉽습니다.공격자는 공격을 시작하기도 전에 대역 외 방식으로 사용자 이름을 수집할 수 있습니다.
결국에 사용자들 중에는 보안이 강화되었다고 생각하는 사람도 있지만 더 혼란스러워하는 사람도 있습니다.이미지 기반 사이트 인증을 구현하는 데 막대한 비용을 들였지만 최종 사용자가 위조 웹 사이트에 자격 증명을 제출하도록 유인하는 악의적인 사용자를 막는 데는 별다른 도움이 되지 못했습니다.
이번 호 Security Watch는 여기서 마치도록 하겠습니다.다음 달에 연재되는 이번 시리즈의 제2부에서는 잘못된 보안 관행 및 바람직하지 않은 인증 구현 방식에 대한 사례를 추가로 더 알아보겠습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서,MIS 분야 박사 학위를 취득했고 보안 분야에서 20년 이상의 경력을 보유하고 있으며 엔터프라이즈 보안 분야의 Microsoft MVP입니다.최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.


Field Notes 선거의 정확성 확보
Josh Benaloh

올해 미국 대통령 선거에서는 투표 기술에 대중의 관심이 쏠리고 있습니다.여러 가지 대안을 놓고 고심하는 가운데 나온 방법이 종이 투표지 직접 계수 방식, 레버 기계, 천공 카드, 광학 스캔 투표지, 터치스크린 시스템, 혼합형 방식 등이 있으며 각 방법에는 나름의 단점이 있습니다. 직접 계수 방식은 번거롭고 실수가 나올 수 있고, 레버 기계의 경우 내부자의 조작이 가능하며, 천공 카드는 완전히 떨어져 나가지 않은 천공 부스러기로 인한 논란이 있었으며, 광학 스캔 투표지의 경우 스캐너 보정이 미숙했을 때 잘못 판독하기 쉽고, 터치스크린 시스템은 악성 소프트웨어로 손상될 수 있으며, 다양한 혼합형 방식들은 종종 해결하는 문제보다 야기하는 문제가 더 많습니다.
사실, 이런 문제는 이러한 시스템에 존재하는 취약성의 극히 일부일 뿐입니다.더구나 전 세계에서 일반적으로 사용되는 기법은 선거의 무결성을 유지하기 위해 정직하고 노련한 선거 관리자에 의존하고 있는 실정입니다.
하지만 관리자나 장비에 의존하지 않고 선거의 무결성을 보장할 수 있는 더 나은 대안이 있습니다.공무원이나 개인 투표자에서부터 선거에 참여하지 않은 이권 관계자까지 그 정확성을 검증할 수 있도록 선거를 실시할 수 있습니다.
이를 알아보기 위해, 선거권이 있는 투표자에게 공개 웹 사이트에서 자신의 이름 옆에 자신의 투표를 게시할 수 있는 코드가 제공된다고 가정해 보겠습니다.투표자는 자신이 투표한 내용이 정확하게 기록되었는지 웹 사이트에서 확인할 수 있고, 모든 투표자가 합법적인 유권자인지 그리고 득표 수가 발표된 내용과 일치하는지 여부에 대해 누구든지 독립적으로 감사를 수행할 수 있습니다.
여기서 잠깐 생각해보면 이러한 "공개" 선거에 보안 유지라는 요소가 빠져 있습니다.바로 이 부분을 메우기 위해 암호화 기술을 사용하면 완전한 검증이 가능한 비밀 투표 선거가 가능해집니다.투표 내용을 그대로 게시하는 것이 아니라 게시된 투표를 공개 키로 암호화하고, 암호화 키는 선거 관리인들이 공유하며 이를 해독하려면 여러 관계자의 협력이 필요합니다.투표가 완료되고 나면 선거 관리인들이 협력 하에 득표 결과 집계 및 집계된 수치가 암호화된 투표 용지가 게시된 숫자와 정확히 일치함을 나타내는 암호화된 증거를 도출합니다.
개인 투표자들은 암호화된 투표가 실제로 투표자의 의도와 일치하는지 확인할 수 있고, 암호화된 투표가 올바르게 계수되었는지 누구나 암호화된 증거를 검사해 볼 수 있습니다.이러한 방법으로 선거 득표 결과가 모든 사람에 의해 검증될 수 있습니다.
하지만 정말 이렇게 단순할까요?물론 아닙니다. 이것은 사실 그대로의 개관에 불과하며, 투표의 모든 측면이 빈틈 없이 이루어지려면 신중하게 처리해야 할 세부 사항이 수없이 많습니다.예를 들어, 투표 장치가 투표자에 대한 적절한 보안을 유지하도록 하기 위해 기존의 방법에 의존할 수밖에 없습니다.그리고 투표자들이 암호화된 투표에 어떤 방식으로 기표하는지도 고려해야 합니다.투표자들은 자신의 이름 옆에 게시된 이해하기 어려운 암호화 값이 자신이 의도한 내용이 맞는지 확신할 수 있어야 하며, 강요나 투표 매수 등에 연루되어 투표 내용을 다른 사람에게 보여 주지 않아야 합니다.동시에 투표자들이 현재의 전통적인 투표 방식보다 더 복잡한 절차를 거치지 않고도 이런 결과를 낼 수 있어야 합니다.
25년이 넘는 세월 동안 암호화 분야에서 모든 참여자가 검증할 수 있는 선거 프로세스를 연구해온 결과, 이제 득표 결과의 정확성에 대한 암호화된 증거를 제공할 수 있는 신뢰할 수 있는 실질적인 방법이 마련되었습니다.최근에는 해당 연구 커뮤니티 내에서 투표자에게 제공되는 프런트 엔드에 관심이 집중되었고 그에 따라 많은 진전이 있었습니다.
선거 기술에 대한 상업적 요구는 크지만 엄청날 정도는 아닙니다.이 시장에서 광범위한 이해 관계가 있는 대기업들은 그러한 이해 관계 중 일부가 특정 선거 결과의 혜택을 받을 수 있기 때문에 의혹을 받을 수도 있습니다.따라서 이 시장은 선거를 올바르게 치르는 데 기업 전체 운영이 개입되는 소규모 틈새 주자가 이끌어가는 것이 가장 바람직합니다.모든 참여자가 검증할 수 있는 선거 방법에 대한 자세한 내용 및 관련 링크는 research.microsoft.com/crypto/voting을 참조하십시오.

Josh Benaloh는 Microsoft Research의 수석 암호 전문가입니다.Josh는 IACR(국제 암호 연구 협회) 운영 위원을 8년 간 역임했고 1987년에 발행된 박사 논문인 "Verifiable Secret-Ballot Elections"를 비롯, 많은 저서를 집필한 바 있습니다.


Windows Confidential 공간을 차지하는 이전 도구
Raymond Chen

Microsoft Bob을 기억하십니까? 이것은 Windows® 3.1을 기반으로 간편한 사용자 인터페이스를 만들어 보자는 의도로 개발되었습니다. 그러나 이러한 의도와는 달리 PC 환경에서 최악의 기술 제품 중 하나라는 불명예를 받았습니다.Bob이 단종된 지 몇 년이 지났지만 이 제품은 그 이름이 단순히 웃기다는 이유로 계속 사람들 입에 오르내렸습니다.
덧붙여 말하자면 Microsoft® Bob의 내부 코드 이름은 "Utopia"였습니다. 이 코드 이름은 분명 야심적인 것이었고, 최소한 활기와 의욕이 넘치는 이름이었습니다.마케팅 팀이 제품 이름을 Bob으로 결정한 것을 들었을 때 우리는 모두 이유가 무엇인지 머리를 갸우뚱했습니다.
그러나 Bob이 남긴 것은 여러분이 알고 있는 것보다 훨씬 많습니다.실제로 Bob은 단종된 이후에 더 유용하게 되었습니다.
CD를 통해 소프트웨어를 배포하려는 경우 고려해야 할 것 중 하나는 배포하려는 제품이 CD 하나에 모두 저장될 수 있는지에 대한 것입니다.다행히 변환, 지원 도구 및 Windows XP CD에 넣어야 할 기타 도구에 필요한 디스크 공간을 고려하더라도 남아 있는 저장 용량이 30MB 정도 되었습니다.이러한 문제에 대해 고민하는 사람들은 생각했습니다. 'CD의 전체 저장 공간에 대한 비용은 이미 지불했으니까 전부 사용하는 게 좋지 않을까?'라고요.
Microsoft Bob의 내부 코드 이름은 "Utopia"였습니다. 이 코드 이름은 분명 야심적인 것이었고, 최소한 활기와 의욕이 넘치는 이름이었습니다.(더 크게 보려면 이미지를 클릭하십시오.)
결과는 Windows의 불법 복사본을 만들기 좋아하는 사람들을 저지하는 데는 다소 나약한 시도에 그쳤습니다.누군가 CD의 남는 공간에 더미 데이터를 기록하고 Windows 설치 프로그램에서 더미 데이터가 여전히 있는지 확인하도록 결정했다면이는 다른 사람들이 이 CD 이미지 복사본을 다운로드할 때 추가 30MB 정도의 데이터를 더 다운로드하도록 하는 것이 됩니다.잊지 마십시오. 이 내용은 "광대역"이 대중화되기 전 대부분의 사용자가 전화 접속 연결을 사용하던 시기의 이야기입니다.추가 30MB 데이터를 56Kb 모뎀을 통해 전송해야 하는 것은 사용자에게는 다소 부담이 되는 걸림돌이었습니다. 물론 오늘날 표준에서는 그리 부담이 되지 않겠지요.
이 검사를 구현하도록 요청받은 작업자는 더미 데이터에 대한 원본이 필요했습니다.지금이라면 30MB의 암호화된 난수 데이터를 생성하는 CryptGenRandom 함수를 사용할 수 있겠지만 여기서 흥미로운 것은 무엇일까요?이 작업자는 보관 파일을 조사하여 Microsoft Bob 복사본을 찾았습니다.그런 다음 모든 플로피 디스크 이미지를 가져와서 하나의 큰 파일로 결합했습니다.Microsoft Bob 플로피 디스크 이미지의 내용은 난수 데이터가 아니므로 이 작업자는 데이터를 암호화하여 뒤섞기로 했습니다.암호화 키를 입력해야 할 때 이 작업자는 키보드를 아무렇게나 쳐서 Microsoft Bob의 복사본을 암호화했습니다.이 복사본이 바로 Windows XP CD에서 사용되지 않은 공간에 기본 데이터로 저장된 것입니다.
결국 Windows XP는 Microsoft Bob이 개발된 이후로 가장 효과적인 Microsoft Bob 배포 도구가 되었습니다.작업실로 돌아가 Windows XP 복사본을 조사하고 올바른 방식으로 정확하게 키보드를 눌러서 암호를 뚫을 수 있다면 암호화 프로그램에서 Microsoft Bob 복사본을 확인할 수 있을 것입니다.

Raymond Chen은 자신의 웹 사이트 The Old New Thing에서 Windows의 역사와 Win32 프로그래밍에 대해 다루고 있으며 동명의 저서에서도 이에 대해 다루었습니다.Chen은 자신의 생애에 핵융합이 실용화되지 않을까 생각하기도 합니다.