SSブログ

PHP 再び [Network]

http://windows.php.net/ のサイトを覗いてみたら、PHP のランタイムがバージョンアップしていた。以前、ここで取り上げた時には 5.5 だったのが 7.0 まで進化してしまっていて、殆ど浦島太郎になった気分...と思ったら、なんか 6.x はスキップしているようなので、ちょっと安心。

古いままでも特に困るようなこともないのだけれど、見つけてしまったからにはインストールくらいはしてみようと思う。PHP のランタイムは、システムの設定(レジストリ等)を書き換えるわけでもないようなので、異なるバージョンを共存させることは可能みたいだけど、一応サラの状態に構築してみる。

ザックリとした手順は以下の通り。

 

  1. IIS (Internet Information Services) 
    IIS の上で PHP を稼働させたいのでコレは必須。サーバーマネージャーの役割と機能の追加(サーバー)あるいはコンパネのプログラムと機能(クライアント)がら Web サーバー (IIS) を追加する。必要なオプションとして、[Web サーバー] - [アプリケーション開発] 以下にある CGI を追加してやればいい。
  2. SQL Server
    これも上記と同じ理由で必須。取り合えず、細かいこと考えずにフルインストールしちゃった。
  3. PHP 7.0
    http://windows.php.net/download/ のなかで一番新しそうなパッケージのうち Non Thread Safe となっているものをダウンロードしてきてインストール。インストールとは言ってもインストーラーパッケージは提供されていないため、zip を解凍して配置後、設定ファイルを自分で書き換える必要がある。
    書き換えが必要な情報は、PHP on Windows ガイドライン の 4 章の情報で大体大丈夫。
  4. SQL Server driver for PHP
    PHP から SQL Server を使用するためのドライバーはここにある。製品候補という事なので、正式版が公開されたら差し替えたいと思っている。このバージョンから(?) x64 と x86 の両方が公開されるようになったみたい。一応、両方とも試してみたけど(サンプル程度の動作では)問題なかった。
  5. ODB Driver
    SQL Server driver for PHP が使用するらしい。検証時点で ODBC Driver 13 は Preview 版のみの公開だったので、ちょっと古い ODBC Driver 11 で動作を確認してみた。
上述の通り x64 の環境と x86 の環境を共存させる形で構築してみたのだけど、ランタイムとドライバーの形式さえ合わせておけば特に問題なく動作する模様。

 


半壊 [Network]

SharePoint Server を LAN に導入しようと準備をしていたのだけど、チョットした災難に見舞われて作業が滞っている。検証用に使用している自宅の LAN 環境では、(外部に公開はしていないものの)色々とサーバーを稼働させている。ホストの数がかなり多いので Active Directory も勉強を兼ねて展開している。Microsoft のサーバー群は Active Directory が前提となっているものも結構あるので(Exchange Server や SharePoint Server がそう)結構重宝していた。

 今回、Active Directory を担うサーバーを含む数台(仮想環境で構築していたのだけど、ホストがコケるとゲストは全滅しちゃう)のサーバーがお釈迦になってしまったことで、ネットワークが半壊状態に陥ってしまった。

