IIS

2013年7月18日木曜日

◆ポート8080でサイトを追加する

SharePointが稼働しているサーバーに静的ドキュメント用のサイトを追加する。
ポート8080とかで追加するパターンが多いようなのでそれに倣う。
基本中の基本の設定と思うのだが、素人の悲しさ、やけに戸惑ってしまったのでメモしておく。

まずはドキュメント公開用のフォルダを作成。(D:\TEST)

IISマネージャを立ち上げ、「サイト」を右クリックして「Webサイトの追加」をクリック

「Webサイトの追加」ダイアログで以下のように指定。
サイト名：TEST
アプリケーションプール：DefaultAppPool
物理パス：D:\TEST
ポート：8080

アプリケーションプールはサイト名と同じ名前で新規に仮定されるが、分けるほどではないと思うのでここでは「DefaultAppPool」に突っ込む

TESTフォルダの中に適当なHTMLファイルを置いて参照してみる。

とりあえず良さそう

次に外部PCから確認

っと、デフォルトのままではダメぽ

FireWallですかね・・・。

さて、どうやって穴を開けるのか。

「FireWall.cpl」でファイアウォールを起動し、
現在稼働している「SharePoint」の受信規則を見てみると以下のようになっている。

これ自体を修正して「80」ポートに「8080」ポートを追加するという感じでもないので、別途新しい規則を追加してみる。

右側の操作ペインから「新しい規則」をクリック

「ポート」を選択して「次へ」

「特定のローカルポート」として「8080」を指定して「次へ」

「接続を許可する」を選択して「次へ」

規則の適用対象に「ドメイン」を指定して「次へ」

適当な名前を付けて「完了」

アクセス確認

なお、どうやって作ったのか記憶にないのだが、ローカルユーザーにアクセス権の無いフォルダ（ドメインユーザーのみにアクセス権）があり、エラーとなるケースがあった。
IIS自体はローカルユーザー（IIS_IUSRS?)としてアクセスするので、このユーザーもしくはローカルのUsersグループにファイルアクセス権を付けておく必要がある。

めでたしめでたし、と思ったのだが、次の日試してみるとなぜか認証ダイアログが表示されて何を入れても通らない状態になってしまった。(><)

半日ほどああでもないこうでもないと調べた挙句やっと原因が判った。

実は、この手順を纏めているときはDefaultAppPoolを使っていたのだが、最終的に本物を作る時にはデフォルトのままサイト名と同じアプリケーションプールを使用してしまった。
直接的にそれ自体悪いことではないのだが、何かしらアプリケーションプールによっては（偶然？）今回のような現象を引き起こす不具合があるようなのだ。
TechNet Blogs

回避するためのパッチも出ているようだが、さしあたって実行アカウントを「NetworkService」にすることによって回避できるらしい。

なんともいただけない・・・。
「trustworthy」自体悪くはないのだが、それ以来権限に絡むMS製品の不具合は飛躍的に増えてトラブルばかり・・・。

ちなみに、「承認規則」で拒否に追加したサイトにアクセス不能になったりしても同じ現象（ログインできない）を引き起こすので注意が必要。

本番サーバーで突然こんな状態になったら大事故だな・・・。

2013年3月2日土曜日

◆ワーカープロセスの監視

ワーカープロセスとはアプリケーションプールが実行された際のプロセス。
複数のアプリケーションプールを共存させることも可能。

現在稼働しているワーカープロセスの一覧を表示するには

IISマネージャを起動する
「接続ウィンドウ」のツリービューでコンピューター名を選択
「機能ビュー」で「ワーカープロセス」アイコンをダブルクリック
現在実行中のプロセスが表示される（実際には起動直後などまだリクエストが無いような状態ではプロセスは起動されていないようである）

何かしらASPXページにアクセスしてみるとプロセスが表示される

表示される各項目の説明は以下の通り

また、この情報はコマンドでも表示できる。

とあったが、以下のようなエラーとなった。

WASサービス自体は起動しているのだが・・・・。

PowerShellで実行すると大丈夫だったので深くは追及しない。

◆アクセスログ

IISでは自らのサービスの状態と挙動を監視するための機能を提供している。
ここではアクセスログを説明する。

アクセスログの場所

IISのアクセスログは規定で以下に記録される。
C:\inetpub\logs\Logiles

