[Info]2011年7月の窓口休業予定(Premier/Pro) : 7/5 ALL,7/12 PM, 7/18 ALL

平素より弊社サポート サービスをご愛顧くださいましてありがとうございます。本日は 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,…

0

[閑話休題] Relocation Notice – UikoU ありがとうございました!

今日は、私事ですがひとつご報告させていただきます。 本日 7 月 1 日より、ILM / WMI / ADSI とか色々担当チームというかユニットから、SQL Server サポートチームに新たなチャレンジをする運びになりました。 これまで、私が担当させていただいたお客様、当ブログをご覧いただいていらした皆様、本当にお世話になりました。 思えば、2008 年、Windows Media / DirectX サポートからいきなりまったく触ったことがなかった ADSI、ILM の世界に飛び込んだときはさっぱりとっかかりもなく、こりゃまずい…私首になっちゃうわよとどきどきしたのを今でも鮮やかに思い出します。ところがそこに、ぴろとくんや、おとうさんという卓越した才能を持つ人材がそろって、ここまでくることが出来たとしみじみ思っています。そして何より、サポートをご利用いただいていらっしゃる皆様の声が、私たちにとってどれだけ励みになるか。あの長々としたアンケートに答えてくださっただけでもありがたいのに、おかげさまで本当によい評価をいただくことが出来、まただめな対応の際は、建設的なフィードバックをチームで何度も検討し、方針を修正するなどして進めてきました。本当に、ありがとうございます。 今後は、ILM (など) の担当は、ぴろとくんとおとうさんの二人になります。 このブログはどうするのかと多数お尋ねをいただいていますが、基本ぴろとくんか、お父さんが担当になりますので、消されたりはしません。私も、少し書くと約束したコンテンツがまだあるので、しばらく私も書き込むことになります。それが終わったら、私は次のチャレンジに完全に移行することになるのだと思います。なので、今しばらくお付き合いいただければ幸いです。なお、次のチームもブログは持っていますが、今のところ私が書くというような予定はありません。 今日は、久々に技術的な話がまったくないつまらない、完全に私事の記事で恐縮です。このまま書かないでおくことも考えました。ですが、小さなプロダクトの割りに、たくさんのページビューもおかげさまでいただくなど、私たちにとって、とても励みにさせていただいた皆様に一言お礼を申し上げたく、書かせていただきました。 つたない文章を面白いといってくださった方、Tech Fielders の集いで実際に face to face でお会いできた方、かけがえのない大切な、大切な思い出です! ぴろとくんとお父さんの今後の ILM プロジェクトを、皆さんどうぞ今後ともよろしくお願いいたします。 皆様のますますのご清栄を心より願っております。 ありがとうございました。 Appendix / サイトの PageView コメント : アクセス解析を導入したのは2009年でした。教えてくださった安納さんありがとうございます。 コメント : やっぱりいっぱい書いてた月は強いです。 コメント : 今年です。やっぱりきっちり書いていないと、伸びもちょっとイマイチですね。 ページビューランキング (URL 別)…

0

[PowerShell] HEY YOU WHAT’S YOUR NAME?アクセスしてるのはお前さBABY!アカウント名をセキュリティログから取るぜ!

