Windows インフラ

コンピューターの世界で文字がどのように扱われているかということを理解するには「符号化文字集合」と「文字符号化方式」という2つの異なる概念があり、それぞれがどのようなものであるかを理解することが非常に重要です。これを理解しているかいないかでコンピューターの世界での文字の扱いに関する理解がまったく違ってきますのでぜひ抑えておきましょう。 符号化文字集合 まず符号化文字集合というのは「どのような文字を扱うか」ということを定義するものです。文字といってもアルファベット、ひらがな、カタカナ、数字、記号はもとより日本語には非常に多くの漢字が存在しています。さらに世界に目を向ければいったいどれだけの数の文字が存在しているのでしょうか? ちょっと検索してみると以下のようなサイトが見つかりました。 世界の文字　Written characters of the world ちょっと見てみてほしいのですが、ものすごい数の文字が世の中には存在しています。コンピューターは今でこそ高性能になり、世界中のありとあらゆる文字を使えるようにしてしまおうという構想が現実的に実装できるようになっていますが、歴史的にはごく限られたリソースの中で何とかやりくりをしていた時代の方が長いわけです。そうするとその中では「どの文字を使えるようにするか」ということが非常に重要です。 あなたがコンピューターを「限られたリソースの中で」新しく設計するとしたら、どのような文字を使えるようにしたいと思いますか? リソースには限りがあるので、極力少ない文字の種類で済ませたい かといって通常使う用途に不便するようでは使ってもらえないので必要十分な文字の種類は扱えるようにしたい 世の中に存在しているほかのコンピューターとデータをやり取りできないようでは使い物にならないので、他のコンピューターで使える文字はある程度使えるようにしないといけない このくらいのことはまず考えないといけません。このように考えてみるとどのような文字をコンピューターが扱えるべきなのかという規格があり、世の中に存在するコンピューターがみんなその規格にしたがっていればみんなが幸せになれるはずです。 符号化文字集合の具体例 このような符号化文字集合を定めた規格が複数存在しています。ここでは日本語に深いかかわりを持つもので代表的なもののみを紹介します。 ASCII - Wikipedia JIS X 0201 - Wikipedia JIS X 0208 - Wikipedia 補助漢字 - Wikipedia JIS X 0213 - Wikipedia Unicode - Wikipedia Wikipediaの説明を読むといきなり難しいことが沢山書いてあって混乱するかもしれませんが、まずは「色々あるんだな」くらいに考えておいてもらっていいでしょう。私が考えるポイントは以下です。 アルファベット圏ではアルファベットだけあれば事足りるので、それが定義されているASCIIが主に使われている。 日本語はアルファベットだけでは全然たりないので、ひらがな、カタカナに加えて日常よく使う漢字がまず必要。現在のコンピューターで普通に使える漢字はJIS X 0208で定義されている。 最近のコンピューターではさらに多くの漢字が使えるようにしようという動きがあり、最新のコンピューターではJIS X 0213で定義されている文字(JIS X 0208よりも多くの文字が定義されている)が使えるようになってきた。ただしまだ使えないコンピューターも多くあり、互換性に問題がある。 文字符号化集合が複数あるから互換性の問題が起きるのであって、「世界中の文字を集めた符号化文字集合がひとつあって、それを全てのコンピューターが使えば問題はなくなる」という考えで世界中の文字を集めているのがUnicode。普及はそれなりに進んできたが使えない環境もまだある。 文字符号化方式 コンピューター上では最終的には全てが0と1のデジタルで表現されます。もちろん文字もそうです。ですので符号化文字集合だけがあっても実際にそれをコンピューター上ではどのような0,1の並びで表現するのか、ということが決まっていないとコンピューターでは扱えません。その0,1の並びを定義しているのが文字符号化方式です。 符号化文字集合は複数ありますが、そのそれぞれの集合ごとに1つの文字符号化方式がある･･･というわけではありません。実際にはひとつの文字符号化方式で複数の符号化文字集合を対象にしていますし、ひとつの符号化文字集合に対して複数の文字符号化方式が存在しています。 なぜこのように複雑な関係になっているのかというと、結局それは、「同じ問題でも解き方は複数ある」からだと私は思っています。そしてどれが一番良いのかは「何を目的とするか」によっても変わってきます。 たとえば、アルファベットだけで完結することのできる文化圏の人がいます。そして、アルファベットは文字数が少ないので7ビットもあれば全ての文字を表現できてしまいます。コンピューターにとってきりのいいところで8ビットもあれば十分です。一方私たち日本人はひらがなもカタカナも漢字もありますので8ビットではまったく足りません。このときある人は「8ビットで足りないなら、全ての文字を8ビットを2つくっつけて16ビットで1文字にしよう」と考え、あるひとは「8ビットで足りないなら1文字8ビットのルールは変えないで、使う文字集合を切り替える仕組みを作ろう」と考えたとします。(仮に、です。) これはどちらもコンピューターにルールを教えてあげれば(プログラムをつくれば)コンピュータ上で実現できます。どちらが完全に優れているということもありません。一長一短があります。たとえば16ビットで1文字にすれば「切り替え」を意識しなくてよいので文字の検索などが簡単に実装できます。ですが、16ビットで1文字にしてしまうと1文字8ビットで済む文字にも16ビット使ってしまうので、仮にアルファベットしか使わない文章を書いたとしたら容量が2倍になってしまいます。 この例は解説のために簡略化してあくまでも例として出していますが、実際の文字符号化方式においてもこのようにトレードオフがあり、複数の方式が混在しているのです。 文字符号化方式の具体例 文字符号化方式の具体例としては以下のようなものがあります。 ISO-2022-JP - Wikipedia EUC-JP - Wikipedia Shift_JIS - Wikipedia Microsoftコードページ932 - Wikipedia UTF-8 - Wikipedia UTF-16 - Wikipedia UTF-32 - Wikipedia 沢山あっていきなりだと混乱すると思いますが、まずは以下のような理解をしておくと良いと思います。 ...

