特定の曜日に実行されるタスクの情報を PowerShell で確認すると、[DaysOfWeek]というプロパティにその曜日が表示されます。
確認のために実行するコマンドレットは " ((Get-ScheduledTask -TaskName ***).Triggers).DaysOfWeek " です。
コマンドレット全体を括弧記号 " () " で括ることにより、そのコマンドレットの実行結果を持つ「オブジェクト」として扱えるようになります。
そして括弧記号の後ろに " .プロパティ名 " を続けて記述することで、そのオブジェクトに含まれる各種プロパティの中から、指定したプロパティの情報だけを抜き出して表示できます。
上記コマンドレットは、それを二重で行っているわけです。
まず、タスク名を指定して特定タスクの情報を取得し、その中からプロパティ [Triggers] の情報を取得し、さらにその中からプロパティ [DaysOfWeek] の情報を取得しているわけです。
タスクスケジューラに登録されているタスクの情報を確認したい場合、普通に " Get-ScheduledTask -TaskName *** " コマンドレットを実行するだけでは、 [Actions] 、[Principal] 、[Triggers] といったプロパティの詳細は確認できません。
どうやらこれらは、単なるタスクのプロパティの一項目ではなく、これら自身がプロパティを持つオブジェクトのようです。
（↑技術的に正しい表現なのか、いまいち自信がありませんが。）
そこで、「これらのプロパティの、さらにプロパティを表示する」という方法を試してみることとします。
決して複雑な手順を踏むわけではありません。
たとえば " (Get-ScheduledTask -TaskName task).Actions " を実行すると、
[Execute] に powershell.exe が、
[Arguments] に E:¥script.ps1 が表示されます。
それぞれ、タスクケジューラでタスクを作成する際に入力したプログラムと引数に該当します。
管理ツール「タスクスケジューラ」（taskschd.msc）を PowerShell で操作するためには、モジュール「ScheduledTasks」のコマンドレットを使用します。
なお、このモジュールは、 Windows Server 2012 や Windows 8 以降の OS でしか使えません。
同じ PowerShell 3.0 を Windows Server 2008、Windows Server 2008 R2 、Windows 7 にインストールしてみましたが、使えませんでした。
PowerShell において、なんらかの設定情報を取得するためには " Get-***** " というコマンドレットを打つのが常道ですから、とりあえず " Get-ScheduledTask " を実行してみます。
すると、タスクの一覧を取得できました。
コマンドプロンプトで " SCHTASKS /Query " コマンドを実行した場合と似ています。
（PowerShell もコマンドプロンプトも、「管理者として実行」していない場合、アクセス権が及ばないタスクの情報は取得できません。）
自転車を買い替えて、これまで乗っていたものを知人に譲り渡すことになりました。
そこで問題になるのが、防犯登録です。
私の名義で登録した状態のまま知人が乗っていると、警察官から職務質問を受けた時に「盗品」と見做されてしまいます。
そこで名義変更の手続きが必要になのですが、具体的にどういう手続きが必要なのか全くわかりません。
そこで近所の自転車屋さんで聞いてみたのですが、なんと三店それぞれ言うことが違います。
共通しているのは、手続き自体はどこの自転車屋さんでも可能だということぐらいです。
（てっきり、警察署で手続きするものだと思っていました。）
東京都の A 店：「今この店舗には書類が無いので、防犯協会の WEB サイトから書式を入手し、記入のうえ持ってきてください。」
神奈川県の B 店：「決まった書式は無いので、白い紙に " 譲渡書 " と題し、現所有者と譲渡相手の署名捺印をして持ってきてください。」
神奈川県の C 店：「購入時に登録した、登録書の控えが必要です。手元に無い場合、購入店にあるはずです。最低限、購入を証明できるレシートのような書類が必要です。」
いまいち何を信じたらよいのか分からないので、とりあえず神奈川県自転車防犯協会の WEB サイトを確認したところ、Q & A のページの [ 2. 自転車の譲渡・譲受時 ] に、ちゃんと詳しい解説が書いてありました。
譲り渡す相手は神奈川県在住なので、この情報を参考にします。
もっとも A 店の主張も間違いというわけではなく、東京都自転車商防犯協力会の Q & A のページには、決まった書式を使うように書かれています。
（団体名が紛らわしい・・・）
ともあれ、現登録は東京都なので、神奈川県では抹消できません。
抹消手続きの方法について、念のため購入店に問い合わせたところ、以下３つの情報を新たに得られました。
・現登録を抹消してからでないと新たな登録ができないのは、神奈川県のみ。
・東京都で行った現登録を抹消する手続きは、購入店でなくとも、東京都の自転車屋さんならどこでも可能。
・ただし登録時の書類の控えが無い場合は、購入店で再発行する必要がある。
2 年前に自転車を購入した時の書類を探してみましたが、見つかりません・・・
来週末にでも購入店へ行って抹消してきます。
Windows Server に PowerShell 1.0 が登場したのが、Windows Server 2008 でした。
デフォルトで搭載されてはいましたが、サーバーマネージャーの「機能の追加」でインストールする必要がありました。
(Windows Vista の場合は、KB928439 をインストールします。)
その後、Windows Server 2008 R2 や Windows 7 では、バージョンアップした PowerShell 2.0 が、最初から使えるようになりました。
そして Windows Server 2012 や Windows 8 では PowerShell 3.0 になりました。
この PowerShell 3.0 を、Windows Server 2008 にインストールできるということを今日初めて知りました。
（Windows Server 2008 R2 と同じ PowerShell 2.0 をインストールできることは知っていたのですが。）
あらかじめ Service Pack 2 を適用しておく必要があり、.NET Framework など複数のコンポーネントをインストールする必要がありますが、Installing Windows PowerShell に手順がまとめられています。
さっそくインストールしてみたのですが、決して Windows Server 2012 と全く同じように使えるわけではないようです。
コマンドレットやモジュールの数にだいぶ差があるようなので、両 OS で比較してみました。
※ OS インストール後、「役割」を何も追加していない素の状態です。
まず powershell.exe を起動。
起動した時点で読み込まれているモジュールを比較するため、" Get-Module " を実行。
Windows Server 2008 ---> Microsoft.PowerShell.Management
Windows Server 2012 ----> Microsoft.PowerShell.Management
どちらも一つだけであり、差はありません。
（コマンドプロンプト上で powershell.exe を実行している状態では、どちらもゼロです。）
次に、get-command で利用可能なコマンドレット数を比較します。
実行結果の行数をカウントするために、" (Get-Command).length " を実行。
Windows Server 2008 ---> 349
Windows Server 2012 ---> 1160
なんと、三倍以上の差があります。
同様にして、利用可能なモジュール数を比較します。
" (Get-Module -listAvailable).length " を実行。
Windows Server 2008 ---> 13
Windows Server 2012 ---> 55
こちらは四倍以上の差です。
最後に、利用可能なモジュールを全て読み込んだ状態でコマンドレット数を比較します。
" Get-Module -listAvailable | import-module " を実行してから " (Get-Command).length " を実行。
Windows Server 2008 ---> 349
Windows Server 2012 ---> 1170
読み込む前と大差ありません。
というわけで、Windows Server 2012 と同等の処理は期待できません。
私の勤めているサポートセンターには、システム利用者（エンドユーザー）からのお問い合わせが入ることは滅多にありません。
基本的に、システムの運用管理や構築作業を生業としているプロのエンジニアからのお問い合わせに対応しています。
しかし、開発企業がインターネット上で公開している情報をググった方が明らかに早いようなお問い合わせも、決して少なくありません。
インターネットへ接続していないクローズドな職場にいらっしゃるお客様なのかもしれませんが、そういう職場であればこそ、エンジニア向けの専門書が取り揃えてあるはずです。
Windows のヘルプメニューにも、TechNet と同じ内容が書いてあることがあります。
ところが、そういった情報源を全く活用せずにサポートセンターにお問い合わせいただくケースもあるので、ちょっと心配になってしまいます。
自力で調べても簡単には分からない事柄だった場合は調べた時間が無駄になってしまいますので、最初からサポートセンターへ問い合わせてしまえばよい、と考えるのは合理的かもしれません。
もちろんこちらも仕事ですから、聞かれたことには答えます。
ですが、それで解決できるのは「その時自分が直面した課題や疑問に思った事柄」だけです。
そんな場当たり的な対処を繰り返すだけでは、システムを構築・運用する上で本来知っておくべき体系的な知識は決して身につきません。
するとそのシステムは、たまたまその時の担当エンジニアが気にした問題だけが解決され、気にしなかった部分に意外な落とし穴があるリスクを抱えたまま運用されていく事になります。
そういう落とし穴がある（かもしれない）というリスクを自覚している方であれば、ググるなり専門書を読むなりして体系的な知識を身につけるよう努めるでしょうし、サポートセンターへ問い合わせる頻度も少なくなるでしょう。
（結果的に、サポートセンターへは「そうでない方」からのお問い合わせが集まっているような気がします。）
そのリスクを最終的に負っているのは、エンジニア当人ではなく、あくまでもシステム利用者だということを忘れてはいけません。
私自身はシステム運用・構築の現場で働いたことがありませんが、現場のレベルというのは、あくまでも現場のエンジニアの技術力に依存するのであって、決して現場が契約しているサポートセンターの技術力に依存しているわけではないと考えています。
もしサポートの契約など無い環境で同じ問題を解決しなくてはならなくなったら、誰だって自力で調べるはずです。
むしろその方がエンジニアとしては成長できると思います。
調べても分からないこと、調べる過程で派生した新たな疑問、調べた結果の妥当性確認といったことをサポートセンターへお問い合わせいただくことは有意義だと思いますが、そういうお問い合わせはあまり多くありません。
一企業による固有の商品名だとばかり思っていましたが、違うということを知りました。
KIRIN から販売されているソフトドリンクの「別格」シリーズの中に「生姜炭酸」という商品があるのですが、そのパッケージにも「Ginger Ale」と書いてあるのを見て気付きました。
いままで「ジンジャーエール」という商品だと思っていた、日本コカ・コーラの緑のアレは、「カナダドライ」の方が商品名だったのですね。
Wikipedia によると、ジンジャーエール自体は、「ジンジャー（ショウガ）などの香りと味をつけ、カラメルで着色したノンアルコールの炭酸飲料」だそうです。