アプリケーションでレジストリを参照している時、なぜかレジストリの中身が更新されてしまい思うように動かないという事態が発生し、レジストリを更新したのが何者なのか？を特定する為に監視したいという話がありました。

そこで、ちょっと使い方を気になっていたProcessMonitor (ProcMon.exe) を使ってみることにした。

ProcessMonitor の導入

ProcessMonitor はSysInternals Suiteの中の一つとして提供されています。
もちろん単独でもダウンロード可能

Process Monitor -Windows Sysinternals
http://technet.microsoft.com/ja-jp/sysinternals/bb896645.aspx

Windows上で動作するプロセスの様々な動作をリアルタイムに記録するという、障害調査する上では中々頼もしいツールです。
実行ファイル単独で動くので、比較的導入に対するコストもかからない。

起動とフィルターの設定

ProcMonを起動するとフィルター設定が出てくる

デフォルトで設定されているフィルターは基本的にはそのままでいいのだが、
ここではわかりやすくする為に選択してすべてをRemoveしてしまう。

その後、監視対象となるレジストリパスを登録する。
登録は左から「Path」、「is」、「レジストリパス」、「Include」でいい。

ここでは、テスト的にODBC設定を監視してみることにする。

 気を付けなければいけないのは、レジストリパスの指定。

RegEdit等でキーをコピーすると、通常

HKEY_CURRENT_USER\Software\ODBC\ODBC.INI

のように始まる。
このパス名をフィルターに適用すると対象としてみてくれなかった。

このような場合は、

HKCU\Software\ODBC\ODBC.INI

のように省略キー名称で設定する必要がある。
省略キーの対応は以下の通り。

HKEY_USERS	→	HKU
HKEY_LOCAL_MACHINE	→	HKLM
HEKY_CURRENT_USER	→	HKCU
HKEY_CLASSES_ROOT	→	HKCR
HKEY_CURRENT_CONFIG	→	HKCC

なんで完全キー名称ではだめで、省略キー名称じゃなきゃいけないのかは正確な理由はわからないが、単純に表示するリストビューの幅を節約するために省略して保存。
その保存したものにフィルターするから適用されないんじゃないかと推測している。

基本的に起動＝キャプチャ開始状態になる。

上記の画面キャプチャにて、左下に「No events」と表示されている。
実は、デフォルトの設定ではここにものすごい数のイベントが、秒単位で増えていくことが表示される。
これは、デフォルト設定ではProcMonがフィルターで設定したイベント以外も全て記録しようとしているからだ。

フィルターで設定したものだけを記録する形にしないと、メモリやディスクを圧迫することになるので「Filter」→「Drop Filtered Events」にチェックを入れる。

 基本的な設定はこれで完了したので、動作を確認してみる。

 RegEdit.exeで対象のレジストリにアクセスすると

 問題なく記録された。

 “レジストリの監視”と言う話でいえば間違ってはいないのだが、もう少し手心を加えると

• レジストリのPath指定で「is」ではなく「begins with」を指定してKEY配下のVALUEに対する操作を検知する
• レジストリの編集のみを記録するため、以下のようなフィルターを追加する
  • 「Operation」、「is」、「RegQueryKey」、「Exclude」
  • 「Operation」、「is」、「RegEnumValue」、「Exclude」
  • 「Operation」、「is」、「RegOpenKey」、「Exclude」

などなど。

他にも設定していけば、自分の求める情報をピンポイントで手に入れることができる。「Operation」に対して「RegSetValue」を「Include」で設定してもいいのかもしれないが、それはレジストリに対しての操作が何で行われていたかがはっきりしている場合に限られる。削除して追加したかもしれないし。

そういう意味では、上記のように関係ないものを除外するフィルターを追加していくのがいいのではないかと考えている。
試しに適当に動かしてみて、キャプチャーした内容を見たうえで除外のフィルターを作っていくのが一番確実だと思われる。

 

これで監視出来ているといえるが、もう少し手軽に監視をするために設定情報をエクスポートしておいて、バッチにて起動・停止出来るようにしておく。

「File」→「Export Configuration…」で構成ファイルをエクスポート。
その後、バッチファイルでprocmonを次のような形で呼び出す。