障害状況は下記の通り。

  • Domain Controller(Active Directory Domain Services)
    Active Directory 自体の恩恵なんて普段はあまり実感しなかったんだけど、使えなくなってみるとその効果がよくわかる。というか、これがないとなにもできなくなってしまう。さらに悪いことに、今回は FSMO の 5 要素を一手に引き受けていたホストが被害にあってしまったために「役割の強制」を実施することになってしまった。MCP を受けるときに一応は勉強したけど、実施したのは初めて。結構ドキドキものだった。
  • Windows Deployment Services
    今回、改めて気づいたんだけど、ウチのネットワーク環境には常時稼働状態にある DVD/BD というのが存在しない。殆どのソフトは ISO 形式で保存しているし、OS は常に WDS を使用したネットワークブートで賄っている。WDS を Domain Controller で動作させていたため、一緒に使えなくなってしまった。仮想マシンは ISO から直接インストール可能なんだけど、物理マシンはそうもいかない。
  • Hyper-V
    物理マシンは全て Hyper-V を稼働するサーバーになっている。1 台コケると 10 台近いサーバー群が一気に利用できなくなるのは結構イタい。とはいっても、仮想環境を利用せずに今の環境に近いものを構築するのはちょっと無理。チョットした教訓にはなるかも。運用を生業にする気はないけど。
  • Active Directory Certification Services
    Active Directory の環境で、かなり過保護に育てられるのがこの子。一度構築してしまうと、転身することができなくなる証明書サービス。業務用として利用しているわけではないので、壊れてしまったら別の証明書サービスを建てたらすむのだけど、結構な手間がかかることを実感した。
  • Windows Server Update Services
    Windows Update を中継するだけの割にディスクをバカ食いするこのサービス。常時 2TB のディスクを割り当てるようにしていたのだけど、無くなってみるとネットワーク負荷削減には結構効果があったのだと感じる。新規インストールする環境が多くなると覿面に現れる。
  • Dynamic Host Configuration Services
    ブロードバンドルーターが DHCP をサポートしていることが多いのだけど、上記の WDS が必要としていたために導入していた。一応 2 系統展開していた(スコープは異なる)ので、IP を求めることはできていたのだけど、デフォルトゲートウェイに死んだサーバーを指定していたため、結局はネットワークが麻痺してしまった。

なんだかんだ言っても、Active Directory が逝ってしまったのが痛い。軒並み名前解決ができなくなり、RDS(Remote Desktop Services) が通らないし、Hyper-V マネージャも繋がらない。ホストにキーボードとマウスを繋げるなんて何年ぶりだったろうか。

一応、仮想マシンのバックアップはとってあったので、バックアップからの復旧は可能な状態ではある。ただし、復旧するか、新たに構築するか、ちょっと考えようと思う。復旧しなければならないような情報がないということが解ったので、この際、新しいバージョンにしてしまおうかと思案中。

 


LAN [Network]

自宅の LAN 環境をちょっと改造しようと思う。

現行の LAN は Active Directory をコアとした Windows Network なんだけど、仕事の絡みもあって SharePoint を導入してみようと思う。

以前に一度チャレンジして失敗しているので、かなり不安ではあるんだけど、サーバーサイドのギミックを扱うためには SharePoint Online では無理みたいなので再チャレンジしてみる。

 


Outbound Port 25 Blocking [Network]

メールの送信に際して、SMTP の標準ポート 25 番を利用できない設定としているプロバイダーが結構ある。代わりにサブミッションポートと呼ばれる 587 番への接続を利用することで、メールの送信は行えるようになるので取り敢えず問題は起こらないようにはなっている、、、まあ、近くにこのあたりの事情に詳しい人がいればねぇ。

会社でメールシステムを利用しているのであれば、専任の技術者がいる(はず?)だろうから、解らなければ内線電話で確認すればいいだろうけど、個人的にネットワークに繋いでいるような場合だと全て自分で処理しないといけない。中にはユーザーアカウントから接続先を自動で設定してくれるメールソフトもあるようだけど、そうでない場合にはダイアログに書かれた意味不明な用語を電話の向こうのサポートエンジニアに伝えなければならない。多くのサポートエンジニアは初心者にでも解るように話しをしてくれるようだけど、中には外れのときもあって煙に巻かれるだけで何も解決しない場合もある。

メールソフトの設定に必要な情報は下記の通り。殆どの設定を自動でやってくれる web の設定と比べると多いような気もする。

  1. メールアドレス
    プロバイダーから提供された、自分のメールアドレス。これが解らないとメールの送信も受信もできないので、ちゃんと控えておく。
  2. アカウント / パスワード
    プロバイダーによって、メールアドレスとユーザーアカウントが同じであることも、異なることもある。プロバイダーの web サイト(web メール等)にログインするアカウントと同じになっていることもある。
  3. 送信メールサーバー / ポート番号
    送信サーバーの設定が必要な場合、大抵は SMTP サーバーの FQDN を指定することになる。Outbound Port 25 Blocking を導入しているプロバイダーであればポート番号は 587、そうでなければ 25 番を指定することになる。
  4. 受信メールサーバー / ポート番号
    受信メールサーバーは POP3 あるいは IMAP4 のいずれかを指定することになる。POP3 なら 110 番、IMAP4 なら 143 番が標準。
  5. 暗号化接続の種類
    SSL や TLS を利用する場合には上記のポート番号が変わることがあるのでこれも確認する。

