はじめまして。日本マイクロソフト、デベロッパーサポート DSI の平井です。入社以来、主に IIS、MSMQ、BizTalk Server などのサーバー系製品を担当してきました。
今日は、ワールドワイドでのお問い合わせが多く、かつインパクトの大きい現象についてお知らせしたいと思います。以下の条件にすべて合致する環境を運用されている方は、是非そのまま最後まで目を通してください。
上記条件をすべて満たした環境では、以下の技術文書に記載された問題が発生する可能性があります。
文書番号: 2545850タイトル: Users cannot access an IIS-hosted website after the computer password for the server is changed in Windows 7 or in Windows Server 2008 R2http://support.microsoft.com/kb/2545850/en-us*機械翻訳http://support.microsoft.com/kb/2545850/ja-jp
技術文書 2545850 の問題が発生すると、ブラウザーで該当の Web サイトにアクセスすると認証ダイアログが表示されるようになりますが、以下のような特徴があります。
もし、上記の条件に合致する環境や、上記の特徴の現象に遭遇したことがあれば、早急に以下の回避方法を検討してください。
IIS のマシンを再起動することで、一時的に本現象を回避することができます。しかし、再度この現象が発生する可能性があります。
技術文書 2545850 から、修正プログラムを入手し適用します。(マシンの再起動が必要です)
もし修正プログラムの適用がすぐにできない場合は、アプリケーションプールの実行アカウントを既定の ApplicationPoolIdentity から Network Service に変更することでも、本現象を恒久的に回避することができます。 この方法の場合、マシンや IIS の再起動を行わずに現象を回避することができます。ただし、アプリケーションプールのリサイクルが発生します。
なお、ApplicationPoolIdentity から Network Service に変更したことによる影響は、ApplicationPoolIdentityのアカウントに対して何か設定をしていない限り、低いものと考えられます。
この問題を意図的に発生させて、上記の回避方法の有効性を確認することができます。
＊検証環境で確認するようにしてください。
＊以下の技術文書に記載の ASP ファイルを実行することで、Kerberos 認証が行われたかどうか確認できます。ただし、この ASP ファイルを実行するためには IIS 役割サービスの [ASP] がインストールされている必要があります。
文書番号: 241835タイトル: [IIS]IIS 5.0 における認証方法の選び方http://support.microsoft.com/kb/241835/ja-jp
以下の手順で、マシンアカウントのパスワードが更新された日時を確認することができます。
＊IIS のマシンを WebServer01.contoso.local と仮定します。
それでは、またの機会に。
はじめまして。日本マイクロソフト、デベロッパー サポート DSI の澤田です。
今回は、お問い合わせの多い、IIS (WWW サービスと FTP サービス) のクラスタリング (フェールオーバークラスタリング) についてお知らせしたいと思います。これから Windows Server上で IIS のクラスター環境の構築をされる方、あるいは、既にクラスター環境で IIS を使用し、フェールーオーバーする障害が発生している方は、是非そのまま最後まで目を通してください。
Windows Server 2008 または Windows Server 2008 R2 上では IIS のクラスタリングがサポートされています。環境構築手順は以下の技術文書にあります。
文書番号: 970759タイトル: Microsoft Windows Server 2008 フェールオーバー クラスターで IIS 7.0 World Wide Web 発行サービスを構成するhttp://support.microsoft.com/kb/970759/ja-jp
文書番号: 974603タイトル: Windows Server 2008 フェールオーバー クラスターで FTP 7.5 を構成する方法http://support.microsoft.com/kb/974603/ja-jp
また、以下の修正プログラムの適用を強くお勧めします。
// Windows Server 2008 環境の場合文書番号: 2163398 タイトル: A memory leak occurs in the Rhs.exe process when you configure IIS 7.0 World Wide Web Publishing Service in a Windows Server 2008 failover clusterhttp://support.microsoft.com/kb/2163398/en-us
// Windows Server 2008 R2 SP1 環境の場合文書番号: 2618982 タイトル: FIX: Memory leak in Rhs.exe after you configure the IIS 7.5 W3SVC service in a Windows Server 2008 R2 SP1 failover clusterhttp://support.microsoft.com/kb/2618982/en-us
技術文書には、IIS をクラスタリングする際の環境構築手順として、大きく以下の 2 つの要素があります。
しかし、クラスターの仮想サーバー名を利用して IIS にアクセスするためには、実は、このどちらの設定も不要です。IIS 7.x および FTP 7.x 以後の IIS では、クラスター固有の機能は提供していません。つまり、クラスター環境で動作しているかどうかに IIS は関与しないのです。各要素の目的は以下の通りです。
クラスター環境を始めとする負荷分散をしている IIS は全てのノードを同じ構成にして利用することが推奨されます。IIS の構成情報は既定で %systemdrive%\system32\inetsrv\config フォルダ以下の applicationHost.config に保存されており、各ノードがローカルに構成情報を保持することになります。各ノードで構成情報を容易に統一する方法として、共有構成の機能があります。
これにより、IIS の構成情報である applicationHost.config は 1 つの共有フォルダ上で一元管理されるようになります。サーバー管理者は、どれか 1 台の Web サーバーまたは FTP サーバーで、インターネット インフォメーション サービス マネージャーや appcmd.exe を使用して IIS の構成を変更すると、全てのノードで自動的にその変更が反映されます。
IIS はクラスター環境で動作しているかどうかは関与しないため、それらにおいて障害が発生しても自動的に別のノードにフェール オーバーすることはありません。
IIS において障害が発生した時に、自動的に別のノードにフェール オーバーさせる機能は、クラスターの汎用スクリプト リソースによって実現しています。技術文書にあるサンプルのスクリプトでは、Web サイトやアプリケーション プールが開始状態にあるかどうか、また、FTP サービスが “RUNNING” の状態にあるかどうかをチェックしています。
このスクリプトをクラスターの汎用スクリプト リソースに登録することにより、クラスターの機能にて定期的に IsAlive/LooksAlive メソッドが呼ばれ、各メソッド内で実装している Web サイト、アプリケーション プール、または、FTP サービスの状態をチェックする処理が行われます。
技術文書にあるサンプル スクリプトを利用した場合、Web サイトやアプリケーション プールが開始状態にない、または、FTP サービスが “RUNNING” の状態にないと、「障害」が発生したと検知され、フェールオーバーします。
例えば、ワーカープロセスが短期間に異常終了を繰り返し、ラピッドフェール保護機能が働いてアプリケーション プールが停止した場合や CPU 監視機能を有効化しており、設定した期間内、ワーカープロセスがCPU を占有したために、CPU 監視機能が働いてアプリケーション プールが停止した場合などは、汎用スクリプト リソースに登録したスクリプトによって「障害」が検知されフェールオーバーします。このような場合は、一般的に、ラピッドフェール保護機能が働いたことや CPU 監視機能が働いたことがイベント ログから確認できます。
また、W3SVC サービスや FTPSVC サービスが停止した場合も、同様に、汎用スクリプト リソースに登録したスクリプトによって「障害」が検知されフェールオーバーします。
しかし、このような機能によりアプリケーション プールが停止したことや、あるいは、W3SVC サービス、 FTPSVC サービスが停止したことをイベント ログから確認することができず、代わりに、以下のようなエラーが記録され、その直後にフェールオーバーしている場合があります。また、フェールオーバーのタイミングで以下のようなエラーが記録され、フェールオーバーが繰り返される (フェールバックする) 場合もあります。
上記イベントは、共有構成を有効にしている IIS および FTP が共有フォルダ上にある構成情報 applicationHost.config を読み取れなかったことを意味します。これは、多くの場合、IIS の構成情報を配置している共有フォルダを、同じクラスター環境上にあるクラスター ディスクに作成している場合に発生します。以下に主な理由と対策を説明します。
共有フォルダがあるクラスター ディスクを保持するクラスター リソースがフェールオーバーするタイミングで、一時的に共有フォルダへのアクセスができない状態が発生します。この時、オフライン ファイルの機能を有効化していないと、Windows Process Activation サービス (以下 WAS) や FTP サービスは構成情報を読み取ることができず、サービスを開始することはできません。
対策: 共有構成を有効にする場合は、必ず、オフライン ファイルの機能を有効にする必要があります。
共有フォルダがあるクラスター ディスクのディスク リソースと WAS や FTP のサービスには依存関係はありません。例えば、全てのクラスター ノードの OS がシャットダウンしている状態で、ある単一のクラスター ノードの OS を起動することを想定します。この時、ディスク リソースのオンライン化より WAS や FTP のサービス開始の方が先に行われる可能性があり、このタイミングでは共有フォルダへのアクセスができません。
この場合、オフライン ファイルの機能を有効にしていても、共有フォルダ \\FileServer\ConfigShare のディスクはローカル ディスクであるため、オフライン ファイルが利用されることがありません。
対策: 構成情報を配置している共有フォルダを同じクラスター環境上のクラスター ディスクではなく、スタンドアロン サーバーや、別のクラスター環境上のクラスター ディスクに配置します。これにより、WAS や FTP サービスが構成情報を読み取るタイミングで、確実に共有フォルダへのアクセスができる、または、アクセスできなくてもオフライン ファイルが利用できるようになります。構成情報を配置している共有フォルダを同じクラスター環境上のクラスター ディスクに配置する場合は、クラスター ディスクのディスク リソースがオンラインになってから、WAS や FTP のサービスを再起動します。
Windows Server 2012 上で IIS 8.0 および FTP 8.0 のクラスタリング構成はサポートされます。*ただし、Microsoft では高可用性を目的とした Web サーバー、FTP サーバー環境は Microsoft Failover Cluster (MSFC) を利用するのではなく、Network Load Balancing (NLB) を利用することを推奨しています。
Windows Server 2012 上で IIS をクラスタリング構成する手順は上述の技術文書から以下の 2 点が変更されています。
オフライン ファイルを利用するためには、デスクトップ エクスペリエンスをインストールする必要があります。Windows Server 2012 ではサーバー マネージャーの [機能] - [ユーザー インターフェイスとインフラストラクチャー] を展開すると、デスクトップ エクスペリエンスがあります。
Windows Server 2012 ではオフライン ファイルと同期センターが統合されています。デスクトップ エクスペリエンスをインストール後、コントロール パネルからオフライン ファイルを有効化するためには、同期センターを開き、左ペインのオフライン ファイルの管理リンクをクリックします。
Windows Server で IIS をクラスタリング構成する際は、技術文書のサンプルのような Web サイト、アプリケーション プール、FTP サービスの状態を監視するスクリプト (clusweb7.vbs や clusftp7.vbs) を汎用スクリプト リソースとして追加します。*汎用サービスと間違い易いので注意してください。汎用サービスに W3SVC サービスや FTP サービスを登録することはサポートされていません。
Windows Server 2012 ではフェールオーバー クラスター マネージャーのユーザー インターフェイスが変更されています。汎用スクリプト リソースを追加する時は、フェールオーバー クラスター マネージャーを起動し、[ロール] を右クリックして、[ロールの構成] メニューを選択します。
こんにちは。日本マイクロソフト、デベロッパー サポート DSI の澤田です。
Windows Server 2003/IIS 6.0 まで Web アプリケーション経由でユーザーのパスワードの有効期限切れ事前通知機能、および、パスワード変更機能として IISADMPWD を提供していました。しかし、IISADMPWD は Windows Server 2008/IIS 7.0 以降のバージョンの IIS ではインストールされません。今回は Windows Server 2008/IIS 7.0 以降のバージョンのIIS における Web アプリケーション経由でユーザーのパスワードの有効期限切れ事前通知、パスワード変更確認機能、および、パスワード変更機能に関する情報を紹介します。
Windows Server 2008/IIS 7.0 以後のバージョンの IIS では、IISADMPWD はサポートしておらず、動作しません。
IISADMPWD には、IIS 6.0 のメタベースに登録された PasswordExpirePreNotifyDaysプロパティ、PasswordChangeFlagsプロパティなどの値に基づいて動作する以下の主要な 3 つの機能があります。
Windows Server 2003/IIS 6.0 までの IIS には、IIS 自体に 1. および 2. の機能が動作するような実装が組み込まれています。具体的には、Windows Server 2003/IIS 6.0 までの IIS には、1. および 2. の機能に必要な PasswordExpirePreNotifyDays プロパティや PasswordChangeFlags プロパティ、これらの機能に基づいて表示する ASP ページを指定するための AuthNotifyPwdExpURL プロパティなどが実装されています。しかし、Windows Server 2008/IIS 7.0以降のバージョンの IIS には、このような機能の実装自体がありません。
このため、たとえ、Windows Server 2003/IIS 6.0 のIISADMPWD を Windows Server 2008/IIS 7.0 以後の IIS にコピーし、IISADMPWD に含まれる iispwchg.dll をレジストリ登録し、更に、IISADMPWDに必要なメタベース プロパティ値を登録したとしても、Windows Server 2008/IIS 7.0 以後の IIS で 1. や 2. の機能を実現することはできません。メタベースプロパティの設定自体はエラーとはなりませんが、Windows Server 2008/IIS 7.0 以降のバージョンの IIS にはそれらの設定値をハンドルする実装がありません。マイクロソフトでは、Windows Server 2008/IIS 7.0以降のバージョンの IIS において IISADMPWD はサポートしていないのみならず、IISADMPWD の上述のような機能は提供していません。
IISADMPWD の利点は、ユーザーが IISADMPWD のページに直接アクセスすることなく、つまり、IIS 上で動作する基本認証や統合 Windows 認証を要求する Web アプリケーションにアクセスしたタイミングで、1. や 2. の機能によって自動的にパスワード変更画面にリダイレクトされることです。このような IISADMPWD の機能を Windows Server 2008/IIS 7.0 以後の IIS で実現するためには、ユーザーの認証 “後”、かつ、ユーザーがアクセスした Web アプリケーションの実行 “前” に機能���るような ISAPI フィルタや HTTP モジュールの開発が必要です。
これについて、マイクロソフトが提供している既存のサンプル等はありませんが、以下のような HTTP モジュールのサンプルが CodePlex から提供されていますので参考にしてみてください。
IISADMPWD ASP.NET HTTP Modulehttp://iisadmpwdhttpmodule.codeplex.com/
また、IISADMPWD の 3 つ目の機能であるパスワード変更機能は、iispwchg.dll 内で NetUserChangePassword API にて実現しています。「Web 経由でパスワード変更をする方法」、すなわち、IISADMPWD の 3. の機能だけを利用したいという場合には、IADsUser::ChangePassword メソッドを使うことで容易に実現できます。サポートを提供していない IISADMPWD を利用する代わりに、以下のように IADsUser::ChangePassword メソッドを使ってパスワード変更する Classic ASP の独自実装をご検討ください。以下は、IADsUser::ChangePassword メソッドを使用し、ユーザーのパスワードを変更する Classic ASP のサンプル コードです。パスワードの変更は domain\testuser アカウントで実行し、パスワードの変更対象のユーザーは LDAP の CN に指定している User1 です。
<%@ LANGUAGE="VBSCRIPT" %><% Dim objDSO,objUser, strUser, strPwd 'Password 変更の実行権限を持つユーザー strUser = "domain\testuser " strPass = "testuserpassowd" 'Password 変更対象者の古いパスワード、新しいパスワード oldPass = "oldpassword" newPass = "newpassword" Set objDSO = GetObject("LDAP:") Set objUser = objDSO.OpenDSObject(LDAP://test.contoso.com/CN=User1,OU=UserAccounts,DC=test,DC=contoso,DC=com, strUser, strPass, 1) If err.number <> 0 Then Response.Write "GetObject is failed: " & err.number & "</BR>" End If objUser.ChangePassword oldPass, newPass If err.number <> 0 Then Response.Write "ChangePassword is failed: " & err.number & "</BR>" Else Response.Write "Password has changed successfully." End If%><html><title>PASSWORD CHANGE SAMPLE</title></html>
CodePlex のサンプル、および、passchange.asp はマイクロソフトでサポートを提供するものではありませんが、IISADMPWD の代替ソリューションを検討する上での参考情報としていただけると幸いです。
※ 本件は、Visual Studio サポート チームのブログの転載となります。2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。
KB3002339 https://support.microsoft.com/kb/3002339/
本問題の報告を受け、Windows Update の配信は既に停止いたしましたが、Windows Server Update Services (WSUS) を使用して更新プログラムを配信されているお客様におかれましては、本更新プログラムの配信を停止していただけますようお願い申し上げます。
既に本更新プログラムを適用し、ハングアップなどの現象が発生している環境での復旧方法につきましては、現在調査中です。進展があり次第、Visual Studio チーム記事にて情報公開させていただきます。最新の内容は下記 Visual Studio チームブログをご覧ください。
Visual Studio サポートチームブログ[ご注意ください] 12 月 10 日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生するhttp://blogs.msdn.com/b/jpvsblog/archive/2014/12/10/12-10-windows-update-visual-studio-2012-kb3002339.aspx
お客様には多大なご迷惑をおかけしておりますこと、深くお詫び申し上げます。
こんにちは。日本マイクロソフト、CSS デベロッパー ツールズ DSI の牧です。
Windows 2000 時代の IIS 5.0 は inetinfo.exe というプロセスが一つでほぼすべてを取り仕切っていました。Windows Server 2003 の IIS 6.0 では HTTP 通信部分が http.sys、アプリケーションワーカープロセスは w3wp.exe と役割分担がされました。これによってパフォーマンスやセキュリティが向上しましたが、他方、問題が発生した際にいったいどの部分でエラーとなっているかが、分かりにくくなっている事は否めません。
本トピックでは、IIS 7.5（Windows Server 2008 R2）以降、IIS を構成するコンポーネントを説明し、それらコンポーネントがどの様に処理を行うかを解説したうえで、本題の IIS が行うエラー制御処理についてどこでエラーが起きたらどのように観測されるのか、といった点を簡単に解説します。
まず、IIS のコアコンポーネントをご紹介したいと思います。
それでは、クライアントからの要求がどのようにコンポーネントを通って処理され、応答が返るのかを簡単に説明します。
このように多くのコンポーネントがリクエスト処理に関わるため、リクエストに問題がある場合、その各所でエラーが生じる可能性があります。
特に注意する必要がある箇所としては、各コンポーネントが行うエラー制御処理は独立しており、相互に干渉することが出来ないという点にあります。結果、例えば http.sys がクライアントへ応答するエラーはカスタマイズできないといった動作上の制限が生じます。
以下に、不正なリクエストがどのコンポーネントで弾かれる可能性があるか、またその場合、エラーがどのように見えるかを記載しました。
RFC に反するような HTTP リクエストの多くは、http.sys で弾かれます。
例えば、ヘッダーに不正な文字列が設定されていたり、ヘッダーとして不正な場合、RFC 3987（私用領域の文字を使用している）等に違反するリクエストの場合などには、HTTP の要求を最初に受け付ける http.sys によって 400 Bad Request が返されます。この事は http.sys のエラーログにも記録されます。
HTTP API でのエラー ログhttp://support.microsoft.com/kb/820729/ja
なお、この場合、http.sys でリクエストを弾いているため、該当の要求は IIS や IIS 上で動作するアプリケーションまで到達しません。また、http.sys 側で HTTP エラー 400 に対して任意のエラー ページを返すような設定は用意されていないため、http.sys が返すエラー (HTTP エラー 400 / 503 等) が発生した際に、カスタムのエラーページを表示する方法はありません。
Configuring HTTP Error Responses in IIS 7http://technet.microsoft.com/en-us/library/cc731570(v=WS.10).aspx
IIS には、以前 URLScan というアドオンで提供されていた要求をフィルタリングする機能が、requestFiltering として製品に組み込まれました。
要求のフィルタリング <requestFiltering>http://technet.microsoft.com/ja-jp/library/ee431637.aspx
例えば、requestLimits 要素には、要求データ長を制限する maxAllowedContentLength 属性、要求クエリ長を制限する maxQueryString 属性、要求 URL 長を制限する maxUr属性があり、denyUrlSequences 要素では URL 中の特定文字列を拒否できます。
要求制限 <requestLimits>http://technet.microsoft.com/ja-jp/library/ee431638.aspx
URL シーケンスの拒否 <denyUrlSequences>http://technet.microsoft.com/ja-jp/library/ee431583.aspx
これら IIS の要求制限については httpErros 要素によってエラーページが表示されます。なお、existingResponse 属性によって後述の ASP.NET によるエラーの動作に影響が生じる場合があります。
HTTP エラー <httpErrors>http://technet.microsoft.com/ja-jp/library/ee431601.aspx
ASP.NET には要求検証機能があります。特に代表的なものとして、スクリプトのインジェクションとみなされるリクエストにはエラーが表示されます。
How To: ASP.NET でインジェクション攻撃から保護する方法http://msdn.microsoft.com/ja-jp/library/ff647397.aspx
スクリプトによる攻略の概要http://msdn.microsoft.com/ja-jp/library/w1sw53ds(v=vs.110).aspx
ASP.NET の検証機能は httpRuntime 要素にて設定可能です。例えば、要求データ長を制限する maxRequestLength 属性、要求 URL 長を制限する maxUrlLength 属性、要求ファイル名検証に関わる relaxedUrlToFileSystemMapping 属性、さらに前述の XSS 検証に関わる requestValidationMode 属性、requestValidationType 属性、requestPathInvalidCharacters 属性などがあります。
httpRuntime 要素 (ASP.NET 設定スキーマ)http://msdn.microsoft.com/ja-jp/library/e1f13641(v=vs.110).aspx
ASP.NET のこれらの検証機能によってエラーとなった場合、基本的にはカスタムエラー設定に従った動作をします（問題によっては強制的に接続を切断する場合もあります）。しかし、customErrors 要素の redirectMode 属性が redirect であり、かつリダイレクト先のエラーページを表示する事にも支障がある場合、ランタイムエラーとなる場合があります。
customErrors 要素 (ASP.NET 設定スキーマ)http://msdn.microsoft.com/ja-jp/library/vstudio/h0hfz6fc(v=vs.100).aspx
また、ASP.NET で構築されている部分、例えばASP.NET のモジュール（ビルトインの ASP.NET FileAuthorizationModule や URL 解釈機能を含みます）やハンドラで、リクエスト処理に支障があった場合も ASP.NET のカスタムエラーが動作します。エラーコードは発生する問題によって異なる場合があります。
FileAuthorizationModule クラスhttp://msdn.microsoft.com/ja-jp/library/System.Web.Security.FileAuthorizationModule(v=vs.110).aspx
上記のようにやや複雑の構成となっていますが、該当のリクエストがどのコンポーネントで拒否されたかを知る事で、適切な対処が選択できます。
そのことを知るためには、IIS 7.0 以降に搭載された「失敗した要求トレース」が非常に有用です。以下にその設定方法と使い方に関するドキュメントがあります。
失敗した要求トレース <traceFailedRequests>http://technet.microsoft.com/ja-jp/library/ee431657.aspx
失敗した要求トレースを使用して Classic ASP エラーをトラブルシューティングするhttp://technet.microsoft.com/ja-jp/library/ee155452.aspx
エラーはどこで起きたのか、という点に注目してトレースを見て頂くと、それに応じて、どのコンポーネントの検証機能によってエラーとなったのか、が分かるかと思います。