procmon /minimized /backingfile <出力ファイルパス>\%date:~-10,4%%date:~-5,2%%date:~-2,2%%time:~-11,2%%time:~-8,2%%time:~-5,2%.pml /loadconfig <構成ファイルパス>

停止時には

Procmon /terminate

で停止するバッチをたたく形にする。

一応、最小化状態で立ち上げるための「minimized」を指定しているけど、タスクバー上に出てしまう上にバッチのDOSプロンプトまで出てしまうので正直微妙なのだが、まぁ手軽にはなったかな。

再起動時の動作に対して疑いたいときは、「Option」→「Enable Boot Logging」をONにする。

ダイアログが出てくるが、とりあえずそのまま「OK」でいい。

再起動後にProcMonを立ち上げると、ログを保存するか聞いてくるので保存すればOK。ただ、これに関しては試してない。
Helpには

If you configure boot logging and the system crashes early in the boot you can deactivate boot logging by choosing the Last Known Good option from the Windows boot menu (which you access by pressing F8 during the boot).

なんてことも書いてあるから、使うときは少し注意したほうがいい気もする。

今回はレジストリの監視にProcMonを使ってみたが、このツールは使いこなせばいろいろな調査に役立つ。
SysInternalsのツールはこういう役立つのが実に多いんだけど、使い方に慣れるのに少し手間取ってしまったりするな。

参考:Process MonitorについてのTips　- Ask Core
http://blogs.technet.com/b/askcorejp/archive/2010/01/29/process-monitor-tips.aspx

ずっとこれまでWindows使ってて、今更ながらに基本的な事に驚く事がある。

ファイルの名称は基本的に大文字／小文字を区別せずに考えられている。
同一のフォルダ内に「hoge.txt」と「Hoge.txt」は存在出来ない。

このように、英数ファイル名において大文字／小文字が異なるだけのファイルを上書きすると、
中身は当然のように上書きしたファイルによって更新されるのだがファイル名は更新されずに
そのまま維持されてしまう。

ファイルの上書きという行為は、削除してからの作成ではなくて中身の更新と言う動きなのだろうか。

実はこれ、試しにやってみたらMacでも同じ動きをした。

基本的に問題が起きるケースは少ないとは思うのだけど、作成したファイルをそのまま
Webサイトへとデプロイする場合にはパスが謝った状態となってしまうので気をつけなければ行けない。

うーん、何とかならんのかな。これ。

普段、Macで利用しているSkitch。Windows版はなかったのですが、Windows8のStoreには実はあったりします。
もちろん無料で。

 

ただし、Store Appの場合はサンドボックスで動くので、Mac版のようにスクリーンをキャプチャすることはできません。
当初、リリースされていたSkitchは、画像をピクチャフォルダから取込む事しか出来ずに使い勝手に関していうと怪しいものでしたが、更新をかけてみたらクリップボードから取得する事も出来るようになり、使えるようになっていました。

画像の取得方法としては、地図・写真（ピクチャフォルダ）・クリップボードの3種類が用意されていて、その他に無地に絵を描くことも可能になっています。

なので、利用方法としてはPrint Screenにて画像をキャプチャして、Skitchを起動。”貼り付ける”を選択して使うといった形になります。

 

これまでもやろうと思えばできたのですが、地図との連携はちょっと面白いと思いました。

・・・・

 

あれ？

てっきりBINGのMAPと連携しているのだと思ったら、MapDataから取得しているようです。
見てみると、地図としてはさすがにGoogle Mapと比べると寂しいものがあります。
Appleの地図のように間違った情報が載っている訳ではないとは思いますが、情報量としては少ないかな、と。

この辺りは、使い方を検討するか、Google Mapをキャプチャして使うかと言った形で考えればいい事ですね。
Skitchの公式サイトにはWindows版に対しての言及がどこにも見当たらないと言うのが少し気になっているのですが・・・。
まだまだ試作品状態と言うことなのかな？

今後のアップデートがあるのであれば楽しみですね。

Windows7までは64Bit OSにおいて、管理ツール上のODBCデータソースは、64Bit版しか表示されておらず、32Bitを操作するときはSysWow64からわざわざ実行しなければならなかった。

