AT コマンドが廃止されてた。

Windows の「タスクスケジューラ」にタスクを登録するコマンドとしては、”at” , “schtasks” の2つがありますが、Windows Server 2012 で “at” コマンドを実行すると、「それもう廃止されたから “schtasks” 使ってね。」という旨のメッセージが表示されます。

 

“at” コマンドの特徴として、登録したタスクが、既定では [SYSTEM] アカウントにより実行される、という点が挙げられます。

[SYSTEM] アカウントとは、通常はコンピューターの内部処理に使われるものであり、ユーザーがこのアカウントを用いて対話的にログオンする事は出来ません。

大変強い権限があるため、Administrator でもアクセス許可が無い「何か」へアクセスするタスクは、”at” コマンドで作成すると便利です。

 

 

その “at” コマンドが無くなってしまいました・・・

では 今後、[SYSTEM] アカウントによりタスクを実行したい場合はどうしたらよいのでしょうか?

手段を3つ考えてみました。(Windows Server 2008 R2 SP1 および Windows Server 2012 にて確認。)

 

 

<1> まず一番簡単なのは、手動による変更です。

GUI (タスクスケジューラ)ないし “schtasks” コマンドにより作成したタスクは、GUI 上の操作(タスクを右クリック -> プロパティの[全般]タブ内)でその実行ユーザーを変更することが可能なので、 [SYSTEM] アカウントに変更します。

 

 

<2> タスクの作成および作成後に、GUIでの操作が一切出来ないというケースもあるかと思います。

そのような場合には、”schtasks” コマンドによりタスクを作成する際に、実行ユーザーを指定するオプション “/RU” の引数に [SYSTEM] と記述します。(パスワードの入力は不要です。)

 

 

<3> ”schtasks” コマンドによる、「XML ファイルのインポート」という手もあります。

GUI上でタスクを右クリックし、「エクスポート」を選択することで、実行ユーザー等の設定情報が記述されたXMLファイルが保存されます。

あらかじめ [SYSTEM] アカウントにより実行されるよう設定したタスクをエクスポートしておき、”schtasks” コマンドによりタスクを作成する際、XMLファイルを読み込むオプション “/XML” の引数としてそのXMLファイルのフルパスを記述します。

これにより、”/RU” オプション無しでも、 [SYSTEM] アカウントにより実行されるタスクが作成されます。

※”/RU” オプションにより、XML内の記述と異なる実行ユーザーを指定した場合は、”/RU” オプションが優先されます。

 

 

このXMLファイルには、実行ユーザー以外にもタスクの設定情報が多く記述されていて、メモ帳でも編集可能です。

“schtasks” コマンドによりタスクを作成する際のオプションとしては存在しない設定も、どうやら編集出来るようなので、覚えておいて損は無い方法だと思います。

Windows Server バックアップを、PowerShell でやってみる。<変数編 2 >

前回は、一行目のコマンドレット “$policy=new-wbpolicy” の意味を解説しました。新たな変数名「policy」 を定義し、”new-wbpolicy” コマンドレットによって作成されるバックアップ実行時のポリシー情報をその内容として格納するというものです。

 

 

では、二行目の ”add-wbbaremetalrecovery $policy” は何をしているのでしょうか。二行目を実行した後に、「$policy」を実行するとその意味が分かります。変数名の頭に「$」を付けて実行する事でその内容が表示されるわけですが、一行目の実行直後と二行目の実行直後とでは、その内容が変わっているのです。

一行目の実行直後だと、ただ単に “new-wbpolicy” を実行した場合と同じ「空のポリシー」が表示されるだけなのですが、二行目の実行直後では、「BMR」の項目が「: False」から「: True」に変化しています。このことから、「ベアメタル回復を実行する」というポリシーが設定されたことが分かります。

 

 

三行目の “$backuptargetvolume=new-wbbackuptarget -volume G:” では二つ目の変数が登場しますが、やっている事の本質は一行目と同じです。「backuptargetvolume」という変数名を定義し、その中に、「バックアップ先としてGドライブを指定する」という意味の「new-wbbackuptarget -volume G:」を格納しています。

 

 

