Windows

今回はWindows Serverをインストールしたあとで確認しておくべきことをまとめてみます。 i386フォルダの配置 i386フォルダというのはWindowsのインストールCD内にあるフォルダです。これがWindowsのインストラーの実態で、これさえあればWindowsコンポーネントの追加のときにCDを別途用意しなくてすみます。 i386フォルダを配置しておき、サーバーに対してSPを適用するときにはスリップストリームにてi386フォルダの内容も更新しておくことで、後日追加コンポーネントが必要になったときにSP適用済みのメディアがなくてあせるようなことになりません。 もちろんそれなりに容量をとりますので、別にサーバーのローカルディスクに必ず配置する必要があるわけではないですが運用形態によってはこのようなルールも便利だと思います。 ツールのインストール Support Tools マイクロソフト製のツールです。インストールCDやサービスパックなどの「\SUPPORT\TOOLS\SUPTOOLS.MSI」というファイルがSupport Toolsのインストーラーになっています。非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) Resource Kit Tools これもマイクロソフト製のツールです。昔は書籍にしかついていない時期もありましたが、今はWebからダウンロードできます。こちらも非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。) 管理タスクの Windows 2000 リソース キット ツール Download details: Windows Server 2003 Resource Kit Tools adminpak こちらは必須というわけではないですが、自身のサーバーには導入されていないサービスだけれども、リモートサーバーを管理したい、と言うようなときにはadminpakを導入しておくと便利です。 インストーラーは「%windows%\system32\adminpak.msi」です。これを導入すると、管理コンソールのみすべて導入されます。 各種更新作業 ドライバ更新 ドライバはインストール時に自動的に適用されているはずですが、きちんとドライバが適用されているかどうかを確認し、必要があれば更新を行うようにしましょう。 基本的にドライバのアップデートは各サーバーベンダーから出ているドライバのバージョンを一括管理できるツールを使って行いますが、きちんとデバイスマネージャーを見て、異常が無いことを確認しておきましょう。 黄色の感嘆符が出ないようにしましょう。 Service Pack, Hotfix 基本的にはWindows Server構築時には最新のService Packを適用した上でさらに全てのHotfixを適用しておくべきです。台数が少なければ個別に適用するべきものがなくなるまでMicrosoft Updateを実行すればいいでしょう。 一度Service Packを実行して、再起動したあとで再度Microsoft Updateを実行する･･･というように何度も繰り返す必要がありますので注意してください。 Microsoft UpdateはProxy接続の環境ではうまく動かないことがあります。この場合にはInternet explorerでのProxy設定だけではなく、proxycfg.exeコマンドでProxyを設定、再起動の上で再度実行するとうまくいくことがあります。 自動構成スクリプトの指定方法によって Windows Update が失敗する 上でも述べましたが、SP適用済みの環境に対して、SP的用済みではないメディアからWindowsコンポーネントを追加してしまった場合には、再度SPの再適用が必要ですので気をつけましょう。必ずスリップストリーム済みのi386フォルダからコンポーネントを追加しましょう。 イベントログの確認 インストール後には必ずイベントログの確認を行いましょう。警告、エラーが記録されている場合には、必ずそれに対して対処を行い、問題が無い状態にしましょう。 エラーの解消には以下のようなサイトが有効です。 マイクロソフト サポート オンライン EventID.Net 中には出ていても問題のないエラーなども存在しますので、それもあわせて確認しましょう。 Windows FireWall 現在のWindows ServerではWindows FireWallが自動的に有効になります。なんらかのサービスを提供するサーバーであれば必ずそのポートは開放する必要がありますので、忘れずに設定しましょう。 また、場合によってはWindows FireWallは無効に設定するポリシーのところもあるでしょう、いずれにしてもきちんと目的に合った設定にしましょう。 ...

