IIS Insider: 2006 年 9 月

良い質問ですね。ソリューションを確認する前に、スマート ホストについて理解しましょう。スマート ホストとは何でしょうか? 下記は、マイクロソフトの文書によるものです:

「スマート ホスト – すべてのリモート ドメインの送信メッセージをドメインに直接送信する代わりに、スマート ホストを経由してルーティングできます。これは別の方法にくらべて、より直接的または低費用で、メッセージを接続上で送信することができます。このスマート ホストはリモート ドメインのためのルート ドメインのオプションに類似しています。相違点としては、一旦スマート ホストが指定されたら、すべての送信メッセージはそのサーバーにルーティングされます。ルート ドメインでは、リモート ドメインのメッセージのみが特定のサーバーにルーティングされます。」

次に、理解しておくべき重要なことは、SMTP のリクエストの受信および送信の場合に、接続の認証が 2 種類あるということです。受信は、クライアント自身がメール メッセージをローカルの SMTP サーバーにリレーできる前に、ローカルの SMTP サーバーに対して認証を行うことです。その一方で、送信の認証はリモートの SMTP サーバーがそのメッセージのいずれかを許可する前に、ローカルの SMTP サーバーがリモートの SMTP サーバーを認証するものです。スマート ホストでリレーされたメッセージは送信接続と考えられます。そのために、送信認証の設定が必要になるのです。

IIS 6.0 で正しく設定するために、以下をご覧ください。

1. IIS MMC を表示します。

2. SMTP 仮想サーバー (スマート ホストに送られる) を右クリックし、[プロパティ] を選択します。

3. [Delivery] タブをクリックし、図 1.1 のような [Outbound Security] ボタンをクリックします。

1. ここで行うことは、独自のスマート ホストの設定により異なります。Active Directory の Microsoft Exchange である場合、クリア テキストの認証を防ぐために、「統合された Windows 認証」を構成することができます。私の場合は、iMail サーバーに対してなので、「基本認証」だけに依存できます。もちろん、通信の安全性を確保するために、SSL の証明で TLS の暗号化を適用可能です。

2. 希望する認証スキームに関連する丸ボタンを選択し、ログオンのユーザー資格情報を入力します。私の場合は、図 1.1 のように「relayuser@mydomain.com」です。

3. 変更を適用するために、[OK] を 2 回クリックします。

4. IIS SMTP サービスを再起動する。

認証が行われたかどうかをモニターするためには、IIS SMTP のログ ファイルを確認します。既定は [匿名] のアクセスで、送信の接続に認証が必要ないことを意味しています。送信通信の認証が有効になったら、IIS SMTP はサーバーにメール メッセージを転送する前に、スマート ホストを認証します。

一般的に、このエラーは正しく構成されていない NTFS の許可に関連しています。ログオン イベント (技術的に、ユーザーはログオンしているが、そのホーム ディレクトリには進めない状態) の後にエラー メッセージが表示されることは、一般的なことです。ここで、ユーザー ディレクトリが正しい ACL を持っているか、ユーザーがフォルダへのアクセス許可を得ているかを確認してください。また、www.sysinternals.com から Filemon を入手すると、権限の許可に関連する問題の追跡に役立ちます。

みなさんが、三重に検証された権限の許可の設定を行っていて、問題が検出されない場合、最近のサーバーの変更について、サーバー ログの本 (所有している場合) を確認することをお薦めします。IIS FTP ログ ファイルを確認すると、最初に問題が起きた時期がわかります。ログオンのイベントを追跡するためにセキュリティの監視を有効にしている場合、イベント ログを確認し、イベント エラーに関連する何かを見つけ、そこからトラブルシューティングを行うことができます。ログオンのセキュリティの監査を有効にすることは、優れたセキュリティ実施の一部です。詳細は、「セキュリティ監査を有効にする」をご覧ください。

終わりに、エラー メッセージについて、あなたと同様の投稿者に協力したことがあります。その際、いくつかのメッセージのやりとりをして、それは統合された AD 接続のユーザー アカウントが原因であると考えました。これは、Active Directory 情報にアクセスするために使用する アカウントの FTP です。FTP のサイトを作成するためのウィザードを使用する際に、このアカウントを特定する必要があります。

上のケースでは、FTP サイトは実行されていましたが、FTP AD のユーザー アカウント パスワードが変更されていました。この場合、まったく同じエラー メッセージが再び表示されますが、エラーについてヒントが提供されないので、あまり意味がありません。

