SHBLITZ.NET

안녕하세요!! 오늘도 어제에 이어서 Windows Server 2008 강좌입니다!! 이번 강좌는 TechNet Magazine 2008년 3월호에 실린 Windows Server 2008에서 SCW 사용이란 내용의 강좌입니다.

Windows Server 2008에서 SCW 사용
Jesper M. Johansson

이 문서는 Windows Server 2008 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

2005년에 Microsoft에서는 Windows Server 2003 SP1을 발표했습니다. 이 서비스 팩에서는 최초의 Windows용 역할 기반 보안 관리 도구인 SCW(보안 구성 마법사)를 소개했습니다. Microsoft에서는 SCW를 최초이자 최고의 보안 취약점 감소 도구로 설계했습니다. 이 도구의 목적은 사용자가 컴퓨터를 통해 실제로 수행한 작업을 분석하여 필요한 해당 역할을 지원하도록 자동으로 컴퓨터를 구성할 뿐만 아니라 사용되지 않는 역할과 서비스는 비활성화하는 것입니다.

SCW는 Windows Server® 2008에서도 제공되지만 새 역할과 새로운 Windows® 방화벽과의 통합을 통해 업데이트되었습니다. 하지만 이전보다 더욱 향상된 고급 관리 기능을 제공합니다.

Windows Server 2008에는 새로운 역할 기반 서버 관리자 도구 및 이와 유사한 역할 추가 및 기능 추가 마법사가 포함되어 있습니다. Windows Server 2008에서는 이전 방식의 Windows 구성 요소 추가/제거 제어판을 통해 개별 구성 요소를 추가하는 대신 역할 관리 도구를 사용하여 서버를 구성합니다. Byron Hynes는 이번 호 TechNet Magazine의 기사 "서버 관리자를 사용하여 역할 구성"에서 이 도구에 대해 설명합니다.

역할 추가 및 기능 추가 마법사는 사용자가 선택한 역할을 지원할 수 있는 적합한 구성 요소로 서버를 구성하도록 설계되었습니다. 또한 이러한 역할이 올바르게 작동할 수 있도록 기본 제공 방화벽도 구성합니다. 그렇다면 SCW가 왜 여전히 필요한지에 대한 궁금증이 생길 수 있습니다. 사실 많은 수의 관리자에게 SCW는 더 이상 필요하지 않습니다. 하지만 SCW가 매우 유용한 도구가 될 수 있는 두 가지 사용자 그룹이 있습니다. 첫 번째 그룹은 보안에 매우 엄격한 사람들입니다. 이러한 사람들은 SCW가 보안을 한 차원 높은 수준으로 끌어올린다고 평가합니다.

역할 추가 및 기능 추가 마법사는 관리자가 원하는 역할과 기능을 안전하게 지원하도록 기본 서버를 구성하는 도구로 생각할 수 있습니다. 반면에 SCW는 관리자가 원하는 역할과 기능만 지원하도록 서버를 구성하는 도구입니다. 또한 SCW에는 서버가 구성되는 방식을 더 자세히 이해하도록 돕는 교육적 효과도 있습니다. 따라서 필자는 역할 및 기능을 통해 서버를 구성한 이후에 SCW를 실행할 것을 강력히 권장합니다.

두 번째 그룹은 다양한 구성 요소 간의 관계를 이해하고자 하는 사용자들입니다. SCW는 역할, 기능, 서비스 및 네트워크 포트 사이의 관계를 문서화하는 XML 파일 집합과 함께 제공됩니다. 다양한 구성 요소에 무엇이 필요한지 파악하는 데 관심이 있다면 SCW는 매우 유용한 도구입니다.

이 칼럼에서는 SCW가 작동하는 방식과 SCW를 사용하여 서버를 보호하는 방법을 설명합니다. 또한 SCW와 서버 관리자 도구를 비교합니다. 이 칼럼은 필자의 책 Windows Server 2008 Security Resource Kit(Microsoft Press®, 2008)를 각색한 것입니다.

보안 구성 마법사 개요
우선 Windows Server 2008의 보안 취약점에 대한 몇 가지 통계를 소개하겠습니다. 사용자가 선택한 역할과 기능을 추가하여 서버를 구성하기 전에도 상당히 많은 수의 서비스가 사용되고 있습니다. 기본적으로 Windows Server 2008에는 105개의 서비스가 있으며, 그 중 42개는 자동 시작으로, 55개는 수동 시작으로, 8개는 사용 안 함으로 설정되어 있습니다. 이와 반대로 Windows Server 2003 R2 SP2를 새로 설치하면 기본적으로 86개의 서비스가 설치되는데, 이 중에서 34개가 자동 시작, 32개가 요청 시 시작, 20개가 사용 안 함으로 설정됩니다.

역할 의미가 사용되고 지원되는 기본 역할의 수가 줄었지만 Windows Server 2008에는 여전히 많은 서비스가 사용되며 서버 보안을 강화하기 위한 추가적인 작업이 필요합니다. SCW는 특정 서버에 적합한 사용자 지정 보안 구성을 만드는 과정에 도움이 됩니다.

SCW는 서버 보안 강화를 위해 기존 도구와는 전혀 다른 방법을 사용합니다. 역할 의미를 사용하여 시스템이 해당 역할만 지원하고 다른 역할은 거의 지원하지 않도록 구성합니다. SCW는 역할 추가 및 기능 추가 마법사처럼 방화벽 구성을 지원하는 동시에 불필요한 서비스를 사용하지 않도록 설정하고 몇 가지 추가적인 보안 설정도 구성합니다. 마지막으로 역할 추가 및 기능 추가 마법사는 Windows에 기본으로 제공되는 역할만 설치하고 구성할 수 있는 반면에 SCW는 확장이 가능합니다. 개발자나 관리자는 사용자 지정 역할 또는 기능 구성 파일을 작성하고 SCW를 사용하여 모든 제품을 구성할 수 있습니다.

SCW는 서버에 필요한 모든 역할과 기능을 설치한 후에 사용하도록 설계되었습니다. 서버에 타사 응용 프로그램도 있는 경우에는 SCW를 실행하기 전에 해당 응용 프로그램도 설치해야 합니다.

필자는 작동 방식을 설명하기 위해 세 가지 역할(응용 프로그램 서버, DNS 서버 및 웹 서버)과 두 가지 기능(Microsoft® .NET Framework 3.0 기능 및 Windows Process Activation Service)으로 서버를 구성했습니다. 논리적인 역할 및 기능 집합은 아니지만 이 칼럼에서 설명하는 내용에는 적합한 예가 됩니다.

SCW를 시작하려면 관리 도구 메뉴에서 실행합니다. 그러면 그림 1과 같은 대화 상자가 표시됩니다.


그림 1 수행할 작업을 묻는 SCW

첫 번째 단계에서는 새 보안 정책을 만들 것인지, 기존 정책을 편집하거나 적용할 것인지, 정책을 롤백하여 시스템을 원래 설정으로 되돌릴 것인지 여부를 선택합니다. 각 항목은 비교적 쉽게 이해할 수 있습니다.

새 보안 정책 만들기를 선택하면 SCW는 일부 컴퓨터를 정책에서 지원해야 하는 항목에 대한 템플릿으로 사용하여 새 정책을 만듭니다. 컴퓨터를 분석하여 컴퓨터에서 지원하는 기능과 역할을 파악함으로써 해당 기능과 역할은 작동하도록 하고 불필요한 기능은 사용되지 않도록 합니다.

SCW는 프로토타입 모델에서 작동하며, XML 파일을 사용하여 설치된 파일, 구성된 서비스 등의 측면에서 역할과 기능의 형태를 지정합니다. 이러한 이유 때문에 정책을 적용할 대상 컴퓨터에는 모든 항목이 설치되어 있어야 합니다. 설치 시 SCW 정의를 설치하는 타사 프로그램이 있는 경우에는 문제 없이 통합됩니다. 하지만 SCW 정의를 설치하지 않는 타사 프로그램은 수동으로 구성해야 합니다.

여기서 볼 수 있듯이 한 시스템에서 정책을 만든 다음 이것을 여러 시스템에 적용할 수 있습니다. 여러 시스템이 있는 네트워크를 구축할 때는 모두 개별적으로 구성된 호스트 클래스를 먼저 정의해야 합니다. 그런 다음 이 중 하나를 프로토타입으로 사용하여 정책을 만들면 정책을 거의 또는 전혀 수정하지 않고 다른 컴퓨터에 쉽게 적용할 수 있습니다.

그림 1의 대화 상자에서 다음을 클릭하면 마법사에는 이 새 정책의 기준 또는 프로토타입으로 사용할 컴퓨터를 묻는 질문이 나타납니다. 대개의 경우 로컬 컴퓨터를 선택하지만 원격 컴퓨터를 프로토타입으로 사용할 수도 있습니다.

사용할 시스템을 지정한 후에는 분석 단계로 넘어갑니다. 이 단계에서 SCW는 설치된 역할과 기능을 열거하고 이를 역할 및 기능 데이터베이스에 일치시킵니다. 데이터베이스에는 각 역할과 기능에 사용되는 서비스에 대한 정보, 필요한 네트워크 포트 및 기타 중요한 구성 정보가 들어 있습니다. 분석이 끝나면 구성 데이터베이스 보기를 클릭하여 보안 구성 마법사에서 찾은 항목을 볼 수 있습니다. 이 보기는 컴퓨터의 구성에 대한 포괄적인 정보를 보여 주는 읽기 전용 보기입니다. 실제로 컴퓨터에 어떤 항목이 있는지 파악하는 데 관심이 있는 경우에는 이 정보를 면밀히 살펴보는 것이 도움이 될 수 있습니다.

SCW로 서버 구성
다음을 클릭하면 SCW의 네 개 섹션 중 첫 번째인 역할 단위 서비스 구성으로 넘어가게 됩니다. 그림 2에서처럼 SCW에서 찾는 역할은 역할 추가 마법사에서 찾는 역할과 같지 않을 수 있습니다. 역할 추가 마법사에서 사용 가능한 역할의 대부분이 여기에도 있지만 SCW는 역할 추가 마법사에는 없는 몇 가지 역할도 제공합니다. 예를 들어 여기에서 선택한 응용 프로그램 서버 역할은 존재하지 않습니다. SCW는 역할에 대해 약간 다른 의미를 사용하기 때문입니다. 이에 대해 좀 더 자세하게 설명하겠습니다.


그림 2 SCW를 사용하여 서버에서 지원할 역할 선택

이 대화 상자에 적절한 역할 집합이 이미 선택되어 있는 경우가 많습니다. 따라서 찾아야 할 것으로 생각한 항목이 분석을 통해 검색되었는지 여부만 확인하십시오. 잘못된 것이 있다면 역할이 설치되었는지 확인하고 누락된 역할을 설치한 후 SCW를 다시 실행하십시오. 실수를 한 경우에도 걱정할 필요는 없습니다. SCW에는 롤백 기능이 있기 때문에 정책으로 인한 모든 변경 사항을 실행 취소하여 처음으로 돌아갈 수 있습니다.

이 섹션에서 선택하는 답변은 네트워크 섹션에 표시될 항목을 결정하기 때문에 매우 중요합니다. 다행이 검색 논리가 상당히 훌륭하여 대개의 경우 올바른 역할 집합이 선택됩니다.

또한 기본적으로 디스크에 저장된 데이터로 서버에서 지원할 수 있는 역할인 설치된 역할이 표시됩니다. 선택된 역할은 현재 지원되는 역할입니다. 데이터베이스의 모든 역할을 표시하도록 선택할 수도 있습니다. 이렇게 하려면 드롭다운 목록에서 모든 역할을 선택합니다. 이는 필요한 모든 역할이 아직 설치되지 않은 프로토타입 서버를 사용하여 정책을 만들어야 할 때 유용합니다.

역할을 구성한 후에는 지원할 클라이언트 기능을 선택합니다. 기능 집합은 기능 추가 마법사의 기능 집합과 비슷하지만 동일하지는 않으며 포함된 기능이 더 적습니다. 마찬가지로 의미가 정확하게 동일하지 않고 SCW는 확장이 가능하기 때문에 표시되는 내용은 기능 추가 마법사와는 다릅니다.

SCW의 클라이언트 기능 페이지에서 다음을 클릭하면 그림 3과 같은 관리 및 기타 옵션 선택 대화 상자가 열립니다. SCW의 옵션은 역할이나 기능에 적합하지 않은 옵션입니다. SCW의 옵션은 관리 지원을 제공하거나 대화형 서비스 감지와 같은 단일 서비스일 수 있습니다. 필요한 옵션의 대부분을 여기에서 선택해야 합니다. 드롭다운 메뉴도 살펴볼 필요가 있습니다. 여기에는 앞서 선택한 역할 및 기능에 관련된 옵션이 들어 있으며 컴퓨터마다 다릅니다.


그림 3 SCW에서 다른 서비스 및 기능 선택

다음으로는 추가 서비스 선택 대화 상자가 열립니다. SCW에는 매우 큰 서비스 데이터베이스가 함께 제공되지만 여기에서 모두 설명하지는 않습니다. 데이터베이스에 없는 서비스를 SCW가 컴퓨터에서 찾는 경우 해당 서비스는 추가 서비스 페이지에 표시됩니다. 모든 기본 제공 서비스에 대한 설명이 제공되며 타사 서비스를 설치한 경우가 아니면 이 대화 상자는 나타나지 않습니다.

마법사를 사용하면 현재 구성하지 않은 서비스에 대해 수행할 작업을 선택할 수 있습니다. 이 옵션은 현재 작성 중인 정책을 다른 컴퓨터에 적용할 때 사용하기 위한 것입니다. 사용자가 정책을 만든 서비스와는 다른 서비스가 해당 컴퓨터에 있을 경우 SCW는 이를 어떻게 처리할지 알아야 합니다. 이에 대한 한 가지 방법은 그대로 두는 것입니다. 이것이 기본값입니다. 다른 한 방법은 사용하지 않도록 설정하는 것인데, 이것은 더 안전하지만 문제를 일으킬 수 있습니다. 그러나 정책을 만든 서버와 동일한 서버에만 정책을 적용하는 방법을 따르는 경우 이 페이지에서 선택하는 항목은 문제가 되지 않습니다.

이제 SCW의 역할 구성 부분을 마쳤으며 마법사에는 지금까지의 작업 요약이 표시됩니다. 그림 4에서 볼 수 있듯이 계속 다음만 클릭하더라도 컴퓨터의 보안 취약점에 큰 영향을 미칩니다. 예를 들어 이 컴퓨터는 인쇄 서버가 아니며 프린터가 설치되어 있지 않기 때문에 인쇄 스풀러 서비스를 실행할 이유가 없습니다. SCW는 필요 없는 모든 서비스를 사용하지 않도록 설정합니다. 테스트 서버에서 SCW는 자동 시작으로 설정되었던 서비스 17개를 사용 안 함으로 설정하고 42개의 수동 시작 서비스를 사용하지 않도록 설정했습니다. 물론 사용자 서버가 구성된 방식에 따라 결과는 달라질 수 있지만 SCW를 사용하면 손쉽게 각 서버에 맞게 정책을 사용자 지정할 수 있으므로 보안 취약점을 상당히 줄일 수 있다는 점을 알 수 있습니다.


그림 4 변경한 내용이 요약된 SCW

이제 SCW에서 가장 중요한 부분이라고 할 수 있는 네트워킹 섹션으로 이동합니다. 처음 시작 페이지가 나타난 후 그림 5와 같은 네트워크 보안 규칙 대화 상자가 표시됩니다. 여기에는 이전 섹션에서 사용자가 선택한 역할 지원을 기반으로 하여 SCW가 제안하는 모든 방화벽 규칙이 나열됩니다.


그림 5 사용자에게 필요한 모든 규칙을 나열하는 SCW

사용자가 네트워크 섹션에서 추가적인 구성을 설정하지 않으면 SCW는 이러한 역할과 기능만 지원되는 동시에 이에 대한 모든 클라이언트 액세스는 허용되도록 네트워크 인터페이스를 잠그는 방화벽 규칙을 생성합니다. 그러나 서버의 보안을 실제로 최적화하려면 서버 격리 전략 구축에 있어 가장 중요한 부분으로 SCW를 사용해야 합니다. 서버 격리 및 이와 깊게 연관된 도메인 격리에 대한 자세한 내용은 technet.microsoft.com/network/bb545651을 참조하십시오.