ひとつでも間違えるとまともに送受信できないので結構敷居が高いかもしれない。面倒でも送受信が可能とわかっているデバイス(スマートフォン) 相手にテストメールを送り続ける(導通試験)のが手っ取り早いかもしれない。

多少イレギュラーではあるけど、自分でメールサーバーを建ててプロバイダー経由でメールの送受信をするような設定 (Smart Host) を試す場合も上記の設定が必要になる。

 


Active Directory Certificate Services [Network]

暗号化やディジタルシグネチャといった機能を利用するさいに必要になるのが証明書。一般公開するような証明書が必要な場合には信頼されている認証局によって発行された証明書が必要になるけど、例えば、社内だけで流通させたい文書を暗号化させたいといった用途にはオレオレ証明書のようなものでも結構役に立つ。

Microsoft の提供するサーバーコンポーネントには IIS (Internet Information Services) を利用した Web アプリケーションを配置するものが多い。セキュリティの面を考慮すると HTTPS を利用するようになり、そのたびに証明書が必要になってくる。

Active Directory Certificate Services 自身も証明書の発行のための Web サイトを公開するのだけど、最初にアクセスするときは証明書がないために「信頼されてない」と警告が出てくるのはご愛嬌なのかな?その後、証明書を配置することでそんなメッセージはでなくなるけど、なんとなくモヤモヤ感があった。

IIS には証明書の要求の作成を支援してくれる機能があるのだけど、SAN (Sabject Alternative Names) を指定したいときはちょっと手順が必要。一応 https://support.microsoft.com/ja-jp/kb/931351 が日本語のオリジナルだと思うのだけど、「Windows Server 2003 のサポートは 2015 年 7 月 14 日で終了しています」なんてコメントが表示されてしまう。KB の文書は残っているみたい。

PowerShell のスクリプトをファイルサーバー上の共有フォルダにおいたまま実行するような場合、スクリプトにコード署名を挿入することができる。こうしておくことで PowerShell のセキュリティ要件を弱めず(ローカルで作成したスクリプト以外は実行できない)にスクリプトの利便性を高めることもできる。

AD CS は一度立ててしまうと無傷のまま解体はできないらしい。セットアップは DHCP 同様すぐに終わるのだけど、試しに作るにしても慎重に。

 


Dynamic Host Configuration Protocol [Network]

コンピューターがネットワークに接続する際に、必要な情報を割り当てるための手順を指す。名前の通り手順(Protocol)なので、これをサポートするサーバーを DHCP サーバーなどと呼ぶことがある。

DHCP によって自動的に割り当てる情報というと、ホストの IP アドレス、ルーターの IP アドレス(デフォルトゲートウェイ)、DNS サーバーの IP アドレス等が一般的だろうか。このあたりの情報であれば、最近のブロードバンドルーターに搭載されている DHCP サーバーの機能でもサポートされているはず。

前回の WDS を利用する際に DHCP サーバーが必要になるのは、クライアントがWDS サーバーの IP アドレスを DHCP サーバーから貰う必要があるから。PXE を使用して情報を得る場合、一般的な OS が起動していないことが多いため、必要な情報を外部から取得可能にするための配慮なのかもしれない。全てを調べたわけではないけれど、WDS を使用するための情報は、ブロードバンドルーターではサポートされていないと考えた方がいいかもしれないね。

Windows が搭載された PC を購入してきて、何もせずにルーターに繋げばインターネットに繋げてしまう。これは、一般家庭においても、ブロードバンドルーターを介してインターネットに繋いでいるのであればほぼ DHCP の世話になっているという事になる。ネットに繋ぐ必要のある PC が大量にある企業では当然の様に採用されているだろう。何100台、何1000台とある PC の設定を手作業でやるなんて、ちょっと考えたくないからねぇ。