今回の話題はWindowsネットワークに関してです。まずは一番基本的なところから、ということで2台のWindowsPCをネットワークで接続することから始めます。 まず接続する(レイヤー1) まず2台のPCを接続する必要があります。接続するには主に以下のような方法があります。 ハブ(スイッチングハブ、あるいはリピータハブ)を用意し、それぞれのPCをハブに接続する。ケーブルにはストレートケーブルを使う。 クロスケーブルを使い、2台のPCを直接接続する。 それぞれ無線LANのアクセスポイントに接続する。 どの方法でも構いません。下位レイヤに上位レイヤが無影響でいられるところがOSI参照モデルのメリットです。(参照：OSI参照モデルとTCP/IP) APIPA(Automatic Private Ip Addressing)を理解する 接続がすんだら次はネットワークの設定…なのですがその前に今の状態を確認してみましょう。 何もネットワークの設定をしていない状態で以下のコマンドを実行してみてください。 ping もう一台のコンピューター名 どうでしょうか?何も設定していないのにpingに応答があったと思います。(応答がない場合には後述する「通信できない原因」を参照してください)もうちょっと見てみましょう。「スタート」→「ファイル名を指定して実行」にて「\もう一台のコンピューター名」を入力してみてください。結果は環境やパスワードの設定などによって異なるのですが以下のような挙動のはずです。 パスワード入力を求められた コンピュータに接続でき、ウインドウが開いた さらに言うと、「マイネットワーク」を開いて適当にたどってもらうと、そこにもう一台のコンピューターも表示されているはずです。表示されるまでには時間がかかるのでまだ表示されていないようであれば10分程度待ってからもう一度表示してみてください。 つまり、何も設定していないのにもうネットワーク的に接続されていて、しかも、コンピューター名をお互いに認識できているわけです。Windowsは知識がないユーザーのために「とりあえず刺せば繋がる」ようになっているわけですね。 このときネットワークの設定はAPIPAという機構が働いて設定されています。アドレスは169.254.0.0/16の範囲から重複しないように選ばれます。ipconfig /allで設定を確認することができます。 この機能、親切だし便利ではあるのですが「設定されるまでに時間がかかる」「インターネットには接続できない」という致命的な問題もあり、実際にはよく分かっていない人がわけもわからず使ってしまっていることをのぞけばまず使われていません。 ネットワークの設定をする(レイヤー3) では、きちんとネットワークの設定をしていきましょう。現在はTCP/IPがデファクトスタンダードですので、WindowsのネットワークにおいてもTCP/IPの設定をすることになります。設定は以下の手順で行えます。 「マイネットワーク」を右クリック→「プロパティ」→「ローカルエリア接続」(※使用するネットワークアダプタ)を右クリック→「プロパティ」→「インターネットプロトコル(TCP/IP)」→「プロパティ」 ここで2台のコンピューターのネットワーク設定を以下のように設定します。 同一のネットワーク 重複しないIPアドレス 今はプライベートなネットワークを作ろうとしていますのでIPアドレスとしてはプライベートIPアドレスを設定すべきです。具体的には以下のアドレスの範囲から選択します。 範囲 サブネットマスク 10.0.0.0 - 10.255.255.255 255.0.0.0 172.16.0.0 - 172.31.255.255 255.240.0.0 192.168.0.0 - 192.168.255.255 255.255.0.0 実際には2台であれば192.168.1.0/24のネットワークを使って、192.168.1.1, 192.168.1.2というIPを割り当てることが慣習的に多いです。 しかし、上記のプライベートIPアドレスの範囲であれば何を使っても構いません。さらに言うと上記のプライベートIPアドレスの範囲を超えてグローバルIPアドレスの範囲を使っても通信は問題なく行えます。ただし、特殊用途のIPアドレスとして割り当てられている範囲もあるため、適当に設定すると通信できないこともあり得ますので、素直にプライベートIPアドレスを使うべきでしょう。 デフォルトゲートウェイとサブネットマスク このとき、デフォルトゲートウェイとDNSサーバーに何を入れればいいのか迷うかもしれませんが、今回の構成ではネットワーク上に存在しないわけですから何も入力しなくて構いません。あるいは何か適当なIPアドレスを入力しても構いません。このような構成は検証環境等ではよくあります。 ここでひとつ注意点です。たまにデフォルトゲートウェイに値が入っていないと正常に動作しないアプリケーションがありますので注意してください。(単にソフトウェアのつくりが悪いだけなのですが) 例：Outlook 2007 と Exchange Server の接続を試みたときに、エラー メッセージ “アクションを完了できません。Microsoft Exchange Server への接続が利用できません” または “Your Microsoft Exchange Server is unavailable” が表示される 通信してみる ここまででWindowsネットワークの設定が完了しました。 ...

今回はリクエストをいただいたので「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とローカルループバックの逆引きのレコードしか登録されていません。 ...

今回はドメイン参加の話をします。ドメインといってもＤＮ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 コンテナのリダイレクト

今回は、クライアントアクセスライセンス(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ドライブだと決め打ちしているところがあったそうです・・・。（＾＾； このようなことがありましたよ、ということで参考にしてもらえればと思います。

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と文字の場所が違いますが、誤植ではありません。 ...