일반 IIS 7.0 질문

이 작업은 수동으로 수행해야 합니다.

영향은 서버 부하에 따라 달라집니다. 초당 10,000개의 요청을 수행하는 경우 커널 캐싱이 몹시 누락됩니다. 그러나 초당 100개의 요청을 수행하는 경우 알 수 없습니다. 제공되는 콘텐츠에 따라 크게 달라집니다. IIS 5.0에는 커널 모드 구성 요소가 없으며 대부분의 고객에게 잘 작동했습니다.

기본 Ruby 지원이 있습니다. 자세한 내용은 다음 링크를 참조하세요.

http://mvolo.com/10-steps-to-get-ruby-on-rails-running-on-windows-with-iis-fastcgi/

서버 관리자 GUI("기능 추가")를 통해 설치하는 경우 설치 순서는 중요하지 않습니다. 기능 추가 마법사는 모든 종속성을 확인하고 필요한 모듈이 누락된 경우 경고합니다. 또한 기능 추가 마법사는 모듈의 올바른 순서를 알고 있습니다.

명령줄에서 설치하거나 무인 설치를 사용하는 경우 모듈 순서는 중요하지 않지만(다시 설치 프로그램에서 모듈의 올바른 순서를 알고 있음) 모든 종속성을 식별해야 합니다. 필요한 종속성을 포함하지 않으면 무인/명령줄 설정이 실패합니다.

모든 기능이 설치된 정적 파일만 제공하는 애플리케이션 풀의 공간은 3MB 프라이빗 바이트, 5MB 페이지 파일입니다. (IIS 6.0보다 큽니다.) Windows Server 2008은 WS03보다 여러 애플리케이션 풀을 더 잘 처리합니다. ASP.NET 요청이 이루어지면 시작(~100kb) 동안 소량의 CLR을 미리 로드합니다. 미리 로드는 ApplicationPool의 속성으로 구성할 수 있습니다. 이를 managedRuntimeVersion이라고 합니다. CLR의 나머지 부분(~8mb)은 첫 번째 ASPX 요청에 로드됩니다.

액세스는 32비트 애플리케이션 풀에서만 작동합니다. 사용자 프로필(AppPool의 loadUserProfile 속성)을 로드하는 것은 사용자 프로필이 로드될 때 익명 사용자에 대한 액세스를 허용하지 않는 임시 디렉터리를 사용하므로 클래식 ASP를 사용할 때 문제가 됩니다.

Windows Server 2008 웹 버전이 훨씬 개선되었으며 인공 제한을 제거하는 데 집중했습니다. 최종 라이선스는 아직 완료되지 않았지만 모든 하드웨어 제한을 제거하고 4x 프로세서 및 32GB RAM(x64)을 허용할 계획입니다. SQL이 허용되고 SharePoint는 SKU에 설치할 수 있습니다.

FPSE는 더 이상 Windows Server의 일부가 아닙니다. 타사와 협력하여 FPSE가 Windows Server 2008/IIS 7.0에서 실행되도록 다운로드 패키지를 만듭니다. 새로운 기능이나 향상된 기능이 없으며 호환되도록 수정하기만 하면 됩니다.

Windows Server 2008을 새로 설치하고 마이그레이션하는 것이 좋습니다. 또는 새 고객을 새 서버에 배치하기만 하면 됩니다. 현재 환경을 새 서버에서 복제할 수 있도록 각 서버에 대해 잘 관리되는 타사 구성 요소 및 구성 목록을 문서화하는 것이 좋습니다. 사이트 및 애플리케이션 풀 구성에 대한 공유 호스팅 문서의 권장 사항을 참조하세요. 마이그레이션을 지원하는 도구는 가까운 장래에 릴리스될 예정입니다.

현재 위치 업그레이드는 다음 시나리오에서 지원됩니다.

