過日より、”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】

OS :

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年目を迎えることができました。

ひとえに皆様方のご声援の賜物と、日々感謝しております。深く御礼申し上げます。

心機一転、サポート関連情報、製品情報など、情報提供の場としてまいりますので。

今後ともよろしくお願いいたします.

お問い合わせ窓口休業のお知らせ
https://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)

思えば、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 も根強いです。

検索ワードランキング

2009 年

2010 年

2011 年

以上となります。どうぞよろしくお願いいたします。

ILM / ADSI / WMI Prog / PowerShell Support Team
横井 羽衣子 (よこい ういこ)

さて、「夏を待てない」と歌ったのは國生さゆりさん (おニャン子クラブ会員番号は 8 番) ですが、コマンドレット君も、あみんのようにいつまでも待てないことがあるのです。
Active Directory といっても、運用形態は様々。オブジェクト数も数個から数万ということもありえます。たとえば数万のオブジェクトを動かしたり、取得したりするとき、いつまでも時間がかかるような事態はパフォーマンスの観点など、まあ色々よろしくありません。というわけで、既定では get-ad 系コマンドレットは、検索クエリのオープン時間に対し、30 分の制限値を持ちます。この制限値は Active Directory Web サービスの Config ファイルのパラメーターで設定されています。

1. 30 分以上のクエリ要求を行うと SocketException やらいろいろな例外が発生することがある

なかなかいやらしいことに、30 分以上経過したときの PowerShell コンソール上に出てくる例外、エラーの発生パターンは一定ではありません。ADException が返る場合も、構文が無効とか、SocketException が出るときとかもございます。ただ、例外の出方に惑わされてはいけません。この問題のポイントは、「30 分以内に終われば何事もない、ところが 30 分を少しでも過ぎると何か、異常終了しちゃう」というところです。これが満たされている場合は、今回ご紹介する問題に合致する可能性がかなり高いです。

・これまで確認されている PowerShell 上のエラーメッセージの出方（これ以外にもあるかもしれません）

・ ちょっとダンプでも見てみましょうか
気が向いたら、おダンプでも一発取ってみてみると楽しいかもしれません。Windows Server 2008 R2 だからタスク マネージャ上で指先一つでダンプさ！ができるんです。ああ便利。
Powershell コンソール上で実行し、エラーが出ている状態で、PowerShell.exe に対してダンプを取ります。これで OK です。

ダンプを採ったら、Windbg で開いてみましょう。psscor2.dll でもダウンロードしていただき、!dae コマンドを実行すると、ほらこんなに例外が。ただし、ロードとかするのにコストがかかる StackOverflowException とか、OutOfMemoryException はあらかじめロードされており、これが !dae で見えるからと言って、必ずしも発生しているわけではありません。あっ OOM 出てる！と思う前に、そういう処理かどうかを状況から見極めて判断してください。

- PSSCOR2 の入手先
Psscor2 Managed-Code Debugging Extension for WinDbg
https://www.microsoft.com/download/en/details.aspx?displayLang=en&id=1073

- PSSCOR2 で使えるコマンドを紹介してくださってる Jin さんのブログです。
psscor2
https://blogs.msdn.com/b/jink/archive/2010/04/01/psscor2.aspx

Windbg のセットアップ、簡単な使い方は以下で紹介させていただいています。ご参考になれば幸いです。

