[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

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

[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

[WinRM] トラブルシュートはエラーとイベントビューアから確認を開始するべし

皆さんごきげんよう。ういこです。今日は「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…

0

[Info] VBScript / ADO RecordSet : 時刻を文字列として扱う際 “0:00:00” の場合は文字列が Drop されてしまう

本日は VBScript で時刻を扱う処理を実施する際、システム時刻の 0 時 0 分 0 秒に実行すると、日付は取れるものの時刻が返却されない現象が発生するという事象についてご報告申し上げます。 問題の概要 VBScript (WScript/CScript) の時刻を扱う処理を実施したタイミングがシステム時刻の 0 時 0 分 0 秒である場合、日付は取れるものの時刻は取り扱われません。 この現象は製品の設計上の動作であり、障害ではありません。またこれは時刻取扱を行う関数動作に起因するものではなく、Scripting Runtime 内部で時刻の戻り値を文字列に変換する部分が原因です。 再現コードおよび再現例 Wscript.Echo Now ■00:00:00の場合(現象発生時) 2010/9/6 ■00:00:01の場合(正常時) 2010/9/6 00:00:01 原因 例えばコンソール に出力する、ファイルに出力するなどの動作を行う場合などは、Scripting Runtime 内部で時刻データを文字列に変換してから値を引き渡す動作になります。この際 Scripting Runtime 側での内部では結果的に VarBstrFromDate() API を使用して "時間:分:秒(hh:mm:ss)" に変換いたします。この動作の際、内部実装では、明示的に時間:分:秒がすべて 0 の場合は、これらを文字列として変換しない処理となります。 日付型のデータは内部的には浮動小数点型 (日付が整数部で時刻が小数部) で扱われますが、時刻が 0:00:00 のときは xxx.0 = xxx というように小数部を省略した形式で扱えることもあり、String 型への変換時には…

0

[WMI : C++] WMI プロバイダ以外 CoCreateInstance には CLSID_WbemAdministrativeLocator クラス識別子を指定してはいけない

今日は WMI コンポーネント使用時の CoCreateInstance() で指定するクラス識別子の違いについてのお話しをご紹介させていただきます。 【概要】 WMI を使用するプログラムを C++ で作成する際に、まず IWbemLocator インターフェースを取得して、そこから WMI の実行ターゲットコンピュータ(ローカルまたはリモート)の IWbemServices インターフェース (= WMI サービス) を取得する処理を行います。 このまず最初の IWbemLocator インターフェースを取得する際に CoCreateInstance() の第一引数 REFCLSID には、プログラムの目的によって以下のように指定するクラス識別子を使い分ける必要があります。 ・WMI プロバイダ自体(あるいはフィジカル コンシューマー)を作成している場合 ⇒ CLSID_WbemAdministrativeLocator クラス識別子 ・それ以外の一般的な WMI クライアント アプリケーションの場合 (端的にいえば WMI の処理を実施するだけのアプリケーション) ⇒ CLSID_WbemLocator クラス識別子 【詳細】 -a. CoCreateInstance() の使用法について (1) WMI プロバイダ作成の場合 – “CLSID_WbemAdministrativeLocator“ 例えば、以下の MSDN ライブラリ…

0

[WMI基礎] トラブルシュートの基礎知識 (4)/n : アクセス拒否発生!WMIPrvSEの実行ユーザの権限を確認しよう!

皆さんごきげんよう。ういこです。 今日は WMI のトラブルシュートの続き、”アクセス拒否系 – WMI プロバイダの実行権限は適切に割り当てられているか?” をお送りします。 WMI のアクセス拒否系でよくひっかかるのが、WMI をコールしたプロセスの実行権限が適切なはずなのに、なぜかアクセス拒否が返るというところです。実は、このとき WMI の呼び出し側の他、その先の WMI のプロバイダ ホストと呼ばれるプロセス実行アカウントの権限も同時に考慮する必要があります。 以下、これまでのあらすじです。 ************************************************ [WMI基礎] トラブルシュートの基礎知識 (1)/n : WMI の動作基盤のテストから始めよう http://blogs.technet.com/jpilmblg/archive/2010/04/04/wmi-1-n-wmi.aspx [WMI基礎] トラブルシュートの基礎知識 (2)/n : WMI 詳細ログと WMIDiag ダイジェスト http://blogs.technet.com/jpilmblg/archive/2010/04/05/wmi-2-n-wmi-wmidiag.aspx [WMI基礎] トラブルシュートの基礎知識 (3)/n : DCOM の既定の構成であるか確認し、動作するか確かめてみよう http://blogs.technet.com/jpilmblg/archive/2010/04/10/wmi-3-n-dcom.aspx ************************************************ WMI を使用すると、WMIPrvSE.exe というプロセスが WMI を呼び出したプロセスとは別に立ち上がります。この WMIPrvSE は、”WMI プロバイダ ホスト” とよばれ、実際の WMI の処理の仲介を行い、その先の実際のシステムからの情報取得などを行うモジュールとやり取りなどを行います。  一般的には、WMI…

0

EventLog を取得する方法 ~ とにかくイベントログを早くゲットしたい! ~

皆様ごきげんよう。ういこです。 今日は微妙にお問い合わせが多く、それでいて環境ごとに動作に差異が出やすい「イベントログの取得」についてのお話です。 イベントログの監視などを行う際、皆さんはどんな手段をご利用されていますでしょうか。 Technet のスクリプト センターでは、WMI を使っているような気がします。 実際、ネットに数多くあるステキなサンプルなども、WMI を使って取るものが多いかと思います。 WMI は、C++ で使うと鬼のように厳しいですが、Script などで使うとあら不思議あっという間に優しい子になります。そんなこともあり、巷では WMI でログを取るのが多いんだろうなぁと思います。(C++ だったら、後述の API 使ったほうがたぶん楽なきがするです) しかし、そんな優しい彼女 (WMI) も、ひとつ致命的ともいえるかもしれない欠点が…。 そう、鬼 の よ う に 鈍 く さ い の で す そんなわけでイライラ~な気分な方も多くいらっしゃるのではないでしょうか。 そこで、WMI よりも高速にイベント ログを取得する手段につきまして検討してみたいと思います。しかし、残念なことに、現行巷で元気に動作中の OS のバージョンすべてを網羅する手段はありませんでした。ただし、それぞれ Windows XP 以前とそれ以降で、それぞれ手段を変えれば、うまくいきそうです。 はじめに : イベントログは OS によってベーステクノロジが違いますです Windows のイベント ビューアの内部動作 Windows のイベント ビューアは、Win32 API で実装されています。可能な限り効率的なイベント…

0

[~W2K8 / W2K8R2] Windows on Windows (WOW) の最大サポート CPU 基数はいくつ?

皆様御機嫌よう、ういこです。 今日は、せっかく今期から Windows SDK 一家の軒下を借りるようになったので、たまには Windows API についてのことでも書いてみようと思います。 Windows API というか、Windows の仕組みの話になっちゃいますが…。 Windows Server 2008 R2 から、64bit CPU に特化されましたことは、これまでのサーバー製品が 64bit 版にどんどんシフトしていっている流れ的にさもありなん、という感じはあったものの、ついにきたなという思いでした。ただ、64bit CPU が出てかなり時間が経つとはいえ、既存のアプリケーション資産は 32bit でビルドされたもの(32bit Windows 上で動作することを想定して作成されたものという意味)がまだまだ現役で動いている、という状況が大半ではないでしょうか。 Windows On Windows (WOW) Windows OS では、64bit OS 上でも、32bit アプリケーションを動作させる仕組み "Windows On Windows" というサブ システムがあります。32bit アプリケーションは、このサブ システム上で動作します。あくまでもサブ システムなので、エミュレーションしているようなものです。そのため、厳密に 32bit Windows と同じ動作にはならないことがあることに注意しなくてはなりません。昔、Windows が出始めのころ、コマンド プロンプト上で DOS アプリケーションを動かした方で、挙動が微妙に違うと悩んだかたもいらっしゃるでしょう。それと同じことになることを頭に入れる必要があります。 CPU の最大サポート基数について サーバー上で動作させるアプリケーションである場合、WOW…

0