一般的な IIS 7 に関する質問
公開日: 2007 年 12 月 22 日 (作業者: walterov (英語))
更新日: 2008 年 3 月 6 日 (作業者: walterov (英語))
モジュールがクラッシュを繰り返す場合、不具合の原因となっているモジュールを削除し、そのモジュールなしでアプリケーション プールをリサイクルすることは IIS 7 では可能ですか?
これは手動で行う必要があります。
カーネル モード キャッシュを無効にするとどのような影響が生じますか?
どのような影響が生じるかは、サーバーへの負荷によって異なります。1 秒あたりの要求数が 10,000 件に上る場合は、カーネル キャッシュが是非とも必要です。1 秒あたりの要求数が 100 件ほどならば、影響は微々たるものでしょう。これは、提供しているコンテンツによって大きく左右されます。IIS 5 にはカーネル モード コンポーネントが存在していませんでしたが、そのことはユーザーにとってほとんど問題となりませんでした。
Windows Server® 2008 で提供される Ruby on Rails のサポートの種類には、どのようなものがありますか?
Ruby and Rails については、基本的なサポートを提供しています。詳細については、以下のリンクを参照してください。
モジュールをインストールする順序は重要ですか?
Server Manager の GUI ([機能の追加]) を使ってインストールする場合は、インストールの順序は問題になりません。機能の追加ウィザードによって依存関係のチェックが行われ、必要なモジュールがない場合は警告が通知されます。加えて、機能の追加ウィザードは、モジュールの正しいインストール順を認識しています。
コマンド ラインからインストールする場合や無人インストールを使用する場合も、モジュールの順序は問題になりません (セットアップにより、モジュールが正しい順序でインストールされます) が、ユーザーの方ですべての依存関係を把握しなければなりません。無人/コマンド ライン セットアップは、必要な依存関係を 1 つでも欠くと失敗します。
メモ: セットアップ中のモジュールの順序とは反対に、共通のパイプライン (たとえば、モジュールが通知にサブスクライブする順序) では、モジュールの順序が重要になります。たとえば、2 つのモジュールが同一の通知にサブスクライブする場合、順序が最初のモジュールが最初に通知を受け取ります (1 つの例外として、既定の IIS 7 モジュールでは、順序の変更に関する問題は生じません)。認証モジュールについては、認証スキームを試行する順序は既存の順序に従うため、既存の順序を保持することをお勧めします。最も安全度の高いスキームから安全度の低いスキームへと順番に並べます。IE では、認識可能な最初の認証スキームを使用します。安全度の低い認証スキームを先頭に配置すると、IE は安全度の高い認証スキームの代わりに、その安全度の低いスキームを選択してしまいます。
アプリケーション プールのメモリー占有領域とは何ですか?また、そのメモリー占有領域には CLR が読み込みまれますか?
すべての機能がインストールされた、静的ファイルのみを提供するアプリケーション プールのメモリー占有領域は、3 MB のプライベート バイトと 5 MB のページング ファイルとなります (これは IIS 6 を上回るサイズです)。Windows Server 2008 の複数のアプリケーション プールを処理する能力は Windows Server 2003 よりも向上しています。ASP.NET 要求が発生すると、起動時に小さなサイズの CLR (100 KB 以下) をプリロードします。このプリロード処理は、ApplicationPool のプロパティの managedRuntimeVersion によって構成できます。残りの CRL (8 MB 以下) は、最初の ASPX 要求が発生した時点で読み込まれます。
32 ビット アプリケーション プールで Access を使用するユーザーが、32 ビット アプリケーション プールと 64 ビット アプリケーション プールを必要とすることはありますか?
Access は、32 ビット アプリケーション プールでのみ動作します。Classic ASP を使用している場合にユーザー プロファイル (アプリケーション プールの loadUserProfile プロパティ) を読み込むと、問題が発生します。ユーザー プロファイルの読み込み時に、Access が使用する一時ディレクトリには匿名ユーザーではアクセスできないことがその原因です。
Windows Server 2008 Web Edition にはどのような機能制限がありますか?
Windows Server 2008 Web Edition では、この点について大きく改善されており、人為的な制限を取り除くことに努めました。最終的なライセンス形態はまだ決定されていませんが、ハードウェアに関する制限をすべて取り除き、4x プロセッサーや 32 GB RAM (64 ビット上) をご利用いただけるようにする予定です。SQL が使用可能になり、SKU に SharePoint をインストールできるようになります。
Windows Server 2008 では、Front Page Server Extensions についてどのようなサポートが提供されますか?
今後、FPSE は Windows サーバーに搭載されません。マイクロソフトでは、サード パーティと共同で、Windows Server 2008/IIS 7 で動作する FPSE のダウンロード パッケージを作成中です。このパッケージには、新機能や強化機能は含まれず、互換性維持を目的とした機能修正のみ提供されます。
Windows Server 2008 では、インプレース アップグレードをサポートしていますか?
Windows Server 2008 を新規にインストールして移行するか、新しいサーバーに新規ユーザーを配置するようお勧めします。また、現在の環境を新しいサーバーでレプリケートできるようにするために、サード パーティのコンポーネントを一覧にして管理し、各サーバーの構成を記録するようお勧めします。サイトおよびアプリケーション プールの構成については、共有ホスティングの記事にある推奨事項を参照してください。移行作業を支援するツールが、近日リリースされる予定です。
インプレース アップグレードは、以下のシナリオでサポートされています。
- Windows Server 2003 を Windows Server 2008 Beta3、Windows Server 2008 RC0、Windows Server 2008 RC1、Windows Server 2008 RT にアップグレード
- Windows Server 2008 Beta3 を Windows Server 2008 Beta3、Windows Server 2008 RC0 にアップグレード
- Windows Server 2008 RC0 を Windows Server 2008 RC0、Windows Server 2008 RC1、Windows Server 2008 RTM にアップグレード
- Windows Server 2008 RC1 を Windows Server 2008 RC1、Windows Server 2008 RTM にアップグレード
サーバーが共有構成モードの場合、アップグレードを実行する前に、スタンドアロン構成に戻す必要があります。構成を戻すには、共有構成を無効にし、applicationhost.config および暗号化されたキーのコピーをローカル マシンに保存し、各サーバーでアップグレードを実行します。以上の処理が終了したら、再び共有構成を有効にします。
無人セットアップを行う際、使用するログ ファイルを指定できますか?指定可能な場合、ログに記録する内容を詳細に設定できますか?
セットアップが書き込みを行うログ ファイルと iis7.log は、両方とも常に有効です。ログに記録する内容を詳細に設定することはできません。
無人セットアップを行う際、pkgmgr を使用して、サード パーティ モジュールの使用を指定できますか?
セットアップ中に Windows モジュール以外のモジュールを構成する方法はありません。汎用的な無人セットアップを使用して、セットアップ後にモジュールを実行する方法はあります。この方法では、ユーザーがある程度コードを作成することができます。
失敗した要求トレースにより、どのようなパフォーマンスの低下が生じますか?特定のサーバー上のすべての Web サイトに対して、失敗した要求トレースを実行できますか?
1 秒あたり 1,000 件未満の処理速度ですべての要求のトレースを実行した場合の CPU 使用率は、5% 未満です。すべてのサイト用のグローバルなトレース規則を構成できます。<siteDefaults> セクションを変更することにより、すべてのサイトに対してトレースを有効にできます。
1 つのアプリケーション プールが使用するメモリーの容量を制限できますか?
いいえ、制限できません。ただし、メモリーベースのリサイクルは可能です。この場合、設定したメモリー制限を超過したアプリケーション プールがリサイクルされます。
Sysprep を実行すると、コンピューター キーを使って暗号化した資格情報は失われてしまいますか?この問題の回避策はありますか?
Sysprep を実行すると、実行する前に行った暗号化データは失われてしまいます。回避策はありません。
共有構成では、暗号化された資格情報を扱う複数のコンピューターをどのように操作しますか?
コンピューター キーをエクスポートして、すべてのサーバーへインポートすることによって、暗号化された資格情報を復号化できます。Server Beta 3 の UI に、複数コンピューターでの暗号化/復号化が可能な "共有構成" という機能があります。[エクスポート] をクリックすると、コンピューター キーの暗号化が行われ、applicationHost.config および administration.config といっしょに特定のパスにコピーされます。次に、その他のコンピューターで [インポート] をクリックすると、コンピューター キーがインポートされ、共有構成が構成されます。
クラシック モードと統合されたマネージ パイプライン モードを同時に有効にできますか?同時に有効にできる場合、一部のアプリケーションはクラシック モードに、その他のアプリケーションは統合されたマネージ パイプライン モードという風に構成することは可能ですか?
アプリケーション プールごとに異なる値を設定できます。アプリケーションは、複数のアプリケーション プールに割り当てることができます。
要求されたフォルダー内に既定のドキュメントが存在しない場合 (HTTP エラー 403.14)、このエラーによってサーバー バージョン情報に "IIS 7" と表示されます。情報漏えいを避けるため、この情報を非表示にすることは可能ですか?
このエラーを処理する既定のファイルは、\inetpub\custerr\ja-jp にあります。エラーのフッターに "サーバー バージョン情報: インターネット インフォメーション サービス 7.0. (Server Version Information: Internet Information Services 7.0.)" という情報があるのでこれを削除するか、.htm ファイルを直接編集してください。
マネージ API を使用して、リモートの IIS 7 サーバーをプロビジョニングできますか?
マネージ API (Microsoft.Web.Administration) は、ネイティブ API が処理可能なすべての設定にアクセスできます。また、ServerManager.OpenRemote 静的メソッドによって DCOM リモーティングがサポートされています。アプリケーション プールの状態や、要求やワーカー プロセスの一覧といったランタイム情報をサポートしていない Beta 3 を除き、すべての構成設定を設定できます。
URL 承認とは何ですか?URL 承認を使用する理由は何ですか?
以前のバージョンの IIS では、ファイル システムの ACL を使用してアクセスを制御していました。この方法は手間がかかり、Web インターフェイスも存在しませんでした。URL 承認では、IIS のユーザー インターフェイスを使用するか、web.config を直接編集することで、URL へのアクセスを制御できます。加えて、フォーム認証によって提供されるメンバーシップ ユーザーや役割といった Windows 以外の ID も使用できます。
applicationhost.config や web.config のどの設定を変更すると、すべてのアプリケーション プールの再起動がトリガーされますか?
applicationPool セクションの関連するデータ (つまり、applicationPoolDefaults の値またはそのアプリケーション プール固有のデータ)を変更すると、WAS はそのアプリケーション プールのリサイクルを実行します。特定の構成が変更されると、ワーカー プロセスは WAS にアプリケーション プールをリサイクルするよう要求します。これを行っているのは、今のところ、globalModules に対してのみですが、構成の変更によって他のモジュールもリサイクルすることができます。
Windows Server 2008 または IIS 7 にネイティブな負荷分散コンポーネントまたはクラスタリング コンポーネントはありますか?
NLB は Windows Server 2008 に搭載されています。機能は、基本的に Windows Server 2003 に搭載されているものと変わりありません。NLB をインストールするには、[サーバー マネージャー] > [機能] > [機能の追加] から、リストにある [ネットワーク負荷分散] を選択します。NLB を構成するには、コマンド プロンプトを開き、nlbmgr を実行します。これは、Windows Server 2003 に用意されているのと同じ UI です。
構成可能な CPU 使用率とは何ですか?
システム全体の CPU 使用率がしきい値を超えると、動的圧縮の処理が停止し、消費されていた CPU が解放されます。システム全体の CPU 使用率がもう 1 つの制限値を下回ると、動的圧縮が再開して、帯域幅が節約されます。
動的圧縮を常に無効にするのはどうでしょうか?
最適な CPU 使用率は、ユーザーによって意見が異なります。平均 20% が最適だと考えるユーザーもいれば、75% だという人もいます。もし使用率 X を維持したいのに常に X を超えているようであれば、動的圧縮は無用なので、完全に削除してしまってもよいでしょう。
頻繁に CPU 使用率が急上昇する場合は、動的圧縮はどのように動作しますか?
最後に取得したサンプルから 30 秒間の平均使用率によって動作が決まります。不規則に急上昇する場合も、使用率が急上昇してから最長で 30 秒間、動的圧縮が行われます。瞬間的に急上昇しただけ (30 秒間の平均 CPU 使用率にさほど影響を与えない） の場合は、影響はありません。
共有ホスティング環境では、LoadUserProfile の既定値としてどのような値を設定すべきですか?
共有ホスティング シナリオでは、applicationPoolDefaults で loadUserProfile=false と設定します。アプリケーション プールの起動時間が大きく短縮されるほか、一時ディレクトリのアクセス許可に関する問題をすべて回避できます。
"HTTP エラー 500.19 - 内部サーバー エラー" を引き起こす原因は何ですか?
500.19 エラーは、IIS 7 の機能の委任モードが原因です。ある機能をサイト所有者へ委任後、サイト所有者がその機能を変更した場合、その変更内容は web.config に保存されます。サーバー管理者がその機能の管理の委任を取り消した場合、Web サイト所有者は web.config から機能の詳細を削除しなければなりません。削除しない場合、委任された機能の変更が行われたすべてのサイトで、"HTTP エラー 500.19 - 内部サーバー エラー" メッセージが表示されます。この問題を回避するには、ホスト管理者は、委任した機能をエンド ユーザーに対して発行した後は、委任を取り消さないことを推奨します。
IIS 7 では、web.config の更新をどのように処理しますか?
ホストされているサイトの web.config が存在しない場合、IIS 7 は web.config を新たに作成します。サイトの web.config が存在する場合は、その web.config を変更します。web.config が変更されたら、サイト所有者は変更内容をマージします。必ず手動で変更をマージして、保持してください。
IIS 7 のインストール時に、管理サービスをインストールしませんでした。現在共有構成を使用していますが、今からこのサービスをインストールすると何か影響がありますか?
管理サービスをインストールしても、AppHost.config または Administration.config は変更されません。唯一の変更は、新しいバイナリ (wmsvc.exe) が作成されることです。自己署名入り証明書が作成され、いくつかのレジストリ キーが追加されます。つまり、理論的には影響は何もないはずです。
管理サービスをインストールする際、管理サービスと正しく連携して機能するように、共有構成 ACL に対して何らかの変更が加えられますか?
apphost/admon.config の読み取りに redirection.config 設定を使用するので、ほとんどの場合、共有構成 ACL は正常に動作します。ただし、厳密に答えるならば、シナリオによって結果は異なります。
- ローカル コンテンツを使用する共有構成: Windows または IIS の標準ユーザーがローカル コンテンツや web.config を変更する場合は、設定を変更しなくても、すべて正常に動作します。
- Windows ユーザーがリモート コンテンツを使用する共有構成: Windows アカウントがコンテンツへアクセスできる場合にのみ、共有構成 ACL は問題なく動作します。
- IIS ユーザーがリモート コンテンツを使用する共有構成: このシナリオでは、コンテンツへのアクセスにプロセス ID を使用するので、サービス (WMSVC) の ID を、リモート コンテンツにアクセス可能なアカウントに変更する必要があります。redirection.config を使用するので apphost.config/admon.config は正常に動作します。
- サーバー接続を管理する Windows 管理者: Windows 管理者が共有構成への "書き込み" アクセス許可を持っていれば、共有構成 ACL は問題なく動作します。
どのような方法でコマンド ラインから Web サイトを作成できますか?
IIS 7 でサイトを作成する方法について、次のリンクを参照してください。
http://technet.microsoft.com/ja-jp/library/cc772350.aspx
CLR は、w3wp とアプリケーション プールごとに自動で読み込まれますか?
すべての機能がインストールされた、静的ファイルのみを提供するアプリケーション プールは、3 MB のプライベート バイトと 5 MB のページング ファイルを占有します。ASP.NET 要求が発生すると、起動時に小さなサイズの CLR (100 KB 以下) をプリロードします。このプリロード処理は、ApplicationPool のプロパティの managedRuntimeVersion によって構成できます。残りの CRL (8 MB 以下) は、最初の ASPX 要求が発生した時点で読み込まれます。
IIS 7 は、新しい Web サイトをプロビジョニングする際に、W3SVC1 や FTPSVC2 といったフォルダーを作成し、Administrators および SYSTEM にフル コントロールのアクセス許可を割り当てます。これにより、サイトのユーザーは、これらのフォルダー (およびフォルダー内のログ ファイル) をダウンロードできなくなります。こうした IIS 7 の動作を変更して、親ディレクトリから継承したアクセス許可を持つログ ディレクトリを作成するようにすることは可能ですか?
これらのフォルダーが存在しない場合は、Http.sys がフォルダーを自動的に作成します。アクセス許可を別のアクセス許可に変更すると、新しいアクセス許可が保持されます。
IIS 7 には、ColdFusion 8 との互換性はありますか?
内部的にこの互換性をテストしましたが、ISAPI とメタベースがインストールされている場合、正常に機能するようです。また、IIS 7 で ColdFusion 8 を使用する方法を紹介しているオンライン ブログがいくつかあります。詳細については、以下のリンクを参照してください。
http://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx (英語).
WSS3 で IIS 7 を設定し、サーバーの一元管理機能を使用してサイト コレクションを作成したところ、"サーバーの現在の構成はこの設定をサポートしていないため、ページを表示できません。このタスクを実行するため、Stsadm.exe でコマンド ライン操作を行ってください。" というエラー メッセージが表示されてしまいます。これは何が原因ですか?
サーバーは、AD のアカウント作成モードで設定されています。AD 作成モードは非推奨機能 (サポートは継続されています) で、V4 では廃止される予定です。WSS によって AD にユーザーを自動的に作成するのではなく、WSS を使用せずにユーザー プロビジョニングを行うことをお勧めします。
一元化された共有グローバル構成機能に関する詳細情報は、どこで入手できますか?
一元化されたグローバル構成についての詳細は、次のサイトを参照してください。IIS 7 の構成システム
FrontPage Server Extensions は Windows Server 2008 64 ビット版で使用できますか?I386 用のダウンロードしか見つかりません。
現時点では、64 ビット用の FPSE は提供されていません。推奨される共有ホスティングのアーキテクチャは、32 ビット アプリケーション プールを使用した 64 ビット OS です。残念ながら、現在このシナリオで FPSE を 64 ビット OS にインストールできないバグがあります。
以前は Windows Server 2008 のインストールにプロダクト キーは必要ありませんでしたが、現在では、ライセンス認証コードが求められます。現在プロダクト キーを確認できないのですが、どうしたら Windows Server 2008 を再度ライセンス認証できますか?
以下の手順に従って、3 回までシステムをリアームできます。
slmgr /rearm を実行するには、regedit.exe を実行して、HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL へ移動します。"skiprearm" の値が "0" に設定されていることを確認します。この値が 0 以外の場合、リアーム機能によるシステムのライセンス認証タイマーのリセットが行われません。
"skiprearm" レジストリ値がゼロ (0) であることを確認後、管理者特権で起動したコマンド プロンプトから slmgr /rearm を実行します。プロセスの完了が通知されるまで待機します。完了まで 1 ～ 2 分かかります。処理が完了したら、メッセージに従いコンピューターをシャットダウンします。再起動後、コンピューターは最初の猶予期間 (OOB) に入ります。30 日以内にライセンス認証を行います。その他のシステムに対する変更はありません。
複数の Web サーバーに X509 証明書を展開する方法として推奨されるのはどのような方法ですか?
IIS 7 にも IIS.CertObj COM オブジェクトが存在します。複数の Web サーバーで証明書を展開する上で、このオブジェクトが最良の選択肢であると考えています。このコンポーネントの動作はこれまでと同様で、従来のすべてのスクリプトが機能します (ABOMapper が有効な場合)。
メモ: LH RC0 には、セキュリティで保護されたバインドをインスタンス名として指定できる新機能が追加される予定です。
set iiscertobj = CreateObject("IIS.CertObj")
iiscertobj.InstanceName = "0.0.0.0:443"
iiscertobj.Import pfxfile, pfxfilepassword, true, true
このようなスクリプトは、ABOMapper に依存しません。