今回はリクエストをいただいたので「Windows Serverで社内向けイントラネットをお金をかけずに構築したい」というときにどのような選択肢があるのかを考えてみることにします。 まずは目的を明確に 何かをしようと思ったら色々な事を明確にしなければいけません。アクセスするのは誰なのか、顧客なのか、社員なのか、プロジェクトメンバーなのか。そこでは何がなされるのか、情報提供なのか、商品を売りたいのか、共同の作業場所にしたいのか。アクセスはどの程度見込むのか、可用性はどの程度あればいいのか。 そして何よりも重要なのは、そのシステムによって「何を実現するのか、何ができれば成功なのか」という事を明確にすることです。 これによって何を選択するのかは全く変わってきますし、また、おのずと明確になっていくでしょう。 とはいえ選択肢を並べてみましょう とはいえ、今回ここで具体的に何かを作り出すわけではありませんから、具体的にどのような選択肢があるのかを見ていってみましょう。 手動管理 一番原始的な方法です。 Webサーバーを構築する 手動でコンテンツ(HTMLファイル等)を作成、配置する WebサーバーとしてはWindows ServerですからIISを使うもよし。Apacheを使うもよし。その他動けばなんでもかまいません。 そしてそのWebサーバーに対して自分で作成したコンテンツをおいていくわけです。更新する場合にはエディタで開いて中身を更新。静的なファイルですから読むだけ･･･ですね。 私が始めてWebページを作り出した1998年あたりのころは、みんなこうやってWebページを作っていたものでした。手間かかってました。 手動管理+動的ページ 静的なファイルが置かれているだけではあんまりですので、動的なページを使うということもできます。CGI等を用いてPerl、Ruby、Phyton、Java等で書かれたプログラムを動かす形になります。ちょっとひねるパターンとしてはFlaxを使うようなバージョンでしょうか。マイクロソフト的にはIIS+.NETという感じになります。 確かにやればもうこれだけで何でもできてしまいます。ちょっと大規模にやるならデータの保管場所にSQLデータベースでも使ってしまえばやってできないことは何も無い。という形でしょうか。 ただし、このような形で手動で管理するのは手間もかかりますし、間違いも起きます。大規模なWebサイトを作ろうと思ったらこのような手法だけでは限界があります。また、プログラミングスキルが要求されるなど、誰にでもできるようなものではありません。 コンテンツマネジメントシステム(CMS) そこで登場してきて一気に普及したのが、CMSです。昨今のWebシステムと言えばほとんどCMSにカテゴライズされてしまうのではないでしょうか。 CMSはWebシステムを構成する要素を統合的に管理し、HTMLやプログラミングを知らなくてもWeb上のインターフェース(だけとは限らないが)でWebサイトが構築できてしまうものです。 コンテンツマネージメントシステム – Wikipedia 上記のWikipediaを見てもわかりますが、非常に多くの種類があります。汎用的なものからブログなどある程度形の決まったものまであります。これらはインストールさえしてしまえばその後の運用が楽なものが多いです。 Webアプリケーションフレームワークを使った構築 自分で作る、あるいはCMS自体を作る、というときには昨今は強力なWebアプリケーションフレームワークを用いて作る、ということが多いようです。「手動管理+動的ページ」と書いたものをかなり発展させたものです。 Webアプリケーションフレームワーク - Wikipedia お勧め それでは、私のお勧めを書いてみます。 Windows SharePoint Services Windows SharePoint Services テクノロジ ホーム ページ - Microsoft Office Online 正直なところ、機能的にはあまりお勧めではないのですが以下の点でやはりお勧めせざるを得ないかなと思います。 Microsoft純正である 無料である 特に企業内で使うような場合に「上司が何のことやら理解していないOSSのプロダクト」よりも「Microsoftの製品で無料だけれども、それなりのことができるもの」の方が納得感が得られやすいのではないかと思います。 インストールが簡単なのも良い点です。ドキュメントライブラリなどは他の製品よりもはるかに出来がいい(そもそもこういうものを実装しているものがあまりない)ので、それも良い点です。 ただし、繰り返しますが、機能的な面ではお勧めしません。ですが、それも用途しだい。用途を明確にして、マッチするようであれば有力な選択肢の一つになるでしょう。 機能として何を持っているのか、と言う点については以下にまとまっていますので参照してみてください。(※ただし、何でもできるように書かれているので鵜呑みにしないように!) Windows SharePoint Services の概要 ｜ Microsoft TechNet ブログ - Wordpress WordPress | 日本語 目的が「ブログ」で達成できるのであればWordPressは良い選択肢です。あなたが今読んでいるこのブログもWordPressで構築されています。情報発信がメインであるのであればこれを選んでおけば間違いないでしょう。 ブログとしての次点にはMovableTypeをあげておきます。サポートありの商用バージョンもありますし、オープンソースバージョンもあります。 ...

ホスト名、それに対応するIPアドレス。それがどのようにホスト上にキャッシュされるのかについて見てみます。なお、ここではNETBIOS名に関しては言及しません。ホスト名限定の話です。 キャッシュする様子を見てみる まずは単純にホストに対してpingを実行する、というケースに対し、このときの動きをキャッシュを含めてみてみましょう。 まず、キャッシュを確認してみます。コマンドは「ipconfig /displaydns」です。 C : \ D o c u m e n t s a n d S e t t i n g s \ A d m i n i s t r a t o r > i p c o n f i g / d i s p l a y d n s W i n d o w s I P C o n f i g u r a t i o n 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a R e c o r d N a m e . . : 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a . R e c o r d T y p e . . : 1 2 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r P T R R e c o r d . : l o c a l h o s t l o c a l h o s t R e c o r d N a m e . . : l o c a l h o s t R e c o r d T y p e . . : 1 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r A ( H o s t ) R e c o r d . . : 1 2 7 . 0 . 0 . 1 .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /white-space: pre;/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } キャッシュ上にはlocalhostとローカルループバックの逆引きのレコードしか登録されていません。 ...

ディスクイメージを作成し、それをクローニングする作業の中ではよくsysprepが実行されます。ここでは「なんのためにsysprepを実行するのか」「実際には裏で何が行われているのか」といったことを整理してみます。 sysprepは何をしてくれるのか sysprepはそもそも何をしてくれるものなのか、という点に関してはTechNetに記述がありますので、引用します。 Sysprep ユーティリティは下記の 3 つの異なる用途で使用できます。 **ディスクの複製。**Sysprep を使用してディスク複製の準備を行うと、完全にインストールされたシステムを同様のハードウェアにコピーできます。Sysprep によって、ローカル コンピュータのセキュリティ ID (SID) がコンピュータごとに一意になるように変更されます。詳細については、次を参照してください。Sysprep を使用してディスク複製用のイメージを準備する方法 (英語) 監査。 コンピュータの監査を実行した後に Sysprep を使用すると (–nosidgen コマンド ライン オプションを使用)、Sysprep によって、エンド ユーザーが Windows を実行できる準備が整えられます。詳細については、次を参照してください。Sysprep を使用して監査をインストールする方法 (英語) **ミニ セットアップの自動化。**Sysprep では簡易形式の GUI モード セットアップが作成されます。このセットアップでは、通常 45 ～ 60 分かかる処理が 5 ～ 6 分で済み、エンド ユーザーは使用許諾契約書 (EULA) の同意や、プロダクト キーの入力、ユーザー名および会社名の入力など、ユーザー固有の必須情報を入力するだけで済みます。このモードで Sysprep を使用するには、Windows XP をローカル コンピュータにプレインストールした後、–nosidgen パラメータを付けて Sysprep を実行し、次の手順に従います。詳細については、次を参照してください。Sysprep を使用してミニ セットアップを自動化する方法 大きく3つの用途があるということですが簡単に言ってしまえば以下の3つです。 SIDの変更 監査の実行 ミニセットアップの実行 が、はっきりいって2と3は普通行いません。通常はディスクの複製時におけるSIDの変更のためにsysprepが実行されると思っておいて良いでしょう。 具体的な動作ロジックに関してはsysprepではなく類似のSID変更ツールであるNewSIDに詳細に書かれており、sysprepでも同じことが行われていると考えてよいものと私は考えています。 以下NewSID v4.10から引用しました。 NewSID starts by reading the existing computer SID. A computer’s SID is stored in the Registry’s SECURITY hive under SECURITY\SAM\Domains\Account. This key has a value named F and a value named V. The V value is a binary value that has the computer SID embedded within it at the end of its data. NewSID ensures that this SID is in a standard format (3 32-bit subauthorities preceded by three 32-bit authority fields). ...

普段コンピューターを扱っていると、様々な場面で「文字化け」に出会うことがあると思います。文字化けに関しては書くべきことが沢山あるのですが、沢山ありすぎて逆に何から書いて良いのか迷ってしまいます。このブログでも書いていくつもりですが何年かかるか分からないのでまずは書籍を紹介しておきます。 文字コード超研究 深沢 千尋 「文字コード超研究」ではコンピューターが文字を扱う上での原理から様々な文字コード(ASCIIからUnicode、大文字セットまで)などなど多くのことが網羅的に、分かりやすく書かれており、非常にためになります。お勧めです。(私がこのブログに書こうと思っていたこととほぼ同じコンセプトでまとまって書かれていて、やられたと思いました･･･。)

