[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]Get-AD* 系コマンドレットの検索クエリは既定値 30 分 でタイムアップする(MaxEnumContextExpiration)

皆さんごきげんよう。ういこです。最近 PowerShell の案件も微妙に増えております。SEO 対策をあざとく狙い、今回も逝ってみましょう PowerShell! 今日のお題は、「Active Directory 系コマンドレットは 30 分でタイムアップすることがある」です。 【今日のお題】 Active Directory 系コマンドレットは 30 分でタイムアップすることがある (対象 OS とサービス : Windows Server 2008 R2 / Active Directory Web Service) さて、「夏を待てない」と歌ったのは國生さゆりさん (おニャン子クラブ会員番号は 8 番) ですが、コマンドレット君も、あみんのようにいつまでも待てないことがあるのです。 Active Directory といっても、運用形態は様々。オブジェクト数も数個から数万ということもありえます。たとえば数万のオブジェクトを動かしたり、取得したりするとき、いつまでも時間がかかるような事態はパフォーマンスの観点など、まあ色々よろしくありません。というわけで、既定では get-ad 系コマンドレットは、検索クエリのオープン時間に対し、30 分の制限値を持ちます。この制限値は Active Directory Web サービスの Config ファイルのパラメーターで設定されています。 1. 30 分以上のクエリ要求を行うと SocketException やらいろいろな例外が発生することがある なかなかいやらしいことに、30 分以上経過したときの PowerShell コンソール上に出てくる例外、エラーの発生パターンは一定ではありません。ADException…

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

[重要なお知らせ] 東日本大震災(東北地方太平洋沖地震): サポート対応について (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

[Info]Windows Azure 90日間 無料パス (東北地方太平洋沖地震 対応) をご利用下さい!

東日本大震災の被災者の皆様、またそのご家族や関係者の皆様、心よりお見舞い申し上げます。 東京の街を歩けば、ガソリンスタンドで渋滞が起きていたり、コンビニの棚が空っぽだったりすることを除けば、とても穏やかないつものような日々が続いているように見えます。でも、本日 (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) https://twitter.com/search/%23JAZUG #AzureJP (Windows Azure 日本語情報) https://twitter.com/search/%23azurejp 参考 MSDN Windows Azure デベロッパーセンター…

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

[Info] ライフサイクル : .NET Framework 2.0 と Visual Studio 2005 は 2011/04 にメインサポート期間終了、延長サポートに移行します

みなさんごきげんよう。ういこです。今日はひな祭りです(2011/03/03 現在)が、大人の階段を登りきった私には関係ないですよ。 さて本日はそんな自虐的な 3x 歳の乙女心より .NET と VS2005 のライフサイクルの話をご紹介させていただきますね。 【今日のお題】 ・.NET Framework 3.0 以降の新サポート ライフサイクルポリシーを再確認しよう ・Visual Studio 2005 および .NET Framework 2.0 のメインストリームは 2011/04/12 に終了 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] サポートライフサイクル :…

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