なお、パラーメーターとして「-volume」を用いても成功しない場合は、「-volumepath」を用いてみてください。私の使っている環境では、先月の <実践編> 執筆時には前者で成功していたはずなのですが、今現在は後者でないとエラーしてしまいます。

英語版 Technet の「New-WBBackupTarget」を見る限りではどちらのパラメーターも存在するのですが、微妙に意味が異なるのか、環境や条件によって使い分ける必要があるようです。

(不思議な事に、打ち間違えて “-volumepat G:” で実行した場合にも成功しました。試しに “-volumepa G:” を実行したところ、これでも成功しました。PowerShell は妙な省略機能が充実しています・・・)

三行目の実行後に「$backuptargetvolume」を実行すると、指定したドライブが表示されます。

 

 

四行目 “add-wbbackuptarget -policy $policy -target $backuptargetvolume” が、最後のポリシー設定となります。三行目で変数「$backuptargetvolume」として設定したバックアップ先ドライブの情報を、さらに変数「$policy」の内容として格納します。(変数の設定を2段階で行うというのは、正直面倒ですね・・・)

四行目の実行後に「$policy」を実行すると、空欄だった「BackupTargets」の項目が「: {指定したドライブ名}」に変化していることが分かります。

 

 

ちなみに、「-policy」と「-target」は省略可能です。二つの変数名だけ記述し、“add-wbbackuptarget $policy $backuptargetvolume” で実行した場合にも、同様の結果となる事を確認しています。

(実は二行目でも、「-policy」を入れて “add-wbbaremetalrecovery -Policy $policy” と書くのが正式な書き方のようです。少なくとも、Technet の「ステップ バイ ステップ ガイド – Windows Server 2008 R2 の Windows Server バックアップ」ではそうなっています。)

 

 

こういった必須パラーメーターを一切記述せず、たとえば  “add-wbbackuptarget” だけを実行したらどうなるかというと、結局「Policy」と「Target」の入力を求められます。ところが、その際にそれぞれ「$policy」と「$backuptargetvolume」を入力しても、エラーしてしまいます。どうやら、コマンドレット上で記述する場合と対話的に入力する場合とで、違う書き方をしなくてはいけないようです。詳しいことはまだよく分かりません。

 

 

最後の五行目 “start-wbbackup -policy $policy” で、変数「$policy」内に格納された各種設定を用いてバックアップを実行します。もちろんここでも、「-policy」を省略可能です。

バックアップ先ドライブがバックアップ元ドライブと物理的に同一ディスク上にある場合には、警告メッセージが出て ” y “ の入力が必要であると<実践編>に書きましたが、”-force” というオプションを用いることでスキップ可能です。すぐにバックアップが開始されることを確認しました。

 

以上で、「Windows Server バックアップを、PowerShell でやってみる。」シリーズは終了です。

正直言って、まだまだ PowerShell を理解しきれていはいません。変数の扱いや、パラメーターの入力方法など、「なぜこうしなければいけないのだろう?」と疑問に思いながら進めている箇所がいくつもあります。それらは今後、別のシリーズとしてこのブログで取り上げていきたいと思います。

 

Windows Server バックアップを、PowerShell でやってみる。<変数編 1 >

Windows Server バックアップを、PowerShell でやってみる。<実践編> を書いてから、すでに一ヶ月以上経っています・・・

Windows Server バックアップのために書いた 5 行のコマンドレットの意味を、時間があるときにじっくり調べようと思っているうちにゴールデンウィークも終わってしまいました。いつでも出来ると思っていると、なかなか手をつけないものです。私が無精なだけかもしれませんが。

これはいかんと思い、この土日でアレコレ調べたところ、ボチボチ理解出来てきました。

 

 

さて、詳細は過去の記事を参照していただくとして、さっそく1行目から見ていきましょう。

$policy=new-wbpolicy

いきなり「ドル記号」から始まっています。これが今回のテーマである「変数」です。

 

 

コマンドプロンプトでは、前後をパーセント記号で挟む環境変数というものがありました。