全てのデバイスの IP アドレスを固定にしてしまえばよさそうだけど、デバイスが増減することで設定を変更しなければならなくなった時のことを考えると鬱になりそう。ただ、なかには DHCP を禁止しているところもないことはない。PC を持ち込んでネットに接続させて貰うときに IP アドレスの提供を受けるのだけど、そのたびにシステム管理者を不憫に思う。

Windows Server に含まれる DHCP サーバーのセットアップは難しくない。役割を追加して DHCP のアドレス範囲を設定してやれば殆ど稼働してしまう。だからというわけではないのだけど、同一ネットワーク内で複数の DHCP サーバーが稼働してしまう可能性がないわけでもなく、その点は注意しなくちゃならない。社内ネットワークに内に(勝手に)ドメインを構築し、DHCP サーバーを稼働させてしまったために、社内ネットワークがマヒし業務が停止してしまった例を見たことがある。

Windows Server の DHCP には、DHCP によって得られた IP アドレスを DNS サーバーに登録する機能が含まれている。DNS が Active Directory に統合された環境では、個々のホストが自ら登録するより都合がいいのだろうか。

 

 


Windows Deployment Services [Network]

PC を起動する方法はいくつかある。一番オーソドックスなのは OS をインストールしたハードディスクから起動する方法。また、OS がインストールされていない環境ではリムーバブルメディア等からインストーラーを起動する方法もある。一部の OS では、USB メモリから起動可能な OS を利用することが可能なこともある。

これらは、PC に配置されている BIOS (Basic Input Output System) によって提供されている機能により使用可能か否かが決定されている。最近の PC では上記のような起動方法は全てサポートされていると考えても差し支えないだろう。これらは手元にブート可能なメディアがある場合にのみ利用可能な方法という事になるのだけど、実はもう一つの変わり種がサポートされていることがある。

ネットワークブートあるいは PXE (Pre-boot Execution Environment) という機能が NIC (Network Interface Card) 上の ROM によってサポートされていることがある。字面から想像できるとは思うのだけど、ネットワークからブートし PC を起動させる方法といったところ。上に挙げた方法と異なり、ブートアップするプログラムを提供するサーバーを配置することが必要ではあるのだけど、一度配置してしまうとインストール対象の PC をネットワークに繋げさえすればインストールが可能になるという、なんとも便利な機能が手に入る。

WDS (Windows Deployment Services) というのが、Windows Server に同梱されている PXE 対応のサーバーソフトウェア。PXE を利用するためには DHCP サーバーが PXE サーバーの IP アドレスを通知してくれる必要があるため、ブロードバンドルーターが提供する DHCP サーバーの機能だけでは賄えない場合もある。Windows Server のインストールメディアには DHCP サーバーも含まれているので、必要であれば展開すればいい。

Windows Vista あるいは Windows Server 2008 以降の OS であれば、WDS を利用してインストールするのは至って簡単に行える。インストールメディアからインストールイメージを抜き出して使ってもいいし、SysPrep を使ってカスタマイズした環境を構築しておいてもいい。WDS の本来の目的はマルチキャストを使った一斉インストールという事になるのだろうけど、そこまでやらなくても結構便利に使える。

物理環境のインストールをしたいのであれば、上述の通り PXE をサポートしている環境が必要なのだけど、Hyper-V のクライアント環境でも PXE が利用できる。

あまりネットワーク負荷のかかる環境で試したことはないのだけれど、DVD のような光メディアを使用してインストールするよりも WDS を利用した方がインストールにかかる時間は短くなるようだ。

ネットワーク環境につながるデバイスが増えてくると、デバイス毎にイチイチ手動で IP アドレスふ振るのは現実的でない。また、WiFi を展開しているならスマートフォンからネットワークにアクセスしたいなんてことも考える。

こんな需要を満たすために、接続してきたデバイスに対して適切に IP アドレスを払い出してくれる機能が DHCP。企業のネットワーク環境では殆ど確実に導入しているだろうし、ブロードバンドルーターを利用している環境では知らずに恩恵に預かっている可能性もある。次回はこの、DHCP サーバーについてのお話し。

 


