現在モニタを操作しているユーザ名の取得

Question

社内のクライアントPC（Widnows10）全てに同一の設定を施すため、タスクスケジューラより管理プログラムを起動する様に設定しています。
各クライアントPCのログインユーザは標準ユーザですが、管理プログラムは専用の管理者権限で動作させています。

今回、とあるミドルウェアを使用するにあたり「現在ログインしPCを操作しているユーザ（今の作業内容がモニタに表示されているユーザ）」で実行する必要が出てきました。
ミドルウェア実行には管理端末からSchtasksコマンドをリモートで実行してタスクスケジューラに登録させようと考えておりますが、今回の実行ユーザは前述の「現在PCを操作しているユーザ」になります。
タスク登録の際のユーザには「現在モニタを操作しているユーザ」を取得する必要がありますが、いくつか問題があります。

1. 「現在モニタを操作しているユーザ」のユーザ名は分かりません。
2. 環境変数USERNAMEやは同変数を展開したユーザ名のため、「現在モニタを操作しているユーザ」とは限りません。whoami.exeコマンドも同様。
3. net userコマンドではユーザ一覧を取得できますが「現在モニタを操作しているユーザ」を取得できません。

以上です。
Schtasksなどリモートでも実行可能なコマンドでも構いませんし、タスクスケジューラから管理プログラムを使用してそのPCの当該ユーザを取得出来れば一番シンプルかなと思います。

分かりにくい文章となってしまい恐れ入りますが、ご存知の方がいらっしゃいましたら
どうか宜しくお願い致します。

Comments

[CHERRY]

現在モニタを操作しているユーザ というのは、どの様な定義でしょうか？

パソコンにログインしているユーザーアカウント名に関係なく、パソコンの前で、モニタを見てキー入力等の操作をしているユーザが誰かを取得したいということですか？

[dai3922]

説明が悪く申し訳ありません。
仰るご認識の通りです。

「現在モニタを操作しているユーザ」
　リモートデスクトップを始めその他プロトコルでリモート接続しているユーザではなく、PC本体に差しているキーボード・マウスの操作内容をモニタに反映しているユーザです。
　このユーザが誰かを取得したいと思います。

Answer 1

Win10標準搭載の"Query"コマンドが使えるかもしれません。
セッション名に"console"となっているところのユーザー名が、現在その端末の物理コンソールを使用しているユーザーになります。

PS C:\Users\blade> query session
 セッション名      ユーザー名               ID  状態    種類        デバイス
 services                                    0  Disc
>console           blade                     1  Active
PS C:\Users\blade> query session /?
リモート デスクトップ サービス セッションの情報を表示します。

QUERY SESSION [セッション名 | ユーザー名 | セッション ID]
              [/SERVER:サーバー名] [/MODE] [/FLOW] [/CONNECT] [/COUNTER] [/VM]

  セッション名        セッション名を指定します。
  ユーザー名          ユーザー名を指定します。
  セッション ID       セッション ID を指定します。
  /SERVER:サーバー名  照会するサーバーを指定します (既定値は現在のサーバー)。
  /MODE               現在の回線の設定を表示します。
  /FLOW               現在のフロー制御の設定を表示します。
  /CONNECT            現在の接続の設定を表示します。
  /COUNTER            現在のリモート デスクトップ サービスのカウンター情報を表示します。
  /VM                 仮想マシン内のセッションに関する情報を表示します。

PS C:\Users\blade>

Comments

[dai3922]

返信が大変遅くなり申し訳ありません。

ご回答頂きありがとうございました。
Queryコマンドをバッチ上で試してみましたが私のWin10 64bit環境では使用できないコマンドの様です。
実行しても「内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません。」と表示されてしまいます。

非常に便利そうなので引き続き実行方法を探してみます。

[Takeda_Kazuhito]

解答から申し上げると、"C:\Windows\Sysnative\query.exe"とフルパス指定でQueryコマンドを実行することで解決するものと予想します。
　以下にその理由を記載します。

　Queryコマンドですが、コマンド本体は”C:\Windows\System32\Query.exe"のパスのみに存在しており、ここに保管されているコマンドは、64ビット版コマンドプロンプト(または64ビット版PowerShellコンソール)でのみ実行されます。
　ちなみに32ビット版で実行されたコマンドプロンプトやPowerShellコンソールから呼び出されるコマンドは、"C:\Windows\SysWOW64"に存在しているモノのみが利用可能です(32ビット版シェルから呼び出される"C:\Windows\System32"内のファイルは、WindowsのFile System Redirectorという機能で自動的に"C:\Windows\SysWOW64"へリダイレクトされる為、32ビット版シェルは必然的に"C:\Windows\SysWOW64"に存在するファイルのみ利用可能となる)。

　実行しているバッチファイルが32ビット版で処理されている場合、上記理由によりQueryコマンドは使用できません。バッチファイルが32ビット、64ビットのどちらで実行されているかは以下の環境変数を参照して、値が"AMD64"なら64ビット、"x86"なら32ビットであると判断することが可能です。

環境変数名：PROCESSOR_ARCHITECTURE

