” システムで予約済み ” パーティション <1>

まっさらなハードディスクにWindows OSをインストールすると、通常はCドライブが作成され、そこにOSが入ります。インストールのウィザードにおいて特段何もしなければ、Cドライブとは別にデータ用の領域が作成されるということはありません。

ところがWindows Server 2008 R2 やWindows 7 の場合、Cドライブと一緒に、それもHDDの一番先頭に「システムで予約済み」というパーティションが作成されます。容量は100MBしかありません。

このパーティションにはドライブ文字が割り当てられていないため、OSインストール後に[スタート]メニューから[コンピューター]を開いても、Cドライブしか見えません。しかし、「ディスクの管理」画面を開くと、Cドライブより左(先頭)側にこのパーティションが在ることとが分かります。あるいは、”diskpart“コマンドで”list volume“を実行することでも表示されます。

いったいこのパーティションは何なのでしょうか? 無いとどうなるのでしょうか?

 

 

まずは中身を見てみましょう。「ディスクの管理」画面で右クリックしてやればドライブ文字を割り当てることが出来るので、適当に何か割り当ててやればエクスプローラーで開くことができます。一応ここではFドライブとします。

普通に見ても空っぽなのですが、エクスプローラーの「フォルダー オプション」で「保護されたオペレーティング システム ファイルを表示しない(推奨)」を無効化することで中身が表示されます。するとなにやらOSのブートに関するフォルダやファイルがあります。というか、それしかありません。

Fドライブ直下にあったのは、

・Boot  (フォルダ)

・System Volume Infomation  (フォルダ)

・bootmgr  (ファイル)

・BOOTSECT.BAK  (ファイル)

の4つだけでした。(”dir F: /s /A”コマンドを使えば、Bootフォルダの中身まで表示されます。)

このBootフォルダの直下に在るBCDというファイル(ブート構成データ)は、OSをブートする為に非常に重要です。これが壊れるとブート出来なくなるそうです。

こちら↓のサイトでいろいろ興味深い実験をしています。

◆ win7 システムの修復