さらにWebサイト、FTPサイトごとにフォルダーが分割され、それぞれサイトIDが付加されたフォルダに保存される。

Webサイト：”W3SVC” + サイトID（数字）
FTPサイト：”FTPSVC” + サイトID（数字）

（例）

サイトIDはIISマネージャでサイトの詳細設定を表示すると確認できる。

アクセスログの内容

アクセスログはテキスト形式で保存されているため、メモ帳などでその中身を確認できる。

規定で出力される内容は以下の通り。

Excelなどで分析するか、無償で提供されている「Log Parser」というツールで分析しても良い。
Log Parser 2.2 日本語版

ログファイルは自動では削除されないので適当な時期に整理したほうが良い。

アクセスログの種類

IISで指定可能なアクセスログの形式は以下の通り。

＜ログの形式の変更方法＞

「IISマネージャ」で対象のサイトを選択
「機能」ビューで「ログ記録」をダブルクリック
「ログ記録」の設定画面が表示されるので「形式」ドロップダウンリストボックスから任意の形式を選択
画面右の「操作」ペインで「適用」をクリック

アクセスログの記録項目を変える

ログファイル形式が「W3C」の場合に限り、ログファイルが記録する項目を変更することができる。

IISマネージャにて対象のサイトを選択
「機能」ビューにて「ログ記録」をダブルクリック
「ログ記録」の設定画面で「形式」が「W3C」でなければ「W3C」に変更
「フィールドの選択」ボタンをクリック
「W3Cログ記録フィールド」ダイアログボックスが表示されるので、ログファイルに記録したいフィールドのチェックボックスにチェックを入れるか、記録したくないフィールドのチェックを外すかして「OK」
「操作」ペインの「適用」をクリック

アクセスログファイルの分割方法

規定では1日1ファイルに記録されるが、変更することも可能。

IISマネージャにて対象のサイトを選択
「機能」ペインで「ログ記録」をダブルクリック
「ログ記録」画面にて「ログファイルロールオーバー」セクションの「スケジュール」オプションにチェックをつけ、ドロップダウンからログファイルを切り替えるタイミングを指定する。

期間では無く、サイズで変更したい場合は「ファイルの最大バイト数」オプションにチェックをつけ、テキストボックスにファイルサイズをバイト単位で指定する。

さらに、ログファイルを分割せずに１つのファイルに記録し続けたい場合は「新しいログファイルを作成しない」オプションをチェックする。
「操作」ペインの「適用」をクリック

ログについての詳細な設定方法は以下のドキュメントを参照。
IIS 7 でログ記録を構成する

2013年2月28日木曜日

◆アプリケーションの実行環境を設定する

IISで実行できるアプリケーションは、「ASP」「ASP.NET」「PHP」他、何種類かあるようだが、メインはやはり「ASP.NET」になると思われるので、ここでは「ASP.NET」のみ簡単に纏めておく。

環境設定

Windows Server 2008R2の場合

「サーバーマネージャ」で「Webサーバー(IIS)」を展開し「役割サービスの追加」をクリック
「役割の追加」ウィザードが起動し、「役割サービスの選択」画面が表示されるので、以下の追加役割サービスを選択し「次へ」ボタンをクリックする。
・ASP.NET
・.NET拡張機能
・ISAPI
・ISAPI拡張機能
（「ASP.NET」を選択すると以下のダイアログボックスが表示されるので「必要な役割サービスを追加」ボタンをクリックする。その際にその他の必要な役割も自動で選択される。
「インストールオプションの確認」画面が表示されるので「インストール」ボタンをクリック

Windows7の場合

「Win + R」で「ファイル名を指定して実行」を開き「appwiz.cpl」
「Windows の機能の有効化または無効化」リンクをクリック
「Windowsの機能」ダイアログボックスで「インターネットインフォメーションサービス」のツリーより以下の追加機能を選択する。
・ASP.NET
・.NET拡張機能
・ISAPIフィルター
・ISAPI拡張機能
「OK」をクリックしてインストール実行

ASP.NETを実行してみる

以下のソースをメモ帳に張り付けて「Hello.aspx」という名前で保存する

<%@ Page Language="C#" %>

<html>

</head>

<body>

<h3>

<%="Hello World" %>

</h3>

</form>

</body>

</html>

