IIS 7.0 に関する一般的な質問

この操作は手動で行う必要があります。

影響は、サーバーの負荷によって異なります。 1 秒あたり 10,000 件の要求を実行している場合は、カーネル キャッシュがひどく失われますが、1 秒あたり 100 件の要求を実行している場合は、おそらく気付かれないでしょう。 これは処理されるコンテンツに大きく依存します。IIS 5.0 にはカーネル モード コンポーネントがなかったため、ほとんどのお客様にとってうまくいっていました。

Ruby の基本的なサポートがあります。 詳細については、次のリンクを参照してください。

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

サーバー マネージャーの GUI ([機能の追加]) を使用してインストールする場合、インストールの順序は関係ありません。 [機能の追加] ウィザードでは、すべての依存関係がチェックされ、必要なモジュールがない場合は警告が表示されます。 さらに、[機能の追加] ウィザードでは、モジュールの正しい順序が認識されます。

コマンド ラインからインストールする場合、または無人インストールを使用している場合、モジュールの順序は関係ありません (ここでも、セットアップではモジュールの正しい順序が認識されています)。ただし、ユーザーはすべての依存関係を識別する責任があります。 必要な依存関係を含めなかった場合、無人セットアップまたはコマンド ラインセットアップは失敗します。

すべての機能がインストールされている静的ファイルのみを提供するアプリケーション プールには、3 MB のプライベート バイト、5 MB のページ ファイルのフットプリントがあります。 (これは IIS 6.0 より大きいです)。 Windows Server 2008 では、複数のアプリケーション プールが WS03 よりもうまく処理されます。 ASP.NET 要求が行われると、起動時に少量の CLR を事前に読み込みます (約 100 kb)。 プリロードは、ApplicationPool のプロパティによって構成できます。 これは managedRuntimeVersion と呼ばれます。 残りの CLR (最大 8 mb) は、最初の ASPX 要求で読み込まれます。

Access は、32 ビット アプリケーション プールでのみ機能します。 ユーザー プロファイルの読み込み (AppPool での loadUserProfile プロパティ) は、Classic ASP を使用する場合に問題になります。これは、ユーザー プロファイルの読み込み時に匿名ユーザーへのアクセスを許可しない temp ディレクトリが Access で使用されているためです。

Windows Server 2008 Web エディションは大幅に改善され、人為的な制限を取り除くことに重点を置いています。 最終的なライセンスはまだ完了していませんが、すべてのハードウェア制限を解除し、4x プロセッサと 32 GB RAM (x64 上) を許可する予定です。 SQL は許可され、SharePoint は SKU にインストールできます。

FPSE は Windows Server の一部ではなくなりました。 Microsoft はサードパーティと協力して、WINDOWS Server 2008/IIS 7.0 で動作する FPSE 用のダウンロード パッケージを作成しています。 新しい機能や拡張機能はありません。互換性を持たせるために修正されただけです。

Windows Server 2008 を新規にインストールしてそこに移行するか、新しい顧客を新しいサーバーに配置することをお勧めします。 サード パーティのコンポーネントと構成の適切な管理リストをサーバーごとに文書化して、現在の環境を新しいサーバーでレプリケートできるようにすることをお勧めします。 サイトとアプリケーション プールの構成に関する共有ホスティング文書の推奨事項を参照してください。 移行を支援するツールは、近い将来にリリースされる予定です。

インプレース アップグレードは、次のシナリオでサポートされます。

• Windows Server 2003 は、WS2K8 Beta3、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 秒あたり 1000 件未満<の要求ですべての要求をトレースするには、CPU を 5% 未満にする必要があります。 すべてのサイトに対してグローバル トレース ルールを構成できます。 <siteDefaults> セクションを変更することで、すべてのサイトでトレースを有効にすることができます。

いいえ。ただしメモリベースのリサイクルがあり、これによって、構成されたメモリ制限を超える AppPool がリサイクルされます。

sysprep より前に行われた暗号化は、sysprep の後に失われます。 回避策はありません。

暗号化解除が機能するように、マシン キーをエクスポートしてすべてのサーバーにインポートできます。 これを行うことができる共有構成と呼ばれる機能が Server Beta 3 の UI に含まれています。 [エクスポート...] をクリックすると、マシン キーが暗号化され、applicationHost.config と administration.config と共にパスにコピーします。 その後、他のすべてのマシンから [インポート...] を選択できます。すると、マシン キーがインポートされ、構成が共有構成にポイントされます。