Windows Server 2008 Security Resource Kit에는 서버 및 도메인 격리를 통한 네트워크 보안에 대한 내용이 있습니다. 이 책에서는 또한 간편하게 서버 격리를 배포할 수 있도록 네트워크 위협 모델링을 사용하여 네트워크를 분석하는 방법도 설명합니다. 이 프로세스에서 SCW는 매우 유용한 도구입니다.

규칙을 선택하고 편집을 클릭하면 제안된 규칙에 대한 제한 사항을 구성할 수 있습니다. 이렇게 하면 그림 6과 같은 대화 상자가 열립니다. 이 그림은 네트워킹 규칙에 제한 사항을 추가할 수 있는 네 개의 페이지 중 한 페이지입니다. 예를 들어 IPsec 인증을 요구할 수 있습니다. 이 옵션을 선택하면 포트를 특정 끝점에만 연결할 수도 있습니다. 예를 들어 특정 호스트로부터의 원격 관리만 허용되도록 구성할 수 있습니다. 이 기능은 역할 추가 및 기능 추가 마법사에 비해 크게 향상된 것입니다.


그림 6 방화벽 및 IPsec 규칙을 작성할 수 있는 SCW

선택한 역할에 따라 연결 보안 규칙을 작성할 수 있는 이 기능에는 두 가지 중요한 목적이 있습니다. 첫째, 서버에서 수행되고 있는 작업을 파악할 수 있는 소중한 학습 기회를 제공합니다. 즉, 서버를 구축할 필요도 없습니다. 마법사를 실행하고 몇 가지 항목을 선택한 후 다음 페이지의 옵션에 어떤 영향이 있는지 살펴보기만 하면 됩니다. 둘째, 매우 추상적인 포트 개념을 더 논리적인 서비스 개념에 연결하고, 정확히 시스템에서 수행되고 있는 실제 작업을 기반으로 네트워크 제한 사항을 구성할 수 있습니다.

올바르게 설정하기만 하면 서버에 대한 매우 엄격한 구성을 만들 수 있습니다. SCW의 네트워킹 섹션은 서버의 보안 정책을 만드는 과정에서 대부분의 시간의 투입해야 하는 매우 중요한 부분입니다.
SCW의 나머지 부분에서는 감사 및 몇 가지 레지스트리 설정을 구성할 수 있습니다. 이러한 매개 변수의 기본 설정은 대부분의 조직에 적합하며, 특별한 요구 사항이 없다면 그다지 변경할 필요가 없습니다.

정책을 만든 후에는 정책을 저장하고 현재 작업 중인 컴퓨터에 적용하거나 다른 컴퓨터에 적용할 수도 있습니다. 또한 scwcmd.exe /transform 명령을 사용하여 정책을 GPO(그룹 정책 개체)로 변환할 수도 있습니다.

하지만 정책에 특정 컴퓨터에 관련된 설정이 있을 때는 정책이 성공하지 못하거나 의도하지 않은 결과가 나타날 수 있습니다. 예를 들어 네트워킹 섹션에서 로컬 어댑터를 포함하는 끝점 제한 사항을 만든 경우 해당 정책은 특정 컴퓨터 관련 정책으로 간주되며 성공적으로 변환되지 않습니다. 그 이유는 GUID를 사용하여 해당 어댑터를 지정해야 한다는 점 때문입니다. 한 컴퓨터의 어댑터에 대한 GUID는 다른 컴퓨터에서는 의미가 없습니다.

따라서 SCW는 서버 단위로 사용할 때와 학습 도구로 사용할 때 더 유용한 경우가 많습니다. 대규모 서버 팜에서는 컴퓨터 정보를 파악하고 기본 정책을 개발하는 하나의 방법으로 SCW를 사용할 수 있습니다. 그런 다음 해당 정책을 기반으로 정책을 다시 만들어 그룹 정책이나 엔터프라이즈 관리 시스템(예: Microsoft Systems Center)과 같이 서버 구성 도구를 사용할 때 적용할 수 있습니다.

SCW와 서버 관리자
지금까지 살펴본 것은 역할과 기능에 사용되는 의미가 서로 다르다는 점입니다. SCW에서 "기능"은 컴퓨터가 클라이언트 역할을 하기 위해 수행하는 것입니다. 반면에 "역할"은 컴퓨터가 서버 역할을 하기 위해 수행하는 것입니다.

즉, 이러한 개념은 역할은 하나의 단위로 생각할 수 있는 서비스 및 기능의 모음이고 기능은 역할을 지원하는 것으로 간주되는 서버 관리자 도구에서의 의미와 다릅니다. 기본적으로 서버 관리자에서는 역할을 서버가 수행해야 하는 것으로 간주합니다. 기능은 중요하기는 하지만 이를 위해 서버가 존재하는 것은 아닙니다. 동일한 용어에 대해 두 가지 의미와 두 가지 서로 다른 용도로 인해 혼동이 유발됩니다. 도구를 전환할 때는 먼저 이에 대해 신중하게 생각해 보아야 합니다.

또한 서버 관리자 도구에는 확장성이 없습니다. 즉, Windows와 함께 제공되는 구성 요소만 관리하도록 설계되었습니다. 이와 반대로 사용자가 설치하는 타사 프로그램에서는 SCW에 역할과 기능을 추가할 수 있습니다. 역할과 기능을 직접 작성할 수도 있습니다. 자세한 내용을 보려면 "보안 구성 마법사 확장" 백서(go.microsoft.com/fwlink/?LinkId=107397)를 참조하십시오.

또한 SCW는 필요 없는 구성 요소를 사용 안 함으로 설정합니다. 반면 서버 관리자 도구는 사용자가 요청한 구성 요소만 배포하며 컴퓨터의 다른 어떠한 항목도 변경하지 않습니다. 필요하지 않을 수 있는 구성 요소를 확인하는 데 도움이 필요한 경우에는 SCW를 사용해야 합니다.

서버 관리자 도구와 SCW 모두가 네트워크 구성에 사용되지만 이 경우에는 SCW가 훨씬 더 강력한 기능을 제공합니다. 서버 격리 전략을 구현할 때 SCW는 유용한 정보를 제공하는 최상의 배포 도구가 될 수 있습니다. 이러한 작업은 분명히 고급 보안 관리 항목에 해당하지만 SCW 역시 고급 보안 도구에 해당합니다.

마지막으로 SCW를 사용하면 서버 관리자 도구로는 할 수 없는 몇 가지 추가적인 보안 설정도 구성할 수 있습니다. 하지만 Windows Server 2008에서는 이러한 설정이 대부분 더 효율적인 컨트롤로 대체되거나 이미 기본으로 설정되어 있습니다.

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

안녕하세요!!~~ 이번에 올라가는 강좌는 TechNet Magazine 2008년 1월호에 실린 Windows Server 2008의 DNS 기능 향상 이란 내용으로 올라온 강좌입니다.

Windows Server 2008의 DNS 기능 향상
Joseph Davies

이 문서는 Windows Server 2008의 시험판 버전을 기준으로 작성되었습니다. 이 문서에 수록된 모든 정보는 변경될 수 있습니다.

Microsoft는 Windows NT 4.0부터 Windows Server 버전에 DNS(Domain Name System) 서버 서비스를 추가했습니다. DNS는 DNS 도메인 이름과 IP 주소 같은 다양한 데이터 형식 간의 매핑을 포함하는 계층적 분산 데이터베이스입니다. Windows Server 2008의 DNS 서버 서비스에는
백그라운드 영역 로드, IPv6 지원 향상, RODC(읽기 전용 도메인 컨트롤러) 지원, 전역 단일 레이블 이름 호스트와 같은 새로운 기능이 포함되어 있습니다.

백그라운드 영역 로드
Windows Server® 2008의 DNS 서버 서비스는 백그라운드 영역 로드를 구현함으로써 빨라진 데이터 검색 기능을 제공합니다. 과거에는 기업의 Active Directory® 영역에 포함된 레코드가 많은 경우, Windows Server 2003의 DNS 서버 서비스를 다시 시작하면 DNS 서버 서비스가 Active Directory에서 DNS 데이터를 검색하는 데 최대 한 시간 이상 지연되는 상황이 발생했습니다. 검색이 지연되는 동안 DNS 서버는 서버에서 호스팅되는 다른 영역에 대한 DNS 클라이언트 요청에 응답할 수 없었습니다.

이 문제를 해결하기 위해 Windows Server 2008의 DNS 서버 서비스는 다른 영역의 데이터 요청에 응답할 수 있도록 서비스가 시작되면 Active Directory의 영역 데이터 검색을 백그라운드에서 수행합니다. 서비스는 시작될 때 Active Directory에 저장된 영역을 로드하기 위한 실행 스레드를 하나 이상 만듭니다. 이렇게 Active Directory 기반 영역을 로드하기 위한 별도의 스레드를 생성함으로써 DNS 서버 서비스는 영역을 로드하는 동안 쿼리에 응답할 수 있습니다. DNS 클라이언트가 이미 로드된 영역의 데이터를 요청하면 DNS 서버는 요청에 적절히 응답합니다. 아직 완전히 검색되지 않은 영역의 데이터가 요청되면 DNS 서버가 Active Directory에서 해당 데이터를 검색합니다.
영역을 로드하는 동안 Active Directory에서 특정 데이터를 검색하는 이 기능을 통해 DNS 서버 서비스는 요청에 즉시 응답할 수 있으므로 영역 정보를 파일에 저장하는 것보다 훨씬 효율적입니다. 영역을 파일에 저장한 경우 DNS 서버 서비스가 해당 데이터를 찾을 때까지 파일을 순서대로 읽어야 합니다.

IPv6 지원 향상
이 칼럼의 지난 호에서 다룬 IPv6은 새로운 인터넷 표준 프로토콜 집합입니다. IPv6은 주소 고갈, 보안, 자동 구성, 확장성 요구 등 현재 버전인 IPv4가 지닌 많은 문제를 해결하기 위해 설계되었습니다.
IPv6이 기존 IPv4와 다른 가장 큰 차이점은 IPv4 주소는 길이가 32비트에 불과하지만 IPv6은 128비트에 이른다는 점입니다. IPv6 주소는 콜론으로 구분된 16진수 표기 방식으로 표현됩니다. IPv6 주소를 구성하는 각 16진수 숫자는 4비트입니다. 완전한 IPv6 주소는 32자리의 16진수로, 여덟 블록으로 구성되며 각 블록은 콜론으로 구분됩니다. 예를 들면 FD91:2ADD:715A:2111:DD48:AB34:D07C:3914와 같습니다.

IPv6 주소에 대한 정방향 이름 확인에서는 AAAA 레코드("쿼드 A"로 발음)라고 하는 IPv6 호스트 DNS 레코드를 사용합니다. 역방향 이름 확인의 경우 IPv6은 IP6.ARPA 도메인을 사용하며 32자리 IPv6 주소의 각 16진수는 역방향 도메인 계층 구조에서 역순으로 별도의 수준이 됩니다. 예를 들어 주소 FD91:2ADD:715A:2111:DD48:AB34:D07C:3914에 대한 역방향 조회 도메인 이름은 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA입니다.

Windows Server 2003의 DNS 서버 서비스는 IPv6에 대해 정방향 및 역방향 이름 확인을 지원하지만 지원 기능이 완전히 통합되지는 않았습니다. 예를 들어 Windows Server 2003 DNS 관리자 스냅인에서 IPv6 주소 레코드(앞에서 설명한 AAAA 레코드)를 만들려면 영역을 마우스 오른쪽 단추로 클릭하고 다른 새 레코드를 클릭한 다음 리소스 레코드 형식으로 IPv6 호스트(AAAA)를 두 번 클릭해야 합니다. Windows Server 2008 DNS 관리자 스냅인에서 AAAA 레코드를 추가하려면 영역 이름을 마우스 오른쪽 단추로 클릭한 다음 새 호스트(A 또는 AAAA)를 클릭합니다. 그런 다음 New Host(새 호스트) 대화 상자에서 IPv4 주소나 IPv6 주소를 입력할 수 있습니다. 그림 1에 그 예가 나와 있습니다.


그림 1 New Host(새 호스트) 대화 상자

역방향 IPv6 영역에서도 IPv6에 대한 지원이 향상되었습니다. Windows Server 2003 DNS 관리자 스냅인에서 역방향 조회 영역을 만들려면 New Zone Wizard(새 영역 마법사)의 Reverse Lookup Zone Name(역방향 조회 영역 이름) 페이지에서 역방향 영역 이름을 직접 입력해야 합니다. 예를 들어 DNS 역방향 영역 이름으로 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa(IPv6 서브넷 접두사가 2001:db8:0:1::/64인 경우 완전한 주소는 2001:0db8:0000:0001::/64임)를 입력합니다.

이제 Windows Server 2008의 DNS 관리자 스냅인에서는 IPv6 역방향 영역이 New Zone Wizard(새 영역 마법사)에 완전히 통합되었습니다. 이 마법사에는 IPv4 역방향 조회 영역 또는 IPv6 역방향 조회 영역을 선택할 수 있는 새로운 페이지가 추가되었습니다. IPv6 역방향 조회 영역을 만들려는 경우 IPv6 서브넷 접두사만 입력하면 자동으로 영역이 만들어집니다. 그림 2에 그 예가 나와 있습니다.


그림 2 IPv6 역방향 조회 영역 이름 지정

DNS 관리자 스냅인에 IPv6 PTR(포인터) 레코드가 표시되는 방식에 있어서도 역방향 영역에 대한 지원이 향상되었습니다. 그림 3에서 Windows Server 2003 DNS 관리자 스냅인에 PTR 레코드가 표시되는 방식을 볼 수 있습니다.

그림 3 Windows Server 2003의 IPv6에 대한 PTR 레코드 (더 크게 보려면 이미지를 클릭하십시오.)

이 표시 방식은 IPv6 역방향 도메인 이름에 대한 DNS 네임스페이스 구조를 정확하게 반영하기는 하지만 IPv6 주소에 대한 PTR 레코드를 관리하기가 어렵습니다. 그림 4에서 Windows Server 2008 DNS 관리자 스냅인에 PTR 레코드가 표시되는 방식을 볼 수 있습니다.


그림 4 Windows Server 2008의 IPv6에 대한 PTR 레코드 (더 크게 보려면 이미지를 클릭하십시오.)

Windows Server 2003의 DNS 서버 서비스는 IPv6에 대한 작업을 지원하지만 dnscmd /config /EnableIPv6 1 명령을 사용하여 지원을 직접 활성화해야 합니다. Windows Server 2008에서는 IPv6에 대한 작업을 기본적으로 지원합니다. Dnscmd.exe 명령줄 도구는 명령줄 옵션에 IPv6 주소를 사용할 수 있도록 업데이트되었습니다. 또한 DNS 서버 서비스가 이제 IPv6 전용 서버에 재귀 쿼리를 전송할 수 있으며 서버 전달자 목록에 IPv4 주소와 IPv6 주소를 모두 포함할 수 있습니다.

IPv6 및 Windows®의 IPv6 지원 방식에 대한 자세한 내용은 microsoft.com/ipv6을 참조하십시오.

읽기 전용 도메인 컨트롤러 지원
Windows Server 2008에는 Active Directory 정보의 읽기 전용 복사본을 포함하며 Active Directory 기능을 수행하지만 직접 구성할 수는 없는 새로운 유형의 도메인 컨트롤러인 RODC가 도입되었습니다. RODC는 공격에 덜 취약하므로 도메인 컨트롤러에 대한 물리적 보안을 보장할 수 없는 위치나 위험할 수 있는 호스트가 포함된 네트워크에 배치할 수 있습니다.

Windows Server 2008의 DNS 서버 서비스는 RODC에 대해 새로운 형식의 기본 읽기 전용 영역을 지원합니다. 컴퓨터를 RODC로 구성하면 도메인 파티션, ForestDNSZones 및 DomainDNSZones를 비롯하여 DNS가 사용하는 모든 응용 프로그램 디렉터리 파티션의 전체 읽기 전용 복사본이 복제됩니다. 이를 통해 RODC에서 실행되는 DNS 서버 서비스는 RODC가 아닌 도메인 컨트롤러의 디렉터리 파티션에 저장된 모든 DNS 영역에 대한 전체 읽기 전용 복사본을 사용할 수 있습니다. RODC의 기본 읽기 전용 영역의 내용은 볼 수는 있지만 변경할 수는 없습니다. RODC로 구성되지 않은 도메인 컨트롤러의 영역 내용만 변경할 수 있습니다.

GlobalNames 영역