　32ビット版シェルでバッチファイルが処理されている場合、同じようにFile System Redirector機能で提供されているパスである"C:\Windows\Sysnative"を指定することで、実ファイルの”C:\Windows\System32"へアクセスすることが可能になっています。
　まとめると、環境変数"PROCESSOR_ARCHITECTURE"の値に応じて、以下のように処理を変える必要があると言うことです。
　同様の現象を引き起こすコマンドはいくつかあるので、一度System32とSysWOW64の内容を見比べておくと良いかもしれません(または、必要に応じてバッチの先頭で"C:\Windows\Sysnative"へパスを通しておくのも悪い手ではありませんね)。

環境変数"PROCESSOR_ARCHITECTURE"の値が"AMD64"のケース：
　"C:\Windows\System32\Query.exe"
　…一般的にはPathが指定されているので"Query"のみで実行可能。

環境変数"PROCESSOR_ARCHITECTURE"の値が"x86"のケース：
　"C:\Windows\Sysnative\Query.exe"

…なんか読みづらくなってしまって申し訳ない(^_^;

[dai3922]

早速ご回答頂きありがとうございます。
また、詳細なご説明も加えて頂き恐縮です。

ご教授通り"C:\Windows\Sysnative\query.exe"にて実行が出来ました。
32bit版、64bit版でバッチファイルを実行する際の、使用できるコマンドがリダイレクトされる点については一切存じ上げませんでした。

余談ですが、
私のPCは64bitOSですが、"Query"のみで実行することが出来ず、追加の質問に至りました。
そしてコマンドプロンプトで"%PROCESSOR_ARCHITECTURE%"を実行したところ"x86"が返ってきまして、何かおかしいなとここで気付きました。
今回の"Query"コマンドを試す際に使用していたコマンドプロンプトは「nrLaunch」というランチャーソフトから起動していたもので、そうやらこれが関係していました。
ランチャー上に設定しているコマンドプロンプトは間違いなく"C:\WINDOWS\system32\cmd.exe"を参照しているのですが、ランチャーを経由して起動するとcmd.exeが32bitとして振る舞うようです。
ランチャーが32bitで開発されたのか？は分かりませんが古いソフトであり考えられます。
結果的に"C:\WINDOWS\system32\cmd.exe"を直接起動し、フルパスを指定せずに"Query"コマンドを実行したところ問題なく起動しました。

以上です。
今回は多くを授けて頂きとても勉強となりました。
今後ともどうか宜しくお願い致します。

Answer 2

他にも方法はあるでしょうが、tasklistコマンドでユーザーが分かります。

for /f "tokens=8" %%A in ('tasklist /v /fi "imagename eq explorer.exe"') do set U=%%A

Comments

[dai3922]

ご回答ありがとうございます。

なるほど！
つまり、ログインしていないとタスクリストに表示されないexeを利用しているユーザを見つければいいだけですね。
まさに目からうろこです。
ユーザ名だけしか見ていなかったので発想すら出来ませんでした。
頭が固いです。

Answer 3

ログオンスクリプトを使用されてはどうでしょう？
ユーザーがログオンしたときにミドルウェア実行(?)をするのが確実ではないでしょうか？
ActiveDirectoryでドメイン運用されているのであればグループポリシーで設定するだけですし。

Comments

[dai3922]

いつもご回答頂きありがとうございます。

不勉強ですがログオンスクリプトを初めて聞きました。
調べたところActive Directoryへの参加が必須とのことでしたが、Active Directoryは使用しておらずタスクスケジューラ一本で全クライアントの管理をしております。
今回の件も含めActive Directoryは管理・運用で便利で実装したいのですが、何分専門家や専門部署が社内にありませんので運用後の保守も叶わないだろうとのことで永年保留してしまっています。

[Y.H.]

> Active Directoryへの参加が必須
いえ、ローカルグループポリシーエディタ([Win]+[R]でgpedit.mscを実行)で「ユーザーの構成」-「Windowsの設定」-「スクリプト」でログオン時に実行するバッチファイルなどを登録できます。
(この設定はレジストリに登録されるので、直接レジストリを編集することで登録できると思います。)
https://www.google.co.jp/search?q=ログオンスクリプト+レジストリ
Active Directory環境ではこれをADサーバーで一元管理できるので便利ということです。

[dai3922]

早速ご教授頂きありがとうございます。
ログオンスクリプトの敷居の高さを勘違いしていました。
確かに、確実にログイン中のユーザ名が取得できますね。
タスクスケジューラ起動にこだわっていたのは
　１．時間指定で起動が可能
　２．リモートによる実行指示が可能
この2点でした。
ログオンスクリプトでの乗り換えを検討します。

大変参考になりました。
ご親切にお教え頂きどうもありがとうございました。

Answer 4

手っ取り早く安価で済ませるなら、webカメラ装着で
端末を利用しているユーザを判断させればよいのでは？

codeを書いて識別させてもログインした人が必ずしも
モニタを使用しているとは限らないため

Comments

[dai3922]

ご回答頂きありがとうございます。

なるほど、思いもしませんでした。
現在のユーザを識別してそのままそのユーザでミドルウェアを実行したいので、WEBカメラ装着だとどうしても認識する部分は人手になってしまうと思いますので難しいです。

ただし、ログインしたユーザが必ずしもモニタを使っているわけではない、というのはその通りです。
WEBカメラが自動で判別してくれれば一件落着なのですが…