Windows Server Backup [Network]

将来何かの訳に立つかもしれない、いざというときに何も備えてなかったとしたら不安なので元気なうちに何かしらの対策を、、、というときに使われるのが保険というもの。コンピューターシステムで一番手軽に利用される保険と言えばバックアップがオーソドックスなところだろう。

Windows Server のインストールメディアには Windows Server Backup というバックアップツールが含まれており、必要であればこれを利用することも可能になっている。

Windows Server Backup は単発のバックアップや定期的なバックアップをスケジュールするという機能は備えているものの、オプションの選択肢は多くない。ヘビーユーザーでなくてもお手軽に使える程度のツールとして捉えるといいかもしれない。慣れないうちはベアメタル回復を選択しておけば、対象サーバーを丸ごとバックアップしてくれるようなイメージになる。

バックアップ対象の容量が急激に増加しているため、以前のように光メディアにバックアップするなんていう手法はまず採れない。市販の NAS (Network Attached Storage) も価格の割に容量は少ない上に遅いので殆ど実用にはならない。そこで、私は以下のような手順でバックアップしている。

・安価なベアボーンを購入、Windows OS をインストールしてファイルサーバーを構築。バックアップ用のディスクを除く費用はおよそ \20,000 程度の構成。Giga bit 対応のイーサネットや SATA が利用できることを考慮しているけど、今なら当然の様にサポートされているので、これで価格が上昇することはないだろう。
・バックアップの時期(大体月に1度くらい)になると、2TB 程度の内蔵ハードディスクを数基購入してきて、上記のファイルサーバーに装着。ディスクアドミニストレータを起動して当該ディスクを有効化する。
・ネットワーク上のコンピューターのバックアップスケジュールを設定し、順次バックアップさせる。バックアップ先はファイルサーバーに繋いだハードディスク。大体、金曜日の夜に作業を開始すると、土曜の昼頃にはすべてが完了するので時間を見計らってファイルサーバーをシャットダウンする。後はハードディスクを抜いてしまえば作業完了。ハードディスクは図体の割に結構重たいけれど、場所はあまり取らないので保管するにも便利。

ハードディスクの価格は結構変動があるようで正確には解らないところもあるけど、2TB 程度のものだと凡そ \8,000 くらい(高価なものはありますが、バックアップ用のストレージとして使うだけなので、これくらいで充分かと)から購入可能。また、4TB 級の NAS を用意すると \30,000弱といったところなので、およそ 4 割程の経費節減ができる。Windows ネットワークに Windows OS を搭載したファイルサーバーを配置した場合、一般的な NAS とのパフォーマンスの違いが体感できるほどです。加えて Active Directory にも普通に参加できますので使い心地はバツグン。

現在、私の(ノートを含めた)物理環境で稼働している OS は全て Windows Server の 2008 R2 となっているので、すべてが 64 bit OS という事になります。なので、ハードディスクの容量を 2TB にこだわる必要はないのかもしれません。

既に市場には 8TB なるハードディスクも登場しているようです。出典が思い出せないのですが、「データ量は与えられた記憶装置のスペースを満たすまで膨張する」なんていう法則があったような気がします。これだけの容量を使いきるには何を溜め込んだらいいんでしょうか、、、マルチメディア関連の容量増加はすさまじいものがあるようですが。

最近は仮想環境が普通に使えるようになってきているので、業務に差し支えなければシステムを一度停止させて仮想ディスクをそのままバックアップしてしまうという荒業が使えない訳ではない。こちらの場合、普通にエクスプローラーでファイルをドラッグするだけでバックアップできてしまうのが大きなメリットになるかもしれない。

システムのバックアップはそれ自体を目標にするものではないはず。いざというときに利用できなければ何の役にも立たない。なので、いくつかの憂慮事項は先に押さえておく必要がある。一度はリカバリ手順を実行しておくと、より安心できるかもしれない。