Windows Server 2008과 Windows Vista®는 NetBT(NetBIOS over TCP/IP) 프로토콜을 지원합니다. NetBT는 NetBIOS 이름을 사용하여 세션 계층 NetBIOS 응용 프로그램을 확인합니다. 이름 확인에 Windows 소켓 기반 네트워크 응용 프로그램 및 DNS를 사용하는 최신 버전의 Windows에서는 WINS를 사용한 NetBIOS 이름 확인이 필요하지 않지만, 대부분의 Microsoft 고객은 이전의 NetBT 응용 프로그램을 지원하고 조직 전체에 단일 레이블 이름에 대한 이름 확인 기능을 제공하기 위해 네트워크에 WINS를 배포합니다. 단일 레이블 이름은 전자 메일 서버, 중앙 웹 서버, LOB(기간 업무) 응용 프로그램용 서버 등 일반적으로 조직에서 잘 알려지고 보편적으로 사용되는 중요한 서버를 나타냅니다.

이러한 단일 레이블 이름을 DNS만 사용해서 조직 전체에서 확인할 수 있도록 하려면 Windows 기반 DNS 클라이언트가 클라이언트에 할당된 DNS 도메인 접미사나 접미사 검색 목록에 관계없이 이름을 확인할 수 있도록 조직의 여러 DNS 도메인에 A 레코드를 추가해야 할 수도 있습니다.

예를 들어 contoso.com이라는 조직에 central.contoso.com 도메인의 구성원인 CWEB이라는 중앙 웹 서버가 있다고 가정해 보십시오. DNS 클라이언트에 DNS 도메인 접미사 wcoast.contoso.com, central.contoso.com 또는 ecoast.contoso.com을 할당할 수 있는 경우 CWEB 서버에 대해 단일 레이블 이름을 구현하려면 네트워크 관리자가 cweb.wcoast.contoso.com과 cweb.ecoast.contoso.com 모두에 대해 추가 A 레코드를 만들어야 합니다. 단일 레이블 이름에 대해 직접 만든 A 레코드는 IPv4 주소 할당이 변경되거나 새로운 이름이 사용될 경우 그에 따른 유지 관리가 필요합니다.

contoso.com이 이전의 NetBT 응용 프로그램에 대해 이미 WINS를 사용하고 있을 경우 네트워크 관리자는 해당 WINS 인프라에 단일 정적 WINS 레코드를 추가하여 단일 레이블 이름 CWEB에 대한 이름 확인을 구현할 수 있습니다. IPv4 주소가 변경되면 단일 정적 WINS 레코드만 변경하면 됩니다. 단일 레이블 이름은 WINS에서 관리하기가 더 쉬우므로 대부분의 Windows 기반 네트워크에서는 단일 레이블 이름에 정적 WINS 레코드를 사용합니다.

정적 WINS 레코드처럼 관리하기 쉬운 단일 레이블 이름 확인 기능을 DNS에 제공하기 위해 Windows Server 2008의 DNS 서버 서비스는 단일 레이블 이름을 저장하기 위한 GlobalNames라는 새로운 영역을 지원합니다. 이 영역의 복제 범위는 일반적으로 포리스트이며 이를 통해 전체 Active Directory 포리스트에 단일 레이블 이름 확인 기능이 제공됩니다. 또한 GlobalNames 영역 위치를 게시하는 데 SRV(서비스 찾기) 리소스 레코드를 사용하는 경우 GlobalNames 영역은 포리스트가 여러 개 포함된 조직에도 단일 레이블 이름 확인 기능을 지원할 수 있습니다.

WINS와 달리 GlobalNames 영역은 일반적으로 조직의 IT 부서에서 관리하는 조직의 중앙 서버 및 중요 서버와 같은 제한된 호스트 이름 집합에 단일 레이블 이름 확인 기능을 제공할 목적으로 만들어졌습니다. GlobalNames 영역은 데스크톱 컴퓨터나 IPv4 주소가 변경될 수 있는 다른 서버의 이름을 저장하는 데 사용할 목적으로 만들어지지 않았으며 DNS 동적 업데이트를 지원하지 않습니다. GlobalNames 영역은 대개 단일 레이블 이름을 FQDN(정규화된 도메인 이름)에 매핑하는 별칭(CNAME) 리소스 레코드를 보관하는 데 사용됩니다. 현재 WINS를 사용 중인 네트워크의 경우 이미 WINS에 정적으로 구성되어 있으며 IT 부서에서 관리하는 이름에 대한 리소스 레코드는 일반적으로 GlobalNames 영역에 포함됩니다.

GlobalNames 영역은 권한 있는 모든 DNS 서버가 Windows Server 2008을 실행하는 경우에만 단일 레이블 이름 확인 기능을 제공합니다. 이 경우 영역에 대한 권한이 없는 다른 DNS 서버는 이전 버전의 Windows나 다른 운영 체제를 실행할 수 있습니다. GlobalNames 영역은 포리스트에서 고유해야 합니다.

GlobalNames 영역을 Active Directory와 통합하여 권한 있는 각 DNS 서버를 Active Directory의 로컬 복사본으로 구성하면 최고의 성능과 확장성을 제공할 수 있습니다. 이렇게 하면 여러 포리스트에 GlobalNames 영역 배포를 지원할 수 있습니다.

Windows의 DNS 지원 및 GlobalNames 영역 배포에 대한 자세한 내용은 Microsoft DNS 웹 페이지(microsoft.com/dns)를 참조하십시오.

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

서론

IIS7 은 XML 구성 설정 파일들을 완벽하게 조작할 수 있게 해주고 서버 개체들에 대한 편리한 접근을 가능하게 해주는 관리되는 코드로 작성된 포괄적인 관리 응용 프로그램 프로그래밍 인터페이스 (API) 를 제공해줍니다. 본문에서는 서버의 구성 설정을 수정하고 서버 개체들을 관리하기 위해 새로운 관리 API 를 사용하는 방법을 여러분들에게 소개해드리고자 합니다.

IIS7 에는, XML 구성 설정 파일들의 완벽한 조작을 통해 구성 설정을 편집할 수 있게 해줄 뿐만 아니라 서버와 서버의 속성 및 상태를 관리하기 위한 편리한 개체들을 제공해주는, 웹 서버를 위한 새로운 관리 API 인 Microsoft.Web.Administration 이 포함되어 있습니다. 구성 설정 편집이라는 관점에서 볼 때, 이 API 에서는 IIS 구성 설정 파일 계층 및 특정 구성 설정 파일들의 구성 설정 속성들에 대한 프로그래밍적인 접근 방법을 제공해줍니다. 그리고, 개체 관리 측면에서는 서버의 직접적인 관리를 위한 일련의 최상위 관리 개체들을 제공해줍니다. (예: 사이트, 응용 프로그램 풀, 작업자 프로세스 등)

이러한 관리 클래스들은 Microsoft.Web.Administration 네임스페이스에 포함되어 있습니다. 이 클래스들은 구성 설정 섹션들과 편리한 개체들에 접근할 수 있는, 구성 설정상의 특성들에 대응하는 속성들과 (가상 디렉터리의 경로 등) 특정 개체를 대상으로 동작을 수행하는 메서드들을 (응용 프로그램 풀 재생 등) 가지고 있는 약한 유형의 인터페이스를 제공합니다.


전제조건

1. 반드시 IIS 가 머신에 설치되어 있어야만 합니다. 예를 들어서, 인터넷 익스플로러의 주소창에 http://localhost/ 라고 입력했을 때, "환영합니다." 페이지가 나타나야만 합니다. 만약 IIS 가 설치되어 있지 않다면 설치 방법에 관한 문서를 참고하여 IIS 를 설치합니다.
2. 먼저 여러분들이 머신에 대한 관리자 권한을 갖고 있는지를 확인하십시오. 만약 여러분들이 내장된 Administrator 계정 이외의 계정으로 로그온했다면, 비록 해당 계정이 머신의 로컬 Administrators 그룹에 추가되어 있는 계정이라고 하더라도 기본적으로 관리자 권한을 갖고 있지 않은 것으로 간주됩니다. (이 기능은 LUA 라고 불리우는 Longhorn 에서 제공되는 새로운 보안 관련 기능으로서, 본문에서 다루고자 하는 범위를 벗어나는 주제입니다.) 내장된 Administrator 계정으로 로그온하거나, 또는 필요하다면 “runas” 명령줄 도구를 사용하여 명시적으로 응용 프로그램을 내장된 Administrator 계정의 권한으로 실행시키십시오. 예를 들어, notepad.exe 를 실행시키기 위해서 “runas /user:administrator notepad.exe” 와 같은 명령어를 실행시킬 수 있습니다. 이 명령어를 실행하면 Administrator 계정의 비밀번호 입력을 위한 대화 상자가 나타날 것입니다. 아니면 “runas /user:administrator cmd.exe” 명령어를 실행하여, 미리 관리자 권한을 가진 명령 프롬프트를 실행하는 것도 또 다른 방법입니다. 이 명령 프롬프트에서 실행되는 응용 프로그램들 역시 모두 관리자 권한으로 실행되며, 명렴 프롬프트에서 “runas” 구문을 사용할 필요가 없어집니다.
3. 반드시 마스터 구성 설정 파일을 백업하도록 하십시오. 단지 applicationHost.config 파일을 다른 이름으로 복사해 놓기만 하더라도, 나중에 원상태로 복구가 가능합니다. 이 applicationHost.config 파일은 %windir%\system32\inetsrv\config 디렉터리에서 찾을 수 있습니다. 이 작업을 처리하기 위해서는 방금 위에서 설명한 관리자 권한이 필요하다는 점에 주의하십시오.
4. 본격적인 작업을 시작하기 전에 시스템이 "깨끗한 상태" 가 되도록 하십시오. 이를 위해서, 지금까지 이루어진 applicationHost.config 파일에 대한 모든 변경 사항들을 원래대로 돌려 놓으십시오. (만약, 여러분들이 VPC 이미지를 사용중이라면, 가장 손쉬운 방법은 변경된 상태를 저장하지 않고 이미지를 재시작하는 것입니다.)
5. Microsoft.Web.Administration 라이브러리를 사용하여 코딩이 가능하도록, 이 라이브러리를 여러분들의 콘솔 응용 프로그램 프로젝트에 참조를 추가해야만 합니다. 비주얼 스튜디오에서는, 솔루션 탐색기에서 프로젝트를 마우스 오른쪽 버튼으로 클릭한 다음 "참조 추가" 메뉴를 클릭하여 손쉽게 작업을 처리할 수 있습니다. MSWEBADMIN 라이브러리는 %WINDIR%\System32\InetSrv 디렉터리에서 찾을 수 있습니다.
6. 문제점이 발생하면 빨리 대응이 가능하도록 가급적 인터넷 익스플로러의 "HTTP 오류 메시지 표시" 기능을 (도구 > 인터넷 옵션 > 고급) 꺼놓는 것을 권장합니다.
7. 주의 : .html 파일로부터 텍스트를 복사하는 경우, 숨겨진 문자들까지도 함께 복사가 됩니다. 따라서 여러분들이 복사한 텍스트를 비주얼 스튜디오 같은 편집기, 또는 명령 프롬프트에 붙여 넣으면 겉으로 보기에는 정상적으로 복사가 된 것처럼 보이지만, 숨겨진 문자들을 포함하고 있기 때문에 적절하게 동작을 하지 않게 됩니다. 그래서, 결과적으로는 문제점을 발견해 내기가 매우 어려워집니다. 이 문제를 해결하기 위한 가장 좋은 방법은 복사한 텍스트를 먼저 노트패드에 붙여 넣은 뒤에 노트패드에 복사된 텍스트를 다시 한 번 복사하는 것입니다. 이렇게 하면 숨겨진 문자들이 제거됩니다. 만약 텍스트가 짧다면, 복사해서 붙여 넣는 것이 아니라 여러분들이 직접 타이핑하여 입력하는 것이 더 간단할 수도 있습니다.

새 사이트 만들기 개요

다음의 코드는 “Racing Cars Site” 라는 이름의 사이트를 루트 응용 프로그램 및 루트 가상 디렉터리와 함께 생성합니다. 그리고, 이 사이트는 8080 포트를 통해 HTTP 프로토콜을 사용하도록 설정되며, 물리적인 경로는 d:\inetput\wwwroot\racing 디렉터리로 정의됩니다.


ServerManager 클래스는 강력한 유형으로 사용할 수 있는 속성들과 메서드들을 갖고 있는 편리한 서버 개체들을 포함하고 있는 팩터리 클래스입니다. 이 클래스는 서버 관리를 위해 가장 중요한 진입점입니다. 물론 서버 관리는 다른 비효율적인 방법을 통해서도 (구성 설정 XML 에 직접 접근하거나 상태 APIs 를 호출하는 것과 같은) 이루어질 수도 있습니다만, 이와 같은 개체들을 사용하는 것이 서버 관리를 위한 보다 효과적인 방법입니다. ServerManager 클래스를 이용하여 사용이 가능한 가장 보편적인 개체들의 집합에는, 응용 프로그램, 가상 디렉터리, 사이트, 작업자 프로세스, 그리고 응용 프로그램 도메인 등이 있습니다.


Sites 컬렉션을 사용하면 특정 사이트의 속성과 응용 프로그램에 접근할 수 있습니다. 그리고, 이 컬렉션에는 시스템에 사이트를 추가하거나 시스템에 존재하는 모든 사이트들의 갯수를 얻는 등과 같은 작업을 처리하기 위한 메서드들도 존재합니다. Add 메서드는 사이트의 이름과 루트 가상 디렉터리 경로, 그리고 정수형의 포트 번호를 인자로 받습니다. 그리고, 그 실행 결과인 사이트 개체의 인스턴스를 mySite 개체 변수에 리턴하고, 이 개체의 프로퍼티들을 직접 수정하여 새로 생성된 사이트를 대상으로 작업을 수행할 수 있습니다.


이러한 편리한 개체들은 속성의 수정을 간단하게 만들어줍니다. 특정 XML 특성이나 항목들의 의미를 모르고 있다고 하더라도 mySite 개체의 속성들에 접근하여 사이트의 자동-시작 속성을 직접 "true" 로 설정하는 등과 같은 작업이 가능합니다.


또는, 사이트 개체의 인스턴스를 명시적으로 생성하지 않고 자동-시작 속성을 수정할 수 있는 다른 방법도 존재하는데, 이 경우 사이트 정보를 페치하여 임시 개체를 생성하고 직접 그 속성을 수정하게 됩니다. 관리 개체는 인덱서의 개념을 사용함으로써 전체 개체 집합의 목록을 가져오기 위한 고비용의 호출을 발생시키지 않으면서도 이름이나 인덱스와 같은 키를 통해서 특정 개체를 조회합니다. 다음의 코드에서는 이름을 사용하여 특정 개체를 얻고, 해당 개체에 대한 작업을 수행하고 있습니다.


변경 사항을 반영하기 위해서, CommitChanges 메서드를 실행시키면 작업 결과가 구성 설정 파일로 직렬화되고, 변경된 사항이 존재하는 경우, 디스크에 기록됩니다.


지금까지 살펴본 코드를 실행시키면 applicationHost.config 파일의 <sites> 섹션에 다음과 같은 결과를 생성하게 됩니다. 구성 설정 XML 을 항목이나 특성 수준에서 직접 조작하기 보다는, 웹 서버를 관리하기 위해 서버 관리 개체들이 제공해주는 보다 편리한 방법을 사용하십시오.



새로운 응용 프로그램 풀 생성

다음의 코드는 기존의 “Racing Cars Site” 의 이름을 변경하고 물리적인 경로를 d:\inetput\wwwroot\racing 로 수정합니다. 그리고, 새로운 응용 프로그램 풀을 생성하여 몇 가지 속성들을 설정한 다음, 사이트가 이 응용 프로그램 풀을 사용하도록 설정하고 최종적으로는 응용 프로그램 풀을 재생시킵니다.

사이트를 페치하기 위해 인덱싱을 하는 대신, 사이트 개체 인스턴스를 생성하고 그 참조를 설정할 수도 있습니다. 일단 참조가 설정되면, 해당 개체의 속성을 참조하거나 메서드를 호출할 수 있으며, 이 경우에는 사이트 이름이 그 작업 대상으로서 직접 속성을 사용하여 그 이름을 변경하고 있습니다.


다음은 인덱서를 사용하는 또 다른 사례로서, 루트 응용 프로그램을 얻은 다음 다시 루트 디렉터리를 얻고 그 물리적인 경로를 설정합니다.