作成した「Hello.aspx」ファイルを「c:\inetpub\wwwroot\webApp」フォルダにコピー
「Win + R」で「名前を指定して実行」を開いて「inetmgr」
IISマネージャが起動したら「Default Web Site」の「webApp」仮想ディレクトリを選択
右クリックして表示されたメニューから「アプリケーションへの変換」をクリック
「アプリケーションへの変更」ダイアログボックスが表示sれるので規定のまま「OK」をクリック
ブラウザから「http://localhost/webapp/hello.aspx」にアクセスして「Hello World」が表示されるのを確認

ASP.NETのエラーをログで確認する

「win + R 」でファイル名を指定して実行を開き「eventvwr.msc」でイベントビューワーを起動する
左側のツリービューから「アプリケーション」を選択し、右側の操作ペインで「現在のログをフィルター」をクリック
「現在のログをフィルター」ダイアログボックスが表示されるので「イベントソース」ドロップダウンから「ASP.NET」を選択して「OK」
ASP.NETに関するイベントログのみが表示されるので、任意のイベントログをダブルクリックして内容を確認する

2013年2月27日水曜日

◆ASP.NETモジュールを使えるようにする(IIS8)

バージョンおよびクライアント・サーバーの別でも微妙に違ってくる。

とりあえず、現時点の最新バージョン（IIS８）の「Windows Server 2012」と「Windows8」でのインストール方法が以下に載っている。
手順 1: IIS と ASP.NET モジュールをインストールする

Windows8での手順を要約しておくと、

「win + R」で「appwiz.cpl」
「Windowsの機能の有効化または無効化」をクリックしダイアログを開く
「インターネットインフォメーションサービス」「World Wide Web サービス」「アプリケーション開発機能」と展開し「ASP.NET 4.5」をチェック（「.NET 拡張機能4.5」「ISAPIフィルター」「ISAPI拡張」には自動でチェックがつく）

2013年2月25日月曜日

◆エラーページをカスタマイズする

以前も少し調べたことがあるのだが、どうも理解できていないのでもう一度挑戦。
MTG Blog: ◆IISエラーページのカスタマイズ

カスタマイズ操作

「IISマネージャ」を起動する
「機能ビュー」から「エラーページ」をダブルクリックして開く
「エラーページ」画面でカスタマイズしたい「エラーコード（状態コード）」をダブルクリックして開く　　　
「応答動作」にデフォルトの代わりに表示させたいページを指定して「OK」をクリックする

静的ファイルのコンテンツをエラー応答に挿入

実際にエラー応答をどう設定するかとなるとIIS8になっても設定画面は変わりが無く、良くわからない。
前回に引き続きもう一度手探りで調べてみる。

まずは「静的ファイルのコンテンツをエラー応答に挿入」という事なのだが、これは単純に静的カスタマイズページを返すという事なのか、もともとのテンプレート的なエラーページに、部分的にエラーページを挿入できるということなのか？

英語も見てみたが、特にMSお得意の誤訳といった感じでもなかった。

Web.configで設定するサーバー屋さんからすれば当たり前の事なのか、さっぱりここら辺の情報は見つからない。

我々プログラマーからすると、どうしてこんなに単純なことが簡単にできないのか不思議だ。

とりあえず、カスタマイズしたファイルを指定してみる。
以前調べたときに、「このサイトでURLを実行」に指定してうまくいったのと同じ記法で指定してみた。

これで存在しないファイルにアクセスしてみると、

といった表示になり、「MyError.html」は表示されない。

パスの書き方を色々変えてみても一向にうまくいかない。
前回と同じだ。

ググってみてもやっぱり前回同様、これといった情報を見つけられない。
仕方がないので地道にログを探っていくこととした。

まずは「C:\inetpub\logs\LogFiles\W3SVC1」にある「IISアクセスログ」を見てみたが、特に有益な情報は無し。

そこで、「トレース」機能をインストールして「失敗した要求トレース」なるものを見てみる。
IIS: ◆「失敗した要求のトレース」を使う

すると、404のエラーが発生した後に、カスタマイズしたエラーファイルにアクセスしている部分が見つかった。

これを見ると、明らかに「/MyError.html」の書き方が間違っているのがわかる。

そこで「MyError.html」に修正して再度見てみる。

すると、どうみてもカスタマイズした「MyError.html」の内容をリターンしているのが判る。

ん～、どうやら問題はサーバー側ではなくクライアント側のようだ。