• Windows Server 2003을 WS2K8 베타3, WS2K8 RC0, WS2K8 RC1 및 WS2K8 RT로 업그레이드할 수 있습니다.
• Windows Server 2008 Beta3을 WS2K8 Beta3 및 WS2K8 RC0으로 업그레이드할 수 있습니다.
• Windows Server 2008 RC0을 WS2K8 RC0, WS2K8 RC1 및 WS2K8 RTM으로 업그레이드할 수 있습니다.
• Windows Server 2008 RC1을 WS2K8 RC1 및 WS2K8 RTM으로 업그레이드할 수 있습니다.

서버가 공유 구성 모드인 경우 업그레이드를 실행하기 전에 독립 실행형 구성으로 되돌려야 합니다. 이렇게 하려면 공유 구성을 사용하지 않도록 설정하고, applicationhost.config 및 암호화된 키를 로컬 컴퓨터에 복사하고, 각 서버에서 업그레이드를 실행한 다음, 공유 구성을 다시 사용하도록 설정합니다.

설정이 작성 중인 로그 파일과 iis7.log는 모두 항상 켜집니다. 기록되는 항목에 대해서는 세분화되지 않습니다.

설치하는 동안 Windows 모듈 이외의 모듈을 구성하는 방법은 제공하지 않습니다. 일반 무인 설치를 통해 설치가 완료된 후 사용자가 코딩을 수행할 수 있는 방법이 있을 수 있습니다.

초당 1,000개 요청에서 <모든 요청을 추적하는 것은 5% CPU여야 <합니다. 모든 사이트에 대해 전역 추적 규칙을 구성할 수 있습니다. siteDefaults 섹션을 변경 <하여 모든 사이트에 대해 추적을 사용하도록 설정할 수 있습니다> .

아니요, 하지만 구성된 메모리 제한을 초과하는 AppPools를 재활용하는 메모리 기반 재활용이 있습니다.

sysprep 전에 만들어진 암호화는 sysprep 후에 손실됩니다. 해결 방법이 없습니다.

암호 해독이 작동되도록 컴퓨터 키를 내보내고 모든 서버로 가져올 수 있습니다. 서버 베타 3용 UI에는 공유 구성이라는 기능이 포함되어 있으므로 이를 수행할 수 있습니다. 내보내기...를 클릭합니다. 컴퓨터 키를 암호화하고, applicationHost.config 함께 복사하고, 경로에 administration.config. 그 후 다른 모든 컴퓨터에서 "가져오기..."를 선택할 수 있습니다. 컴퓨터 키를 가져오고 구성을 공유 구성으로 가리킵니다.

다른 AppPools는 이 설정에 대해 서로 다른 값을 가질 수 있습니다. 애플리케이션을 다른 AppPools에 할당할 수 있습니다.

이 오류를 처리하기 위한 기본 파일은 \inetpub\custerr\en-us에 포함되어 있습니다. 오류의 바닥글에는 "서버 버전 정보: 인터넷 정보 서비스 7.0"이 포함되어 있으며, .htm 파일에서 직접 제거하거나 편집할 수 있습니다.

관리되는 API(Microsoft.Web.Administration)는 네이티브 API가 수행하는 모든 설정에 액세스할 수 있으며 ServerManager.OpenRemote 정적 메서드를 사용하여 DCOM 원격 지원을 제공합니다. 구성 설정을 설정할 수 있지만 베타 3의 경우 AppPool의 상태 또는 요청 또는 작업자 프로세서 목록과 같은 런타임 정보에 대한 지원이 없습니다.

이전 IIS 버전에서는 파일 시스템 ACL을 통해 액세스를 제어해야 했습니다. 이것은 지루하고 그것을 할 수있는 웹 인터페이스가 없습니다. URL 권한 부여를 사용하면 IIS 사용자 인터페이스를 사용하거나 직접 web.config 사용하여 URL에 대한 액세스를 제어할 수 있습니다. 또한 Windows가 아닌 ID(예: 멤버 자격 사용자 및 양식 인증에서 제공하는 역할)를 사용할 수 있습니다.

applicationPool 섹션의 모든 데이터는 해당 앱 풀과 관련되어 있으므로 applicationPoolDefaults 또는 해당 앱 풀과 관련된 데이터로 인해 WAS가 앱 풀을 재활용하게 됩니다. 작업자 프로세스는 특정 구성 변경에 따라 WAS에 앱 풀을 재활용하도록 요청할 수 있습니다. 현재는 globalModules만 수행하지만 모듈에서 구성 변경에 따라 재활용을 요청할 수 있으므로 닫힌 목록은 아닙니다.