또한 사이트 개체 외에도, 상태 메서드와 데이터 뿐만 아니라 구성 설정 속성들을 편리하게 얻거나 설정할 수 있는 방법을 제공해주는 응용 프로그램 풀 개체를 얻습니다. 다음 코드에서는 새로운 응용 프로그램 풀이 생성되고, 그 즉시 사이트가 그 응용 프로그램 풀에 추가됩니다.


여러분들은 서버 관리자 사이트 개체를 사용하는 경우와 마찮가지로, 서버 관리자 응용 프로그램 풀 개체를 사용하여 응용 프로그램 풀을 생성하고 참조를 설정할 수 있습니다. 물론 속성들을 얻거나 설정할 수도 있으며 메서드를 호출할 수도 있습니다. 업데이트 호출을 통해 응용 프로그램 풀 구성 설정 데이터가 파일로 직렬화되고 나면, 여러분들은 바로 재생 메서드를 실행시킬 수 있습니다. 이 재생 작업은 필수적인 것은 아니며, 해당 응용 프로그램 풀은 이제 막 생성되었으므로 그다지 필요한 작업은 아닙니다. 그러나, 여기에서는 방금 생성된 개체에 대한 작업은 반드시 그 개체가 디스크로 직렬화되고, 서버가 해당 구성 설정을 페치할 수 있어야만 재생 작업이 실행 가능하다는 점을 보여주고 있습니다.


지금까지 살펴본 코드를 실행시키면 applicationHost.config 파일의 <sites> 섹션에 다음과 같은 결과를 생성하게 됩니다. 구성 설정 XML 을 항목이나 특성 수준에서 직접 조작하기 보다는, 웹 서버를 관리하기 위해 서버 관리 개체들이 제공해주는 보다 편리한 방법을 사용하십시오.


또한, <applicationPools> 섹션에는 다음과 같은 항목이 추가되어집니다.



사이트 루트 web.config 구성 설정

다음의 코드는 "Default Web Site" 사이트의 <defaultDocument> 섹션의 “enabled” 특성값을 false 로 설정합니다.

Configuration 클래스는 시스템의 구성 설정 섹션들에 대한 접근을 제공해주는 클래스입니다. 여러분들은 구성 설정을 가져오기 위해 제공되는 다양한 메서드들을 호출하여 applicationHost.config, web.config, administration.config 또는 임의의 다른 구성 설정 파일들에 접근할 수 있습니다. 특히 GetWebConfiguration 메서드를 호출하면 지정한 사이트의 (이 경우에는 Default Web Site) 특정 경로에 대한 (이 경우에는 root) web.config 파일을 얻을 수 있습니다.


일단 web.config 파일을 얻고 나면 (만약 파일이 존재하지 않는다면 새로 생성됩니다.) 섹션을 가져오기 위한 호출이 생성됩니다. 우리는 <defaultDocument> 섹션을 비활성화하기 위해 찾고 있습니다. 만약 web.config 파일이 존재하지 않거나, 존재하기는 하지만 파일에 <defaultDocument> 섹션이 명시적으로 설정되어 있지 않다고 하더라도, 여전히 사이트 수준에서 실질적인 구성 설정으로 작용합니다. 이 섹션은 계층적으로 상속되며 재정의 가능한 구성 설정이기 때문입니다.


여러분들은 섹션 개체의 메서드를 호출하여 enabled 특성을 개체로 가져오고, 이 개체의 Value 속성을 통해서 그 값을 설정할 수 있습니다. 그런 다음, 서버 관리자 개체의 CommitChanges 메서드를 호출하기만 하면 변경 사항들이 직렬화되어 디스크에 저장되고, 즉시 서버로 반영됩니다. 만약, 해당 시점에 구성 설정 개체 인스턴스가 여러개 존재하고 있다면, 서버 관리자 개체의 CommitChanges 메서드 호출은 모든 인스턴스의 변경 사항들을 디스크로 저장하게 됩니다.


또 다른 방법으로 인덱서를 사용하여 섹션에서 특성 정보를 읽고 쓸 수도 있습니다. 다음의 코드 라인은 먼저 섹션 개체를 얻은 다음, enabled 특성의 값을 설정할 때 사용이 가능합니다.


결과적으로 지정한 사이트의 web.config 파일에는 해당 구성 설정이 이루어지게 됩니다.


사이트 구성 설정을 applicationHost.config 에 설정하기

다음의 코드는 "Default Web Site" 사이트의 <defaultDocument> 섹션의 “enabled” 특성값을 false 로 설정합니다.

이 코드는 바로 위에서 설명했던 작업 내용과 사실상 정확하게 동일한 작업을 수행하고 있으며, 단지 유일한 차이점은 구성 설정 관리자가 applicationHost.config 파일을 가져오기 위해 GetApplicationHostconfiguration 메서드를 호출한다는 점 뿐입니다. 섹션을 가져오기 위해 메서드를 호출할 때, 읽고 쓰기 위한 섹션과 해당 섹션의 위치 경로도 함께 지정한다는 점에 주의하십시오.


결과적으로 applicationHost.config 파일에는 location 태그를 통해 지정된 사이트에 대한 구성 설정이 반영되어 집니다.

출처 : 한국 마이크로소프트 MSDN (2007년 2월)

서론

IIS 7.0 에서도 여전히 레거시 구성 설정 스크립트와 응용 프로그램들을 사용할 수 있습니다. 이것이 가능한 이유는 메타베이스 시스템과 그에 대한 프로그래밍 인터페이스인 Admin Base Objects (ABO), 그리고 그 상위에 존재하는 ADSI 제공자와 WMI 제공자를 사용할 수 있게 해주는 선택적 설치 구성 요소가 존재하기 때문입니다. 시스템은 ABO 에 대한 호출을 가로채어 이를 새로운 구성 설정 시스템으로 맵핑합니다. 데이터는 applicationHost.config 파일에 저장되지만, ABO 호출자는 레거시 구성 설정 구조 뷰의 형태로 데이터를 출력합니다.

전제조건

1. 반드시 IIS 가 머신에 설치되어 있어야만 합니다. 예를 들어서, 인터넷 익스플로러의 주소창에 http://localhost/ 라고 입력했을 때, "환영합니다." 페이지가 나타나야만 합니다. 만약 IIS 가 설치되어 있지 않다면 설치 방법에 관한 문서를 참고하여 IIS 를 설치합니다.
2. 먼저 여러분들이 머신에 대한 관리자 권한을 갖고 있는지를 확인하십시오. 만약 여러분들이 내장된 Administrator 계정 이외의 계정으로 로그온했다면, 비록 해당 계정이 머신의 로컬 Administrators 그룹에 추가되어 있는 계정이라고 하더라도 기본적으로 관리자 권한을 갖고 있지 않은 것으로 간주됩니다. (이 기능은 LUA 라고 불리우는 Longhorn 에서 제공되는 새로운 보안 관련 기능으로서, 본문에서 다루고자 하는 범위를 벗어나는 주제입니다.) 내장된 Administrator 계정으로 로그온하거나, 또는 필요하다면 “runas” 명령줄 도구를 사용하여 명시적으로 응용 프로그램을 내장된 Administrator 계정의 권한으로 실행시키십시오. 예를 들어, notepad.exe 를 실행시키기 위해서 “runas /user:administrator notepad.exe” 와 같은 명령어를 실행시킬 수 있습니다. 이 명령어를 실행하면 Administrator 계정의 비밀번호 입력을 위한 대화 상자가 나타날 것입니다. 아니면 “runas /user:administrator cmd.exe” 명령어를 실행하여, 미리 관리자 권한을 가진 명령 프롬프트를 실행하는 것도 또 다른 방법입니다. 이 명령 프롬프트에서 실행되는 응용 프로그램들 역시 모두 관리자 권한으로 실행되며, 명렴 프롬프트에서 “runas” 구문을 사용할 필요가 없어집니다.
3. 반드시 마스터 구성 설정 파일을 백업하도록 하십시오. 단지 applicationHost.config 파일을 다른 이름으로 복사해 놓기만 하더라도, 나중에 원상태로 복구가 가능합니다. 이 applicationHost.config 파일은 %windir%\system32\inetsrv\config 디렉터리에서 찾을 수 있습니다. 이 작업을 처리하기 위해서는 방금 위에서 설명한 관리자 권한이 필요하다는 점에 주의하십시오.
4. 본격적인 작업을 시작하기 전에 시스템이 "깨끗한 상태" 가 되도록 하십시오. 이를 위해서, 지금까지 이루어진 applicationHost.config 파일에 대한 모든 변경 사항들을 원래대로 돌려 놓으십시오. (만약, 여러분들이 VPC 이미지를 사용중이라면, 가장 손쉬운 방법은 변경된 상태를 저장하지 않고 이미지를 재시작하는 것입니다.)
5. 문제점이 발생하면 빨리 대응이 가능하도록 가급적 인터넷 익스플로러의 "HTTP 오류 메시지 표시" 기능을 (도구 > 인터넷 옵션 > 고급) 꺼놓는 것을 권장합니다.
6. 주의 : .html 파일로부터 텍스트를 복사하는 경우, 숨겨진 문자들까지도 함께 복사가 됩니다. 따라서 여러분들이 복사한 텍스트를 비주얼 스튜디오 같은 편집기, 또는 명령 프롬프트에 붙여 넣으면 겉으로 보기에는 정상적으로 복사가 된 것처럼 보이지만, 숨겨진 문자들을 포함하고 있기 때문에 적절하게 동작을 하지 않게 됩니다. 그래서, 결과적으로는 문제점을 발견해 내기가 매우 어려워집니다. 이 문제를 해결하기 위한 가장 좋은 방법은 복사한 텍스트를 먼저 노트패드에 붙여 넣은 뒤에 노트패드에 복사된 텍스트를 다시 한 번 복사하는 것입니다. 이렇게 하면 숨겨진 문자들이 제거됩니다. 만약 텍스트가 짧다면, 복사해서 붙여 넣는 것이 아니라 여러분들이 직접 타이핑하여 입력하는 것이 더 간단할 수도 있습니다.

Windows Vista Starter 에디션과 Home 에디션은 웹 응용 프로그램을 실행하거나 웹 배포를 할 필요가 없는 가정과 개인 사용자들을 대상으로 하고 있습니다. IIS 7 웹 서버와 FTP 서버의 기능들은 이 에디션들에서는 사용할 수 없습니다. 그렇지만, 만약 자세하게 살펴본다면 여러분들은 이 에디션들에 설치할 수 있는 IIS 7 의 특정 구성 요소들을 발견할 수 있을 것입니다. 그러나, 이런 컴포넌트들을 설치한다고 하더라도, 정적 콘텐츠나 클래식 ASP, 또는 ASP.NET 등을 지원하는 웹 서버 기능이 제공되지는 않는다는 점에 주의하시기 바랍니다.

이 에디션들에서 사용 가능한 IIS 7 의 구성 요소들은 마이크로소프트의 Windows Communication Foundation (WCF) 기반 구조를 지원하기 위한 목적으로 제공되는 것입니다. 이러한 기반 구조를 제공하는 IIS 7 의 구성 요소들을 통칭하여 Windows 프로세스 활성화 서비스 (WAS) 라고 합니다. 그러나, WCF 기반의 응용 프로그램을 설치할 때 사용자가 명시적으로 WAS 를 설치할 필요는 없으며, 필요한 경우 WCF 에 의해서 자동으로 설치됩니다.

Vista Starter 에디션과 Home 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.


ABO를 사용한 가상 전역 설정 기록

이번 단계에서는 AdminBaseObjects (ABO) 인터페이스를 사용하여 전역 설정값을 변경하고, 변경된 값을 applicationHost.config 파일에 기록하는 방법에 대해 살펴봅니다. 이러한 작업을 위해 MBExplorer.exe 도구를 사용할 것입니다.

먼저 IIS 7.0 의 메타베이스 호환성 구성 요소가 머신에 설치되어 있는지부터 확인하시기 바랍니다. 이 구성 요소는 기본적으로 설치되지 않습니다. Longhorn Server 에서는 서버 관리자 도구를 (시작->관리 도구->서버 관리자) 이용하여 "IIS 6.0 메타베이스 호환성" 구성 요소가 설치되어 있는지 확인할 수 있습니다. 아니면, 명령 프롬프트상에서 "net start iisadmin" 명령을 실행하여 IISADMIN 이라는 이름의 NT 서비스가 구동중인지 확인하십시오. 이 명령을 실행했을 때 IISADMIN 이 이미 실행되었다는 메시지가 나타나야만 합니다.

그 다음에 MBExplorer 도구를 웹으로부터 다운로드합니다. MSN 서치 등의 검색 엔진을 이용해서 이 도구를 찾다보면, 결국 여러분들은 Microsoft.com 의 다운로드 센터로 이동하게 되는데, 이 다운로드 센터에서 IIS 6.0 리소스 킷을 다운로드하고 설치해야 합니다. MBExplorer 도구는 바로 이 리소스 킷에 포함되어 있습니다. 정상적으로 설치를 마치고 나면 일반적으로 %ProgramFiles%\IIS Resources\Metabase Explorer\ 폴더에서 MBExplorer 도구의 실행 파일인 MBExplorer.exe 파일을 찾을 수 있습니다.

먼저 MBExplorer.exe 도구를 실행합니다. 이 도구는 AdminBaseObjects (ABO) 인터페이스의 최상단에서 동작하며, 그렇기 때문에 ABO 를 통해 얻어진 구성 설정 계층 정보를 보여줍니다.

좌측 패인에서, LM > W3SVC 노드를 찾습니다. 이 노드는 ABO 뷰 상에서 전역 수준의 구성 설정 계층을 나타내는 노드입니다.

이제 우측 패인에서 AuthFlags 속성을 선택합니다. 목록에서 Name 컬럼 헤더를 마우스로 클릭하여 속성들을 정렬하면 손쉽게 이 속성을 찾을 수 있습니다. 이 속성의 기본값은 5 입니다.


<메타베이스 탐색기>

이 값을 1 에서 7 사이의 정수를 입력하여 변경합니다.

노트패드 같은 텍스트 편집기를 사용하여 다음의 경로에 위치해 있는 ApplicationHost.config 파일을 엽니다.

그리고, 이 파일에서 <authentication> 섹션 그룹을 찾습니다. 이 섹션 그룹 하위에 존재하는 인증 섹션들은 여러분들이 설정한 값에 따라서 각각 활성화되거나 비활성화 되어 있을 것입니다. 예를 들어서, 만약 여러분들이 AuthFlags의 값을 2 로 설정했다면, BasicAuthentication 섹션의 enabled 속성값만 true 로 설정되어 있고, 다른 모든 인증 섹션들의 enabled 속성값은 false 로 설정되어 있을 것입니다. 왜냐하면 IIS 6.0 스키마상에서 값 "2" 가 "AUTH_BASIC" 와 매핑되어 있기 때문입니다.

다시 MBExplorer 를 사용하여 이 속성의 값을 바꿔보고 ApplicationHost.config 파일의 내용을 다시 확인해 보십시오. 메타베이스의 AuthFlags 속성값이 변경됨에 따라, 간접적으로 ApplicationHost.config 파일의 인증 스키마들이 활성화되거나 비활성화 되는 것을 확인할 수 있습니다.


ABO를 사용한 가상 디렉터리 설정 기록

이번 단계에서는 ABO 를 사용하여 가상 디렉터리의 속성값을 변경하고, 변경된 값을 applicationHost.config 를 통해서 확인하는 방법에 대해 살펴볼 것입니다. 여러분들이 변경하게 될 내용은 전역 설정에 해당하는 영역이 아니므로, ABO 호환성 계층은 applicationHost.config 파일 내부에 변경된 가상 디렉터리에 대응하는 경로가 포함된 새로운 location 태그를 생성하게 됩니다. 어떠한 web.config 파일도 메타베이스 호환성 구성 요소에 의해 변경되지 않는다는 점을 주의하십시오.

먼저 MBExplorer.exe 도구를 실행합니다.

좌측 패인에서, LM > W3SVC > 1 > ROOT 노드를 찾습니다. 이 노드는 기본 웹 사이트의 루트 응용 프로그램을 나타내는 노드입니다.

이제 AuthFlags 속성값을 설정합니다. 우측 패인에 AuthFlags 속성이 이미 존재한다면 이 과정을 생략할 수 있습니다. 좌측 패인에서 ROOT 노드를 선택하고 Edit 메뉴에서 New > DWORD Record 메뉴를 실행한 다음, Record Name or Identifier 입력란에 6000 을 입력합니다.


<메타베이스 탐색기>