実際の所、アプリケーションはまだ32Bitが主流だった事からか、Windows8では最初からコントロールパネルに両方表示されている。

 

エクセルのVBAからODBCを利用してOracleやDB2に対してアクセスして解析するツールを自前で作っていたので、その設定の為にいじって見ている。

これは64Bit版を表示した画面だが、32Bit版のデータソースも表示されており、”プラットフォーム”列によってそれを見分ける形となる。
ただし、それぞれのプラットフォームにあった管理ツールからでないと新規追加や構成の変更を行うことはできない。

使用するアプリケーションのプラットフォームにあったデータソースを定義しないと、そのアプリケーションでは接続することができない。

見てみると、Excelは32Bitで立ち上がっているみたいだ。なんでだろう？
ちゃんとMicrosoftのページに書いてあった。

64 ビット OS に Office 2010 のインストール DVD-ROM をセットした場合、既定では 32 ビット版 Office 2010 のインストーラーが起動します。これは、64 ビット OS 環境に対しても 32 ビット版 Office 2010 をインストールすることが推奨されているためです。
http://support.microsoft.com/kb/2248011/

 

これを見る限りでは、何も考えずに普通にインストーラーを実行してしまったので、32Bit版がインストールされてしまったのだ。

Microsoftの言い分としては、サードパーティー製アドイン等に対する互換性が意識されての話のようだ。デフォルトで立ち上がるIEも32Bitだし、OSが64Bitと言ってもなんだかんだ言ってメインは32Bitアプリケーションが多いんだなと実感。

実際のところ、それほどアドイン機能を使っていないので64Bitでもそれほど問題は無いとは思うのだけど、わざわざ入れ直すのも面倒なのでこのままで行く事にしました。

 

今回、Windows8に更新した一つの理由にディスプレイの変更があります。

これまでは15インチのディスプレイ2台を利用していました。解像度としては1280*1024が二つですね。

これが、新しく支給されたディスプレイは1920*1080の解像度を可能とするワイドディスプレイでした。

Windows8ではModern Style Appsが横にスクロールするモデルをとっているので、推奨としては1366*768以上。Windows7にするか少し躊躇していたのですが、これによって大きくWindows8へ舵を取った形となりました。

ただし、支給されたのは1台だけなので、ワイドディスプレイ＋通常（？）ディスプレイの組み合わせですが。
ワイドディスプレイを縦置きして、ソースやWebページの閲覧に使おうかとも思いましたが、まずはModern Style Appsの利用のために横置きしてメインモニタとして活用することにしました。

 

Windows8では複数のディスプレイに対しての対応がいくつか行われています。

これまで、マルチディスプレイを利用しているときはタスクバーがメインディスプレイにしかありませんでした。
Windows8では全ディスプレイにタスクバーを表示し、そこに何を表示するのかを選ぶことができるようになっています。

ウィンドウは移動させる事が多いので、基本的にタスクバーにあるボタンはすべて表示させる形。つまりデフォルトのまま今は使っています。

Windows8になって変更されたスタートスクリーンや、端にカーソルを持って行く事で表示されるチャームもそれぞれのディスプレイで表示させる事が出来ます。
また、ウィンドウをドラッグして全画面表示や画面半分へフィットさせるもそれぞれのウィンドウで可能になっていました。

各ディスプレイの境界には、端っこだけガードが仕掛けられていて、マウスをある程度の速さで動かして持っていくと隣のディスプレイにはカーソルはいかずに留まるようになっています。
面白いですね。

これらは地味に便利で、マルチディスプレイを利用した時にマウスカーソルをわざわざメインディスプレイに持っていかないと切り替えられないので面倒なのだ。

もちろん、マルチディスプレイしている人なんてキーボードで切り替えなりなんなりをしているから関係ないってのはあるかもしれないが。

ウィンドウを楽に画面半分表示にさせる事が出来る動きは便利なのですが、マルチディスプレイの対応に関しては中途半端な印象を持っています。
ディスプレイとディスプレイの境界側にフィットさせる事が出来ないのです。
そのため、この機能は現状ではマルチディスプレイ環境では使いづらい状態にあります。修正されないかな？

 