NLB는 Windows Server 2008의 일부입니다. 기본적으로 Windows 2003과 동일합니다. NLB를 설치하려면 서버 관리자 > 기능 > "기능 추가"로 이동하여 목록에서 "네트워크 부하 분산"을 선택합니다. NLB를 구성하려면 명령 프롬프트를 열고 nlbmgr을 실행해야 합니다. Windows 2003에 있는 UI입니다.

시스템 전체 CPU가 임계값 동적을 초과하면 압축이 중지되어 사용하던 CPU가 확보됩니다. 시스템 전체 CPU가 다른 제한 아래로 떨어지면 동적 압축이 다시 시작되어 대역폭이 절약됩니다.

다른 사용자는 최적의 CPU 사용률에 대해 서로 다른 의견을 가지고 있습니다. 어떤 사람들은 20%의 평균이 완벽하다고 생각하고, 다른 사람들은 75%를 생각합니다. X를 원하고 X보다 일관되게 위에 있는 경우 동적 압축을 완전히 제거할 수 있습니다.

이는 마지막 샘플 이후 30초 동안의 평균 사용량을 고려하므로 불규칙한 급증이 있더라도 급증 후 최대 30초 동안 동적 압축을 켜고 스파이크가 즉각적이면(30초가 넘는 평균 CPU 사용량에 영향을 미치지 않음) 동적 압축에 영향을 미치지 않습니다.

applicationPoolDefaults에서 loadUserProfile=false를 설정하는 것은 공유 호스팅 시나리오에 적합합니다. AppPool의 시작 시간이 훨씬 빨라지고 임시 디렉터리 권한 문제를 방지할 수 있습니다.

500.19 오류는 IIS 7.0 기능 위임 모드로 인해 발생합니다. 기능이 사이트 소유자에게 위임되고 사이트 소유자가 기능을 수정하면 변경 내용이 web.config 유지됩니다. 서버 관리에서 해당 기능에 대한 위임된 관리를 취소하는 경우 웹 사이트 소유자는 web.config 기능 세부 정보를 정리할 책임이 있습니다. 그렇지 않으면 위임된 기능을 수정한 모든 사이트에서 즉시 "Http 오류: 500.19 - 내부 서버 오류" 메시지가 표시됩니다. 이 문제를 방지하려면 호스트가 최종 고객에게 게시된 후 위임된 기능을 취소하지 않는 것이 좋습니다.

호스트된 사이트에 web.config 없는 경우 IIS 7.0에서 만듭니다. 사이트에 web.config 있는 경우 IIS 7.0에서 수정합니다. web.config 수정된 경우 사이트 소유자는 변경 내용을 병합하고 변경 내용을 수동으로 병합하고 유지 관리할 책임이 있습니다.

관리 서비스를 설치해도 AppHost.config 수정하거나 Administration.config 않습니다. 새 이진 파일만 표시됩니다(wmsvc.exe). 자체 서명 인증서가 만들어지고 몇 개의 레지스트리 키가 추가됩니다. 이것은 이론적으로 아무것도 중단해서는 안된다는 것을 의미합니다.

대부분의 경우 apphost/admon.config 읽기 위한 redirection.config 설정을 사용하기 때문에 기본으로 작동합니다. 그러나 자세한 답변의 경우 사용할 시나리오에 따라 달라집니다.

• 로컬 콘텐츠를 사용한 공유 구성: 로컬 콘텐츠 및 web.config 수정하기 위해 연결하는 일반 Windows 또는 IIS 사용자 - 아무 작업도 수행되지 않으며 모든 것이 기본으로 작동해야 합니다.
• Windows 사용자를 사용하여 원격 콘텐츠를 사용하는 공유 구성: Windows 계정에 해당 콘텐츠에 액세스할 수 있는 경우 작동해야 합니다.
• IIS 사용자를 사용하여 원격 콘텐츠를 사용하는 공유 구성: 이 시나리오에서는 콘텐츠에 액세스하기 위해 프로세스 ID를 사용하므로 WMSVC(서비스 ID)를 원격 콘텐츠에 액세스할 수 있는 계정으로 변경해야 합니다. redirection.config 사용하므로 apphost.config/admon.config 작동합니다.
• 서버 연결을 관리하는 Windows 관리자: Windows 관리자가 공유 구성에 대한 쓰기 권한이 있는 경우 작동해야 합니다.