%date% や %computername% のようにデフォルトで設定されている環境変数以外でも、“set <環境変数名>=<値>”  というコマンドを実行することで任意の値を任意の環境変数として登録出来、”echo %<環境変数名>%” を実行することでその<値>を表示させることが出来ました。

 

 

“$policy=new-wbpolicy” は、それと似たことをしています。「policy」 という、デフォルトでは存在しない変数を定義しているのです。

※PowerShell においては「変数」と「環境変数」は別々の概念であって、「$×××=○○○」という形式で任意に登録出来るのは「変数」の方です。両者の違いについては後述します。

 

 

「policy」という変数の中に格納した値を表示するには、“$policy” を実行します。

なお、格納した値である「new-wbpolicy」自体もコマンドレットであり、新規のバックアップポリシーを作成するものです。もし “new-wbpolicy” コマンドレットだけを実行した場合には、作成されたバックアップポリシーが下記のように表示されます。

———————————

Schedule                    :

BackupTargets         :

VolumeToBackup    :

FileSpecsToBackup :

FileSpecToExclude  :

BMR                             : False

SystemState                : False

VssBackupOptions   : VssCopyBackup

———————————

このバックアップポリシーは作成されたばかりなので、中身はほぼ空っぽと言ってよい状態です。それを変数「policy」に格納するというのが、1 行目の意味です。

( 1 行目を実行した直後に “$policy” を実行すると、当然ですが同じ結果が表示されます。)

 

 

2〜3 行目は、この空っぽのバックアップポリシーに具体的な設定を施すためのコマンドレットです。

そして、最後の 5 行目でいよいよバックアップを実行する際、変数として格納しておいたバックアップポリシーを呼び出して利用するわけです。

 

 

続く。

Windows Server バックアップを、PowerShell でやってみる。<おまけ>

導入編でも書きましたが、Windows Sewrver 2008 R2 SP1 で Windows Server バックアップ機能を利用するためには、事前にサーバーマネージャーにて「機能の追加」をしておく必要があります。

せっかくなので、それも PowerShell でやってみようと思います。方法は、Technet の記事「サーバーの役割と機能を追加する」を参考にしました。

 

 

機能の追加は “add-windowsfeature” というコマンドレットで出来るのですが、Windows Sewrver 2008 R2 SP1 に標準搭載されている PowerShell 2.0 では、最初はこのコマンドレットを使用出来ません。

先に、”import-module servermanager” というコマンドレットを実行しておく必要があります。こうして 「servermanager モジュール」を読み込んでおかないと、”add-windowsfeature” 等のサーバーマネージャー関連のコマンドレットは使えないようです。

※PowerShell を終了してしまうと、次に起動した際には読み込まれていない状態に戻ります。

※Windows Server 2012 に標準搭載されているPowerShell 3.0 では、インポートの手間は不要です。”add-windowsfeature” を実行した時点で、必要な「servermanager モジュール」が自動的に読み込まれます。

 

 

モジュールの読み込みが出来たところで、”get-windowsfeature” というコマンドレットを実行してみます。これにより、現時点での役割や機能を確認出来ます。

一覧の中で Windows Server バックアップ の箇所を見てみると、

[   ]  Windows Server バックアップ            Backup-Features

       [   ]  Windows Server バックアップ      Backup

       [   ]  コマンドライン ツール                     Backup-Tools

となっています。左端の [   ] が空なので、現時点では追加されていないことが分かります。真ん中が「Display Name」で、右端が「Name」です。コマンドレット実行時には「Name」を使います。

 

 

では実際にこれらの機能を追加してみましょう。 “add-windowsfeature backup-features” を実行します。進捗状況が画面上部に表示され、完了後に表示されるメッセージから再起動の必要があるかどうかも分かります。

完了後、あらためて “get-windowsfeature” をしてみると、以下のようになっています。

[ X ]  Windows Server バックアップ            Backup-Features

         [ X ]  Windows Server バックアップ      Backup

         [     ]  コマンドライン ツール                     Backup-Tools

