みなさんごきげんよう。ういこです。すっかりご無沙汰しております。
過日より、”ILM 一家” のエンジニアはIdM 製品担当ではなく、それぞれが、別の製品の担当になりました。今までの担当のうち、ADSI / WMI / PowerShell は今でも「おとうさん」が担当していますが、そもそも IdM 製品の担当として始めたブログであることなどから、関係各位とも検討した末、本ブログは凍結することとなりました。それに伴い、ブログにあったメールアドレスの連絡先はオフにさせていただきました。 今でも本ブログはそれなりにページビューがあって、ご覧いただいている方もいらっしゃるのだと認識しています。
いろいろ考えた末、このような結論になったことは私としても残念ですが、どうか、今後とも弊社製品とサポートをご愛顧いただければこれほどうれしいことはありません。
このブログを始めたのは、IdM 製品がまだまだマイナーな時期であったこと、何とかして使っていただけるようにと思ったこと、そして私たち「顔が見えない」と言われるマイクロソフトのサポートの「中の人」も、普通のひとなんだよ、ということを知ってほしいな、と思ったからでした。結果、いろいろなところに読んでいただいて、さまざまな方とお知り合いになれました。このプロジェクトを通じて得られたものはとても素晴らしいものでした。それだけに、個人的には非常に残念です。 ブログは、さげてしまおうかとも思いましたが、公開を続けることにしました。もう、記事を書くことは 99.99999% ありませんが、何かのお役に少しでも、たっていたらいいなと思っています。
皆さん、ありがとうございました。 これでもう本当におしまいです。最後なので、デザインをちょっと変えてみました。見やすくなっていれば良いのですけどね。 エンジニアは社内におりますので、別の製品でお会いすることもあるかと思いますが、今後ともよろしくおねがいします。
…ちなみに、私は今、ある製品のチームのブログでちょこっとずつ書いています。
それでは、みなさんごきげんよう。 皆様の前途にたくさんの幸あらんことを。
～ ういこう@ありがとうございました！ ～
皆様、こんにちは。2 月から新たに FIM/ADSI サポートチームに加わりました shfujita です。
いままで、ADSI、FIM には携わった経験はなく修行中の身ではございますが、一日も早く皆様の抱えておられる問題をどんどん解決できるようになるために頑張りますのでどうぞよろしくお願いいたします！！
さて、今回のテーマは「FIM パスワードリセットを行おうとすると何も操作できなくなる !?」についてお話したいと思います。
環境は下記の通りです。今一度ご確認くださいませ。
今回は既に Forefront Identity Manager 2010 を運用されていることを想定したシナリオでお送りいたしますのであしからず！！
【FIM Server】
OS :
Windows Server 2008 R2 Enterprise Edition もしくは Standard Edition
導入ソフトウェア :
Forefront Identity Manager 2010
SQL Server 2008 SP1 Enterprise Edition もしくは Standard Edition
Windows SharePoint Services 3.0 SP2
【FIM Client】
Windows 7 Professionalもしくは Ultimate (32bit 版もしくは 64bit 版)
FIM 2010 Client, Add-ins and Extensions (32bit 版もしくは 64bit 版)
Office Outlook 2007 SP2
まずは現象についてご案内いたします。
FIM Server 側の Forefront Identity Manager 2010 で秘密の質問を定義した後、FIM Client 側で秘密の回答を登録します。 続けて、FIM Server 側の Forefront Identity Manager 2010 で秘密の質問数を増やし、FIM Client 側の PC のログオン画面を表示し、[パスワードのリセット] を実行しようとすると何も操作できない状態になります。この状態になると、電源を落とすしか対処法がございません。
下記の画面が表示されたままとなります。
なぜ、このような現象が発生するのでしょうか？まずは現象再現確認してみましょう・・・
1. FIM Server 側の Forefront Identity Manager 2010 を起動いたします。[管理] – [ワークフロー] を開いてください。[Password Reset AuthN Workflow] を選択し、[アクティビティ]タブ – [QA ゲート] を展開していただき、[このゲートの質問の合計数] に “3” と設定されていることを確認します。(今回は例として 3 つ設定されているとします。)
2. [全般]タブ - [登録設定] の “再登録が必要” のチェックボックスにチェックが入っていない状態にします。
3. 次に FIM Client 側で秘密の回答を登録いたします。ここでは 3 つの質問に対する回答を登録することになります。
4. 再度、 FIM Server 側の Forefront Identity Manager 2010 を起動し、[管理] – [ワークフロー] を開いてください。[Password Reset AuthN Workflow] を選択し、開いてください。[アクティビティ]タブ – [QA ゲート] を展開し、[このゲートの質問の合計数] を “5” に変更してください。(必要な回答数を増やしていただければ 5 でなくてもかまいません。)
この状態でFIM Client 側のログオン画面を表示し、[パスワードのリセット] をクリックします。すると・・・・・
何も操作できない状態になってしまします。リプロしました！！
では、どのように設定すればこの現象を回避することができるのでしょうか？
その方法をこれからご説明いたします。
上記の 2. のタイミングで [全般]タブ - [登録設定] の “再登録が必要” のチェックボックスにチェックをいれてください。
その後、FIM Server 側で必要な回答数を増やした後、FIM Client 側の PC にログオンしていただき秘密の回答を再登録してください。
一旦ログアウトしていただき、FIM Client 側のログオン画面を表示し、[パスワードのリセット] をクリックしていただきますとパスワード リセットすることができます！！
パスワード リセットは FIM Server 側の質問数と FIM Client 側で登録した質問に対する回答数が一致している場合のみ行うことができるのです！！
注) 英語版 Windows 7 Professionalもしくは Ultimate (32bit 版もしくは 64bit 版) をご利用していただいた場合も日本語版をご利用いただいた場合と同様の結果が得られます。
いかがでしたか？
Forefront Identity Manager 2010 をご利用いただいている皆様、これから導入をお考えの皆様、FIM Client 側からパスワード リセットしようとして何も操作できない状態になった場合はこの辺りを今一度ご確認いただければと思います。
大変ご無沙汰しております。 現在、家族募集中の パパ（わたなべ）でございます。
本、Blog をご愛顧いただき、誠にありがとうございます。おかげさまで、本 Blog は4年目を迎えることができました。
ひとえに皆様方のご声援の賜物と、日々感謝しております。深く御礼申し上げます。
心機一転、サポート関連情報、製品情報など、情報提供の場としてまいりますので。
今後ともよろしくお願いいたします.
平素より弊社サポート サービスをご愛顧くださいましてありがとうございます。本日は 7 月の弊社指定休業日のお知らせです。 7/5 終日と、12 日の午後、そして海の日の 18 日（祝日）は休業となります。 お急ぎの皆様にはご迷惑をお掛けし恐縮でございますが、何卒ご理解の程お願い申し上げます。
お問い合わせ窓口休業のお知らせ http://support.microsoft.com/gp/holiday/ja
[指定休業日] 2011 年 07 月 05 日 (火) 終日 2011 年 07 月 12 日 (火) 午後 2011 年 07 月 18 日 (月) 海の日
[対象のサービス] プレミア サポート サービス プロフェッショナル サポート サービス (※) 上記期間内もプレミアサポート、プロフェッショナルサポートの緊急案件 (Severity A) につきましては対応させていただきます。
(ILM/FIM/WMI/PowerShell/ADSI Support Team – Jul 01, 2011)
今日は、私事ですがひとつご報告させていただきます。 本日 7 月 1 日より、ILM / WMI / ADSI とか色々担当チームというかユニットから、SQL Server サポートチームに新たなチャレンジをする運びになりました。 これまで、私が担当させていただいたお客様、当ブログをご覧いただいていらした皆様、本当にお世話になりました。
思えば、2008 年、Windows Media / DirectX サポートからいきなりまったく触ったことがなかった ADSI、ILM の世界に飛び込んだときはさっぱりとっかかりもなく、こりゃまずい…私首になっちゃうわよとどきどきしたのを今でも鮮やかに思い出します。ところがそこに、ぴろとくんや、おとうさんという卓越した才能を持つ人材がそろって、ここまでくることが出来たとしみじみ思っています。そして何より、サポートをご利用いただいていらっしゃる皆様の声が、私たちにとってどれだけ励みになるか。あの長々としたアンケートに答えてくださっただけでもありがたいのに、おかげさまで本当によい評価をいただくことが出来、まただめな対応の際は、建設的なフィードバックをチームで何度も検討し、方針を修正するなどして進めてきました。本当に、ありがとうございます。
今後は、ILM (など) の担当は、ぴろとくんとおとうさんの二人になります。 このブログはどうするのかと多数お尋ねをいただいていますが、基本ぴろとくんか、お父さんが担当になりますので、消されたりはしません。私も、少し書くと約束したコンテンツがまだあるので、しばらく私も書き込むことになります。それが終わったら、私は次のチャレンジに完全に移行することになるのだと思います。なので、今しばらくお付き合いいただければ幸いです。なお、次のチームもブログは持っていますが、今のところ私が書くというような予定はありません。
今日は、久々に技術的な話がまったくないつまらない、完全に私事の記事で恐縮です。このまま書かないでおくことも考えました。ですが、小さなプロダクトの割りに、たくさんのページビューもおかげさまでいただくなど、私たちにとって、とても励みにさせていただいた皆様に一言お礼を申し上げたく、書かせていただきました。 つたない文章を面白いといってくださった方、Tech Fielders の集いで実際に face to face でお会いできた方、かけがえのない大切な、大切な思い出です！ ぴろとくんとお父さんの今後の ILM プロジェクトを、皆さんどうぞ今後ともよろしくお願いいたします。
皆様のますますのご清栄を心より願っております。 ありがとうございました。
Appendix / サイトの PageView
コメント : アクセス解析を導入したのは2009年でした。教えてくださった安納さんありがとうございます。
コメント : やっぱりいっぱい書いてた月は強いです。
コメント : 今年です。やっぱりきっちり書いていないと、伸びもちょっとイマイチですね。
ページビューランキング (URL 別)
うちのブログは内外で、何も考えずに書いてるとよく言われていましたが、実は解析して傾向を決めていました。
2009 年
このころは、5000 件アカウント列挙が人気です。windbg も人気。
2010 年
このあたりから、イベントログ、WinRM、WMI の参照傾向が強まってきたため、winRM の記事などを増量する方向にしました。後は何気に windbg もまだ人気です。
2011 年 (7 月 1 日現在)
ページランキング。何気に、最近はwinrm/wmi系が強いですが、Windbg も根強いです。
検索ワードランキング
2011 年
以上となります。どうぞよろしくお願いいたします。
ILM / ADSI / WMI Prog / PowerShell Support Team 横井 羽衣子 (よこい ういこ)
皆さんごきげんよう。ういこです。最近 PowerShell の案件も微妙に増えております。SEO 対策をあざとく狙い、今回も逝ってみましょう PowerShell! 今日のお題は、「Active Directory 系コマンドレットは 30 分でタイムアップすることがある」です。
さて、「夏を待てない」と歌ったのは國生さゆりさん (おニャン子クラブ会員番号は 8 番) ですが、コマンドレット君も��あみんのようにいつまでも待てないことがあるのです。 Active Directory といっても、運用形態は様々。オブジェクト数も数個から数万ということもありえます。たとえば数万のオブジェクトを動かしたり、取得したりするとき、いつまでも時間がかかるような事態はパフォーマンスの観点など、まあ色々よろしくありません。というわけで、既定では get-ad 系コマンドレットは、検索クエリのオープン時間に対し、30 分の制限値を持ちます。この制限値は Active Directory Web サービスの Config ファイルのパラメーターで設定されています。
なかなかいやらしいことに、30 分以上経過したときの PowerShell コンソール上に出てくる例外、エラーの発生パターンは一定ではありません。ADException が返る場合も、構文が無効とか、SocketException が出るときとかもございます。ただ、例外の出方に惑わされてはいけません。この問題のポイントは、「30 分以内に終われば何事もない、ところが 30 分を少しでも過ぎると何か、異常終了しちゃう」というところです。これが満たされている場合は、今回ご紹介する問題に合致する可能性がかなり高いです。
・これまで確認されている PowerShell 上のエラーメッセージの出方（これ以外にもあるかもしれません）
サーバーから、無効な列挙コンテキストのエラーが返されまし。,Microsoft.ActiveDirectory.Management.Commands.GetADComputer Category : NotSpecified Activity : Get-ADComputer Reason : ADException TargetName : TargetType :
(2) RuntimeException Number of exceptions of this type: 1 Exception type: System.Management.Automation.RuntimeException Message: null 値の式ではメソッド InnerException: <none> StackTrace (generated): SP IP Function 000000001EC2DAC0 000007FEE9C5FE25 System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(System.Object, System.Collections.Hashtable, Boolean) 000000001EC2DB90 000007FEE9C69D96 System.Management.Automation.PipelineNode.Execute(System.Array, System.Management.Automation.Internal.Pipe, System.Collections.ArrayList ByRef, System.Management.Automation.ExecutionContext) 000000001EC2DC50 000007FEE9C69A0F System.Management.Automation.StatementListNode.ExecuteStatement(System.Management.Automation.ParseTreeNode, System.Array, System.Management.Automation.Internal.Pipe, System.Collections.ArrayList ByRef, System.Management.Automation.ExecutionContext)
・ ちょっとダンプでも見てみましょうか 気が向いたら、おダンプでも一発取ってみてみると楽しいかもしれません。Windows Server 2008 R2 だからタスク マネージャ上で指先一つでダンプさ！ができるんです。ああ便利。 Powershell コンソール上で実行し、エラーが出ている状態で、PowerShell.exe に対してダンプを取ります。これで OK です。
ダンプを採ったら、Windbg で開いてみましょう。psscor2.dll でもダウンロードしていただき、!dae コマンドを実行すると、ほらこんなに例外が。ただし、ロードとかするのにコストがかかる StackOverflowException とか、OutOfMemoryException はあらかじめロードされており、これが !dae で見えるからと言って、必ずしも発生しているわけではありません。あっ OOM 出てる！と思う前に、そういう処理かどうかを状況から見極めて判断してください。
- PSSCOR2 の入手先 Psscor2 Managed-Code Debugging Extension for WinDbg http://www.microsoft.com/download/en/details.aspx?displayLang=en&id=1073 - PSSCOR2 で使えるコマンドを紹介してくださってる Jin さんのブログです。 psscor2 http://blogs.msdn.com/b/jink/archive/2010/04/01/psscor2.aspx
- PSSCOR2 の入手先 Psscor2 Managed-Code Debugging Extension for WinDbg http://www.microsoft.com/download/en/details.aspx?displayLang=en&id=1073
- PSSCOR2 で使えるコマンドを紹介してくださってる Jin さんのブログです。 psscor2 http://blogs.msdn.com/b/jink/archive/2010/04/01/psscor2.aspx
Windbg のセットアップ、簡単な使い方は以下で紹介させていただいています。ご参考になれば幸いです。
[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(1) http://blogs.technet.com/jpilmblg/archive/2009/02/21/debugging-windbg-1.aspx [Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(2) Ver 1.1 http://blogs.technet.com/jpilmblg/archive/2009/02/25/debugging-windbg-2.aspx [Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(3) http://blogs.technet.com/jpilmblg/archive/2009/03/06/debugging-windbg-3-tips.aspx
[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(1) http://blogs.technet.com/jpilmblg/archive/2009/02/21/debugging-windbg-1.aspx
[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(2) Ver 1.1 http://blogs.technet.com/jpilmblg/archive/2009/02/25/debugging-windbg-2.aspx
[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(3) http://blogs.technet.com/jpilmblg/archive/2009/03/06/debugging-windbg-3-tips.aspx
・スタック上に残っている例外のパターンのサンプル ダンプを取って例外を見てみると、「タイムアウトで切りました」「リモート ホストが応答しませんでした」というメッセージが見られます。PowerShell コンソール上でも、これらの例外が通知される場合もあります。
例
Number of exceptions of this type: 1 Exception MethodTable: 000007fee6d7fd58 Exception object: 0000000003538348 Exception type: System.ServiceModel.CommunicationException Message: ソケット接続が中止されました。これは、メッセージ処理時のエラー、リモート ホストでの受信タイムアウトの超過、または基になるネットワーク リソースの問題が原因で発生する可能性があります。ローカル ソケットのタイムアウトは '00:01:00' でした。 InnerException: System.Net.Sockets.SocketException, use !PrintException 00000000035061a0 to see more StackTrace (generated): SP IP Function 000000001C1EC690 000007FEE7A4B60C System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[], Int32, Int32, System.TimeSpan, Boolean) 000000001C1EE770 000007FEE6B43D75 System.ServiceModel.Channels.SocketConnection.Close(System.TimeSpan) 000000001C1EE840 000007FEE6B46969 System.ServiceModel.Channels.BufferedConnection.Close(System.TimeSpan) 000000001C1EE8A0 000007FEE6B44DBE System.ServiceModel.Channels.ConnectionPool.CloseItem(System.ServiceModel.Channels.IConnection, System.TimeSpan) 000000001C1EE8D0 000007FEE73A93BF System.ServiceModel.Channels.CommunicationPool`2+EndpointConnectionPool[[System.__Canon, mscorlib],[System.__Canon, mscorlib]].CloseItem(System.__Canon, System.TimeSpan) 000000001C1EE900 000007FEE6C126DE System.ServiceModel.Channels.IdlingCommunicationPool`2+IdleTimeoutEndpointConnectionPool[[System.__Canon, mscorlib],[System.__Canon, mscorlib]].CloseItem(System.__Canon, System.TimeSpan) 000000001C1EE940 000007FEE73A9562 System.ServiceModel.Channels.CommunicationPool`2+EndpointConnectionPool[[System.__Canon, mscorlib],[System.__Canon, mscorlib]].CloseIdleConnection(System.__Canon, System.TimeSpan)
StackTraceString: <none> HResult: 80131501
Number of exceptions of this type: 1 Exception MethodTable: 000007fee7f9b090 Exception object: 00000000033f3ad8 Exception type: Microsoft.ActiveDirectory.Management.ADException Message: サーバーから、無効な列挙コンテキストのエラーが返されました。 InnerException: System.ServiceModel.FaultException, use !PrintException 00000000033f2590 to see more StackTrace (generated): SP IP Function 000000001EC2C7C0 000007FEE8012473 Microsoft.ActiveDirectory.Management.AdwsConnection.ThrowException(Microsoft.ActiveDirectory.Management.Faults.AdwsFault, System.ServiceModel.FaultException) 000000001EC2C810 000007FEE7E9C8F9 Microsoft.ActiveDirectory.Management.AdwsConnection.Search(Microsoft.ActiveDirectory.Management.ADSearchRequest) 000000001EC2C9A0 000007FEE7E9572B Microsoft.ActiveDirectory.Management.ADWebServiceStoreAccess.Microsoft.ActiveDirectory.Management.IADSyncOperations.Search(Microsoft.ActiveDirectory.Management.ADSessionHandle, Microsoft.ActiveDirectory.Management.ADSearchRequest) 000000001EC2C9E0 000007FEE7EA39DE Microsoft.ActiveDirectory.Management.ADObjectSearcher.PagedSearch(System.Object ByRef, Boolean ByRef, Int32, Int32) 000000001EC2CAC0 000007FEE7EB6917 Microsoft.ActiveDirectory.Management.ADObjectSearchResultEnumerator.System.Collections.IEnumerator.MoveNext() 000000001EC2CB20 000007FEE7ECA9EF Microsoft.ActiveDirectory.Management.Commands.ADFactory`1+<GetExtendedObjectFromFilter>d__0[[System.__Canon, mscorlib]].MoveNext() 000000001EC2CBA0 000007FEE7EF5D03 Microsoft.ActiveDirectory.Management.Commands.ADGetCmdletBase`3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].OutputSearchResults(Microsoft.ActiveDirectory.Management.IADOPathNode) 000000001EC2CC60 000007FEE7EF650F Microsoft.ActiveDirectory.Management.Commands.ADGetCmdletBase`3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].BeginProcessingOverride() 000000001EC2CCF0 000007FEE7EF3D41 Microsoft.ActiveDirectory.Management.Commands.ADCmdletBase.BeginProcessing()
StackTraceString: <none> HResult: 80131500
Number of exceptions of this type: 1 Exception MethodTable: 000007fee9d1e810 Exception object: 00000000033f3f50 Exception type: System.Management.Automation.CmdletInvocationException Message: サーバーから、無効な列挙コンテキストのエラーが返されました。 InnerException: Microsoft.ActiveDirectory.Management.ADException, use !PrintException 00000000033f3ad8 to see more StackTrace (generated): SP IP Function 000000001EC2D350 000007FEE9C5FE25 System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(System.Object, System.Collections.Hashtable, Boolean) 000000001EC2D420 000007FEE9C69D96 System.Management.Automation.PipelineNode.Execute(System.Array, System.Management.Automation.Internal.Pipe, System.Collections.ArrayList ByRef, System.Management.Automation.ExecutionContext) 000000001EC2D4E0 000007FEE9C69747 System.Management.Automation.ParseTreeNode.Execute(System.Array, System.Management.Automation.Internal.Pipe, System.Management.Automation.ExecutionContext) 000000001EC2D530 000007FEEA3A824A System.Management.Automation.AssignmentStatementNode.Execute(System.Array, System.Management.Automation.Internal.Pipe, System.Management.Automation.ExecutionContext) 000000001EC2D620 000007FEE9C699F2 System.Management.Automation.StatementListNode.ExecuteStatement(System.Management.Automation.ParseTreeNode, System.Array, System.Management.Automation.Internal.Pipe, System.Collections.ArrayList ByRef, System.Management.Automation.ExecutionContext)
Number of exceptions of this type: 2 Exception MethodTable: 000007fef2b475c0 Exception object: 0000000003539400 Exception type: System.TimeoutException Message: ソケット転送が 00:01:00 後にタイムアウトしました。バインドに設定されているタイムアウトを超えました。この操作に割り当てられた時間は、より長いタイムアウト時間の一部であった可能性があります。 InnerException: System.Net.Sockets.SocketException, use !PrintException 0000000003538948 to see more StackTrace (generated): SP IP Function 000000001C1EC690 000007FEE7A4B60C System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[], Int32, Int32, System.TimeSpan, Boolean) 000000001C1EE770 000007FEE6B43D75 System.ServiceModel.Channels.SocketConnection.Close(System.TimeSpan)
StackTraceString: <none> HResult: 80131505
Number of exceptions of this type: 2 Exception MethodTable: 000007fef0f99848 Exception object: 00000000035061a0 Exception type: System.Net.Sockets.SocketException Message: 既存の接続はリモート ホストに強制的に切断されました。 InnerException: <none> StackTrace (generated): SP IP Function 000000001C1EE650 000007FEF0ECE486 System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags) 000000001C1EE6A0 000007FEE6B54C9D System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[], Int32, Int32, System.TimeSpan, Boolean)
StackTraceString: <none> HResult: 80004005
さて、ではこの現象の要因となる「私これだけ待つことができます」値 (私の心の中では『あみん値』と呼称しているのは内緒ですが…なんで「あみん」なの？というヤングマンはお母さんに聞いてみてください。) は以下に記載がある、MaxEnumContextExpiration です。この値は %Windir%\ADWS\ フォルダ配下にある、Microsoft.ActiveDirectory.WebServices.exe.config で設定されています。
What's New in AD DS: Active Directory Web Services Updated: January 9, 2009 Applies To: Windows Server 2008 R2 http://msdn.microsoft.com/en-us/library/dd391908(v=ws.10).aspx
ご注意ください : 期間が長いクエリを実行していて、この現象に合致するかな？と思われる場合は試しにちょっとだけ伸ばしてみるのもありですが、基本的に上記の "Caution" にあるように、既定値を変えることはおすすめできません。やはり、30 分以上検索コンテキストをオープンにしておくのはあまりよろしくないですし、確認もしくは一時的にどうしても、大容量データを取得する必要がある場合などにちょっと変えるくらいがよいでしょう。あくまでも暫定回避です。お勧めの回避方法としては、やっぱりリトライになります。 なお、上記 MSDN の日本語訳があるのですが、全く逆の内容になっています。(2011/06/28 現在) 基本的に、原文も併せて読むことをお勧めいたします。
日本語訳 http://technet.microsoft.com/ja-jp/library/dd391908(WS.10).aspx
× 注意 このパラメーターの既定値は変更することをお勧めします。 ○ 注意 このパラメーターの既定値を変更することは推奨いたしません。
原文
日本語訳
・get-AD 系コマンドレットの検索クエリがオープン可能な時間は既定で 30 分、MaxEnumContextExpiration で設定 ・MaxEnumContextExpiration は %Windir%\ADWS\ フォルダ直下にある ・30 分以上クエリに時間を要すると発生する例外のパターンは一意ではないが、必ず 30 分が現象発生有無の分水嶺になる ・例外が発生した状態の PowerShell コンソールをタスク マネージャでダンプを取り、psscor2.dll の !dae コマンドで見ると多数の Socket 系例外や、AD のクエリ関連のタイムアウトの情報が出ている ・MaxEnumContextExpiration の値を書き換えるのはお勧めできない。が、日本語訳のページではおすすめしている。正解は「(MaxEnumContextExpiration の) 既定値を書き換えることはおすすめいたしません」
それでは皆様ごきげんよう。
ういこう@ヴァン・アレン帯デーキッス★
皆さんごきげんよう。ういこです。気が付いたら 6 月。カエル型宇宙人がいたら肌艶が良くなりそうな気候になっていますが私の肌艶は全然よくなりません。ヒアルロン酸が足りないんでしょうか。さて今日は、『セキュリティ イベントログを PowerShell で取る際「アカウント名」を引っこ抜く方法』をお送りします。
【今日のお題】 オレをすりこぎにしちまった奴 そいつは誰だ 誰なんだ
HEY YOU HEY YOU WHAT'S YOUR NAME？ -- 左とん平「とん平のヘイ・ユウ・ブルース」より
(※) 敬称略
…一応、Script 担当チームとして Hey, Scripting Guy! を気取ってみましたが、いきなりやらかした感じですみません。なんか引用とかして見たかったんです。すりこぎとか意味不明すぎますね。すみません。いきなりこのページをご参照頂いた方、当ブログは決して怪しいブログではありませんので、ご安心ください。ちなみに名曲です。
さて、世迷言は置いておいて、唐突ですが、システム管理者様に取って、必要不可欠ながら手がかかるので愛憎合いまみえることもあるものの一つ…そのなかにイベント ログは入っていらっしゃいませんか？特にセキュリティ イベントログ。監査増やした日にはあっという間にログが流れていくわ、WMI で取ろうとするとバッファサイズ超えることもありえるわ、だけど保存しなきゃ…と、すごく手がかかる子です。その辺の話は、過去熱く語ったことがあります。
[WMIは万能ではない] 大容量イベントログ取得時によくある問題と回避策 ～ Script からも wevtutil.exe が使える ～ http://blogs.technet.com/b/jpilmblg/archive/2011/02/15/wmi-script-wevtutil-exe.aspx
[WMIは万能ではない] 大容量イベントログ取得時によくある問題と回避策 ～ Script からも wevtutil.exe が使える ～
http://blogs.technet.com/b/jpilmblg/archive/2011/02/15/wmi-script-wevtutil-exe.aspx
イベントログを取るコマンドレットとして、Windows PowerShell には、以下の二つがあります。
・Get-EventLog 古い Windows XP / Windows Server 2003 以前のイベントログ形式で動作するため、処理時間のパフォーマンスに問題を及ぼす場合があります。また、Windows Vista / Windows Server 2008 以降の新イベントログ形式 (EventLog 2.0) のログは取得できません。 ・Get-WinEvent 新しいイベントログ形式で動作しますし、Get-EventLog と比較すると安定した高速な動作ですが、PowerShell 2.0 以降に搭載されたコマンドレットですので OS 既定の PowerShell のバージョンが 1.0 の Windows Server 2008 無印以前では PowerShell をアップグレード頂く必要があります。
・Get-EventLog
古い Windows XP / Windows Server 2003 以前のイベントログ形式で動作するため、処理時間のパフォーマンスに問題を及ぼす場合があります。また、Windows Vista / Windows Server 2008 以降の新イベントログ形式 (EventLog 2.0) のログは取得できません。
・Get-WinEvent 新しいイベントログ形式で動作しますし、Get-EventLog と比較すると安定した高速な動作ですが、PowerShell 2.0 以降に搭載されたコマンドレットですので OS 既定の PowerShell のバージョンが 1.0 の Windows Server 2008 無印以前では PowerShell をアップグレード頂く必要があります。
※ PowerShell 2.0 に興味をもたれた Windows Vista 以前のユーザの皆様、ダウンロードはこちらから実施いただけます！
Article ID: 968929 - Last Review: June 10, 2011 - Revision: 3.1 Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0) (※注 : 下記文書中にダウンロード直リンク群あり) http://support.microsoft.com/kb/968929/ja
さて、セキュリティログに話を戻しましょう。
たとえば監査ログを取っていて、「何だか変…最近わたしの可愛いサーバに誰かが繰り返し入り込もうとしているようだわ！！気持ち悪い！誰か突き止めてとっちめてやるわ！」とか、気になる人のサーバをチェックしてあげて、「べっ…別に、あなたのためにやったんじゃなくて、会社のセキュリティのためなんだからねっ！」なんて思ったとします。でもイベントログ一個一個見てると疲れるので、アクセスしている連中のアカウント名を一気にリストにして晒し挙げ差上げてやりたいときとかあるかもしれませんよね。
では、アカウント名ってどうやってとったらよいのでしょう？実は、セキュリティ イベントの中の「アカウント名」って独立したプロパティではなく、イベントログ エントリに関連付けられている文字列の中に紛れていて、抜き出さないといけません。案外面倒なのです。イベント ビューア上では綺麗にみられるのに！と思われる方、イベント ビューアは健気に水面下で激しく水を掻く白鳥のように実はがんばっているのです。材料のイベント ログそのものは XML の面倒なデータそのものだったりするのです。イベント ビューア、がんばってます！
ではアプローチ方法はないのかというと、少々泥臭い方法を取らなくてはなりません。
イベント ログ エントリに関連付けられている置換文字列 "ReplacementStrings" を取得し、配列番号を指定して抽出する。
一般的には、アカウント名は ReplacementStrings の二番目の配列 (ReplacementStrings[1]) に格納されていますので、この配列[1] を取得する対処を実施します。なお、これはあくまでも一般的なログの話であり、すべてのイベントログに共通する処理ではないことに注意が必要です。
参考 : EventLogEntry.ReplacementStrings プロパティ http://msdn.microsoft.com/ja-jp/library/system.diagnostics.eventlogentry.replacementstrings.aspx
Get-EventLog は旧来の Event Log 1.0 ベースのイベント ログ形式に対応していますが、Get-WinEvent は 2.0 以降のイベント XML 形式に対応しておりますため、以下のような段階を踏んで情報を抽出する必要があります。
1. Get-WinEvent コマンドレットにてイベントログを取得する 2. Select-Object コマンドレットにパイプで受け渡しし、-Property オプションで Property パラメーターを取得する 3. Expression キーの n 番目の値 (Value) を取得する
Property パラメーターの配列数は、"イベント XML" の下の <EventData> 要素配下の数に一致します。
例)
図 1 : アカウント名が二つある場合もある
図 2 : アカウントが “-” ハイフンになっている場合もある
実行結果例)
イベント ビューアで個別のイベントを開くと、[詳細] タブが選択できます。このタブには、XML が表示されています。
イベント XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4624</EventID> <Version>0</Version> <Level>0</Level> <Task>12544</Task> <Opcode>0</Opcode> <Keywords>0x8020000000000000</Keywords> <TimeCreated SystemTime="2011-05-24T07:34:53.910829500Z" /> <EventRecordID>5138894</EventRecordID> <Correlation /> <Execution ProcessID="572" ThreadID="5472" /> <Channel>Security</Channel> <Computer>uikou-seven.JPDSFIM.corp.microsoft.com</Computer> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-5-18</Data> <Data Name="SubjectUserName">UIKOU-SEVEN$</Data> <Data Name="SubjectDomainName">JPDSFIM</Data> <Data Name="SubjectLogonId">0x3e7</Data> <Data Name="TargetUserSid">S-1-5-21-2146773085-903363285-719344707-1205599</Data> <Data Name="TargetUserName">FABRIKAM01$</Data> <Data Name="TargetDomainName">JPDSFIM</Data> <Data Name="TargetLogonId">0xee4ced</Data> <Data Name="LogonType">3</Data> <Data Name="LogonProcessName">Advapi </Data> <Data Name="AuthenticationPackageName">Kerberos</Data> <Data Name="WorkstationName">UIKOU-SEVEN</Data> <Data Name="LogonGuid">{E7C2D064-03C2-6232-CE07-590C1823359E}</Data> <Data Name="TransmittedServices">-</Data> <Data Name="LmPackageName">-</Data> <Data Name="KeyLength">0</Data> <Data Name="ProcessId">0x3e4</Data> <Data Name="ProcessName">C:\Windows\System32\svchost.exe</Data> <Data Name="IpAddress">-</Data> <Data Name="IpPort">-</Data> </EventData> </Event>
このうち、<Event> セクション配下には、<System> 要素と <EventData> 要素があります。<System> 要素は、それぞれ独立した名前で Property として取得できます。一例をあげますと、以下のような形になります。
> Get-WinEvent -FilterHashtable @{LogName="Security"; ID=4624} -MaxEvents 5 | Select-Object -Property ID,Keywords,ProviderName,Task ★← 独立した名前を持つプロパティ
Id Keywords ProviderName Task -- -------- ------------ ---- 4624 -9214364837600034816 Microsoft-Windows-Security...12544 4624 -9214364837600034816 Microsoft-Windows-Security...12544 4624 -9214364837600034816 Microsoft-Windows-Security...12544 4624 -9214364837600034816 Microsoft-Windows-Security...12544 4624 -9214364837600034816 Microsoft-Windows-Security...12544
上記例では、(Event)ID、Keywords、Provider Name、Task の要素を取得して表示しています。一方、<EventData> 要素配下にあるデータを取得する際は、上述の<System> 要素内にある値と異なり、EventData のひと塊の配列として取得後、添え字（インデックス）を入れて分解する必要があります。
※ properties[20] のように、データが存在する数以上の添え字を指定しても空白のみが返ります。
「アカウント名」が表示上二つ存在するイベントも存在します。上記のイベントを例にとりますと、配列要素 2 番目 ($_.properties[1].value) “SubjectUserName” および配列要素 6 番目 ($_.properties[5].value) が "アカウント名 = TargetUserName" として イベント ビューア上に表記されている値と一致します。
以下配列要素 6 番目 ($_.properties[5].value) が "アカウント名" としてとってきた際のスクリーンショットです。
以下のように参照頂ければ、情報は取得できるかと存じます。下記の例では、サブジェクトの "アカウント名" を取得しています。アカウント名は、配列 2 番（添え字 1）ですので、以下のような取得方法になります。
例) Get-WinEvent -FilterHashtable @{LogName="Security"; ID=4624} -MaxEvents 15 | Select-Object -Property @{n="SubjectUserName";expression={$_.properties[1].value}}
補足 : 各イベントごとの要素配列の設計資料などについて なお、Select-Object コマンドレットは、配列の名前を付けなおすこともできます。後述 "■参考資料" 中の MSDN マガジンの記事などがご参考になるかと思います。イベント ID によって要素の配列位置が移動する可能性もありますので、# のコメントで参照データ名を PS1 ファイル内に記載しておき、万が一将来参照先のイベントログの ID を変える必要ができた時などは、配列の添え字だけ変えることで対処するということもよいでしょう。
(例: 二番目から八番目に参照箇所を変える場合 / $_.properties[1].value -> $_.properties[7].value など)
イベントは、各ソース、ID 毎にフォーマットが異なります。「概ね共通して同じような形式」ではありますが、明示的に「配列の何番に何を入れなければならない」ということは決まっていないということがどうしてもあります。また今後も追加、変更される可能性などもあり、実際に確認いただきつつ必要な情報の取捨選択を実施頂く必要があります。Message プロパティ内にどれだけのイベントログ内の情報を採れるかについては、そのイベントログの構造に依存する動作になります。コマンドレットはイベントログに取得を依頼したあとは、そのログが返すデータをそのまま格納するため、イベント ログそれぞれがどのようにデータを渡してくるかまでは（明らかに NULL の場合などを除き)特に形式や中身を意識しないためです。
Select-Object http://technet.microsoft.com/ja-jp/library/dd315291.aspx
Windows PowerShell の機能 Select-Object コマンドレットの使用 http://technet.microsoft.com/ja-jp/library/ee176955.aspx
Windows PowerShell 続すてきなパイプラインの手法 (Select-Object による要素の rename など) http://technet.microsoft.com/ja-jp/magazine/ff394367.aspx
Windows PowerShell: コマンドを再利用可能なツールにする http://technet.microsoft.com/ja-jp/magazine/gg537351.aspx
さて、すごく久しぶりに書いたのでちょっと緊張しております。少しでも皆様のイベントログ管理の負担が減って、すりこぎにされそうな日々が解消しますように。
ういこう@人生はすりこぎなんだよ! OH MY BABYこのブルースを聴いてくれ!!
本日のトピックは、WMI の クラスの組み合わせで発生する制限事項についてのお話となります。
はじめに : NIC 自身のシステムへの登録の仕方に Name プロパティの取得結果が影響される システムに登録されたネットワーク カード (NIC) の情報を採取する際に WMI の Win32_NetworkAdapterConfiguration および Win32_NetworkAdapter クラスを使用する例は多くあります。しかし、これらのクラスの Name や Description プロパティだけでは複数の同じ種類の NIC それぞれを識別する指標にはなりえません。
Name や Description プロパティなど、上記の WMI のクラスが返すプロパティ情報は、その環境の NIC がセットアップされる際にどのように自身の情報をシステムに登録したかに依存します。つまり、同じ種類の NIC を複数セットアップする際に、システムにそれぞれの NIC 毎に同じ名前で登録してしまう作りのデバイスの場合、Name や Description プロパティの値がすべていっしょということも起こりうるということになります。アダプタによっては、システム登録時複数同じ種類のアダプタが存在していても #1 、#2 のように識別子を付けず同じ名前で登録してしまうものがあるのです。
図 : NIC によっては同じ名前でレジストリに登録してしまうものもありえる。ただし、デバイス ID は固有。
名前が重複するインスタンスそれぞれを見分けるための指標とは こうした「同じ名前のインスタンスそれぞれ、同じ名前でプロパティが返ってきてしまう」ということは Win32_NetworkAdapter や Win32_NetworkAdapterConfigration クラス以外にもよくあります。一番身近な例としては、Win32_Process クラスです。システム上に、notepad.exe や svchost.exe など複数の同じ名前のプロセスが起動していることはごく普通にあるシチュエーションです。こうしたクラスでは、ほかにインスタンス（それぞれのデバイス、それぞれのプロセス）を特定するためのユニークな ID 情報のプロパティがありますので、そちらを使って個別の判定をします。
・Win32_NetworkAdapter … DeviceID プロパティ ・Win32_NetworkAdapterConfigration … SettingID プロパティ ・Win32_Process … processID プロパティ など
通常はデバイスやプロセスなどの個別の実体を把握するには、これらのユニークな値を返すプロパティ値を基準にします。
Win32_PerfRawData_Tcpip_NetworkInterface (Win32_PerfFormattedData_Tcpip_NetworkInterface) クラスのインスタンス識別が事実上できないのはなぜか Win32_PerfRawData_Tcpip_NetworkInterface および Win32_PerfFormattedData_Tcpip_NetworkInterface クラスは、パフォーマンス モニターのエンジンを通じて NIC のパフォーマンス情報を取得します。ところが、この際に以下の点に注意しなくてはなりません。
・Win32_PerfRawData_Tcpip_NetworkInterface (Win32_PerfFormattedData_Tcpip_NetworkInterface) クラスはパフォーマンス モニターの GUI 上の見た目をそのまま引き継ぐわけではない ・各 NIC のインスタンス識別は、同クラスの Name や Description プロパティを用いるほかにないが、これらは複数同じ名前でネットワーク アダプタが登録されたシステムではすべて同じになってしまう。(※)
しかし、残念ながら Win32_PerfRawData_Tcpip_NetworkInterface (Win32_PerfFormattedData_Tcpip_NetworkInterface) クラスは DeviceID や SettingID をインターフェースに持たないため、事実上これらのクラスの各 NIC のインスタンスを識別しきれないということになります。(※ Captionプロパティの頭には識別子がつきますが、Win32_Perf… クラスの Name 自体に識別子を持たないため、結局どれがどれなのか判別できません)
＜データを識別できないパターン＞ ・複数の Win32_PerfRawData_Tcpip_NetworkInterface インスタンスが同じ Name プロパティを持つ ・複数の Win32_NetworkAdapterConfiguration インスタンスが同じ Description プロパティを持つ
Description プロパティの元になるのはレジストリですが、レジストリ キーは環境や NIC によって異なる値の可能性がある上、値を変更することでその NIC の情報に依存したアプリケーションがある場合も含め、システム上の影響としてどのような状況に至るかはケースバイケースになる上、書き換えたはずのレジストリが再度書き換えられる、あるいは別にレジストリがまた作られるような動作をする場合もあります。そのため、環境側から名前を書き換えることは推奨しません。
図 : レジストリに登録されたデータが重複していると取得結果も重複する
パフォーマンス モニター上では NIC が識別されるのに、なぜ WMI のクラスでは識別子がついてない状態になるのか なお、このように元データが重複している環境でも、パフォーマンス モニター上では、各 NIC のデータはちゃんと #1、#2… のように識別できる状態で表示されています。しかし、これはパフォーマンス モニタが出力する際に内部でそれぞれの実体を識別し、識別子を付けた状態で表示させる実装をしているためです。残念ながら、パフォーマンス モニタ側の識別子ありの状態のデータを扱うためのインターフェースは公開されていないため、事実上プログラム側では識別ができない状態は変わりありません。
参考 : Win32_Process クラスと Win32_PerfRawData_PerfProc_Process (Win32_PerfFormattedData_PerfProc_Process) 一方、同じく Name プロパティが重複して帰ってくるプロセスの場合を見てみますと、Win32_PerfRawData_PerfProc_Process および Win32_PerfFormattedData_PerfProc_Process クラスでは、Caption のほか、プロセス ID に対してもインターフェースを解放しています (IDProcess)。プロセス ID は文字通りインスタンス固有の情報ですのでそもそも Caption ではなく ID を使うことで識別ができます。そのため、ネットワーク アダプタのように、名称が重複しても識別できない状況にはなりません。
*****
残念ながら、この動作は製品の既定の動作となります。また、NIC の名称を重複させてはいけないという制限事項もないため、NICのハードウエアメーカー様の設計次第でそのシステム上で動作するソフトウエア（含む OS のモジュール、たとえば今回の WMI など）が今回のように影響されてしまう状況が全くないと言いきれません。
上記のようなシナリオでプログラムを設計されている場合はこうした構成にご注意ください。
(WMI Programming Support Team – May 04, 2011)
***** この記事は 2011 年エイプリルフールの企画です。*****
2011 年 4 月 1 日 (Japan) 日本マイクロソフト株式会社
■Microsoft最新情報
マイクロソフト コーポレーション（Microsoft Corporation、本社：米国ワシントン州レドモンド）は日本時間 4 月 1 日未明、次世代の ID 管理製品である Forefront !dent1ty M0nster (F!M) Zolo R2 の開発者向け試用版を発表しました。F!M は現在、業界で広く採用されている ID 管理ソリューションです。Forefront !dent1ty M0nster Zolo R2 では、次世代の ID 管理のための最新テクノロジを活用できます。Forefront !dent1ty M0nster Zolo R2 は、Active Directory やグローバル アクセス リストの同期をはじめ、これまでと同様 若返り機能、婚活機能をはじめとした多機能な同期機能と豊富なツール セットを提供します。これにより、統合されたスムーズかつ効率的な同期を実施しつつ、IT 業界従事者の共通の課題である運動不足を解消することが可能になります。加えて新機能「Forefront !dent1ty M0nster」を搭載。「直観的にユーザのポジション（偉さ）がわかりづらい」「プロジェクト人員を選定しているが、どれくらい仕事ができる人かわからない」といった問題に対し、各ユーザの属性をもとに MP・HP・Job などを GUID や各属性の値をもとに数値化し、アバターとして "!dent1ty M0nster" を GUI にグラフィカルに表示することが可能になりました。このアバター同士を戦わせることによって、ユーザに知られることなく、ユーザの仕事力などを判断することができるようになります。 また大きな変更点として、これまで文字ばかりで分かりづらいとの声が多かった F!M Synchronization Manager を XBOX プラットフォーム版に統一し、Kinect を通じた操作を行うよう変更されました。これに伴い、Windows 上の F!M Synchronization Manager は廃止されることになります。また、F!M Portal も Kinect 用インターフェース追加が実施されました。
+
◇
マイクロソフト コーポレーション Forefront !dent1ty M0nster 担当 プロダクト マネジメント ディレクターは「マイクロソフトは Metadirectory Server を提供以降、ID 管理製品業界の拡大に寄与しました。さらにこの F!M R2 によって、マイクロソフトはこれまで無かった発想で、サーバー製品と Kinect という革新的なインターフェースとの統合をはかるなど、ID 管理製品におけるイノベーションを牽引し続けていきます。これまでの F!M で提供されてきたリソースの集中管理を行うことで分散された ID を統合することで企業が抱える ID の分散によるセキュリティ リスクやコスト削減などの機能に加え、Kinect を通じて体を動かすことによる体感的直観的な操作ができることにより、管理者のフラストレーションまで解決することができるでしょう。また、!dentity M0nster 同士で戦わせることによって、本当に仕事のデキる人間は誰かを容易かつ客観的な数値によって評価することができるようになることで、いわばド●ゴンボールのスカウターのような役割を果たします。また肩書と実際の仕事力、人間力のバランスが適正か素の状態の人物像も把握できるようになるのです。日本では、渡辺淳一氏の孤舟という本が話題を集めていると聞きます。定年後、肩書を亡くした自分の人間力のプレビューをすることで、より豊かな人生を送ることも期待ができると考えています。」と述べています。
Forefront !dent1ty M0nster Zolo 2010 R2 は以下の機能やサービスを提供します：
■既存機能 <若返り機能> 同期の際に Delete/Add することで、アラ不思議! Export 後は、同じ名前で新しく...
※ Delete/Add では、作成された同じ名前のオブジェクトは Delete 前と SID は実は変わってしまっているので、同じ名前でもアクセス権等の問題で家とか行きつけの会員制ほにゃららに入れない可能性もあります。
＜婚活機能> 気になる彼女に FullSync ! 思いのままに Join ルールを設定いただけます DisConnect も可能ですが、しがらみが残ることはご容赦下さい...
※ Yome オブジェクト / Danna オブジェクトの Deprovision はしばしば非常な困難を伴います。色々なしがらみにより、Pending Export でいつまでも残っちゃったりするので、運用シナリオは慎重に計画することを推奨します。最悪あなたの大事な CS を削除して、Full Import 、Full Sync x 2 回からやりなおさないといけないリスクがあります。
<拡張機能 1> Codeless Provisioning で、家族を拡張も容易に ※ 子オブジェクトは計画的にお作り下さい。Deprovision できません...
※ 子オブジェクトは…（以下略）
<拡張機能 2> ルール拡張次第で、お好みの自分に 実装障害で予期せぬ容姿にならぬよう、十分注意下さい。
※ 残念ながら、システムの再構築（通称 : 来世待ち）をお勧めせざるを得ない可能性もあります。
■R2 からの追加機能 <追加機能 1> Forefront !dent1ty M0nster 一定のルール付けを実施したフィルタを管理エージェントに搭載することで、Active Directory の属性などにより仕事力、コミュニケーション力、人間力、毛根力などを測定することができます。 このルールは、F!M Portal 上で直観的に編集することも可能です。 設定後は各ユーザごとにアバター "!dent1ty M0nster" が生成され、!dent1ty M0nster カプセルに格納されます。!dent1ty M0nster を戦わせることで測定を実施します。この際、ジョブタイトル、クラスチェンジなどでパラメータの重みづけが変更されることによる実際の人間力に肩書などによる補正後のデータによる測定のほか、全重みづけを解除することで、素の人間力を判断することも可能です。
<追加機能 2> F!M Portal の Kinect 対応 ユーザー インターフェイスに左右されることなく、手足の動きや声によってだれでも直感的に IT 機器を操作可能とする Xbox 360 のゲーム システム「Kinect」と統合することにより、管理ポリシーなどを直観的に体を使い、操作することができます。
<追加機能 3> F!M Synchronization Manager を XBOX プラットフォーム版に統一、Kinect を通じた操作可能に これまで文字ばかりで直観的に操作しづらいと言われることもあった F!M Synchronization Manager を XBOX プラットフォーム版に統一し、Kinect を通じた操作を行うように変更されました。これに伴い Windows OS 上の F!M Synchronization Manager は廃止になりました。IT 業界に従事する人間の運動不足の解消も可能です。
Before
After R2
図 : デモ操作の様子。画面は開発中のため、本日時点は非公開となります。
Forefront !dent1ty M0nster Zolo R2 は、さまざまな場面においてリッチなエクスペリエンスを提供するというマイクロソフトの戦略の中核として、サーバー製品としてはいち早く若返り機能など、革新的な機能やサービス、エクスペリエンスを提供しイノベーションとユーザー エクスペリエンスの向上を促し、"Windows の世界" だけでなく、アストラル界など異次元へのつながりまでも実現するソフトウェアおよびサービスの提供を目指すマイクロソフトの姿勢を体現する ID 管理製品です。 Forefront !dent1ty M0nster Zolo R2 の開発者向け試用版についてはこちらを参照してください。
■参考資料 Xbox 360 のゲーム システム「Kinect」: 直感的に使えるインターフェイス Kinect の技術が IT の未来を拓く http://www.microsoft.com/japan/opinionleaders/economy_ict/110302_2.mspx
Forefront Identity Manager のすごい効能が明らかに！！明かされる隠された機能... v1.1 http://blogs.technet.com/b/jpilmblg/archive/2010/04/01/fim2010-forefront-identity-manager.aspx
◆マイクロソフトに関する詳細な情報は、下記マイクロソフトWebサイトを通じて入手できます。 日本マイクロソフト株式会社 Webサイト http://www.microsoft.com/japan/ マイクロソフトコーポレーション Webサイト http://www.microsoft.com/ *Microsoft、Windows Server、Visual Studio、SQL Server、Forefront、Hyper-V は、米国 Microsoft Corporationの米国及びその他の国における登録商標または商標です。 *Windowsの正式名称は、Microsoft Windows Operating Systemです。 *その他、記載されている会社名、製品名は、各社の登録商標または商標です。
重要なお知らせ [2011/03/21 23:00 Update] 平素より弊社製品およびサポートサービスをご愛顧くださいましてありがとうございます。
2011 年 3 月 22 日火曜日 9:30 AM 以降、サポート窓口は Premier / Professional サポートとも、すべての深刻度で受付が再開されます。これまでお急ぎのところ、ご不便をおかけしておりましたことをお詫び申し上げます。 なお引き続き災害復旧事案の対応を優先するため、お電話のお問い合わせの際も引き続き受付窓口でいったんお受けした後、担当エンジニアよりコールバックする対応とさせていただきます。弊社からお客様へのご連絡が遅れる場合もございますが、何卒ご理解のほどお願いいたします。
サポート窓口の対応のアップデートにつきましては、下記の web および本トピックにて随時更新いたします。
http://support.microsoft.com/select/?target=assistance&ln=ja
なお、先日の地震発生に伴い、弊社オフィスも輪番停電の対象となっております。停電時のバックアップ体制は別オフィスなどにも構築しておりますが、停電や電話回線事情により、以前にお伝えしている各担当エンジニアの直通電話番号は 3/16 以降一時着信できない場合があります。引き続き、上述の通りコールバックにて対応いたしますので、メールにてご連絡頂ければ幸いです。誠に恐縮ではございますが、諸般事情のご理解を賜りたく、何卒よろしくお願い申し上げます。 ※ 下記にも反映されました。
http://msdn.microsoft.com/ja-jp/default.aspx 最新ニュース http://technet.microsoft.com/ja-jp/default.aspx IT 担当者向け最新情報 http://technet.microsoft.com/ja-jp/today セキュリティ& サポート
[2011/3/16 JST 14:30 Update]
東北地方太平洋沖地震についてのマイクロソフトの対応についてのプレスリリースが発表されました。詳細は下記画像をクリック頂くとページに遷移いたします。
なお、twitter アカウント @msdnjp @technetj にて最新情報などを随時お伝えしていますので、よろしければご利用ください。
～ ILM / ADSI / WMI / PCNS サポートチーム ～
(Update : 2011/03/14 9:15 PM By JPDSILM)
東日本大震災の被災者の皆様、またそのご家族や関係者の皆様、心よりお見舞い申し上げます。
東京の街を歩けば、ガソリンスタンドで渋滞が起きていたり、コンビニの棚が空っぽだったりすることを除けば、とても穏やかないつものような日々が続いているように見えます。でも、本日 (3 月 13 日) 現在、こうしている今も被災地で、被災された皆様はそれぞれの戦いをされています。私事ながら、私も親戚と友人が被災地に住んでおり、いまだ連絡が取れない状況が続いております。そんな中で、弊社に何ができるのか、有志たちが考え続けております。
その一つの形として、Windows Azure Platform 無料パス(クレジットカード登録不要、90日間) が開始されました。 利用の前段階に必要な処理（アクティベーション）も、即日対応となっています。通常は 3 日前後いただいておりましたが、即日です。 また通常の Windows Azure 無料パスは 30 日間の有効期限がありますが今回のプロモーション コードをご利用いただいた場合、90 日間ご利用頂くことが可能です。被災者の皆様が直接今使うことではありませんが、被災された方を支援する方々がこちらを情報伝達手段などに利用頂くことで、スムーズに対応を進めていただくことが可能になるかもしれません。どうか、お役立て頂ければ幸いです。
Windows Azure Platform 無料パス (東北地方太平洋沖地震 対応用) http://windowsazurepass.com/?Campid=F3313E69-464C-E011-98E3-001F29C8E9A8
プロモーションコードは AZURE312 です。
また、Azure 利用に関するご相談は twitter.com で以下のハッシュタグをつけて tweet してみてください。
#JAZUG (Japan Azure Users Group) http://twitter.com/search/%23JAZUG #AzureJP (Windows Azure 日本語情報) http://twitter.com/search/%23azurejp
参考 MSDN Windows Azure デベロッパーセンター http://msdn.microsoft.com/ja-jp/windowsazure/ff394366
どうか、一日も早く離れている方々が再会出来て、復旧が進みますように。一人でも多くの人が無事でいらっしゃいますように。 心より皆様の御無事をお祈り申し上げます。
～ FIM / ADSI サポートチーム一同 ～
みなさんごきげんよう。ういこです。花粉はビシバシ飛んでいるのに寒くて仕方ないアンビバレンツな日々ですが皆様いかがお過ごしでしょうか。 今日は、「コマンドレットみたいにボクの PS1 ファイルの引数もタブ補完させる方法」をご紹介します。対象は PowerShell v1.0 – 2.0 共通です。
a. PowerShell のタブ補完の素晴らしさに思いを馳せる PowerShell がすてきだな、と思わせてくれる瞬間は、何といっても「あのすさまじく長いこともあるコマンドレットの名前をタブでガッツリ補完してくれる」というあの至れり尽くせりな感じ」であると私は思います。正直「コマンドレット名…なんでこんなに長いのさ…」と思うなが～いコマンドレット名もいっぱいありますが、��丈夫！ちょっと打ち込んで、タブを打てばどこかの黒い執事さん張りに「あなたのお探しのコマンドレットはこれでございましょうか」くらいの勢いで提案してくれます。 素敵！ ありがとう PowerShell！これでうろ覚えでも使えるよ！ちなみにカレントディレクトリにあるファイルも補完してくれちゃったりします。これはコマンド プロンプトと同じですね。
例 コマンドレットを探してみよう (Get-ADAccountAuthorizationGroup) get-a まで入力して、おもむろにタブキーを押そう
候補を出してくれますよ！”Get-ADAccountAuthorizationGroup”、な、ながっ！！
※ すぐに結果だけほしいの…というあなたには、あるいは get-help get-a* のように、ワイルドカードで一気に出しちゃうという手もお勧めです
さて。それで、タブ補完って、実はコマンドレット名だけじゃなくて、そのコマンドレットの引数まで出してくれるんですよ。 これがまた特に switch と呼ばれる、変数がほしいわけじゃなくて、処理を分岐させる判断のために使うタイプの引数とかに威力を発揮。なが～い引数名いちいち打ってられないじゃないですか。だってタイプミスしたらまた長いの打ち直しだし。 上記のコマンドレットを例にとると、いくつか引数を取りますが、いちいち Get-Help で見るの面倒。もしくはうろ覚えで機能は覚えてるけど引数名超覚えてないという方も大丈夫。- (ハイフン) を打って、タブを打つと、引数名まで保管してくれます。
いやほんと便利ですよね。
b. PS1 (PowerShell スクリプト ファイル) にも引数を取るつくりの場合、タブ補完って使えないのかな？ コマンドレットがバリ便利ということはいやってほどわかりますが、それを組み合わせてスクリプト ファイルにした場合、引数を取ることってありえますね。そうした場合、PS1 実行時に使う引数名をコマンドレットみたいに補完出来たらいいなぁと思うことがあるのではないでしょうか。 こうした時、どうすればいいか？答えは、「Param ステートメントを使う」です。
＜ポイント＞ ・PS1 ファイル (スクリプト ファイル) で PowerShell コマンドレットと同様に引数名を公開させるためには、param ステートメントを利用します。これにより、- キー入力後続けてタブ キーを押すことでパラメータ名の補完が実施されます。 ・param ステートメントは PS1 ファイルの先頭に記載する必要があります。ただしコメント (# で続く文字列) が前に来るぶんには問題ありません。
例) Param( [string]$computer=$env:computerName, [switch]$disk, [switch]$processor, [switch]$memory, [switch]$network, [switch]$video, [switch]$all )
引数名にアクセスできるようにするためには、引数名を PS1 ファイルの先頭に param ステートメントを定義し、その中で指定します。構文は Param(<…>) です。<…> に引数名を指定します。必ずかっこ内に入れてください。この際既定値を与えておくことも可能です。引数が明示的にユーザに与えられなかった場合設定しておいた既定値が使用されます。 上記の例では、第一引数 $computer に PowerShell は Environment プロバイダを通じ、$env 変数からシステムの環境変数に関する情報を取得して初期値としてセットしています。
[string]$computer=$env:computerName,
初期値として実行コンピュータ名が入ります。これは実行時に上書きし、例えばリモート コンピュータ名を入力すれば、リモート コンピュータ名が $computer 変数に入りますが、実行時に指定しなければ、ローカル コンピュータの値がそのまま使われる動作になります。
次の、二個目以降の [switch] がついている引数は、スイッチ パラメータ、つまり値を指定しない、処理分岐用の引数などに用いられるタイプの引数です。
[switch]$disk, [switch]$processor, [switch]$memory, [switch]$network, [switch]$video, [switch]$all
タブ押下時に呼び出される順番は？ 基本的に、宣言された順に候補が補完されます。上記の例の場合、以下のようになります。
タブ 1 回目 : .\<PS1 ファイル名>.ps1 –computer
タブ 2 回目 : .\<PS1 ファイル名>.ps1 –disk
タブ 3 回目 : .\<PS1 ファイル名>.ps1 -processor
簡単に挙動を試す方法 一番挙動を簡単に試すには、上記 -a. 項の Param ステートメントだけをメモ帳に張り付け、拡張子 PS1 ファイルで保存し、PowerShell 上で動かすことです。中身がないので、実行しても何も起こりませんが、タブ補完の挙動だけみることができます。
＜確認手順＞ 1. 以下をメモ帳にコピー ####### ここから Param( [string]$computer=$env:computerName, [switch]$disk, [switch]$processor, [switch]$memory, [switch]$network, [switch]$video, [switch]$all ) ####### ここまで
2. メモ帳を拡張子 ps1 で保存 (例 C:\temp\Tabtest.ps1) 3. PowerShell を起動 4. .\<ファイル名>.ps1 の後、"-" を入力し、タブキーを押す
例) PS C:\temp> .\Tabtest.ps1 -computer
5. もう一度そのままタブキーを押すと、-computer から -disk に引数が変わって補完されることを確認
例) PS C:\temp> .\Tabtest.ps1 -disk
c. Scripting Guy のコマンドレットをちょっとだけ改造したサンプル このサンプルでは、WMI を使ってコンピュータの情報を出すようにしています。以下の表の中の内容をメモ帳にコピーし、拡張子 ps1 で実行してみてください。実行前に - を打ってタブを打って、ちゃんと引数が変わることを確認していただけると思います。
-computer … コンピュータ名、省略時はローカルの情報を出す。指定した場合はリモート コンピュータの情報を確認しに行く -disk … ディスク情報を取得します。 -processor … CPU の情報を取得します。 -memory … 搭載メモリの情報を取得します。 -network … NIC (ネットワークアダプタ) の情報を取得します。全部。 -video … ディスプレイ デバイスの情報を取得します。接続モニタ全部。 -all … 上記の -disk ～ -video まで全部まとめてとってきます。
################################################## # Param ステートメント開始。 # [switch] が頭に付けられているのは、「スイッチ パラメータ」です。 # 値を指定しない、処理分岐用の引数などに用いられます。 # 通常の引数には [string] [int] など型を指定しておくことをお勧めします。 # # 注意 ※ # ・Param ステートメントはスクリプトの先頭に来る必要があります。 # ・コメントは Param ステートメントより前に記述することができます。 # ・関数の引数は "Param(" 以降に記述し、各引数は "," で区切ります。 # ・最後の引数の後には "," は使用せず、")" で閉じます。 ################################################## Param( [string]$computer=$env:computerName, [switch]$disk, [switch]$processor, [switch]$memory, [switch]$network, [switch]$video, [switch]$all ) # Param ステートメントここまで ###################
# エントリで使用できる関数を事前定義します。 Function Get-Disk($computer) { Write-Host "-------------------------------------" Write-Host "- ドライブのサイズ情報" Write-Host "-------------------------------------" $logicalDisk=(Get-WMIobject Win32_LogicalDisk -filter "DriveType=3") foreach ($disk in $logicalDisk) { Write-Host $disk.Deviceid "Drive Size = " $disk.Size } } Function Get-Processor($computer) { Write-Host "-------------------------------------" Write-Host "- CPU 情報" Write-Host "-------------------------------------" $processors = Get-WmiObject -class Win32_Processor -computername $computer foreach ($processor in $processors) { Write-Host "CPU Name = " $processor.Name "コア数 :" $processor.NumberOfLogicalProcessors } } Function Get-Memory($computer) { Write-Host "-------------------------------------" Write-Host "- 搭載メモリ情報" Write-Host "-------------------------------------" $memories = Get-WmiObject -class Win32_PhysicalMemory -computername $computer foreach ($memory in $memories) { Write-Host "メモリサイズ (Byte) " $memory.Capacity "メモリ区分 :" $memory.Description }
} Function Get-Network($computer) { Write-Host "-------------------------------------" Write-Host "- ネットワーク アダプタ情報" Write-Host "-------------------------------------" $adapters = Get-WmiObject -class Win32_NetworkAdapter -computername $computer foreach ($adapter in $adapters) { Write-Host $adapter.NetConnectionID $adapter.Description } } Function Get-Video($computer) { Write-Host "-------------------------------------" Write-Host "- ビデオカード情報" Write-Host "-------------------------------------" $videoControllers = Get-WmiObject -class Win32_VideoController -computername $computer foreach ($videoController in $videoControllers) { Write-Host $videoController.Description } }
############################################################### # *** スイッチ パラメータを解釈し、処理分岐をさせる関数 *** ############################################################### Function Get-CommandLineOptions { if($all) { Get-Disk($computer) Get-Processor($computer) Get-Memory($computer) Get-Network($computer) Get-Video($computer) exit } if($disk){Get-Disk($computer)} if($processor){Get-Processor($computer)} if($memory){Get-Memory($computer)} if($network){Get-Network($computer)} if($video){Get-Video($computer)} }
################################################################ # *** スクリプトのエントリ ポイントはここから *** ################################################################ # 実行環境チェック #"…現在ご利用の環境が仮想マシンか実機か確認しております。少々お待ちください…" #if((Get-WmiObject Win32_ComputerSystem).model -ne "virtual machine") #{ # $response = Read-Host -prompt "この環境は仮想マシンではありません。処理を続行しますか？ <y / n>" # if ($response -eq "n") { exit } #} #else #{ # $response = Read-Host -prompt "この環境は仮想マシンです。バックアップ取得を先にされる場合は n を、処理を続行する場合は y を押してください。 <y / n>" # if ($response -eq "n") { exit } #} # スイッチ パラメータの分岐と実行呼び出し Get-CommandLineOptions
d. 参考情報 作成したスクリプトをテストする方法はありますか http://technet.microsoft.com/ja-jp/scriptcenter/ee517335
Windows PowerShell スクリプトの処理速度を上げる方法はありますか http://technet.microsoft.com/ja-jp/scriptcenter/ee532494
Windows PowerShell: スクリプトでコマンドレットを記述する http://technet.microsoft.com/ja-jp/magazine/ff677563.aspx
では皆様ごきげんよう。
ういこう@PowerShell を腐女子的に見た場合（以下自粛）
みなさんごきげんよう。ういこです。今日はひな祭りです（2011/03/03 現在）が、大人の階段を登りきった私には関係ないですよ。 さて本日はそんな自虐的な 3x 歳の乙女心より .NET と VS2005 のライフサイクルの話をご紹介させていただきますね。
ILM 2007 FP1 は .NET Framework 2.0 です。ルール拡張の開発によく Visual Studio 2005 を使われているお客様もいらっしゃるかと思います。 直接 ILM 一家の守備範囲にかかわる話ではないのですが、ご参考になれば幸いです。 ちなみにライフサイクル（含サービスパック ライフサイクルポリシー）って何？！という方は、以下の記事をご参照いただいてから読み進めていただくとわかりやすいかもしれません。
[Windows 7 / Virtual PC] XP Mode のサポート期間（ライフサイクル）っていつまでなの？ http://blogs.technet.com/b/jpilmblg/archive/2009/12/16/windows-7-virtual-pc-xp-mode.aspx [Windows XP] サポートライフサイクル : 2009/04/14 メインサポート期間終了、延長サポートへ移行しました。ver2.0 (includes “XP Mode” on Win7) http://blogs.technet.com/b/jpilmblg/archive/2009/03/17/windows-xp-2009-04-14.aspx
新サポート ライフサイクル ポリシーを再確認しよう 2010 年 3 月(記事の時点では昨年)、.NET Framework のライフサイクルが改訂され、.NET Framework 3.0 以降は「インストールした先のマシンの Windows OS のシステムのサポート ライフサイクル」＝ 「.NET Framework のライフサイクル」になりました。このドキュメントに書いてある「コンポーネントとして扱い…」は、OS ("EULA に規定されている親製品") の構成要素（コンポーネント）の一部として解釈されるからおおもとの OS のライフサイクルに準拠することになりました、ってことなんですよね。
ただし、2.0 は従来通り .NET Framework 自体のライフサイクルのままなので、2011/4/12 にメインフェーズが終了し、それ以降は延長サポートフェーズになります。つまり、この記事は 2011/3/3 に書いていますが、来月 4 月に .NET Framework 2.0 のメインフェーズが終了してしまうことに注意が必要です。
さらに、.NET Framework 3.0 / 3.5 についても、サービスパック ライフサイクルのサポートが 2011/4/12 に節目を迎えます。NET Framework Version 3.0 RTM / 3.0 SP1 および 3.5 RTM は 2011 年 4 月 12 日までサポートされます。この日以降、サポートは終了します。2011 年 4 月 12 日より前に .NET Framework 3.5 SP1 に移行することを強くお勧めします。これ以降、何かあった場合サポートにお問い合わせいただいた際、.NET Framework 3.5 SP1 をベースとして修正モジュールが作成されることになります。つまり、修正モジュールをリクエスト頂き、リリースしたとしてもそのモジュールの適用前提が「すでに .NET Framework 3.5 SP1 が適用されている環境であること」になってしまうなど、これまでとは違う扱いになります。 (※)
(※) カスタム サポートなどをお持ちの方は一部扱いが異なる場合がありますので、ご契約をご確認ください。
上段がメインフェーズ終了日、下段 () つき日付は延長サポート終了日です。 http://support.microsoft.com/gp/lifeandotnet
上段がメインフェーズ終了日、下段 () つき日付は延長サポート終了日です。
http://support.microsoft.com/gp/lifeandotnet
Visual Studio 2005 につい��� Visual Studio 2005 シリーズも、順次 2011/04/12 にメインストリームが終了します。 これ以降たとえば障害と分かった場合でも延長サポートに入りますと修正プログラムの新規リクエストができなくなります。(※)
Visual Studio 2005 Professional Edition Visual Studio 2005 Service Pack 1 Visual Studio 2005 Standard Edition Visual Studio 2005 Standard Edition academic license Visual Studio 2005 Team Edition for Database Professionals (なぜかこれだけ 2012/04/10 メインストリーム終了) Visual Studio 2005 Team Edition for Software Architects Visual Studio 2005 Team Edition for Software Developers Visual Studio 2005 Team Edition for Software Testers Visual Studio 2005 Team Foundation Server Visual Studio 2005 Team Foundation Server Service Pack 1 Visual Studio 2005 Team Suite Visual Studio 2005 Team Test Load Agent Visual Studio 2005 Tools for the Microsoft Office System
※※※※※※ 以下は上記記事よりの抜粋です ※※※※※※
延長サポート期間に移行することによる変更内容 (1) 延長サポート期間に移行後に提供されなくなるサービス
・無償サポート ・セキュリティ修正以外の修正パッチの作成
(2) 延長サポート期間に移行後に継続して提供されるサービス
・有償サポート ・セキュリティ修正パッチの作成と提供
…要は延長サポートに入ってしまうと、調査の結果障害と判明しても、修正モジュールはセキュリティにかかわること以外提供されず、かつインシデント / レイバーは無条件に消費されてしまうということです。
※注意点※ 延長サポートを受けるには、サポート対象となっているサービスパックが適用されている必要があります。サービスパック別のサポート期間についてはこちらでご確認ください。
サポート対象サービス パック http://support.microsoft.com/default.aspx/gp/lifesupsps/ja
製品サポート ライフ サイクルってそもそも何？ マイクロソフトでは、ビジネス製品および開発用製品に於いて、最短でも 10 年間 (※) という一定期間の製品サポートを提供しています。この期間を製品サポートライフサイクルとして定義しています。 (※) 内訳はメインストリームサポート フェーズ 5 年間 ＋ 延長サポート フェーズ 5 年間で計 10 年
メインストリーム サポート フェーズとそれ以外の違いって？ -a. メインストリーム サポート メインストリーム サポート フェーズは、製品サポート ライフ サイクルの最初のフェーズであり、以下のサポートが含まれます。
・有償サポート ・無償サポート ・時間制サポート ・その他サポート - セキュリティ更新プログラム サポート (セキュリティ更新プログラムの提供) - セキュリティ関連以外の修正プログラム、仕様変更の新規作成リクエスト受付 (※) - オンライン セルフ ヘルプ サポート
(※) リクエストはビジネス上のインパクトや、修正後の副作用、リスクなどを総合的に判断した上で受諾可否が決められます。メインストリーム サポート フェーズ内にリクエストを受け付けたとしても、場合によっては修正、変更が出来ないという結論になる場合があります。
-b. 延長サポート 延長サポートは、ビジネス製品および開発用製品に対して、メインストリーム サポートに続く、次のフェーズになります。提供されるサポートは下記 2 点です。
・ 有償サポート (インシデント制、時間制) ・ セキュリティ更新プログラム サポート (無償提供)
延長サポートフェーズに含まれないサポートとしては以下のとおりとなります。
・ 無償サポート ・ セキュリティ関連以外の修正プログラム ・ セキュリティ関連以外の修正プログラム、仕様変更の新規作成リクエスト受付 ・ オンライン セルフ ヘルプ サポート
メインストリーム サポート フェーズ内の製品についてお問い合わせを頂いた場合、調査の結果製品の障害である場合、お問い合わせのインシデント（※1）およびレイバー（※2）は消費対象もしくは課金対象となります。 要はセキュリティ更新プログラム提供以外、基本有償であるということになります。また、コンシューマ製品、 ハードウェア製品、およびマルチメディア製品には延長サポートは提供されません。
(※1) お問い合わせの権利、一問 = 一インシデントが消費されます。バスの回数券みたいなものです (※2) プレミア サポート、アドバイザリー サービスなどの「時間制」サービスでは、デバッグ、切り分け作業の代行など上位のサポート内容が提供されますが、課金単位がエンジニアの作業時間単位となります。つまり、一時間 X 万円 x 作業時間 が請求金額になります。ただしプレミアの一部契約など、カスタム約款が提供されている場合は契約にのっとった対応となる可能性があります。ご利用の際は、約款をご確認いただくことをお勧めします。
-c. オンライン セルフ ヘルプ サポート オンライン セルフ ヘルプ サポートは、全製品に対して提供される、オンラインのサポート技術情報です。延長サポートフェーズも終了した製品に対しても、その後、最短 1 年間提供されます。サポート技術情報の高度な検索や FAQ 、トラブルシューティング ツール、その他のリソースを利用して、一般的な問題を解決することができます。
-d. 製品のライフサイクル確認方法 サポート ライフ サイクルを確認するには、サポートライフサイクル検索のページで、製品名の一部をキーワードとして検索してみてください。
マイクロソフト サポートライフサイクル全般 http://support.microsoft.com/lifecycle
マイクロソフト プロダクト サポートライフサイクル検索 http://support.microsoft.com/lifecycle/search/
プロダクトサポートライフサイクル－製品一覧 http://support.microsoft.com/gp/lifeselect
まとめ ・.NET Framework 2.0 のメインストリームは 2011/04/12 に終了 ・Visual Studio 2005 シリーズも、順次 2011/04/12 にメインストリームが終了 ・.NET Framework 3.0 以降は「インストールした先のマシンの Windows OS のシステムのサポート ライフサイクル」＝ 「.NET Framework のライフサイクル」 ・NET Framework Version 3.0 RTM / 3.0 SP1 および 3.5 RTM は 2011 年 4 月 12 日まで。この日以降のサポート対象は .NET Framework 3.5 SP1 が対象になる
ういこう@Visual Studio .NET 2002 の年に生まれた息子は早 9 歳になりますよ…
みなさんごきげんよう。ういこです。私事ですが顔面半分にビッシリと赤い発疹がでて、洒落じゃなく顔面崩壊してますが皆様はいかがお過ごしでしょうか。本日は「外部サービスに依存した処理（しかも WMI みたいな重い処理なんてとくに）は PC 起動直後のログオン時に動作するプログラム（ログオンスクリプトやサービス アプリケーション）内で使うこととあまり相性が良くない」というお話です。
今日、お隣のチームさんからスクリプトである機能を自動化したいとご相談をを受けまして、要件を見たら、なーんだ WMI つかえば簡単じゃないのよ奥様？これなら有りモノで何とかなるんじゃないの？WMI ってほんと調理に便利よね★ とふっと思ったんですが、WMI って RPC に依存しているんですよね。
ということは…PC 起動 → ログオン直後にスクリプト実行というタイミングでは、WMI サービス起動のタイミングがログオンスクリプトの動作タイミングに間に合わないことがあり得るわけです。 最近のマシンはメモリもハードディスクも脳みそ (CPU) も充実したリア充が多いので顕在化しないで済むことがほとんどだと思います。しかし、有りモノのマシンだってまだまだ現役！という環境とか、大量のサービスが動作するような環境では、この「起動タイミングによって残念」という状況も起こりえてしまいます。その状況をクリティカルととらえるか、あるいはまた動作させればいいじゃないか、で済むかはそれぞれのシステム要件次第ですが、おおむね起きることはないから大丈夫ということでも、ミッションクリティカルなシステム上で動かす場合や、サービス アプリケーションの場合などは、避けるべきと私は考えます。もし、今ログオン時に動作させるプログラムを設計されているならば、ぜひこの点について考慮の上プログラム設計とシステム要件を検討されればと思います。
今回は、デベロッパーサポート担当らしく、サービス アプリケーション作成を例にとりご案内したいと思います。
[1] サービスの起動順序は必ずしも人間の期待通りになるとは限らない あるサービスに依存しているサービスが自動起動になっている場合、依存先のサービスがあがったあとに自身のサービスが起動される動きになります。たとえば、WMI の場合、後述のように RPC に依存していることがわかります。さらに、RPC を見ると、RPC 自身も別のサービスに依存しています。
では、サービスの起動順序はどのようにマネージされているかですが、自動起動となっているサービスは、HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List に格納されている順にフェーズ単位で起動されていきます。このレジストリ値に格納される順番がイコール起動順序となり、この��番で起動されていきます。よってレジストリを変更する事によって、起動順序を変更する事は可能です。 しかし、サービスの起動順序の変更をするということは、数十以上ある全サービスの起動順序に大きく影響を及ぼす可能性があるということを意識する必要があります。基本的にはサービス起動順序を変更することはお勧めしません。どうしても変更することが必要である場合は、可能な限り考えうる「重い」環境でじっくりと検証を実施することをお勧めいたします。また、可能であればですがそうしたサービスを用いない API などで処理ができないか検討することもよい方法です。
[2] 問題としてよくあげられる例 - サービス アプリケーションを作ったが動かない これまで挙げられた例としては、ログオン スクリプトなどのほか、サービス アプリケーションを作成していて、このサービスの起動時に依存先サービスを使った処理を実施していると制御が返ってこない、または極端にレスポンスが悪くなることがあるというものがあります。現象の出方はタイミングによるので様々ですが、例えば処理が遅い、依存サービスのタイムアウトに間に合わず起動失敗するなどの状況などがあります。これらの条件を満たし、かつイベント ID 7009 などがイベントログに記録されている場合はこれにあたる可能性が高いです。
サービスの所属グループはどこ？サービスの依存関係は変更できるの？ 通常、サービスの起動および停止順序は、サービス単体の依存関係、サービスグループの依存関係で制御されています。サービスグループの起動される順番は下記のレジストリキーにおける List 値により確認する事が出来ます。 なお、グループに所属していないサービスもありますが、これは順番を変えることはできません。
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \ServiceGroupOrder
どのサービスがどのグループに所属しているかは、[管理ツール] - [コンピュータの管理] - [サービス] で、各サービスをダブルクリックすることで 確認できます。
図1 : WMI (Windows Management Instrumentation) のプロパティより。RPC に依存している状況がわかる。
図 2 : RPC (Remote Procedure Call) のプロパティ。さらに DCOM 関連サービスなどに依存している。ちなみにここからも、WMI が RPC の依存している DCOM にさらに依存していることが見て取れる。
また、依存関係にあるサービスも確認することも、依存関係を設定することも、下記のレジストリ DependOnService から可能です。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<自分の作っているサービス アプリケーション名>
1. [Start] - [Run] をクリックします。 2. 名前に "regedit" と入力し、レジストリ エディタを起動します。 3. [編集] メニューの [値の追加] をクリックして、次の情報を入力します。
Value Name : DependOnService Value Type : REG_MULTI_SZ Data : 依存するサービス名
イベント ID 7009 について イベント ID 7009 は、サービス プロセスの管理およびサービス プロセスの起動や終了を制御する Service Control Manager (SCM) がサービスを起動させる際のタイムアウト値 (既定では 30000 ミリ秒) を超えた場合に記録されます。つまり、サービスから SCM に対して、"サービスが開始した"（SERVICE_RUNNING）ことを通知していない場合に、ID 7009 が記録されます。障害ではない状況でもこのイベントは発生しうる可能性はあります。例えば、Microsoft Update による修正プログラム適用やデバイス ドライバの更新などが発生した場合、システム内部情報の更新や整合性を保つための処理が行われることがあり、適用後の初回起動時に、通常の再起動時とは異なり、サービスの開始に時間を要する結果発生する場合などもあります。これは何かサービスを利用するアプリケーション (あるいはサービス) を実装する際、この現象が起きうる可能性を考慮し設計する必要があるということを意味します。
レジストリによる SCM 遅延時間変更については以下のサポート技術情報をご覧いただくともっとわかりやすいと思います。
Windows Server 2003 でサービスが開始されずイベント 7000 および 7011 が記録される http://support.microsoft.com/kb/922918
変更方法 :
1. [Start] - [Run] をクリックします。 2. 名前に "regedit" と入力し、レジストリ エディタを起動します。 3. 下記のパスのキーをアクティブにし、値を追加します。下記を右クリックし、[NEW] - [DWORD Value] をクリックします。
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control
4. 新しく作成された値を下記のように設定します。
Name : ServicesPipeTimeout
例：60秒に設定する場合(Decimal の場合はミリ秒で設定)
60000 (Decimal)
[3] 回避策 : サービス アプリケーションの実装で回避する WMI に限らずサービス アプリケーションで自身のサービス起動時に 重い処理を実施する必要がある場合は、サービスのメイン スレッドとは別にワーカー スレッドを起動させ、ワーカー スレッド内で時間を要する可能性がある処理を実施し、メイン スレッドで Service Control Manager (SCM) に対し SERVICE_RUNNING ステータス通知を行う実装が一般的です。あるいは上記レジストリ設定あるいはご自身で作成されているサービスのスタートアップの起動の種類を遅延にしてタイムアウトの間隔を変更しても、状況によっては設定した値を上回る時間を処理に要することになる可能性などもあるため、やはりワーカースレッド内で時間を要する処理を実施頂く設計にすることが最も確実なリスクヘッジの手段であるといえます。 特に、WMI は非常に重い処理であるため、特にシステム負荷が高い起動時に利用した場合特に遅くなる可能性は正直あります。もともと WMI 自体がそもそも完了までに時間がかかる可能性のある処理であるため、処理時間を短縮することは非常に困難です。
上述の SCM がサービスを監視する際のタイムアウト時間内に SERVICE_RUNNING ステータスを通知されない場合は ID 7009 などが発生しますので、SCM からこのサービスに対し停止リクエストが送信されるなどのリスクが発生します。 よって、完了までにどのぐらいの時間を要するか判断ができない処理を、SERVICE_RUNNING ステータス通知を行う前の段階で実行するのではなく、サービスが SERVICE_RUNNING ステータスを通知した後でワーカスレッドを起動し、このワーカスレッド内で 時間のかかることが予想される処理を実行していただくことが適切となります。これにより、上述のようにシステム コンディションによって時間が変動しうる可能性がある機能に依存するサービスであっても安定して動作させることが期待できます。
How to debug Windows services http://support.microsoft.com/default.aspx?scid=824344
[4] まとめ ・サービスの起動および停止順序は、サービス単体の依存関係、サービスグループの依存関係で制御されている ・サービスが自動起動の際はレジストリに追加された順番を起動順序として順次実行されていく ・依存関係先サービスが多いサービスの処理を自身のプログラム中で、PC 起動直後やログオン時に参照するような処理を実施している場合は起動タイミングによっては参照先サービス起動が間に合わず自身のプログラムが影響され動作しない場合がある ・外部サービスの処理を参照するような処理はせず、API などで代替できる処理がないか確認することも有効手段の一つ ・やむを得ず自身のサービスから外部サービスの処理を参照する必要がある場合は、サービスが SERVICE_RUNNING ステータスを通知した後でワーカスレッドを起動し、ワーカスレッド内で時間のかかることが予想される処理を実行することが安全な設計となる
ういこう＠呪われてる？心当たりありすぎてわからないです。
皆さんごきげんよう。ういこです。今日はイベントログのとり方でよくある問題とその対処案についてのお話です。
運用管理をしていてあるある！なニーズとして、イベントログを定期的に保存して、出来ればアーカイブして保存しておきたいなんてことがあると思います。しかもバッチ処理にして、タスク スケジューラなんかで人間様がいなくてもサーバ内の小人さん動かして定期的に保存させちゃおうとか。そんなニーズ、ありませんか。
では、全国津々浦々のイベントログ大好き管理者様はどのようにしてイベントログの取得をされていますか。問い合わせに来るものを見る限りでは、WMI の Win32_NTLogEvent 、Win32_NTEventLog 、Win32_NTEventLogFile とか、その辺を使っていらっしゃる方が多い印象です。それも、VBScript が圧倒的に多く、PowerShell による対処などは殆どお問い合わせとしてあがってきていません。ただ、私は開発サポート部門ですので、OS の基盤（プラットフォーム）サポート部門では違うのかもしれませんね。
ではなぜ WMI が多く使われているのか。非常にカンタンに使うことが出来、かつ VBScript からも .NET Framework ベースのプログラムからもアンマネージ (C++) からも呼び出しやすいという、手軽さが訴求しているのだと思います。しかし、以前から WMI についてはカンタンな反面、RPC 、DCOM などに依存している、内部処理が複雑で遅い、重いといった不便な点についてご紹介してきたように、やはりすべていいことずくめというわけにはいきません。 特に問題なのは、WMI は内部でデータを扱うために持っている領域のサイズが少なく、ある程度サイズ拡張は出来るものの、数ギガバイトといった大容量のデータを取り扱う際にエラーが発生することが多いという点です。イベントログは扱うデータ量が半端なく大きいことが少なくないため、この「内部データ領域足りません問題」に直面することが非常に多いシナリオです。
WMI によるイベントログ保存時に発生しやすい問題 監査ログなどを仕掛けている場合、セキュリティ イベントログの肥大化が問題になることが多くあると思います。こうしたログに対し、WMI でイベントを取得しようとして以下のエラーが発生することが多くあります。また、これらのエラーは必ず発生するのではなく、WBEM_E_QUOTA_VIOLATION が発生したと思えば、次に取得処理を実行すると今度は WBEM_E_OUT_OF_MEMORY が発生するなど、揺らぎが良く見られます。
(※ まれに 0x80041001 WBEM_E_FAILED という形で異常終了することもあり)
調整方法としては、WQL 文で取得してくるイベントログの時間帯を指定することで、一回に扱うデータサイズを減らすということしかありません。ただ、時間を指定しても、その時間帯にたまたまアクセスが集中し、ファイル監査のログが大量発生した場合などは、データサイズがスパイクするため結果としてエラーが発生する可能性があることは避けられません。
なぜこうしたエラーが起きるのか 0x8004106C (WBEM_E_QUOTA_VIOLATION) は、WMI サービスにより消費されるメモリが割り当てられたメモリの制限に達したことを意味します。また、このエラーが発生する状況下では、同じクエリを同じデータストアに対して実施した場合であってもリソースを多く消費しシステムが不安定になることを防ぐために処理をキャンセルすることがあり、その場合に 0x80041032 (WBEM_E_CALL_CANCELLED) をスローする可能性もあります。いずれも、WMI クライアントの応答が遅い場合、クライアントに返すデータを保存するバッファが足りなくなる状況を指します。よって、あらかじめ大容量のデータを扱うことが予想される際は、WMI のメモリの仕組みを考慮したうえで WMI を採用するか慎重に検討する必要があるということになります。
WMI のクエリの結果の保存に使うメモリ量に関しては WMI 自身が使用量を確認していますが、WMI を実行するプロセス全体のメモリ領域も考慮する必要があります。
a. 実行結果など、WMI 自身が使用量を管理するメモリ領域 b. OS が管理する a を含むプロセス全体のメモリ領域
a. に関しては、レジストリである程度拡張することは出来ますが、b. の領域はレジストリ設定は影響しません。 0x8004106C (WBEM_E_QUOTA_VIOLATION) は、WMI サービスにより消費されるメモリが制限に達したことを意味しており、上記の例では、b. にあたります。 レジストリの設定は、上記 a. の結果セットの保存領域のサイズに影響するものとなります。
一般的にこうした状況を回避するために下記フラグを設定してメモリ領域内のインデックスを扱わせないことで若干のメモリ領域に余裕をあけることはできますが、フラグ設定も取り扱いデータ全体のインデックス領域を取得しないだけですので、結局扱うメモリ量を劇的に減らすことはできません。よって、元々考慮された値以上のデータ全体からクエリするような大容量データを扱う場合は残念ながらインデックス領域を減らしても余りあるデータ量になってしまう場合はフラグを設定しても効果はありません。
・WBEM_FLAG_FORWARD_ONLY クエリ結果セットの列挙を前方方向のみに制限することで、メモリ消費を抑える事ができます。ただ、もともと扱う内部データ領域のサイズを変えることはできないため、大容量イベントログなどの巨大データを取り扱う際は効果がないことがほとんどです。
・WBEM_FLAG_RETURN_IMMEDIATELY メソッド (ExecQuery) 実行後でも必要に応じて Background でオブジェクトの取得を試みる事ができるようになるため、大量のオブジェクトの取得も可能になる場合があります。ただし、あまりにも大量のデータの場合は効果がありません。
対処方法 問題の対処としては、以下の二つが挙げられます。
・wevtutil.exe を使う ・新しくなった EventLog API を使う
.NET Framework にて、内部的に EventLog API を使うクラスを扱えますので、PowerShell で使用することができます。ただ、VBScript でなんとかしたいという場合はこれでは対処ができません。そうした場合は、wevtutil.exe をスクリプト内でコールすることで対処することができます。しかも高速です。
' <<< サンプルここから Dim strDate Dim strDate2
strDate = Now
Set objShell = WScript.CreateObject("WScript.Shell")
if Len(strDate) <= 10 Then ' VBScript Now() 関数の制限。0 時ジャストの場合、時間が Drop されることに対する対策 strDate2 = strDate & " " & "_0時00分00秒" Else strDate2 = FormatDateTime (strDate,1) & "_" & Right("0" & Hour(strDate) , 2) & "時" & Right("0" & Minute(strDate) , 2) & "分" & Right("0" & Second(strDate) , 2)& "秒" End If
' *** Debug ' WScript.Echo strDate2 ' *** 引数の作成 teststr = "wevtutil epl Security" & " " & strDate2 & ".evtx"
Set objExec = objShell.Exec(teststr) Do While objExec.Status = 0 WScript.Sleep 1000 ' <<< 処理終了まで待機。実際のシステム上での動作に合わせて調整ください Loop ret = objExec.ExitCode if ret = 0 Then WScript.Echo "処理が成功しました" ElseIf ret = 1 Then WScript.Echo "処理が失敗しました" Else WScript.Echo "予期せぬエラーが発生しました : コード " & ret End If ' <<< サンプルここまで
wevtutil について wevtutil は、テキスト、バイナリ、XML で保存ができます。この保存形式によって、以下のようにファイルサイズに影響が発生します。
・フォーマット形式 : テキストの場合 wevtutil qe Security /f:TEXT > mylog.txt -> バイナリ evtx 3.0 GB に対し txt 3.6 GB まで増加
・XML 形式保存の場合 wevtutil qe Security /f:XML > hoge.xml -> バイナリ evtx 3.0 GB に対し XML 4.8 GB まで増加
バイナリでそのまま保存いただいたほうがよいかもしれません。なお、以下のように指定することで、時間指定でのアーカイブを実行することも出来ます。(情報提供くださった M 様、ありがとうございました)
上記例では、2/14 日の 11:00 から、2/14 日の 13 時までの間を指定しています。
参考資料 Article ID: 957662 - Last Review: October 29, 2010 - Revision: 4.0 Recommended settings for event log sizes in Windows Server 2003, Windows XP, Windows Server 2008 and Windows Vista http://support.microsoft.com/kb/957662/en-us (※ Windows Server 2008 / Vista までの記述ですが、Windows 7 / Windows Server 2008 R2 も対象になります。)
[WMI基礎] Remote で動作する仕組み + ExecQuery と ExecQueryAsync の違い ～ “wbemFlagForwardOnly” は Count プロパティが取れない ～ http://blogs.technet.com/b/jpilmblg/archive/2010/03/29/wmi-remote-execquery-execqueryasync-wbemflagforwardonly-count.aspx
Memory and Handle Quotas in the WMI Provider Service http://blogs.technet.com/b/askperf/archive/2008/09/16/memory-and-handle-quotas-in-the-wmi-provider-service.aspx
[Info] VBScript / ADO RecordSet : 時刻を文字列として扱う際 “0:00:00” の場合は文字列が Drop されてしまう http://blogs.technet.com/b/jpilmblg/archive/2010/09/06/info-vbscript-ado-recordset-0-00-00-drop.aspx (※ Now() 関数の制限。0 時ジャストの場合、時間が Drop されることについて)
ういこう＠Dance Evolution 楽しいですよ。
みなさんごきげんよう。ういこうです。もう明日から二月ですが本年もよろしくお願いします。 今年の一本目はみんな大好き PCNS についてです。といっても、PowerChute Network Shutdown ではないですよ。Password Change Notification Service ですよ。 PCNS についての詳しい話は英語でも構わなければ結構あるもんですが、たとえばこれから提案をしに行こうと思っていらっしゃる方などが知りたいようなまとまった情報はあまりないという噂を聞きましたので、ざっくりとまとめてみました。 後日、図などを加筆するかもしれません。
【今日のお題】 PCNS (Password Change Notification Service) の動作条件や注意事項などについて
-a. PCNS の動作条件 PCNS が正しく動作するための前提条件は以下の四つがあります。これらすべての条件を満たしている必要があります。
1. パスワード更新に際し一定のプロトコルが使用可能であり、認証動作が成功することが保証されていること 2. Kerberos 相互領域認証が使用可能であること 3. RPC / DCOM の構成が適切になされていること 4. 適切にポートが構成されていること
1. パスワード更新に際し一定のプロトコルが使用可能であり、認証動作が成功することが保証されていること こちらは、ILM / FIM に限った話ではありません。 PCNS は、パスワード更新をドメイン コントローラで検知して、それを FIM サービスに通知します。パスワード更新がされたということを FIM が受け取ると、FIM はパスワードが変わった場合にそのパスワードを AD と同様に変更させたいデータストア（たとえば Oracle 、Lotus Notes など）に対し右から左に受け流してやります。 Oracle とか Lotus Notes など、パスワード変更通知を FIM から受け取ると、自身の該当ユーザのパスワードに変更されたものを反映します。 ということは、つまり、PCNS とは、AD 起点の、Active Directory ありきのシナリオということに注意していただく必要があります。AD は抜きでパスワード同期をしたいというシナリオは、残念ながら仕組み上実現できません。
よって、この話は Windows ドメインに対するパスワード更新について必要な条件を満たしている環境であることが前提になります。プロトコル、認証動作のリストにつきましては技術情報 264480 にて詳細な説明がなされております。この技術情報は、Windows 2000 をターゲットに記載されていますが、Windows Server 2003 以降にも当てはまる概念となります。
Description of password-change protocols in Windows 2000 http://support.microsoft.com/kb/264480/en-us ※ FIM サーバ - 同期先ドメインの DC 間で上記の動作が保障されている必要があります
2. Kerberos 相互領域認証が使用可能であること ID 管理製品 (FIM、ILM など) に対してパスワードの変更を通知する際PCNS の SPN が認識される必要があります。このためには、ID 管理製品が存在するドメインで、PCNS のサービスアカウントが認証される必要があります。この際に使われる認証は Kerberos 相互領域認証 で行われます。フォレスト間の同期などシステムの拡張を行う際は、注意が必要です。相互認証を可能にするには、PCNS のあるフォレストと、ID 管理製品の構成されているフォレスト間でフォレスト間信頼がなされていることが必要となります。信頼関係がない場合、ターゲット名が識別できずエラーが発生します。Kerberos 認証を実現するには、互いのフォレスト機能レベルが Windows 2003 である必要があります。また、この場合 DNS 名に基づく信頼関係が結ばれますため各 DNS が、フォレスト境界を越えて、名前解決が出来るよう正しく設定されている必要があります。(後述 “参考 : [PCNS] ILM 連携の際に使われるポートについて” も参照ください)
3. RPC / DCOM の構成が適切になされていること PCNS の起動アカウントに、DCOM 経由で FIM サーバに接続し、FIM Sync サービスを呼び出す権利が設定されている必要があります。RPC と DCOM Server / Client の通信が DC - FIM 間で疎通出来ているか確認してください。 4. 適切にポートが構成されていること 各 Management Agent および、パスワード同期に必要なプロトコルおよびポートについてTechnet 上のドキュメントは、以下の URL をご参考下さい。
Management Agent Communication Ports, Rights, and Permissions http://technet.microsoft.com/en-us/library/cc720599(WS.10).aspx
ホワイトペーパーにつきましては、以下のサイトより、MIIS_Ports_Rights_and_Permissions.doc をダウンロードいただきご確認いただけます。FIM につきましても同様となりますので、ご確認ください。 http://www.microsoft.com/downloads/details.aspx?FamilyID=d7894cc9-eeeb-40d9-8f5f-573050624f67&DisplayLang=en
上記より抜粋した Active Directory Management Agent のポートは以下の通りとなります。
* Active Directory Management Agent について Service Protocol Port LDAP TCP/UDP 389 Kerberos TCP/UDP 88 DNS TCP/UDP 53 Kerberos Change Password UDP(*) 464 (*) Kerberos Change Password は、UDP での接続が不可能な場合に、TCP にて要求が行われます。そのため、UDP が使用可能であれば TCP は不要となりますため、ドキュメント上は上記記載となっています。 * Password Synchronization Port Settings RPC Endpoint mapper TCP 135 Dynamic RPC ports (PCNS) TCP 5000 - 5100 Dynamic RPC ports TCP 57500 - 57520 (management agent for Active Directory)
* Active Directory Management Agent について
Service Protocol Port LDAP TCP/UDP 389 Kerberos TCP/UDP 88 DNS TCP/UDP 53 Kerberos Change Password UDP(*) 464
(*) Kerberos Change Password は、UDP での接続が不可能な場合に、TCP にて要求が行われます。そのため、UDP が使用可能であれば TCP は不要となりますため、ドキュメント上は上記記載となっています。
* Password Synchronization Port Settings RPC Endpoint mapper TCP 135 Dynamic RPC ports (PCNS) TCP 5000 - 5100 Dynamic RPC ports TCP 57500 - 57520 (management agent for Active Directory)
参考 : [PCNS] ILM 連携の際に使われるポートについて http://blogs.technet.com/b/jpilmblg/archive/2009/02/17/pcns-ilm.aspx
-b. PCNS で良くある問題について PCNS 関連でよくあるお問い合わせと各注意点についてまとめました。
1. FIM サーバの OS 再起動直後はパスワード同期が失敗することがある 2. "Kerberos-no-logon-server" が発生することがある 3. パスワード管理のエクステンションではロギングを行うと例外が発生するので Visual Studio でデバッグする必要がある
1. について パスワード通知動作の初回は、通知先の FIM に対して PCNS の認証が発生します。しかしながら、パスワード変更はドメイン コントローラのパスワード フィルタによるものであり、PCNS の動作とは別の動作となるため PCNS の FIM サーバの起動状態に関わらず要求は発生してしまいます。 PCNS の初回認証が完遂するまでの間隔は、その時点のシステムのコンディションに影響されますが、一般的に PCNS サービスは遅延起動となるため、パスワード変更が出来る状態になるまで 30 秒 ～ 数分程度要することが少なくありません。 そのため、たとえば PCNS の設定で リトライ回数が 1、リトライ間隔が 10 というように PCNS 起動中に来た要求が失敗してもリトライまで十分余裕がない構成などの場合は、再度パスワード変更通知を試行しても起動が完了していないためこの時点においても失敗してしまいます。結果として PCNS の通知は失敗とみなされることになります。
ただし、ネットワークのトラフィック、システム上のサービス、メモリの使用状況などその時々の FIM サーバのコンディションによって認証動作有効になるまでの期間はある程度幅がでるものであると見られます。それぞれ実際の運用状況、環境に合わせてリトライ回数はご検討ください。
2. について "Kerberos-no-logon-server" 発生要因としては、FIM はパスワード設定を行うために、Kerberos Change Password を使って要求を行いますが、この要求が失敗した場合や、不通となった場合に "Kerberos-no-logon-server" のエラーが発生します。過去いくつかこのエラーが報告されていますが、過去の事例からは、本エラーの発生要因はほぼネットワークに起因するという結果となっております。該当エラー時の直接要因となったネットワークトラブルは以下のようなものがありました。
a) FIM サーバーが、Active Directory ドメインについて名前解決が行えていない (SRV レコードを含め、DNS の環境見直しを実施いただき改善) b) Firewall により、UDP/TCP 464 (Kerberos Change Password) がフィルタされており、パスワード変更要求が Active Directory へ届いていない (Firewallの見直しを実施いただき改善) c) Active Directory から、UDP 464 (Kerberos Change Password) からの応答が、FIM サーバーに届く前に、伝送が不安定となったためにパケットロスが発生した。(この場合は、パスワード設定は完了していたがエラーが表示される場合となります)
特に、同期対象が国外拠点などの場合はネットワークの伝送状況が不安定になり、その結果問題が発生する事例が複数ございますので、サーバの拠点についても事前に確認を行って頂くのをお勧めいたします。
3. について Password Management 関連のエクステンションでは、ロギングを実装するとセキュリティ上、例外が発生しますので Visual Studio のデバッグ実行で状況の確認をすることをお勧めいたします。 ****************
それではみなさんごきげんよう。
ういこう＠少々事情がございまして、ブログ継続が難しくなってまいりました…。
平素より弊社サポート サービスをご愛顧くださいましてありがとうございます。本日は年末年始の弊社サポートの予定についてのお知らせです。 今年も早いもので年末です。先生走ると書いて師走です。その割に 15 度とか気温が高くて師走感に欠ける感じですね。地球大丈夫でしょうか。
さて地球も大事ですが、まずは目の前のプロジェクトが大事ですよね。毎年の傾向として、年末はお問い合わせが非常に多くなりますので、早めに対応を迫られていらっしゃるお客様は、前倒しでお問い合わせ頂くことをお勧めいたします。
弊社では、年末年始の下記の期間に無償および有償電話サポート窓口を休業致します。 プレミアサポート、プロフェッショナルサポートも休業いたします。 ご迷惑をお掛け致しますが、何卒ご理解の程お願い申し上げます。 以下は平日のみサポートを提供している製品・土日サポート対応製品共通のスケジュールになります。(後述年末年始休業対象窓口を参照ください。XBOX はXBox.xom / サポートトップで別途ご確認をお願いいたします。)
月曜日 ～ 金曜日および土日サポート提供窓口およびパートナー様向けサポート (パートナー ビジネス支援サービスなど) 共通
(★) 終日休業 (※) 上記期間内もプレミアサポート、プロフェッショナルサポートの緊急案件 (Severity A) につきましては対応させていただきます。
年末年始休業対象窓口
参考情報
カスタマー サービス & サポートお問い合わせ窓口休業のお知らせ http://www.microsoft.com/japan/customer/holiday/ マイクロソフト サポート オンライン 電話サポート窓口休業予定のお知らせ http://support.microsoft.com/gp/Holiday
今年は ID 管理製品は、FIM が出てなかなかエキサイティングでした。日の当たらないマイナーと言われるチームのわれわれですが、来年も変わらぬご愛顧をどうぞよろしくお願いいたします。
(ILM/FIM Support Team – Dec 06, 2010)
みなさんごきげんよう。ういこです。 今日は Windows XP における FIM 2010 セルフ サービス パスワード リセット クライアントとほかにカスタム GINA を使うアプリケーションは共存できないというお話しです。なお、Windows Vista 以降は GINA モデルではないので、複数の認証プロバイダを登録することができます。
カスタム GINA って何？二つ以上登録できるの？ さて、いきなりタイトルにもある "カスタム GINA" とは何かですが、これはすごく簡単にいうと OS にログオンする際に Ctrl + Alt + Del でダイアログ ボックスを表示させる仕組みです。ただし、この仕組みは Windows XP までであり、Windows Vista 以降の OS では後述の認証プロバイダと呼ばれる機構に変わっています。
図 : WinXP の GINA (こっちは既定) と Windows 7 の認証プロバイダ
この仕組みを行うモジュールを GINA (ジーナ、Graphical Identification and Authentication の略) といいます。 GINA はマイクロソフト以外のサードパーティのアプリケーションでも拡張することができます。このカスタマイズされた GINA を「カスタム GINA」と言います。この言葉は、サポート技術情報でもよく使われているのを見ますね。カスタム GINA は所定のレジストリにモジュール名を登録することで有効になります。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\
この値は OS の初期インストール状態では表示されません。 この状態の OS 内部では、Msgina.dll が既定の GINA モジュールと見なされます。カスタム GINA を使うサードパーティ製品は、このwinlogonキーを修正してGinaDll値を追加します。
FIM のセルフ パスワード リセットも、GINA や Vista 以降であれば認証プロバイダを拡張してカスタマイズすることで、ログオンしてない状態なのに AD にアクセスして自分のアカウントのパスワードをリセットすることができるようにしています。つまり、カスタム GINA を使うということです。
では、FIM 2010 セルフ サービス パスワード リセットを入れたいクライアントに、さらにカスタム GINA を使うアプリケーションを入れる必要がある場合はどうなるか。残念ながら、カスタム GINA は一つしか登録できません。よって、FIM 2010 セルフ サービス パスワード リセットを入れるか、もう一つのカスタム GINA を使うアプリケーションを入れるかどちらのプログラムを入れるかあらかじめ選択頂かなくてはいけないということになります。 これは、Windows XP までの Windows OS の設計に起因する制限事項であり、FIM 2010 セルフ サービス パスワード リセットに限定された話ではありません。
Windows Vista 以降は複数設定できる (認証プロバイダ) Windows Vista / Windows 7 以降のクライアントの場合は GINA に代わる新しい資格情報プロバイダ (CredentialProvider) の仕組みに変更されています。ログオン時は Logonui.exe というプロセスが起動され、以下のレジストリ キーを参照します。
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers
Logonui は、複数の CredentialProvider を同時にホストすることができます。そのため、資格情報をログイン時に操作するようなアプリケーションを複数必要とする要件のシステムの場合は Windows Vista / Windows 7 に移行いただくことで対応可能になる可能性があります。ただし、CredentialProvider の作りによっては複数動作が出来ない場合がありますので、実際に構成検証いただくことをお勧めいたします。
カスタム GINA を使うアプリケーションと FIM 2010 セルフ サービス パスワード リセットを一緒に入れたらどうなるか 上記の制限事項のため、影響を受ける可能性のあるシナリオとしては以下のようなものがあります。 ※実際には、各アプリケーションの導入の設計はそれぞれ違うので、実際の結果はそれぞれ異なるものになる可能性があります。
・FIM コンポーネントをインストールした後にカスタム GINA アプリケーションをインストールした場合 FIM パスワード リセット機能をログオン画面で使えなくなる可能性があります。 ・FIM コンポーネントをインストールする前にカスタム GINA アプリケーションが既にインストールされている場合 別のカスタム GINA アプリケーションがログオン画面で使えなくなります。
・FIM コンポーネントをインストールした後にカスタム GINA アプリケーションをインストールした場合 FIM パスワード リセット機能をログオン画面で使えなくなる可能性があります。
・FIM コンポーネントをインストールする前にカスタム GINA アプリケーションが既にインストールされている場合 別のカスタム GINA アプリケーションがログオン画面で使えなくなります。
アンインストールをする際も注意が必要 FIM コンポーネントの導入については、他の GINA が事前に導入されていることは運用シナリオ上想定していないため、上述の GINA 登録先レジストリに自身のデータを書き込み、上書きします。 FIM モジュールによって上書きされたレジストリは、FIM モジュールをアンインストールする際、削除対象になります。あらかじめレジストリ キーを保持し、書き換えるような動作を行うことはありませんので、事前に入っていたカスタム GINA の登録が戻ることはありません。カスタム GINA 登録キーを削除してしまうことによって、既定のログオンダイアログに戻ってしまいます。
-- カスタム GINA 登録レジストリを削除する動作は既定の動作 アンインストール時は、自身が導入したコンポーネントおよびレジストリ情報を削除対象とするため、上書きした上記レジストリを削除するアクションがとられます。 これは、カスタム GINA が環境から削除されているにもかかわらず当該レジストリが残存することによってログオン動作に支障がでる可能性を排除することを目的としたアクションです。
また、FIM クライアント プラグインを導入する際、インストール時のカスタム動作でレジストリ存在チェックを実施し、存在した場合はバックアップを取るという動作をしない理由としては、仮にそうしたアクションを取りますと、今度は以下のようなシナリオで問題を生じる可能性があるためです。
＜問題となりうるシナリオ＞ 1. カスタム GINA を導入 2. FIM プラグイン導入、レジストリをバックアップ 3. 上記 1. のカスタム GINA をアンインストール 4. FIM プラグインをアンインストール 5. すでに存在しない上記 1. のカスタム GINA の情報が残ってしまう 6. ログオンに支障がでる
なお、手動で FIM モジュール導入以前のカスタム GINA 登録レジストリを FIM モジュールの削除後に復旧したとしても、今度は別のカスタム GINA を使うアプリケーションをアンインストールする際に削除対象から外れ、残存してしまう可能性なども懸念されますので、手動でレジストリを書き戻した後にカスタム GINA アプリケーションをアンインストールする際は必ず当該レジストリが削除されているか確認されることをお勧めいたします。
Windows Vista カーネルの内部 : 第 2 部 http://technet.microsoft.com/ja-jp/magazine/2007.03.vistakernel.aspx ⇒ "資格情報プロバイダ" の項をご参照ください。
Windows Vista® および Windows Server® 2008 アプリケーション互換性解説書 http://msdn.microsoft.com/ja-jp/library/aa480152.aspx ⇒ "Microsoft GINA (Graphical Identification and Authentication)" の項をご参照ください。
※ CredentialProvider モデルは Windows Vista / Windows Server 2008 以降 Windows 7 および Windows Server 2008 R2 共通となります。
ういこう@全身の蕁麻疹が世界地図のようですね
みなさんごきげんよう。ういこです。
年末の見えてきてついおなかを下したり蕁麻疹だらけになったりしがちな今日この頃ですが、皆様いかがお過ごしでしょうか。 さて本日は SQL Server Parallel Data Warehouse のお披露目イベントについてご紹介させてください。 来る 12 月 7 日 (火曜日) に秋葉原の UDX ギャラリーにて、イベント 「Microsoft BI / DWH Day」 が開催される運びになりました。 あの超大規模並列処理(10～40台!??)を実現した SQL Server Parallel Data Warehouse のお披露目です！！
FIM や ILM 管理者の皆様なら、バックエンドの実際のデータストアは SQL Server が担っていることをご存知と思います。2010/12/02 現在、FIM は SQL Server 2008 R2 の対応をすべく、開発本部が毎日のように激しく対応をしています。ですので、今すぐ…というわけではないですが、SQL Server 2008 R2 についてもぜひ、これを切っ掛けになじんでいただくことでスキルの幅を広げていただけるのではないかと思います。 ぜひぜひ、ご参加ください！今後のシステム管理の効率化などに役立つ情報が満載です。
お申込みはこちらから！
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032468425&Culture=ja-JP
Microsoft BI / DWH Day 日 時 : 2010 年 12 月 7 日 (火) 13:00 ～ 17:00 (受付開始 12:30) 会 場 : 秋葉原 UDX ギャラリー 対 象 : 企業や組織において BI/DWH のシステム導入にかかわる方 (IT 部門および経営企画部門) 参加費 : 無料 (定員 300 名) 協賛スポンサー : 株式会社NTTデータ ※来場者特典として、ご来場の先着 200 名様に、セッション スピーカー 平山 理の執筆書籍「絵で見てわかる SQL Server の内部構造」を進呈いたします。 ↓↓↓↓セミナー内容、Agenda はこちらから！↓↓↓ http://www.microsoft.com/japan/sqlserver/2008/r2/event/pdw.mspx
Microsoft BI / DWH Day
日 時 : 2010 年 12 月 7 日 (火) 13:00 ～ 17:00 (受付開始 12:30) 会 場 : 秋葉原 UDX ギャラリー 対 象 : 企業や組織において BI/DWH のシステム導入にかかわる方 (IT 部門および経営企画部門) 参加費 : 無料 (定員 300 名) 協賛スポンサー : 株式会社NTTデータ ※来場者特典として、ご来場の先着 200 名様に、セッション スピーカー 平山 理の執筆書籍「絵で見てわかる SQL Server の内部構造」を進呈いたします。
↓↓↓↓セミナー内容、Agenda はこちらから！↓↓↓ http://www.microsoft.com/japan/sqlserver/2008/r2/event/pdw.mspx
おまけ ちなみに、セッション スピーカーの平山ですが、私の所属するデベロッパーサポート部のお隣の SQL Server 担当チームのエンジニアでした。過去いっぱい質問して、SQL がほとんどわからなかった数年前の私にとても分かりやすく、難しい技術を理解させてくれる素敵な人でした。 今回は、クエリを 10 分割し、さらに効率よく並列処理を行うなんて難しそうなことを実際にどのように処理を行っているのか、内部動作に関する部分も含めてわかりやすく解説してくれるそうです。絶対損はないです！！ さらに、あのファンが多い SQL Server のプロダクト マネージャーの松澤（「動画でわかる SQL Server」でご存知の方も多いのではないでしょうか）もエンドユーザもよく使う Excel との関連について定数 30 人なんて少数セッションで体験させてくれます。ハンズオンラボは、操作を通じて実際の「使いどころ」などについて体感的に判断頂く指標になると思います。 松澤さんファンの方、ここは参加しどころです！！
SQL Server Product Manager チームブログ http://blogs.technet.com/b/sqlpm-j/archive/2010/11/22/3370240.aspx http://blogs.technet.com/b/sqlpm-j/archive/2010/12/01/3372289.aspx
みなさんふるってご参加くださいませ♪
ういこう@FIM-SQL 連携について思いをはせてみた
本日はサポート技術情報 (KB) 982556 の Identity Lifecycle Manager 2007 Feature Pack 1 Service Pack 1 用の修正モジュール (build 3.3.1160.02) を適用した場合に AD 管理エージェント (AD MA) の Export 時に "no-start-ma" になる問題についてご報告いたします。この問題は製品の不具合による問題となります。
問題の概要 修正モジュールを適用後、AD MA の Export を実行しようとすると、Status が "no-start-ma" となり、Export ができなくなります。 なお、この問題は AD MA にて "Exchange 2010 Provisioning" を実施している場合に発生します。
Article ID: 982556 - Last Review: September 25, 2010 - Revision: 3.0 A hotfix rollup package (build 3.3.1160.02) is available for Identity Lifecycle Manager 2007 Feature Pack 1 Service Pack 1 http://support.microsoft.com/kb/982556/en-us
以下のようなエラー メッセージがイベント ビューアのアプリケーション ログに記録される場合があります。内容は環境によって異なる可能性がありますが、no-start-ma の場合は本件に当てはまります。
-- パターン 1
状況 マイクロソフトでは、この不具合を対象製品として記載されているマイクロソフト製品の不具合として認識しています。 2010 年 11 月 11 日現在、本件の修正予定は未定となっております。 (不具合判断は 11 月 10 日に実施されています)
対処方法 AD MA の "Exchange 2010 Provisioning" チェック ボックスを一旦はずし、再度チェックをつけて OK します。
対象製品 Microsoft Identity Lifecycle Manager 2007 Feature Pack 1
弊社製品の不具合ですでにご迷惑をおかけしたお客様もいらっしゃるかと存じます。 あらためて、心よりお詫び申し上げます。
(ILM/FIM Support Team - November 11, 2010)
みなさんごきげんよう、ういこです。今日は障害情報「リモートマシンへの認証を複数回繰り返し実行するとLSASS.exeのCPU使用率がスパイクする」 (Windows Vista / 2008 Server 無印限定) についてお知らせいたします。この現象は、Windows 2003 および Windows XP、Windows 7 および Windows Server 2008 R2 では発生しません。
【現象】 Windows Server 2008 / Windows Vista において、リモート PC に対しての WMI を使ったプログラムを同一のマシン上で同時に複数インスタンスを起動すると、プログラムを稼動させているマシン上の lsass.exe の CPU 使用率がスパイクし、プログラムの反応が遅くなっていき、最終的にプログラムがフリーズするように見える状態にまで至ることがある。この状態の間は無応答になるが、しばらくすると CPU 使用率も低下し処理が戻る。
【ステータス】 この現象は認証関連の動作の問題に起因する現象となり、修正モジュールが以下のサポート技術情報にて公開されております。 対象は Windows Vista、Windows Server 2008 です。（モジュールは CPU の種別はあるものの、OS の違いはありません）
Article ID: 2028484 - Last Review: October 13, 2010 - Revision: 1.0 You experience poor performance when you use Kerberos authentication to connect to lots of remote computers at the same time from a computer that is running Windows Server 2008 or Windows Vista http://support.microsoft.com/default.aspx?scid=2028484
【原因】 この問題は WMI 固有の動作ではありません。認証関連の処理に起因するものになります。 よって、認証処理フェーズを実施する LSASS.exe の CPU 使用率が上昇するという形で問題が発生します。今回の事例では WMI にて発生した現象に見えますが、WMI に限らず、認証動作が伴う処理を複数実行する場合に発生する可能性があります。
リモート PC への WMI 操作を実行する場合、複数の WQL 文によるクエリが実施されますが、このように毎回認証動作が発生する動作パターンの場合、この問題による認証時の処理のオーバーヘッドが乗算的に増加し、CPU 使用率や処理時間に影響を及ぼす状況になります。
修正モジュールが適用できない場合の回避策 ■プログラミングの場合 WMI によるリモート環境の参照には、必ず有効な資格情報が必要となります。この資格情報を毎回取得し認証するか、既存の資格情報により認証するかで処理負荷の改善が可能です。
ConnectionOptions でアカウントを指定するのではなく、ConnectionOptions を指定せず、事前にプロセスアカウントを想定ユーザで偽装していただくことが可能であれば、本現象に触れることはありません。 そのため、RunAS や .NET Framework の Process.Start() メソッドを用いて System.Management 名前空間を通じた WMI の処理を実行するプロセスの実行アカウントを指定し、同名前空間のメソッドの引数を変更することによって資格情報の取得および認証動作を減らすことで回避することになります。 認証動作の回数自体を減らすことはできませんが、認証に必要とされる資格情報をプロセス アカウントの資格情報で使いまわすことで資格情報の取得という認証フェーズの中でもコストの高い処理をスキップすることができ、結果として認証動作の処理負荷を軽減することが可能になります。 しかしながら同一ドメインに所属したコンピュータ間のリモート管理ではなく、ドメイン所属マシンからワークグループ所属マシンに対してのリモート管理を実施するシナリオの場合は、残念ながらこの方法を採ることが出来ません。
■WMIC コマンドの場合 ドメインに属したマシンからパスワードとユーザ名を指定せずに実行することになります。 ※ ワークグループの場合は net use であらかじめ IPC$ をマウントしてコマンドを実行することで対処可能です。(後述 "再現例(2) コマンド" でも回避可能)
【再現例(1) スクリプト】 Const WbemAuthenticationLevelPktPrivacy = 6
'接続先コンピュータ名 strComputer = "uikoutest2008" strNamespace = "root\cimv2" '接続ユーザアカウント名:パターン1-NetBIOS (ドメイン名\ユーザ名) strUser = "fareast\uikou" '接続ユーザアカウント名:パターン2-FQDN (ユーザ名@ドメイン名) 'strUser = "uikou@microsoft.com" 'パスワード strPassword = "P@ssw0rd"
For i = 0 to 1000 Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator") Set objWMIService = objwbemLocator.ConnectServer _ (strComputer, strNamespace, strUser, strPassword) objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy
Set colItems = objWMIService.ExecQuery("Select * from Win32_LocalTime")
For Each objItem in colItems Wscript.Echo objItem.Hour & ":" & objItem.Minute & ":" & objItem.Second Next
Set objWMIService = nothing Set objWbemLocator = nothing Next
【再現例(2) コマンド → バッチ化して複数回実行】 以下内容を 拡張子(.BAT) のファイルにコピーいただき、複数 (3 つ ～)のコマンド プロンプトを開いた上で同時実行します。
@ECHO OFF for /L %%i in (1,1,50) Do WMIC /node:uikou01v /user:fareast\uikou /password:P@ssw0rd path Win32_LocalTime
ういこう＠大丈夫か？問題ないか？
皆さんごきげんよう。ういこです。最近森ガールの後継の山ガールが流行ってるらしいですね。私もついカッとなってファーベストを試着したら山狩り上等なマタギ感溢れるコーデになってしまいそして僕は途方にくれるな秋ですが皆さま如何お過ごしでしょうか。
さて、今日は WinRM についてです。あんまり情報が無いので、おいしそうに見えませんが、毒キノコじゃないですよ。WinRM は食べて美味しいものですよ！食べず嫌いはもったいないです。というわけで、今日は本当に基本の基本になっちゃいますが、簡単な使い方を御紹介します。
能書き WinRM とは…というのを語ってるとすごく難しくて、色々語られつくされているのですがまあ要は DCOM 使わないで HTTP/HTTPS などでリモートコンピュータやらの管理ができる便利なインターフェースと思ってください。興味をもたれた方は後述の technet コンテンツなどご参照頂ければと思います。管理系インターフェースとしては、WMI が随分人口に膾炙している感がありますが、WinRM も基本同じような目的のものなので、ほとんど同じことが出来ます。むしろ、もっと出来ることあるかも。
① WinRM のバージョンを見てみよう 2010 年 10 月 27 日現在、WinRM のバージョンは二つありますです。
・Windows Vista / Windows Server 2008 … Version 1.x ・Windows 7 / Windows Server 2008 R2 … Version 2.x
実は、それぞれ微妙に違います。例えば、既定のポート番号が違ったりします。そこで、まずあなたの環境と、リモートでこっそりいじりまわしてやりたい環境と双方の WinRM のバージョンを確認してみたいと思います。
ローカルで実行してみる 1. PowerShell を管理者権限で実行します。 2. WinRM id と打って、Enter キーを押します。例えば、Windows 7 の環境で実行した場合は以下のようになります。
Windows Server 2008 の場合は以下のようになります。どうも、Stack というところが実際の WinRM のバージョンのようですね。
リモート PC の WinRM バージョンを確認してみる まず、リモート PC では WinRM QC を実行してある必要があります。これがないと、リモートからアクセスできません。
例) WinRM Qc を実行していないマシンに対して実行した場合
PS C:\Windows\system32> WinRM id -r:uikou2008r2 WSManFault Message = WinRM クライアントは、指定された時間内に処理を完了できません。コンピューター名が有効で、ネットワークを介して到達可能で、Windows リモート管理サービスのファイアウォールの例外が有効化されていることを確認してください。
エラー番号: -2144108250 0x80338126 WinRM クライアントは、指定された時間内に処理を完了できません。コンピューター名が有効で、ネットワークを介して到達可能で、Windows リモート管理サービスのファイアウォールの例外が有効化されていることを確認してください。
② WinRM の細かい設定を見てみよう WinRM の構成情報を確認する場合、コマンドは以下のようになります。
WinRM get WinRM/config
これを実行すると、認証や、既定ポートなどが判ります。さっきの通り、Windows 2008 と Windows 2008 R2 では既定ポートが違うのがよくわかります。
・Windows Vista / Windows Server 2008 の場合 : HTTP = 80、HTTPS = 443 が使われている
・Windows 7 / Windows Server 2008 R2 の場合 : HTTP = 5985、HTTPS = 5986 が使われている
さて、リモートで実行してみましょう。簡単です。さっきと同じく、-r: にリモートマシン名つければいいだけです。
WinRM get WinRM/config -r:jpdsfim
③ WMI 見たいなことをやってみよう 例えば、WMI のコマンドラインである WMIC で特定のサービスの情報を取ってきたい場合は、以下のような構文になります。
wmic path win32_service where Name="WinRM"
これと同じこと�� WinRM でやると、こんな感じになります。Whare 句の後にクラス (この例では、win32_service) のプロパティを指定していますが、(この例では Name) クラス名のあとに ? とプロパティ名を指定して確認が可能です。例えば、WinRM 自身の情報を取ってきましょうか。Name のあとにサービス名、つまり今回の場合 WinRM と指定してあげれば、取れます。
まずローカルでやってみます。
WinRM get wmi/root/cimv2/Win32_Service?Name="WinRM"
こんな指定方法でもよいです。
WinRM get http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service?Name=WinRM
では次はリモートやってみましょう。まず、WMI の場合は、/node:<いじってやりたいマシン名> を wmic の後につつましくつけてあげましょう。
wmic /node:jpdsfim path win32_service where Name="WinRM"
はい、取れました。相変わらずインデントが色々気に食わないです。つぎ、WinRM 行ってみましょう。WinRM でリモートは… そう、-r:<いじってやりたいマシン名> でしたね。最後に追加してあげても全然 OK です。
WinRM get wmi/root/cimv2/Win32_Service?Name="WinRM" -r:jpdsfim
美しい。
④ リモート シェル実行してみますか さて、WinRM って、結構色々できるのね★ってことがまだ実感できないというかた！Windows Remote Shell (WinRS) を使って色々コマンドも実行できますよ。WinRS は、WinRM を基盤として、シェルを実行するもの見たいな感じです。WinRM が構成されている必要があります。(WinRM qc) 例えば、リモートマシンに適切なアクセス権があるユーザで接続できさえすれば、shutdown もできますよ！ちょっとしたおちゃめ心で同僚の気になるあの子のマシンに WMI でシャットダウンさせちゃって怒られたものの、「え…僕、あのマシンの管理者権限貰っちゃってたんだ」と微妙にときめいたりした経験のある方などは、今度は WinRS で再チャレンジしてみるというのもオツなものかもしれません。それでアクセス権なくなってたら男泣きですが。
というわけで、心優しい私は一瞬、チームメンバーのマシンでも落としてやろうかと思いましたが、思い直して自分のおととい構成したマシンをシャットダウン…するのが怖いので、休止モード (/h) で実行したら、休止状態無効にしててほっとしたようなそれでいてまったりしたような気分でした。
でもこれ、別に WMI のころから変わってないんですが、ひそかにコマンドとかを実行させたりできる分、怖いなあと思います。アクセス権は適切にしておいたほうがいいですね。
⑤おまけ : エラーコードを見てみるです 以前の記事で紹介した、WinRM のイベント ビューアのエラーコード。 イベント ビューア上だと、これの説明があんまりないです。そういう時は、以下の構文で確認が出来ます。
winrm helpmsg 0x<エラーコード>
が、電卓と、頭に 0x をつけないと動いてくれません。
Windows リモート管理コマンド ライン ツール
winrm helpmsg errorcode
エラー コードに関連付けられているエラー メッセージを表示します。 例: winrm helpmsg 0x5
そこで、まずエラーコードをイベント ビューアからコードをコピーします。
電卓を起動し、プログラマ電卓あるいは関数電卓にして 10 進数にした状態で、コードをペーストします。
ペーストしたら、16 進数にします。8033803B と判ります。
ここで、0x をつけて、0x8033803B にした状態で、winrm helpmsg に渡します。
winrm helpmsg 0x8033803B
参考
An update is available for the Windows Remote Management feature in Windows Server 2003 and in Windows XP http://support.microsoft.com/default.aspx?scid=kb;EN-US;936059
Windows Remote Management and WMI http://msdn.microsoft.com/en-us/library/aa384463(VS.85).aspx
Windows Management Instrumentation (WMI) コマンド ライン ユーティリティ (Wmic.exe) の説明 http://support.microsoft.com/kb/290216/ja
Examples of WMIC commands for Windows .NET SERVER Family http://support.microsoft.com/servicedesks/webcasts/wc072402/listofsampleusage.asp
WMIC のエイリアス http://technet.microsoft.com/ja-jp/library/cc736307(WS.10).aspx
[ILM/FIM] Remote PowerShell/WinRM を用いて Exchange 2010 コマンドレットを投入にチャレンジする http://blogs.technet.com/b/jpilmblg/archive/2010/10/12/ilm-fim-remote-powershell-winrm-exchange-2010.aspx
[WinRM:初級編] WinRM を構成してみよう！(WinRM QC) http://blogs.technet.com/b/jpilmblg/archive/2009/11/25/winrm-winrm.aspx
[WinRM] Windows Remoe Management を使って、らくらく管理！- その1 http://blogs.technet.com/b/jpilmblg/archive/2009/08/17/winrm-windows-remoe-management-1.aspx
ういこう@これからはマタギガールがなうでトレンディだと思うよおっかさん
(改稿 : 2010/11/02 By Uikou)
皆さんごきげんよう。ういこです。
羽田空港の国際化が始まったらしいです。(うろ覚え、2010/10/21 現在)これにあざとく便乗した ILM 一家が送る今日のコンテンツ、”FIM のポータルの国際化対応方法” についてご案内いたします。インストーラパッケージを見て頂くと判るように、FIM ポータルは、9 言語に対応しています。では、インストールした後、どうやってポータルの言語を変えればよいのでしょう？これより導入を検討頂いている方などは、ドキュメントも英語だし、判りづらいなと思っていらっしゃるのではないでしょうか。
結論からいうと、一台 FIM ポータルサーバを組んで頂くだけで複数言語対応を行うことが可能です。アクセス URL も一つで、クライアント側の設定を変更するだけでポータルの表示を変更することができます。一方サーバ側の設定は、ポータルの言語パックを別途ダウンロード サイトより入手後、FIM サーバ上でインストールを実施頂くのみとなります。 ただしインストールの際、"Custom Setup" フェーズにてインストール対象のリソースを選択する画面がありますが、対応したい言語パックはすべて対象としてインストールして頂く必要があります。
FIM ポータルの言語は、Client IE の "言語の優先順位" の最優先の言語 もしくは OS の [地域と言語] オプションの "形式" に設定されている言語形式と紐づいております。 例えば、日本語版 Windows であっても、形式が [スペイン語(スペイン)] が設定されている環境の Web ブラウザから FIM ポータルにアクセスした場合、FIM ポータルにスペイン語のリソースがインストールされていればブラウザ上の FIM ポータル表示はスペイン語になります。(図)
図 : FIM ポータルの URL はひとつだけで OK。各クライアント OS の IE の "言語の優先順位" の最優先の言語もしくは、コンパネの [地域と言語] - “形式”に従って表示される FIM ポータルページの言語が変わる
FIM ポータルは ASP.NET で動作しており、サーバサイドで動的に生成されたデータを Web ブラウザ上で解釈、表示しておりますので、クライアントサイドの各国語の表示条件(たとえば、そもそも表示するためのフォントがインストールされているか、コードページが対応しているかなど)はInternet Explorer など Web ブラウザの設定に依存します。
対応言語は 9 種類
FIM ポータルは、以下の 9 言語に対応しております。
1. 日本語(日本) Japanese Language Pack 2. 中国語 (簡体字、中国) Chinese (Simplified) Language Pack 3. 中国語 (繁体字、台湾) Chinese (Taiwan) Language Pack 4. オランダ語 (オランダ) Dutch Language Pack 5. フランス語 (フランス) French Language Pack 6. ドイツ語 (ドイツ) German Language Pack 7. イタリア語 (イタリア) Italian Language Pack 8. ポルトガル語 (ポルトガル) Portuguese Language Pack 9. スペイン語 (スペイン) Spanish Language Pack
一方、FIM ポータルにインストールされていない言語リソースが"形式" に設定されている場合は、英語での表示となります。
例 1) 英語版 Windows + 形式が "フランス語" … フランス語で FIM ポータルが表示されます。
例 2) 英語版 Windows + 形式が "ディベヒ語 (モルディヴ)" … 上記言語はリソースに含まれないため、英語で表示されます。
実際に試してみよう(2010/11/02 Up)
※ その後、IE サポートチームの D 先生より、この設定は IE の [インターネットオプション] の [言語(L)] で変えられることをお知らせいただきましたので、改稿いたしました。（2010/11/02 By Uikou）
Internet Explorer の日本語版を例にとりますと、規定の状態では "言語の優先順位" が "日本語 (日本) [ja-JP]" が最上位、かつこれだけになっています。
図 1 : IE 日本語版の例。言語優先順位には、既定では日本語のみが設定されている
IE から、サーバに対して要求を送る際、ここに指定されている言語に対して最大が 1 になるよう重みづけをつけるそうです。そこで、最上位に表示させたい言語を設定すれば、その言語が表示されます。よって、たとえば中国語 (繁体字) を表示させたい場合は、"中国語 (繁体字) [zh-Hant]" を追加し、最上位にしてあげればよいということになります。
図 2 : 中国語（繁体字) が最上位に設定されているので、FIM のページは繁体字中国語で表示されることになる。韓国語も設定されているが、最上位の言語が表示される
図 3 : 優先順位に言語を追加したい場合
→
余談 : IE から要求を受け取った側のサーバでは… 以下、D 先生からいただいた情報です。サーバ (この場合だと、FIM ポータルの IIS) 側でみると…
1) 図 1 の既定の "日本語 (日本) [ja-JP]" だけが設定されている状態
GET http://xxxx/xxxxx/xxxx.aspx HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: ja-JP User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MS-RTC LM 8; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 1.1.4322) Accept-Encoding: gzip, deflate, peerdist Host: xxxx
2) 図 2 の英語 / 中国語 / 韓国語を加え、それらのうち、繁体字中国語を最優先に上げた状態。繁体字は 0.8 が与えられています。二番目の韓国語は 0.5、最下位の日本語は 0.3 の重みづけです。
GET http://xxxx/xxxxx/xxxx.aspx HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: en-US,zh-Hans;q=0.8,ko-KR;q=0.5,ja-JP;q=0.3 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MS-RTC LM 8; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 1.1.4322) Accept-Encoding: gzip, deflate, peerdist Host: xxxx
興味深いですね。
実際に試してみよう(Ver1.0の内容です)
1. [地域と言語] の “形式” が “日本語(日本)” の場合
Internet Explorer 上のポータル表示は日本語です。”ようこそ, Administrator”
2. [地域と言語] の “形式” が “中国語 (簡体字、中国)” の場合。FIM Portal Language Pack インストーラの “Chinese (Simplified)” が相当します。
Internet Explorer 上のポータル表示は簡体字中国語です。”欢迎, Administrator”
3. [地域と言語] の “形式” が “中国語 (繁体字、台湾)” の場合。FIM Portal Language Pack インストーラの “Chinese (Taiwan)” が相当します。
Internet Explorer 上のポータル表示は簡体字中国語です。” 歡迎, Administrator”
4. [地域と言語] の “形式” が “オランダ語 (オランダ)” の場合。FIM Portal Language Pack インストーラの “Dutch Language Pack” が相当します。
Internet Explorer 上のポータル表示はオランダ語です。”Welkom, Administrator”
5. [地域と言語] の “形式” が “フランス語 (フランス)” の場合。FIM Portal Language Pack インストーラの “French Language Pack” が相当します。
Internet Explorer 上のポータル表示はフランス語です。”Bienvenue, Administrator”
6. [地域と言語] の “形式” が “ドイツ語 (ドイツ)” の場合。FIM Portal Language Pack インストーラの “German Language Pack” が相当します。
Internet Explorer 上のポータル表示はドイツ語です。”WillKommen, Administrator”
7. [地域と言語] の “形式” が “イタリア語 (イタリア)” の場合。FIM Portal Language Pack インストーラの “Italian Language Pack” が相当します。
Internet Explorer 上のポータル表示はイタリア語です。”Pagina iniziale, Administrator”
8. [地域と言語] の “形式” が “ポルトガル語 (ポルトガル)” の場合。FIM Portal Language Pack インストーラの “Portuguese Language Pack” が相当します。
Internet Explorer 上のポータル表示はポルトガル語です。” Bem-vindo, Administrator”
9. [地域と言語] の “形式” が “スペイン語 (スペイン)” の場合。FIM Portal Language Pack インストーラの “Spanish Language Pack” が相当します。
Internet Explorer 上のポータル表示はスペイン語です。”Pagina principal, Administrator”
※ その他
FIM ポータル言語パックにない言語を設定した場合は、英語表記になります。
例 : シンハラ語 (スリランカ)
英語表記になります。
クライアントの言語を変えてアクセスすると、同一の Internet Explorer から複数言語の表示をすることが出来ます。URL も同一です。
※補足事項 : 確認環境
OS : Windows 7 および Windows Server 2008 R2 日本語版、英語版
Internet Explorer : Version 8
Internet Explorer は構成無し（”後で構成する” を選択）
だいたい、FIM に限らず割とコントロール パネルの地域と言語の設定に引きずられて変化する動作のものって良くあります。
なかなか壮観なので皆様も是非、お試しくださいませ。
では皆さんごきげんよう。
ういこう@カールマイヤーとひぐらしの相性はなかなかなもんだと思います。
皆さんごきげんよう。ういこです。今日は「WinRM でトラブル発生したときは、表示されたエラーと、イベントビューアをじっくり見よう！」をお送りします。
WinRM というのは、"リモートコンピュータを管理を可能にする" 機構だと Web でご覧になった方もいらっしゃるかと思います。SOAP ベースとか何とか色々難しいことが良く書いてありますが、あの弊社の誇る素敵エバンジェリストの安納さんのブログにもございますように、要は HTTP (含む HTTPS) で WMI が使えちゃうぞーというステキテクノロジです。はて、WMI はリモート コンピュータを対象にしても使えるし、何をいまさらジロー？と思うそこのあなた！いえいえ、何がいいって、DCOM 使わなくていいんです。DCOM。
以前の記事にもちらっと触れたことがありますが、WMI は DCOM を基盤として動作しますので、動作前提として DCOM がきちんと構成されている必要があります。DCOM はさらに RPC を基盤として動作します。よって、WMI でリモート コンピュータを管理したいというときは、以下の三つが動作する必要があるのです。
・RPC ・DCOM ・WMI
当然、そこにはリモートコンピュータへのアクセス権の他、RPC、DCOM が使うポートが外部から使える状態になっていなくてはいけません。 会社のイントラネットで使うならまだしも、例えばインターネット越しに操作してほしい！という端末で、RPC / DCOM などのポート解放は…怖いです。そうしたことに対する一つの答えとして、WinRM があります。WinRM は HTTP / HTTPS で WMI の動作が出来てしまうので、セキュリティ上の懸念が随分楽になります。
さて、そんないいことずくめに思える WinRM ですが、やっぱりなんか問題が起きた時は結構面倒です。 WMI もそうですが、使うに易しいからと言って、トラブルシュートや仕組みも易しいわけではないということを常に考える必要があります。ここを誤解すると、保守などのフェーズでとんでもないことになります。
…と、脅かしまくりですが、WinRM、どうも問題発生時の状況を把握するのが WMI と比べるとずっと楽になっているようです。 とにかく、失敗時にコンソールに出るメッセージも詳細だし、イベントログに出る情報が判りやすいこと。 WMI の場合、スクリプトで使われることが多いですが、スクリプトの実行エラーとか言われちゃうと何がエラーなのかさっぱりですし、プログラムで実行したとしても、HRESULT 判りづらいし、イベントログも、DCOM のエラーだ、RPC のエラーだ何だと色々見なくてはいけない情報があちこちとっちらかってましたが、WinRM の場合、ちゃんと集約されています。しかも情報が詳細。非常に判りやすいです。
じゃあどんだけわかりやすいのよと思いますよね。早速試してみましょう。 さて、Hyper-V を構成し、リモート デスクトップを有効にした程度にしてある環境（Windows Server 2008 R2）が都合よく手元にあったので、コイツをターゲットにして実行してみます。クライアントは Windows 7、クライアントには winrm quickconfig してますが、サーバはもちろん何にもしておりません。 さあどんなコマンド叩いたろかとしばし考えましたが、かめがわさんの素晴らしく判りやすいこの Technet コンテンツから頂いてきたコマンドをたたいてエラーを出してみました。(内容も判り易く、とてもいい記事です。是非ご覧ください！) ちなみに実行元は Windows 7 日本語版、実行先は Windows Server 2008 R2 日本語版、それぞれ同じドメインに入っています。
PowerShell でのリモート管理 http://technet.microsoft.com/ja-jp/windows/ee460851.aspx
PS C:\Windows\system32> Invoke-Command -ComputerName jpdsfim -ScriptBlock {Get-Service} [jpdsfim] リモート サーバーへの接続が失敗し、次のエラー メッセージが返されました。WinRM クライアントは、指定された時間内に処理を完了できません。コンピューター名が有効で、ネットワークを介して到達可能で、Windows リモート管理サービスのファイアウォールの例外が有効化されていることを確認してください。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照してください。 + CategoryInfo : OpenError: (:) []、PSRemotingTransportException + FullyQualifiedErrorId : PSSessionStateBroken
このメッセージによると、
1. (パラメータに指定した) コンピューター名が有効であること 2. (パラメータに指定したコンピュータに対して) ネットワークを介して到達可能であること 3. (パラメータに指定したコンピュータ上で) Windows リモート管理サービスのファイアウォールの例外が有効化されていること
の三つの条件がそろってるか確認してほしいということですね。 今回、"上記のパラメータに指定したコンピュータ" は、jpdsfim という名前でございます。 じゃあ、手っ取り早く指定した名前で Ping でもやってみましょうか。
PS C:\Windows\system32> ping jpdsfim jpdsfim.uikoutest.microsoft.com [2001:4898:7008:1014:69d0:d1a0:925b:e057]に ping を送信しています 32 バイトのデータ: 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 =1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 0ms、最大 = 1ms、平均 = 0ms
PS C:\Windows\system32> ping jpdsfim
jpdsfim.uikoutest.microsoft.com [2001:4898:7008:1014:69d0:d1a0:925b:e057]に ping を送信しています 32 バイトのデータ: 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 =1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms 2001:4898:7008:1014:69d0:d1a0:925b:e057 からの応答: 時間 <1ms
2001:4898:7008:1014:69d0:d1a0:925b:e057 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 0ms、最大 = 1ms、平均 = 0ms
名前もしっかり解決して Ping も通ってるようなので、1 および 2 は OK ということですね。 あとは 3 だと。 では jpdsfim にログオンして、winrm qc をしてみます。
PS C:\Windows\system32> winrm qc WinRM は既にこのコンピューター上で要求を受信するように設定されています。 WinRM は、管理用にこのコンピューターへのリモート アクセスを許可するように設定されていません。 次の変更を行う必要があります: このコンピューター上のあらゆる IP への WS-Man 要求を受け付けるため、HTTP://* 上に WinRM リスナーを作成します。 WinRM ファイアウォールの例外を有効にします。 変更しますか [y/n]?
PS C:\Windows\system32> winrm qc WinRM は既にこのコンピューター上で要求を受信するように設定されています。 WinRM は、管理用にこのコンピューターへのリモート アクセスを許可するように設定されていません。 次の変更を行う必要があります:
このコンピューター上のあらゆる IP への WS-Man 要求を受け付けるため、HTTP://* 上に WinRM リスナーを作成します。 WinRM ファイアウォールの例外を有効にします。
変更しますか [y/n]?
と表示されました。どうも、WinRM ファイアウオールの例外設定はこれから有効にしないとだめ見たいです。ためしに y を実行して、リモート管理用に WinRM の更新を実施します。
変更しますか [y/n]? y WinRM はリモート管理用に更新されました。
変更しますか [y/n]? y
WinRM はリモート管理用に更新されました。
このコンピューター上のあらゆる IP への WS-Man 要求を受け付けるため、HTTP://* 上に WinRM リスナーを作成しました。 WinRM ファイアウォールの例外を有効にしました。 PS C:\Windows\system32>
これでもう一度、クライアントから同じコマンドを実行すると…
PS C:\temp> Invoke-Command -ComputerName jpdsfim -ScriptBlock {Get-Service} Status Name DisplayName PSComputerName ------ ---- ----------- -------------- Running AeLookupSvc Application Experience jpdsfim Stopped ALG Application Layer Gateway Service jpdsfim Stopped AppIDSvc Application Identity jpdsfim Running Appinfo Application Information jpdsfim Stopped AppMgmt Application Management jpdsfim Stopped aspnet_state ASP.NET 状態サービス jpdsfim Stopped AudioEndpointBu... Windows Audio Endpoint Builder jpdsfim Stopped AudioSrv Windows Audio jpdsfim … (以下省略) …
PS C:\temp> Invoke-Command -ComputerName jpdsfim -ScriptBlock {Get-Service}
Status Name DisplayName PSComputerName ------ ---- ----------- -------------- Running AeLookupSvc Application Experience jpdsfim Stopped ALG Application Layer Gateway Service jpdsfim Stopped AppIDSvc Application Identity jpdsfim Running Appinfo Application Information jpdsfim Stopped AppMgmt Application Management jpdsfim Stopped aspnet_state ASP.NET 状態サービス jpdsfim Stopped AudioEndpointBu... Windows Audio Endpoint Builder jpdsfim Stopped AudioSrv Windows Audio jpdsfim … (以下省略) …
おお、行けました。
こんな感じで、比較的判りやすいメッセージで、具体的に何をすればよいか割と判る感じになっています。 では、ついでなので、実行元のクライアント側で、失敗時と成功時、それぞれイベントログではどう出ているか見てみましょう。
実行元のクライアントマシン上のイベントビューアを開きます。 [スタート] メニュー上の���[ファイル名を指定して実行] もしくは [プログラムとファイルの検索] で
eventvwr
と入力し、Enter キーを激しく叩きます。壊れない程度に。
イベントビューアが開きますので、左ペインを以下のように展開してください。
[イベント ビューアー (ローカル)] + [アプリケーション ログとサービス ログ] + [Microsoft] + [Windows] + [Windows Remote Management] - Operational
ここに WinRM 関連のログが表示されます。失敗時の処理の流れを抜粋していきますね。冗長ですが、処理の流れがとてもつかめると思いますです。 ちなみに以下は割愛していますが、接続に使われたユーザ名等も判ります。
失敗時のログの流れ from イベントビューア
情報 2010/10/12 17:39:41 Windows Remote Management 2 WSMan API の初期化 「WSMan API を初期化しています」 情報 2010/10/12 17:39:41 Windows Remote Management 29 WSMan API の初期化 「WSMan API の初期化が正常に完了しました」 情報 2010/10/12 17:39:41 Windows Remote Management 6 WSMan セッションの初期化 「WSMan セッションを作成しています。 接続文字列は jpdsfim/wsman?PSVersion=2.0 です」 情報 2010/10/12 17:39:41 Windows Remote Management 31 WSMan セッションの初期化 「WSMan セッションの作成操作が正常に完了しました」 情報 2010/10/12 17:39:41 Windows Remote Management 27 WSMan API 呼び出し 「WSMan セッション オプション (29) を取得しています」 情報 2010/10/12 17:39:41 Windows Remote Management 10 WSMan API 呼び出し 「WSMan セッションのオプション (25) に値 (ja-JP) を正常に設定しました」 情報 2010/10/12 17:39:41 Windows Remote Management 10 WSMan API 呼び出し 「WSMan セッションのオプション (1) に値 (180000) を正常に設定しました」 情報 2010/10/12 17:39:41 Windows Remote Management 10 WSMan API 呼び出し 「WSMan セッションのオプション (12) に値 (180000) を正常に設定しました」 情報 2010/10/12 17:39:41 Windows Remote Management 10 WSMan API 呼び出し 「WSMan セッションのオプション (17) に値 (60000) を正常に設定しました」 情報 2010/10/12 17:39:41 Windows Remote Management 10 WSMan API 呼び出し 「WSMan セッションのオプション (16) に値 (60000) を正常に設定しました」 情報 2010/10/12 17:39:41 Windows Remote Management 11 WSMan API 呼び出し 「WSMan シェルをリソース URI http://schemas.microsoft.com/powershell/Microsoft.PowerShell で作成しています」 情報 2010/10/12 17:39:41 Windows Remote Management 166 ユーザーの認証 「選択された認証機構は Kerberos です」 情報 2010/10/12 17:39:41 Windows Remote Management 80 要求の処理 「操作 CreateShell の要求を送信しています。送信先コンピューターおよびポート jpdsfim:5985」 情報 2010/10/12 17:39:41 Windows Remote Management 166 ユーザーの認証 「選択された認証機構は Kerberos です」 エラー 2010/10/12 17:40:44 Windows Remote Management 138 応答の処理 「クライアントがネットワーク レイヤーからタイムアウトを受信しました (ERROR_WINHTTP_TIMEOUT)」 エラー 2010/10/12 17:40:44 Windows Remote Management 142 応答の処理 「WSMan の操作 CreateShell に失敗しました。エラー コード 2150859046」 情報 2010/10/12 17:40:44 Windows Remote Management 26 WSMan API 呼び出し 「エラー コード 2150859046 のメッセージ取得が正常に完了しました。languageCode パラメーターは ja-JP でした。」 情報 2010/10/12 17:40:44 Windows Remote Management 16 WSMan API 呼び出し 「WSMan シェルを閉じています」 情報 2010/10/12 17:40:44 Windows Remote Management 8 WSMan セッションの初期化解除 「WSMan セッションを閉じています」 情報 2010/10/12 17:40:44 Windows Remote Management 33 WSMan セッションの初期化解除 「WSMan セッションを閉じる操作が正常に完了しました」
上記のオプションであんまり指定した覚えのないものもありますがこれらの流れで興味深い情報は以下のあたりです。
・ユーザの認証は Kerberos が使われている ・Windows 7 は WinRM 2.0 なので、何もいじっていない状態（既定）では ポート 5985 番が使われている ・タイムアウト (ERROR_WINHTTP_TIMEOUT) を契機に失敗している ※ WinRM 2.0 では既定の場合 HTTP:5985、HTTPS:5986 が使われますが、WinRM 1.1 の場合、既定値として HTTP:80、HTTPS:443 が使われます。
どうも、通信先で WinRM のリモート管理の構成がなされていない場合は、タイムアウトとして現れるんですね。2150859046 = 80338126 ですが、これは一般的なエラーを示すだけのものと思ってよいようです。この番号だけで何かがわかるという類のコードではないということです。
ちなみにうまくいく場合は、上記の "ユーザーの認証「選択された認証機構は Kerberos です」" の直後のイベントで、HTTP_STATUS_OK が返され処理が進みます。エラー時は ERROR_WINHTTP_TIMEOUT だったところです。
ログの名前: Microsoft-Windows-WinRM/Operational ソース: Microsoft-Windows-WinRM 日付: 2010/10/13 12:01:58 イベント ID: 143 タスクのカテゴリ: 応答の処理 レベル: 情報 キーワード: クライアント ユーザー: FAREAST\uikou コンピューター: uikou-seven.fareast.corp.microsoft.com 説明: ネットワーク レイヤーから応答を受信しました。状態: 200 (HTTP_STATUS_OK)
参考：WinRM の規定ポートを変更する方法 Installation and Configuration for Windows Remote Management http://msdn.microsoft.com/en-us/library/aa384372(VS.85).aspx
なお、WinRM の 1.1 - 2.0 間の既定ポート値の違いが元でおこる問題など、WinRM の使う規定ポートを変更したい場合は、上記参考資料の "Default ports changed for WinRM and PowerShell remoting" (ずいぶん下のほうにスクロールするとあります) を参照ください。本日 2010/10/13 現在、2010/6/24 が最新の更新です。
それではまた。
ういこう
皆さんごきげんよう、ういこです。 今日は久しぶりに ILM2007 のトラブルシュート初級編をお送りします。
【問題】 ILM 2007 をインストールしようとすると、グループの追加の際に以下のエラーが発生する。
One or more the groups entered is invalid. Group names cannot contain the characters '\/*:|<>+=;?*@' except where the '\' is user to separate the domain name from the group. Domain groups must already exist. Verify that each group name is correct, and then try again.
MSI のログを取ってみても、はかばかしい情報がありません。以下は抜粋です。 コマンドラインで取得しています。
例) >msiexec /i "C:\temp\MIIS_FullVersion_3.3.1160.2\MIIS\Setup\Microsoft Identity Integration Server.msi" /l*vx c:\temp\logfile.txt ※ MSI のフルパス (C:\temp\MIIS_FullVersion_3.3.1160.2\MIIS\Setup\Microsoft Identity Integration Server.msi) と、ログファイルのフルパス (c:\temp\logfile.txt) を指定しています。
以下はログファイルからの抜粋です。エラー ダイアログは開きっぱなしの状態で止めてます。
…(抜粋ここから)… Action 21:08:34: GroupInformation. Dialog created ← ★ グループ作成ダイアログ MSI (c) (48:70) [21:08:35:375]: Doing action: ValidateGroupsWithoutMsg Action 21:08:35: ValidateGroupsWithoutMsg. Action start 21:08:35: ValidateGroupsWithoutMsg. MSI (c) (48:70) [21:08:35:375]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'ValidateG …(抜粋ここまで)…
なぜかここでログが終わってしまっています。
【対処方法】 あらかじめ下記のグループをドメインに作成します。作成は、[Active Directory ユーザーとコンピュータ] などを使います。
1. MIISAdmins 2. MIISBrowse 3. MIISJoiners 4. MIISOperators 5. MIISPasswordSet
上記属性の値は同じ以下の値を入れてください。それぞれ、以下の 5 個分作成してください。
1. ドメイン コントローラ上の [Active Directory ユーザとコンピュータ] を開きます。もしくはクライアントからのリモート 管理ツールから開いてもOKです
2. 左ペインのドメインを展開し、”Users” フォルダ型のアイコンを右クリックし、さらに [新規作成(N)] → [グループ] 選択
3. グループ名を “グループ名(A):” に入力。以下の例では、MIISBrowse グループを指定している。”グループ名 (Windows 2000 以前)(W):” にも同じ名前が自動入力されるので、そのままにする。スコープ、グループの種類もそのまま既定で [OK]
そうすると、自動的に作成されます。
※ ADSIEdit.msc の場合
下記二つの属性を一致させるようにグループを作成してください。
もし、セットアップが途中で止まっている場合は、5つのグループをサービス アカウントを入力するところまで戻って、ちょっとユーザ名の入力文字列あたりを変えてから戻して次に進むとその先はスムーズに進みます。
何だかおかしなエラーですが、もしこうした体験をされましたらお試しください。