Modern Style Appsはと言うと、立ち上げた側のスクリーンで起動します。

つまり、一方はModern Style App。もう一方はデスクトップを表示と言ったシナリオも行えるし、ドラッグによって別のスクリーンにModern Style Appsを持って行く事も可能です。

色々と組み合わせて試してみたいですね

今回VistaからWindows8へ環境移行を行うにあたって、Windows転送ツールを使ってみたのでその備忘録を。
Windows転送ツールは、MCPの資格取得時に勉強していたので知ってはいたが、実際に使ってみた事は無かった。

開発を行っていると、設定周りには様々なゴミが残ってしまうため、移行時にそれらも一緒に引き連れてしまう事を嫌った為だ。
とは言っても、環境の移行で数時間を費やすのもそれはそれで馬鹿らしいし、やった事も無かったのでやってみたいと言う何とも安直な理由で今回試してみる事になった。

 

転送元での操作

まず、転送元の環境でWindows転送ツールを起動する。
転送ツールはWindows8のディスク内(/support/migwiz/Migsetup.exe)に入っている。

注意しないといけないのは、対応するビット数の転送ツールを使う必要があるところ。
今回私は、32Bit Vistaから64Bit Win8への移行だったので、わざわざ32Bit Win8のメディアから転送ツールを持ってきて起動した。
なお、Windows7には転送ツールが 最初からインストールされている為に、特にメディアから持ってくる必要は無いらしい。

 

 

転送ツールが開始される。”次へ”を押す

 

転送の方法としては３種類から選ぶ。
今回私は新しいPCへの移行で両方とも手元にあるのでネットワークを利用することにした。

 

Windows8の転送ツールを利用しているからか、選択肢は一つで”これは今までのPCです”を選択します。

 

すると、移行元のPCとしては作業が完了し、待ち状態に入ります。

この時、移行先のWindows8側で転送ツールを立ち上げずに”次へ”を押すと、移行は失敗してしまうのでこのまま、左下の転送ツールキーをメモって新PCへ移動します。上記の画像では「931-592」に当たる部分です

 

移行先での操作

移行先で転送ツールを起動して、転送ツールキーを入力すると自動で情報が確認され、転送する内容を選択する画面が表示されます。

ここで、転送元のPCから移行するプロファイルを選択します。
“ユーザー設定”を選ぶことでより詳細な内容まで選択することができます。

必要なものを選択したら”転送”を実行。
転送が完了したら確認画面が表示されます。

 

最終的に移行が完了したアプリケーションやプロファイルの情報をレポートで確認することができます。

このレポートは後々からでも確認することができるので、移行元のPCに何のソフトウェアを入れていたのかを確認するのに役立ちます。

ソフトウェアをインストールすることでチェックもつくので、何のソフトウェアをあとインストールしなければいけないかがわかっていいですね。

 

感想

これまでは、ひたすら手動で行ってきた環境移行ですが、転送ツールを利用することでかなりの部分が楽になった感じがします。
特にOutlookのデータとか設定周りもうまく引き継いでくれたのはよかったですね。

ちょっと困るのは、何の設定情報が引き継いで何の情報が引き継いでいないかがかえって分かりづらい面もあるということです。
ほとんどの設定が引き継いでくれている割に、同じオフィスでも引き継いでくれない部分もあったり。この辺りは言い出すときりがないのかもしれません。

ODBCの設定に関しても、データソースの定義そのものは引き継いでくれたものの、肝心のドライバが存在していない（当たり前と言えば当たり前だが）ので当然の事ながら動かない。
こういう場合は、ゴミデータを増やすだけになってしまいますね。

メインブラウザにGoogle Chromeを利用しているので、設定周りは基本的にログインすれば勝手に同期される。やっぱりプロファイルの情報がクラウドにあると、こういう時便利だなと強く感じる。
この辺りの体験はiPhoneも同じで、MicrosoftとしてもVDIに向けた取り組みとして幾つか用意されている。

でも、やっぱり日本の企業はまだまだそういったプロファイルや企業で利用するデータを外部に保存すると言うのは抵抗があって、中々思うようにいっていないと言うのが実情に感じる。
ましてや自宅環境ともなると、なかなか難しい。