今回はドメイン参加の話をします。ドメインといってもＤＮSの話ではなく、Windowsのドメインの話です。(両者はよく混同されるので気をつけてください) ドメイン参加をすると何が嬉しいのかという事に関してはまた別エントリにして、ここでは、ドメイン参加時の設定の意味や良くあるトラブル等に関しての話をします。 ドメイン名には二種類ある test.localというActive　Directoryのドメインがあったとします。この時、ドメイン参加する際に入力すべきなのは「test」でしょうか、「test.local」でしょうか?この問いに答えるためには2つの違いをしっかりと認識しておく必要があります。 まず「test」ですがこれはNETBIOSドメイン名と呼ばれます。より正確には大文字で「TEST」です。これはNTドメインの時代から使われてきたドメイン名です。NETBIOSの名前ですからNETBIOSの名前解決が必要になります。つまり、ブロードキャスト、lmhosts、WINSをつかってドメインを探すわけです。 一方「test.local」はDNSドメイン名と呼ばれます。こちらはDNSあるいはhostsを使ってドメインを探します。DNSのドメイン名の話ではないと始めにいっておきながらやっぱりそうじゃないか、と思うかもしれませんが、そうではありません。ここが混同しやすいのですが、あくまでも探す目的はWindowsのドメインであり、探す手段としてDNSが利用されているだけです。 「Active Directoryのドメインに参加する際にどちらが適切か」という問いに関しての答えは「test.localの方が良い」という答えになります。何故ならActive Directoryでは全てのコンピュータが適切にDNSを利用して名前解決ができる事が前提になっているからです。「test.local」と入力する事できちんとDNSを使って名前解決が出来る事のテストを兼ねる事ができる訳です。 ここでの最悪の行動は「test.localと入力したらドメインが見つから無かったが、testと入力したらドメインが見つかってドメイン参加出来たからそれで良いことにした」というものです。一見正常に動作するように見えますが後々色々な所で問題が発生してきますので、絶対にやってはいけません。具体的には、Kerberos認証ができなくなるのですが、その影響は特定のwebアプリケーションのさらに一部の機能が使えなかったり、特定のアプリケーションの動きが他の端末に比べて明らかに遅かったりなど、認証方式が原因であるということが非常にわかりづらい形ででてきてしまいます。 逆のパターン(「test」ではドメイン参加できないが、「test.local」ではドメイン参加できる場合)はWINSを使っていない環境では普通に起こりますので問題ありません。ただし、ドメインコントローラーと同じセグメントにいるコンピュータでは「test」で正常にドメイン参加できます。これは同一セグメントであればブロードキャストでの名前解決が成功するからです。これを理解していないと場所によって挙動が異なり混乱してしまいます。さらに同一セグメントであっても条件によってはドメインを見つけられないこともあり(NETBIOS over TCP/IPが無効になっている場合やノードタイプの違いなど)更に混迷を極めます。 「ドメイン参加はDNSドメイン名で」と覚えておきましょう。 ドメイン参加時のアカウント ドメイン参加をする際にはアカウントとパスワードの入力を求められます。これはなぜかというと、ドメイン参加時にはActive Directory上にコンピューターアカウントが作成されるためです。それを行うことのできるActive Directory上のアカウントを指定し、その権限でもって操作を行うわけです。具体的にはコンピューターのローカルのSIDが含まれる文字列を設定し、Active Directory上のオブジェクトと紐付けます。これによってコンピューターがドメイン上のリソースにアクセスできるようになるわけです。 このときには具体的にどのアカウントを指定すればよいのでしょうか?よく誤解されているのですが、ドメインアドミン(Domain Adminsに所属しているユーザー)である必要はありません。ドメインユーザー(Domain Usersに所属しているユーザー)であれば権限は十分なのです(正確にはAuthenticated Usersに対して許可がなされている)。つまり**「ユーザーが勝手に自宅のパソコンを会社に持ってきて、ネットワークに接続し、ドメイン参加させてしまう」ということが既定の状態ではできてしまう**わけです。 逆に言うとドメイン参加の際にわざわざ管理者が作業を行ったり、あるいはドメインアドミンのアカウントのID、パスワードを伝えたりするケースがありますが、そんな必要は無いわけです。特に、クライアントの大量導入の際に作業員にドメイン参加させるためだけにドメインアドミンのID、パスワードを一時的とはいえ伝えているケースがあるかと思いますが、セキュリティの面から考えると大変に危険ですし、かつ本来その必要は無いわけです。(※もちろんその他作業との関連性やお客様との信頼関係、作業員との信頼関係に基づき、ドメインの管理者自体を伝えて作業するケースは考えられると思います。) 企業によっては、ドメイン参加作業はユーザーが自分で行うのが当たり前という運用方針のところもあります。ドメインのユーザーであるということはドメインにコンピューターを参加させる権限がある、ということなわけです。Active Directoryはそのような思想で構築されています。もちろんこの設定は変更することもできます。 しかし、ドメインユーザーを使えばあとは何も問題が無いのかというとそういうわけではありません。既定の状態で10台までしかドメイン参加させることができないという制限があります。これではクライアントの大量導入の場合の作業効率に問題があります。 これに関しては3つの解決策があります。 ドメイン参加を許可する台数の上限を十分に大きな数に設定しておく あらかじめコンピュータアカウントを作成しておき、ドメイン参加させることができるアカウントとしてドメイン参加に使用するユーザーを指定しておく コンピューターアカウントの生成を許可するようにセキュリティ設定を変更する 特に2番目の方法だと、以下のような点で別のメリットもあります。 あらかじめコンピューターアカウントを特定のOUに作成しておくことができGPOの適用もれがなくなる コンピューター名の間違いに気が付くことができる (ドメインユーザーでのドメイン参加を許可させないように設定変更しておくことで)すでに存在しているコンピューター名でしかドメイン参加できない 権限の無いユーザーではドメイン参加できない コンピュータアカウントのできる場所 何も特別な設定を行わずにコンピューターをドメイン参加させると、コンピュータオブジェクトは「Computersコンテナ」に作成されます。特にコンピューターに対して何も特別なポリシーを適用していない、という環境ならこれで問題ないのですが、コンピューターオブジェクトに対してGPOを適用している環境では一度「Computersコンテナ」に作成されたコンピューターオブジェクトを手動で任意のOUに移動させる必要があります。これはGPOはOUに対しては適用できるもののコンテナに対しては適用できないからです。かなり面倒ですね。 全てのコンピューターを一律特定のOUに格納する運用であれば良い方法があります。以下のコマンドでドメイン参加時にコンピューターオブジェクトが作成される場所を変更させることができます。 c:\windows\system32\redirusr container-dn ただしこの方法はActive DirectoryがWindows Server 2003以上のドメイン、フォレスト機能レベルで実行されていなければいけませんので気をつけてください。 全てのコンピューターが同じOUに配置されるわけではない場合にはすでに紹介したようにコンピューターオブジェクトをあらかじめOUに作成しておく方法が良いでしょう。特にこの方法はグローバルな企業で、特定の国の管理者には特定のOUにのみ権限が委任されている場合によく採用されているようです。 認証モード すでに述べましたが、ドメイン参加後にはWindows 2000以上のOSであれば認証モードがKerberos認証に変更されます。運用中に切り分けの難しい問題で悩まないためにもきちんと確認しておくと良いでしょう。確認は以下の場所から行えます。 「マイコンピュータ」→右クリック→プロパティ→「変更」→「詳細」 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」にチェックが入っている状態でドメイン参加し、きちんとActive Directoryであることを認識できると、この部分にきちんとドメインサフィックスが追加され、フルコンピュータ名がFQDNになります。こうなっていればきちんとKerberos認証になっている(=Active Directoryであることを認識できている)ということになります。 WINSが存在する、あるいはドメインコントローラーが同一セグメントに存在する状態で、DNSの設定を誤ったままでNETBIOSのドメイン名を指定してドメイン参加を完了すると、この部分がきちんと更新されません。気をつけましょう。 参考 ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない Windows Server 2003 ドメインの Users および Computers コンテナのリダイレクト

