男女比率

私の勤務先のサポート部門では、どういうわけか女性が大変少ない。

 

 

私が所属する Windows の課に限らず、全体的にそうだと言える。

 

 

なぜだろう。

 

 

サーバー女子とか流行らないだろうか。

 

 

流行らないだろうな。

 

 

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のサポート、という仕事。

今時ほとんどの家庭にPCがあるのと同じように、ほとんどの企業には「○○サーバー」があると思います。

実務的にはPCが数台あれば事足りる小規模組織でも、データの共有や保全のためにファイルサーバーを置いているケースもあることでしょう。それも立派なサーバーです。最近は家電量販店でもかなりこなれた価格のものが売っています。

ある程度の規模の企業では、間接部門の中で情報システム部が独立していて、専任のサーバー管理担当者がおかれています。さらに大きな企業になると、外の世界と隔絶されたサーバールームに常駐してサーバーの面倒をみる人がいたりします。

 

 

私が今就いているサポートの仕事では、そういう「現場」の方々からの問い合わせに答え、様々なトラブルや機能面の疑問などを解消し、業務システムの安定運用をお手伝いしています。

仕事の内容はあくまでも「問い合わせへの回答」に限られるため、私自身が現場に赴いて設定作業などをすることはありません。また、効率的・効果的な運用手法についてアドバイスやコンサルティングをすることもありません。それらは、サポートとは違う「別の職種」の仕事となっています。

各職種の棲み分けは会社によっても違うでしょうが、少なくとも今の私の勤め先では明確に切り分けられているため、サポート契約の中にそれらは入っていません。

それと、私自身の守備範囲がWindowsに限られているため、他のOSおよびOS上で動くアプリケーションについての問い合わせは、適宜別の担当者へとお任せすることになります。(そちらのサポート契約があれば、ですが。)

 

 

正直言いまして、" OSのサポートとして出来ること " は限られています。「パソコンなんでも相談室」ではありませんので、「サポートに電話さえすれば、どんな問題もたちどころに解決!」というわけにはいきません。(そんな相談室は世界中探しても無いと思いますが。)

しかし時々、そう誤解していると思われる問い合わせや、首を傾げたくなる(理由は様々)問い合わせが入ることもあります。

今回新設したカテゴリー「サポート雑感」では、そういった問い合わせの例を挙げながら、「OSサポートの使いこなし方」や「OSサポートの在り方」について、思うことを書いていこうと思います。

 

 

※当然ながら守秘義務があるため、実際にあった問い合わせの内容をそのまま載せるわけにはいきません。下手をすると顧客情報の漏洩になりますので。一部を改変したり複数のケースを合体させたりすることで、個別の顧客や個別の問い合わせを特定できないように配慮します。