すべてをクラウドに置きたい訳ではないけれど、ドンドン楽になっていくとありがたい。

MicrosoftがSurfaceに関しての情報をアップデートしてきました。

http://youtu.be/8mSckyoAMHg

これはSurfaceのCM。とりあえず、カチャカチャと結構音がする事はわかったぞ。

さて、10/26に発売を予定しているSurface。
価格としてはiPadと同じ499ドル。
Officeが付いてくる仕様だそう（RT版のみで、Proは自分で購入する）
アメリカでは既に予約が始まったとの事。

日本ではどうなのかな〜と見てみると

 http://japanese.engadget.com/2012/10/16/surface-windows-rt/
Surface は米国とカナダに加えてオーストラリア、中国、フランス、ドイツ、香港、英国の8か国でオンライン販売される予定です。「Japan」は今のところ含まれていません。

え。。。
なんでや・・・

WindowsPhone8が日本を外した事から、少し嫌な感じはしていたけど、Surfaceまで対象外にするのはちょっとがっかり。
Windows8がタッチを意識したOSだと言うのに、肝心のMicrosoft謹製のデバイスが発売されないと言うのは
ユーザーの立場としても開発者の立場としても正直がっかりなところが否めないなぁ。

Modern Style UIに対しての試行錯誤と言う面で大きく出遅れる事になるんだろうか。
それとも、国内の他のメーカーがMicrosoftを上回るデバイスをリリースするんだろうか。
うーん、残念

少し前の事ではあるが、会社のメインPCをWindows VistaからWindows8へ変更した。
Windows8に関しては、やはりその独特のデザインであるmodern style(旧Metro)UIに関しての違和感を感じる人が多いと思う。

ウィンドウズ8、不慣れな操作画面に企業が二の足踏む可能性も
http://jp.wsj.com/IT/node_530673?google_editors_picks=true

私はと言うと、元々利用していたのがVistaと言うこともあるし、PCのスペックも更新された事もあって、今のところそれほどの不満はない。

	旧PC	新PC
OS	Windows Vista Pro (32bit)	Windows 8 Enterprise (64bit)
Memory	2GB	8GB
HDD	130GB	500GB

Coreは元々なんだったかうろ覚えだが、新PCはi5になっている。
64bitにすることは、正直利用しているアプリケーションの互換性に関して心配があったが、
メモリをより多く使う事が出来るのはこの先大きいと考えて踏み切った。

実際問題、ユーザ企業でも今後は64bitの利用が進んで行く事を考えると開発者側がいつまでも
古くさい事を言っていられないと言うのもあったりする。

先のThe Wall Street Journalの記事にもあったが、modern style UIに対して戸惑わないかと言うと、最初は戸惑う。
しかし、利用するアプリケーションがmodern style UIを利用している比率が高まれば高まるほど、その利点を多く享受出来るのではないかと考えている。

また、Windows8によってWindows7から変更された点も多く、それがいい方向に動く事もあれば困った事を引き起こしている事もある。
実際にWindows8が一般発売されるのは10/26と、もう少し先の話になるが、気がついた点に関してこの先書いて行ければと思う。

なんだかんだ言っても、ユーザ企業が全部Macになるなんて事は現状あり得ないし、
変更された事をあーだこーだいいながらXP使い続けるなんて気にもならない。
であれば、率先していい点を享受しながら困った点を回避する手段を探して行きましょうよって言うスタンスで。

ただし、一部、業務で使うアプリが動かなくなるのは困り者なので、VMとかで逃げるのはもちろん有りです。はい。

品川のグランドプリンスホテルで行われたMicrosoft Conference 2012に行って来た。

The Microsoft Conference 2012
http://www.microsoft.com/ja-jp/events/msc/2012/default.aspx

今回、事前にたまたま見つけた”ファーストチケット”と言うものに応募していたら、専用ラウンジとかレッドブル飲み放題とか付いてた。
ノートPC持って行って、ずっとそこで仕事すると言う手も無くはなかったのだが、いくつかのセッションに参加して来たので
そのいくつかをかいつまんで書きたいと思います。