IIS 7.0에서 사이트를 만드는 방법에 대한 자세한 내용은 다음 링크를 참조하세요.

설치된 모든 기능이 있는 정적 파일만 제공하는 애플리케이션 풀은 3MB 프라이빗 바이트, 5MB 페이지 파일을 차지합니다. ASP.NET 요청이 이루어지면 시작하는 동안 소량의 CLR(~100kb)을 미리 로드합니다. 미리 로드는 ApplicationPool의 속성으로 구성할 수 있습니다. 이를 managedRuntimeVersion이라고 합니다. CLR의 나머지 부분(~8mb)은 첫 번째 ASPX 요청에 로드됩니다.

Http.sys 이러한 폴더가 없으면 자동으로 만듭니다. 사용 권한을 다른 권한으로 재정의하는 경우 새 사용 권한을 유지해야 합니다.

내부적으로 테스트했으며 ISAPI 및 메타베이스가 설치된 경우 잘 작동하는 것 같습니다. 온라인으로도 작동하도록 하는 방법에 대한 지침을 제공하는 몇 가지 블로그가 있습니다. 자세한 내용은 다음 링크를 참조하세요.

https://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx.

서버가 AD 계정 만들기 모드로 설정됩니다. AD 생성 모드는 계속 지원되지만 V4에서 제거되는 사용되지 않는 기능입니다. WSS가 AD에서 사용자를 자동으로 만들 수 있도록 허용하는 대신 WSS 외부에서 사용자 프로비저닝을 수행하는 것이 좋습니다.

중앙 집중식 글로벌 구성에 대한 자세한 내용은 IIS 7.0의 구성 시스템에서 찾을 수 있습니다.

현재 x64에 대한 FPSE는 없습니다. 공유 호스팅 권장 아키텍처는 32비트 AppPools가 있는 64비트 OS입니다. 아쉽게도 현재 이 시나리오에 대해 FPSE가 64비트에 설치되지 않도록 하는 버그가 있습니다.

다음 단계를 완료하여 시스템을 세 번 다시 무장할 수 있습니다.

slmgr /rearm을 실행하려면 regedit.exe 열고 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL로 이동합니다. "skiprearm" 값이 '0'으로 설정되어 있는지 확인합니다. 이 값이 0이 아닌 경우 다시 arm 함수는 시스템 활성화 타이머를 다시 설정하지 않습니다.

"skiprearm" 레지스트리 값이 0과 같은지 확인한 후 관리자 권한 명령 프롬프트에서 slmgr /rearm을 실행합니다. 프로세스가 완료되었다는 알림이 표시되기를 기다립니다. 1~2분 정도 걸릴 수 있습니다. 완료되면 프롬프트에 따라 컴퓨터를 종료합니다. 다시 시작되면 컴퓨터가 OOB Grace에서 실행되고 정품 인증할 30일이 더 있습니다. 이 프로세스에 의해 시스템에 다른 변경이 수행되지 않습니다.

Iis. CertObj COM-object는 여전히 IIS 7.0에 있으며 여러 웹 서버에 인증서를 배포하는 데 여전히 가장 적합한 옵션이라고 생각합니다. 이 구성 요소 동작은 동일하게 유지되므로 모든 이전 스크립트가 작동해야 합니다(ABOMapper를 사용하는 경우).

set iiscertobj = CreateObject("IIS. CertObj")

iiscertobj. InstanceName = "0.0.0.0:443"

iiscertobj. pfxfile, pfxfilepassword, true, true 가져오기

그리고 이러한 스크립트는 ABOMapper에 따라 달라지지 않습니다.