IIS 7을 사용한 공유 구성
소개
인터넷은 기업이 일상적인 비즈니스를 처리하는 방법과 시장에서 경쟁하는 방식을 변경합니다. 새로운 웹 기술의 출현과 웹을 통해 사용할 수 있는 리소스에 액세스하는 고객의 수가 증가함에 따라 애플리케이션의 확장성, 가용성, 안정성 및 관리 효율성이 개선되어야 합니다. 애플리케이션은 경쟁 시스템보다 높은 가동 시간, 향상된 요청 처리량, 증가된 동시 사용자 트랜잭션 및 더 나은 투자 수익률(예: 서비스 품질 향상)을 제공하는 기능을 제공하는 시스템에 의존해야 합니다.
서버 클러스터인 웹 팜은 부하를 분산하여 확장성이 뛰어나고 사용 가능하며 관리 가능한 애플리케이션을 제공하는 데 표준이 되었습니다. 보다 구체적으로, 이러한 애플리케이션 특성은 웹 팜과 부하 분산의 기본 이유입니다. 조직에서는 웹 팜을 사용하여 애플리케이션 및 해당 리소스에 동시에 액세스하는 사용자 기반의 용량을 늘릴 수 있는 확장 가능한 방법을 제공할 수 있습니다.
서버 클러스터는 여러 서버가 부하를 분산하여 향상된 가용성을 제공합니다. 또한 클러스터는 지정된 시점에 증가된 고객 수로 더 잘 확장됩니다. 마지막으로, 클러스터는 운영 리소스에 부담을 주지 않고 웹 팜 아키텍처의 프로비전 및 관리를 간편하게 처리하여 향상된 관리 환경을 제공합니다.
개요
이 문서에서는 공유 중앙 집중식 글로벌 구성 기능에 중점을 둡니다. 이 기능은 서버가 서버 그룹에서 동일한 구성을 공유하는 동종 웹 팜을 지원하는 데 도움이 됩니다. UNC 공유를 사용하면 추가 도구 또는 프로그래밍 방식 지원 없이 중앙 마스터 구성 파일에 대한 변경 내용이 여러 서버에 전파됩니다.
이 문서의 첫 번째 부분에서는 IIS 7 이상 관리 UI를 사용하여 공유 구성을 사용하도록 설정하고 사용하는 방법을 설명합니다. 두 번째 부분에서는 명령줄에서 공유 구성을 사용하도록 설정하고 사용하는 방법을 설명합니다.
비목적: 이 문서에서 다루지 않는 내용
올바른 지원성, 관리 효율성, 접근성, 확장성 등 여러 측면이 성공적인 웹 팜 환경에 기여합니다.
공유 구성은 웹 팜의 구성 관리 측면에만 중점을 두고 서버 간 구성을 처리합니다. 여러 서버 관리, 콘텐츠 복사, 모듈 배포, 애플리케이션 이진 파일 동기화, 타사 구성 요소 설정 등에 도움이 되는 도구 및 기타 기능이 있습니다. 이러한 도구, 기능 및 측면은 이 문서의 범위를 벗어납니다.
이 문서에서는 서버에서 중앙 파일을 사용하여 구성을 기본 하는 방법만 자세히 설명합니다.
따라서 sharedconfiguration을 사용하면 서버가 로컬 구성인 것처럼 백 엔드 UNC 공유의 구성 파일에 액세스할 수 있습니다. 따라서 프런트 엔드 웹 서버를 사용하여 구성을 업데이트하면 다른 모든 서버에 대한 업데이트가 이루어집니다.
타사 모듈 설치 또는 구성 설정 추가와 같은 다른 상황을 고려해야 하며, 한 서버만 이해할 수 있고 이진 파일과 스키마를 올바르게 작동할 수 있는 속성을 포함해야 합니다. 그렇지 않으면 이 유형의 사용량이 다른 서버를 중단시킬 수 있습니다.
같은 유형의 팜에서 이 문제를 방지하려면 클러스터에서 공유 구성을 사용하지 않도록 설정하고, 원격 파일을 미러 로컬 applicationHost 파일을 업데이트하고, 단일 서버에서 모듈 및 구성을 배포 및 업데이트한 다음, 해당 서버에서 공유 구성을 다시 사용하도록 설정해야 합니다. 그런 다음 공유 구성을 다시 사용하도록 설정하기 전에 나머지 서버에서 이진 파일 및 모듈을 배포하고 업데이트할 수 있습니다.
Do기본 및 Non-do기본 Environment
일부 관리자는 할 일기본 환경에서 웹 서버 클러스터를 배포하고 다른 관리자는 작업 그룹(비도행기본)에 배포합니다. 이 문서에서는 시나리오를 모두 설명하고 차이점과 주의 사항을 설명합니다. Do기본 컨트롤러를 사용하여 Active Directory에서 제공하는 도움말 및 보안을 사용하여 할 일기본에서 클러스터에 IIS를 설정하는 것이 좋습니다.
필수 조건
다음 단계를 순서대로 완료해야 합니다.
- 이 문서 전체에서 웹 서버라고 하는 서버에 IIS를 설치합니다.
- 이 문서 전체에서 파일 서버라고 하는 두 번째 서버에 대한 액세스를 확인합니다. 파일 서버는 UNC를 사용하여 액세스할 수 있는 구성 및 기본 콘텐츠에 대한 공유를 보관합니다.
- 이 문서의 각 단계에서는 이전 단계가 완료되었다고 가정합니다. 모든 단계를 순서대로 수행합니다.
- 일부 단계에서는 UI를 사용하여 수행할 수 있는 동일한 단계가 있습니다. 달리 지정하지 않는 한 한 하나의 단계 유형만 수행합니다.
중앙 집중식 구성
IIS 관리 UI에는 구성 리디렉션을 설정하고 구성 파일 및 필요한 암호화 키를 지정된 경로로 내보내는 지원이 포함됩니다.
UI를 사용하여 파일을 내보내고 구성 리디렉션을 설정하려면
- IIS 관리자를 엽니다.
- 트리 뷰에서 구성 리디렉션을 설정할 서버 연결을 선택합니다.
- 공유 구성을 두 번 클릭합니다.
- 작업 창에서 구성 내보내기를 클릭하여 필요한 구성 파일을 로컬 서버에서 다른 위치(예: UNC 공유)로 내보냅니다.
- 구성 내보내기 대화 상자에서 파일을 내보낼 경로를 입력합니다. 내보낸 암호화 키를 보호하기 위해 암호를 입력합니다. 확인을 클릭하여 구성 파일 및 암호로 보호된 암호화 키를 내보냅니다.
- 공유 구성 검사 사용 상자를 선택하여 구성 리디렉션을 사용하도록 설정합니다.
- 구성 및 암호화 키가 있는 경로를 지정하고 해당 경로에 액세스하는 데 사용할 자격 증명을 지정합니다. 커넥트...를 클릭하고 자격 증명을 입력합니다.
- 적용을 선택하여 설정을 저장합니다. 공유 구성 대화 상자에서 암호화 키를 보호하기 위해 지정한 암호를 입력합니다.
- 확인을 클릭하여 구성 리디렉션 설정을 완료합니다.
위의 단계에서는 구성을 내보내고 중앙 집중식 구성을 설정하는 방법을 설명합니다. 그러나 구성을 한 번만 내보내면 됩니다. 중앙 집중식 구성을 사용하는 각 후속 서버에서 6~9단계를 수행합니다.
UI 사용에 대한 참고 사항
구성 리디렉션을 설정할 때 내보낸 파일은 UI를 사용하여 내보내야 합니다. 이는 UI가 자체 사용자 지정 형식을 사용하여 암호로 보호된 암호화 키와 같은 항목을 내보내고 가져오기 때문입니다.
예를 들어 administration.config 및 applicationHost.config 파일을 공유에 수동으로 복사한 다음 암호화 키를 수동으로 내보낸 경우 UI를 사용하여 해당 파일을 가리키도록 구성 리디렉션을 설정할 수 없습니다. 내보낸 암호화 키가 UI에 필요한 형식이 아니기 때문입니다.
명령 프롬프트
이 문서의 다시 기본 전체에서 명령 프롬프트를 사용하여 특정 명령을 실행해야 합니다. 일반 명령 프롬프트를 실행하는 경우 특정 명령이 작동하지 않으므로 관리자 권한으로 명령 프롬프트를 사용하는 것이 좋습니다.
관리자 권한으로 명령 프롬프트를 열려면
- 시작을 클릭합니다.
- 모든 프로그램을 클릭합니다.
- 액세서리를 클릭합니다.
- 명령 프롬프트를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택합니다.
- 표시되는 대화 상자의 프롬프트를 따릅니다.
현재 applicationHost.config 파일 백업
새 기능을 시도하거나 여러 구성 설정을 변경하는 경우 현재 applicationHost.config 파일을 백업하는 것이 좋습니다.
applicationHost.config 파일을 백업하려면
명령 프롬프트가 엽니다.
기본적으로 있는 IIS 디렉터리로
%WINDIR%\System32\InetSrv
이동합니다. 구성 파일은 InetSrv\Config 디렉터리에 저장됩니다. AppCmd 도구를 사용하여 백업 개체를 만들고 다음 명령을 실행하여 applicationHost.config 파일을 백업합니다.cd /d %windir%\system32\inetsrv appcmd add backup centralConfigBackup
참고 항목
AppCmd 도구는 InetSrv 디렉터리에 있습니다. 도구의 경로가 시스템의 환경 변수에 추가되지 않는 한 이 디렉터리에서 도구에 액세스해야 합니다.
다음 명령을 실행하여 applicationHost.config 파일 및 SMTP 및 기타 비 웹 서버 설정에 대한 레거시 메타베이스 파일을 포함하는 백업 개체가 있는지 확인합니다.
appcmd list backup
현재 구성 파일을 백업 파일로 바꾸려면
명령 프롬프트가 엽니다.
기본적으로 InetSrv 디렉터리에 있는 IIS 디렉터리로 이동합니다. 다음 명령을 실행하여 AppCmd 백업 파일 개체를 복원합니다.
cd /d %windir%\system32\inetsrv\ appcmd restore backup centralConfigBackup
구성에 대한 UNC 공유에 액세스할 사용자 만들기
do기본 환경에서 관리자는 Active Directory와 함께 사용할 할 일기본 계정을 제공하거나 만들어야 합니다. UNC 공유에 액세스하려면 올바른 사용자 권한으로 이 계정을 설정해야 합니다.
비도 기본 환경에서 관리자는 콘텐츠에 액세스할 수 있는 사용자 권한이 있는 로컬 사용자를 두 서버에 모두 만들어야 합니다. 사용자 이름과 암호는 이 설정에서 작동하려면 서버에서 동일해야 합니다. 다음 단계는 공유 구성이 있는 공유를 읽을 사용자를 만드는 데 도움이 됩니다.
공유 구성이 있는 공유를 읽을 수 있는 사용자를 만들려면(비도기본)
명령 프롬프트가 엽니다.
웹 서버(IIS가 설치된 프런트 엔드 서버)에서 다음 명령을 실행하여 ConfigPass1 암호를 사용하여 ConfigUser1이라는 사용자를 만듭니다.
net user ConfigUser1 ConfigPass1 /add
파일 서버(중앙 구성이 상주하는 백 엔드 서버)에서 다음 명령을 실행하여 ConfigPass1 암호를 사용하여 ConfigUser1이라는 사용자를 만듭니다.
net user ConfigUser1 ConfigPass1 /add
중앙 구성 및 콘텐츠에 대한 UNC 공유 만들기
구성에 대한 UNC 공유는 이 중앙 집중식 위치에서 구성 데이터를 선택하려는 모든 서버에 대해 applicationHost.config 파일을 호스트합니다.
UNC 공유를 만들려면
파일 서버에서 명령 프롬프트를 엽니다.
드라이브의 루트로 이동합니다. 다음 명령을 실행하여 구성용 디렉터리를 만들고 이 디렉터리를 공유하여 사용자에게 디렉터리를 읽고 쓸 수 있는 권한을 부여합니다.
md %SystemDrive%\centralconfig net share centralconfig$=%SystemDrive%\centralconfig /grant:Users,Change
참고 항목
이 명령은 사용자 그룹에 이 공유에 대한 사용자 권한을 자동으로 부여합니다. 비도기본 시나리오에 대해 만든 사용자에게는 변경 권한이 자동으로 부여되며, 필요한 경우 추가로 제한될 수 있습니다. do기본 시나리오의 경우 사용자에게 공유에 액세스하기 위해 명시적으로 설정된 사용자 권한이 있거나 시스템의 사용자 그룹에 추가되어야 합니다.
비도기본 시나리오: 공유의 보안을 강화하려면 사용자, /grant 스위치의 일부 변경 부분을 ConfigUser1,Change 매개 변수로 대체할 수 있습니다. 지정된 사용자만 공유에 액세스할 수 있습니다.
할 일기본 시나리오: 공유의 보안을 강화하려면 사용자, /grant 스위치의 변경 부분을 do기본\user,Change 매개 변수로 대체할 수 있습니다. 지정된 사용자만 공유에 대한 원격 액세스 권한을 갖습니다.
참고 항목
공유에 대한 사용자 권한은 원격 및 로컬 파일 시스템 사용자 권한 간의 합집합입니다. 구성 공유를 성공적으로 읽을 수 있도록 할 일기본 계정에 대한 적절한 사용자 권한을 디렉터리에 설정해야 합니다.
중앙 구성 및 콘텐츠를 호스트하는 UNC 공유의 계정에 대한 사용자 권한 부여
구성에 액세스하는 데 사용되는 계정에 적절한 사용자 권한이 있는지 확인해야 합니다. 이 계정은 가상 디렉터리가 UNC 공유에 매핑되는 경우 콘텐츠에 액세스하는 것과 동일한 방식으로 UNC 공유에 액세스하기 위해 IIS에서 사용됩니다. 이 계정에 대한 읽기 사용자 권한은 공유에만 액세스할 때 유용합니다. 이 시점 이후에 IIS는 구성 파일을 읽을 때마다 호출자가 가지고 있는 ID(API, 사용 중인 관리 도구 또는 해당 시점에 로그인한 사용자)로 다시 되돌리기.
참고 항목
구성을 읽는 데 사용되는 ConfigUser1 계정 또는 동일한 do기본 계정은 구성을 작성하는 데 사용되는 계정과 다릅니다. 이러한 계정은 공유 또는 구성 파일에 대한 쓰기 사용자 권한을 가질 필요가 없습니다.
UNC 공유 계정에 사용자 권한을 부여하려면(수행기본)
- do기본 계정이 로컬 사용자 그룹의 일부이고 공유를 만들 때 사용자에게 액세스 권한이 부여된 경우 do기본 설정에 대한 다음 단계를 건너뛸 수 있습니다. 그러나 로컬 파일 공유에 액세스하는 do기본 계정이 로컬 사용자 그룹의 일부가 아닌 경우 명령을 실행하여 사용자 권한을 부여해야 합니다.
- 파일 서버에서 명령 프롬프트를 엽니다.
- 다음 명령을 실행하여 구성이 저장되는 디렉터리를 읽을 수 있도록 do기본 계정에 대한 사용자 권한을 제공합니다.
icacls %SystemDrive%\centralconfig\ /grant domain\user:R
UNC 사용자를 추가하려면(비할 일기본 및 수행기본)
할 일기본 및 비도기본 시나리오의 경우 사용자 이름에 로그온 일괄 처리 작업 구성이 포함되어야 합니다. Windows Servers® 2008의 기본 설정은 아닙니다. 웹 서버에 수동으로 추가해야 합니다.
- 시작을 클릭합니다. 관리Istrative Tools를 클릭하고 로컬 보안 정책을 선택합니다.
- 로컬 정책에서 사용자 권한 할당을 선택합니다.
- 일괄 작업으로 로그온을 두 번 클릭하고 만든 UNC 사용자를 추가합니다.
구성 리디렉션
소개
이전 단계를 완료했으므로 웹 서버가 작동하고 프런트 엔드 웹 서버가 localhost 루프 백 주소를 사용하여 기본 웹 사이트를 제공해야 합니다.
이제 구성을 중앙 위치로 이동할 수 있습니다. 이렇게 하면 파일을 마스터 파일로 선언하고 여러 서버의 구성을 위해 UNC 공유에 저장할 수 있습니다. 이 파일을 한 번 변경하면 모든 서버 구성이 한 번에 프로비전되고 업데이트됩니다.
UNC 공유에 구성을 저장하려면
프런트 엔드 웹 서버의 디렉터리에서 applicationHost.config 및 administration.config 파일을 복사하여 백 엔드 파일 서버에서
%windir%\system32\inetsrv\config
공유합니다. 현재 로그인한 사용자 계정에 백 엔드 공유에 대한 쓰기 권한이 있는 경우 디렉터리에 파일을 삭제할 수 있습니다. 그렇지 않은 경우 이 단계를 완료하려면 백 엔드에 대한 사용자 계정을 인증해야 합니다.프런트 엔드 서버의 구성 디렉터리에서 기존 redirection.config XML 파일에 액세스합니다.
- Windows 탐색기를
%windir%\system32\inetsrv\config
사용하여 . - redirection.config 파일을 엽니다. 이 파일 및 해당 내용은 웹 서버가 설정되면 만들어집니다. 도구 및 API는 이 파일에 액세스하여 이 기능을 사용할 수 있는지 여부를 확인할 수 있습니다.
- Windows 탐색기를
redirection.config 파일을 엽니다. 환경에 대한 올바른 서버 이름, 사용자 이름 및 암호를 사용하여 다음 구성을 설정합니다.
<configuration> <configSections> <section name="configurationRedirection" /> </configSections> <configurationRedirection enabled="true" path="\\machinename\centralconfig$\" userName="ConfigUser1 or domain\user" password="ConfigPass1 or domainPassword" /> </configuration>
redirection.config 파일을 저장합니다. 사이트에 다시 액세스할 수 있지만 구성은 이제 UNC 공유에 저장됩니다.
구성 테스트
백 엔드에서 구성을 참조하는 경우 이 기능이 디자인된 두 가지 주요 시나리오가 있습니다. 프런트 엔드 웹 서버에서 다음 두 가지 방법으로 구성을 업데이트할 수 있습니다.
- applicationHost.config 파일을 파일 공유에서 직접 편집할 수 있습니다. 이 작업이 완료되면 변경 알림이 수행되고 웹 서버가 파일의 변경 내용을 선택합니다.
- 백 엔드 파일 공유에 두 번째 applicationHost.config 파일을 추가하고 웹 서버의 redirection.config 파일을 새 버전의 파일을 가리키도록 변경할 수 있습니다. 이는 롤백 목적 또는 단계적 배포에 유용합니다.
요약
이 문서에서는 새로운 중앙 집중식 구성 기능을 소개했습니다. 이 기능을 사용하면 웹 팜 환경에서 동종 클러스터가 설정된 관리자가 원활한 방식으로 모든 서버에 구성을 배포할 수 있습니다.
기능이 설정되면 UNC 공유의 파일에서 변경되거나 서버가 다른 위치로 리디렉션되는지 여부에 관계없이 웹 서버에서 즉시 변경 내용을 선택합니다. 여러 사이트 및 애플리케이션에 영향을 주는 전역 변경 내용만 재활용되지만 지역화된 범위에서 변경된 경우 나머지 사이트 및 애플리케이션은 다시 시작되지 않습니다.
부록 1: 값 읽기를 프로그래밍 방식으로 Redirection.config 파일에 액세스
이 단계에서는 새 COM AHADMIN API를 활용하여 프로그래밍 방식으로 redirection.config 파일에 액세스하는 방법에 대한 샘플을 제공합니다. AHADMIN COM API를 사용하여 네이티브 코드 또는 스크립트 및 관리 코드에서 이 API를 구현합니다.
프로그래밍 방식으로 값을 읽으려면
텍스트 파일을 만들고 .js 확장명과 함께 저장합니다. 다음 스크립트는 사용자 환경에 사용할 수 있는 특성, 서버 이름, 사용자 이름 및 암호를 읽는 방법의 샘플을 제공합니다.
try { var config = WScript.CreateObject( "Microsoft.ApplicationHost.AdminManager" ); var section = config.GetAdminSection( "configurationRedirection", "MACHINE/REDIRECTION" ); WScript.Echo( "Current redirection:" ); WScript.Echo( "enabled = " + section.Properties.Item( "enabled" ).Value ); WScript.Echo( "path = " + section.Properties.Item( "path" ).Value ); WScript.Echo( "user = " + section.Properties.Item( "userName" ).Value ); WScript.Echo( "pass = " + section.Properties.Item( "password" ).Value ); } catch(e) { WScript.Echo(e.number); WScript.Echo(e.description); }
redirection.js 파일을 저장합니다. 이제 WSH(Windows 스크립트 호스트)로 인해 명령 프롬프트에서 이 파일을 실행할 수 있습니다.
부록 2: redirection.config 파일에 프로그래밍 방식으로 액세스하여 값 작성
이 단계에서는 새 COM AHADMIN API를 활용하여 프로그래밍 방식으로 redirection.config 파일에 액세스하는 방법에 대한 샘플을 제공합니다. 네이티브 코드 또는 COM 개체의 스크립트 및 관리 코드에서 이 API를 사용합니다.
프로그래밍 방식으로 값을 쓰려면
텍스트 파일을 만들고 .js 확장명과 함께 저장합니다. 다음 스크립트는 환경의 사용 특성, 서버 이름, 사용자 이름 및 암호를 작성하는 방법의 샘플을 제공합니다.
try { var config = WScript.CreateObject( "Microsoft.ApplicationHost.WritableAdminManager" ); config.CommitPath = "MACHINE/REDIRECTION"; var section = config.GetAdminSection( "configurationRedirection","MACHINE/REDIRECTION" ); section.Properties.Item( "enabled" ).Value = true; section.Properties.Item( "path" ).Value = "\\\\somemachine\\sharefile://folder/"; section.Properties.Item( "userName" ).Value = "testuser"; section.Properties.Item( "password" ).Value = "testuser"; config.CommitChanges(); } catch(e) { WScript.Echo(e.number); WScript.Echo(e.description); }
redirection.js 파일을 저장합니다.
이제 WSH(Windows 스크립트 호스트)로 인해 명령 프롬프트에서 이 파일을 실행할 수 있습니다.
부록 3: 컴퓨터별 암호화 속성 처리
기본적으로 IIS에는 속성을 보호하기 위한 두 개의 기본 공급자가 포함되어 있습니다. 이러한 공급자는 applicationHost.config 파일의 <configProtectedData> 구성 섹션에 있으며 공급자 요소에 <정의되어 있습니다> .
AesProvider는 system.webServer 섹션에 있는 속성에 대한 암호화 및 암호 해독을 처리하는 것과 관련이 있습니다.
IISWASOnlyRsaProvider는 system.applicationHost 섹션에 있는 속성에 대한 암호화 및 암호 해독을 처리하는 것과 관련이 있습니다.
이러한 키는 iisConfigurationKey 및 iisWasKey 키 컨테이너에 있으며 머신별로 다릅니다. 웹 팜 시나리오에서 암호화가 필요한 경우 보안 속성을 암호 해독하고 웹 서버에서 사용할 수 있도록 한 컴퓨터(일반적으로 applicationHost.config 파일을 만든 컴퓨터)의 키가 내보내지고 다른 컴퓨터로 가져옵니다.
단계
명령 프롬프트를 엽니다. 기본적으로 있는 Framework 디렉터리로
%windir%\Microsoft.NET\Framework\v2.0.50727\
이동합니다.참고 항목
참조를 위해 시스템의 컴퓨터 키는 %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys\에 있습니다.
aspnet_regiis 도구를 사용하여 키를 내보냅니다. 구성 키를 전송하는 명령은 아래에 명시되어 있습니다. px 스위치는 RSA 키 쌍을 내보낼 것을 식별합니다. 기본 스위치는 프라이빗 키와 공개 키를 모두 포함하려는 것을 식별합니다.
이 스위치 식별은 암호화 및 암호 해독을 모두 수행하는 데 필요합니다. 그렇지 않으면 내보낸 키로만 데이터를 암호화할 수 있습니다. -px 뒤의 매개 변수는 내보낼 키 컨테이너의 이름입니다. 이 경우 "iisConfigurationKey" 키 컨테이너입니다. IIS에서 사용하는 다른 키 컨테이너는 "iisWasKey" 키 컨테이너입니다.
aspnet_regiis -px "iisConfigurationKey" "D:\iisConfigurationKey.xml" -pri
내보내기가 성공적으로 완료되면 XML 파일을 클러스터의 다른 컴퓨터에 복사하여 가져오기를 준비합니다.
Framework 디렉터리로 이동하고 aspnet_regiis 도구를 사용하여 XML 파일에서 키를 가져옵니다. 키 전송을 완료하는 명령은 아래에 명시되어 있습니다.
-pi 뒤의 매개 변수는 가져올 키 컨테이너의 이름입니다. 이 경우 "iisConfigurationKey" 키 컨테이너입니다. IIS에서 사용하는 다른 키 컨테이너는 "iisWasKey" 키 컨테이너입니다.
aspnet_regiis -pi "iisConfigurationKey" "D:\iisConfigurationKey.xml"