「インターネットに繋がらない」という事象をテーマにして以下2つのエントリを書きました。 「インターネットに繋がらない」 - 初級編 「インターネットに繋がらない」 - Proxy編 今回はVPN編です。 VPN接続の場合にはさらに話が複雑になります。VPN接続の場合には以下の4つのパターンが存在することになります。 VPN接続ではない直接接続しているネットワークを使って直接インターネットに接続 VPN接続ではない直接接続しているネットワーク上のProxyをつかってインターネットに接続 VPN接続先のネットワークを使って直接インターネットに接続 VPN接続先のネットワーク上のProxyを使ってインターネットに接続 Proxyの設定をしていないときに1の経路になるのか、3の経路になるのかは、VPNの設定上でコントロールをします。 ここの「リモートネットワークでデフォルトゲートウェイを使う」というチェックボックスがまず1つ目のポイントです。 チェックが入っていなければ直接接続されているネットワークから別ネットワークにアクセスする(パターン1) チェックが入っていればVPN接続先のネットワークから別ネットワークにアクセスする(パターン3) もちろんどちらの場合にも「初級編」で解説した内容が当てはまりますが、1点注意点として、VPN接続時の参照DNSはVPN接続先のDNS設定よりも直接接続されているネットワーク上の設定が優先されるようです。(手元のWindowsXP SP3で確認) 次に、IEの中に「ダイアルアップと仮想プライベートネットワークの設定」という項目があります。 この中に「プロキシサーバー」の設定があります。ここが2つ目のポイントです。VPN接続先のProxyサーバーを使うにはここの部分にProxyの設定を入力する必要があります。ここに設定がなされていればパターン4になるわけです。 直接インターネット接続に出る経路とVPN経由の経路とであまりスピードが変わらないような場合には問題にならないかもしれませんが、特にダイアルアップ接続など帯域が細い経路が存在している場合には、きちんと帯域の太い経路からインターネットアクセスを行わせるように構成することが重要ですね。

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、Proxyを経由してインターネット上のWebサイトを閲覧するようなケースを考えてみます。 一般家庭でProxyを利用しているようなケースは極稀でしょうけれども、企業では様々な理由からProxyを利用しないとWebサイトの閲覧ができないように構成していることもあります。特にセキュリティに気を使っている企業ではProxyの利用は当たり前です。あとは、サイトを閲覧する際に実IPを隠すためにあえてProxyを利用するようなケースもあるかとは思いますが今回はそのあたりに関しては扱いません。例の如く別エントリにて解説予定です…。 Proxy接続の場合には通常の直接インターネットへ接続(Webサイトの閲覧)をする場合と比較すると以下のようなプロセスの違いがあります。 直接 Proxy経由 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 5．DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 6．該当のWeb Serverに接続する 7．Web Serverからコンテンツを得る 8．ブラウザにコンテンツを表示する 5．Proxyサーバーに接続する 6．Proxyサーバーからコンテンツを得る 7．ブラウザにコンテンツを表示する 大きな違いは以下の2点です。 DNSを使用した”名前解決”を実行しない(必要ない) 接続するのは常にProxyサーバー Proxyサーバーを利用する場合には、Proxyサーバーに実際のコンテンツの取得をお願いする形になります。つまりProxyサーバーは「直接」の場合の5,6,7の動作を行い、その結果をPCに渡してくれるわけです。 トラブルシュートの方法 トラブルシュートとしては、Proxyサーバーの設定およびProxyサーバーへの接続があります。 Internet Explorerの場合には「ツール」→「インターネットオプション」→「接続」タブ→「LANの設定」からProxyの設定を行います。 Proxyへの接続がきちんとできているかを確かめるには、「telnet Proxyサーバー ポート番号」を実行するとよいでしょう。コマンドを実行して、画面が真っ暗になれば接続できています。 「ローカルアドレスにはプロキシサーバーを使用しない」の意味 Proxy環境の場合によく問題になるのは「ローカルアドレス」という言葉の意味です。普通に「ローカルアドレス」と聞くと同一セグメントのIPアドレスなり、プライベートアドレスなりといったものを連想すると思いますが、これはそういう意味ではなくて「名前に.(ドット)が含まれていないもの」という意味になっています。通常WindowsネットワークではPC名のみで近くのサーバーへの接続(名前解決)ができるため、このような判断基準になっているのだろうと思います。 具体例をあげましょう。Proxyサーバーを利用し、かつ「ローカルアドレスにはプロキシサーバーを使用しない」のチェックが入っているとします。 pcname(ホスト名) pcname.test.local(FQDN) 192.168.1.1 上記の3つが全く同じホストを指している場合、1はホストに対して直接のアクセス、2と3はProxyサーバー経由のアクセスということになります。単純に.(ドット)が含まれているかどうかが判断基準です。 よく2や3の場合でも同じサブネットなんだからProxyサーバー経由ではなく直接接続してくれると勘違いしてしまうケースがあるので、きをつけてください。 2や3の入力方法でも直接接続させたい場合には除外設定を行えばよいです。 そもそもProxy接続をしなければいけないことをどのように知るのか Proxy接続が必要な環境であること自体を知る、あるいは直接接続はできないと判断するにはどうすればいいでしょうか。これはDNSの確認とHTTPポートでの接続の可否で判断できます。 外部のホスト名の名前解決ができるか まず、DNSに関して。DHCPなり固定IPなりできちんとしたDNSを割り振られていることを前提とします。この状態でnslookupにて外部ホストの名前解決ができるかどうかを確認します。 上記のように名前解決ができるようであれば、自らWebサイトへの接続が試行できるので、Proxyは必要ない環境の可能性が高いです。逆にここで名前解決ができないようであればProxyが必須の環境であるということがわかります。あるいは完全にインターネット上のホストへのアクセスができないか、です。 外部のホストに接続できるか 名前解決ができる環境であれば直接Webサイトへの試行を行うことができます。Webサーバーへの接続はtelnetでHTTPポートへの接続で試すことができます。 名前解決ができても外部ホストに接続できない場合や逆に名前解決ができなくても外部ホストに接続ができる場合などもあり得ます。ですが基本的には両方うまくいかなければProxy接続が必要な環境だ、ということがいえます。 Proxyの設定に関する注意点 ちなみにWindows上のアプリケーションの場合にはインターネットアクセスの際にIEのProxyの設定を参照するものも結構あるので注意が必要です。特に規定のブラウザをIE以外のブラウザに変更しているときには注意が必要です。IEのProxy設定にも設定を入れておきましょう。 また、サービスで動作しているプロセスがProxy設定を必要とするケースがあります。この場合には該当アカウントのプロファイル上でIEのProxy設定を行う必要があるものもあるので注意が必要です。 さらに、IEのProxyを見ないでWinHTTPの設定を見るアプリケーションもあります。さらにはIEでアクセスするくせにWinHTTPの設定を見るようなものも存在していますので(Microsoft Update等)、proxycfgコマンドでの設定が必要なケースもあります。このあたりには注意が必要です。 参考：How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site ...