(http://ftlabo.sakura.ne.jp/win/w7-system-repair/w7-system-repair.shtml)

 

その他、マイクロソフトのサイトにも解説が載っています。

◆ ブート構成データ エディタに関してよく寄せられる質問

(http://technet.microsoft.com/ja-jp/library/cc721886(v=ws.10).aspx)

この↑サイトを見ると分かりますが、BCDによるブートの制御自体は、Windows Server 2008 やWindows Vistaの段階ですでに採用されています。しかし、それらのOSではCドライブ内に存在しました。ではどうして、Windows Server 2008 R2 やWindows 7 では独立したパーティションが作られるようになったのでしょうか?

 

 

手がかりとなりそうな情報が、同じくマイクロソフトのサイトにありました。

◆ ヒント: 不可解な小さなパーティションを理解して削除する

(http://technet.microsoft.com/ja-JP/windows/Win7_Tips65)

◆ ハード ディスクを BitLocker ドライブ暗号化用にセットアップする

(http://windows.microsoft.com/ja-jp/windows-vista/set-up-your-hard-disk-for-bitlocker-drive-encryption)

 

 

どうやら、「BitLocker」という暗号化機能のためのようです。BitLocker機能自体はWindows Server 2008 やWindows Vistaの段階ですでにあったのですが、OSが存在するCドライブ自体を暗号化したい場合には、「OS起動用の領域」を手動で切り分ける必要がありました。なぜなら、BIOSは暗号化されたCドライブを直接認識出来ないからです。

それを最初から独立させておいたのが、Windows Server 2008 R2 やWindows 7における「システムで予約済み」というパーティションなのです。

 

つづく

netsh の運命や如何に。

Windows Server 2012 R2 のプレビュー版が、6月中には公開されるそうですね。

ソースは、Microsoft Cloud というMicrosoft社によるツイッターアカウントです。

 

 

Windows Server 2012 では、コマンドプロンプトで ” netsh ” を実行し、次に ” interface ” 等を実行した時点で「Windows の将来のバージョンで、TCP/IP の Netsh機能が削除される可能性があります。」と表示されます。そしてPowerShell への移行を促されます。

さて、Windows Server 2012 R2 ではどうなっているでしょうか。

 

 

本当に無くなるのはさらに次のバージョンかもしれませんが、 “netsh” が無くなるとすると、これまで蓄積してきたスクリプト等の資産に少なからぬダメージがあるのではと思います。Windows Server 2008 R2 以降はパケットキャプチャまで出来ますからね。

Windows Server 2003 では OS 自体に標準で付属していたキャプチャツール「 Network Monitor 」が、Windows Server 2008 以降はダウンロードツールになりました。

商用稼働中のサーバーの場合、障害調査のためといえど、パケットキャプチャのためにフリーソフトをインストールすることなど言語道断!なケースもあります。たとえ Microsoft 純正であっても。そんな時には、 “netsh>trace” コマンドが有効な手段となりました。

パケットだけでなくネットワーク関連の様々な情報をまとめて採取出来るので、パケットキャプチャ自体が不要だったとしても、ネットワークの障害調査には有用なコマンドだと思います。

 

 

今のところ、Windows Server 2012 標準のPowershell v3.0 には、パケットキャプチャのコマンドレットは無いようです。Windows Server 2012 R2 には新しいバージョンが搭載されるのでしょうか。あるいは、バージョン自体は同じでモジュールの数が増えるのでしょうか。今から楽しみです。

 

 

ちなみに、Windows Server 2012 の PowerShell で “Get-Wild” と実行すると・・・

何も起こりません。

Windows Server 2012 R2  に期待します。

Netdom join コマンドによるドメイン参加。

コンピューターをActive Directory のドメインに参加させる方法はいくつかありますが、その一つに、”Netdom join ~~” というコマンドがあります。

グーグルで「Netdom ドメイン参加」で検索すると、少なくともこの記事を書いている時点では、検索結果のトップに「IT Pro」の下記サイトが表示されます。

仕事に役立つコマンド入門   netdomコマンドでドメインに参加する

 

 

最低限必要と思われるオプションを網羅したコマンド例が載っていて助かるのですが、1点だけ気になるところがありました。

参加したいドメイン名を指定する、”/domain:example” の部分です。

これって、いわゆるひとつの 「NetBIOS ドメイン名」ですよね? じゃ、NetBIOSによる名前解決が可能な、同一セグメント内でしか通用しないんじゃ・・・?

 

 

実機(Windows Server 2008 R2 SP1)で確認したところ、ドメインコントローラーとクライアントコンピューターが別セグメントに存在する場合は、確かにドメイン参加に失敗しました。

たとえクライアント側で「優先DNS」にドメインコントローラー(兼DNS)のIPアドレスを登録しておいたとしても、NetBIOSドメイン名だけの記述では不十分だということです。NetBIOSなんですから。

そういったケースでは、例えば ”/domain:example.local” のように、FQDNを最後まで記述する必要があります。そうしたところ、ドメイン参加に成功しました。

ちなみに、TechNet の Netdom join の解説ページでは、コマンド例がFQDNで記述されています。

 

PowerShell における「変数」の扱い

PowerShell における「変数」について調べてみました。

PowerShell にはデフォルトでもいくつかの変数が存在します。PowerShell のバージョンを確認出来る “$psversiontable” は、やったことのある方も多いのではないでしょうか。(Windows Server 2008 R2 に標準搭載されている PowerShell V2.0 以降にしか存在しない変数ですが。)

 

 

コマンドプロンプトでも、「%」で前後を括る事により、「環境変数」を使うことが出来ました。例えば、現在ログオンしているユーザー名を表示するためには、”%username%” を実行します。(結果として表示されるユーザー名がコマンドとして実行されてしまうことを回避するには、”echo %username%” を実行します。)

ではPowerShell で”$username” を実行するとどうなるかというと、なにも起こりません。PowerShell においては、「$psversiontable」 のような「変数」と、従来の「環境変数」とは別物のようです。

調べた結果、PowerShell で「現在ログオンしているユーザー名」を表示するためには、”$env:username” を実行すればよいことが分かりました。

この「env:」とやらは一体なにものでしょうか? 実はこれ、「PSドライブ」の一種なのです。(調べれば調べるほど、次から次へと新しい用語が出てくるので参ります。。。)

 

 

PSドライブ」はPowerShell 独特の概念のようです。PowerShell だけが扱える仮想的なファイルシステムのようなもの、と言えるかもしれません。

従来のコマンドプロンプトでは、Cドライブ等のファイルシステムのディレクトリの中を見るには「dir」コマンドを用いましたが、同じような階層構造を持つレジストリの場合、別途「reg query」コマンドを用いる必要がありました。Powershell の場合はどちらも「PSドライブ」として扱えるので、「get-childitem」という共通のコマンドレットで両方の中を見る事が出来ます。

PSドライブの一覧を確認するには、”get-psdrive” を実行します。すると、マウントされているドライブやレジストリ(HKCU、HKLM)の他に、「Env」もあることが分かります。

 

 

「Env」がPSドライブであるならば、同じくPSドライブであるCドライブの中身を見る時と同じように、”get-childitem” コマンドレットでその中身を見る事が出来るはずです。そこで”get-childitem env:” を実行してみたところ、「環境変数」の一覧を取得することができました。もちろんその中には「USERNAME」もあります。

$env:username” の意味は、「PSドライブ『Env』配下にある環境変数『USERNAME』に格納されている値を、『変数』として呼び出す」というものだったようです。

 

 

なお、「$」を先頭に付与する事で、PSドライブ配下の「変数ではないもの」を、変数のように扱う事が出来ます。

たとえば、”${C:¥1.txt}” を実行する事で、Cドライブ直下の「1.txt」というテキストファイルの中身を表示出来ます。(パス全体を{}で括る必要があるのは、おそらく「¥」が特殊記号だからでしょう。)

 

 

では、PSドライブを明示する必要が無い、「$psversiontable」のような「純粋な変数」の情報は、一体どこに存在するのでしょうか。

調べたところ、PSドライブ「Variable」の中にありました。このPSドライブの中にある「変数」は、変数名の先頭に「$」を付けるだけで(variable: は記述せずとも)呼び出す事が可能です。Variable 配下の変数の一覧は、”get-variable” ないし “get-childitem variable:” を実行することで確認出来ます。

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 でやってみる。<変数編 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 でやってみる。<実践編>

前回、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“でヘルプを表示出来るかどうかでも確認出来ます。

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

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

 

 

続きます。