整理しきれていないので、その辺りはご容赦を。

WinRTアプリ

10月にリリースを控えているWin8。
やっぱり特徴的なのは、どのセッションでも闇に葬り去られてしまった旧名称MetroであるModern Style UIで作られたWinRTアプリ。
コンセプト自体がタッチを意識したUIなのでしょうがないかもしれないが、どのアプリも見せる事を優先したアプリだった。

中にはガリガリ入力して行くような基幹系アプリの例があっても面白いんじゃないかな〜と思ったけど、
そういうアプリだとタイルとかあんまり関係なくなってしまうんだろうなぁ。

今日話のあった面白い事例としては、WinRTアプリで実装する内容を最小限にすると言うアイデア。
主立った処理は、相変わらずウェブアプリとして存在し続けてWinRTアプリからそこへ誘導する。
まるでWinRTアプリを広告として使うようなイメージだ。
アプリが切り替わる様は、ちょっと手抜き感が拭えなくはないが、その辺りから始めてみるのは面白いかもしれない。

WinRTアプリの強みは作ったものがそのままSurfaceなどのARMアーキテクチャ上でも動作する点だと思う。
一方で、そういった通信環境が不安定な状況下と言うことも想定した作りにしておかないと、
思わぬところで痛い目を見る事になりそうな気がしている。

ただ、良くも悪くもWindows8のメニューはタイル型のみ。
ここに良い状態で載せる事が出来るか出来ないかは、アプリとしては結構重要ではないだろうか。
折角の仕組みだ。有効活用して行きたい。

仮想化（VDI / RDS)

デスクトップ仮想化を提供するVDI (Virtual Desktop Infrastructure)やRDS (Remote Desktop Service)に関するセッションもよく見かけた。
もちろん、Hyper-Vも一緒に付いてくる。

これだけスマホやクラウド。SNSが普及してくると、やっぱり働き方と言うものも変わって行く。
その中で、企業としてはセキュリティを意識しながらどれだけそれらに関わって行くのか？というのが問われる。
一つの答えとしては、旧来通りでそれらをすべてカットしてしまうのも無くはない。

ただ、私も子育てをしているとどうしても自宅でうまい事仕事ができればなぁと思う事がよくある。
育休がとりづらい理由の一つに、会社に行かないと仕事ができないというのもあるんじゃないだろうか。

一方でこれは、私生活と仕事の境界が随分と曖昧になってしまう事を意味する。
これに嫌悪感を感じる人もいるだろうが、SNSとかを考えてしまうと人によっては既に随分曖昧だ。
問題はどうつき合って行くかなんだろう。

VDIを実現する上で、プロファイルやアプリケーションを仮想化させる為の仕組みがいくつか紹介されたが、
一番興味を持って、比較的手軽に試せないかなぁと思ったのは社外から社内へ接続する為のDirectAccessという仕組み。

Windows Server 2012 Direct Access – Part 1 What’s New
http://blogs.technet.com/b/meamcs/archive/2012/05/03/windows-server-2012-direct-access-part-1-what-s-new.aspx

Windows Server 2008とWin7時代からあるとは言え、だいぶ使いやすくなっているみたい。
RemoteFXによるUSB Redirectと言うのも加わり、VDI環境による働き方を変える土台は出来つつあるんだなぁと感じた。

うちの会社でも試してみれないかな〜なんて思ったりする。
実は某部長が隠れてやっていたりしないかと（略

今後の展開

今回のコンファレンスでは、会社のメンバーも参加させたので思い切ってIE10に関しては外した。
っていうか、多分それほど新しい話は出ないだろうと勝手に思った為でもある。

WinRTアプリに関して、これまでそれほどまじめに考えていなかったので中々面白い機会だったと思う。
また、VDIやRDSのような内容は、自分が使う／使わないに関わらずお客さんから質問が往々にして来る。
自分が関連するプロダクトが、そういった多様な利用形態で使われた場合にどういう事が考えられるのか？
と言うのを考えておいたほうがいいかもしれない。

さてさて、WinRTアプリはどうなるんだろうね。
結局はどういうアプリを世に出す事が出来るのか、開発者次第なんだろう。
楽しみだ。