이 작업은 기본값으로 0 이 설정된 AuthFlags 속성을 ROOT 노드에 생성합니다. 오른쪽 패인에서 이 속성을 더블 클릭하고 1 에서 7 사이의 정수를 입력하여 값을 변경합니다.

노트패드 같은 텍스트 편집기를 사용하여 다음의 경로에 위치해 있는 ApplicationHost.config 파일을 엽니다.

파일의 마지막 부분을 살펴보면, 여러분들이 설정한 값에 따라 활성화되거나 비활성화 된 authentication 섹션들을 포함한 새로운 <location path="Default Web Site"> 태그를 발견할 수 있을 것입니다.

요약

본문에서 여러분들은 구성 설정 시스템의 호환성 기능을 활성화하고 사용하는 방법에 대해서 살펴보았습니다. 여러분들은 레거시 도구를 사용하여 전역 수준이나 가상 디렉터리 수준의 설정들을 변경할 수 있으며, 이런 방법으로 변경된 내용은 applicationHost.config 파일에 기록됩니다. 여러분들은 맵핑과 기록을 위해서 adsutil.vbs 와 같은 다른 도구들을 사용하고 싶을 수도 있습니다. 또는 기존의 ABO/ADSI/WMI 스크립트들이나 응용 프로그램을 새로운 환경에서도 계속해서 사용할 수 있다는 사실을 확인하고 싶을 수도 있습니다. 또한, 본문에서 살펴본 방법과는 정반대의 방법으로도 동일한 실험을 해 볼 수 있는데, 먼저 applicationHost.config 파일의 값을 변경한 다음에 그 반영된 결과를 MBExplorer 를 비롯한 ABO 를 사용하는 도구들 및 스크립트를 통해서 확인한 수 있습니다.

출처 : 한국 마이크로소프트 MSDN (2006년)

개요

다음은 ASP.NET v1.1 을 IIS7 에 설치하기 위한 5 가지 단계입니다.

• "IIS 메타베이스 호환성" 이 설치되어 있는지 확인합니다.
• .NET 프레임워크 v1.1 과 .NET 프레임워크 v1.1 SP1 을 설치합니다.
• ASP.NET v1.1 ISAPI 익스텐션을 활성화합니다.
• .NET 프레임워크 v1.1 의 machine.config 파일에 system.webServer 라는 이름으로 IgnoreSection 헨들러를 추가합니다.
• 여러분들의 사이트나 응용 프로그램을 .NET 프레임워크 v1.1 응용 프로그램 풀로 이동합니다.

단계 1: "IIS 메타베이스 호환성" 설치

반드시 IIS 메타베이스 호환성이 설치되어 있어야만, .NET 프레임워크 v1.1 설치 프로세스가 Longhorn Server 에 ASP.NET v1.1 을 정상적으로 설치할 수 있습니다.

만약, 여러분들이 Longhorn Server 상에서 작업을 하고 있다면, 시작을 통해서 서버 관리자를 실행하십시오. 서버 관리자의 좌측 트리뷰에서 서버 관리자 노드를 확장하고 역할 관리를 클릭해보면, Web Server (IIS) 노드를 찾을 수 있습니다. 이 노드를 선택하고 우측 패인을 살펴보면 역할 서비스 추가라는 옵션이 존재합니다. 여러분들은 이 옵션을 사용하여 "IIS 메타베이스 호환성" 을 설치할 수 있는 마법사를 실행시킬 수 있습니다.



만약, 여러분들이 Windows Vista 상에서 작업을 하고 있다면, 시작을 클릭한 다음 제어판을 클릭하여 열고, 프로그램 항목에서 Windows 기능 사용/사용 안 함을 클릭하여 Windows 기능 대화 상자를 실행합니다. 이 대화 상자에서 인터넷 정보 서비스 (IIS) 부분을 살펴보고 "IIS 메타베이스 호환성" 을 설치하십시오.

단계 2: .NET 프레임워크 v1.1 과 .NET 프레임워크 v1.1 SP1 설치

다음의 .NET 프레임워크 v1.1 과 SP1, 그리고 ASP.NET 보안 업데이트를 설치하십시오.

• Microsoft® .NET Framework 버전 1.1 재배포 가능 패키지
• Microsoft .NET Framework 1.1 서비스 팩 1
• .NET Framework 1.1 Service Pack 1 ASP.NET 보안 업데이트

여러분들이 .NET 프레임워크 버전 1.1 과 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하려고 하면, 다음과 같은 대화 상자가 나타날 것입니다. 그러면 Run program 버튼을 클릭하십시오.



주의: 만약 여러분들이 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하지 않는다면, 아마도 다음과 같은 "IIS 작업자 프로세스가 동작을 멈췄습니다." 와 같은 메시지와 더불어 데이터 실행 방지 (DEP) 오류가 발생할 것입니다. 이는 예상된 결과입니다. 이 문제점은 .NET 프레임워크 버전 1.1 서비스 팩 1 을 설치하면 해결됩니다.



단계 3: ASP.NET v1.1 ISAPI 익스텐션 활성화

이에 대한 구체적인 방법을 알아보시려면 IIS 관리자를 사용하여 익스텐션을 활성화 하는 방법 (영문) 온라인 문서를 참고하시기 바랍니다.

익스텐션: C:\Windows\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
주의: 만약 여러분들이 C:\ 드라이브가 아닌 다른 드라이브에 시스템을 설치했다면 위의 경로에서 드라이브를 적절하게 수정해줘야만 합니다.
그룹 아이디: ASP.NET v1.1
설명: ASP.NET v1.1

또는, 다음과 같은 명령 프롬프트 명령어을 실행하여 동일한 작업을 수행할 수 있습니다.

단계 4: ASP.NET v1.1 machine.config 파일에 IgnoreSection 헨들러 추가

만약, 여러분들의 ASP.NET v1.1 응용 프로그램에 IIS 에 대한 구성설정 섹션을 가지고 있는 web.config 파일이 존재한다면, 응용 프로그램 구동시에 ASP.NET v1.1 이 런타임 예외를 던질 것입니다. 따라서, ASP.NET v1.1 로 하여금 IIS 관련 구성설정 섹션을 무시하도록 지시하려면, 먼저 .NET 프레임워크 v1.1 의 machine.config 파일을 열고 (%windir%\Microsoft.NET\Framework\v1.1.4322\config\machine.config), 다음 구성설정 섹션 항목을 섹션 태그가 닫히기 직전에 추가하십시오.

　　<section name="system.webServer" type="System.Configuration.IgnoreSectionHandler,
　　　　System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>

단계 5: ASP.NET 1.1 응용 프로그램 풀로 사이트 또는 응용 프로그램 이동

NET 프레임워크 v1.1 은 설치과정 중, 구동시에 .NET 프레임워크 v1.1 을 로드하도록 구성된 "ASP.NET 1.1" 이라는 이름의 응용 프로그램 풀을 생성합니다. IIS 관리자를 통해서 여러분들의 웹 사이트나 웹 응용 프로그램을 이 응용 프로그램 풀로 이동하는 구체적인 방법에 대해서는 이 온라인 문서 (영문)를 참고하시기 바랍니다. 또는, 명령 프롬프트 상에서 %windir%\system32\inetsrv 디렉터리로 이동하여 다음의 명령어를 실행시켜도 동일한 작업을 수행할 수 있습니다.

appcmd set app "Default Web Site/" /applicationPool:"ASP.NET 1.1"

만약, 여러분들이 .NET 프레임워크 v1.1 을 로드하도록 구성된 새로운 웹 응용 프로그램 풀을 직접 생성하는 방법을 선호한다면, 응용 프로그램 풀 생성 (영문) 온라인 문서를 참고하시기 바랍니다. 명령 프롬프트 상에서 %windir%\system32\inetsrv 디렉터리로 이동하여 다음과 같은 명령어를 실행시켜도 동일한 작업을 수행할 수 있습니다.

appcmd add apppool /name:"NewPool" /managedRuntimeVersion:"v1.1" /managedPipelineMode:"Classic"

출처 : 한국 마이크로소프트 MSDN (2006년)

서론

URLScan 은 이전 버전의 IIS 에 애드-온 형태로 제공되던 보안 도구로 관리자들은 이 도구를 사용하여 웹 서버에 엄격한 보안 정책을 적용할 수 있었습니다. IIS 7.0 에서는 URLScan 의 모든 핵심적인 기능들이 요청 필터링이라는 모듈에 병합되었으며 숨겨진 네임스페이스라는 기능이 추가되었습니다. 본문에서는 요청 필터링이 제공하는 각각의 기능들에 대해서 알아보고 여러분들이 접하고 있는 환경에 적용이 가능하도록 실제 상황에서의 예제를 살펴보겠습니다.

이중 인코딩 요청 필터링

기능 개요
이 기능은 이중 인코딩된 요청을 이용한 공격을 방지합니다. 이 시나리오는 공격자가 주의 깊게 만들어진 이중으로 인코딩된 교묘한 요청을 IIS 로 전송하는 경우에 적용됩니다. 이와 같은 공격이 발생한다면 IIS 는 요청이 유효한 경우에만 허용하고 그렇지 않다면 거부할 것입니다. 이 기능이 활성화되면 IIS 는 해당 URL 을 두 번 디코딩하는데, 만약 첫 번째 디코딩 결과와 두 번째 디코딩 결과가 다르다면 요청은 거부되어질 것입니다. 이 기능에 의해서 요청이 거부되면 404.11 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능
이 기능은 URLScan 의 VerifyNormalization 옵션의 기능과 동일합니다.

실제 예제
이 예제에서는 서버 관리자가 서버로 전송되는 이중으로 인코딩된 요청을 결코 허용하지 않기를 원한다고 가정합니다. 이 시나리오를 반영하기 위해 다음과 같은 구성설정을 사용할 수 있습니다.

최상위 비트 설정 문자 필터링

기능 개요
이 기능은 IIS 로 전달되는 비 ASCII 문자가 포함된 모든 요청들을 허용할지 또는 거부할지를 결정합니다. 이 기능에 의해서 요청이 거부되면 404.12 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능
이 기능은 URLScan 의 AllowHighBitCharacters 옵션의 기능과 동일합니다.

실제 예제
이 예제에서는 서버 관리자가 전체 서버에 전송되는 최상위 비트가 설정된 문자들을 허용하지 않기를 바라지만, 오직 하나의 응용 프로그램에서는 이를 허용하기 원한다고 가정합니다. 이를 위해서 서버 관리자는 applicationHost.config 파일에는 allowHighBitCharacters=”false” 를 설정했지만, 비 ASCII 문자를 받아들이기 바라는 응용 프로그램의 루트 아래에는 web.config 파일을 생성했습니다. 다음의 구성설정이 바로 그 web.config 파일에 사용된 설정입니다.

파일 확장자에 기반한 필터링

기능 개요

이 기능은 IIS 가 서비스 할 수 있는 파일 확장자들의 집합을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.7 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 AllowExtensions 옵션과 DenyExtensions 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 ASP 파일은 서비스 되지 않지만 그 외의 모든 파일들은 서비스 되기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 allowUnlisted 옵션을 “true” 로 설정하고, 명시적으로 서비스 되지 않기를 바라는 ASP 파일을 위해 다음과 같은 파일 확장자 항목을 정의합니다.

요청 제한에 기반한 필터링

기능 개요

이 기능은 다음 세 가지 기능들의 조합으로 이루어집니다.

• maxAllowedContentLength ? Content-Length 요청 헤더값의 최대 크기를 지정합니다.
• maxUrl ? 쿼리스트링을 제외한 URL 의 최대 길이를 지정합니다.
• maxQueryString ? 쿼리스트링의 최대 길이를 지정합니다.

이 기능에 의해서 요청이 거부되면 다음과 같은 오류 코드가 로그에 기록됩니다.

• 404.13 콘텐츠가 너무 큰 경우
• 404.14 URL 이 너무 긴 경우
• 404.15 쿼리스트링이 너무 긴 경우

URLScan 의 동일한 기능

이 각각의 기능들은 URLScan 의 다음 기능들과 동일합니다.

• maxAllowedContentLength
• maxUrl
• maxQueryString

실제 예제

이는 소스 코드에 접근할 수 없는 소프트웨어를 구매하는 기업들에게는 매우 일반적인 상황입니다. 코드에 내제된 취약성들이 발견되었을 때, 그 영향을 받는 코드를 갱신하는 것이 매우 어려울 수도 있습니다. 이러한 취약성들은 대부분 응용 프로그램으로 전송되는 URL 이나 쿼리스트링이 단지 ‘너무 커서’ 또는 ‘콘텐츠가 너무 많아서’ 발생하는 경우가 대부분입니다. 서버 관리자가 안전한 최대값을 결정할 수 있다면, 응용 프로그램의 이진 파일들을 수정하지 않고서도 아래와 같은 구성설정을 사용해서 그 제한값을 적용할 수 있습니다.

HTTP 동사 필터링

기능 개요

이 기능은 IIS 가 요청으로 받아들일 동사들의 목록을 정의할 수 있게 해줍니다. 이 기능에 의해서 요청이 거부되면 404.6 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 UseAllowVerbs 옵션, AllowVerbs 옵션, 그리고 DenyVerbs 옵션의 기능과 동일합니다.

실제 예제

이 예제에서는 서버 관리자가 오직 하나의 동사, 즉 GET 동사만 허용하기를 원한다고 가정합니다. 이를 위해서 서버 관리자는 먼저 구성설정 파일에 allowUnlisted=”false” 옵션을 설정하여 명시적으로 지정하지 않은 모든 동사를 허용하지 않도록 설정합니다. 그리고, 그 다음에 허용하고자 하는 동사들의 목록을 명시적으로 지정합니다. 이 예제에서는 오직 GET 동사만을 허용합니다.

URL 문자열 시퀀스에 기반한 필터링

기능 개요

이 기능은 IIS 가 거부할 문자열 시퀀스의 목록을 정의합니다. 이 기능에 의해서 요청이 거부되면 404.5 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 URLScan 의 DenyUrlSequences 옵션의 기능과 동일합니다.

실제 예제

이 기능은 매우 강력합니다. 만약 IIS 에 의해 서비스 되지 않기를 바라는 어떤 문자열 시퀀스가 있다면, 그 문자열 시퀀스를 다음과 같이 구성설정에 추가할 수 있습니다.

이 예제에서는 ‘..’ 시퀀스를 거부합니다. 그러나, 보다 현실적인 시나리오는 여러분들이 이미 폐업한 판매자로부터 구매한 응용 프로그램을 갖고 있으며, 특수한 시퀀스의 문자열이 이 응용 프로그램으로 전송되었을 때 문제가 발생할 수 있다는 사실을 발견한 경우입니다. 여러분들은 이 기능을 사용하여 해당 응용 프로그램의 코드를 수정하지 않고서도 단순히 거부 목록에 URL 시퀀스를 추가하는 것만으로 응용 프로그램을 보호할 수 있습니다.


숨겨진 네임스페이스 필터링

기능 개요

이 기능은 ‘서비스 가능한’ 네임스페이스를 (또는 URL 구역) 정의할 수 있도록 해줍니다. 이 기능에 의해서 요청이 거부되면 404.8 오류 코드가 로그에 기록됩니다.

URLScan 의 동일한 기능

이 기능은 IIS 7.0 에서 새롭게 제공되는 기능으로 URLScan 에는 존재하지 않습니다.

실제 예제

이해를 돕기 위해서 서버에 다음과 같은 두 개의 URL 이 존재하는 경우의 예제를 생각해 보겠습니다.

• http://site.com/bin
• http://site.com/binary

우리들이 원하는 것은 binary 디렉터리의 콘텐츠들은 서비스를 허용하지만 bin 디렉터리의 콘텐츠들은 서비스를 허용되지 않는 것입니다. 그렇지만, 만약 URL 시퀀스 필터링 기능을 사용하여 “bin” 시퀀스를 거부하도록 설정한다면, 결국 두 개의 URL 이 모두 거부되고 말 것입니다. 다음과 같은 구성설정을 사용하여 오직 bin 디렉터리에 대한 접근만을 거부하고 binary 디렉터리 하위에 존재하는 콘텐츠에 대한 접근은 계속해서 허용하도록 지정할 수 있습니다.

요약

이전 버전의 IIS 에서 관리자들은 URLScan 을 사용하여 전역적인 수준의 보안 정책을 정의하고 자신들이 관리하는 시스템에 이를 적용할 수 있었습니다. IIS 7.0 에서 관리자들은 전역적인 수준뿐만 아니라 각각의 URL 들을 대상으로 동일한 정책을 적용할 수 있게 되었으며, 새롭고 풍부한 기능의 대체 모델이 제공하는 이점들을 이용할 수도 있습니다.