その解明方法は、最近変更がおこなわれたかどうかの有無を質問したところ、彼は AD アカウント パスワードが変更されたことを思い出したのです! これが問題を理解した経緯です。そして、ユーザーがログオンに失敗し、ホーム ディレクトリにアクセスできず、不完全なユーザー名やパスワードのためにログオンに失敗したことを示しているイベント ログで、詳細な情報がおわかりになると思います。

投稿者にアドバイスをする前に、彼は自分でソリューションを生みました。FTP サイトを削除して新たなサイトを再び作成したのです!

そうですね。彼は抜本的なことを行いました。しかし、サイト全体を再度作成する必要はありません。彼にとっては、そうは思えなかったのでしょうが。しかし、FTP サイトが作成されたら、AD の接続アカウントまたはパスワードを変更する方法はありません。

それは、まったく正しいです。IIS MMC – FTP UI はそのような変更をサポートしませんが、みなさんは IIS のすべての設定がメタベースに保存されていることを覚えていると思います。ですから、メタベース レベルでの変更が可能です。ここには、その FTP の AD の構成を制御する 2 種類のメタベースのキーがあります。

ADConnectionsUserName および ADConnectionsPassword

通常のように、このキーを ADSUtil.vbs で構成します。

値を読み取る場合:

C:\Inetpub\AdminScripts>adsutil.vbs get msftpsvc/XX/adconnectionsusername

XX は FTP サイトの ID で、その値は以下のように得ます:

Adconnectionsusername: (String) “myAD\ftpuser”

ここでは、AD 接続のユーザー パスワードをリセットするための実際のステップです:

1. コマンド プロンプトを表示します。

2. AdminScripts フォルダを表示します。例えば、「cd\Inetpub\AdminScripts」です。

3. 以下のコマンドを入力します:

   C:\Inetpub\AdminScripts>adsutil.vbs set msftpsvc/1735/adconnectionspassword myftppwd2111

   Adconnectionspassword: (String) “**********”

   上のコマンドは FTP サイトの ID 1735 を新たな AD ユーザー パスワードの「myftppwd2111」でリセットします。

4. 次に、FTP サービスを停止するために「net stop msftpsvc」と入力します。

5. FTP サービスを再起動するために、「net start msftpsvc」と入力します。

6. コマンド プロンプトを終了します。

上のステップを行った後、AD のユーザー アカウントでFTP にログオンを試行してください。ユーザーがログオンされ、彼/彼女のフォルダへリダイレクトされるはずです。結論として、エラーは Active Directory から情報をえることができなかった FTP サービスです。私のシナリオでは AD のアカウント パスワードが変更された問題でした。同様に、ほかにも多くの潜在的な原因があります。例えば、削除/ロック アウトされたアカウントの構成、または FTP サービスがドメインのコントローラに接続できない、などです。この場合にセキュリティのログオンの監査を有効にすることは、この問題の原因を潜在的に狭めることになります。

すばらしい質問です! 私自身も、IIS 3.0 以降この問題の悪夢に悩まされ、苦労して解決しました。開発者は「サーバー構成でなければ、ハードウェアの問題です」と言うと思います。なぜでしょう? 彼らは常に、アプリケーションが問題の原因であると感じています、なぜなら開発者のサーバーでは問題なく実行されているからです。どのリクエストに最もリソース時間がかかるのかを突き止めるのは、難しいことではありません。困難な部分は、「スタック トレースで、みなさんのコンポーネントが CPU を消費している」というようなことを証明することです。もちろん、これには Web アプリケーションのデバッグおよび Windows 内部のアーキテクチャの理解に関する知識がいくらか必要になります。

とにかく、IIS5 または IIS 6 を使用していると仮定してください。Debug Diagnostic (英語情報) によりデバッグを行うためには、dllhost.exe または w3wp.exe のどちらがデバッガに添付されているかを確認することが必要です。そして、質問への回答ですが、最大のリソース時間を持つ URL またはリクエストをどうやって確認しますか? これは、簡単なことで、ツールがなくても行えます。まず、W3C の拡張されたログ ファイルの「Time-taken」の領域を有効にしてください。このフィールドは、特定のリクエストのプロセス時間をタイムスタンプします。その例は以下の通りです。

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken

2006-07-25 05:45:21 W3SVC1 127.0.0.1 GET /test.asp - 80 - 127.0.0.1 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) - - localhost 200 0 0 246 254 13310

上の例では、 test.asp へのリクエストは 13310 ミリ秒 (13 秒 ) 以上かかります。さて、みなさんの Web アプリケーションに大きな動的コンテンツが含まれていて非常に複雑なものである場合はどうでしょうか? 100 メガバイト (MB) 位のログをどのように解析するのでしょうか?