・システム全体をバックアップした場合、ハードウェア構成が変ってしまうと戻せない可能性がある。必要なものだけを取り出す手段があるのか確認する。
・Active Directory の環境では、バックアップした環境をそのまま戻せなくなる可能性があるので、そのための対応手段を把握しておくこと。
https://support.microsoft.com/ja-jp/kb/2771040

上記の症状は、ドメインに参加しているコンピューターのアカウント(とパスワード) の情報がドメイン コントローラーで不一致になってしまうことで発生するらしい。ユーザーアカウントの場合、ポリシーによって一定期間が経過したパスワードはユーザーの入力によって変更させられることがあるけど、コンピューターアカウントはそれが自動で行われている。常時起動されているコンピューターであれば問題にはならないはずなんだけど、バックアップからリストアした環境だとパスワードが不一致になってしまうことがあるとか。

対処方法としては Active Directory ユーザーとコンピューターからのアカウントのリセットするだけではダメで、当該コンピューターを一度ドメインから外し、再度参加させるという手順を踏む必要がある。上記の URL にはこの手順(だけ)が記載されている。

この手順を踏むために、ドメイン管理者の権限以外にローカル管理者の権限(最初に作られる Administrator でいい)を有効にしておく必要がある。私はなぜかドメインコントローラーでこの症状を発現させたことがある。ドメインコントローラーのローカルアカウント、、、どうしろって言うんでしょうかねぇ。

私は検証環境を整備するために Active Directory を展開したところがある。ソフトウェアの動作環境として、素の状態の環境を構築、動作検証を実施して、作業が終了したら捨てるという手順を繰り返しているのだけど、毎回インストールメディアを引っ張り出してきて OS のインストールを実行するのも結構面倒。Windows Server にはこれを簡単に実現してくれるも提供されている。

次回のネタは Windows Deployment Services です。


Active Directory [Network]

Microsoft 系の OS でネットワークを構築する場合、その中心に据えられるのが Active Directory。Active Directory の主たる役割はアカウントの管理。Kerberos 認証と呼ばれるユーザー認証機能と共にグループやサービス、コンピュータの ID を一元管理する機能を提供している。

アカウントというと、コンピューターにログオンする際に使用するユーザーアカウント以外に思いつかないこともあるけど、ネットワークの中でお互いがお互いを認識するための機能として、人知れず利用されている絡繰りでもある。また、アカウントの影響範囲を定めた括りを、従来の DNS のドメインと関連付けたのが Active Directory の基本的な構成単位となっている。

ちなみに、ドメインという考え方は SMTP (Simple Mail Transfer Protocol) というメール送信のためのプロトコルの基礎になっているもの。Microsoft 製のメールサーバーである Exchange Server が Active Directory と密に連携しているのは偶然ではないのかもしれない。もしかして、Exchange Server のアカウント管理機能をActive Directory として切り出した?

Active Directory 自体の考え方は、従来のドメインの考え方と大きく変わってはいない。大きく違うのはドメインに特化した製品群を次々と世に送り出し、Active Directory の付加価値を知らしめたところなんじゃないだろうか。Exchange Server, SharePoint Server, SQL Server といった製品群は Active Directory が存在する環境において本来の機能をフルに発揮できるように設計されていると思う。

組織の中で Active Directory が利用される場合、Active Directory の提供するグループポリシーという機能が活用される傾向がある。組織内のコンピューターを一元管理できるこの機能は、システム管理者にとっては無くてはならない機能のひとつとも言える。何百台もあるコンピューターをひとつひとつ設定して回るなんて、人手でやりたいと思う人も少ないだろうし。一定時間操作していないとモニターの電源落とされてしまうとか、リムーバブルメディアの使用禁止とか、パソコンを使って作業している立場からするとウゼェと思うような設定も少なくはないのだけれど。

技術的に難解な部分が多い Active Directory ではあるけれど、使っているうちに Active Directory の便利なところも徐々に見えてくる。多分、今のネットワーク環境を捨てて、ワークグループに戻そうなどとは思わないくらいには。

