Windowsサービスからアプリケーションを起動する

　Windowsサービスから自動でアプリケーションを起動しようとしたところ、起動してもデスクトップに表示されない・・・。

　　　＊　　　＊　　　＊

　よくよく調べてみれば、サービスをSYSTEMユーザーで起動するように構成しているため、そのままアプリケーションを起動すると、SYSTEMユーザーでアプリケーションが起動する。つまりログオンしているユーザーのデスクトップには表示されず、バックグラウンドで実行されるということ。

　.NET frameworkのSystem.Diagnostic.Processクラスを利用して、アプリケーションを起動している
のだけど、アプリケーションの起動ユーザーを指定できるので試してみた。

　　　＊　　　＊　　　＊

　権限がなくてNG・・・。普通のコンソールアプリやアプリケーションからは起動できるので、メソッドの使用方法は間違っていない様子。特定のユーザーでアプリケーションを起動させるコンソールアプリを作成し、サービスからそれをキックしても同様のエラー。コンソールアプリ単体では動作するのに・・・。

　ユーザーの偽装ができないように対策されている様子。まあ、当たり前か。

　　　＊　　　＊　　　＊

　Win32APIを利用して、ユーザーを偽装させて実行させることは可能なようだけど、手順が面倒臭いし、普通のアプリケーションを作成するほうが楽チンなので、必要ならばそちらで対応しようと思う。

　　　＊　　　＊　　　＊

　バックグラウンドでExcelマクロなどを実行できるので、特殊な利用方法には使えるかもしれない。サービスをユーザー権限でインストールするようにすればよいのだけど、複数ユーザーが利用する場合はどのように動作するのだろう。興味深いので、そのうち試してみようかな。

　　　＊　　　＊　　　＊

　System.Diagnostic.Processでユーザーを利用して、プロセスを起動する場合、パスワードが必要になる。受け渡しは、System.Security.Stringクラスを利用するのだが、パスワードの入力を省略させる場合、パスワードを保存する手法にはどのようなものがあるのだろうか。例えばWindowsだとネットワークドライブのパスワードの保存ができるが、内部的にはどのように保存しているのだろう？　Windowsでの安全な保存方法（完璧なものはないと思うが）の一般的な方法はあるのだろうか。

　　　＊　　　＊　　　＊

　パスワードつながりで、いつも気になっていることを少し。社内などで認証をしているアプリケーションでは、パスワードの平文がアプリケーションには渡されているわけで、開発している人にはユーザーのパスワードを入手することが簡単。LDAPサーバを立てて、各システムで共用している場合、イントラネットのメールから何から、すべて一つのパスワードで利用できてしまうので、ある意味危険なのかなあ、と思う。とあるシステムの開発担当は、悪意があれば、その社内のすべてのアプリケーションの利用をするためのパスワードを入手することが可能なのではないか。

　同じことがネット上でも言えるかもしれない。たいていのサービスはメールアドレスがユーザIDとなっている。異なるサービスのユーザーIDを共通にすることは多いだろう。パスワードをメールのアカウントと同じにしている人も多いかもしれないが、サービスごとに変えておいたほうが安全かもしれない。

　だらだらと書きなぐり。

浮気の境界

　少し前に電車で中学生くらいの女子二人の会話。

女子A「浮気の境界ってあるじゃん。」

女子B「え〜、よくわかんないなー。」

女子A「二人で出かけるときに

　　　　　マックはOKだけど、

　　　　　スタバはNG。

　みたいなこと。」

女子B「え〜、やっぱりわからないよー。」

　自分もよくわかりません！！　マックとスタバの違いのポイントは何？　値段？　雰囲気？

　どうもコイバナだったようですが、続きが聞けなかったのが残念。

　マックはOKで、スタバはNGという微妙な境界があるということを覚えておこう、というメモ。

VistaのI/O Priority

備忘録。Vista。

　Vistaのタスクスケジューラで（ログオン時に）起動させたアプリケーションのI/O PriorityはLowに設定される。これをNormalにするには、以下の方法を行う。

１．タスクスケジューラで実行させたいタスクを設定する（タスク名はAAAとする）。
２．管理者でログインし直し、コマンドプロンプトを起動。
３．１で作成したタスクの定義をXMLファイルとして取得する。下記のコマンドを実行。
　> schtasks /query /tn "AAA" /xml > output.xml
４．output.xmlの内容を編集する。
　要素で指定されている値を6にする（6より小さい値にすればOKの模様）。
５．１で作成したタスクを一度削除する。
　> schtasks /delete /tn "AAA"
６．４で編集したXMLファイルを利用してタスクを再作成する
　> schtasks /create /tn "AAA" /xml output.xml

　以上で完了。Process Exploreで確認すれば、I/O PriorityがNormalになっていることが確認できるはず。

　余談だが、上記XMLファイルでRun Levelを指定できるがHighの設定（値は忘れた）にすると、何故かCPUの優先度が通常よりも下がる。不思議。また、I/O Priorityの設定とRun Levelの設定は同時に指定できない模様。

　設定する場合は、自己責任で。

--- 追記 ---

　コメントが付いたので、更新を忘れていたのでもう少し簡単な方法を追記。

　１．タスクスケジューラでタスクを設定して、タスクのエクスポートを行う。

　２．エクスポートしたXMLファイルを上記で記載したように編集。

　３．タスクスケジューラで設定したタスクを一度、削除する。

　４．２で編集したXMLファイルをインポートする。

　もっと早く更新しておけばよかったですね・・・。

ClickOnceアプリケーションをコマンドラインから起動する。

備忘録。Vistaで検証。

　ClickOnceアプリケーションをコマンドラインからアプリケーションマニフェストを指定して起動しようとしても実行できない。

　そのため、バッチファイルやタスクスケジューラではそのままでは起動できない。以下、コマンドラインから起動させる方法。

rundll32.exe dfshim.dll ShOpenVerbShortcut アプリケーションマニフェスト参照ファイル

※アプリケーションマニフェスト参照ファイルは、拡張子がappref-ms。名称は適当。

　これが必要となるのは、スタートアップにClickOnceアプリケーションを登録しても、何故か起動できないため、タスクスケジューラを使うしかないから。

　何故、スタートアップで起動できないのかは調べていない。スタートアップのレジストリ設定でもNG。しばらく待ち合わせてから起動させるバッチファイルでも何故か起動できず。

　ただし、タスクスケジューラを利用すると、I/O PriorityがLowに設定される。

　これをNormalにする方法は別記事で。

　使用する場合は自己責任で。