본문을 통해서 우리들은 요청이 거부될 때 요청 필터링이 리턴하는 몇 가지 새로운 오류 코드를 살펴보았습니다. 다음은 모든 IIS 로그 오류 코드를 정리한 간단한 참조 목록입니다.

오류	상태 코드
요청된 포트에서 웹 사이트에 액세스할 수 없습니다.	404.1
웹 서비스 확장 잠금 정책으로 인해 이 요청이 거부됩니다.	404.2
MIME 맵 정책으로 인해 요청이 거부됩니다.	404.3
핸들러가 존재하지 않습니다.	404.4
요청 필터링: URL 시퀀스로 인해 요청이 거부됩니다.	404.5
요청 필터링: HTTP 동사로 인해 요청이 거부됩니다.	404.6
요청 필터링: 파일 확장자로 인해 요청이 거부됩니다.	404.7
요청 필터링: 숨겨진 네밍스페이스로 인해 요청이 거부됩니다.	404.8
숨겨진 파일 속성이 설정되어 요청이 거부됩니다.	404.9
요청 필터링: 요청 헤더가 너무 길어서 요청이 거부됩니다.	404.10
요청 필터링: 이중 인코딩된 URL 로 인해 요청이 거부됩니다.	404.11
요청 필터링: 비 ASCII 문자로 인해 요청이 거부됩니다.	404.12
요청 필터링: 콘텐츠 길이가 너무 커서 요청이 거부됩니다.	404.13
요청 필터링: URL 이 너무 길어서 요청이 거부됩니다.	404.14
요청 필터링: 쿼리스트링이 너무 길어서 요청이 거부됩니다.	404.15

출처 : 한국 마이크로소프트 MSDN (2006년)

Windows Vista와 Windows Server Longhorn의 에디션에 따른 IIS 7의 차이점 개요

IIS 7 은 Windows Vista 와 Windows Server Longhorn 배포본의 모든 주요 Windows 에디션에서 최초로 사용할 수 있습니다. 그리고, Windows 서버상에서 IIS7 은 지금까지 마이크로소프트가 제공한 적이 없었던 최고의 웹 서버 역할을 제공하게 될 것입니다.

Windows Vista 의 각각의 에디션에서, IIS 7 은 두 가지 역할을 수행합니다. 그 첫 번째로, IIS 7 은 Windows XP 에서와 동일하게 웹 개발자들에게 서버에 배포하기 위한 웹 응용 프로그램 구축과 테스트를 위한 완벽한 웹 플랫폼 경험을 제공합니다. 두 번째로, 프로세스 활성화 및 관리, 그리고 Windows Communication Foundation (.NET 프레임워크 3.0) 을 사용하여 만들어진 연결된 소비자 활성화 시나리오에 필요한 HTTP 기반 구조를 제공합니다.

Windows Vista Starter 에디션과 Home 에디션

Windows Vista Starter 에디션과 Home 에디션은 웹 응용 프로그램을 실행하거나 웹 배포를 할 필요가 없는 가정과 개인 사용자들을 대상으로 하고 있습니다. IIS 7 웹 서버와 FTP 서버의 기능들은 이 에디션들에서는 사용할 수 없습니다. 그렇지만, 만약 자세하게 살펴본다면 여러분들은 이 에디션들에 설치할 수 있는 IIS 7 의 특정 구성 요소들을 발견할 수 있을 것입니다. 그러나, 이런 컴포넌트들을 설치한다고 하더라도, 정적 콘텐츠나 클래식 ASP, 또는 ASP.NET 등을 지원하는 웹 서버 기능이 제공되지는 않는다는 점에 주의하시기 바랍니다.

이 에디션들에서 사용 가능한 IIS 7 의 구성 요소들은 마이크로소프트의 Windows Communication Foundation (WCF) 기반 구조를 지원하기 위한 목적으로 제공되는 것입니다. 이러한 기반 구조를 제공하는 IIS 7 의 구성 요소들을 통칭하여 Windows 프로세스 활성화 서비스 (WAS) 라고 합니다. 그러나, WCF 기반의 응용 프로그램을 설치할 때 사용자가 명시적으로 WAS 를 설치할 필요는 없으며, 필요한 경우 WCF 에 의해서 자동으로 설치됩니다.

Vista Starter 에디션과 Home 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Vista Home Premium 에디션

Windows Vista Home Premium 에디션의 IIS 7 은 비전문적인 웹 개발자들이나 취미로 웹 개발을 하는 개발자들을 지원하기 위한 것으로서, 웹 사이트를 개발하기 위해 반드시 필요한 IIS 7 웹 서버의 대부분의 기능들이 지원됩니다. 그렇지만, 비전문적인 웹 개발에서 보편적으로 사용되지 않는 FTP 서버나 향상된 웹 인증과 권한 부여, 그리고 원격 관리등과 같은 기능들은 Vista Home Premium 에디션에서는 사용할 수 없습니다.

Vista Home Premium 에디션의 IIS 7 동시 요청 처리 제한값은 3 개 입니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Vista 프로페셔널 에디션

Windows Vista 프로페셔널 에디션의 IIS 7 은 전문적인 웹 개발자들을 그 직접적인 대상으로 하고 있으며, 전문적인 웹 개발자들이 웹 응용 프로그램을 설계, 개발, 그리고 테스트하기 위해 필요로 하는 모든 기능들을 제공합니다. (여기에서 얘기하고 있는 프로페셔널 에디션에는 Vista Business 에디션, Enterprise 에디션, 그리고 Ultimate 에디션이 포함됩니다.) 원격 관리를 제외한 Windows Server Longhorn 에서 제공하는 모든 IIS 7 의 기능들을 프로페셔널 에디션에서도 동일하게 사용할 수가 있습니다. 그리고, 프로페셔널 에디션에서는 동시 요청을 한 번에 10 개 까지 처리할 수 있습니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

Windows Server Longhorn 에디션

Windows Server Longhorn 의 IIS 7 은 원격 관리를 비롯한 모든 기능들에 대한 웹 응용 프로그램의 완전한 배포를 위해 준비되었으며, 당연히 동시 요청 처리에도 제한이 존재하지 않습니다.

이 에디션에서 사용할 수 있는 IIS 7 기능들의 목록은 본문 하단의 기능 정리표를 참고하시기 바랍니다.

IIS 7 Vista 에디션별 기능 정리표

화면 출력명 / 계층

패키지 업데이트명

Server

Pro

Premium

Basic & Starter

인터넷 정보 서비스

IIS-WebServerRole

가능

가능

가능

가능

World Wide Web 서비스

IIS-WebServer

기본

기본

기본

기본

공통 Http 기능

IIS-CommonHttpFeatures

기본

기본

기본

기본

정적 콘텐츠

IIS-StaticContent

기본

기본

기본

N/A

기본 문서

IIS-DefaultDocument

기본

기본

기본

N/A

디렉터리 나열

IIS-DirectoryBrowsing

기본

기본

기본

N/A

HTTP 오류

IIS-HttpErrors

기본

기본

기본

기본

HTTP 리디렉션

IIS-HttpRedirect

가능

가능

가능

가능

응용 프로그램 개발 기능

IIS-ApplicationDevelopment

가능

가능

가능

가능

ASP.NET

IIS-ASPNET

가능

가능

가능

N/A

.NET 확장성

IIS-NetFxExtensibility

가능

가능

가능

가능

ASP

IIS-ASP

가능

가능

가능

N/A

CGI

IIS-CGI

가능

가능

가능

N/A

ISAPI 익스텐션

IIS-ISAPIExtensions

가능

가능

가능

N/A

ISAPI 필터

IIS-ISAPIFilter

가능

가능

가능

N/A

Server-Side Includes

IIS-ServerSideInclude

가능

가능

가능

N/A

상태 진단

IIS-HealthAndDiagnostics

기본

기본

기본

기본

HTTP 로깅

IIS-HTTPLogging

기본

기본

기본

기본

로깅 도구

IIS-LoggingLibraries

가능

가능

가능

가능

요청 진단

IIS-RequestMonitor

기본

기본

기본

기본

추적

IIS-HttpTracing

가능

가능

가능

가능

사용자 정의 로깅

IIS-CustomLogging

가능

가능

가능

N/A

ODBC 로깅

IIS-ODBCLogging

가능

가능

N/A

N/A

보안

IIS-Security

가능

가능

가능

가능

기본 인증

IIS-BasicAuthentication

가능

가능

가능

N/A

Windows 인증

IIS-WindowsAuthentication

가능

가능

N/A

N/A

다이제스트 인증

IIS-DigestAuthentication

가능

가능

N/A

N/A

클라이언트 인증서 맵핑 인증

IIS-ClientCertificateMappingAuthentication

가능

가능

N/A

N/A

IIS 클라이언트 인증서 맵핑 인증

IIS-IISCertificateMappingAuthentication

가능

가능

N/A

N/A

URL 인증

IIS-URLAuthorization

가능

가능

가능

가능

요청 필터링

IIS-RequestFiltering

가능

가능

가능

가능

IP 보안

IIS-IPSecurity

가능

가능

가능

가능

성능

IIS-Performance

기본

기본

기본

가능

정적 콘텐츠 압축

IIS-HttpCompressionStatic

기본

기본

기본

N/A

동적 콘텐츠 압축

IIS-HttpCompressionDynamic

가능

가능

가능

가능

웹 관리 도구

IIS-WebServerManagementTools

기본

기본

기본

기본

IIS 관리 콘솔

IIS-ManagementConsole

기본

기본

기본

N/A

IIS 관리 스크립트 및 도구

IIS-ManagementScriptingTools

가능

가능

가능

가능

IIS 관리 서비스

IIS-ManagementService

가능

가능

가능

N/A

IIS 6 관리 호환성

IIS-IIS6ManagementCompatibility

가능

가능

가능

가능

IIS 메타베이스 및 IIS 6 호환성

IIS-Metabase

가능

가능

가능

가능

IIS 6 WMI 호환성

IIS-WMICompatibility

가능

가능

가능

N/A

IIS 6 스크립팅 도구

IIS-LegacyScripts

가능

가능

가능

N/A

IIS 6 관리 콘솔

IIS-LegacySnapIn

가능

가능

가능

N/A

FTP 퍼블리싱 서비스

IIS-FTPPublishingService

가능

가능

N/A

N/A

FTP 서버

IIS-FTPServer

가능

가능

N/A

N/A

FTP 관리 콘솔

IIS-FTPManagement

가능

가능

N/A

N/A

Windows 활성화 서비스

WAS-WindowsActivationService

가능

가능

가능

가능

프로세스 모델

WAS-ProcessModel

기본

기본

기본

기본

.NET 환경

WAS-NetFxEnvironment

가능

가능

가능

가능

구성설정 APIs

WAS-ConfigurationAPI

가능

가능

가능

가능

동시 요청 처리 제한값

제한 없음

10

3

3

요약

본문에서는 Windows Vista 와 Server Longhorn 의 각각의 에디션이 제공하는 IIS 7 의 차이점들에 대해서 살펴보았습니다. 각각의 Windows Vista 와 Windows Server Longhorn 에디션에서 IIS 7 설치를 사용자 정의하는 방법에 대한 추가적인 정보들은 다음의 관련 링크들에서 살펴보실 수 있습니다.

관련 링크

보다 자세한 정보는 다음의 기사들을 참고하십시오.

IIS7 설치 개요 (영문)
Longhorn Server 에서 IIS7 을 설치하는 방법 (영문)
Windows Vista Beta 2 에서 IIS7 을 설치하는 방법 (영문)
명령 프롬프트를 통한 IIS7 설치 방법 (영문)
IIS7 무인 설치 방법 (영문)

출처 : 한국 마이크로소프트 MSDN (2006년)

서론

이전 버전의 IIS 에는 설치시에 생성되는 IUSR_MachineName 라는 로컬 계정이 존재했습니다. 이 IUSR_MachineName 계정은 익명 인증이 활성화되어 있는 경우 IIS 에 의해서 기본 신원계정으로 사용되며, FTP 서비스와 HTTP 서비스 모두 이 계정을 사용했습니다. 그리고, 응용 프로그램 풀의 신원 계정으로 사용되는 모든 계정들을 포괄하기 위한 목적으로 IIS_WPG 라는 그룹도 존재했습니다. IIS 가 설치되는 동안 시스템에 존재하는 모든 적절한 리소스에는 IIS_WPG 그룹에 대한 올바른 권한 모음이 설정되었습니다. 그래서, 관리자들은 새로운 응용 프로그램 풀 계정을 생성하면 그 계정을 IIS_WPG 그룹에 추가해야만 했었습니다.

이 모델은 대단히 잘 동작했지만, 대부분의 설계들이 그런 것처럼 이 모델에도 단점은 존재했으며, 그 중에서도 IUSR_MachineName 계정과 IIS_WPG 그룹이 생성된 시스템에 국한되는 계정이라는 점이 가장 큰 단점이었습니다. Windows 의 모든 계정과 그룹은 다른 계정들과 구분되는 SID (Security IDentifier) 라고 불리우는 유일한 번호를 부여받는데, ACL 이 생성될 때 바로 이 SDI 가 사용됩니다. IIS 의 기존 버전에서는 IUSR_MachineName 계정 정보가 metabase.xml 파일에 저장되도록 설계되었는데, 여러분들이 metabase.xml 파일을 한 머신에서 다른 머신으로 복사한다고 하더라도, 대상 머신의 IUSR_MachineName 계정은 본래 머신의 계정과 다른 SID 를 가지고 있기 때문에 IIS 가 곧바로 동작하지 않았습니다. 게다가, 머신과 머신간의 SID 는 서로 다르므로 'xcopy /o' 명령만으로는 한 머신에서 다른 머신으로 ACL 을 복사할 수도 없습니다. 도메인 계정을 사용하는 방법도 있지만, 그렇게 되면 여러분들의 네트워크 기반 구조에 엑티브 디렉터리를 추가해야만 합니다. 그리고, IIS_WPG 그룹도 권한과 관련된 비슷한 문제점을 갖고 있었습니다. 만약 여러분들이 어떤 머신의 파일 시스템에 IIS_WPG 그룹에 대한 ACL 을 설정한 다음, 'xcopy /o' 명령을 사용하여 또 다른 머신으로 복사를 시도한다면 그 작업은 실패하게 될 것입니다. IIS 팀에서는 이러한 문제점에 대한 피드백을 받아들여 내장 계정과 그룹을 사용하여 IIS 7.0 을 개선했습니다.

내장 계정과 그룹은 운영체제 시스템에 의해 언제나 동일한 SID 를 보장받습니다. 그리고, IIS 는 이를 더욱 적극적으로 받아들여 새로운 계정과 그룹의 실제 이름이 결코 지역화되지 않도록 보장합니다. 예를 들어서, 설치된 Windows 의 언어와는 관계없이, 언제나 IIS 계정의 이름은 IUSR 가 되고 그룹의 이름은 IIS_IUSRS 가 됩니다.

이를 정리하면, IIS 7.0 에서는:

• IUSR 내장 계정이 기존의 IUSR_MachineName 계정을 대체합니다.
• IIS_IUSRS 내장 그룹이 기존의 IIS_WPG 그룹을 대체합니다.

내장된 계정인 IUSR 계정은 비밀번호가 필요하지 않습니다. 그리고, 여러분들은 논리적으로 이 계정은 NETWORKSERVICE 계정이나 LOCALSERVICE 계정과 동일한 것으로 간주할 수 있습니다. 다음 섹션에서 IUSR 계정과 IIS_IUSRS 그룹에 대해서 보다 깊게 알아보도록 하겠습니다.

새로운 IUSR 계정에 대한 이해

앞에서 설명했던 것과 같이, IIS 7.0 에서는 IUSR 계정이 IUSR_MachineName 계정을 대체합니다. 그러나, IUSR_MachineName 계정도 여전히 생성되고 사용되는데, 이는 오직 FTP 서버가 설치된 경우에만 해당됩니다. 만약 FTP 서버가 설치되지 않는다면 이 계정은 결코 생성되지 않을 것입니다.

IUSR 내장 계정은 비밀번호를 요구하지 않으며 익명 인증이 활성화된 경우 기본 신원계정으로 사용되어집니다. 만약, 여러분들이 applicationHost.config 파일을 살펴본다면 다음과 같이 정의된 부분을 쉽게 찾아보실 수 있을 것입니다.

이 부분은 우리들이 모든 익명 인증 요청에 대해서 이 새로운 내장 계정을 사용하기를 원한다는 것을 IIS 에게 말해줍니다. 이러한 결과로 우리들이 얻을 수 있는 커다란 이점은 다음과 같습니다.