ひとつのネットワーク内で、コンピューターを利用する一般ユーザーのアカウントを複数使用することは多くないだろう。特権を与えられていない、一般のアカウントを複数持つのは、(セキュリティ上は有効化もしれないけど)かなり辛いものがある。多くの場合、ひとりのユーザーに対してひとつのユーザーアカウントが割り当てられることになると思う。そんな環境に新しく高性能パソコンが導入され、それを利用する場合、Active Directory が展開されている環境であれば、当該パソコンをドメインに参加させさえすれば、自分のアカウントを使ってログオンし利用することが可能になる。ワークグループ環境であれば、新しくアカウントを作成し、アカウントに権限を与え、さらにネットワーク上のリソースにアクセスするための設定を施して、、、という雑多な手順を踏まなくてはならないのと比べるとかなり省力化できる。

Active Directory 自体が大量のストレージを使用するような技術ではないし、また、CPU 負荷の大きい処理でもないことから、型落ちしたような環境でも意外にスムースに動作する。最も、大規模なネットワーク環境においてはそんな前提も成り立たないだろうけど、「お試し」程度で遊ぶくらいなら殆ど費用をかけずに実現できる。

ただ、Active Directory も万能ではない。アカウント情報が消失してしまった場合など、人手で復旧する以外に手段がない場合もある。そんな時に役に立つのは日頃のバックアップかもしれない。ハードウェアはいずれ壊れてしまう可能性があるわけで、万が一に備えて対応策を施すのはシステム管理者としては最低限の良心かもしれない。まあ、私自身はシステム管理者になるつもりなんて毛頭ないけど、定期的にバックアップは取るようにしている。幸運にも未だかつてバックアップが役に立ったという経験はありませんが。

次回は Windows Sever Backup のお話し。

 


ネタ振り [Network]

本職ではないのだけれど、ネットワークの設定をいじることもある。適応範囲は Microsoft 系のネットワーク限定なのだけど、社内ネットワークに Exchange を配置しているようなところだと必然的に Active Directory を展開することになるので、意外に需要が多かったりする。

ネットワークに繋ぐコンピューター機器が増えてくるとアカウントの集中管理をするためのディレクトリィ システムが必要になってくる、、、と、いうようなことがその手の教科書に記されていることが多い。私の場合は 100% 興味本位。MSDN (Microsoft Developer Network) の会員でもあったので、そこで提供されるサーバー OS (Windows Server 2008) を中古のパソコンにインストールしてみたのがネットワークに足を突っ込むきっかけだった。

Windows ではワークステーションでもサーバーでもインストール手順は左程変わらない。DVD からブートしてインストールすれば殆どの場合失敗することはないだろう。意外に厄介なのはその後のセットアップ。サーバー OS はインストールしただけだと何も機能しないというのが最近の Microsoft 流なのだろう。とりあえず Internet Explorer は使えるので Web を徘徊することくらいはできるだろうけど、それじゃサーバー OS の意味もないし、、、。

Windows でサーバー群を構築する場合、サーバー版の Windows をインストールしたのちに、役割に応じて必要なコンポーネントを追加セットアップする必要がある。Active Directory や IIS (Internet Information Services) のように Windows Server に同梱されているものや SQL Server のように別の製品として扱われているものがあるけれど、基本的な流れとしてはほぼ同様の扱い。ただし、Exchange Server のようにドメインネットワークが必要なものや、ドメインネットワークとワークグループの両方をサポートしているものの利用できる機能や設定方法が微妙に異なっているものもある。私が、一番最初に構築したネットワークはこんな感じ。

  • サーバー OS を建てて、開発用に IIS をホストする。SQL Server も入れておこうか。
  • 開発マシンと連携させたいから、取り敢えず Active Directory も展開しよう。

これを数日かけて構築し、ネットワーク関係の実験台として機能するようになったものが、自宅の LAN 環境の礎になっている。

次回から数回に分けて、Microsoft ネットワークの機能についてまとめてみたいと思う。なお、内容については、「どうやって使う」ではなく「何ができる」をメインにするつもりです。


 実はひょんなことから、Microsoft ネットワークの機能についての説明をする羽目になってしまった。その時の資料を基に、要旨を抜粋したものをココに載せておくことにします。


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。