今回はクライアント端末への雛形展開作業の話をしたいと思います。雛形作成作業自体に関してはまた別のエントリで書く予定です。 私が思う雛形展開作業の理想系は以下のようなものです。 PCを箱から出す ネットワークケーブルとACアダプタをさす 電源を入れると自動的にネットワークブートする(ネットワークブートをさせるためには機種によってはキー操作が必須なものもあるでしょう) 自動的に配信サーバーに接続される 必要な台数接続されるまで1~4を繰り返す 接続された全ての端末に対して配信サーバーからイメージが配信される 必要な処理が自動でなされる(SIDの書き換え等) 必要ならばOS起動後、必要な処理が自動でなされる 必要最小限の入力項目が聞かれ、設定が完了する 終了 こうやって書くとちょっと抽象的過ぎるかもしれませんね。ひとつづつ具体的に見ていきます。 「1.PCを箱から出す」 ここに関しては特に何もありません。単純に出すだけです。取り出しやすい箱が嬉しいところですね。 「2.ネットワークケーブルとACアダプタをさす」「3.電源を入れると自動的にネットワークブートする」 ここに関してのポイントは「ネットワークケーブル」と「ACアダプタ」の2つだけでよいということです。雛形を展開する際に使うツールにもよりますが、通常は雛形のイメージを落とし込むために、専用の環境を立ち上げます。たとえばSymantec GhostであればDos+ghost.exeだったりするように。その際に専用の環境はFDD、CD/DVD、HDD、USBメモリなどさまざまな場所に格納、起動可能ではありますが、いちいちメディアを抜き差しするのも面倒なので、ネットワークブートが一番簡単だと思います。メディアをなくしたりすることもありませんしね。 「4.自動的に配信サーバーに接続される」 ここでのポイントは「自動的に」というところです。雛形を落とし込むための専用の環境が立ち上がったあとで、たとえば配信サーバーのIPを入力したり、セッションIDを入力したりする作業が発生するのが普通ですが、大量に展開するようなケースでは全ての端末で全く同じ操作を行うことになることが大半です。であれば、はじめからこの部分を自動化しておくと省力化になります。 「5.必要な台数接続されるまで1~4を繰り返す」「6.接続された全ての端末に対して配信サーバーからイメージが配信される」 ここでのポイントは、全ての端末に一度にイメージを配信する、ということです。つまりブロードキャストやマルチキャストを使って、一斉配信をするわけです。こうすることによって同時に配信する端末の数がいくら多くなろうとも全く同じ速度でイメージ配信作業を完了させることができます。 この部分に関してはたとえばCDやDVDを使って1台つづイメージを落とし込む方法など他にもバリエーションが考えられますが、昨今の大容量HDDをつんである程度のボリュームのあるイメージを展開する場合にはメディアの枚数がふえがちになってしまい、入れ替え作業を何度も何度もやらなくてはいけなかったりしてしまいますし、メディアを消費するので環境にもやさしくない気がします。なので、個人的にはネットワークでの一斉配信が理想だと思っています。 「7.必要な処理が自動でなされる(SIDの書き換え等)」「8.必要ならばOS起動後、必要な処理が自動でなされる」「9.必要最小限の入力項目が聞かれ、設定が完了する」 ここでのポイントもやはり自動化です。Windows OSであれば必須なのはSIDの書き換えですが、この作業はやったかやってないかの見分けがかなり難しい(めんどくさい)こともあり、必ず自動的に処理される、という状況を作り出すのがよいと思います。具体的にはSymantec Ghostであれば雛形展開後にGhost Walkerが自動的に動作するようにする･･･とか、Sysprep適用済みのイメージをマスタイメージとし、初回起動時に必ずSIDが書き換わる･･･という状況を作るのがよいと思います。 その他、OSが起動しなければできない設定等もありますので、そのあたりはOSが起動してからになるのが普通でしょう。OSの起動すらせずに全ての必要な設定が完了するならばそのほうがいいとは思いますが、現実的にはかなり難しいのではないかと思います。ここでの代表的な設定はホスト名の設定等でしょうか。このあたりに関しても対してステップ数のない作業であれば手動で行ってもいいかもしれませんが、ある程度の分量があるようであれば、必要最小限の入力のみ行い、あとは自動で設定されるような仕組みを作成し、マスターイメージに盛り込んでおき、初回起動時に実行されるようにしておくといいでしょう。 と、今回はここで終わってしまうのですが、「ちょっとまて、具体的にはどうやってやればいいんだ」と言われてしまいそうですね。具体的な方法に関しては別エントリでそのうち書いていこうと思いますので、気長にお待ちください･･･。(いつもこればかりですね･･･すいません･･･。)

「インターネットに繋がらない！」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと････。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0｣というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考：APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...

今回の話題はOSのインストール先に関してです。 OSは普通HDDにインストールします。あまりにも当たり前すぎて疑問に思わない人も多いかもしれませんが、たとえばOSをインストールするときにはCDやDVDから起動しますよね。つまりCDやDVDにOSが入っていて、そこから起動するということは技術的に可能なわけです。で、あれば、CD、DVDにOSを入れておいてその状態で使用することもできるのではないでしょうか? CD,DVDにOSを入れておいて、そこから起動して使う、この状態で利用することに何か問題があるでしょうか。ちょっと考えてみます。 CD,DVDを入れるだけでOSが起動するならインストール作業がいらない→お手軽 CD,DVDを入れ替えるだけでOSや構成を簡単に変更できる、まるでゲーム機のような仕組みが出来上がる→便利 間違えてデータを消してしまうようなことがない、再起動すれば必ず同じ状態になる→堅牢 ということで、とてもよいシステムのように思えます。予想される反論に関しても答えてみましょう。 アプリケーションが追加できないのではないか?→CD,DVDから起動した後でHDDをマウントして利用するようにすればアプリケーションのインストールも可能でしょう。 設定を残しておけないのではないか?→これも上記と同じようにHDDなりUSBなり、書き込み可能なデバイスに設定を残しておけばよいでしょう。ゲーム機のメモリーカードと一緒ですね。 OSに問題があったらどうするのか?→CD,DVDを新しいバージョンにさしかえれば良いでしょう。 どうでしょうか。ここまでに出てきた要素だけでは、HDDにOSを入れる必然性は説明できていないように思えます。もっと視野を広げるならばたとえば以下のものにOSが入っていても良いのではないでしょうか?(このリストは簡単にいくらでも増やしていけるのですが) USBメモリ フラッシュメモリ FD ネットワーク上のデバイス テープデバイス SAN上のストレージ どうでしょう。これらのものに置き換えても話は同じですよね?実際のところ、上記のものにOSを配置して実際に利用されている、されていたシステムは実在しています。OSはHDDに入っていなくてはいけないなんていうルールは存在しません。OSだってただのデジタルデータですからどこにどんな形で保管されていようと本質的には関係ないのです。 では、なぜOSは当たり前のようにHDDに保存され、そこから起動されているのでしょうか?それは”今現在HDDが一番早くて容量が大きくて手軽に利用できるから”です。ただそれだけです。スピードも速いし、容量も大きいし、書いたり消したりできるし、電源を切ってもデータがなくならないのです。このように都合がいいのでHDDを使っているわけです。これとまったく同じ理由で過去にはOSはFDに入っていて、OSを起動させるにはFDを入れてそこから起動していた時代もありました。そのときにはHDDは存在していない、あるいは、高すぎて普及していない時代だったわけです。 もしも超高速なネットワークが全世界の末端まで普及するならば、OS自体はネットワーク上に存在することになるでしょうし、CPUの1次キャッシュが超大容量になって電源を切ってもデータが消えないようになったならば、OSはCPうの1次キャッシュ内に存在することになるでしょう。(どちらもありえない仮定ではありますが) 具体例 余談ではありますが、HDDが一番適しているとはいっても他のデバイスにだってOSは入れられるわけです。そして世の中には実際にそのようなものが存在しています。デメリットはあるでしょうが、それを承知の上で、それぞれの人の利用状況によってはHDD以外のものにOSを入れておいたほうが良いケースもあるわけです。 以下、HDD以外の場所から起動するものの具体例へのリンクです。「こういうものもあるよ」という例なので、あまりまじめに探していませんが、なかなか面白そうなリンクが沢山ありますよね!HDDをまったく使わないものも面白いですが、HDDには普通にOSをインストールしているときに、HDD以外からブートさせることでさらに面白いことができたりすることが多々あります。このブログでも後日この当たりに関してはさらに詳しく話をしたいと思います。 KNOPPIX - Wikipedia USBブート推進協議会 「BOOT革命/USB Ver.3」、外付けHDDにOSを直接インストールできる機能追加 USBメモリーでWindowsを起動！？ 「BOOT革命/USB Memory Ver.1」 - デジタル - 日経トレンディネット BOOT革命/USB Ver.3 Std PXEを使ったネットワークブート ＠IT：PXEネットワークブート用サーバを構築するには Windows PE 2.0 for Windows Vista の概要 管理者必携！ 最強のデータ・サルベージ・ツールを自作する － ＠IT

