今回は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からダウンロードできます。こちらも非常に便利なツールが多数入っていますので必ずインストールしておくことをお勧めします。(ツールの内容は別エントリで解説予定です。)
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を設定、再起動の上で再度実行するとうまくいくことがあります。
上でも述べましたが、SP適用済みの環境に対して、SP的用済みではないメディアからWindowsコンポーネントを追加してしまった場合には、再度SPの再適用が必要ですので気をつけましょう。必ずスリップストリーム済みのi386フォルダからコンポーネントを追加しましょう。
イベントログの確認
インストール後には必ずイベントログの確認を行いましょう。警告、エラーが記録されている場合には、必ずそれに対して対処を行い、問題が無い状態にしましょう。
エラーの解消には以下のようなサイトが有効です。
中には出ていても問題のないエラーなども存在しますので、それもあわせて確認しましょう。
Windows FireWall
現在のWindows ServerではWindows FireWallが自動的に有効になります。なんらかのサービスを提供するサーバーであれば必ずそのポートは開放する必要がありますので、忘れずに設定しましょう。
また、場合によってはWindows FireWallは無効に設定するポリシーのところもあるでしょう、いずれにしてもきちんと目的に合った設定にしましょう。
Windows自動更新
Windowsの自動更新もきちんと忘れずに運用ポリシーに合致するように設定しましょう。
ページングファイルの容量
ページングファイルはメモリに収まりきらなくなったデータが一時的にHDD上に置かれる場所です。パフォーマンスに非常に大きく影響を与えますので、極力早いディスクに配置しましょう。
きちんと目的に合わせた容量を、設計された場所に配置しましょう。パフォーマンスを重視するならシステムのディスクとは別のディスクに配置すべきです。
容量に関してはサーバーの種類や使われ方によって必要な量はまったく変わってくるので一概には言えませんが、メインメモリの1.5倍が一般的に推奨されています。サイズに関しては拡張時にパフォーマンスが低下してしまうので、最小サイズと最大サイズは同じサイズにはじめから設定しておきましょう。
hosts, lmhostsファイル
hostsファイル、lmhostsファイルは使用しないのがお勧めですが、どうしても使用する必要がある場合には必ず適切に設定しましょう。さもなければ致命的な問題になります。
ダンプファイルの種類と生成場所
ダンプファイルはOSやアプリケーションが致命的なエラーに陥った場合に、そのときの情報を吐き出すファイルです。大きく分けてOSのダンプファイルとアプリケーションのダンプファイルの2種類が存在します。
どちらも規定の状態でシステムドライブに生成される上に、サイズも巨大になりうるのでシステムドライブ以外の場所に変更しておくことをお勧めします。
OSのダンプファイルに関してはミニダンプでも、必要最小限の情報は取得できますが、HDD容量に余裕があるならば、カーネルメモリダンプに設定し、万が一なにかあった場合にカーネル内の調査ができるようにしておくといいでしょう。
アプリケーションのダンプファイルに関しては規定の状態でdrwtsn32.exeがデバッガに設定されていますので、「C:\Windows\system32\drwtsn32.exe」を起動し、設定を変更しておきましょう。
エラー報告機能
なにか問題があったときにマイクロソフトにエラーレポートを送信してくれるエラー報告機能ですが、これを有効にしておくと、エラー報告用のファイルが「C:\WINDOWS\PCHEALTH\ErrorRep\UserDumps」フォルダに延々とたまり続けてしまいます。場合によっては数十GBになることもあります。
必要がなければ機能を無効にしてしまいましょう。
時刻同期
コンピューターシステムでは時刻をきちんと同期させておくことが重要です。そうしておかないとあとから何かあったときにログを見ても時系列で問題を追いかけることができなくなってしまいます。
Windows Server 2003, Windows XPではw32tmコマンドで時刻同期を設定します。Active Directory環境では自動的に時刻同期がなされます。
時刻同期がきちんとなされているかどうかは「w32tm /monitor」コマンドで確認できます。
手動で同期先を設定するには「w32tm /config /manualpeerlist:<ピア>」コマンドで設定します。手動ピアの一覧を指定されたピアに設定します。DNS および IP アドレス、またはその両方をスペースで区切った一覧です。 複数のピアを指定する場合は、このスイッチを引用符で 囲む必要があります。
Windows ServerにWindows Server以外のNTPサーバーと同期させるように設定する際に以下のKBに該当するエラーが発生することが多いので注意してください。
時刻同期に関しては少々古い記事ですが以下の記事が詳しく書かれていてお勧めです。
イベントログの設定
イベントログは規定の状態で以下の状態になっています。
- 最大ログサイズ 16MB程度
- 必要に応じてイベントを上書きする
この結果、問題が発生しイベントログに大量にイベントが記録された際に、原因発生時のイベントログが残っていない、ということが起き得ます。最大ログサイズを大きくし、イベントを上書きしない設定にした上で、イベントログの保管ルーチンを別途設計、構築すべきです。
メモリチューニング
32bitOSで1GB以上のメモリを積んでいる場合にはメモリチューニングを行ったほうがいいケースが多いです。
OSの仮想メモリ空間の配置方法に関しての設定として/3GBスイッチと/uservaスイッチがあります。アプリケーションとしての推奨があればそれに従い、それ以外の場合にはいじらないのが無難です。
1プロセスで大量にメモリを消費するアプリケーションを使っている場合には、仕組みを理解した上でスイッチを付与するとパフォーマンス向上に効果的です。
/3GBスイッチのみを付与した場合にOSが不安定になるトラブルが結構報告されているそうなので注意してください。
コメント
たびたびありがとうございます。
なるほど。「Windows Server 2003完全技術解説」も確認してみたいと思います。(どうやら社内書籍として存在しているようなので)
でも、このあたりってちょっとビギナーには敷居が高過ぎるんですよね。読んでも寝ちゃう…みたいな。(それはまた全く別問題なのですが)
Windows Serverの本は、確かにないきもしていますが、
なくもないという気もします。
最近ようやく、インサイドWindowsをリファレンス用に使うようになりましたが、
それまでは『Windows Server2003完全技術解説』
を使ってました。
これも絶版プレミアム化されてます。
（インサイドWindowsより、手前レベルの本です）
絶版プレミアム化された本は、ヤフオクでアラート登録して、
気長に入手する方法が良さそうです。
>fjtさん
非常に有益な情報をありがとうございます!各項目のより深く突っ込んだものに関しては別途エントリを書こうと思います。
「サーバー管理者のためのイベントログ運用の基本」という本は知りませんでした。読んでみたいですが、ちょっと高いですね･･･。
こういったサーバー構築、管理に関する書籍はほとんどまともなものが無いというのが実情だと思ってます。(だからこうしてブログにちょっとずつでも書いていこうと思ってます。)もしも他にも良い本を知っていたら是非教えてもらえると嬉しいです。
おまけ情報です。
（エントリの趣旨からすると、踏み込んだ内容なので、深掘りしたい場合向けの情報）
> 最大ログサイズを大きくし、イベントを上書きしない設定にした上で、イベントログの保管ルーチンを別途設計、構築すべきです。
イベントログの設計をする場合には、以下の仕様（挙動）を把握しておいた方が良さそう
・アプリ・セキュリティ・システム・（ディレクトリサービス・DNS・etc）等、全てのログを合計したサイズが、300MBを超えることはないという仕様がある。
（設定上は、各ログにつき4GBまで設定可能。また、300MBは環境により変動する）
・イベントログはメモリに保存されるので、記録したイベントログのサイズ分だけメモリを消費する。（Services.exeのメモリ消費量が肥大化する）
■ 参考
イベントログに関する説明
http://www.microsoft.com/japan/technet/security/guidance/serversecurity/tcg/tcgch06n.mspx
『サーバー管理者のためのイベントログ運用の基本』 養老 利紀、平松 健太郎、高橋 明、 相場 宏
↑良い本だけど、絶版→プレミアム化
■おまけのおまけ
イベントログの自動ローテーション
http://support.microsoft.com/kb/312571/