[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(1)
https://blogs.technet.com/jpilmblg/archive/2009/02/21/debugging-windbg-1.aspx

[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(2) Ver 1.1
https://blogs.technet.com/jpilmblg/archive/2009/02/25/debugging-windbg-2.aspx

[Debugging] Windbg を使ってご機嫌ナナメな彼女の心を激しくデバッグ！(3)
https://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

2. 既定値ってどのくらい？

さて、ではこの現象の要因となる「私これだけ待つことができます」値 (私の心の中では『あみん値』と呼称しているのは内緒ですが…なんで「あみん」なの？というヤングマンはお母さんに聞いてみてください。) は以下に記載がある、MaxEnumContextExpiration です。この値は %Windir%\ADWS\ フォルダ配下にある、Microsoft.ActiveDirectory.WebServices.exe.config で設定されています。

3. 参考資料

What's New in AD DS: Active Directory Web Services
Updated: January 9, 2009
Applies To: Windows Server 2008 R2
https://msdn.microsoft.com/en-us/library/dd391908(v=ws.10).aspx

ご注意ください : 期間が長いクエリを実行していて、この現象に合致するかな？と思われる場合は試しにちょっとだけ伸ばしてみるのもありですが、基本的に上記の "Caution" にあるように、既定値を変えることはおすすめできません。やはり、30 分以上検索コンテキストをオープンにしておくのはあまりよろしくないですし、確認もしくは一時的にどうしても、大容量データを取得する必要がある場合などにちょっと変えるくらいがよいでしょう。あくまでも暫定回避です。お勧めの回避方法としては、やっぱりリトライになります。
なお、上記 MSDN の日本語訳があるのですが、全く逆の内容になっています。(2011/06/28 現在) 基本的に、原文も併せて読むことをお勧めいたします。

日本語訳
https://technet.microsoft.com/ja-jp/library/dd391908(WS.10).aspx

×
注意 
このパラメーターの既定値は変更することをお勧めします。
○
注意 
このパラメーターの既定値を変更することは推奨いたしません。

原文

日本語訳

4. まとめ

それでは皆様ごきげんよう。

ういこう@ヴァン・アレン帯デーキッス★

(※) 敬称略

…一応、Script 担当チームとして Hey, Scripting Guy! を気取ってみましたが、いきなりやらかした感じですみません。なんか引用とかして見たかったんです。すりこぎとか意味不明すぎますね。すみません。いきなりこのページをご参照頂いた方、当ブログは決して怪しいブログではありませんので、ご安心ください。ちなみに名曲です。

セキュリティ イベントログからアカウント名を取得する - コマンドレット Get-EventLog・Get-WinEvent

さて、世迷言は置いておいて、唐突ですが、システム管理者様に取って、必要不可欠ながら手がかかるので愛憎合いまみえることもあるものの一つ…そのなかにイベント ログは入っていらっしゃいませんか？特にセキュリティ イベントログ。監査増やした日にはあっという間にログが流れていくわ、WMI で取ろうとするとバッファサイズ超えることもありえるわ、だけど保存しなきゃ…と、すごく手がかかる子です。その辺の話は、過去熱く語ったことがあります。

[WMIは万能ではない] 大容量イベントログ取得時によくある問題と回避策 ～ Script からも wevtutil.exe が使える ～

https://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 をアップグレード頂く必要があります。

※ 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)
(※注 : 下記文書中にダウンロード直リンク群あり)
https://support.microsoft.com/kb/968929/ja

さて、セキュリティログに話を戻しましょう。

たとえば監査ログを取っていて、「何だか変…最近わたしの可愛いサーバに誰かが繰り返し入り込もうとしているようだわ！！気持ち悪い！誰か突き止めてとっちめてやるわ！」とか、気になる人のサーバをチェックしてあげて、「べっ…別に、あなたのためにやったんじゃなくて、会社のセキュリティのためなんだからねっ！」なんて思ったとします。でもイベントログ一個一個見てると疲れるので、アクセスしている連中のアカウント名を一気にリストにして晒し挙げ差上げてやりたいときとかあるかもしれませんよね。

では、アカウント名ってどうやってとったらよいのでしょう？実は、セキュリティ イベントの中の「アカウント名」って独立したプロパティではなく、イベントログ エントリに関連付けられている文字列の中に紛れていて、抜き出さないといけません。案外面倒なのです。イベント ビューア上では綺麗にみられるのに！と思われる方、イベント ビューアは健気に水面下で激しく水を掻く白鳥のように実はがんばっているのです。材料のイベント ログそのものは XML の面倒なデータそのものだったりするのです。イベント ビューア、がんばってます！

ではアプローチ方法はないのかというと、少々泥臭い方法を取らなくてはなりません。

(1) Get-EventLog コマンドレットの場合

イベント ログ エントリに関連付けられている置換文字列 "ReplacementStrings" を取得し、配列番号を指定して抽出する。

一般的には、アカウント名は ReplacementStrings の二番目の配列 (ReplacementStrings[1]) に格納されていますので、この配列[1] を取得する対処を実施します。なお、これはあくまでも一般的なログの話であり、すべてのイベントログに共通する処理ではないことに注意が必要です。

参考 : EventLogEntry.ReplacementStrings プロパティ
https://msdn.microsoft.com/ja-jp/library/system.diagnostics.eventlogentry.replacementstrings.aspx

(2) Get-WinEvent コマンドレットの場合

■情報を抽出する

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 : アカウントが “-” ハイフンになっている場合もある

実行結果例)

■イベントログの Property 要素数

イベント ビューアで個別のイベントを開くと、[詳細] タブが選択できます。このタブには、XML が表示されています。

例)

イベント XML: <Event xmlns="https://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 として取得できます。一例をあげますと、以下のような形になります。

上記例では、(Event)ID、Keywords、Provider Name、Task の要素を取得して表示しています。一方、<EventData> 要素配下にあるデータを取得する際は、上述の<System> 要素内にある値と異なり、EventData のひと塊の配列として取得後、添え字（インデックス）を入れて分解する必要があります。