この層はイメージすることが難しいネットワークの層の中では比較的イメージしやすい層かもしれません。なぜなら目に見える(ものもある)ので。具体的には以下のようなものがレイヤー1に対応するものとして存在しています。 ネットワークケーブル リピータハブ モデム 一番具体的にイメージしやすいのはネットワークケーブルだと思います。ネットワークケーブルを使ってコンピューターとコンピューター(や、HUBなど)を接続すると、情報がやり取りできるようになります。Windowsでいえばファイルもコピーできますし、きちんと構成してあげればInternet経由で世界中のサーバーからWebページ、音楽、動画なども取得することができます。 このとき、ネットワークケーブルの中では何が起きているのでしょうか?色々なものが通るのだからものすごく複雑なものが、得体のしれないものが通っているのでしょうか? 実は非常に複雑･･･ではなく、ものすごくシンプルです。基本的に電気信号が通るだけです。しかも電圧が高い、電圧が低いの2パターンしかありません。2パターンしかないのだから、言ってしまえば人間が手で旗を上げている、下げている、ということと同じことしかやっていません。 2パターンしかないのに、PCで使える全てのもの(文字、画像、音声、動画、プログラム、その他なんでも)を全て伝えられるのは何でだろう?と思うかもしれませんが、それこそが「デジタル」のすばらしいところです。この部分に関して突っ込んでいくと今回のエントリの目的からどんどん離れていってしまいますので、そこにかんしては後日別エントリでまとめたいと思います。 さて、本題に戻ります。ネットワークケーブルはただ単に電気信号を通しているだけ、という話でした。リピータハブに関しても同じです。リピータハブは入力があった電気信号を他のすべてのポートに対して電気信号として流す、ということをやっているだけです。モデムは電気信号を電話回線に対して「ガガガ」と音声に変換して流したり、その逆をしたりしているだけです。 つまりレイヤー1に属するものたちは何も考えずに電気信号なり、音声なりを流す、あるいは変換して流す、というただそれだけだということです。そしてその信号を「デジタル信号」として上位の層(レイヤー2)に渡します。 OSI参照モデルを思い出してほしいのですが、OSI参照モデルではそれぞれの層が独立しているのがポイントです。一昔前までは物理層として物理的なケーブルしかありませんでしたが、今は無線LANのように電波をつかって通信するものがあります。ですが、有線だろうが無線だろうがきちんとTCP/IPで通信できるわけです。新しいテクノロジが出てきても関連する層でのみ対応を行えばよく、他の層は何も気にしなくてもよいのがポイントです。 参考 詳細編 実際のWebアクセスをレイヤーで見てみよう：ITpro

Windowsサーバーのインストールがとりあえず完了したら、次に行うことはネットワークの設定でしょう。ということで、今回からネットワーク(の入門)のお話がしばらく続く予定です。 ネットワークの説明をする際にはまずOSI参照モデルのお話が出てくるのがお約束です。OSI参照モデルとTCP/IPとの対応等については以下のあたりを確認してみてください。 OSI参照モデル - Wikipedia TCP/IP と OSI 参照モデル 第10回 OSI基本参照モデル――7階層による道案内で，データを迷わせない：ITpro TCP/IPとOSI参照モデル とりあえず4つだけリンクを張りましたが、「OSI参照モデル TCP/IP」とかそのあたりのキーワードで検索をすると、嫌というほど沢山ヒットすると思います。ネットワーク技術に関してはきちんとまとまった資料が書籍にしても、Webサイトにしても多数公開されているのが非常によい点だと思います。 閑話休題。とりあえずいくつかのページを見ながら以下のことに取り組んでみてください。 OSI参照モデルの7層のそれぞれの分割のされ方、役割の理解 OSI参照モデルと対比してTCP/IPの実装がどのように分割されているかの理解 いくつか解釈があるようですが、私なりの理解としては以下のようになります。 レイヤ1：物理層 物理的な接続。電気信号など。 レイヤ2：データリンク層 直接通信可能な機器同士の信号のやりとり。 レイヤ3：ネットワーク層 通信の経路選択、データ中継。複数の機器をまたいだ情報のやり取り。 レイヤ4：トランスポート層 通信の交通整理。エラー訂正、再送信、順序入れ替え等。 レイヤ5：セッション層 プログラム上での、通信の開始から終了までの手順。 レイヤ6：プレゼンテーション層 データの表現方法。 レイヤ7：アプリケーション層 具体的な通信サービス。 TCP/IPはOSI参照モデルのレイヤ3とレイヤ4に対応していて、レイヤ3がIPに、レイヤ4がTCPとUDPに対応しています。 いきなりこれだけのことを出されてもよく理解できないと思いますが、一番重要なことは「階層構造になっている」ということです。つまり、それぞれのレイヤに関しては「別のものに交換可能」ですし、「他の層のことは考えなくてもよい、それぞれの層どうしで話ができる」ということです。 たとえば、レイヤ1に関しては物理的な接続、電気信号の話です。どんなアプリケーションだろうとだれ宛のどんなデータだろうと、「電気信号」として伝えるだけでいいわけです。 たとえばレイヤ7に関しては具体的な通信サービスですので、それが具体的にどのような手段で相手に伝わっているかということは気にせず、「伝わること」を前提としておけるのです。 ・・・・ちょっと難しく、イメージが沸きづらいと思います。今後それぞれのレイヤーの具体例をあげながら話をしていこうと思うので、一通りその内容をみてからここを見直すとすっきりできると思います。

今回は、クライアントアクセスライセンス(CAL)に関しての話です。Windows Server 2003であれば以下のようにインストール時に聞かれます。 このようにサーバー側の設定としては「同時使用ユーザー数モード」と「接続デバイスまたは接続ユーザー数モード」の2種類があります。料金や利用形態によって色々と複雑なことがあるのですが、まずはサーバー側のモードは2種類しかないということをしっかりと認識してください。 「同時使用ユーザー数モード」は「サーバーにCALを持たせるモード」。 「接続デバイスまたは接続ユーザー数モード」は「サーバーにCALを持たせないモード(そのかわりにクライアント側にCALを持たせる)モード」。 です。CALをサーバーが持つ、持たない、ということで2つあるわけですね。 そしてもうひとつ重要なルールとして「同時使用ユーザー数モードから接続デバイスまたは接続ユーザー数モードへの変更が1度だけできる。逆は不可能。」というものがあります。付け加えておくと、「同時使用ユーザー数モードでのライセンス数の変更は後からでも可能」です。 とりあえずの方針 ここまでの話から導き出されるのは以下の方針です。 「**よく分からなければ同時使用ユーザー数モードにしておけば後で正しい設定に変更可能。**とりあえず同時使用ユーザー数モードにしておいて、後ではっきりしてから設定変更すればいい。」 何だその方針は?と思われるかもしれませんが、このCALの話は非常に難しい話なので、よく間違いがあったりします。「接続デバイスまたは接続ユーザー数モード」でセットアップしたのに、実は本当は「同時使用ユーザー数モード」にしなければいけなかったということが後から分かった場合にはOSを1から再インストールする以外ありません。これはショックとダメージが大きいですよ。 そうならないための、この方針なわけです。 実際の現場ではここまで理解できていれば問題ないことが多いです。あくまでもお客さんのCALの買い方の話なので、よくお客さんから話を聞いて設定すればよいでしょう。 ここまでを理解できたら、CALの選択方針の理解に進みましょう。 CALの理解 CALはWindows Serverにアクセスする際に必要です。いくつか例外がありますが、ここではまずは基本から行きましょう。CALを持たせることができる場所(CALの買い方)は以下の3つです。 Windows Server 接続デバイス(Windows Client、PDAなど) 接続ユーザー 1は「同時に使用するユーザー」であるのがポイントです。接続デバイスや接続ユーザーするがどれだけ多くても(たとえ1万でも10万でも)同時にアクセスするユーザー数が5人なのなら、Serverに5CALを持たせておけばよいのです。特にサーバーの数が少ないような環境で有効な買い方です。この買い方ではサーバーが複数あれば、それぞれにCALを買わなければいけないことに注意してください。 2は接続デバイスにCALを持たせて、そのデバイスからはどのWindows ServerにアクセスしてもOKとするCALの持たせ方です。たとえば、Serverが何十台あっても、ユーザーが何百人いても、接続デバイスの数が限られているならば(そしてそれを共有するならば)、そのデバイス数だけのCALを購入すればよい、という買い方です。サーバーやユーザー数がある程度多く、接続デバイスを共有しているような環境で有効な買い方です。 3は接続ユーザーにCALを持たせて、そのユーザーがどの端末からどのサーバーにアクセスしても問題なくする、というCALの持たせ方です。サーバーが何台あっても、端末が何台あっても、ユーザーの数だけCALを購入しておけばよい、という買い方です。特に、ユーザー1人あたり、複数台の端末(デスクトップPCと、ノートPCと、PDAと･･･)を使っているような場合に有効な買い方です。 特に、小規模なユーザーでは1のWindows ServerにCALを持たせる買い方が多く、中規模から大規模になってくると、サーバーにはCALを持たせなくなってきます。その際に2と3のどちらに移行するのかというと、そこはユーザーによって違って、ユーザー数と端末数のどちらの方が数が多いかによって変わってきます。 ・・・・。うーん。今回はかなり分かりづらいですね。以下の参考サイトもあわせて読んでみて下さい。 参考サイト Windows Server 2003 R2 のクライアント アクセス ライセンスの概要 Windows Server 2003 - 知って得する Windows Server ライセンス購入情報