この設定の値は AppPools によって異なる場合があります。 アプリケーションを別の AppPools に割り当てることができます

このエラーを処理するための既定のファイルは、\inetpub\custerr\en-us に含まれています。 エラーのフッターには、"Server Version Information: Internet Information Services 7.0." と記載されており、これはもちろん .htm ファイルから直接削除するか編集することができます。

マネージド API (Microsoft.Web.Administration) は、ネイティブ API が実行するすべての設定にアクセスでき、ServerManager.OpenRemote 静的メソッドを使用して DCOM リモート処理をサポートします。 任意の構成設定を設定できますが、Beta 3 では、AppPool の状態や要求またはワーカープロセスの一覧などのランタイム情報はサポートされていません。

以前の IIS バージョンでは、ファイル システム ACL を使用してアクセスを制御する必要がありました。 これは面倒で、それを行う Web インターフェイスはありません。 URL 認可を使用すると、IIS ユーザー インターフェイスを使用するか、web.config を直接使用して URL へのアクセスを制御できます。 さらに、Windows 以外の ID (フォーム認証によって提供されるメンバーシップ ユーザーとロールなど) を使用できます。

そのアプリ プールに関連する applicationPool セクション内のデータ (applicationPoolDefaults またはそのアプリ プールに固有のデータ) が原因で、WAS ではアプリ プールがリサイクルされます。 ワーカー プロセスでは、特定の構成変更に基づいてアプリ プールをリサイクルするように WAS に要求でき、現時点では globalModules だけですが、これはクローズド リストではありません (モジュールでは構成変更に基づいてリサイクルを要求できるため)。

NLB は Windows Server 2008 の一部です。 これは基本的に Windows 2003 にあったものと同じです。 NLB をインストールするには、[サーバー マネージャー] > [Features]\(フィーチャ\) > [機能の追加] に移動し、一覧から [ネットワーク負荷分散] を選択します。 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 サイトの所有者は、その機能の詳細を 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 でのサイトの作成については、次のリンクを参照してください。

すべての機能がインストールされている静的ファイルのみを提供するアプリケーション プールには、3 MB のプライベート バイト、5 MB のページ ファイルがあります。 ASP.NET 要求が行われると、起動時に少量の CLR を事前に読み込みます (約 100 kb)。 プリロードは、ApplicationPool のプロパティによって構成できます。 これは managedRuntimeVersion と呼ばれます。 残りの CLR (最大 8 mb) は、最初の ASPX 要求で読み込まれます。

これらのフォルダーは存在しない場合、Http.sys によって自動的に作成されます。 アクセス許可を別のものでオーバーライドする場合は、新しいアクセス許可が保持されるはずです。

Microsoft の社内でテストしており、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 はありません。 共有ホスティングの推奨アーキテクチャは、64 ビット OS で 32 ビット AppPools を使用することです。 このシナリオでは現在、残念ながら、FPSE が 64 ビットにインストールできなくなるバグがあります。

次の手順を実行して、システムを 3 回再初期化できます。

slmgr /rearm を実行するには、regedit.exe を開き、HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL に移動します。 値 "skiprearm" が '0' に設定されていることを確認します。 この値が 0 以外の場合、再初期化機能ではシステム アクティブ化タイマーがリセットされません。

"skiprearm" レジストリ値が 0 (ゼロ) であることを確認したら、管理者特権でのコマンド プロンプトから slmgr /rearm を実行します。 プロセスが完了したことを示す通知を待ちます。 この処理には 1 ～ 2 分かかる可能性があります。 完了したら、プロンプトに従ってコンピューターをシャットダウンします。 再起動すると、コンピューターは最初の猶予期間 (OOB Grace) で実行され、あと 30 日間アクティブ化されます。 このプロセスによって、他の変更がシステムに行われることはありません。

IIS 7.0 には IIS.CertObj COM オブジェクトがまだ存在するため、Microsoft では、やはりこれが複数の Web サーバーに証明書を展開するための最適なオプションであると考えています。 このコンポーネントの動作は同じままであるため、すべての古いスクリプトが機能するはずです (ABOMapper が有効になっている場合)。

set iiscertobj = CreateObject("IIS.CertObj")

iiscertobj.InstanceName = "0.0.0.0:443"

iiscertobj.Import pfxfile, pfxfilepassword, true, true

また、このようなスクリプトは ABOMapper に依存しません。