こんどは、実在しないページを要求したときのクライアント側のトレースを見てみる。
IEでは「F12」を押すと簡単にトレースが見れる。
「ネットワーク」タブを選択し、「キャプチャの開始」をクリックしてから実在しないページにアクセスしてみる。

「キャプチャの停止」をクリックし「詳細ビューに移動」をクリック

「応答本文」タブをクリックして表示させると、

あれー、ちゃんと来てるじゃない。

試しに「Chrome」で見てみると、あらら、カスタマイズページが表示されるじゃないですかぁ。

IEの問題？

調べてみると、以下に説明があった。
IIS 7.0 で HTTP の詳細エラーを使用する方法

これによると、「400～500」の範囲の状態コードがサーバーから帰ってきた場合はIE側でエラー表示を差し換えている模様。

この差し替えをやめるには、「インターネットオプション」「詳細設定」「ブラウズ」にある「HTTPエラーメッセージを簡易表示する」のチェックをはずす。

これで、前回の調査から苦節１年やっと「静的ファイルのコンテンツをエラー応答に挿入」することができた。

クライアント言語でエラーファイルを返す

静的ファイルがうまく返せたので、今度は「クライアント言語でえらーファイルを返す」に挑戦。（個人的には使うことはないと思うが）

「クライアントの言語でえらーファイルを返す」をチェックして「設定」ボタンをクリックする
ここで、「ディレクトリパス」に何を指定すれば良いか？
「\」や「/」を指定すると以下のような応答が表示されるのだがカスタマイズした内容ではない。またトレースを見てみたところやはりサーバー側でエラーになっていた。
色々と試行錯誤した結果「.」ピリオドを指定すればよさそうだ

これで静的ファイルはOKと思ったのだが、たまたまエラーファイルをサブディレクトリにと思ったら、これがなぜかうまくいかない。

以下のような指定をして、

「カスタムエラーページの編集」に戻って「OK」ボタンを押すと

といったエラーが表示されて保存することができない。

いや～、ルートディレクトリなんて指定したつもりはないんだけど・・・。

どうにもこうにもエラーを回避できない。
調べてみると、以下のMSの資料を見つけた。

[ローカライズされたカスタムエラーのパスの設定] ダイアログボックス

どうもこれを見ると、エラーメッセージが言う通り絶対パスを指定するっぽい。
（カレント指定はできたのに・・・、不思議な仕様だ）

まぁ、仕方がないので絶対パスで指定してみる。
おぉー、今度は保存できた！！

しか～し、ブラウザでアクセスしてみると、

こっちでは「相対パス」を指定しろと怒られる。
一体全体誰を信じれば良いの？

このエラーコードでググってみるとMSの人のブログが見つかった。
MSDN Blogs

これを見ると、絶対パスを許可するように設定を変更しろとの事。
手順は以下の通り

「IISマネージャ」を開く
「ルート（サーバー名）」を選択
「機能ビュー」「管理」「構成エディタ」を起動
「セクション」で「httpErrors」を選択
「allowAbsolutePathsWhenDelegated」を「True」に設定
右側の「操作ペイン」で「適用」をクリック

これでやっとカスタマイズしたエラーが表示された。

本当に、こんな複雑怪奇なものが正しい仕様なのだろうか・・・。

このサイトでURLを実行

なんとか「静的ファイル」の指定がうまくいったので、今度は「このサイトでURLを実行」

こちらは以下のような指定で単純にうまくいく。

記入例にあるように「aspx」ファイルでも大丈夫だ。

結局、「静的ファイルのコンテンツをエラー応答に挿入」と「このサイトでURLを実行」では何が違うのか。
字面だけでは感じ取れないが、「静的」の方は状態コード「404」を返し（今回の場合）、「URLを実行」では「200」を返しているのが根本的な違いではなかろうか・・・。

なので、「URLを実行」の方はブラウザの設定によらず最初からカスタマイズしたエラーページを表示することができた。

では、実際どう使い分けるのか？
はっきり言って「意味不明」

「IE」のデフォルト設定を考えれば「静的」の方はデバッグ情報などを表示するのかとも思うが、なぜにこちらにしか言語対応がないのか・・・。

リダイレクトによる応答

以下のような指定でうまくいく。

こちらはリダイレクトなのでアドレスも指定したものに変わっている。

※使い分けは別にして、３通りの指定の違いは結局クライアントに返す状態コードの違いという事のようだ。

登録: 投稿 (Atom)