今回の話題はパーティションの分割方法に関してです。インストールの際に出てくる以下の画面のお話です。 今回の話題は特にクライアントPCでHDDが1つしか搭載されていないものに関して当てはまる話です。企業のクライアントPCでもまだまだこのようなケースは多いかと思います。 (※注意)サーバーに関しては昨今はかなり仮想化が進んでおり、RAIDシステムはもとよりSAN環境も当たり前ですし、その上でさらにHW,SWを絡めた仮想化がなされていることが多く今回の話はあまり当てはまりません。この辺りに関しては別エントリで解説予定です。 分割のメリット パーティションを分割することのメリットには主に以下のようなものがあります。 システムとデータの分離 システム復旧(OS再インストール、イメージ流し込み)の際に、データをそのまま保持できる。 システムイメージのバックアップおよびイメージ取得時の容量を小さく、時間を短くできる。 データが肥大化する際に(特に自動的に生成されるログ等)その影響をシステムに与えないようにできる。 どちらかのパーティションが不整合な状態になった際に、別のパーティションへ影響を与えない可能性がある。 別システムとの共存 1つのDisk内に複数のOSを導入したい場合にはパーティションを区切る方が管理が容易になる。複数のOSで異なるファイルシステムを利用する場合にはパーティションの分割が必須となる。 フラグメントへの影響 ファイルを頻繁に書き換え無いパーティション(具体的にはシステムパーティション)と頻繁に書き換えるパーティションを分割しておくことにより、ファイルのフラグメントの影響がシステムパーティションに波及しづらくすることができる。 分割のデメリット パーティションを分割することのデメリットとしては主に以下のようなものがあります。 HDD容量の有効活用 複数のパーティションに分割することで、空き容量が分割され、それによってHDD容量を最大限に利用できない。(特にHDD容量が不足しがちな環境で) 意図に反するデータ配置 特定のドライブレター(特にC)でないとうまく動作しないようなソフトウェアが存在した場合にルールが崩れる可能性がある。 容量見積もりが困難 Windows Update,復元ポイント等でシステムが肥大化する、またその容量を完全に見積もることができない。 エンドユーザーの知識レベルによる影響 パーティション分割の意味を理解していないエンドユーザーがメリットを享受できず、逆に不利益となるケースがある。 構成変更が困難 万が一容量見積もりに失敗し、特定のパーティションの空き容量が不足してしまったが、Disk全体としては空き容量が余っている、というような場合に、パーティションサイズの変更が非常に困難。専用のソフトウェアを購入したりする必要がある。 その他のトピック FATからNTFSにファイルシステムが変化したことによる影響 1パーティションの最大値の制限があり、パーティションを分割せざるを得ないケースがあったが、NTFSではそれがなくなった。 パーティションを分割しないと、小さなファイルを多数保管する際の効率が良くないという問題があったが、NTFSでは改善された。 余談 私自身は、自分が個人的に使っているPCでは昔はパーティション分割を当たり前に行っていましたが、最近はパーティションの分割は行わなくなりました。私の場合にはすぐに容量を使い切ってしまうので「空き容量の確保」という点が一番のポイントですが、パーティションを分割して云々するよりも、Diskが安くなってきたからDisk自体を別のものにしてしまえばよい、というのも大きかったりします。 仕事上では以前、以下のような仕組みを提案、実装したことがあります。(HDDは1つだけ搭載しているPCでした。) パーティションは2つに分ける。(システム用とデータ用) Cドライブにはシステム関連ファイルのみを配置する。 データはすべてDドライブに配置する。 ユーザーのプロファイルデータもDドライブに配置する(参考：[HOW TO] ユーザー プロファイルとプログラム設定のデフォルトの場所を変更する方法) システムパーティションの内容はGhostを使用してイメージ化。 もしもシステム的に不具合が起きればCDまたはファイルサーバー上のイメージからシステムパーティションのみ自動リストア このようにしておけば、もしもシステムが不安定になったりしても、システム復旧用のCDを1枚渡して、「これを入れてPCを起動して」と言っておけばOSとしてはクリーンな状態に戻ります。これを実際に適用しているお客さんではかなり快適に運用できているそうです。 ただ、これを実装するに当たっては1つ大きな問題がありました。 特定ベンダが作成したカスタムアプリケーションが、該当PCでは正常に動作しない というものです。Dドライブにプロファイルを変更している所が原因だろうとあたりをつけて、プロファイルの場所をCドライブだと決め打ちしている場所がないかどうか確認したのですが、「それはない」という回答でした。ですので、このときはかなり困ってしまった…というのが正直なところでした。 この際は、暫定的な回避策として「Cドライブにプロファイルの残っているAdministratorアカウント(このアカウントなら実行できた)として実行させるランチャーをラッパーとして使ってもらう」という方法でしばらく逃げました。 ですが、後から原因が判明したところでは、やはりプログラム内でユーザープロファイルの場所をCドライブだと決め打ちしているところがあったそうです・・・。（＾＾； このようなことがありましたよ、ということで参考にしてもらえればと思います。

今回はファイルシステムの選択に関しての話です。インストールの最中に以下のように聞かれます。 NTFSかFATか NTFSかFATか、という選択に関しては**迷うことなく「NTFS」**を選択すれば間違いありません。その理由としては「NTFSの方があらゆる面で高機能だから」ということになります。具体的に機能の比較表を見てみましょう。以下の評価Webサイトのあちこちから情報を拾ってきてつくった表です。(参考：ファイル システム) 全ての面でNTFSが優れていて、FATを積極的に選ぶ理由がないことが理解してもらえると思います。その中でも特に重要なのは以下のあたりだと思います。 最大ファイルサイズ FAT16, 32の4GBというのは今となっては小さすぎます。特にサーバーシステムでDBを利用するようなものに関しては1ファイルのサイズは4GBどころではなく、10GB、100GBなどというサイズも当たり前にあり得ます。 最大パーティションサイズ こちらもFAT16, FAT32では4GB、2TBとなっており今となっては小さすぎます。 ローカルセキュリティ機能の組み込み これはつまりファイルやフォルダに対してアクセス権を設定できるということです。具体的にはファイルやフォルダのプロパティを開いたときの「セキュリティ」タブの有無ですね。昨今のシステムでセキュリティ設定ができないなんてありえませんので、これは非常に重要なことです。 ちなみにこれはファイルシステムとしてのセキュリティ機能であり、共有フォルダのアクセス権とは別ですので、混同しないようにしましょう。 ローカル暗号化機能の組み込み これはつまりEFSが使えるかどうかということです。「内容を暗号化してデータをセキュリティで保護する」にチェックを入れると暗号化できます。この設定を行わないと、物理的にPCにアクセスできれば事実上セキュリティ設定なんて意味がありませんので(詳細は別エントリで解説予定)、これも非常に重要な機能です。 FATをあえて選ぶのはどのような時か? FATよりもNTFSの方があらゆる面で優れているということは理解してもらえたと思いますが、ではファイルシステムとしてFATを選択するケースというのは存在しないのでしょうか?存在しないのならそもそも選択肢として用意されている意味がないのでは? もちろんFATを選択することになるケースも存在します。それはたとえば以下のようなケースです。 FATは扱えるがNTFSは扱えないOSからアクセスされる可能性があるとき。 デュアルブート環境 ブートディスクからの起動時 リムーバブルメディア 等 最近ですとLinuxからもNTFSの読み書きも行えますが、少し前は読むことはできても書くことはできないという状況がありました。WindowsとLinuxのデュアルブートにしつつ、データの受け渡し用のパーティションはあえてFATを選択するということを私自身していたことがあります。 他にもあえてFATを選ぶケースがありそうですが、ちょっと私には思いつきませんでした、そのくらいFATを選ぶケースというのは現状では稀だと思います。