• 탐색기나 그 밖의 다양한 명령 프롬프트 도구들을 사용하여 IUSR 계정에 대한 파일 시스템 권한을 설정할 수 있습니다.
• 더 이상 IUSR 계정의 비밀번호 만료에 대해서 걱정할 필요가 없습니다.
• 파일들을 소유권 정보와 ACL 정보까지 포함하여 xcopy /o 명령을 통해 다른 머신에 완벽하게 복사할 수 있습니다.

가장 중요한 점은 IUSR 계정이 LOCALSERVICE 계정과 유사하게 네트워크상에서 익명으로 동작한다는 사실입니다. NETWORKSERVICE 계정과 LOCALSYSTEM 계정은 머신의 자격 증명으로 동작할 수 있지만 IUSR 계정은 권한 승격으로 인해서 그럴수가 없습니다. 만약, 여러분들이 익명 계정에 네트워크 권한을 부여하고자 한다면, 기존 버전에서 익명 인증을 위해서 작업했던 것과 같이 새로운 계정을 생성하고 수작업으로 사용자 이름과 비밀번호를 설정해야만 합니다. IIS 관리자를 사용하여 이 작업을 처리하려면:

• 시작을 클릭한 다음 'INetMgr.exe' 를 입력하고 엔터키를 누릅니다. (만약, 보안 경고 대화 상자가 나타난다면 "계속' 버튼을 선택하여 권한을 승격시키십시오.)
• "Connections" 섹션에서 여러분들의 머신 이름이 적힌 노드 좌측에 위치한 "+" 버튼을 클릭합니다.
• 웹 사이트 노드에서 여러분들이 관리하고자 하는 사이트를 더블 클릭합니다.
• "Feature Name" 이 "Authentication" 인 항목을 더블 클릭합니다.
• "Anonymous Authentication" 을 선택하고, 화면 오른편에 위치한 "Actions" 섹션에서 "Edit" 버튼을 클릭하여 "Edit Anonymous Authentication Credentials" 대화 상자를 불러옵니다.
• "Specific User" 옵션을 선택하고 그 옆의 "Set" 버튼을 누릅니다.
• 원하는 사용자 이름과 비밀번호, 비밀번호 확인을 입력하고 "OK" 버튼을 누릅니다.

새로운 IIS_IUSRS 그룹에 대한 이해

이미 앞에서 설명했던 것처럼, IIS_IUSRS 그룹은 IIS_WPG 그룹을 대체하기 위한 목적으로 만들어 졌습니다. 이 내장 그룹은 필요한 모든 파일과 시스템 리소스에 대한 접근 권한을 갖고 있으며, 바로 그렇기 때문에 어떤 계정이 이 그룹에 포함되면, 아무런 문제없이 응용 프로그램 풀 신원 계정으로 동작할 수 있게 됩니다.

내장 IUSR 계정의 경우와 마찮가지로 내장 IIS_IUSRS 그룹도 몇 가지 XCOPY 배포의 문제점들을 해결해줍니다. 만약, 여러분들이 IIS_WPG 그룹에 대해서 - IIS 6 시스템에서 사용가능한 - 여러분들의 파일에 권한을 설정하고, 그 파일들을 다른 Windows 머신에 복사하려고 한다면, 이 그룹의 SID 는 머신들마다 다르므로 여러분들의 사이트 구성설정은 깨지게 될 것입니다.

그러나, IIS7 에서 IIS_IUSRS 그룹의 SID 는 롱혼이 실행되는 모든 시스템에서 동일하기 때문에, 'xcopy /o' 명령을 사용하여 머신에서 머신으로 파일들을 복사할 때 소유권 정보와 ACL 정보가 그대로 유지됩니다. 결과적으로 XCOPY 배포가 극단적으로 쉬워지는 것입니다.

고객들이 요청한 두 번째 사항은 '응용 프로그램 풀의 신원 계정을 설정하면 IIS 가 사용자를 대신하여 자동으로 필요한 모든 변경작업을 대신 처리해달라.' 라는 것이었습니다. IIS 팀에서는 이 피드백을 수용하여 IIS 7.0 에서는 이 작업을 보다 편리하게 만들었습니다. IIS 가 작업자 프로세스를 시작할 때, 이 작업에는 작업자 프로세스에서 사용될 토큰의 생성이 필요합니다. 이제는 이 토큰이 생성될 때, IIS 가 자동적으로 IIS_IUSRS 그룹의 계정들을 런타임시에 작업자 프로세스 토큰에 추가합니다. 그래서 결과적으로 '응용 프로그램 풀 신원 계정'으로 동작하도록 정의된 계정을 더 이상 명시적으로 IIS_IUSRS 그룹에 포함시킬 필요가 없어졌습니다. IIS 팀에서는 이러한 변화가 여러분들의 시스템 설정을 보다 덜 번거롭도록 도와주고 전반적인 작업을 편리하게 만들어줄 것이라고 믿고 있습니다.

그러나, 만약 여러분들이 이 새로운 기능을 비활성화 시키고 수작업으로 IIS_IUSRS 그룹에 계정을 추가하는 것을 선호한다면, 언제라도 manualGroupMembership 속성의 값을 'true' 로 설정하여 이 새로운 기능을 비활성화시킬 수 있습니다. 다음은 defaultAppPool 을 대상으로 해당 설정을 적용한 예입니다.

출처 : 한국 마이크로소프트 MSDN (2006년)

통합된 ASP.NET 모드의 이용

II7 에서 ASP.NET 응용 프로그램은 기본적으로 통합 모드로 실행됩니다. 그렇지만, 견고한 통합이 제공하는 이점을 이용하기 위해서는 응용 프로그램 구성설정을 일부 수정해야만 합니다. 더 나아가, 여러분들의 응용 프로그램에 보다 강력한 기능을 부여하기 위해서 여러분들은 통합 모드를 이용하는 새로운 ASP.NET 구성요소를 개발할 수도 있습니다.

모든 유형의 콘텐츠에 대한 ASP.NET 서비스 활성화

통합 모드에서 ASP.NET 모듈에 의해 제공되는 서비스들은 모든 유형의 콘텐츠 요청을 대상으로 실행될 수 있습니다. 그러나, 하위 호환성을 유지하기 위한 목적 때문에 기본적으로 ASP.NET 모듈은 ASP.NET 콘텐츠에 대한 요청만을 대상으로 실행되도록 구성되어져 있습니다.

이러한 결과는 서버 수준의 구성설정 섹션에 설정된 각각의 ASP.NET 모듈에 추가된 managedHandler 전제 조건 속성값으로 인해 얻어집니다.

이 preCondition 속성은 서버가 해당 모듈이 모든 요청을 대상으로 실행되어야 할지 말아야 할지를 결정하기 위해 사용하는 기준값입니다. managedHandler 속성값은 지금 현재 ASP.NET 핸들러와 맵핑되어 있는 콘텐츠 유형들에 대한 요청에 대해서만 ASP.NET 모듈이 실행되도록 지정합니다.

만약 여러분들이 ASP.NET 모듈이 제공하는 기능을 모든 요청을 대상으로 적용하고 싶다면, 해당 모듈 항목을 제거한 다음, 여러분들의 응용 프로그램의 최상위 web.config 파일에 preCondition 속성만을 제외하여 다시 추가하면 됩니다. 예를 들어서, ASP.NET 폼 기반 인증을 여러분들의 응용 프로그램 전체를 대상으로 적용하고 싶다면 다음과 같이 지정하면 됩니다.

이렇게 변경함으로서 FormsAuthentication 모듈은 여러분들의 응용 프로그램에 대한 모든 요청을 대상으로 동작할 것입니다. 그리고 폼 기반 인증 서비스가 여러분들의 응용 프로그램 콘텐츠 전체를 보호해주게 됩니다. 모든 응용 프로그램 콘텐츠를 대상으로 폼 기반 인증을 제공하기 위해 통합 모드를 활용하는 방법에 대한 보다 많은 정보를 얻으시려면, Taking advantage of Integrated mode walkthrough 를 참고하시기 바랍니다.

그리고, 여러분들이 "managedHandler" 전제 조건에 관계없이, 모든 관리되는 (ASP.NET) 모듈들이 응용 프로그램에 대한 모든 요청을 대상으로 동작하도록 활성화시킬 수 있는 손쉬운 방법도 존재합니다. 각각의 모듈 항목에서 일일이 "managedHandler" 전제 조건을 제거하지 않으면서도 모든 요청을 대상으로 모든 관리되는 모듈을 활성화시키려면, 다음과 같이 <modules> 섹션에 runAllManagedModulesForAllRequests 속성을 추가합니다.

이 속성이 사용되면, "managedHandler" 전제 조건은 무시되고 모든 관리되는 모듈들은 모든 요청을 대상으로 동작합니다.

여러분들은 다른 ASP.NET 모듈들이 여러분들의 전체 응용 프로그램에 적용되도록 활성화시는 실험을 해볼 수도 있습니다. 대표적인 경우로, ASP 페이지의 출력을 캐시하기 위해 ASP.NET 출력 캐시 모듈을 적용해본다거나, 여러분들의 사진에 대한 접근 제한 설정을 하기 위해 Url 인증과 역할 관리자를 적용해볼 수도 있습니다. 아니면, 여러분들이 직접 자신만의 모듈을 개발하여 여러분들의 전체 웹 사이트에 ASP.NET 의 기능들을 적용할 수도 있습니다.

보다 강력한 ASP.NET 서비스의 구현

통합 모드에서 ASP.NET 모듈은 모든 콘텐츠를 대상으로 서비스를 제공할 수 있습니다. 게다가 통합 모드에서 ASP.NET 은 통합된 요청 처리 파이프 라인상에서 실행되기 때문에, 네이티브 서버 모듈과 동일한 요청 처리 단계를 구독할 수 있으며 동일한 작업을 수행할 수 있습니다. 또한, ASP.NET APIs 는 이전에는 사용할 수 없었던 몇 가지 중요한 기능들이 제공되는 것을 제외한다면 대부분 예전과 동일합니다.

런타임 충실도

통합 모드상에서 모듈에 노출되어 있는 ASP.NET 요청 처리 단계들은 IIS 파이프 라인의 일치하는 단계에 직접적으로 연결되어 있습니다. 전체 파이프 라인은 다음의 단계들을 포함하고 있으며, 이 단계들은 ASP.NET 상에서 HttpApplication 이벤트로 노출됩니다.

1. BeginRequest. 요청 처리를 시작합니다.
2. AuthenticateRequest. 요청이 인증됩니다. 이 단계에서 IIS 와 ASP.NET 인증 모듈이 인증을 수행합니다.
3. PostAuthenticateRequest
4. AuthorizeRequest. 요청에 권한이 부여됩니다. IIS 와 ASP.NET 권한 부여 모듈이 인증된 사용자에게 요청된 리소스에 접근할 권한이 있는지 검사합니다.
5. PostAuthorizeRequest
6. ResolveRequestCache. 캐시 모듈이 해당 요청에 대한 응답이 이미 캐시에 존재하는지 파악하고, 남아 있는 이후의 단계들을 실행하는 대신 캐시에 존재하는 응답을 리턴할 수 있습니다. ASP.NET 출력 캐시 기능과 새로운 IIS 출력 캐시 기능이 모두 이 단계에서 실행됩니다.
7. PostResolveRequestCache
8. MapRequestHandler. ASP.NET 의 내부 단계이며, 요청 핸들러가 결정됩니다.
9. PostMapRequestHandler
10. AcquireRequestState. 요청 실행을 위해 필요한 상태를 가져옵니다. ASP.NET 세션 상태, 그리고 프로파일 모듈들이 이 단계에서 데이터를 가져옵니다.
11. PostAcquireRequestState
12. PreExecuteRequestHandler. 핸들러가 실행되기 전에 필요한 일련의 작업들이 이 단계에서 실행될 수 있습니다.
13. ExecuteRequestHandler. 요청 핸들러가 실행됩니다. ASPX 페이지, ASP 페이지, CGI 프로그램, 그리고 정적 페이지들이 이 단계에서 처리됩니다.
14. PostExecuteRequestHandler
15. ReleaseRequestState. 변경된 요청 상태가 저장되고 정리됩니다. 이 단계에서 ASP.NET 세션 상태와 프로파일 모듈들의 상태가 정리됩니다.
16. PostReleaseRequestState
17. UpdateRequestCache. 다음에 사용될 응답이 캐시에 저장됩니다. 이 단계에서 ASP.NET 출력 캐시와 IIS 출력 캐시 모듈이 각각의 캐시에 응답을 저장하기 위해 실행됩니다.
18. PostUpdateRequestCache
19. LogRequest. 요청 처리 결과를 로그에 기록합니다. 만약 오류가 발생하더라도 이 단계는 실행됩니다.
20. PostLogRequest
21. EndRequest. 일련의 마지막 처리가 수행됩니다. 만약 오류가 발생하더라도 이 단계는 실행됩니다.

통합 모드에서 실행되는 ASP.NET 요청 처리 단계들이 IIS 모듈과 같은 단계를 공유한다는 사실은, 과거 네이티브 ISAPI 필터나 익스텐션을 사용해서만 가능했던 많은 작업들을, 이제는 친숙한 ASP.NET APIs 와 풍부한 .NET 플랫폼의 기능들을 사용하는 관리되는 코드만으로도 가능하게 만들었습니다. 예를 들어서, 여러분들은 다음과 같은 작업을 처리하는 모듈을 작성할 수도 있습니다.

1. 요청이 다른 작업에 의해서 처리되기 전에 가로챌 수 있습니다. 예를 들어서 Url 을 다시 기록하거나 보안 필터링을 실행할 수 있습니다.
2. 기본 제공되는 인증 모드를 교체할 수 있습니다.
3. 요청 헤더와 같은 들어오는 요청의 내용을 수정할 수 있습니다.
4. 모든 콘텐츠 유형의 나가는 응답을 필터링할 수 있습니다.

사용자 정의 ASP.NET 인증 모듈을 사용하여 IIS 를 확장하는 훌륭한 샘플을 Developing an IIS7 module with .NET (영문) 에서 살펴볼 수 있습니다.

ASP.NET APIs 확장

여전히 ASP.NET APIs 는 이전 버전과의 하위 호환성을 유지하고 있으며, 이는 기존의 모듈들이 수정없이 IIS7 에서 동작할 수 있도록 해주고 모든 응용 프로그램 콘텐트의 코드 변경을 불필요하게 만들어줍니다.

그렇기는 하지만, IIS7 통합 모드를 위해 작성된 모듈들은 지금까지는 처리가 불가능했던 핵심적인 요청 처리 시나리오를 지원하기 위해 추가된 몇 가지 APIs 의 이점을 얻을 수 있습니다.

이를테면, 새로운 HttpResponse.Headers 컬렉션을 이용하여 다른 응용 프로그램 구성요소에 의해서 생성된 요청 헤더를 모듈로 분석하거나 조작할 수 있습니다. 한 가지 예로, 여러분들은 브라우저에 다운로드 대화상자가 나타나도록 ASP 페이지에서 생성된 Content-Type 헤더를 변경할 수도 있습니다. 더군다나 HttpResponse 클래스가 제공하는 Cookies 컬렉션은 요청 처리 작업의 일부로 만들어진 쿠키의 수정까지도 가능하도록 개선되었으며, 심지어는 쿠키가 ASP.NET 외부에서 생성되었다고 하더라도 변함없이 수정이 가능합니다.

HttpRequest.Headers 컬렉션도 기록이 가능해졌으며 모듈에서 들어오는 요청 헤더를 조작할 수 있게 해줍니다. 이와 같은 변화는 다른 서버 구성요소의 동작을 변경하는데 사용될 수 있습니다. 예를 들어서, 여러분들은 Accept-Language 헤더의 값을 동적으로 변경하여 지역화된 응용 프로그램이 다른 언어를 사용하여 클라이언트에게 응답하게 할 수 있습니다.

마지막으로 HttpRequest.ServerVariables 컬렉션도 역시 기록이 가능해졌으며 IIS 서버 변수들의 값을 설정할 수 있게 되었습니다. ASP.NET 모듈은 IIS 가 제공하는 값들을 변경하거나, PHP 와 같은 다른 응용 프로그램 프레임워크에게 노출하기 위한 목적으로 새로운 서버 변수를 만들어 낼 수도 있습니다.

런타임 통합

새롭게 제공되는 APIs 와 함께, 통합 모드는 기존의 ASP.NET 의 기능들이 여러분들의 응용 프로그램에 보다 많은 가치를 제공해줄 수 있도록 지원해줍니다.

이제 System.Diagnostics.Trace 클래스와 ASP.NET 페이지 추적 기능 등, ASP.NET 으로부터 제공되는 추적 기능들은 추적된 정보를 IIS 추적 시스템으로 출력할 수 있습니다. 결과적으로 IIS 나 ASP.NET 이 요청을 처리하면서 발생한 모든 추적 정보를 단일 로그 파일에 저장할 수 있게 되었으며, 서버상의 문제점들을 분석하기가 더욱 편리해졌습니다.

클라이언트로 응답이 전송되기 전에 스트림 인터페이스를 통해 응답 내용을 수정할 수 있도록 해주는 ASP.NET 의 응답 필터링 기능 역시, 비 ASP.NET 콘텐츠를 대상으로도 동작할 수 있도록 향상되었습니다. 따라서 여러분들은 ASP.NET 필터링을 모든 서버 콘텐츠에 적용하거나, 일부 원하는 유형의 콘텐츠들만을 대상으로 동작하도록 선택적으로 설치할 수 있습니다. 이 기능을 이용하면, 해당 콘텐츠가 ASPX 페이지인지 정적 파일인지 전혀 신경쓰지 않고서도, 여러분들의 사이트 응답에서 임의의 콘텐츠들을 대상으로 주입 또는 검열을 실시하는 필터링 기능을 작성할 수 있습니다.

요약

IIS7 과 ASP.NET 의 통합은 ASP.NET 의 모든 가능성을 활짝 열어주어, 개발자들로 하여금 쉽고 풍부한 기능의 ASP.NET 과 .NET 프레임워크를 사용하여 강력한 서버 구성 요소들을 작성할 수 있도록 해줍니다. 기존 응용 프로그램들을 위한 ASP.NET 통합 모드 활용에 대한 보다 상세한 내용은 통합된 ASP.NET 모드의 이용을 참고하시기 바랍니다. 그리고, 서버 확장을 위한 새로운 ASP.NET 구성요소를 작성하는 방법에 관한 정보는 Developing an IIS7 module with .NET (영문) 을 참고하시기 바랍니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

호환성

가장 주목할 만한 부분은, 통합된 아키텍처가 기존의 ASP.NET 런타임 아키텍처와 APIs 를 여전히 지원하므로, 기존의 ASP.NET 응용 프로그램과 서비스 대부분이 수정을 거치지 않고서도 정상적으로 동작한다는 점입니다. 게다가 단지 약간의 수정만으로도 새로운 ASP.NET 기능들의 이점을 누리도록 변경할 수 있습니다.

ASP.NET 응용 프로그램을 통합 모드에서 실행할 수 있도록 설정하는 방법에 대한 보다 자세한 정보는 IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션을 참고하시기 바랍니다.

게다가, 개발자들은 런타임 통합으로 인한 이득을 누리면서도, 계속해서 친숙한 기존의 ASP.NET APIs 를 사용하여 새로운 응용 프로그램을 작성할 수 있습니다.

IIS7 은 통합 모드에서 지원되지 않는 특정한 호환성이 요구되는 ASP.NET 응용 프로그램을 위한 "클래식" ASP.NET 모드를 지원합니다. 관리자는 응용 프로그램 풀 단위로 필요한 통합 모드를 선택할 수 있으며, 결과적으로는 새로운 통합 모드를 사용하는 응용 프로그램과 클래식 ASP.NET 모드를 사용하는 응용 프로그램을 동일한 서버에서 함께 운영할 수 있습니다.

두 가지 ASP.NET 통합 모드간의 전환에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.


IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션

기본적으로 IIS7 은 ASP.NET 이 새로운 통합 모드에서 동작하도록 구성되어 있습니다. 따라서, 여러분들의 응용 프로그램은 최소한의 변경만으로도 향상된 통합 모드의 이점을 얻을 수 있습니다.

구성설정이 통합되었기 때문에 일부 응용 프로그램들은 통합 모드에서 운영되기 위해서는 마이그레이션이 필요할 수도 있습니다. 기본적으로 서버는 마이그레이션을 지원하기 위해 응용 프로그램이 마이그레이션을 필요로 하는지를 감지하고, 응용 프로그램을 마이그레이션하기 위해 요구되는 내용들을 오류 메시지로 리턴합니다.

다음과 같은 구성설정은 마이그레이션 오류를 발생시킵니다.

1. 응용 프로그램의 web.config 파일이 <httpModules> 구성설정 섹션을 정의합니다.
   응용 프로그램이 새로운 ASP.NET 모듈을 로드하거나, 기존 모듈 중 하나를 제거합니다. 통합 모드상에서 ASP.NET 모듈은 네이티브 모듈과 함께 통합된 <system.webServer>/<modules> 구성설정 섹션에 지정됩니다. <system.web>/<httpModules> 구성설정 섹션에 지정된 ASP.NET 모듈이 정상적으로 동작하기 위해서는 새로운 구성설정 섹션으로 이동되어야만 합니다. 새로운 ASP.NET 모듈은 통합된 섹션에 직접 추가되어야만 합니다.
   
2. 응용 프로그램의 web.config 파일이 <httpHandlers> 구성설정 섹션을 정의합니다.
   응용 프로그램이 일부 콘텐츠 유형을 대상으로 사용자 정의 핸들러 맵핑을 사용합니다. 통합 모드에서 ASP.NET 핸들러 맵핑이 정상적으로 동작하기 위해서는 통합된 <system.webServer>/<handlers> 구성설정 섹션을 통해 지정되어야만 합니다. 새로운 ASP.NET 핸들러 맵핑은 통합된 <handlers> 섹션에 직접 추가되어야만 합니다. <handlers> 섹션은 이전 버전에서 ASP.NET 핸들러 맵핑을 설정하기 위해 사용되던 ASP.NET <httpHandlers> 구성설정과 IIS 스크립트맵 구성설정을 모두 대체합니다.
   
3. 응용 프로그램의 web.config 파일이 <identity impersonate=”true” /> 구성설정 섹션을 정의합니다.
   응용 프로그램이 클라이언트의 신원을 가장합니다. (대부분 인트라넷 응용 프로그램의 경우) 통합 모드에서 클라이언트 신원 가장 기능은 일부 초기 요청 처리 단계에서 사용이 불가능합니다. 이런 경우, 대부분 오류 발생을 무시하도록 설정해도 크게 문제가 되지 않으며, 또는 응용 프로그램이 클래식 ASP.NET 모드에서 실행되도록 구성할 수도 있습니다.

이와 같은 오류가 발생하는 경우, 일반적으로 응용 프로그램의 구성설정을 마이그레이션하거나 (첫 번째나 두 번째 경우 추천), 응용 프로그램이 클래식 ASP.NET 모드를 사용하도록 전환할 수 (세 번째 경우 추천) 있습니다.


응용 프로그램 구성설정 마이그레이션

IIS7 은 마이그레이션 작업을 수행해주는 APPCMD.EXE 명령줄 도구를 통해서 여러분들의 응용 프로그램 마이그레이션 작업을 여러분 대신 처리해줄 수 있습니다. 대부분의 마이그레이션 오류 메시지에는 여러분들의 응용 프로그램을 통합 모드에 알맞게 즉시 마이그레이션 할 수 있게 해주는, 관리자 권한 명령어 실행창에서 실행 가능한 명령어가 포함되어 있습니다.

마이그레이션 명령어의 기본적인 형식은 다음과 같습니다.

[Application Path] 에는, 예를 들어서 “기본 웹 사이트/app1” 과 같은 사이트 이름을 포함한 가상 경로가 위치합니다.

마이그레이션을 마친 뒤, 여러분들의 응용 프로그램은 통합 모드와 클래식 모드 양쪽에서 모두 정상적으로 동작할 것입니다.

일단 마이그레이션을 마친 뒤에는, 여러분들이 다시 구성설정을 변경한다고 하더라도 서버는 다시 마이그레이션을 하라는 메시지를 지원하지 않는다는 점을 명심하시기 바랍니다. 최초의 마이그레이션 작업이 끝난 다음부터 두 모드 사이의 구성설정 동기화에 대한 모든 책임은 여러분들의 몫입니다. – 여러분들은 다시 한 번 APPCMD.EXE 명령줄 도구를 실행하여 수작업으로 응용 프로그램의 마이그레이션을 수행할 수 있습니다.


클래식 ASP.NET 통합 모드 전환

만약 여러분들이 다시 클래식 ASP.NET 모드를 사용하고 싶다면, 그저 간단히 여러분들의 응용 프로그램을 클래식 모드에서 실행되도록 구성된 응용 프로그램 풀로 이동하기만 하면 됩니다. 해당 응용 프로그램 외의 다른 모든 응용 프로그램들은 클래식 모드 응용 프로그램과 함께 여전히 새로운 통합 모드에서 실행될 것입니다.

응용 프로그램을 클래식 ASP.NET 모드로 이동하는 방법에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.

마이그레이션 오류 메시지 비활성화

만약 여러분들이 수작업으로 응용 프로그램을 마이그레이션하거나, 통합 모드를 사용함에도 불구하고 구성설정을 마이그레이션하고 싶지 않다면 (추천하지 않음), 응용 프로그램의 web.config 파일에 다음과 같은 구성설정 섹션을 추가하여 마이그레이션 오류 메시지를 비활성화 시킬수 있습니다.

주의 : 앞에서 설명한 APPCMD.EXE 명령줄 도구를 사용하여 구성설정을 마이그레이션하고 나면 서버는 자동적으로 오류 메시지를 비활성화 시킵니다. 만약 수작업으로 마이그레이션 오류 메시지를 비활성화 시킨다면, 여러분들은 앞에서 설명했던 지원되지 않는 구성설정에 대한 어떠한 경고 메시지도 더이상 서버로부터 제공되지 않는 상태에서, 응용 프로그램이 통합 모드상에서 적절히 동작하도록 책임져야만 합니다.


응용 프로그램을 위한 ASP.NET 모드 변경

만약 여러분들의 응용 프로그램이 통합된 ASP.NET 모드에서 올바르게 동작하지 않는다면, 응용 프로그램을 다른 응용 프로그램 풀로 이동하여 간단하게 클래식 ASP.NET 모드로 이동할 수 있습니다. 이는 각각의 응용 프로그램 풀이 개별적으로 필요한 통합 모드를 사용하도록 구성되어질 수 있기 때문에 가능한 일입니다. 게다가 이러한 특징은 서로 다른 ASP.NET 통합 모드를 사용하는 응용 프로그램들의 그룹이 동일 서버상에서 함께 실행될 수 있게 해줍니다.

응용 프로그램의 ASP.NET 통합 모드를 변경하려면 다음과 같이 하십시오.

1. 원하는 모드로 구성된 응용 프로그램 풀을 찾거나 생성하십시오.
   기본적으로 시스템상의 모든 새로운 응용 프로그램 풀은 통합 모드에서 실행됩니다. ASP.NET 은 "Classic .NET AppPool" 라는 이름의 클래식 ASP.NET 통합 모드로 실행되는 응용 프로그램 풀을 제공합니다. 여러분들은 새로운 통합 모드에서 실행되면 안되는 응용 프로그램들을 위해서 이 응용 프로그램 풀을 사용할 수 있습니다. 그리고 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램 풀 구성설정을 변경하여 기존 응용 프로그램 풀의 ASP.NET 모드를 변경할 수도 있습니다.
   
2. 해당 응용 프로그램 풀을 사용하도록 응용 프로그램을 설정하십시오.
   각각의 응용 프로그램들은 개별적으로 응용 프로그램 풀을 사용하도록 구성됩니다. 기본적으로 모든 응용 프로그램은 통합 모드에서 동작하는 "DefaultAppPool" 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램의 응용 프로그램 풀 설정을 변경할 수 있습니다.

응용 프로그램을 위한 ASP.NET 버전 선택

역사적으로 IIS 는 여러 버전의 ASP.NET / CLR 을 동시에 지원해 왔으며, 예를 들어 동일한 서버에서 .NET 프레임워크 v1.1 을 사용하는 ASP.NET 응용 프로그램과 .NET 프레임워크 v2.0 을 사용하는 ASP.NET 응용 프로그램이 동시에 실행될 수 있습니다. 이와 같은 지원은 IIS 스크립트맵 구성설정을 기반으로, ASP.NET 콘텐츠 요청을 처리하기 위한 적절한 버전의 ASPNET_isapi.dll 파일이 맵핑됨으로서 제공됩니다.

예를 들어서, 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위해 다음과 같은 스크립트맵을 구성할 수 있습니다.

1. ASP.NET v1.1 응용 프로그램인 /app1
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
   
2. ASP.NET v2.0 응용 프로그램인 /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

응용 프로그램에 *.aspx 파일에 대한 요청이 도착하면, IIS 는 지정된 aspnet_isapi.dll 파일을 로드하고, 이 로딩된 aspnet_isapi.dll 파일이 올바른 버전의 CLR 을 작업자 프로세스에 로딩함으로서 해당 요청을 처리합니다.

그리고 ASP.NET 은 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위한 다음과 같은 구성 방법을 제공합니다.

1. ASP.NET MMC 익스텐션. 사용자가 사용하고자 하는 ASP.NET 의 버전을 지정할 수 있으며, 익스텐션은 자동적으로 응용 프로그램을 위한 올바른 버전의 aspnet_isapi.dll 파일을 지정하여 스크립트맵을 구성하게 됩니다.
   
2. ASP.NET aspnet_regiis.exe. ASP.NET aspnet_regiis.exe. 사용자는 적절한 ASP.NET 버전을 지정하는 스크립트맵을 설치하기 위해 -i 와 -r 옵션을 사용할 수 있습니다.

공교롭게도, 단일 작업자 프로세스에는 하나의 CLR 버전만 로드될 수 있다는 제약 때문에, 서로 다른 버전을 사용하는 두 응용 프로그램이 같은 응용 프로그램 풀을 사용하게 구성되지 않도록 주의를 기울여야만 합니다. 그렇지 않으면, 최초의 요청으로 인해서 그에 대응하는 aspnet_isapi.dll 파일의 CLR 이 로드되고, 직후에 뒤따라 발생한 같은 응용 프로그램 풀의 다른 버전에 대한 요청은 실패하게 됩니다.

IIS7 은 응용 프로그램 풀을 ASP.NET 버전관리의 최소 단위로 간주합니다. 따라서 응용 프로그램 풀에 로드되는 CLR / ASP.NET 의 버전은 응용 프로그램 풀 구성설정에 명확하게 설정됩니다. IIS 는 작업자 프로세스가 로딩될 때 이 구성설정에 지정된 버전의 CLR 을 기본적으로 미리 로드할 것입니다. (버전정보가 공백으로 설정된 경우는 제외)

응용 프로그램 풀이 .NET 프레임워크 버전관리의 경계선이기 때문에, 다음과 같은 작업은 ASP.NET 응용 프로그램의 버전에 변화를 주게 됩니다.

1. 응용 프로그램을 원하는 ASP.NET 버전을 사용하는 응용 프로그램 풀로 이동합니다.
   기본적으로 응용 프로그램은 ASP.NET v2.1 통합 모드로 실행되는 “DefaultAppPool” 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. ASP.NET v2.1 클래식 모드를 사용하기 위해 응용 프로그램을 “Classic .NET AppPool” 이라는 응용 프로그램 풀, 또는 여러분들이 선택한 다른 응용 프로그램 풀로 이동할 수 있습니다.
   
2. 응용 프로그램이 실행되는 응용 프로그램 풀을 원하는 ASP.NET 버전을 사용하도록 설정합니다.
   기본적으로 모든 새로운 응용 프로그램 풀은 ASP.NET 2.1 통합 모드에서 실행되도록 구성됩니다.

특정 응용 프로그램을 대상으로나 전반적으로 ASP.NET 의 버전을 구성하기 위해서는 aspnet_regiis /i 또는 /r 옵션을 사용하면 안된다는 점에 주의하시기 바랍니다.

II7 은 설정된 CLR 버전과 응용 프로그램 풀의 관리되는 통합 모드에 따라 자동적으로 핸들러 맵핑의 올바른 집합을 (클래식 모드에서의 ASPNET_isapi.dll 파일 또는 통합 모드에서의 관리되는 핸들러 유형들을 위한) 선택하기 위해 미리 구성된 핸들러 맵핑을 사용합니다. 이러한 핸들러 맵핑은 ASP.NET 2.0 설치시 서버 수준에서 설치됩니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)