心配する必要はありません。私の以前の構成では、毎日 1 GB のログ ファイルを生成する Web サイトを所有していました。手動でそれを解析するには数日かかります。ここでは、自動のログ解析機が役に立ち、利用できる有償/無償のログ分析機が多くあります。そのほとんどが優れた分析および図を提供していますが、私はどれも気に入っていません (これらの報告を気に入っているのは、マーケティング部門の社員だけのようです)。私を含めたシステム管理者にとっては、重要なのは高速で、正確な小型のツールであり、どこにでも持ち運び可能であるということです。私は、自分が解釈する前に、分析機の報告が完了するのに 3 時間も待ちたくありません。要するに、マイクロソフトの Log Parser を使用したのです、そしてそれが大変気に入りました!

これは、みなさん達のような IIS の管理者のために魔法を起こす小さなツールです。このツールにまつわるすべての興味深い話をするつもりはありません、それはインターネットでご覧になれます。それでは、Log Parser を使用して、リソース時間が消費されるトップ 10 のリクエストをどのように確認するのでしょうか? それは簡単です。以下のクエリを実行します。

---Ch02Top10WebRequests.sql---

SELECT

TOP 10

STRCAT(EXTRACT_PATH(cs-uri-stem),'/') AS RequestPath,

EXTRACT_FILENAME(cs-uri-stem) AS RequestedFile,

COUNT(*) AS Hits,

MAX(time-taken) AS MaxTime,

AVG(time-taken) AS AvgTime,

AVG(sc-bytes) AS AvgBytesSent

FROM %source% TO %destination%

GROUP BY cs-uri-stem

ORDER BY MaxTime, TotalHits DESC

---Ch02Top10WebRequests.sql---

<厚かましい宣伝> 上記は Microsoft Log Parser book (英語情報 - 私も寄稿しました) の 2 章からの抜粋です。</厚かましい宣伝>

何をクエリするのでしょうか? みなさんが、標準の SQL クエリを理解していれば、極めて単純明快です。とにかく、スクリプトは特定の「ソース」からクエリを実行しながら トップ 10 の長さを探し、送信された平均バイト数と共に、URL およびファイル名のヒット数とリクエスト数、最大および平均時間を通知します。なかなか優れていると思いませんか? その実行方法は、以下の通りです。

C:\LogParser\Samples>Logparser.exe file:Ch02Top10WebRequests.sql?source=”<//localhost/w3svc/1>”+destination=”Top10WebRequests.txt” -o:NAT

このスクリプトはすべてのソースに対してクエリができるように、設計されました。例えば、Web サイトの ID 1 からのすべてのログ ファイルを解析し、みなさんのログ ファイル、別のログ ソースなどのフォルダに変更可能です。それからアウトプットを Top10Webrequest.txt file にリダイレクトします。アプトプットについては図 3.1. をご覧ください。

上の図から何がわかりますか? 簡単です – 平均プロセス時間が 40 秒から、最大 80 秒の「reg.asp」ファイルがあります! なんと! これは 1 分以上になります。この図から、スクリプトのコーディングの確認をして、ロジック、データベースのクエリなどを変更することにより、スクリプトを上手く調整しているかどうか確認できます。

この優れた Log Parser に関する詳細は、マイクロソフトから掲載された、この最新 blog (英語情報) をご覧になることを推奨します。そして本を入手することを忘れないでください。これは、ツールに関する唯一の本です。詳細については、www.logparser.com をご覧ください。

それでは、仕事に戻りましょう。さて、次は何でしょう! 「reg.asp」に問題がないと確認できたら? この「登録ページ」のすべてはとてもシンプルです。ユーザー入力をとらえ、DB コンポーネントによりデータ ベースにそれを更新します。上記のスクリプトが行うのは、長く実行されている Web リクエストを特定するだけで、プロセスのスレッドで実際に何が起こっているかを提供できません。より詳細な情報は、スクリプトに問題がないと確認した場合 (そしてスクリプト内をレビューして確認した場合)、アプリケーションのデバッグが必要な可能性があります。ですから、次に期待の星である「マイクロソフトのデバッグ 診断ツール」を紹介させてください! これは、デバッグのツールで、ワーカー プロセスを読み取り、プロセス スレッドおよびメモリ ダンプをとらえることにより、IIS のワーカー プロセス内で何が起こっているかを完全に確認することができます。

これで、質問に対する回答ができたと思います。そして、回答をはるかに超えた DebugDiag の詳細情報を提供できました。それでもなお、興味がある場合は、以前の IIS Insider の コラム でご覧になれます。DebugDiag に関する最新の サポート技術情報 (英語情報) と同様に IIS.Net の Webcast (英語情報) もご覧ください。そろそろ時間がきました。それでは、また!!