Windowsには様々なバージョン、エディションが存在しています。今回はWindowsのエディションの違いについての話です。 今となっては少々古い話ですが、Windows 9x系とWindows NT系という2つの大きな流れがありました。これはカーネルの種類のお話です。Windows 9ｘ系とWindows NT系の違いに関しては以下のあたりを参照してみてください。 Windows 9x系 - Wikipedia Windows NT系 - Wikipedia 今となっては市場に出回っているものはほぼすべてNT系になりました。以下はこれとは別の「製品のエディションの違い」のお話です。 クライアントOSのエディションの違いと重要なポイント WindowsのクライアントOSとして市場に現在出回っているのは主に以下の3つだと思います。最近はさすがにWindows 2000は少なくなりましたが、まだ存在はしています。Windows 9x系のクライアントはもうほぼ使われていないだろうと思います。 Windows 2000 Windows XP Windows Vista そして、これらのOSの中でも複数のエディションがあります。 Windows 2000 Windows 2000 Professional Windows XP Windows XP Home Edition(ドメイン参加不可能) Windows XP Professional Windows XP 64-Bit Edition Windows Vista(参考：エディションの比較) Windows Vista Home Basic(ドメイン参加不可能) Windows Vista Home Premium(ドメイン参加不可能) Windows Vista Business Windows Vista Ultimate Windows Vista Enterprise バージョンを重ねるごとにエディションが増えていき、Windows Vistaでは5つものエディションに分かれていて、はっきりいって違いを理解するのも大変ですね。詳細はリンク先を見てもらうとして、誤解を恐れずに私の考えるWindows Server管理者として一番重要なことを言うと、それは「ドメイン参加可能かどうか」という事です。 ホームユーザーが自宅で使うならともかく、企業でWindowsクライアントを使うとなれば「きちんと管理できる」ということがとても重要です。そしてそのためには「ドメイン参加」ができなくてはいけないのです。 「ドメイン参加」とは何なのか、それによって何ができるようになるのか、ということに関しては別途解説予定です。 サーバーOSのエディションの違いと重要なポイント WindowsのサーバーOSとして市場に現在出回っているのは主に以下の4つです。流石にもうWindows NT Serverはあまりないと思うので省きました。Windows 2000 Serverだけ、Serverと文字の場所が違いますが、誤植ではありません。 ...

Windows上でフォルダをコピーする、移動するというのは日常的によく行う動作ですが、実はコピー&ペーストとカット&ペーストでは結果が異なるということを知っていましたでしょうか? - コピー&ペースト → ペースト先のアクセス権を上位フォルダから継承 - カット&ペースト(同一ドライブ上) → ペースト先のアクセス権には依存せず(上位からの継承は無効にした状態で)、カットした元のNTFSアクセス権が設定される。 - カット&ペースト(別ドライブへ) → ペースト先のアクセス権を上位フォルダから継承 実はこのようにコピー&ペーストとカット&ペーストは動きが明確に異なるし、別ドライブへのカット&ペーストでも動きが異なるのです。面白いですね。 おそらく、コピーというのは結局元のファイルとは別のものを「新規作成」することになるのだと思います。で、「新規作成」されたファイル、フォルダは上位のNTFSアクセス権を継承するのが規定の動作であるため、コピー&ペーストの時には継承になるのだと思います。 一方カット&ペーストの場合には別のものを新規作成するわけではなく、既存のファイル、フォルダの位置情報だけを書き換えるのではないかと思います。で、その際にNTFSアクセス権をどうするか･･･というところで、「継承を切って、今のアクセス権をそのまま」という動きをするようにロジックが組まれているのだと思います。(おそらく。) さらにカット&ペーストでもドライブをまたぐ場合には完全に新しく作成して、元のものを消す、という操作が必要なので、コピー&ペーストと同じ結果になるものと思われます。(おそらく。) 個人的にはカット&ペーストの時だって、上位のフォルダのアクセス権を継承したっていいじゃないか、と思わないでもないのですが、そうなっていないということは継承であっても、NTFSのアクセス権はきちんとそれぞれのファイル、フォルダに書き込まれているということなのではないかと思います。なぜならそのほうが個別の処理がはやそうだから、アクセスがあるたびにいちいちアクセス権が本当に設定してあるところまで上へ上へ･･･とたどっていたら遅そうですものね。 というわけで、「なるべく早く動くように」と考えた結果がこの動作の違いになっているのでは、というのが私の予想です。 もしかしたらおおはずれかもしれませんが、このように裏側のロジックを予想した上で動きを覚えると記憶に定着します。ルールというか考え方だけ覚えておけばいいわけですからね!

WSHスクリプト(VBScript)でライブラリをインクルードするでライブラリをインクルードして…という話を書きましたが、実際に自分でライブラリ的なものを作成してくと、その品質保持が重要になってきます。私は品質保持のためにはxUnitを使ってユニットテストを自動化するのがよいと思っています。 ユニットテスト自体の内容は以下のあたりで確認してみてください。 xUnit - Wikipedia ＠IT：連載：快適なXPドライビングのすすめ 第4回 JUnit 実践講座 で、JavaならJUnit、C#ならNUnitなど非常にメジャーなテスティングフレームワークがある一方で、WSH用には…というと、ほとんど見つけられないというのが現状です。私も長い間ことあるたびに探してみたりしたのですが結局ずっと見つけられずにいて、かなりストレスがたまっていました。(自分で作ればいいのでしょうけれども、そこまでの力と気力が…) ですが、以下のサイトにてこの辺りのことが書かれていました。 UJS/UnitTestFramework - |▽￣)ノ なページ再帰 - livedoor Wiki（ウィキ） このサイトで直接書かれているのはJScriptに関する事です。Javascript用のテスティングフレームワークでそのまま使えるものがある、ということのようです。 さらにScriptUnitに関しては明確にVBScriptとJScriptへの対応を謳っています。 This works well enough for VBScript and JScript, but ActiveState PerlScript doesn’t work as well. ということで、ScriptUnitを用いてWSHで書いたライブラリをテストする方法を実際にこれから試してみようと思います。 (後日追記予定)

仕事を楽にするためにWSHを使いこなすでWSHの必要性について書きましたが、実際にWSHでいろいろとスクリプトを書いていくと、当たり前のようにライブラリが欲しくなります。インターネット上で探してもめぼしいライブラリは見つからないというのが現状だと思います。（もしも良いライブラリを知っている人がいたら教えてください!） そこで仕方なく（?）自分でライブラリを整備しています。具体的にはVBScriptでクラスを作成し、それを利用するスクリプトを拡張子.wsfで作成し、インクルードさせるようにしています。 具体的な記述内容は以下のようになります。 " m a i n " > " V B S c r i p t " s r c = " V B S L i b . c l a s s " " V B S c r i p t " > ' こ こ が ス ク リ プ ト の 本 体 VBSLib.classファイルにクラスが定義されている、というわけです。インクルードするだけのためにわざわざwsfファイルにしてXMLとして記述しなくてはいけないというところにかなりの不満とめんどくささがありますが、他にやりようがないようなので仕方なくこの方法で行っています。 ...