この状態では、PowerShell を用いたバックアップは行えませんので、”add-windowsfeature backup-tools” を実行することで

[ X ]  Windows Server バックアップ            Backup-Features

          [ X ]  Windows Server バックアップ      Backup

          [ X ]  コマンドライン ツール                     Backup-Tools

とします。

この状態でなら、”add-pssnapin windows.serverbackup“ が実行可能になります。

 

 

なお、最初からコマンドラインツールも含めて追加するためには、下記のようなコマンドレットを実行します。

例 1.  “add-windowsfeature backup-features -includeallsubfeature

例 2.  “add-windowsfeature backup-features , backup-tools

また、add の代わりに remove を用いることで、役割や機能を削除することが可能です。

 

Windows Server バックアップを、PowerShell でやってみる。<実践編>

前回、PowerShell のスナップインに”windows.serverbackup”を追加したので、今回はいよいよ”wbbackup“コマンドレットを打ってみます。

 

 

まずは手始めに、”get-help wbbackup“でヘルプを呼び出してみたのですが、正直よく分かりませんでした。仕方がないのでググったところ、役に立ちそうなサイトを2つ見つけました。

 

◆ステップ バイ ステップ ガイド – Windows Server 2008 R2 の Windows Server バックアップ

(http://technet.microsoft.com/ja-jp/library/ee849849%28v=ws.10%29.aspx)

このサイトの、「バックアップ用に Windows PowerShell オブジェクトを作成および構成するには」および「Windows PowerShell を使用して 1 回限りのバックアップを実行するには」という二つの項が参考になると思います。

 

◆PowerShell での Active Directory ディレクトリ サービスのバックアップ

(http://adtan.wordpress.com/2012/01/14/powershell-%E3%81%A7%E3%81%AE-active-directory-%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83/)

私がやりたいことと、かなり近いことを実践されてます。

 

 

これらのサイトを参考にし、実際に私が打ってみたコマンドレットは下記の通りです。コマンドプロンプトのように1行で済ませる方法は見つからず、5行になっています。

———————————————————–

$policy=new-wbpolicy

add-wbbaremetalrecovery $policy

$backuptargetvolume=new-wbbackuptarget -volume G:

add-wbbackuptarget -policy $policy -target $backuptargetvolume

start-wbbackup -policy $policy

———————————————————–

※Gドライブが、Cドライブと物理的に同じディスク上に在る場合、5行目の実行後、リスクを説明するメッセージが表示されます。ここで”y“(イエス)を打ち込まないと、バックアップは開始されません。

 

 

上記5行のコマンドレットにより、(少なくとも私が見る限り、)コマンドプロンプトで”Wbadmin start backup -backuptarget:G: -allcritical”を実行した場合と同じバックアップが取れました。新品のHDDへOS自体を回復することも可能です。もちろんCドライブ内の各種データも一緒に回復されます。

コマンドプロンプトでは”wbadmin get versions“、PowerShellでは”get-wbbackupset“を実行することで「過去のバックアップ履歴とその内容」を確認出来るのですが、これらの結果も、”Wbadmin start backup -backuptarget:G: -allcritical”を実行した場合と同一でした。

 

 

一応、目標は達成できました。しかしながら、まだ私はこの5行のコマンドレットの意味を半分も理解していません。これからそれをじっくり調べていきたいと思います。

 

 

まだ続きます。

Windows Server バックアップを、PowerShell でやってみる。<導入編>

Windows Server 2008 以降、標準のバックアップ機能は「Windows Server バックアップ」といいます。(Windows Server 2003以前は「ntbackup」といいます。)

標準の機能と言っても、OSインストール直後には存在せず、サーバーマネージャーの「機能の追加」で追加してやる必要があります。(私が知る限り、追加後に再起動を要求されたことはありません。)

追加する前にも、[スタート]メニューの[管理ツール]の中には「Windows Server バックアップ」が存在するのですが、起動しても機能しません。「追加してください」という内容の文言が表示されるだけです。

追加後はこれがGUIツールになのですが、コマンドプロンプトで”wbadmin“を実行することでもバックアップをとることが出来ます。

 

 

今回は、これをPowerShellの”wbbackup“コマンドレットを用いて行ってみようと思います。

コマンドプロンプトで、”Wbadmin start backup -backuptarget:G: -allcritical”というコマンドを実行した場合と、同じ結果になることを目指します。

上記コマンドは、OSもユーザープロファイルも、バックアップしたい全情報がCドライブに入っているものとして、それらを「新品のHDDへ、OS自体の回復が可能」な状態でGドライブへバックアップする、という意味です。(これをベアメタル回復といいます。)

オプションとして”-allcritical”を付けることで、OS自体の回復に必要な情報を含むドライブが自動的にバックアップ対象となるため、コマンド内で明示的にCドライブを指名する必要はありません。

逆に、”-allcritical”を付けない場合、たとえコマンド内で明示的にCドライブを指名(-include:C:)してバックアップしたとしても、そのバックアップデータからOS自体の回復は出来ません。Cドライブ内のデータのみ回復可能です。

 

 

なお、今回実際に使ったのは Windows Server 2008 R2 SP1です。Windows Server バックアップの機能が Windows Server 2008よりも強化されており、PowerShell も最初から搭載されています。(Windows Server 2008では、PowerShellもサーバーマネージャーの「機能の追加」で追加する必要があります。)

 

 

さて、「PowerShell」と「Windows Server バックアップ」が両方揃っている環境でも、PowerShellでWindows Server バックアップが出来るとは限りません。

まず最初に、サーバーマネージャーの「機能の追加」で、「Windows Server バックアップの機能」の配下で「「Windows Server バックアップ」の隣にある「コマンドライン ツール」を追加してやる必要があります。

この機能を追加後、PowerShell にて”add-pssnapin windows.serverbackup” というコマンドレットを実行してスナップインを追加することで、やっと”wbbackup“コマンドレットが使えるようになります。

ちゃんとこのスナップインが追加されたかどうかは、”get-pssnapin” で全スナップインの一覧を表示すれば確認出来ます。あるいは、”get-help wbbackup“でヘルプを表示出来るかどうかでも確認出来ます。

(スナップインって何?と聞かれても上手く説明出来ないので聞かないでください。)

なお、サーバーを再起動した後は、またこのスナップインを追加し直す必要があります。なんで消えちゃうんでしょうね・・・  不便です。

 

 

続きます。

2TB超のVHDでは仮想マシンのスナップショットに失敗する!

前回、Windows Server 2008 R2 SP1 の Hyper-V環境において、2TB超のVHDを仮想マシンに接続し、データディスクとして利用できたと書きました。

しかし、その状態では「スナップショット」を取ることに失敗することが分かりました。(仮想マシンはシャットダウンしています。)

この機能が使えないのでは、仮想環境の魅力は半減してしまうのではないでしょうか。

少なくとも私にとっては、半減どころか8割減です。仕事柄、検証などで多用するので。

Windows Server 2008 R2 の Hyper-VのVHDが、最大2TBまでしかサポートしていないというのはこういう意味だったんですね・・・

(Windows Server 2012 で新たに採用された.vhdx という形式は、最大16TBだそうです。)

 

 

今のところ、このVHDを物理マシンに接続した際には特に不都合なことは起きていませんが、何か分かったら都度このブログに書いていこうと思います。

 

2TB超のVHD内に2TB超のファイルを作成。

前回の続きです。 「おそらく次回はありません」なんて言ってましたが、そろそろ舌の根も乾いてきた頃なのでご容赦ください。

 

 

前回、Windows Server 2008 R2  SP1上で約2.5TB のVHDを作成し、同サーバーのHyper-V上にある仮想サーバー(Windows Server 2008 R2  SP1 )にマウントしました。

2TB超のディスクとしてちゃんと認識されるところまでは確認したのですが、一般には「VHD の最大容量は2TBまで」と言われていますので、実際には2TBの容量でしか機能していない可能性もあります。今回はそれを確かめてみました。

 

 

確かめると言っても、実際に2TB超のデータを作成したのでは時間がかかり過ぎます。そこで、こんなコマンドを使いました。

fsutil file createnew E:¥file-1 2400000000000

これにより、Eドライブ(仮想サーバーにマウントした2TB超のVHD)内に2.18TBの「file-1」という名前のファイルを一瞬で作成できます。

なお、コマンド末尾にある容量指定はバイト単位です。出来上がったファイルのサイズは、エクスプローラー上では2,343,750,000 KBと表示され、右クリックしてプロパティを見ると2.18TBでした。

 

 

一応、実質的にも2TB以上の容量を持ったディスクとして機能していることが分かりました。

しかし、Microsoft社が公開している「Microsoft Hyper-V 構成ガイド」には、「VHD は、最大 2,040 GB (2 TB) のサイズをサポートし・・・」という下りがあるので、こういった使い方は「可能だけどサポート外」である可能性が高いと言えます。

サポート外だと何か問題が起きても対処してもらえないので、基本的には自己責任でやることですね。

2TB超のVHD(仮想ハードディスク)を作成。

Windows 7 やWindows Server 2008 R2 では、VHD ファイルを内蔵ドライブとして直接マウント可能なのですが、その容量についてネットで検索すると「最大 2TB まで」という情報が散見されます。

ざっとみたところ、それらの情報は「Hyper-V 」「容量可変」という前提で書かれています。

ちょうどバックアップ用に3TBのHDDを買ってきたところなので、本来の目的に使う前に、「Hyper-V とは関係なく」「容量固定」だとどうなるのか?という実験をしてみました。

(Windows Server 2008 R2 SP1 を使いました。)

 

 

結論、出来ました

E:ドライブとしてマウントした3TBの物理HDDの中に 2.5TBの容量固定のVHDファイルを作成し、それをF:ドライブとしてマウントすることに成功しました。

(作成には4時間以上かかりました。。。 もう二度とやりません。)

なおフォーマットの際には、パーティションのスタイルをGPT形式にする必要があります。旧来のMBR形式を選択すると、MBR自体が2TBまでしか扱えないため、2TBを超える部分が「未割り当て」として残ってしまいます。

※表示上は2TB超だけど、実際には2TB分しか機能しない・・・ という可能性も僅かに残ってはいますが、そこまで検証するのは面倒なので今回はパス。(おそらく次回はありません。)

 

 

次に、Hyper-V 上の仮想マシンのブートディスクとして、このVHDを利用出来るか試してみました。

まずはF:ドライブとしてのマウントを解除。Hyper-Vで新規の仮想マシンを作成してこのVHDを接続し、Windows Server 2008 R2 をインストールします。ところが・・・

インストールウィザードの「Windows のインストール場所を選択してください。」画面で、「このディスクにWindowsをインストールする事はできません。選択されたディスクはGPTのパーティションの形式ではありません。」と断られてしまいました。

いや、GPTなんですけど。。。

ここでパーティションを新規に作り直すと、2TB以上の数値を入力しても2TBのパーティションが作成され、のこりは「未割り当て」となります。この2TBのパーティションを選択すれば「次へ」ボタンがアクティブになるため、おそらくインストール可能です。(実施にはそこまでやってません。)

その状態でインストールを中断し、仮想マシンをシャットダウンしてホスト側にVHDをマウントしたところ、思った通りMBR形式になっていました。

 

 

2TB超のVHDを、仮想マシンのブートディスクには出来ないことが分かったので、次に、既存の仮想マシンのデータディスクとして接続可能か否かを試しました。

まずは、MBRになってしまったVHDをGPTに戻します。それから仮想マシン(Windows Server 2008 R2 SP1)の設定画面でVHDを接続し、起動します。

仮想マシン側の「ディスクの管理」画面で確認したところ、ちゃんとGPT形式のまま、2.5TBの大きなディスクとして認識されています。そのままE:ドライブとしてフォーマットしたところ、ちゃんとエクスプローラーからも2.49TBで認識されるようになりました。

 

 

なるほど、仮想マシンのブートは無理でも、データ用ならオッケーなんですね。