■EventData の文字列を分解する - イベント ID 4624 の場合の例

※ 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 ごとに配列のデータ配置が違う可能性がある

イベントは、各ソース、ID 毎にフォーマットが異なります。「概ね共通して同じような形式」ではありますが、明示的に「配列の何番に何を入れなければならない」ということは決まっていないということがどうしてもあります。また今後も追加、変更される可能性などもあり、実際に確認いただきつつ必要な情報の取捨選択を実施頂く必要があります。Message プロパティ内にどれだけのイベントログ内の情報を採れるかについては、そのイベントログの構造に依存する動作になります。コマンドレットはイベントログに取得を依頼したあとは、そのログが返すデータをそのまま格納するため、イベント ログそれぞれがどのようにデータを渡してくるかまでは（明らかに NULL の場合などを除き)特に形式や中身を意識しないためです。

■参考資料

Select-Object
https://technet.microsoft.com/ja-jp/library/dd315291.aspx

Windows PowerShell の機能 Select-Object コマンドレットの使用
https://technet.microsoft.com/ja-jp/library/ee176955.aspx

Windows PowerShell 続すてきなパイプラインの手法
(Select-Object による要素の rename など)
https://technet.microsoft.com/ja-jp/magazine/ff394367.aspx

Windows PowerShell: コマンドを再利用可能なツールにする
https://technet.microsoft.com/ja-jp/magazine/gg537351.aspx

さて、すごく久しぶりに書いたのでちょっと緊張しております。少しでも皆様のイベントログ管理の負担が減って、すりこぎにされそうな日々が解消しますように。

それでは皆様ごきげんよう。

ういこう@人生はすりこぎなんだよ! OH MY BABYこのブルースを聴いてくれ!!

はじめに : 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 年 4 月 1 日 (Japan)
日本マイクロソフト株式会社

■Microsoft最新情報

日本マイクロソフト、ID 管理ソリューション “F!M Zolo R2” 開発者向け試用版の提供を開始

～ Kinect による同期管理とヒューマンリソースの仕事力計測に対応 ～ ※この記事はエイプリルフールの記事です※

マイクロソフト コーポレーション（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 の未来を拓く
https://www.microsoft.com/japan/opinionleaders/economy_ict/110302_2.mspx

Forefront Identity Manager のすごい効能が明らかに！！明かされる隠された機能... v1.1
https://blogs.technet.com/b/jpilmblg/archive/2010/04/01/fim2010-forefront-identity-manager.aspx

◆マイクロソフトに関する詳細な情報は、下記マイクロソフトWebサイトを通じて入手できます。
 
日本マイクロソフト株式会社 Webサイト https://www.microsoft.com/japan/
マイクロソフトコーポレーション Webサイト https://www.microsoft.com/ 
  
  *Microsoft、Windows Server、Visual Studio、SQL Server、Forefront、Hyper-V は、米国 Microsoft Corporationの米国及びその他の国における登録商標または商標です。
*Windowsの正式名称は、Microsoft Windows Operating Systemです。
*その他、記載されている会社名、製品名は、各社の登録商標または商標です。

*****　この記事は 2011 年エイプリルフールの企画です。*****

2011 年 3 月 22 日火曜日 9:30 AM 以降、サポート窓口は Premier / Professional サポートとも、すべての深刻度で受付が再開されます。これまでお急ぎのところ、ご不便をおかけしておりましたことをお詫び申し上げます。
なお引き続き災害復旧事案の対応を優先するため、お電話のお問い合わせの際も引き続き受付窓口でいったんお受けした後、担当エンジニアよりコールバックする対応とさせていただきます。弊社からお客様へのご連絡が遅れる場合もございますが、何卒ご理解のほどお願いいたします。

サポート窓口の対応のアップデートにつきましては、下記の web および本トピックにて随時更新いたします。

https://support.microsoft.com/select/?target=assistance&ln=ja

なお、先日の地震発生に伴い、弊社オフィスも輪番停電の対象となっております。停電時のバックアップ体制は別オフィスなどにも構築しておりますが、停電や電話回線事情により、以前にお伝えしている各担当エンジニアの直通電話番号は 3/16 以降一時着信できない場合があります。引き続き、上述の通りコールバックにて対応いたしますので、メールにてご連絡頂ければ幸いです。誠に恐縮ではございますが、諸般事情のご理解を賜りたく、何卒よろしくお願い申し上げます。

※ 下記にも反映されました。

https://msdn.microsoft.com/ja-jp/default.aspx 最新ニュース
https://technet.microsoft.com/ja-jp/default.aspx IT 担当者向け最新情報
https://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)