皆さんごきげんよう。ういこです。気が付いたら 6 月。カエル型宇宙人がいたら肌艶が良くなりそうな気候になっていますが私の肌艶は全然よくなりません。ヒアルロン酸が足りないんでしょうか。さて今日は、『セキュリティ イベントログを PowerShell で取る際「アカウント名」を引っこ抜く方法』をお送りします。 【今日のお題】 オレをすりこぎにしちまった奴 そいつは誰だ 誰なんだ HEY YOU HEY YOU WHAT’S YOUR NAME? — 左とん平「とん平のヘイ・ユウ・ブルース」より (※) 敬称略 …一応、Script 担当チームとして Hey, Scripting Guy! を気取ってみましたが、いきなりやらかした感じですみません。なんか引用とかして見たかったんです。すりこぎとか意味不明すぎますね。すみません。いきなりこのページをご参照頂いた方、当ブログは決して怪しいブログではありませんので、ご安心ください。ちなみに名曲です。 セキュリティ イベントログからアカウント名を取得する – コマンドレット Get-EventLog・Get-WinEvent さて、世迷言は置いておいて、唐突ですが、システム管理者様に取って、必要不可欠ながら手がかかるので愛憎合いまみえることもあるものの一つ…そのなかにイベント ログは入っていらっしゃいませんか?特にセキュリティ イベントログ。監査増やした日にはあっという間にログが流れていくわ、WMI で取ろうとするとバッファサイズ超えることもありえるわ、だけど保存しなきゃ…と、すごく手がかかる子です。その辺の話は、過去熱く語ったことがあります。 [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…

0

[WMI]Win32_PerfRawData_Tcpip_NetworkInterfaceは名称が重複したNICがある環境では各カウンタの実体を識別することができない(制限事項)

本日のトピックは、WMI の クラスの組み合わせで発生する制限事項についてのお話となります。 [今日のテーマ] WMI の Win32_NetworkAdapter や Win32_NetworkAdapterConfigration クラスでは、同じ名称でシステムに登録されているアダプタがある場合、Name プロパティは登録名からそのままもってくるため、値が重複して取得されてしまう。このように複数同じ名前で登録されたネットワーク アダプタが存在するシステムでは、Win32_PerfRawData_Tcpip_NetworkInterface (Win32_PerfFormattedData_Tcpip_NetworkInterface) クラスのカウンタと結びつけることができない。 はじめに : NIC 自身のシステムへの登録の仕方に Name プロパティの取得結果が影響される システムに登録されたネットワーク カード (NIC) の情報を採取する際に WMI の Win32_NetworkAdapterConfiguration および Win32_NetworkAdapter クラスを使用する例は多くあります。しかし、これらのクラスの Name や Description プロパティだけでは複数の同じ種類の NIC それぞれを識別する指標にはなりえません。 Name や Description プロパティなど、上記の WMI のクラスが返すプロパティ情報は、その環境の NIC がセットアップされる際にどのように自身の情報をシステムに登録したかに依存します。つまり、同じ種類の NIC を複数セットアップする際に、システムにそれぞれの NIC 毎に同じ名前で登録してしまう作りのデバイスの場合、Name や Description プロパティの値がすべていっしょということも起こりうるということになります。アダプタによっては、システム登録時複数同じ種類のアダプタが存在していても #1 、#2 のように識別子を付けず同じ名前で登録してしまうものがあるのです。 図…

0

[重要なお知らせ] 東日本大震災(東北地方太平洋沖地震): サポート対応について (3/21 23:00 Update – 22 日火曜から全深刻度案件受付再開のお知らせ) Ver.6

重要なお知らせ [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 サポートチーム…

0

[PowerShell] PS1 ファイル実行時にとる引数をコマンドレットみたいにタブ補完したい!

みなさんごきげんよう。ういこです。花粉はビシバシ飛んでいるのに寒くて仕方ないアンビバレンツな日々ですが皆様いかがお過ごしでしょうか。 今日は、「コマンドレットみたいにボクの PS1 ファイルの引数もタブ補完させる方法」をご紹介します。対象は PowerShell v1.0 – 2.0 共通です。 【今日のお題】 タブ補完出来たっていいじゃないか、PS1 ファイルだって PowerShell だもの。 by ういこう a. PowerShell のタブ補完の素晴らしさに思いを馳せる PowerShell がすてきだな、と思わせてくれる瞬間は、何といっても「あのすさまじく長いこともあるコマンドレットの名前をタブでガッツリ補完してくれる」というあの至れり尽くせりな感じ」であると私は思います。正直「コマンドレット名…なんでこんなに長いのさ…」と思うなが~いコマンドレット名もいっぱいありますが、大丈夫!ちょっと打ち込んで、タブを打てばどこかの黒い執事さん張りに「あなたのお探しのコマンドレットはこれでございましょうか」くらいの勢いで提案してくれます。 素敵! ありがとう PowerShell!これでうろ覚えでも使えるよ!ちなみにカレントディレクトリにあるファイルも補完してくれちゃったりします。これはコマンド プロンプトと同じですね。 例 コマンドレットを探してみよう (Get-ADAccountAuthorizationGroup) get-a まで入力して、おもむろにタブキーを押そう 候補を出してくれますよ!”Get-ADAccountAuthorizationGroup”、な、ながっ!! ※ すぐに結果だけほしいの…というあなたには、あるいは get-help get-a* のように、ワイルドカードで一気に出しちゃうという手もお勧めです さて。それで、タブ補完って、実はコマンドレット名だけじゃなくて、そのコマンドレットの引数まで出してくれるんですよ。 これがまた特に switch と呼ばれる、変数がほしいわけじゃなくて、処理を分岐させる判断のために使うタイプの引数とかに威力を発揮。なが~い引数名いちいち打ってられないじゃないですか。だってタイプミスしたらまた長いの打ち直しだし。 上記のコマンドレットを例にとると、いくつか引数を取りますが、いちいち Get-Help で見るの面倒。もしくはうろ覚えで機能は覚えてるけど引数名超覚えてないという方も大丈夫。- (ハイフン) を打って、タブを打つと、引数名まで保管してくれます。 いやほんと便利ですよね。 b. PS1 (PowerShell スクリプト ファイル) にも引数を取るつくりの場合、タブ補完って使えないのかな? コマンドレットがバリ便利ということはいやってほどわかりますが、それを組み合わせてスクリプト ファイルにした場合、引数を取ることってありえますね。そうした場合、PS1 実行時に使う引数名をコマンドレットみたいに補完出来たらいいなぁと思うことがあるのではないでしょうか。…

0

外部サービスに依存した処理をPC起動直後に呼び出す場合はサービス起動タイミングによって失敗する可能性を考慮する必要がある

みなさんごきげんよう。ういこです。私事ですが顔面半分にビッシリと赤い発疹がでて、洒落じゃなく顔面崩壊してますが皆様はいかがお過ごしでしょうか。本日は「外部サービスに依存した処理(しかも 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…

0

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

皆さんごきげんよう。ういこです。今日はイベントログのとり方でよくある問題とその対処案についてのお話です。 運用管理をしていてあるある!なニーズとして、イベントログを定期的に保存して、出来ればアーカイブして保存しておきたいなんてことがあると思います。しかもバッチ処理にして、タスク スケジューラなんかで人間様がいなくてもサーバ内の小人さん動かして定期的に保存させちゃおうとか。そんなニーズ、ありませんか。 では、全国津々浦々のイベントログ大好き管理者様はどのようにしてイベントログの取得をされていますか。問い合わせに来るものを見る限りでは、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 が発生するなど、揺らぎが良く見られます。 0x8004106c WBEM_E_QUOTA_VIOLATION    0x80041006 WBEM_E_OUT_OF_MEMORY 0x80041032 WBEM_E_CALL_CANCELLED (※ まれに 0x80041001 WBEM_E_FAILED という形で異常終了することもあり) 調整方法としては、WQL 文で取得してくるイベントログの時間帯を指定することで、一回に扱うデータサイズを減らすということしかありません。ただ、時間を指定しても、その時間帯にたまたまアクセスが集中し、ファイル監査のログが大量発生した場合などは、データサイズがスパイクするため結果としてエラーが発生する可能性があることは避けられません。 なぜこうしたエラーが起きるのか 0x8004106C (WBEM_E_QUOTA_VIOLATION) は、WMI サービスにより消費されるメモリが割り当てられたメモリの制限に達したことを意味します。また、このエラーが発生する状況下では、同じクエリを同じデータストアに対して実施した場合であってもリソースを多く消費しシステムが不安定になることを防ぐために処理をキャンセルすることがあり、その場合に 0x80041032…

0

[Vista/2008]リモートマシンへの認証を複数回繰り返し実行するとLSASS.exeのCPU使用率がスパイクする(KB:2028484/修正モジュールあり)

みなさんごきげんよう、ういこです。今日は障害情報「リモートマシンへの認証を複数回繰り返し実行すると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…

0

[WinRM/WinRS] 簡単リモート管理!WMI の代わりに使ってみませんか?

皆さんごきげんよう。ういこです。最近森ガールの後継の山ガールが流行ってるらしいですね。私もついカッとなってファーベストを試着したら山狩り上等なマタギ感溢れるコーデになってしまいそして僕は途方にくれるな秋ですが皆さま如何お過ごしでしょうか。 さて、今日は 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…

0