| Windows Serverに関するTips集 |
Windows Serverに関するTips集です。Windows PCに関するFAQとあわせてご利用ください。
| 分類 | FAQ |
| サーバーの起動/停止 | Windows 2003でシャットダウンやリブート時の説明画面を省略するには |
| 説明 | |
| １．「スタート」メニューより、「ファイル名を指定して実行」を選択。 ２．「mmc」と入力して「OK」ボタンを押下。Microsoft Management Console（MMC）が起動される。 ３．MMCのメニューより、「ファイル」-「スナップインの追加と削除」を選択。「追加」ボタンを押下し、グループポリシー（ローカルコンピュータポリシー）を追加する。 ４．「ローカルコンピュータポリシー」「コンピュータの構成」「管理用テンプレート」「システム」の「シャットダウンイベントの追跡ツールを表示する」を無効に設定する。 |
|
| 分類 | FAQ | |||||||||||||
| 導入 | マイクロソフト製品ライセンス（CAL）について | |||||||||||||
| 説明 | ||||||||||||||
Microsoftサーバー・アプリケーションのライセンス方式には以下３つの基本パターンがある。
ケース１：CALモードを採用する製品のライセンス購入例 ・構成 ・Exchange Server 2003 導入サーバ １台 ・クライアント ３０台 →アプリケーションの利用に必要なライセンス ・Exchange Server 2003 サーバー・ライセンス ×１ ・Exchange Server 2003 CAL × ３０ クライアントの数もしくはユーザーの数分のCALを用意する必要がある ケース２：プロセッサ・ライセンスを採用する製品のライセンス購入例 ・構成 ・ISA Server 2000 導入サーバ（CPU１個） １台 ・クライアント ３０台 →アプリケーションの利用に必要なライセンス ・ISA Server 2000プロセッサ・ライセンス ×１ ・CALは不要 クライアントが多数の場合でも、サーバーのプロセッサの数に応じてプロセッサー・ライセンスを購入すれば、別途CALの購入は不要 ケース３：CAL/プロセッサー選択が可能な製品のライセンス購入例 ・構成 ・SQL Server 2000 導入サーバ（CPU１個） １台 ・クライアント ２０台 →アプリケーションの利用に必要なライセンス ・方針１ ・SQL Server 2000 サーバー・ライセンス ×１ ・SQL Server 2000 CAL ×２０ 12万7900円＋（2万8000円×20）＝68万7900円 ・方針２ ・SQL Server 2000 プロセッサー・ライセンス ×１ 87万2700円×1=87万2700円 ケース４：マルチプレキシング ・構成 ・SQL Serverへのアクセス時、複数台のクライアントに、必ずIISサーバを中継させることで、SQL Serverに直接アクセスしているクライアントを １台（= IIS Serverのみ）に見せかける。
→アプリケーションの利用に必要なライセンス ・方針１ ・SQL Server 2000 サーバー・ライセンス ×１ ・SQL Server 2000 CAL ×３０ ・方針２ ・SQL Server 2000 プロセッサー・ライセンス ×１ この場合でも、CAL数を減らすことはできない。インターネットに公開するサーバのようにユーザが不特定数であれば、プロセッサ・ライセンスを選択する。 ケース５：Core CAL ・構成 ・複数の製品をサーバーに導入し、使用する ・Windows2000 Server 導入サーバ １台（Active Directory） ・Windows Server 2003 導入サーバ １台（当サーバーには、アプリケーションとしてExchange Server 2003を導入する） ・クライアント ２０台 →アプリケーションの利用に必要なライセンス ・方針１ ・Windows 2000 Server サーバー・ライセンス ×１ ・Windows Server 2003 サーバー・ライセンス ×１ ・Exchange Server 2003 サーバー・ライセンス ×１ ・Windows Server 2003 CAL ×２０ ・Exchange Server 2003 CAL ×２０ ・方針２ CALのセット品である、「Core CAL」を検討する ・Windows 2000 Server サーバー・ライセンス ×１ ・Windows Server 2003 サーバー・ライセンス ×１ ・Core CAL ×２０ ・Core CALとは、CALのセット品で、「Windows Server」「Exchange Server」「Office SharePoint Portal Server」「Systems Management Server」の４種類が １つになった製品のこと。 ・Core CALにはソフトウェア・アシュアランス付（バージョンアップ保証つき）ライセンスしかない。 ・ちなみに、古いバージョンのCALでは、それより新しいバージョンのサーバー製品に接続できない ケース６：旧バージョンの製品を使用し続ける場合の考慮 ・現行の構成 ・SQL Server 7.0 導入サーバ ×１ ・クライアント（同時アクセスライセンス） ×５ ・新規の構成 SQL Server 7.0の同時アクセスライセンスを「＋５」購入したい。しかし、既にSQL ServerのバージョンはSQL Server 2000に移行しており、 SQL Server 7.0のCAL販売は終了している。 ・SQL Server 7.0 導入サーバ ×１ ・クライアント（同時アクセスライセンス） ×１０ →追加で必要なライセンス ・SQL Server 2000 CAL（ダウングレード権を行使し、当CALをダウングレードして使用） ×５ ・かつ、既存のCALについては、「接続デバイス数またはユーザー数モード」に変更する。 （・SQL Server 7.0であった「同時使用ユーザー・モード」はSQL Server 2000では使えず、「接続デバイス数またはユーザー数モード」しか使用できない） 参考）Open Business |
||||||||||||||
| 分類 | FAQ | ||||||||||||||||||||||||||||
| 導入 | WincowsXP SP2導入のための検証ポイント | ||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||
SP2導入のための検証ポイントと解決策
主なSP2関連ツール／情報の入手先
例外リストの修正： １．「スタートメニュー」から「コントロールパネル」を選択し、「ネットワークとインターネット接続」-「Windowsファイアーウォール」を選択する。 ２．「例外」タブを選択し、Windows ファイアウォールの「例外リスト」画面を表示する。 ３．「プログラムおよびサービス」の一覧に、例外対象としたいプログラムが表示されている場合はチェックをつける。 「プログラムおよびサービス」の一覧に例外対象としたいプログラムが表示されていない場合は、「プログラムの追加」ボタンを押してリストに表示されるプログラムの 中から選択し、登録する。（一覧にない場合は、「参照」ボタンを押下し、直接実行プログラムを指定する） ４．なお、ポートの例外設定については、上記「３」で、「ポートの追加」ボタンを押すことで行える。 ５．「OK」ボタンを押して「Windowsファイアウォール」を終了すれば完了。 |
|||||||||||||||||||||||||||||
| 分類 | FAQ |
| IIS | アプリケーションプールとは？ |
| 説明 | |
| 「IISマネージャ」管理コンソールのツリーに、「アプリケーションプール」というノードがある。このノードを展開すると、「DefaultAppPool」が「実行中」になっているのがわかる。 IIS6.0以降では、すべてのWebアプリケーションは「ワーカープロセス（w3wp.exe）」の内部で実行される。IISはリクエストの受信と送信だけに使用され、ASP.NET、ASP、ISAPIフィルタなどのコードは、すべてワーカープロセスで処理される。 アプリケーションプールとは、ワーカープロセスで処理されるアプリケーションのグループである。アプリケーションは、いずれか１つの指定されたアプリケーションプールに所属する。Webサーバはリクエストを受け取ると、それを適当なアプリケーションプールのリクエストキューに入れる。初期状態では「DefaultAppPool」が定義されているだけなので、すべてのアプリケーションは、「DefaultAppPool」に所属することになる。 Windows Server 2003で搭載されたIIS6.0以降では、このアプリケーションプールの利用方法を細かく制御することが可能である。ディレクトリや仮想ディレクトリごとに個別のアプリケーションプールを指定して、独立性を高めることができる。つまり、他のアプリケーションを停止した場合などにも影響を受けないよう、プロセスを分離することができる。これにより、複数の顧客や部署のサイトを管理する際などに、信頼性と管理性が高まる。さらに、アプリケーションプールがエラーで停止している場合には、それを検知して、アプリケーションプールを自動的に再起動することが可能である。また、アプリケーションプールごとにCPUの使用率やリクエスト数などを管理することもできる。 １．以前のIISとの互換性 IIS6.0の初期設定では、上記のようにアプリケーションプールを細かく制御できる「ワーカープロセス分離モード」になっているが、以前のIISと互換性を持っている「IIS5.0プロセス分離モード」も選択することができる。また、以前のバージョンのIISからアップグレードした場合には、「IIS5.0プロセス分離モード」になっている。「IIS5.0プロセス分離モード」では、IIS6.0以降のこれらのメリットを十分得ることができない。そのため、実行するアプリケーションのアーキテクチャが以前のIISに依存していて、互換性が特に重要視される場合のみ、「IIS5.0プロセス分離モード」を利用する。 |
|
| 分類 | FAQ |
| IIS | IISで使用するアカウント |
| 説明 | |
| IIS特有のアカウント ・IIS_WPG（グループ） IIS のグループアカウント。ワーカープロセスを起動実行するためのアクセス許可とユーザー権利を持っている。 ・IUSR_コンピュータ名 IIS のユーザーアカウント。匿名認証で既定のアカウント。 ・IWAM_コンピュータ名 IIS のユーザーアカウント。IIS5.0分離モードでアプリケーションを起動するためのアカウント。 IISで使う組み込みアカウント ・LocalSystem(SYSTEM) Administratorsグループに属するアカウント。システムへのフルアクセス権を持つので、ワーカープロセスをこのアカウントで実行すると、ワーカープロセスもフルアクセス権を持つことになる。 ・NETWORK SERVICE IIS6.0 での既定のワーカープロセスのアカウント。ネットワークでのやり取りができる。 ・LOCAL SERVICE コンピュータに対するアクセス権は NETWORK SERVICE アカウントと同じである。しかし、ネットワークでのやり取りはできず、権利がローカルコンピュータのみに限定される。 ・ASPNET IIS 5.0分離モードでASP.NETワーカープロセスを実行するためのアカウント。 |
|
| 分類 | FAQ | ||||||||||||||||||||||||
| IIS | IISのユーザ認証機能の種類 | ||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||
IISで設定できるユーザ認証機能には、以下の７種類が存在する。
「匿名認証」は、アクセスしてきたユーザに、パスワードやユーザ情報を求めない認証方法である。これは認証方法の１つであるが、セキュリティの機能はないので、一般に公開するWebサーバに適している認証方式といえる。 一般のWebサーバで使用される単純な認証が「基本認証」である。基本認証は、Internet Explorer以外のブラウザでも利用可能であるため、インターネット上での認証方式として広く利用されている。基本認証は低レベルでのセキュリティを実現するが、ユーザ名とパスワードがBase64でエンコードされたクリアテキストで送信されてしまうため、注意が必要である。 「統合Windows認証」やWindowsドメインサーバでの「ダイジェスト認証」は、パスワードをそのまま送らずに、ハッシュ化したデータをやりとりするため、SSLなどで暗号化しなくてもパスワードが漏洩してしまう危険性は低くなる。しかし、Internet Explorer以外のブラウザでは利用できない。そのため、社内のイントラネットや社員用の社外サイトなどで、WebサイトにアクセスするユーザがInternet Explorerしか使っていないという場合のみに利用することができる。イントラネットのWindowsドメインがある環境で統合Windows認証を利用した場合、ユーザは自動的に認証されるため、ユーザ名やパスワードを入力する必要がない。これは、Active Directoryに実装されているKerberosというセキュリティ機能を利用できるからである。 「.NETパスポート認証」は、マイクロソフトの「Microsoft.NET Passport」という仕組みを利用するものである。.NET Passoportは、個人情報を守りながらオンライン作業を行うためのサインインサービスで、「MSN Hotmail」や「Windowsメッセンジャー」などで利用されている。.NET Passport対応のWebサイトでは、専用の認証システムではなく、.NET Passportセントラルサーバでユーザを認証する。ユーザは１つのサインイン名とパスワードを使用して、.NET Passoprt対応のWebサイトにアクセスすることができる。 |
|||||||||||||||||||||||||
| 分類 | FAQ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IIS | IISログフォーマット一覧 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IISのログファイルフォーマットには以下の４つがある。
・Microsoft IIS ログファイル形式(標準形式、スタンダード形式) Microsoft独自のログファイル形式。カンマで項目が区切られているため、Excelなどへの取り込みや、プログラムでの加工が容易である。 ・NCSAコモンログファイル形式(NCSA共通ログファイル形式、National Center for Supercomputing Applications) National Center for Supercomputing Applicationという米国の国立スーパーコンピュータ応用研究所で開発されたWebサーバのログファイル形式に従ったもの。 ・W3C Extended ログファイル形式(W3C 拡張ログファイル形式) W3Cで標準化されている規格に従った形式。記録する項目を別途カスタマイズすることができる。 ・ODBC ログ データベースにログを保存する場合に利用する。 １．Microsoft IISログファイル形式（標準形式・スタンダード形式） ・テキスト形式 ・ファイル名形式：INyymmdd.log（yymmddは年月日、ログ期間が「毎日」のみ対象） ・フォーマットは、CVS（カンマ区切りのテキスト）。データの並びは以下の通り。
２．NCSAコモンログファイル形式（NCSA共通ログファイル形式） ・テキスト形式 ・ファイル名形式：NCyymmdd.log（yymmddは年月日、ログ期間が「毎日」のみ対象） ・フォーマットは、スペース区切りのテキスト。データの並びは以下の通り。
３．W3C Extendedログファイル形式（W3C拡張ログファイル形式） ・テキスト形式 ・ファイル名形式：EXyymmdd.log（yymmddは年月日、ログ期間が「毎日」のみ対象） ・フォーマットは、スペース区切りのテキスト、値は、その先頭部分に記述された＃Fields:に記載された個数、順番に従う。(*)の印は、IISでの初期値。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IIS | 専用Webサーバにおいて無効が推奨されるサービス | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
●Windows Server2003の専用Webサーバにおいて、無効が推奨されるサービス
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ | |
| IIS | IISマネージャにSMTP仮想サーバーが表示されない | |
| 説明 | ||
| 文書番号906100：SMTP仮想サーバーのスナップインは、IISマネージャConsoleに表示されません。 IIS6.0にて、SMTPサービスをいったんアンインストールし、再度インストールした場合、IISマネージャに「既定のSMTP仮想サーバ」が表示されなくなる。これを解決するには、次の２つの方法のどちらかを実行する。 （１）コマンドプロンプトを起動し、次の２つのモジュールを再登録する。
（２）IIS自体をいったんアンインストールし、再度IISをインストールして、SMTPサービスをインストールする。 |
||
| 分類 | FAQ | ||||||||||||||||||||||||||||||||||||||||||||||||
| IIS | Windows Server2003標準のPOP3メールサービスとExchangeSerever2003の機能比較 | ||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||||||||||||||||||||||
| POP3サービスは、Windows Server 2003により標準で提供されているサービスであるが、Microsoft
Exchange Serverでも同様にこのプロトコルがサポートされている。どちらのPOP3も同じインターネット標準のプロトコルなので、基本的な電子メールサービスをユーザに提供するという点においては同じである。Exchangeサーバーを利用している場合、次のような高度な機能がPOP3サービスで提供されている。 １．オンラインおよびオフラインバックアップ Exchange Serverのメールストアはトランザクションデータベースが採用されている。これによって、電子メールサービスを停止せずにメールデータのバックアップを行うことができる。比較的中規模から大規模の企業では、定期的にサービスを停止するとビジネスを停止させてしまう場合もあるため、この機能は重要である。 ２．単一インスタンスのサポート もし、ユーザが1MBの添付ファイル付きメールを同じサーバに属している100人のユーザに送信した場合、Exchange Serverでは、その1MBを100人分コピーせずに100人のユーザに送信することができる。Windows Server 2003のPOP3サービスでは、100人分展開する。これは、サーバの記憶域などのリソースをそれだけ消費することになる。 その他にも様々な違いが存在する。
|
|||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ | ||||||||||||||||||||||||||
| Active Directory | FSMO役割のマシンの障害回復 | ||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||
| NTドメイン環境では、ユーザーの追加やパスワード変更など、ディレクトリ情報を更新する場合は全てプライマリ・ドメイン・コントローラ（PDC）という役割のサーバー１台が担い、残りのドメイン・コントローラ（DC）はバックアップ・ドメイン・コントローラ（BDC）という役割になっていた。BDCは、ディレクトリ情報の修復を受け取り認証要求だけで処理しており、情報の更新はできない。これはあちこちのDCで情報を更新すると整合性がとれなくなるためである。NTドメインでは１台だけで情報を更新することで整合性の問題に対処していた。 これに対し、ActiveDirectoryドメイン環境では、すべてのDCで更新処理ができるマルチマスターという方式の複製を行っている。一見するとすべてのDCの機能が同一のようである。しかし更新処理によって競合が発生する特定の操作に限っては、「FSMO（フレキシブル・シングル・マスター操作）」と呼ばれる役割のDCにおいて処理され、シングル・マスターで複製を行う仕組みになっている。 この仕組みがあるため、DCが障害で停止したとき、FSMO役割のマシンであるかどうかでその後の復旧作業が変わってくる。日ごろからFSMO役割のマシンを把握しておかないと障害時の復旧時間が長くなってしまう。 FSMOには５つの役割が存在し、それぞれ以下に記載されている処理を単独で担当する。
これらの処理を実行する場合、その役割を持つDCにアクセスできなくてはならない。それぞれの処理が失敗する場合、どのDCがFSMOの役割を持っているかを確認し、そのDCが適切に動作しているかを調べる必要がある。 比較的理解しやすいのは、PDCエミュレータである。これは他のDCで行われたパスワードの変更が優先的に複製されるなどNTドメインにおけるPDCに近い役割を果たす。単純なマルチマスター複製では、ドメインのDCの数が多いと、あるDCでパスワードを変更しても、全てのDCに伝わりきるのに時間がかかる。PDCエミュレータが介在することで、変更されたパスワードの伝達が効率的になっている。 RIDマスターはアカウント作成時に生成されるSIDのもととなるRIDの提供元になるDCである。マルチマスター環境では、複数のDCで同時にアカウントが作成できる。しかし各DCが同じRIDでアカウントを作るとSIDが衝突してしまう。そこで、RIDマスターが一定のRID（RIDプール）をあらかじめ各DCに重ならないように割り振り、各DCにそのRIDプールからSIDを作らせている。 FSMOの役割を持つDCを確認するには、DCにインストールされているMMCスナップインを使用する。
「Active Directoryユーザーとコンピュータ」「Active Directoryドメインと信頼関係」は標準の管理ツールとしてDCのスタート・メニューに登録されるのですぐに利用できる。例えば、RIDマスター、PDCエミュレータ、インフラストラクチャ・マスターを確認する際には「Active Directoryユーザーとコンピュータ」を起動して、表れた画面の中の右側にあるドメイン名のアイコン（microsoft.localなど）を右クリックする。[操作マスター]というメニューが出てくるので、選択すると管理画面が出てくる。 「ドメイン名前付けマスター」は「Active Directgoryドメインと信頼関係」で調べる。起動したら、今度はドメイン名のアイコンではなく、「Active Directoryドメインと信頼関係」のアイコンを右クリックする。「操作マスター」というメニューが出てくるので、選択すると管理画面が表示される。 「Active Directoryスキーマ」は事前に「regsvr32 schmgmt.dll」コマンドを実行して、DLLを登録する必要がある。次にMMCを起動して、スナップインを追加する。「ファイル名を指定して実行」で「mmc」と入力すると、空のコンソールが表れるので、「ファイル」-「スナップインの追加と削除」を選択して出る画面で「追加」ボタンを押す。するとスナップインの一覧が表示されるので「Active Directoryスキーマ」を選んで追加する。 FSMO役割のDCに障害が発生すると、該当する役割の処理が行えなくなる。例えば、PDCエミュレータが停止すると、WIndowsNT4.0クライアントのようなダウンレベル・クライアントでパスワード変更ができない。一般的に、短時間で解決する障害であれば、復旧を待てばよいとされている。しかし、長期的に復旧の見込みがない場合や、クライアントに大きな影響を与える可能性のある障害が発生した場合は、FSMOの役割の移動を検討する必要がある。 移動には「転送」と「強制移動」の２つの方法がある。「転送」は、移動元のDCが正常稼動している状態での役割移動である。一方「強制移動」は、移動元のDCの障害などによりオフライン状態の際、強制的に役割を移動する方法である。 ただし、強制移動には注意が必要である。スキーマ・マスター、ドメイン名前付けマスター、RIDマスターの各役割を強制移動した場合、移動元のDCを、再度ネットワーク上に接続したり、バックアップ・データからリストアしたりしてはならないというルールがある。「強制移動」は、FSMOのDCが起動しない場合や、バックアップからも復旧できない場合など、障害回復の見込みがないときの最終手段である。 役割の移動は、GUIの管理ツールまたはNTDSUTILコマンド・ライン・ユーティリティで行える。ここでは、GUI管理ツールでRIDマスターの移動を行う場合の操作を説明する。 １．移動元のDCに管理ツール「Active Directoryユーザーとコンピュータ」を接続する ２．操作マスターの確認画面を表示する。上段が移行元のDCで、下段が移動先となるDCを表示している。ここで画面上の「変更」ボタンをクリックする。 この操作により、まず「転送」処理が試みられる。さらに移動元のコンピュータと通信ができない場合は、「強制移動」が行われる。 FSMOの役割を移動する際、役割の配置には機能上の制約があるため、注意する。特定のFSMO役割は、他の役割を持つDC上では共存できない。
ここで出てきたGC（グローバルカタログ）サーバーは、ドメインをまたぐ検索に用いるグローバル・カタログというデータベースを持つDCである。ドメイン内に複数設置できるため、FSMO役割とはいえないが、デフォルトでは１台しかない。また上記のような制限のため、どのDCがGCサーバになっているかを把握しておくべきである。確認に用いるツールは「Active Directoryサイトとサービス」である。起動したら、「Sites」というフォルダを開いて、下の階層を表示していく。DC名のアイコンの下に「NTDS Settings」というアイコンがあるので、それを右クリックして「プロパティ」を選択する。表れた画面の「全般」タブに「グローバルカタログ」の設定項目がある。 |
|||||||||||||||||||||||||||
| 分類 | FAQ | |||||||||
| Active Directory | ドメインコントローラのバックアップ | |||||||||
| 説明 | ||||||||||
| Active Directoryドメインでドメイン・コントローラ（DC）が複数存在する環境においては、複数のDCがデータを相互に複製している（マルチマスター複製）。しかし、バックアップからしか復元できない障害もあるため、DCのバックアップは必ず行っておく必要がある。また、リストアの手順は、単なるファイルの復元と異なるので注意すること。 バックアップ手順は通常とほぼ同じである。Windows Server 2003では、DC上のスタートメニューで「アクセサリー」-「システムツール」-「バックアップ」を起動して、「System State」（Windows2000では「システム状態」）を選択して、実行する。 リストア手順は通常と全く異なる。まずOS起動の初期段階の画面でF8キーを押して、「WIndows拡張オプションメニュー」から「ディレクトリーサービス復元モード」を選択する。この起動モードのログオン画面では、ドメインのAdministratorではなく、「ディレクトリ・サービス復元モード」専用のAdministratorのパスワードを入力する。それから「バックアップ」を起動して、「System State」を選択して、リストアを終えたら、再起動して通常モードで起動する。 誤ってユーザーを削除した場合や、手動で直せないほど多数のユーザーの属性情報を、間違った内容に書き換えた場合、「Authoritative Restore（権限ある復元）」を使ったリストアを行う。 ●Non-authoritative Restore（権限のない復元、デフォルト）
●Authoritative Restore（権限のある復元）
権限のない復元ではリストア後に、他のDCのデータで上書きされる。権限のある復元では、リストア後にそのデータで他のDCの情報を書き換える。Authoritative Restoreでは、「System State」のリストア後に再起動を要求されても、再起動してはならない。コマンド・プロンプトを開いて、「ntdsutil.exe」コマンドを実行し、「authoritative restore」と入力する。そして、「restore subtree "ou=ouname,dc=domainname,dc=local"」のようにリストアする必要のあるサブドメインツリーを指定する。
「sysvol」フォルダに格納されるグループ・ポリシーやログオン・スクリプトなどを間違って編集したなどでリストアする場合も注意する。リストア時は必ず「レプリケートされたデータセットを復元するとき、復元されたデータのレプリカをプライマリデータとしてマークする」オプションをオンにする。これにより復元されたデータが他のDCに上書き複製される。 |
||||||||||
| 分類 | FAQ | ||||||
| ActiveDirectory | アカウントの削除について | ||||||
| 説明 | |||||||
| ユーザー・アカウントを誤って削除してしまい、同じ名前で再作成したが、これまで利用していたデスクトップ画面が表示されない、または、共有フォルダやホーム・ディレクトリにアクセスできないという経験はないだろうか？WindowsNT系列のOSではユーザーやグループの作成時に「SID（セキュリティ識別子）」と呼ばれるアカウント固有の番号が割り当てられる。アカウントを一度削除すると，同じ名前で作成し直したとしても、新しいユーザーやグループには別のSIDが割り当てられる。そのため、削除前とは全く異なるユーザーやグループと判断されてしまう。 SIDは，ユーザーやグループ固有の番号、リビジョン、アカウント種別、発行元ドメインなどの情報によって構成されている。 ●セキュリティ議別子（SID）の構成 ユーザーやのグループ固有の番号、リビジョン、アカウント種別、発行元ドメインなどの情報によって構成されている。
①リビジョン・レベルやアカウント種別 ②「ドメイン識別子」ドメインを識別する番号 ③「相対識別子（RID）」アカウント自身の番号 アクセス許可の設定をはじめ、WindowsNT系列のOSでは、ユーザーやグループの名前ではなく、SIDによって、アカウントを特定する。 １．SIDはアカウント国有の番号 SIDは、ドメイン内はもちろん、他のドメインのものと競合することなく、常に一意の番号がアカウントに割り当てられる。同一ドメイン内のアカウントではドメイン識別子までが同一に保たれるが、相対識別子（RID）という部分が変わるようになっている。ドメインが違うとドメイン識別子の部分も異なる仕組みである。過去に発行したSIDが再利用されることはない。アクセス許可の設定はログオン名や表示名ではなく，SIDで行われている。SIDが再利用されると、過去に別人が作成したフォルダなどにアクセスできる恐れがある。アクセス許可リストや、ユーザー・プロファイルの一覧で、「不明なアカウント」という表示を見たことのある人もいるだろう。アクセス許可を与えたユーザーを削除しても、アクセス許可などの設定までは削除されないため、こうした「ゴミ情報」が残る。ここで「不明なアカウント」の後ろに記載されている「S－1-5－21－xxxxxxxxxx-･･･」が、SIDである。ディレクトリの中でSIDに対応するアカウント名に変換できない場合、「不明なアカウント」と表示される。前述のようにユーザーを作成し直しても、以前とは別のSIDが割り当てられるため、「不明なアカウント」が、ユーザ一名表記に戻ることはない。一度削除したユーザー・アカウントを復元するには、バックアップ・データから情報をリストアしなければならず、非常に厄介である。削除前に、削除による影響を洗い出し、次のような方法で対応できないか検討する。 ①削除前に「無効」期間を設ける 利用しなくなったユーザーのアカウントを放置することは、セキュリティ上好ましくない。すぐ実施したいのは，アカウントの無効化である。アカウントを無効にすると、そのユーザー名を利用してログオンができなくなるが、アクセス許可などの設定は維持される。無効期間中に、そのユーザーからドメイン内のサーバーからファイルを取り出したいなどの要求があったら、再度有効化して対応可能である。アカウント無効化の操作は「ActiveDirectoryユーザーとコンピュータ」というアカウント管理ツールで行う。ユーザーの一覧を表示したら、該当ユーザーをマウスで右クリックして表示されるメニューで［アカウントを無効化する］を実行する。 ②ユーザー名を変更する ユーザー・ログオン名の命名規則を変更したり、結婚などにより社員の姓を変更したりする場合には，「名前の変更」という機能で対応できる。山田花子さんが「yamada」というログオン名でシステムにログオンしていたとする。これを高橋花子さんが「takahashi」でログオンするように変更可能である。利用するツールは前述の「ActiveDirectoryユーザーとコンピュータ」である。ユーザーの一覧を表示したら、「山田花子」の上でマウスを右クリックして現れたメニューで[名前の変更］を選択して実行する。後は表示されたダイアログで、新しい姓・名およびユーザー・ログオン名を指定すればよい。ユーザーの表示名、姓・名、ログオン名を変更してもSIDは変わらない。名前を変更したタイミングで、アクセス許可リストやグループ・ポリシーなど、すべての設定に新しい名前が自動的に反映される。 |
|||||||
| 分類 | FAQ | |||
| ActiveDirectory | Windows Server2003ドメインのUsers及びComputersコンテナのリダイレクト | |||
| 説明 | ||||
| Microsoft文書番号：324949／対象：Windows
Server2003ファミリー ActiveDirectoryは、ユーザやコンピュータをOU単位にまとめ、OUごとにグループポリシーを適用して権限や動作を細かく細かく制御できる。今まで管理者がクライアントＰＣを１台ずつ回って設定していたことの多くが、ドメインコントローラ上の操作で完了するため、管理工数が大幅に削減される。 ユーザーアカウントやコンピュータアカウントは、それぞれ「Users」と「Computers」という「オブジェクトクラスコンテナ」に作成されるが、コンテナの中にＯＵを作成したり、コンテナにグループポリシーを設定したりすることはできない（ただし、ドメインコントローラのコンピュータアカウントが格納されている「Domain Controllers」は、ＯＵ内にさらにＯＵを作成したり、グループポリシーを編集することが可能） 「Users」や「Computers」コンテナは、新規作成したユーザーアカウントやコンピュータアカウントなどのデフォルト格納先になっている。これらのコンテナは、名前は変更できるが、削除することはできない。これらのコンテナに強引にグループポリシーを適用するには、次の方法が考えられる。
しかし、「従来のネットワークＡＰＩ（以下）」を利用するツールやユーティリティでは、ユーザやコンピュータを「Users」や「Computers」コンテナに作成するため、アカウントを作成するたびにＯＵへ移動しなければならなくなる。移動を忘れると、期待されるグループポリシーが適用されない可能性がある。
ユーザやコンピュータアカウントがデフォルトで任意のＯＵに作成されれば、管理工数がさらに削減できる上、グループポリシーのトラブルもなくなる。それを可能とするのが、当「コンテナのリダイレクト」手順になる。 コンテナのリダイレクトを行うには、対象ドメインまたはフォレスト全体の機能レベルが「Windows Server2003」でなければならない。 １．ドメインまたはフォレストの機能レベルを確認 最低でもドメインの機能レベルが「Windows Server2003」であることを確認する。ドメインの機能レベルを確認・変更するには「Active Directoryドメインの信頼関係」 を使用する。 ２．リダイレクト先のＯＵを作成する 「Active Directoryユーザとコンピュータ」で「Users」コンテナと「Computers」コンテナのリダイレクト先となるOUを作成する。 例として、「UsersOU」、「ComputersOU」を作成することとする。 ３．コンテナを作成したＯＵにリダイレクトする コマンドプロンプトを開いて「Redirusr」コマンド（> Redirusr OU=<リダイレクト先のOU名>,DC=<ドメイン名>）と「Redircmp」コマンドを順番に実行して、 コンテナをリダイレクトする。
以上のコマンド操作でコンテナのリダイレクト作業は完了である。アカウントのデフォルトの格納先がリダイレクトされたＯＵになり、アカウント作成直後からグループポリシーが適用される。 ところで、通常は「Users」コンテナと「Users」OUのように、同名のオブジェクトを同じ階層に作成するとエラーになる。ところが、「WIndows Server2003サポートツール」の「Ldp.exe」でコンテナ名を変更すると、変更前のコンテナ名と同じ名前のＯＵを同じ階層に作成してリダイレクトできるようになる。この手順は以下。 １．ドメインやフォレストの機能レベルを「WIndows Server2003」に設定する。 ２．コンテナの仮のリダイレクト先となる「一時プレースホルダ」を作成する。一時プレースホルダは任意のＯＵでかまわない。 ３．「Redirusr」コマンドと「Redircmp」コマンドで、コンテナを「一時プレースホルダ」にリダイレクトする。 ４．「Ldp.exe」を起動して、「Modify DN」を実行し、コンテナの名前を変更する。 ５．「Active Directoryユーザーとコンピュータ」で、変更前のコンテナ名と同名のＯＵを作成する。 ６．「Redirusr」コマンドと「Redircmp」コマンドを再度実行して、「一時プレースホルダ」から、手順「５」で作成したＯＵにリダイレクトする。 ７．「一時プレースホルダ」を削除する |
||||
| 分類 | FAQ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ActiveDirectory | グループとOUを区別する | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| WindowsNTの頃から、ユーザーに対する様々なセキュリティ権限を「グループ」と呼ばれるオブジェクトでまとめて管理している。例えば、グループを用いてファイルに対するアクセス許可を設定すると非常に効率的である。ただし、ActiveDirectoryでは組織単位（OU）と呼ばれるオブジェクトが追加された。グループもOUも「同一の権限を与えるオブジェクトを一括で管理するための器」で、それぞれの役割が混同されがちである。必ずそれらの違いを理解しておきたい。 グループはOS上の様々な機能のセキュリティ設定に用いられる。例えば、ファイル／フォルダに対するアクセス許可やプリンタの印刷権限、OS上の操作権限などである。一方、OUはActiveDirectoryのオブジェクトをまとめて管理するために 使われる。例えば、管理権限を一部の部署に委任したり、グループ・ポリシーの適用範囲として利用したりする。グループは削除してもメンバーであるユーザーまでは消えないが、OUを削除すると中身のユーザーなどが消えるという点には特に注意する。OUは中身を移してから削除する。 １．ADのグループは使い勝手が向上 OUとの違いを理解したら、グループの効果的な利用方法を覚える。ActiveDirectoryでは種類の多さから利用法で迷ったり，結果が分かりにくい複雑な使い方をしたりしがちである。ActiveDirectoryのグループとして覚えておきたいのは、「ドメイン・ローカル・グループ」「グローバル・グループ」「ユニバーサル・グループ」の3種類である。 ●ActiveDirectoryで利用できるグループ グループの種類（ドメインの機能レベルがWindows2000ネイティブ・モード以上の場合）
違いは、各グループに所属できるユーザー／グループの種類とグループの利用可能範囲にある。特性に応じて使い分けたい。注意点として、ユニバーサル・グループをファイルのアクセス許可設定に利用するには、ドメインの機能レベルを「Windows2000ネイティブ」または「Windows Server 2003」に設定しなければならないことである。 ●ドメインの機能レベルの種類
要件を満たしている環境であれば、すぐにでも機能レベルをアップさせることをお勧めする。3種類のグループを使う場合、一般的にはアクセス許可を次のようにして付与することが推奨される。 ①ユーザー・アカウントをグローバル・グループやユニバーサル・グループに登録する。 ②そのグループをドメイン・ローカル・グループに登録する。 ③ドメイン・ローカル・グループをファイルやプリンタなどのリソースのアクセス許可に使用する。 これによりアクセス権変更時の工数が削減される。例えば、「売り上げデータ」というフォルダにアクセス権を付ける場合を考える。以下図のようにグループが構成されていれば、営業3課と営業4課のユーザーをフォルダへアクセスさせるとき、「閲覧者」ドメイン・ローカル・グループに営業3課と営業4課のグループを追加するだけで作業が終了する。 ●グループを活用した効率的なアクセス権設定方法 「売り上げデータ」というフォルダにアクセス権を設定する例。営業3課と営業4課もフォルダへのアクセス権設定が必要になったとき、「閲覧者」ドメイン・ローカル・グループに営業3課と営業4課のグループを追加するだけで終了する。
一方、営業課ごとにアクセス権を割り当てていると、営業3課と営業4課の各グループにアクセス許可を設定しなければならない。設定するグループの数が多くなるほど、工数に差が表れる。 ２．グループのネストは3階層まで ActiveDirectoryのドメイン機能レベルを「Windows2000ネイティブ・モード」または「Windows Server 2003」にするとユニバーサル・グループをファイルのアクセス権に利用できるほかに、セキュリティ・グループのネストが柔軟に設定可能になる。ネストは、グループのメンバーに、別のグループを登録することである。ネストはメンバー変更作業の簡略化に役立つ。以下図では、会社の部署ごとにフォルダが作成されており、各フォルダはその部署のグループに所属するユーザーであれば利用可能である。 ●グループのネストを利用したアクセス権設定 部署ごとにフォルダが作成されており、それぞれのフォルダはその部署に所属するユーザーであれば利用可能にしたい。この場合、グループのネスト構造を組織構造に近い形にすることによって、ユーザーを1つのグループに所属させると複数のフォルダへのアクセス許可が設定されるようにできる。
この場合、グループのネスト構造を組織構造に近い形にすると、ユーザーを1つのグループに所属させるだけで複数のフォルダへのアクセスが許可できる。しかし、残念ながらActiveDirectoryには、グループのネスト構造を視覚的に見せるツールがなく、ネスト構造を管理者が直感的に把握しにくい。経験則からすると、グループのネストは3階層が限界、5階層になるとコンピュータ上では管理できず、紙に記した資料が別途必要になる。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ | |||||||||||||||||||||||||||||||
| ActiveDirectory | グループポリシーの設定 | |||||||||||||||||||||||||||||||
| 説明 | ||||||||||||||||||||||||||||||||
| グループポリシーは、ドメイン内のコンピュータやユーザに対して、管理者が指定した設定を一括して適用する機能である。クライアントのデスクトップ環境の統一や、セキュリティ関連の設定など、多数の設定項目が用意されており、項目の選定に迷うところが大きい。管理工数の削減やデスクトップ環境の制御以上に有効な利用方法は、セキュリティ関連の設定である。設定を特定の項目に絞れれば、実用上充分なメリットが得られる。 グループ・ポリシーのトラブルを避ける前提としては、まずサイト、ドメイン、OUのそれぞれのレベルごとに設定が存在することを理解する。
レベルが違っても同じグループ・ポリシーの設定項目がある場合が多く迷いがちだが、それぞれは元来別物である。そのため、サイトとドメインの各レベルで同じ設定項目がある場合、片方だけを設定すると、設定したレベルのものが有効になる。一方、両方のレベルで同じ項目を設定すると、決められた優先順位に従って、１つだけが適用される。 最も優先的に検討すべきセキュリティ項目は、ドメイン・レベルで設定する「アカウントポリシー」である。アカウントポリシーは、ドメインにおけるユーザ・アカウントのパスワードの長さや有効期限、アカウント・ロックアウトの有無など、ドメイン・ユーザのログオン・セキュリティを維持するための重要な項目である。これらはドメイン・レベルだけで有効な項目で、他では設定できない。Active Directoryを導入すると、「Default Domain Policy」と呼ばれる規定のドメイン・レベルのポリシーが設定される。Windows Server2003のActive Directoryドメインからは、セキュリティ強化のための規定値が厳しくなった。また、NTドメインからのアップグレード環境の場合、既存ドメインのアカウントの原則設定（パスワードの最低の長さなど）がそのまま引き継くれる。この他、コンピュータやユーザに適用すべき項目としてはそれぞれ以下のものがある。 １．コンピュータに適用する項目 コンピュータ・オブジェクトを対象としたセキュリティを強化するための設定として、管理者権限のあるユーザやグループの保護は設定しておくべきである。 ●コンピュータ・オブジェクトに適用すべき主なセキュリティ関連の設定
具体的には、「制限されたグループ」を用いてDomain AdminsやAdministratorsグループのメンバーとしてユーザが勝手に追加されないようにする。「Administrator アカウント名の変更」によって、よく知られているデフォルトの名前を変えて、攻撃者に狙われないように対策することも検討する。またファイルサーバでは、ログオン・ イベントをオブジェクト・アクセスの監査設定を実施し、システムに対する操作を追跡できるようにしておく。 ２．ユーザに適用する設定 ユーザを対象としたセキュリティを強化する設定の１つとして、簡易的にデジタル・データの持ち出しを防ぐものがある。例えば、フロッピードライブやCD-ROMドライブを エクスプローラ上で無効にしたり、CDの焼き付け機能を無効にしたりする設定が使用可能である。 ●ユーザ・オブジェクトに適用すべき主なセキュリティ関連の設定
完璧ではないが、対策の第一歩としては有効な手段である。 ドメイン・コントローラのコンピュータ・オブジェクトは、自動的に「Domain Controllers」OUに配置され、「Default Domain Controllers Policy」と呼ばれる規定のポリシーにより他のコンピュータよりもセキュアな構成になるように考慮されている。そのままそのOUを利用して運用することが推奨される。しかし、その他のコンピュータやユーザに対して、目的やセキュリティの強化レベルに応じて適用するポリシーを変更したい場合は、グループ・ポリシーの設定項目とあわせてOUを設計する。 グループポリシーと対応するOUを利用してセキュリティ設定を有効にしておくと非常に便利である。該当するOUへコンピュータやユーザオブジェクトを移動するだけで、設定が自動的に適用され、常に一定したセキュリティを保てるようになる。 |
||||||||||||||||||||||||||||||||
| 分類 | FAQ | |||||
| デバイス | IBMサーバのHDDマウンタ | |||||
| 説明 | ||||||
|
||||||
| 分類 | FAQ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| デバイス | ブレードサーバーについて | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 情報システムに対する信頼性と性能向上の要求に応じるためのアプローチは、１台のサーバのプロセッサの性能や記憶容量を巨大化する「スケール・アップ」と、多数の小型サーバで処理する「スケール・アウト」に大別される。このうち後者のアプローチで注目されている製品が、ブレード・サーバである。ハイエンドのエンタープライズ・サーバでは、コンソリデーション（統合）とバーチャリゼーション（仮想化）をキーワードに、各ベンダーが技術競争を進めている。ブレード・サーバは両技術を取り込みながら、成長していく。 １．ブレードサーバの一般的な構成 ブレード・サーバはそもそも、コンピュータの構成要素を極力共有して、小さなスペースに出来るだけ多数のサーバを収容するよう設計された製品である。その一般的な構成を以下にしめす。 ●ブレードサーバの一般的な構成
基本的な構成要素は、サーバ全体を格納するためのシャーシ（エンクロージャ）と、CPUやメモリー、ネットワーク・インターフェースなどを搭載し、コンピュータ１台に相当する機能を持つ薄い板状のモジュール「ブレード」である。ブレードを必要な台数だけシャーシに追加して、処理能力を増強する。
シャーシの中枢機能は、複数のブレードを接続するバス（プレーン）である。バスはブレードに電源を供給するとともに、ネットワークと接続するコネクタを提供する。バスにはブレードのほか、電源や冷却ファン、ネットワーク・スイッチなどの共通ユニットも接続される。 各ブレードには、CPUやメモリ、ハードディスクを搭載するが、フロッピーディスクやCD-ROMのドライブはなく、シャーシに持つ共通ドライブなどからソフトをインストールする。
ブレードサーバの登場以前から、単位面積当たり台数のサーバを収容できる製品としてラックマウント型のサーバがある。だが、ラック型サーバの大きさは、最小でも１台が19インチ幅、高さ1Uである。一方ブレードサーバは高さ3U～7Uのシャーシに8～24枚のブレードを収容する。例えば、3Uに24枚を挿せるブレード・サーバなら、ラック型の8倍の設置密度になる。一般的な高さ42Uのラックに100台以上のサーバが収まる計算である。企業内の全サーバを１台のラックにまとめてしまうようなソリューションが必要になる。またラック型サーバでは、信頼性を高めるために電源やファン、ハードディスクなどを冗長化しようとすると、1Uの大きさには収納しにくく、設置密度を下げるを得ない。 ●一般的なブレードサーバとラック型サーバ、ハイエンドサーバ（UNIX機やメインフレームなどスケールアップ型サーバ）の比較
２．高性能・高機能型ブレードが主流 ブレードサーバは当初、多くのWebサーバやファイルサーバを必要とするISPやデータセンター事業者に導入が進んだ。そのため各ベンダーは、消費電力の小さいCPUを使用して単位面積当たりのブレードの数を増やすことを競った。しかし、以降のブレードサーバ製品では、比較的高性能なCPUを2～4個搭載できるブレードが主流になってきた。スケールアップ型のサーバに近いアーキテクチャのブレード・サーバも存在する。これは企業システムのアプリケーションやデータベースをブレードで動かすという用途があるためである。企業システムの構成は、Webサーバ、アプリケーション・サーバ、データベース・サーバといった多層化がすすみ、サーバの台数が多くなる傾向にある。さらに、高可用性を実現するためにクラスタリング構成にすれば、より多くのサーバ台数が必要になる。ブレードの単価はサーバ１台よりも安価であり、サーバの台数が数台以上であれば、シャーシや電源のコストも低価格になる。台数が増えるほどブレード・サーバのコスト・メリットは大きい。 ３．集約・統合で無駄を省く ブレードサーバの高性能。高機能化が目指すところは、複数のシステムがばらばらに運用されている環境を、集約して統合する「コンソリデーション」である。単に設置面積を節約するだけでなく、サーバリソースの無駄を省くのである。例えば、ある企業で、受注、製造、会計システムでサーバがそれぞれ2台、2台、3台必要だったとする。システムごとに利用のピークにあわせて余裕を持ったリソース構成でなければならない。これを統合すると、3システムを4台のブレードですませることも可能になる。 通常は受注システムに多くのリソースを割り当てておき、会計処理が多くなる月末のみ会計システムに多くのリソースを割り当てる。
ブレードサーバの強みは、リソースを追加するときのコストと手間が少ないことである。導入当初は最小限のハード構成にして、処理性能が不足したらブレードを追加する手法が採りやすい。故障時にもブレードのみや電源のみといったモジュール単位の交換で済むの、余分な費用がかからない。ブレードの追加や交換時に、他のブレードを止める必要がない。前面からブレードの抜き差しが可能で配線作業が必要ないといった利点もある。 ４．ハードに管理・監視機能を組み込み 逆にブレード・サーバのアキレス腱は、構成管理が複雑になり運用コストが増大しやすいことである。そこで各ベンダーのブレード・サーバは、独自に強化した管理・監視機構を搭載している。シャーシがブレードの追加や交換を検知する仕組みを持ち、ブレードを交換・増設したら自動的に構成情報を更新したり、必要なソフトウェアをインストールする。さらにブレードが故障を起こしたら、待機していた予備のブレードが自動的に交代して同等な構成に復旧する。システムの処理能力が不足してきたら、予備のブレードを立ち上げる、などである。このように、システム構成を動的に更新・再配置する機能を「プロビジョニング」という。ラック型サーバでも運用管理ソフトやクラスタリング・ソフトで同様の機能が実現できるが、ブレード・サーバはハードに組み込んだ機能で自動的なプロビジョニングをより充実させている。ただし、現行のブレードサーバ製品のプロビジョニング機能では、運用管理の完全な自動化は難しい。ネットワークやハード構成が変わったときの、アプリケーション設定の変更の自動化が困難なためである。例えば、交換の前後でブレードのCPUやネットワーク・デバイスの仕様が違っていたら、そのままではシステムが動作しない可能性がある。 ５．バーチャリゼーションの併用が必要 この問題を解決するのがバーチャリゼーションである。すなわちハードウェアを仮想化し、ソフトとハードの依存関係を分断する技術である。バーチャリゼーションを実現する代表的な方法は、VMwareやMicrosoft Virtual Serverなどの自動化ソフトの活用である。仮想化ソフトでブレードのハードの違いを吸収すれば、どのブレードでもアプリケーションが動作できる。1ブレードに複数の仮想マシンを立ち上げることで、より細かなリソース配分も実現できる。コンソリデーションとバーチャリゼーションの技術の併用により、電気や水道などの公共サービスのように、必要なときに必要なだけ資源を利用できる「ユーティリティ・コンピューティング」の環境を実現できる。スケール・アウト型の中でもコンソリデーション機能が高いブレードサーバは、ユーティリティコンピューティングのプラットフォームとして有効である。 ●ユーティリティ・コンピューティングを実現するプラットフォーム
ただし、バーチャリゼーション技術は未熟な部分もある。複数のサーバをまとめて一つのリソースとして扱うには、ソフトウェアでのクラスタリングやグリッド化が必要になる。さらに動的なリソース配分を実現するには、各サーバ・ベンダーが提供するツールだけでは不十分で、アプリケーションサーバやデータベースのクラスタリング、グリッドの設定など、高度なスキルとノウハウが必要である。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ |
| ディスクの管理 | システムファイルを含めたすべてのファイルを拡張子付きで表示させる |
| 説明 | |
| WindowsXPのファイルエクスプローラは、デフォルトではファイルの拡張子やシステムファイル（ユーザプロファイルフォルダの「NTUSER.DAT」、「NTUSER.DAT.LOG」など）を隠している。 システムファイルを含めたすべてのファイルやフォルダを、拡張子付きで正確に表示するには以下手順を行う。 （１）ファイルエクスプローラを起動し、「ツール」 - 「フォルダオプション」を選択。 （２）「フォルダオプション」の表示タブを選択 （３）「詳細設定」リストから、以下の設定を行う。 ・「システムフォルダの内容を表示する」にチェック ・「すべてのファイルとフォルダを表示する」を選択 ・「登録されている拡張子は表示しない」のチェックを外す ・「保護されたオペレーティングシステムファイルを表示しない」のチェックを外す （４）「適用」をクリックし、「すべてのフォルダに適用」をクリックする。 |
|
| 分類 | FAQ | |||
| ディスクの管理 | ファイルの「所有者」「権限」「監査設定」をコピーする | |||
| 説明 | ||||
| 文書番号：323275／対象：Windows2000ファミリー／件名：Robocopyを使用して、ファイルのデータをコピーせずにセキュリティ情報をコピーする方法 NTFSファイルシステム上のフォルダやファイルには必ず「所有者」「アクセス権」「監査設定のセキュリティ情報」が付随しているが、ファイルやフォルダのプロパティを開かないと確認できないので、通常あまり意識されない。しかし、エクスプローラや「COPY」コマンドを使用した単純なコピー操作の裏側では、次のような重大な変化が起こっている。 ・所有者：コピーを実行したユーザまたはグループに変化 ・アクセス権：コピー先フォルダのアクセス権に変化 ・監査設定：コピー先フォルダの監査設定に変化 例えば、次のようなアクセス権が設定された「C:\WORK」フォルダと「D:\TEST」フォルダがあるとする。 ●「C:\WORK」フォルダのアクセス権 Administrators：フルコントロール Domain Admins：フルコントロール Domain Users：読み取り SYSTEM：フルコントロール ●「D:\TEST」フォルダのアクセス権 Everyone：フルコントロール 「C:\WORK」フォルダから「D:\TEST」フォルダにファイルをコピーすると、「D:\TEST」フォルダの「Everyone：フルコントロール」というアクセス権設定が自動的に適用され、コピー元ファイルのアクセス権が消滅してしまう。同様に「マイネットワーク」でネットワーク上の共有フォルダから直接コピーしたり、共有フォルダにドライブを割り当ててからコピーしたりしても、コピー元ファイルのセキュリティ情報は消滅する。 この変化を充分に意識してファイルを操作しないと、ファイルサーバの変更やリプレースなどの際に問題が発生することになる。必要なファイルやフォルダを新しいファイルサーバにコピーし終わって、古いファイルサーバを廃棄してみたら、すべてのセキュリティ情報がリセットされていて役に立たなかったという事故が起こる。 セキュリティ情報を保持したままファイルをコピーする方法の１つとしてWindowsが標準で装備する「バックアップユーティリティ（NTBACKUP）」を使用して、バックアップとリストアを実行するという方法がある。NTBACKUPはセキュリティ情報も含めてファイルやフォルダの全情報をバックアップし、任意の場所にリストアすることができる。 しかし、例えばコピー元ファイルサーバがWindowsNT Server4.0で、コピー先ファイルサーバがWindows2000ServerやWindows Server2003の場合、WindowsNT Server4.0のNTBACKUPがサポートするバックアップメディアがほぼテープメディアに限定されるという制約があるので、コピー先ファイルサーバにテープドライブが必要になる。 また、逆の発想として、コピー先ファイルサーバのNTBACKUPを使って、コピー元ファイルサーバをネットワークドライブとしてバックアップすることは可能だが、いったんファイルやリムーバブルメディアにバックアップしてから、任意のドライブやフォルダにリストアし直す手間に無駄がある。 ファイルやフォルダを丸ごとコピーするには、サブフォルダも含めてコピーできる「XCOPY」コマンドが便利である。しかも、Windows2000以降では「XCOPY」コマンドの機能が大幅に拡張されており、「所有者」と「アクセス権」を同時にコピーする「/O」オプションと、「所有者」「アクセス権」「監査設定」をすべてコピーする「/X」オプションが追加されているので、セキュリティ情報を保持したままネットワーク経由でのコピーが可能になっている。 WindowsNT Server4.0からWindows2000 ServerやWindows Server2003への移行では、移行元のWindowsNT Server4.0ファイルサーバから移行先ファイルサーバにコピーするのではなく、逆に移行先ファイルサーバから「XCOPY」コマンドでファイルを取り出せば、セキュリティ情報も漏れなくコピーできる。 上記のXCOPYの拡張オプションを使わず、ファイルエクスプローラなどで、ファイルやフォルダを単純にコピーしてしまうと、前述のとおり、コピー先ではオリジナルのセキュリティ情報が消滅してしまう。セキュリティ情報を復元するには、「/X」オプションを付けた「XCOPY」コマンドでファイルやフォルダをコピーし直す方法もあるが、Windows2000リソースキットに収録されている「Robocopy.exe」コマンドを用いて、既存ファイルのセキュリティ情報だけをコピーして上書きする方法がスマートである。 「Robocopy.exe」コマンドには、「XCOPY」コマンドにはない、次のような機能が多数搭載されており、きめ細かさと便利さでは「XCOPY」コマンドをはるかに凌ぐ。一部のオプションは、WindowsNT 4.0リソースキットにも収録されている「Robocopy.exe」コマンド（バージョン1.54）にも搭載されているが、すべての機能を利用するには、Windows2000リソースキットで更新された「Robocopy.exe」コマンド（バージョン1.96）が必要になる。 （１）ミラーモード 「/MIR」オプションを指定することで、コピー元フォルダとコピー先フォルダの内容を比較して、サブフォルダも含めて完全に同一になるようにコピーを実行する。通常の コピーでは、削除されてコピー元にはないファイルがコピー先に残るが、ミラーモードでは、コピー先からも削除される。また「/PURGE」オプションを指定して、コピー元で 削除されているファイルを抽出して、コピー先から削除することもできる。 （２）コピーする階層の深さ指定 コピー元フォルダに複数階層のサブフォルダがある場合、「/LEV:n」オプションを指定することで、フォルダツリーのn階層まで選択的にコピーできる。 （３）ファイルやフォルダの移動 コピーではなく、ファイルやフォルダを階層ごと移動することができる。「/MOV」オプションでファイルだけを移動し、「/MOVE」オプションでファイルとフォルダを移動する。 移動元のフォルダからは、ファイルやフォルダが削除される。 （４）属性の変更 「/A+:」オプションで、コピー先のファイルに「読み取り専用」や「隠しファイル」など指定した属性を付加することができる。逆に「/A-:」オプションで、属性を削除する こともできる。 （５）コピー条件の設定 「/MAX:n」オプションと「/MIN:n」オプションで、コピー対象の最大または最小ファイルサイズを絞り込むことができる。「/XC」「/XN」「/XO」の各オプションでは、コピー先 のファイルと比較して変更されたか、新規作成されたか、古いファイルをコピー対象から除外できる。 既存ファイルのセキュリティ情報を上書きコピーするには、「Robocopy.exe」コマンドの「/SECFIX」オプションを使用する。このオプションはWindowsNT 4.0リソースキットの「Robocopy.exe」コマンドには搭載されていないので、必ずWindows2000リソースキットのものを使うこと。 以下のように「/setfix /xo /xn /xc」オプションを付けて「Robocopy.exe」コマンドを実行すれば、ファイルをコピーし直すことなく、既存のコピー済みファイルのセキュリティ情報だけを上書きコピーできる。
しかし、上記のコマンドラインを実行すると、実際にはコピー先フォルダに不足しているファイルもコピーされるため、「既存のファイルのセキュリティ情報だけをコピーする」という動作にはならない。 次のように「/XL」オプションを追加で指定して、コピー先に存在しないファイルをコピー対象から除外することで、初めて既存ファイルのセキュリティ情報だけをこぴーできるようになる。
ところが、今度はコピー元フォルダ直下のファイルのセキュリティ情報だけがコピーの対象になるため、コピー元フォルダにサブフォルダがあると、サブフォルダのセキュリティ情報はコピーされないという別の問題が発生する。この場合は、次のように「/E」オプションを追加して、空のサブフォルダまでコピー対象に含めてやれば、指定したフォルダと、そのサブフォルダと、サブフォルダ内のファイルのセキュリティ情報を一括してコピーすることができるようになる。もちろん、「/XL」オプションが効いているので、指定したフォルダやサブフォルダの不足ファイルがコピーされることはない。
|
||||
| 分類 | FAQ |
| ディスクの管理 | シャドウコピー機能を使用する |
| 説明 | |
| その昔、MS-DOSでは、削除してしまったファイルを復元させる手段がOSの標準機能として提供されていなかった。そのため、フリーソフトの復元ツールに頼っていた（末期のMS-DOSには「UNDELETE」コマンドが提供されたが、これはファイル削除の際に抹消したFATエントリを復活させるもので、意味合いが異なる）。 Windows95以降はMachintoshと同様に「ごみ箱」の機能が加わったので、削除したファイルでも「ごみ箱を空にする」までは復元できるようになった。しかし、ごみ箱から復元できるのは、あくまでローカルディスク上のファイルである。ネットワーク経由で接続した共有フォルダのファイルについては、ゴミ箱が存在しないので、削除したファイルはその場で消え去ってしまう。そのため、共有フォルダのファイルを誤操作で削除してしまうと、バックアップを取っていなければ基本的には取り戻せない。 そこで、Windows Server2003にはシャドウコピー機能が追加された。これは、ハードディスクの内容を定期的に複製して、削除してしまったファイルをその複製から復元できる機能である。ドライブごとに作成される複製は「スナップショット」と呼ばれ、スナップショット用に確保するディスク領域は自由に変更できる。 ただし、シャドウコピー機能を使っても、バックアップ作業が不要になる訳ではない。スナップショットの作成先は、同じサーバ上のディスクであり、ハードディスクやサーバ機器の物理的な故障には対応できないためである。また、スナップショットは一定の間隔で定期的に作成されるので、タイミングによっては、削除したファイルと同じ内容のファイルを復元できない。つまり、更新前のファイルに戻ってしまう可能性もある。 クライアントPC側でこの機能を利用するには、専用の「シャドウコピークライアント」のインストールが必要になる。WindowsXP用のシャドウコピークライアントはWindows Server2003のインストールCD-ROMに含まれている。また、Windows2000用のシャドウコピークライアントはマイクロソフトのダウンロードセンターを通じて提供されている。 １．サーバでシャドウコピーを実行する 次にシャドウコピーを利用するための設定手順を紹介する。 （１）有効化の手順 ①エクスプローラ上でシャドウコピーを設定したいドライブを右クリックして、「プロパティ」を表示する。 ②「シャドウコピー」タブを選択する。初期設定では無効になっているので、「有効」をクリックする。 シャドウコピーを有効にした時点で、スナップショットが作成される。そのスナップショットがいつの時点によるものかは、「選択したボリュームのシャドウコピー」に表示 される。その上部の「ボリュームの選択」には、次のスナップショット作成時刻が表示される。なお、その間にファイルの内容を変更したい場合は、前回のスナップショット からしか復元できない。そのため、重要なファイルを作成/変更して、その時点でのスナップショットを用意しておくには、「今すぐ作成」をクリックする。またディスクの空き 容量が足りないので削除したい場合は、スナップショットを選択して、「今すぐ削除」をクリックする。 （２）カスタマイズする スナップショットの「作成場所」「サイズの上限」「スケジュール」などを規定値から変更する場合、先述の「シャドウコピー」タブより、「設定」をクリックすると開く画面から 行う。変更できる項目の詳細は以下の通りである。 ①記憶域 スナップショットの作成場所をドロップダウンリストを使って変更できる。規定値ではシャドウコピーを設定しているドライブと同じドライブに作成される。「詳細」をクリック すると、記憶域として指定されているドライブ（ボリューム）の空き容量などを確認できる。別のドライブに作成すると、次のような利点がある。 ・ディスクI/O負荷の分散を図れる（同じハードディスクの別のパーティションでは意味がない） ・スナップショットのためにディスク容量が圧迫されないため、大容量のスナップショットを作成できる。多くのデータを保持しておけると、復元対象になる過去の バージョンを増やせる。 ②最大サイズ スナップショットはディスクの空き領域に作成される。無制限に作成していると本来使用すべきディスク容量を圧迫する。そこで100MBを下限として、上限については 指定値以上にスナップショットが作成されないように設定できる。スナップショットが上限いっぱいに達した後は、古いものから削除される。「制限なし」という選択肢も あるが、スナップショットが空き容量を食いつぶしてしまう可能性があるので、指定したほうがいい。 ③スケジュール 設定画面の「スケジュール」をクリックすると、スナップショットを作成するタイミングを変更できる。まずは「タスクのスケジュール」として、スナップショットを作成する 間隔を選択する。選択肢には次のものがある。 ・日単位（何日間隔で行うかの指定） ・週単位（何週単位で行うかの指定。曜日も指定可能） ・月単位（実行日の指定。実行月も指定可能） ・１回のみ（何月何日に行うかの指定） ・システム起動時 ・ログオン時 ・アイドル時（スナップショット開始までの待ち時間を指定。規定値は１０分） ここで「日単位」「週単位」「月単位」「１回のみ」のタスクを選択すると、「詳細設定」が有効になり、タスクの繰り返し実行が可能になる。これらの選択肢は、どの タイミングでスナップショットを必要とするかで使い分ける。例えば、毎日起動とシャットダウンを繰り返しているサーバの場合、「システム起動時」を選択すれば、 少なくとも１日１回のスナップショット作成が確保できる。一般的には日単位で１日１回、あるいは週単位ですべての週末に作成するという選択肢が基本になる。 また、Windows Server2003のシャドゥコピー機能では、複数のスケジュール設定を登録して、それを使い分けることができる。「スケジュール」タブ上部の「新規」を クリックすると、新たなスケジュール設定が作成されて、その内容が画面の下半分に表示される。そこで設定内容を変更する。登録されている複数のスケジュール 設定は、上部のリストボックスから選択する。また「削除」をクリックすると、不要なスケジュール設定を削除できる。 （３）利用を停止する シャドウコピーの実行を停止したい場合には、先述の「シャドウコピー」タブの「ボリュームの選択」で対象となるボリューム（ドライブ）をリストから選択して、「無効」を クリックする。なお、シャドウコピーを無効化すると、既存のスナップショットはすべて削除される。そのため、「スナップショット作成を無効化して、これ以上ディスク 容量を消費するのは避ける。ただし、過去のスナップショットは残しておく」というような使い方はできない点に注意する。 ２．クライアントPC側の準備と操作 （１）専用クライアントのインストール Windows Server2003のシャドウコピーで作成されたスナップショットからファイルを復元できるクライアントOSは、WindowsXPとWindows2000（SP3）以降に限定される。 ただし、これらのOSでも専用のシャドウコピークライアントと呼ばれるソフトウェアをインストールする必要がある。 WindowsXPについては、Windows Server2003のリリース当初からシャドウコピークライアントが提供されていた。その後、WindowsXP/2000の両方に対応したシャドウ コピークライアント（Ver.5.2.01）がリリースされたので、Windows2000でも復元が可能になった。最初にリリースされたWindowsXP専用のシャドウコピークライアントは、 Windows Server2003をインストールしたサーバの「%SystemRoot%\system32\clients\twclient\x86」に置かれている「twcli32.msi」ファイルとして提供されている。 このファイルをクライアントPCにインストールすればよい。 一方、WindowsXP/2000の両方に対応しているシャドウコピークライアントは、「マイクロソフトダウンロードセンター」より入手する。 Windows2000でシャドウコピークライアントをインストールするには、Windows Installer2.0が必要だが、SP4を適用済みであれば、すでに対応している。なお、クライアント PCにWindows2000を使用する場合、Windows Server2003が動作するサーバ側にも、シャドウコピークライアントをインストールする必要がある。これを インストールしないと、復元対象のファイルやフォルダが一覧に表示されないというトラブルがあるので注意したい。 （２）ファイルの復元手順 シャドウコピークライアントをインストールしたWindows2000/XPから、シャドウコピーを設定したサーバやドライブ上の共有フォルダに接続してみる。すると、共有フォルダ の「プロパティ」に「以前のバージョン」というタブが追加されている。共有フォルダ内に置かれているフォルダやファイルのプロパティを直接表示させても同じ「以前の バージョン」タブが表示されている。この状態でスナップショットから復元を行うには、次の３つの方法がある。これは「以前のバージョン」タブの下部にある３つのボタン のうち、どれをクリックするかで次のように使い分けられる。 ①「表示」ボタン スナップショットから復元できるファイルやフォルダの一覧を表示する。表示された画面からドラッグ＆ドロップでファイルを取り出すことができる ②「コピー」ボタン スナップショットから復元するファイルを任意のフォルダに書き出すことができる。つまり、サーバ上のファイルには影響を及ぼさずに別の場所に古いファイルを復元 できる。 ③「復元」ボタン スナップショットから取り出したファイルで、共有フォルダに存在するファイルを上書きする。これを実行すると、スナップショット作成よりあとの更新内容が失われて しまう。 |
|
| 分類 | FAQ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| システムバックアップ | WindowsXPバックアップデータ一覧とその取得方法 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ●Windows XP Professional/Home Editionのバックアップデータ一覧 ※NTBACKUPの「バックアップ」タブ - 「マイコンピュータ\System State」を選択
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ | |
| ネットワーク | Windowsにおける時刻同期動作の流れ、及び時刻同期サーバの設定 | |
| 説明 | ||
| Windows2000/XPベースでの時刻同期には、SNTP
に完全準拠した「W32Time」(Windows Time Service)を使用し行う。 １．W32Time の動作フロー （１）クライアントは、認証しているドメイン コントローラにコンタクトする。 （２）2台のコンピュータ間の通信待ち時間を決定するために、パケットが交換される。 （３）W32Time は、ローカルで統一すべき現在時刻を決定する。 （４）クライアントは、ローカル時刻を調整する。 （５）サーバの時刻とクライアント時刻でクライアントが遅れている時は、クライアント時刻は、サーバの時刻に即座に設定される。(時間を進める) （６）サーバの時刻とクライアント時刻でクライアントが進んでいる場合は、その差が３分を超えていなければ、２つの時刻が合うまで、クライアントの時計を遅く進める。 ３分 以上の差がある場合、時刻は即座に設定される。 （７）クライアントは定期的なチェックを行う。 （８）クライアントは、各 "周期" に 1 回、認証しているドメイン コントローラに接続する。 （９）最初のデフォルトの周期は４５分。 （10）時刻の同期試行が３回連続して成功した場合は、周期は８時間に増える。 （11）時刻の同期試行が３回連続して成功しない場合は、４５分にリセットされる。 ２．Windows2000/XP端末を時刻同期サーバーとする （１）「W32Timeサービス（Windows Time Service）」を開始する。
（２）次回以降、Windows Timeサービスが自動起動するよう設定する。 （３）HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\LocalNTPの値を「0」から「1」に変更する。 参考）Windows2003の場合： ・HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enabledの値を「0」から「1」に変更 ・HKEY_LOCAL_MACHINE\SYSTEM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlagsの値を「5」（Reliable Announceを常時出す）に設定 （４）「W32Timeサービス（Windows Time Service）」（or Windows Timeサービス）を再起動する。 |
||
| 分類 | FAQ | |||||||||||
| ネットワーク | Windows Server2003において、Windows以外の時刻同期サーバとの同期に失敗する | |||||||||||
| 説明 | ||||||||||||
| 文書番号 : 875424 Windows Server 2003 で
Windows 以外の NTP サーバーとの同期が成功しない 文書番号 : 816042 Windows Server 2003 で権限のあるタイム サーバーを構成する方法 Windows Server 2003 が外部NTP Serverと時刻同期に失敗する問題は、外部のタイムサーバが「対称アクティブモード：Symmetric Active Mode」の時刻同期要求を受け付けない場合に発生する。 この場合の問題を解決するには、次のコマンドを実行して、Windows Time Serviceが「クライアントモード：Client Mode」で 要求を送信するように設定する。
/manualpeerlistの第2パラメータ値に「0x8」を指定する。ちなみに上記の値は以下のレジストリ値に記録される。 KEY_LOCAL_MACHINEのSYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer デフォルト：time.windows.com,0x1 ●/manualpeerlistの第2パラメータ値
|
||||||||||||
| 分類 | FAQ | |||||
| ネットワーク | WindowsNT Server4.0のドメインコントローラにWindows Timeサービスを導入する | |||||
| 説明 | ||||||
| Windows2000以降のWindowsでは、Windows Timeサービス（W32time）により、NTPおよびSNTPベースでドメイン全体の時刻が同期される。Windows
Server2003およびWindows2000 ServerのドメインコントローラのWindows
Timeサービスは、外部のタイムソースと時刻同期が行われると、自身がSNTPサーバとして動作し、時刻同期機能を提供できるようになる。Active DirectoryクライアントはドメインコントローラとSNTPで時刻同期を行うので、ドメインコントローラの時刻を外部のタイムサーバと同期させておけば、ドメイン全体の時刻が同期されることになる。ちなみに、Active
Directoryドメインで時刻同期が要求されるのは、デフォルトの認証プロトコルである「Kerberos」が、認証チケットの生成プロセスの一部としてクライアントの時刻を使用するからである。 Windows TimeサービスはWindows2000以降で搭載されたもので、当然、WindowsNT Server4.0には存在しない。したがって、WindowsNT 4.0ドメインに参加するWindowsXP/2000クライアントのWindows Timeサービスはドメインコントローラと時刻同期ができずに、イベントＩＤ「64」の警告イペントを発生させる。Windows NT4.0ドメインは時刻同期を必要としないため、若干のトラフィックの増加のほかには時刻同期が行われなくても実害はない。もちろん、時刻同期のために「NET TIME \\コンピュータ名 /SET /YES」を実行するのもよい方法であるが、Windows Timeサービスによる時刻同期ではないため、当エラーが記録されなくなるということはない。このエラーを回避する方法の1つは、WindowsXP/2000クライアントのWindows Timeサービスのスタートアップを無効にすることである。エラーを回避するもう1つの方法は、WindowsNT4.0のドメインコントローラ（PDCおよびBDC）にWindows Timeサービスを導入することである。（マイクロソフトFTPサーバにて提供あり） WindowsNT4.0用のWindows Timeサービスは、次の手順でインストールする。 ①「W32Time.exe」及び「W32time.ini」ファイルをダウンロードする。 ②ダウンロードした「W32time.exe」を「C:\WINNT\System32」フォルダに、「W32time.ini」を「C:\WINNT」にコピーする。 ③「C:\WINNT\W32time.ini」をを「メモ帳」などのテキストエディタで開く。「NTServer=」の行に外部のタイムソースを指定し、「LocalNTP=no」の記述を「LocalNTP=yes」に 変更してから上書き保存する。 ④コマンドプロンプトを起動し、「C:\WINNT\System32」フォルダに移動してから、次のコマンドラインを実行する。
最初のコマンドにより、Windows TimeサービスがWindowsNTサービスとして追加され、スタートアップが「自動」に設定される。2番目のコマンドにより、Windows Time サービスが開始される。 なお、このあとに「W32time.ini」ファイルを変更した場合は、次のコマンドラインを実行して、設定の変更をレジストリに反映させる必要がある。
⑤以上の設定によりWindowsNT 4.0ドメインコントローラがNTP/SNTP対応のタイムサーバとして動作するようになる。あとは、WindowsXP/2000クライアントで次のコマンド ラインを実行して、タイムサーバをWindows NT4.0ドメインコントローラに設定する。
WindowsNT 4.0ドメンコントローラとの時刻同期が正しく行われることをすぐに確認したい場合は、コマンドプロンプトで次のコマンドラインを実行する。
このコマンドラインにより、すぐに時刻同期を開始させることができる。「コマンドは正しく完了しました」と表示されれば問題ない。 なお、ＷｉｎｄｏｗｓＮＴ4．0リソースキットに含まれる「TimeServ」ユーティリティがインストールされている場合は、Windows Timeサービスをインストールする前に 削除しておく必要がある。削除するには、次のコマンドラインを実行する。
|
||||||
| 分類 | FAQ | |||||
| ネットワーク | トラブル時はDNSを疑う | |||||
| 説明 | ||||||
| ActiveDirectoryではドメイン関連機能の名前解決に、NTドメインで用いていたNetBIOS名解決ではなく、DNSによるホスト名解決を基本的に採用している。そのため、ActiveDirectoryではDNSに障害が出ると多くの主要機能に影響する場合がある。例えば、ActiveDirectoryドメイン内のコンピュータは、認証などを行うドメイン・コントローラ（DC）という役割のマシンがどれかという情報をDNSサーバーにアクセスして得る。また、DCはアカウント情報の複製などで他のDCと接続する場合、DNSサーバーから接続先DCのサーバー名を取得する。DNSはサーバー関係の管理ツールを実行する際にも利用される。こうした機能が正常に動作しなかったり、処理に時間がかかったりするときは、DNSサーバーやDNS関係の設定に問題がないか調べる。 トラブル時にまず点検するのはDNSサーバーのレコード情報である。ActiveDirectoryのDNSサーバーはホスト名からIPアドレスを解決するAレコードに加え、SRVレコードと呼ばれる拡張レコードを利用する。SRVレコードはDCの提供するサービスを示すとともに、サービスを提供するホスト名の名前解決を実現している。 １．DNSサーバのSRVレコードを調査 従って、ActiveDirectoryを正常に動作させるには、DNSサーバーにDCのAレコードおよびSRVレコードが正しく登録されている必要がある。DNSのレコードは標準添付のDNS管理ツールで調べる。ActiveDirectoryドメイン名（例：microsoft.local）の下の「_msdcs」のツリーの下部にDCのSRVレコードがあるかがとりわけ重要である。DCのSRVレコードがないときは登録が必要になる。SRVレコードは複雑な構成になっている。そのため、ActiveDirectoryでは、ダイナミックDNSと呼ばれるレコードの動的更新の機能を利用し、コンピュータの起動時に自動的に登録することが基本である。まず、ActiveDirectory用の全DNSサーバーで動的更新機能が有効であることを確認する。Windows Server添付のDNSサーバーならDNS管理ツールでゾーンのプロパティを開いて確認できる。［動的更新］の欄を［なし］以外にする必要がある。次にDNSクライアント機能で動的更新が有効か調べる。DCとなっているサーバーのTCP/IPプロトコルのプロパティ画面から［詳細設定］ボタンを押して開く画面の［DNS］タブを表示させる。そこで ①［DNSサーバーアドレス］にActiveDirectory用のDNSサーバーのIPアドレスが登録されている ②［この接続のアドレスをDNSに登録する］が有効である の2つを確認する。クライアントPCやメンバー・サーバーで「グループ・ポリシーが適用されない」「ドメインへのログオンが遅い」などの現象が発生する場合も同様にそれらのコンピュータが参照するDNSサーバーの設定を確認する。特にActiveDirectory用のDNSサーバーを新規導入した場合は、クライアント側のDNSサーバーの設定が古いものになっていることが多い。ドメインのクライアントPCやメンバー・サーバーも、ActiveDirectoryドメインへログオンする際、DCの一覧をDNSサーバーから受け取りドメインのログオンなどを行う。このためWindows 2000 Professional以降のクライアントは、参照するDNSサーバーとしてActiveDirectory用のものを指定する必要がある。クライアントPCでは，優先DNSサーバーのIPアドレスをDHCP（動的ホスト構成プロトコル）で設定することもよく行われる。その場合は、DHCPサーバーの設定を確認する。ただし、PCのユーザーが手動で優先DNSを設定すると、そちらが有効になる。DHCP環境でも、その点を考慮しておきたい。注意したいのは、ブロードキャストやLMHOSTSなどでNetBIOS名解決が可能だと、ドメインへの参加やログオンができてしまうことである。ただし、アクセス許可の設定などでドメイン・ユーザーの検索操作を行うと、DNSによるLDAPサーバー情報の取得が必要となり、エラーになる。ちなみにLMHOSTSを利用したログオンでは、DNSの問い合わせがタイムアウトするのを待つため、非常に時間がかかることが多い。 ２．複数DNSの設定では使用順に注意 TCP/IPのプロパティでは、DNSサーバーが使用順に複数設定できる。この順序にも注意する。DNSでは最初に参照したDNSサーバーから必要な情報が取得できないと、すぐ問い合わせを終了してしまう。次のDNSサーバーに問い合わせるのは、最初のDNSサーバーが停止中などまったく応答がない場合だけである。このため社内にインターネット用DNSサーバーとＡActiveDirectoryのDNSサーバーが併設されている場合は、［優先DNSサーバー］としてActiveDirectoryのDNSサーバーのIPアドレスを指定する。クライアントPCにActiveDirectoryのDNSとインターネットのDNSの両方を参照させたい場合は、DNSサーバー側の設定を変更して対応する方法がある。ActiveDirectoryのDNSサーバーで「フォワーダ」を有効にした上、インターネットDNSのIPアドレスを設定する。 ●DNS管理ツールで見たDNSサーバーのフォワーダ設定 クライアントにActiveDirectoryのDNSとインターネットのDNSの両方にアクセスさせるときは、ActiveDirectoryのDNSサーバーでフォワードの設定を有効にして、インターネットのDNSサーバーへ名前解決要求を転送する方法がある。
これによりActiveDirectory用DNSで解決できない問い合わせがインターネット用DNSに転送され、クライアントからは両方のDNSサーバーのレコードを参照可能になる。 |
||||||
| 分類 | FAQ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ネットワーク | ActiveDirectory用のDNSサーバを構成する | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 20040805 ActiveDirectoryドメインを構築するにはDNS（ドメイン・ネーム・システム）サーバーが不可欠である。そのため、DNSサーバーが全くない環境では、ドメイン・コントローラ（DC）という役割のマシンにDNSサーバーが自動構成される。しかし、自動構成はしばしば不適切な設定を行う。例えば、フォワーダが適切に設定されなかったり、独自のルートゾーンが自動作成されたりする。さらに、自動構成に頼っているとトラブルシューティングの知識が身に付かないという問題もある。そこで，ActiveDirectoryがどのようにDNSを使用しているのかを解説し、自動構成に頼らずにActiveDirectory用DNSサーバーを構築する方法を紹介する。 １．AD用のDNSにはSRVレコードが必須 ActiveDirectoryドメインでDNSが必須なのは、DCの発見にDNSを利用するためである。 ●ActiveDirectoryではドメインコントローラをDNSで発見する ActiveDirectoryのクライアントコンピュータは基本的にドメイン名の情報しか持っておらず、DNSサーバーからドメイン・コントローラ（DC）名を入手する必要がある。複数のDCがあるときには、このほか各種の処理が行われて1台が選定される。
クライアントはドメイン名をもとに，DNSの情報からDC名を入手してそこにアクセスし、認証などのサービスを受けている。ActiveDirectoryドメインには、example.comのようにDNSのドメイン名が付けられており、それが利用される。しかし、ActiveDirectoryのDNSではドメイン名に対して単純にDCの情報を割り当てて利用するような方法は採用していない。これは次のような事情があるためである。例えばexample.comドメインのDCとしてdc1.example.com（IPアドレス：192.168.1.1）とdc2.example.com（IPアドレス：192.168.2.1）の2台がある場合を考える。仮にexample.comドメインに対するAレコードとして192.168.1.1と192.168.2.1の2つのホストを登録すればどうなるだろうか。確かにこうすればドメイン名からDCを発見できる。実際、WindowsNTドメインでは、この方法でWindows独自のNetBIOS名解決を行わずにDCを発見可能である。しかし「ドメイン名として登録されたすべてのAレコードがDCである」という制約は一般に強すぎる。例えば、Webサーバーをドメイン名として登録したいことはよくある。現実にも、Webブラウザで「http://www.yahoo.com/」の代わりに「http://yahoo.com/」を指定しても正しくアクセスできるのは、yahoo.comというドメイン名に対してWebサーバーがAレコードとして登録されているためである。 そこで考案されたのがDNSのSRVレコードである。SRVはServiceの略で、サービスを提供するプロトコル、ポート番号、そしてサーバーを登録するための標準規格である。SRVレコードを使うことで提供しているサービスを区別したサーバーの情報がDNSに格納できるようになる。これを応用してDCのサービスが稼働するコンピュータの情報をDNSに格納すれば、WebサーバーなどDC以外のレコードがドメイン名に対応して登録できなくなるような制約はなくなる。SRVレコードの一般形を以下表に示す。 ●SRVレコードの一般形 SRVレコードでプロトコルを意味する名前には例外的に「_」（アンダースコア）を使うことに決まっている。
・優先順位の高い（値の小さい）ホストがあれば、それを優先的に使う。 ・同じ優先順位のホストが複数あれば、重み付けを行う。 ・重さがゼロの場合はラウンド・ロビンを行う。 ・1以上の重さがある場合は、比例配分した確率で選択する。例えば、ホストAの重さが100、ホストBの重さが300の場合、ホストAの選択確率は 100÷（100＋300）＝25%となる。 SRVレコードを「DNS管理ツール」 - 「サービスロケーション(SRV)」で表示すると、サービス名：「_ldap」、トランスポートプロトコル「_tcp」、優先順位「0」などが設定されている。 通常DNSのレコード名には「_」（アンダースコア）は含まれないが、SRVレコードでプロトコルを示す名前には例外的に「_」を使うよう決められた。ActiveDirectoryでは、すべてのDCがLDAPサーバーであることを利用して、_ldap._tcpという名前のレコードによりDCを登録する。従って、ActiveDirectoryを構成するには、SRVレコードをサポートするDNSサーバーが必須である。BINDをはじめとする最新のDNSサーバー・ソフトはSRVレコードをサポートするが、マイクロソフトがActiveDirectoryでの運用を保証しているのはWindows 2000 Server以降に付属するDNSサーバーと、BIND8.1.2以降である。ただし、これだけではDCが複数ある場合、クライアントと高速に通信できるDCが発見されるとは限らない。DNSサーバーの「ネットマスクの順序」という機能を使えば、同一サブネットのDNSサーバーを優先的に使うことは可能だろう。しかし、異なるサブネットにDCがあるときは困る。一般にサブネットの情報だけでは、どのDCと高速に通信できるかは判断できない。 ●DNSの情報だけでは詳しいネットワーク構成は分からない LAN間ルーターを経由するサブネットBの方が高速だが，従来のDNSから得られる情報だけでは、WAN経由のサブネットCと通信速度を比較できない。
また、ネットマスクの順序はAレコードのみで有効である。IPアドレスが直接登録されるのはAレコードだけだからである。そこでActiveDirectoryでは「サイト」という管理単位が追加された。サイトは、1つ以上のサブネットの集合であり、高速に通信できる範囲を1つにまとめる。具体的には、クライアントと同じ、または最も近くのサブネットにあるDCを優先的に使うようにサイトを構成する。サイト情報もDNSに登録されるが（DNS管理画面の、左ペイン「_sites」の部分）、どのサイトがどのサブネットに所属するのかはLDAPを使ってDCに問い合わせる（このときの問い合わせ先は全DCからランダムに選択される）。なお、実際には、ActiveDirectoryに、ドメイン名と同じ名前のAレコードとして全DCのIPアドレスが登録される。これは、ActiveDirectoryではなく、サードパーティー製のソフトウエアの便宜を図るためである。しかし，前述のように問題があり、あまり使われていないようである。 ２．ADのDNSでは動的更新を全面的に利用 以上のようにActiveDirectory用のDNSには、DCに関するSRVレコードやサイトの情報が登録される。ただし、それをDCの追加・削除およびサイト構成の変更のたびに修正する必要があり、手作業では管理者の負担が大きい。できればNTのドメイン並みに簡単にしたいところである。この要望にこたえるため、ActiveDirectoryでは「DNSの動的更新」機能を全面的に利用する。動的更新を行うDNSのことを「ダイナミックDNS」と呼ぶ。DNS動的更新は標準規格であり、BINDなどでも利用できる。Windows ServerのDNSで、動的更新を有効にするにはゾーンのプロパティを変更すればよい（DNS管理画面の「ゾーン」のプロパティの「全般タブ」）。動的更新を有効にすると、DNSリゾルバ（DNSクライアント）が自分のAレコードをDNSサーバーに登録できるほか、任意のサービスが任意のレコードを登録可能になる。ActiveDirectoryではNETLOGONサービスがSRVレコードを登録する。 動的更新で注意したいのはセキュリティである。DNS管理画面の「ゾーン」のプロパティの「全般タブ」では、動的更新の実行モードとしてセキュリティ［なし］と［非セキュリティ保護およびセキュリティ保護］が選択できる。後者は実質的に非セキュリティ保護の状態で、［なし］と同様にだれでも自由にそのゾーンにレコードを登録可能である。そのため、「WWW」のような信頼されやすいサーバーの名前が勝手に登録される恐れがある。不正なレコードの登録を防ぐには「セキュリティ保護のみ」更新の機能を利用する。この方法では、ActiveDirectoryによる認証に成功したホストだけが動的更新を利用できるように構成できる。DNSゾーンを後述する「ActiveDirectory統合」に変更することで利用可能である。何らかの事情で動的更新を設定しない場合は%WINDir%\system32\configフォルダのnetlogon.dnsファイルを参照し、DNSレコードを手動で登録する（%WINDir%はWindowsのインストール先）。ActiveDirectoryの操作の結果として登録されるSRVレコードを完全に把握するのは難しい。SRVレコードはDCの追加のほか、サイトの状態を変更した場合にも変化するからである。netlogon.dnsファイルは動的更新の有無にかかわらず必要なSRVレコードを自動的に登録する。そのため、netlogon.dnsファイルを参照すれば設定の漏れがなく安心である。なお、BINDでは動的更新要求を受け入れるホストをIPアドレスの範囲で制限できるほか、デジタル証明書を使った認証が利用できる。残念ながらBINDが使うデジタル証明書認証はWindowsのDNSでは使えない。相互運用を実現することは検討されているようなので、今後に期待したいところである。 ３．ゾーンをADデータベースに記録するActiveDirectory統合ゾーン 前述のように「ActiveDirectory統合」に構成したDNSのゾーンは「ActiveDirectory統合ゾーン」と呼ばれる。この仕組みでは、DNS情報がゾーン・ファイルではなく、ActiveDirectoryデータベースに格納される。ActiveDirectoryデータベースがあるのはDCだけなので、ActiveDirectory統合ゾーンのDNSサーバーはDC上で構成する必要がある。ActiveDirectory統合ゾーンには以下の利点がある。 ・DNS情報の複製が、アカウントなどドメイン情報の複製と一体化し、ゾーン転送トラフィックを節約できる。 ・ドメイン情報と一体化してマルチマスター複製が行われるため、任意のDNSサーバーでレコード更新が可能である。 ・DNSのレコードの更新にActiveDirectoryの認証を使うセキュリティ保護を設定できる。 ActiveDirectory統合ゾーンを作成するには、DC上でゾーンを作成する時に[ActiveDirectoryにゾーンを格納する］を選ぶ。既存のゾーンをActiveDirectory統合ゾーンに変更するには、ゾーンのプロパティで［種類］の［変更］ボタンをクリックし［ActiveDirectoryにゾーンを格納する］を選択すればよい。ActiveDirectory統合ゾーンになると、前述の動的更新の実行モードも増えて［セキュリティ保護のみ］が利用可能になる。不正なDNS更新を避けるためにも、動的更新では［セキュリティ保護のみ］を設定すべきである。さらに、ActiveDirectory統合ゾーンでは各レコード単位でセキュリティが設定可能になる。ただし、これは作業が繁雑なためほとんど使うことはないだろう。 ４．使い方次第でBINDとの共存は可能 多くの会社にはActiveDirectory用のDNSサーバーを構築する前からUNIXなどによるDNSサーバーがあるだろう。ActiveDirectoryの管理者にとって、DNSの構築以上に悩むのは既存のDNSとの共存ではないだろうか。 ①DNS管理者がWindows嫌いでWindowsのDNSサーバーの使用を禁止された。 ②既存のDNSサーバーの設定を変更したくない。 ③DNSの管理をしたことがないので不安。 ①は，偏見も含まれているため完全な解決は難しい。しかし、「委任」機能を使い、②と合わせて解決できる可能性があ る。以下に一般的なガイドラインを示す。 ・ActiveDirectoryドメインの直下にあるサブドメイン_msdcsを別ゾーンとして構成する。 ・_msdcsをActiveDirectory統合ゾーンとして構成する。 ・_msdcsにセキュリティで保護された動的更新を許可する。 例えば、example.comというActiveDirectoryドメインであれば、以下の手順でゾーンを分離するとよい。 ①_msdcs.examlpe.comドメインを新規のActiveDirectory統合ゾーンとして作成する。 ②_msdcs.example.comゾーンに［セキュリティ保護］動的更新を許可する。 ③example.comゾーンに含まれる_msdcs.example.comドメインを削除する。 ④管理ツール［サービス］を使って、NETLOGONサービスを再起動する。 ⑤_msdcs.example.comゾーンに新しいレコードが登録されていることを確認する。 ⑥example.comドメインの動的更新を禁止する。 example.comドメインで動的更新が有効になっていない場合は、_msdcsドメインが登録されていないので、③のステップは不要である。example.comドメインがBINDで構成されている場合でも手順は同じである。このように、_msdcsゾーンを分離することで（既存のDNS管理者にとっては）以下のメリットが得られる。 ・既存のゾーンで動的更新を許可しない。 ・既存のゾーンにSRVレコードを登録しない。 実は、_msdcsゾーン以外のSRVレコードはActiveDirectoryでは使っていない。サード・パーティ製アプリケーションの便宜を考えて作成されるだけである。そのため、_msdcs以外のSRVレコードがなくてもActiveDirectoryの動作に支障はない。なお，古いBINDではWindowsのDNSサーバーとの相互運用に問題があるケースもあった。古いBINDにはセキュリティ・ホールも多く見つかっているので、この機会に最新版にしてほしい。なお、Windowsの開発チームが相互運用をテストしたBINDのバージョンは4.9.7、8.1.2、8.2、9.1.0である。 ５．DNSは「ネットマスクの順序」と「ラウンド・ロビン」で負荷分散 WindowsのDNSサーバには、負荷分散を行うための機能として、「ネットマスクの順序」と「ラウンド・ロビン」という機能が備わっている。いずれも標準的なDNSサーバの機能であり、デフォルトで有効になっている（サーバオプションの「ラウンドロビンを有効にする」「ネットマスクの順序を有効にする」）。「ネットマスクの順序」は、DNSクライアントと同一サブネットのレコードを優先的に（先頭のレコードとして）返す機能である、これにより、クライアントと高速に通信できるサーバを優先的に利用可能にできる。ただし、ネットワークのトポロジー全体を考慮するわけではないので、同一ネットワークとそれ以外の区別しかできない。 「ラウンドロビン」は、問い合わせの答えとして複数のレコードが存在する場合、各レコードの並び順を順繰りに変える機能である。SRVレコードのように重み付けされていないレコード、例えばAレコードやNSレコードが示すサーバの負荷分散に役立つ。Webサーバでこのラウンド・ロビンを使うと、クライアントはWebサーバのIPアドレスを順繰りに得るので、複数のWebサーバが均等に使われることが期待できる。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ |
| ネットワーク | NetBIOSアプリケーションを、TCP/IP以外のプロトコルでも利用できるよう設定を行う |
| 説明 | |
| 参考）WIndowsネットワークの変遷 Windowsでは同じNetBIOSアプリケーションに対して複数のプロトコルが自由に使える。現在ではTCP/IPが主流だが、ほかのプロトコルを優先的に利用するように設定することも可能である。現実にはTCP/IPのみを使い、他のプロトコルは一切使わないことを推奨するが、そうできないケースもなかには存在する。利用するプロトコルの優先順位は、以下のような手順で変更できる。 ①スタートメニューのコントロールパネルから「ネットワーク接続」を開く ②ウインドウの「詳細設定」メニューから「詳細設定」を選択 ③「アダプタとバインド」タブを選択 ④上下の矢印ボタンを使って、ネットワークインターフェイスごとにプロトコルの優先順位を設定する |
|
| 分類 | FAQ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ネットワーク | Windowsネットワークの変遷 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 説明 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| １．Windowsネットワークの元祖 - MS NETWORKS マイクロソフトのビジネスは、IBM-PC用の「PC-DOS」より始まった。ネットワーク機能については、MS-DOS 3.xと、その上で動作した「MS-NETWORKS」が始まりとなる。例えば、MS-DOS 3.xから「SHARE.EXE」というコマンドが追加されている。これは主に、ネットワークで共有されたファイルの排他制御を実現するために実装されたものである。 また、MS-NETWORKSが利用されていた当時は、SCSIカードやビデオカードなど、拡張カード上に搭載されたBIOSを呼び出して様々な機能を利用するのが、ごく一般的に行われていた。MS-NETWORKSでも、NIC上のBIOSを呼び出すことで、ネットワーク機能を利用していた。この、NICに搭載されたBIOSは「NetBIOS」と呼ばれており、そのプロトコル階層は以下の通りである。 ●MS-NETWORKS当時のプロトコル階層の変遷
ただし、BIOSの規格は各社各様で、プログラムの互換性はほとんどない。このためMS-NETWORKSはかなり使いにくいシステムであった。 ２．NetBEUIの誕生 そこで、ユーザが利用しやすいものにするため、BIOSの機能をハードウェアからソフトウェアに移行された、こうして生まれたのが、NetBEUIである（上図参照）。NetBEUIは、NetBIOSを拡張し、開発者（ユーザ）が容易にプログラムからBIOSを利用できるインターフェースを提供した。しかし、NICはベンダーごとに様々なものが存在するため、NIC用のデバイスドライバを呼び出す標準仕様が提案された。これがNDISである。NICベンダーがNDISに従ったドライバを提供することで、NetBEUIという共通のインターフェースを利用できるようになった。その後NIC上のBIOSは徐々に縮小され、最終的に各NIC用のデバイスドライバと統合された。現在はBIOSを持つNICは皆無と言っていい。NDISはMS-DOS時代に生まれた規格だが、現在のWindowsでもその名残がある。それが32ビット版のNDIS（NDIS.SYS）である。 ３．プロトコルの誕生 本来、NetBEUIはプログラムインターフェースである。そのため、実際にアプリケーションを使って通信を行なう場合は、プロトコルを決める必要がある。そこで、NetBEUIの開発にあわせて「NBF（NetBEUI Frame Protocol、NetBIOS Frame Protocol）」が生まれた。現在では、プログラムインターフェースの名称に「NetBIOS」を使い、プロトコルは「NetBEUI」と呼ばれることが多いが、本来はどちらもプログラムインターフェースである。プロトコルを指すときは「NBF」と呼ぶべきである（なお、NBFはWIndowsXPからサポートされなくなっている）。NBFはインターネット僧のプロトコルで、データの伝送はEthernetなどの下位層に依存する。ただし、IPのような中継機能は持たない。NBFの開発当時は、PCのネットワークで中継を必要とすることが想像できなかったものと思われる。しかし、PCの能力やネットワークに必要な要件が変化してくると、NBF以外のプロトコルを実装せざるおえなくなる。そこでマイクロソフトは、NBFのほかにノベルのNwtWareで使われていた「IPX」やTCP/IPを簡単にサポートする仕組みを考えた。幸い、これはNICとのインターフェースはNDISを使うことで容易に実現できる。こうして、複数のネットワークプロトコルをサポートする仕組みが出来上がった（ちなみに、WindowsNT3.1用には、Digital Equipment(DEC)からDECnetプロトコルが配布されていた）。 ●NDISにより複数のプロトコルを同時にサポートする
実は、NDISの本来の目的は、このように複数のプロトコルを同時にサポートするためであった（なお、NDISと同様のことはノベルでも考案されており、ODI（Open DataLink INterface）というインターフェースが発表されている）。 ４．プロトコルの選択 上図をもう一度参照いただきたい。この図では、アプリケーションごとにプロトコルが用意されている。たとえばWebブラウザにはTCP/IPが、NetWareクライアントにはIPXが必須である（現在のNetWareはIPXを必要とせず、TCP/IPから利用できる）。しかし、プロトコルを意識することなくアプリケーションを使えたほうが便利である。マイクロソフトが開発したプロトコルはNBFであるが、先に説明した通り中継機能がない貧弱なものである。一方、当時のＰＣネットワークではIPXが広く普及していたが、UNIXではTCP/IPが主流であった。さらにIBMに代表される汎用機は、また別のプロトコルを使っていた。当時、TCP/IPは「信頼性が低く、エンタープライズネットワークには適していない」と本気で主張する人も多く、単一のプロトコルしか使えないアプリケーションは生き残れない可能性があった。そこでマイクロソフトが考えた解決策は、新しいプログラムインターフェイスの導入であった。「TDI（Transport Driver Interface）」と呼ばれるこの機能は、WindowsNT3.1以降で利用されている。 ●Windows NT3.1以降に登場したTDI
実際には、アプリケーションが直接TDIとやり取りするわけではない。TCP/IPなら「ソケット」と呼ばれるプログラムインターフェイスを使い、ソケットがTDIとやり取りする。ソケットを使うTCP/IPアプリケーションは、複数のプロトコルをサポートできない。しかし、TDIを経由すればプロトコルに依存せずにアプリケーションが利用できる。NetBIOSのインターフェイスも、ソケットと同様にプロトコルの種類に関係なくアプリケーションが利用できる仕組みである。しかし、NetBIOSやNBFには、中継の概念がない。それどころか「ネットワークアドレス」の概念すらない。あまりに単純なので、アプリケーションはプロトコル固有のパラメータはいっさい必要ない。そこで、マイクロソフトはNetBIOSインターフェイスをTDIに対応させ、TCP/IPやIPXを使って通信できるようにした。これが「NetBIOS over TCP/IP」や「NetBIOS over IPX」と呼ばれるものである。 ５．TCP/IPへの集約 NetBIOSの仕組みは非常にうまく動作した。WindowsNT 3.1では、デフォルトで利用するプロトコルはNetBEUI（NBF）であったが、Windows NT3.5ではIPXに変わる。そして、WindowsNT4.0からはTCP/IPとなった。このようにデフォルトで利用するプロトコルは次々変わっても、アプリケーションの互換性は保たれている。TCP/IPがないと、IEやOutLookExpressは動作しない。しかしファイル共有やプリンタ共有はTCP/IP以外のNetBEUIやIPXなど、お互いに共通のプロトコルが1つでもあれば問題なく通信できる。ただし、この方法にも問題はある。それは通信の効率である。NetBIOSアプリケーションは、通信を開始するときクライアントで利用可能なすべてのプロトコルを使って通信を開始する。サーバは、そのうち最初に受け取った「理解可能な」プロトコルで応答し、クライアントはその応答を使って通信を継続する。そのため、余計なパケットがネットワーク上に流れる。もちろん、複数のプロトコルをサポートすることで余分なメモリも消費する。また、1995年前後のインターネットブームから、TCP/IPがその後の主流となることは確実になった。もはや「信頼性が低い」などという人はいない。そこで、マイクロソフトはWindows2000で大きな方針変更を行なった。NetBIOSをやめ、標準のプロトコルをTCP/IPに絞ることにした。一般にTCP/IPアプリケーションは、ソケットと呼ばれるプログラムインターフェイスを使う。Windows版のソケットは「Windowsソケット」または「WinSock」と呼ばれる。もちろん、従来のNetBIOSを捨てたわけではない。ソフトウェアの寿命はハードウェアと比べ非常に長いため、そう簡単に切り替えられない。しかしWindowsの今後の方針としては、NetBIOSではなくTCP/IPを用いると考えられる。 ６．ファイルとプリンタの共有 こうしたマイクロソフトの方針の影響をもっとも強く受けてきたのが「ファイルとプリンタの共有」である。詳細は以下章で解説するとして、どのような変化があったのかを簡単に紹介する。同時に、現在でも残る混乱の種も紹介する（その他、マイクロソフトはWindowsのDNSサーバにも拡張機能を搭載し、これらの混乱を最小限にとどめようと努力している）。まず1つが、コンピュータの識別方法である。Windows2000より前では、コンピュー タの識別に「NetBIOS名」と呼ばれるコンピュータ名を指定する。NetBIOS名は15文字以内の文字列で、湊字や多くの記号が使える。Windows2000以降でもNetBIOS名は使えるが、デフォルトではTCP/IP標準の「ホスト名」を使う。ホスト名は、周知の通り階層構造を持っており、たとえば「cl01.microsoft.co.jp」のように英数字とハイフンを使った63文字以内（複数の階層で255文字以内）の文字列である。WindowsNTやWindows9Xでは、ホスト名とNetBIOS名に別の名前を付けることが可能なので、1台のＰＣが2つの名前を持つことによる混乱が生じていた。そこでWindows2000以降のコンピュータ名は、特別な設定を行なわない限り英数字とハイフンを使い、NetBIOS名の制約である「15文字以内」のホスト名に限られることとなった。つまり、Windowsネットワークにおけるコンピュータ名の制限事項は、ホスト名とNetBIOS名の折衷案ということである。こうしたコンピュータ名の変化に伴い、名前解決の方法にも変化があった。NetBIOS名はブロードキャストを使って名前解決を行なう。また、WINSと呼ばれるサーバ機能を使うこともできる。一方のホスト名は、ご存じのDNSを使って名前解決を行なう。 ●コンピュータ名の検索手順
Windows2000以降は、ホスト名の検索に失敗すると自動的にNetBIOS名を使った検索に移行するようになった。その逆も行なわれる。そのため、ホスト名の検索にWINSを使うこともできるし、NetBIOS名の検索にDNSを使うこともできる。しかし、DNSとWINSで一方に設定ミスがあっても、他方の力を借りて解決してしまうことがあるためトラブルの原因がつかみにくいという問題がある。 このほかにも、ファイルとプリンタの共有では、Windowsネットワークの歴史的な経緯によって、その仕組みが複雑になってしまっている部分がある。以下で、ファイルやプリンタ共有の設定を見ながら、実際に行なわれている通信手順について見ていく。 ７．共有で使うＳＭＢ Windowsネットワークでファイルやプリンタの共有を行なうには、SMB（Service Message Block）と呼ばれるプロトコルを利用する。SMBは、先にしたNetBIOSインターフェイスをセッション層として使うプロトコルで、サーバ側のモジュールである「サーバサービス」と、クライアント用の「ワークステーションサービス」によって動作する。 ●ファイル共有のプロトコル階層
SMBはWindows固有のプロトコルであるが、他のOSでも利用できる。たとえば「Samba」は、LinuxなどのUNIX系OSで動作するSMB対応のファイルサーバソフトである。Sambaを使えば、WindowsやMacintoshなどの他のOSからもファイル共有ができる。SMBは、利用するポートによって大きく2種類に分かれる。TCPのポート139番を使う場合と、ポート445番を使うものである。445/TCPを使う方法を「ダイレクトホスティングSMB（CIFS：Common Internet File System）」と呼ぶが、これが使えるのはWindows2000以降のOSに限られる（CIFSはSMBをベースにインターネットとの親和性を高めたプロトコルであるが、ダイレクトホスティングSMBと同じものと考えてもよい）。ここでは、139番を使う場合の共有の動作について見ていく。 SMBによる通信は、正確には「NetBIOSセッションサービス」と呼ばれる。これが、先に説明した139/TCPを使ったファイル共有で利用する通信である（正確にはWindowsにはファイル共有の機能はない。搭載されているのはフォルダ共有の機能である。）。SMBでは、それ以外のポートも使う。NetBIOSセッションサービスを行なう前に、137/UDPまたは137/TCPを使ってNetBIOS名の名前解決（NetBIOS名解決）を行なう。NetBIOS名解決とは、実際の通信（NetBIOSセッションサービス）を行なうための宛先となるマシンを検索するためのものである。NetBIOS名は16文字の文字列で表わされるが、実際にユーザーが使えるのは15文字までである。15文字の「NetBIOS名」はWINSやブロードキャストを使って名前解決を行なう。一方、最後の1文字はサービスの種類を示すために自動的に付けられる値で、これは「NetBIOSサフィックス」と呼ばれる。たとえば「0」であればワークステーションサービス、「1」であればマスタブラウザといった具合に、NetBIOSサフィックスを使って各マシンの機能を識別する（マスターブラウザーとは、「マイネットワーク」で表示されるコンピュータの一覧情報を保持するマシンのこと）。SMBを使った通信では、こうした仕組みを使うことでNetBIOS名解決を行ない、サーバサービスが動作している通信相手を見つけた後に実際の共有を行なう。なお、ダイレクトホスティングSMBでは、NetBIOS名解決の代わりにDNSを使ってホスト名解決を行なう。NetBIOS名解決を行なわず、相手のIPアドレスを指定して直接通信を行なうことからダイレクトホスティングSMBという名称で呼ばれている。 ８．ユーザー認証 共有されたファイルやプリンタへアクセスする場合、こうした名前解決とともに必要となるのが「ユーザー認証」である。認証は、アクセスしたユーザーが正当な権限を持つかを判断するために必要となるもので、環境の違いによって3つの方法がある。まず1つ目が、ActiveDirectoryを使った環境である。この場合、ドメインコントローラで認証されたクライアントのユーザー情報が、そのままサーバで利用される。一方、ワークグループ環境では、ファイルやプリンタのサーバ側に搭載されたOSのバージョンによって動作が異なる。サーバがWindowsXPの場合は（どちらか一方、または両方のコンピュータがワークグループで後世された場合。または信頼関係のない異なるActiveDirectoryフォレスト間で通信する場合も含む）、他のコンピュータからのアクセスはつねにGuestとして識別される。一方、サーバがWindows2000以前であれば、以下図のような手順でユーザー認証が発生する。 ●Windows2000以前のユーザ認証の流れ
ただし、WindowsXPの認証方法は、管理ツールの「ローカルセキュリティポリシー」を使って変更できる。「ローカルポリシー」の「セキュリティオプション」にある「ネットワークアクセス：ローカルアカウントの共有とセキュリティモデル」をダブルクリックすると、「ネットワークアクセス：ローカルアカウントの共有とセキュリティモデル」画面が表示される。デフォルトでは「Guestのみ」となっているが、ここで「クラシック」を選択すると、Windows2000以前と同様の認証方式が利用される。 ９．NetBIOSとセキュリティ こうした共有の仕組みを利用するうえでもう1つ忘れてはならないのが、セキュリティの問題である。これは、SMBがNetBIOSをベースにしていることに起因する。先に紹介した通り、NetBIOSはネットワークプログラムのインターフェイスであり、共有機能以外でも利用できるからである。セキュリティ上、もっとも考慮すべきなのは、Windowsに搭載されているリモート管理機能である。リモート管理では、NetBIOSを利用している。そのため、SMBが利用できる環境ではリモート管理も可能になる。もちろんユーザー認証が必要になるため、管理者のユーザー名とパスワードがわからなければ勝手に操作されてしまうことはない。しかし、適切なパスワード管理が行なわれていない場合も多いので、十分に注意しなければならない。また、意図せずに共有しているファイルにアクセスされることも、情報の流出につながる。こうしたことから、現在市販されているほとんどのブロードバンドルータは、デフォルトでNetBIOSが利用するポートの通過を禁止している。そのため、インターネットからNetBIOSを使ってアクセスされることはない。しかし、古い機器ではダイレクトホスティングSMBが使う445/TCPを禁止していない場合もある。Windows2000以前に発売された機器を使っているユーザーは、必ず設定を見直すこと。また、LAN内の通信にも注意が必要である。同じセグメント内の通信はルータを通らないので、NetBIOSが自由に使える。Windowsファイアウォールなどを適切に使うことで、こうした問題を回避することができる。 10．共有の手順 それでは実際に共有を行なう手順について見ていく。とはいっても、非常に簡単な手順で利用できる。Windows2000／XP（「簡易共有機能」をオフにしている場合）でファイル共有を行なうには、エクスプローラで共有したいフォルダのプロパティから「共有」タブを選択する。ここで「このフォルダを共有する」を選び、共有名や一度にアクセスできるユーザー数を入力すればよい。また「アクセス許可」ボタンをクリックすると、共有へのアクセス許可（または拒否）を設定できる。このアクセス許可の設定は、SMBのサーバサービスで参照される。またファイルシステムがNTFSの場合、ファイルやフォルダに対してNTFSアクセス許可による詳細なセキュリティ設定も指定できる。共有のアクセス許可では「フルコントロール」「変更」「読み取り」の3種類だが、NTFSアクセス許可では、これらに加えて「読み取りと実行」や「書き込み」といった細かな設定が可能である。NTFSアクセス許可を設定するには、エクスプローラでファイルやフォルダのプロパティを表示し「セキュリティ」タブを選ぶ。NTFSアクセス許可と共有アクセス許可の両方が設定されている場合、まず共有アクセス許可が検査される。そして共有アクセス許可をパスした場合、次にNTFSアクセス許可が検査されるといった流れである。これで必要な権限があれば、共有フォルダにアクセスしたユーザーはローカルにあるのと同じようにファイルを利用できる。また、プリンタ共有もファイル共有とは同じ手順で行なえる。「プリンタとFAX」フォルダでプリンタを右クリックして「共有」を選択し、「このプリンタを共有する」を選択すればよい。また、必要に応じてドライバをサーバ上に組み込めば、各クライアントでドライバの設定が不要になります。Windowsで共有プリンタを利用する場合、PRINT$という共有フォルダが自動的に作成され、プリンタドライバはそこから自動的にダウンロードされる（Windows Server 2003やWindowsXPなどのWindowsNT系OSでも、Windows95/98/Me用のプリンタドライバを組み込むことができる。ただし、対応するOS[Windows98など]のCD-ROMが別途必要になる）。「$」で終わる共有名は一覧表示されないが、クライアントは共有名がわかっていれば「プリンタの追加」ウイザードで必要なプリンタを利用できる（WindowsNTでは「プリンタの追加」ではなく「プリンタの作成」という用語が使われていた。Windowsでは「ソフトウェア的な印刷システム」のことを「プリンタ」と呼ぶ。なお、用紙サイズを定義することは今でも「新しい用紙を作成する」という）。 11．その他のNetBIOSアプリケーション 最後に、共有以外の目的で利用されているNetBIOSアプリケーションについても紹介しておく。あまり知られてないが、WindowsXPには「チャット（WinChat）」と呼ばれる機能が搭載されている。WinChatは、テキストベースのリアルタイム通信プログラムである。チャット用のプログラムといえばMSNメッセンジャーやYahoo!メッセンジャーが有名だが、WinChatがこうしたアプリケーションと異なるのは、サーバをいっさい使わずピアツーピアで通信を行なうということである。WinChatは、「NetworkDDE」と「NetworkDDE DSDM（NetworkDDE管理サービス）」と呼ばれる2つのサービスを利用する。DDEとは「Dynamic Data Exchange」の略で、Windows3.1時代に開発されたデータ交換用の機能である（DDEはその後、OLE[Object Linking and Embedded]の機能として発展した。）。NetworkDDEはDDEをネットワーク対応にしたものである。現在ではNetworkDDEを使うプログラムはほとんどないため、WindowsXP以降で無効になっている（WinChat以外に現在でも利用できるNetBIOSアプリケーションとしては、クリップボードの内容を複数保存し、それをネットワークで共有するクリップブック機能がある。WinChatと同様、NetworkDDEを使ったアプリケーションだが、追加のサービスとして「ClipBook」が必要である）。そこでWinChatを使う際には、NetworkDDEとNetworkDDE DSDMのサービスの設定を行なう必要がある。具体的には、管理ツールの「サービス」でこれらを選択し、「スタートアップの種類」を「手動」に変更しておく。ここで「自動」にする必要はない。手動に設定しておけば、WinChatが実行されると必要なサービスが起動する。この状態で、コマンドプロンプトで「WinChat」コマンドを実行すればWinChatが起動できる。あとはツールバーにある「ダイヤル」アイコンをクリックし、呼び出すコンピュータを選択する。呼び出された側は自動的にWinChatが起動し、ツールバーにある「受話器を上げる」アイコンをクリックすればチャットが開始できる。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 分類 | FAQ |
| セキュリティ | ファイルやフォルダのプロパティにて「セキュリティ」タブを表示させる |
| 説明 | |
| WindowsXPのデフォルト設定ではファイルやフォルダのプロパティを開いても、「セキュリティ」タブが表示されないので、アクセス権を変更したり確認したりすることができない。 「セキュリティ」タブを表示させて、ファイルやフォルダのアクセス権を確認できるようにするには以下手順を行う。 （１）ファイルエクスプローラを起動し、「ツール」 - 「フォルダオプション」を選択。 （２）「フォルダオプション」の表示タブを選択 （３）「詳細設定」リストから、以下の設定を行う。 ・「簡易ファイルの共有を使用する」のチェックを外す （４）「適用」をクリックし、「すべてのフォルダに適用」をクリックする。 設定が完了したら、任意のフォルダを右クリックしてプロパティを開く。新たに「セキュリティ」タブが追加されていることを確認する。 |
|
| 分類 | FAQ |
| セキュリティ | MBSAでWindowsセキュリティをチェックする |
| 説明 | |
| Microsoft Baseline Security Analyzer（以下MBSA）は、簡単なGUI操作でWindowsのセキュリティをチェックするユーティリティである。2004年5月12日に正式版としてリリースされた（MBSA本体は、ベータ版と同じプログラムが使われており、使用するデータベースが正式版として更新された。したがって、ベータ版を使用していたユーザはインターネットに接続可能な状態でMBSAを通常起動するだけで、自動的に正式版にアップデートできる）。 MBSAのインストールと実行はWindows2000以降が必要だが、スキャン対象のリモートコンピュータにはWindowsNT 4.0 SP4以降も含まれている。MBSAはGUIモードとコマンドモードの２つの実行モードがある。「Mbsacli.exe」を使ってMBSAをコマンドモードで起動し、リモートコンピュータを定期的にスキャンするタスクを設定すれば、セキュリティチェックの自動化が可能になる。複数のコンピュータをほぼ同時並行でスキャンできるので、スキャン時間は１台のチェックとあまり変わらない。２つのモードはどちらでも、次のコンポーネントのセキュリティをローカルまたはリモートでチェックできる。 ・WindowsNT 4.0、Windows2000/XP、Windows Server2003 ・インターネットインフォメーションサービス（IIS） ・Internet Explorer ・Microsoft仮想マシン（Java仮想マシン） ・Windows Media Player ・Office ・Microsoft SQL Server Desktop Engine（MSDE） ・Microsoft Data Access Components（MDSC） ・MSXML ・各種サーバ製品（SQL Server、Exchange Server、BiZTalk Server、Commerce Server、Content Management Server、Host Integration Server） デフォルトのオプションでスキャンを実行すると、最初にマイクロソフトのWebサイトからHTTPプロトコルを通じて「Mssecure_<バージョン番号>.cab」ファイルをダウンロードし、インストールフォルダに「Mssecure.xml」データベースファイルを展開する。続いてスキャン対象のコンピュータから適用済みの修正プログラムを検索して、データベースと照合し、未適用の修正プログラムをレポートとして報告する。このとき、次の３つのケースのいずれかに含まれる古い修正プログラムは未適用とみなされない。 ・更新された修正プログラム ・累積的な修正プログラム ・適用済みのService pack 逆に、データベースに登録された修正プログラムより新しい修正プログラムが適用されていると、「ファイルバージョンは予期されたより新しいバージョンです」として、レポートに含まれてしまうので、修正プログラムを漏れなく適用していても、「セキュリティの評価結果」は「リスク大」と評価されることもある。 「スキャンする単一のコンピュータの選択」では、コンピュータ名、またはIPアドレスを指定して、1台のPCをチェックする。デフォルトではMBSAを実行しているPCが選択され、スキャンが終了すると自動的にレポートが表示され、不合格が出た項目は「結果の詳細情報」「修正方法」をクリックして、不合格になった理由や修正方法などの情報を見ることができる。 「スキャンする複数のコンピュータの選択」では、NTドメイン名やActive Directoryドメイン名、またはIPアドレスの範囲を指定してネットワーク経由で1万台以内のPCを同時にチェックできる。スキャンは並列に実行されるので、スキャン完了までの時間は1台のPCをチェックするより若干長い程度である。スキャンが完了すると、同じように「セキュリティレポート」が表示される。 また、「mbsacli」コマンドを使用し、定型のセキュリティチェックをバッチ処理で実行することも可能である。さらに、「mbsacli /hf」コマンドを実行すると、「HFNetChk」の旧バージョンと同じことができる。 MBSA1.2の新機能として、「Software Update Service（SUS）」への対応が挙げられる。スキャン時に、「SUSサーバを使用する」チェックボックスをオンにすると、ダウンロードした「Mssecure.xml」データベースファイルではなく、SUSサーバで適用を許可した修正プログラムの一覧（Approvediterms.txt）を参照してスキャンが実行される。 SUSサーバオプションを使用すると、先の３つのケースに該当するかどうかにかかわらず、許可済みで未適用の修正プログラムがすべてレポートに表示される。この動作はSUSを利用した修正プログラムの適用漏れをチェックするのに適しているが、別の修正プログラムやService Packの適用で修正済みの項目であってもスキャンするたびに表示されるので、システム管理者は「結果の詳細情報」をクリックして、レポートを精査しなければならない。もちろん修正済みであれば、改めて古い修正プログラムを適用する必要はない。 |
|
| 分類 | FAQ | |
| パフォーマンス | Windows2000にて、システム再起動後もパフォーマンスログの収集を継続させたい | |
| 説明 | ||
| Windows 2000では、パフォーマンスモニタが「パフォーマンス
ログと警告」というMMCのスナップイン化され、インタフェースが大きく変わっている。WindowsNTにおける「パフォーマンス
ログと警告」同様の機能を実現するには、作成したカウンタログのプロパティにある「スケジュール」タブに開始時刻や終了時刻を指定することで、自動実行や停止が可能となっている。 ただし、ここで設定を行なっても、マシンの再起動を行なってしまうと、ログの収集が継続されない。再起動後に自動的にログの収集を開始させるには、「Performance Logs and Alerts」サービスの起動を「自動」に設定した上で、「スケジュール」タブの画面で、ログの停止をデフォルトの「手動」以外にしておく必要がある。「手動」のままだと再起動後にログの収集が継続されないので注意する。 しかし、上記手順にて一応自動実行が可能となるが、OS標準のタスク機能が使えず、定期的な実行もできないので、定常的な運用で利用することを考えると、使い勝手がよいとは言えない。 Windows 2000 Serverのリソースキットにはperfmon4.exeという名称でWindows NT 4.0互換のパフォーマンスモニタが収録されているので、これとWindows NT Server 4.0のリソースキットに収録されているmonitor.exeやdatalog.exeと組み合わせることで、Windows NT Server 4.0と同様の方法でパフォーマンスモニタの制御を行なうことも可能である。 この機能を利用するには、Windows NT Server 4.0のリソースキットに含まれているmonitor.exeとdatalog.exeをあらかじめ、Windows 2000マシンの「%SystemRoot%\System32」にコピーしておく必要がある。その上でperfmon4.exeを起動して、[View]-[Log]メニューから、取得するオブジェクトの種類やログファイルの出力場所、間隔などを設定した上で、最後に[File]-[Save Workspace As]のメニューから、pmwファイルを「%Systemroot\System32」に保存する（ここでは仮にtest.pmwという名称で保存したとする）。 最後に「> monitor setup」コマンドを発行することで、「monitor service」というサービスが登録され、monitor.exeによるパフォーマンスモニタの制御が可能になる。なお「Failed to create service ***」というメッセージが出力されるが、実際には、monitor serviceというサービスが作成されているので問題ない。 この状態で、「> monitor test.pmw」コマンドを発行して、先ほど作成したpmwファイルを関連づける。これにより、「> monitor start」と「> monitor stop」コマンドでパフォーマンスモニタの制御が可能になる。後はタスクなどを使って、このコマンドを適宜実行するようにする。
Windows XP/.NET Serverでは、こうした問題点を踏まえて、新しくlogmanというコマンドが追加されている。当コマンドにより、Windows 2000以降のパフォーマンスモニタの機能をコマンドラインから細かく制御できるので、これとタスク機能を組み合わせることで、きめ細かいパフォーマンスログの取得が可能になっている。 |
||
| 分類 | FAQ | |||||||||||||||||||||||||||||
| デバイス | 32ビットWindows環境のメモリー構成（20050508） | |||||||||||||||||||||||||||||
| 説明 | ||||||||||||||||||||||||||||||
| 32ビット・プロセッサが利用可能なメモリー空間は最大4GBである（参考：64ビット・コンピューティング）。 このメモリー空間を、WindowsXPやWindows Server 2003では通常、カーネルとユーザ・プロセスにそれぞれ2GBずつ割り振っている。 ●32ビットWindows環境のメモリー構成
大容量のデータベースなどで、より広いユーザ・メモリー空間を使いたい場合は、boot.iniファイルの記述に「/3G」オプションを追加すれば3GBに拡張することができる。しかし、この場合は、標準で2GBだったカーネルのメモリー空間が1GBに縮小されてしまう。その影響でシステムのページ・テーブル・エントリの数が減少し、I/O負荷が増加してしまうとエラーが発生することがある。 このような現象に悩んでいるユーザは、EM64T対応のシステムへの移行を検討すべきである。EM64T対応Xeonを搭載するWindowsサーバで動作する32ビット・アプリケーションでは、ユーザ・メモリー空間が最大4Gバイトまで拡大されるようになる。EM64T対応Xeon上で64ビットWindowsを使って、IA-32eモード（互換モード）を利用すると、カーネルが32ビットの4Gバイトを超えた空間上で動作し、4Gバイトの空間すべてをユーザ・メモリー領域として使えるようになる。同時に、カーネルが利用するメモリー空間についての制限もなくなる。このため、高負荷のExchangeサーバなどが遭遇する「システムリソースが不足しているため、要求されたサービスを完了できません」という問題は、64ビット対応Windowsを利用することで解決できる。 |
||||||||||||||||||||||||||||||
| 分類 | FAQ | ||
| 問題判別 | ハードウェアの故障の結果、システムエラーメッセージが表示される | ||
| 説明 | |||
| Microsoft文書番号：315223／対象：WindowsXPファミリー ハードウェア故障やデバイスドライバーに問題が発生すると、WindowsXPは次のエラーメッセージを表示して、起動プロセスを停止することがある。
以下に４つのチェック項目と解決方法を示す １．メモリーモジュールのチェック 筐体を開けて、メモリーモジュールの取り付け不良やメモリチップの表面的な損傷をチェックする。また、動作クロックなどが必要スペックに適合しない メモリーモジュールを交換する。メモリーチップの内部的な損傷や正常な読み書きをチェックするには、「Windowsメモリ診断」ユーティリティを使用する。 ２．BIOSのチェック BIOS設定が、システム構成に適していることを確認する。また更新されたBIOSを入手してアップデートする。システム構成ユーティリティを使用して、システム構成 情報をハードディスクや不揮発メモリに保存するタイプのコンピュータでは、システム構成ユーティリティを再実行して構成情報を更新する。 ３．デバイスドライバの更新 問題が修正されたデバイスドライバがリリースされていれば、デバイスドライバをアップデートする。 実際のトラブルシューティングでは、上記に加え、ケーブル類の取り付けを確認したり、電源やＣＰＵの冷却ファンの回転確認したりする作業等も発生する。もちろんハードディスクなどのドライブ類が正常に動作することもチェックしなければならない。とはいえ、ケーブルやファン、ハードディスクのトラブルであれば、冒頭で紹介したメッセージ以外のメッセージが表示されたり、メッセージすら表示されないケースがほとんどなので、当節では、考慮対象外とする。 上記「１」にある「WIndowsメモリ診断」ユーティリティは、「Microsoftオンラインクラッシュダンプ解析サービス」の補助ツールとして提供されている。正式な名前は「Microsoft Windows Memory Diagnostic」である。「Windowsメモリ診断のダウンロード」を行い、「Mtinst.exe」をファイルを任意のフォルダに保存し、以下の手順を実行することで、ユーティリティをフロッピーディスクにインストールできる。なお、当フロッピーへインストールする作業は、メモリをチェックするＰＣではなく、正常に動作しているWIndows98/Me/2000/XP/2003上で実行する。Windows95/NTでは対応していない。 １．フォーマット済みのフロッピーディスクをドライブにセットする ２．ファイルエクスプローラで「Mtinst.exe」ファイルをダブルクリックして起動する ３．ライセンス条件に同意したら、「Accept」をクリックする。 ４．「Create Startup Disk」をクリックする ５．起動ディスクを作成するドライブを選択する ６．「Cancel」を２回クリックしてインストーラを終了する。 なお、手順４で「Save CD Image to Disk」を選択すると、任意のフォルダにユーティリティのISO 9660イメージファイルを作成できる。別途用意したCD-RライティングソフトでISOイメージをCD-Rに書き込むことで、フロッピーディスクのないＰＣでも「WIndowsメモリー診断」ユーティリティを実行できる。 作成したフロッピーディスクやCDをドライブにセットして、PCを起動すると、自動的に「WIndowsメモリ診断」ユーティリティが起動して、即座にメモリテストが開始される。ユーティリティが起動しない場合は、BIOSの設定で、フロッピーディスクドライブやCD-ROMドライブを優先起動デバイスに指定する。 「Windowsメモリ診断」ユーティリティのデフォルトのテストは「Standard tests」で、６個のテスト項目をユーザーが終了させるまで繰り返し実行する。実行中に「T」キーを押すと「Extended tests」に切り替わり、より詳細な１１個のテスト項目を実行する。「T」はトグルスイッチになっていて、キーを押すたびに「Standard tests」と「Extended tests」が切り替わるが、それまで実行していたテストは途中でキャンセルされてしまうので注意が必要である。
テスト項目の編集画面では、「Avaiable Tests」ウィンドゥにフォーカスがある場合は上下のカーソルキーでテスト項目を選択して、右カーソルキーで「Standard test」に項目を移動することで、テスト項目を追加できる。「Tab」キーを押して、フォーカスを「Selected Test」に移動し、左カーソルキーを押して、項目を削除することもできる。全てのテストを実行して、最終的に画面下部のメッセージ欄に「No errors have been found.」と表示されれば、メモリーモジュールに問題はなかったことになる。ただし、ECCメモリーを搭載したコンピュータでは、軽微なエラーが自動修正されている可能性があるので、ECC機能をオンにした状態とオフにした状態の両方でテストする必要がある。 メモリーモジュールは、SIMMやDIMMが多く利用されているが、複数のメモリモジュールをインストールして問題が見つかった場合は、いったｎ全て取り外し、１枚ずつインストールしてチェックする。 |
|||
| 分類 | FAQ | |
| 問題判別 | タスクスケジューラの実行ログの最大サイズを増やす | |
| 説明 | ||
タスクスケジューラ（スケジュールされたタスク）の実行ログは、
に記録される。これらのログファイルは、「タスク」フォルダの「詳細設定」メニュー -> 「ログの表示」でも確認できる。ログファイルサイズの上限は32KBに設定されており、超過すると新しいログを記録するために、古いログ行が削除されて上書きされる。 ログの最大サイズは、次のようにレジストリを編集することで調整できる。 １．レジストリエディタを起動し、次のレジストリキーを開く。 HKEY_LOCAL_MACHINE\Software\Microsoft\SchedulingAgent ２．当キーの下にある「MaxLogSizeKB」という値エントリが、ログの最大サイズを示している。最大サイズを変更したい場合は、この値エントリを開き、KB単位で入力する。 |
||
| 分類 | FAQ |
| 問題判別 | メモリーダンプを取得する |
| 説明 | |
| 参考） ・Dumpchk.exe を使用してメモリ ダンプ ファイルを確認する方法 ・Dumpchk.exe を使用してメモリ ダンプ ファイルをチェックする方法 ・Windows XP でメモリ ダンプ後に情報を収集する方法 WindowsXPにて、PCクラッシュ時にメモリーダンプを出力する設定にしておくと、以下システムイベントメッセージとともに「C:\WINDOWS\Minidump」以下にダンプファイルを出力する。 「このコンピュータはバグチェック後、再起動されました。バグチェック: 0x10000050 (0xe57ab000, 0x00000000, 0x805b2822, 0x00000001) ダンプが保存されました: C:\WINDOWS\Minidump\MiniXXXXXX-XX.dmp」 ダンプファイルの出力設定は、「コントロールパネル」の「システム」をダブルクリックし、「詳細設定」タブで、「起動と回復」欄の「設定」ボタンを押下する。「デバッグ情報の書き込み」の下の欄にて、プルダウンより「最小メモリ ダンプ」（Minidump）を選択すればよい。 ちなみに、「最小メモリ ダンプ (64 KB)」では次の情報が記録される。 ・STOP メッセージとパラメータ、およびその他のデータ ・ロードされているドライバのリスト ・停止したプロセッサのプロセッサ コンテキスト (PRCB) ・停止したプロセスのプロセス情報とカーネル コンテキスト (EPROCESS) ・停止したスレッドのプロセス情報とカーネル コンテキスト (ETHREAD) ・停止したスレッドのカーネル モードの呼び出し履歴 「カーネル メモリ ダンプ」は、カーネル メモリだけを記録する。なお、未割り当てメモリやユーザー モードに割り当てられたメモリは含まれない。ダンプファイルは 50 MB から 800 MBとなる。「完全メモリ ダンプ」ではクラッシュ時のシステム メモリの全内容を記録する。完全メモリ ダンプは 2 GB に制限される。 解析方法については、上述リンクを参考にされたい。 |
|
| 分類 | FAQ |
| 問題判別 | ブルースクリーン（Windows STOPエラー）の原因を解析する |
| 説明 | |
| WindowsNT系列の場合、画面に残されたメッセージを解読することでブルースクリーンの原因を突き止めることができる。また、OSのクラッシュダンプを採取できるため、これをもとにエラーの詳細を知ることもできる。 以下に、ブルースクリーンを意図的に発生させ、その原因を解析する手順をシミュレートする方法を記す。 １．ブルースクリーン（Windows STOPエラー）を意図的に発生させる ブルースクリーンは、カーネル空間内において何らかの原因で障害が発生した際に表示される画面である。以下に意図的にブルースクリーンを発生させる方法を記述する。なお、本手順は以下の条件を満たしている環境でのみ有効である。 ・Windows2000/XP以上 ・PS/2のキーボードのみ（USBは不可） ①レジストリエディタを起動する。「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters」キーに、新規でDWORD値で「CrashOnCtrlScroll」、その値を「1」として追加する。ちなみに、「i8042prt」はPS/2のキーボードとマウスを制御するIntel8042ポートドライバのことである。 ②レジストリエディタを終了して、マシンを再起動する。 ③再起動後、成功すれば、[右Ctrl]キーを押しながら[ScrollLock]キーを2回押すことで、ブルースクリーンを意図的に起こすことができる。 ２．ブルースクリーン（Windows STOPエラー）発生時、自動的にマシンが再起動されないようにする ブルースクリーンを発生する作業は終了したが、デフォルトでは自動的に再起動するように設定されているので、画面に表示されたメッセージを読み取ることができない。そこで、自動的に再起動しないように設定しておく。 ①「コントロールパネル」内の「システム」をダブルクリックする。 ②「システムのプロパティ」が表示されるので、「詳細」タブ - 「起動/回復」ボタンを押下する。 ③「起動/回復」ウィンドウが表示されたら、「システムエラー」部分の「自動的に再起動する」のチェックボックスのチェックをはずす。そして、「システムログにイベントを書き込む」（後でこのイベントを表示する方法を言及する）と「管理警告を送信する」のチェックボックスにチェックを入れておく。 ④設定後、[OK]ボタンを押下する。再起動を促されるので、再起動しておく。 ３．STOPエラーコードを確認する これで準備がでたので、[右Ctrl]キーを押しながら[ScrollLock]キーを2回押して、ブルースクリーンを意図的に発生される。このとき表示されるメッセージは次のようになっているはずである。 ----- *** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000) The end-user manually generated the crach dump. Beginning dump of physical memory Physical memory dump complete. Contact your system administrator or thechnical support group. ----- 1行目に着目する。 ----- 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000) ----- この英数字列（0xとなっているので16進数表示）がブルースクリーンが発生した原因を突き止めるヒントとなるわけである。この英数字が何を意味しているかは、MicrosoftのWebサイトで配布されているDDK（Driver Development Kit）というデバイスドライバ開発キットをインストールして、「DDK Documentation」というヘルプファイルを参照することで分かる(*1)。 <現在サービス停止> DDKのトップページ：http://www.microsoft.com/japan/whdc/ddk/winddk.mspx FAQ：http://www.microsoft.com/japan/whdc/ddk/ddkfaq.mspx 上述URIから、DDKをダウンロードして、インストールするのだが、現在ではダウンロードできない。Windows2000用のDDKはServer 2003 DDKのCD-ROMに含まれます。このCD-ROM自体は無料だが、送料で25$かかる。 現在は、「Debugging Tools for Windows」というツールの中に「DDK Documentation」が含まれているので、これを次のURIからダウンロードする。 http://www.microsoft.com/japan/whdc/devtools/debugging/default.mspx http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx WindowsNTの場合は、まず「Install Windows Installer 1.1 (Windows NT 4.0 - x86) 1.4MB」をあらかじめインストールしておく必要がある。Windows2000/XP以上の場合、これを省いてインストールするだけでOKである。 それでは、「Debugging Tools for Windows」のインストールが終わったとして話をすすめる。 ①「スタート」メニュー - 「プログラム」 - 「Debugging Tools for Windows」 - 「Debugging Help」を起動する。 ②「Debugging Tools for Windows」 - 「Bug Checks (Blue Screens)」 - 「Bug Check Code Reference」でバグチェックコードを確認できる。意図的に引き起こしたブルースクリーンのバグチェックコードは、1行目の先頭部分の「0x000000E2」である。この項目は次のようになっている。 ----- Bug Check 0xE2: MANUALLY_INITIATED_CRASH [This is preliminary documentation and subject to change.] The MANUALLY_INITIATED_CRASH bug check has a value of 0x000000E2. This indicates that the user deliberately initiated a crash dump from either the kernel debugger or the keyboard. Parameters None Comments For details on manually-initiated crash dumps, see Forcing a System Crash. ----- つまり、これは「MANUALLY_INITIATED_CRASH」という意味であることが判明する。なぜ、意図的にブルースクリーンを発生する仕組みが存在するのかというと、OSがストールしてしまったときに、メモリダンプを採取して解析できるようにするためである。 ４．メモリダンプを解析する バグチェックコードでブルースクリーンの原因である概要は分かるが、詳細はまだ分からない。そこで「Debugging Tools for Windows」に付属している「Windows Debugger」（WinDdg）を用いて、保存したイベント（ここではクラッシュしたイベントなのでクラッシュダンプと呼ぶこととする）をダンプする。 クラッシュダンプはデフォルトで「%SystemRoot%\Minidump」に保存されているはずである。保存場所を変更するには、前述した「起動/回復」ウィンドウで変更できる。しかし、デフォルトのままでは「デバッグ情報の書き込み」の部分が「最小メモリダンプ（64KB）」になっている。これではダンプ量が少なく、情報量が少ないので、「カーネルメモリダンプ」に変更しておく。「完全メモリダンプ」にすれば全てのメモリのダンプを行えるが、そこまでする必要はめったにないであろう。 参考）メモリーダンプを取得する ただし、HDDの容量は最低限「物理メモリ＋1MB」が必要になる。なぜならば、クラッシュダンプは一旦ページングファイル（「C:\pagefile.sys」に位置する）に採取され、その後OS起動時に指定した保存先にコピーされる仕組みになっているからである。なお、2GB以上のメモリを積んでいるマシンの場合注意すべき点がある。これに関しては次のURIを参考にすること。 http://support.microsoft.com/default.aspx?scid=kb;ja;274598 http://support.microsoft.com/default.aspx?scid=kb;JA;241046 それではデバッガでクラッシュメモリを読み込んでみる。まず、WinDdgを起動する。そして、メニューの「File」 - 「Open Crash Dump」で、「MEMORY.DMP」ファイルを指定する。ここでは意図的に引き起こしたブルースクリーンのクラッシュメモリを使用する。すると、次のように表示されるはずである。 ----- Microsoft (R) Windows Debugger Version 6.3.0011.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [G:\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available ************************************************************************ WARNING: Dump file has inconsistent set-bit count. Data may be missing. ************************************************************************ Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe - Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible Product: WinNt Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0 Debug session time: Fri May 21 13:25:36 2004 System Uptime: 0 days 0:02:38.203 ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe - Loading Kernel Symbols ........................................................................................Page aee4 not present in the dump file. Type ".hh dbgerr004" for details .Page ba44 not present in the dump file. Type ".hh dbgerr004" for details ................................... Loading unloaded module list ....... Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck E2, {0, 0, 0, 0} ***** Kernel symbols are WRONG. Please fix symbols to do analysis. *** ERROR: Module load completed but symbols could not be loaded for i8042prt.sys Probably caused by : i8042prt.sys ( i8042prt+1dc3 ) ←ここに着目。 Followup: MachineOwner ----- 下から3行目の「i8042prt.sys」に着目する。「i8042prt.sys」はキーボードドライバである。つまり、バグチェックコードによる推測、意図的に起こした[右Ctrl]ボタンを押しながら[ScrollLock]キーを2回押したことと合致する。 コマンド入力欄に次のように入力してみる（厳密にはkdモードのとき、入力欄に「!analyze -v」）。これでより詳細な情報をチェックできる。詳細な使い方はヘルプ（英語）を参照すること。 ----- kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* MANUALLY_INITIATED_CRASH (e2) The user manually initiated this crash dump. Arguments: Arg1: 00000000 Arg2: 00000000 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. BUGCHECK_STR: MANUALLY_INITIATED_CRASH DEFAULT_BUCKET_ID: DRIVER_FAULT LAST_CONTROL_TRANSFER: from eb081b38 to eb081dc3 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 80473eac eb081b38 85d26500 85e3d101 00000000 i8042prt+0x1dc3 80473f0c 80469e5a 85c27d08 85d264e0 85e3d102 i8042prt+0x1b38 80473f24 8046fff0 ffdff000 0000000c 00000000 nt!KeSynchronizeExecution+0x15a 8046fd60 00000000 8046fd68 8046fd68 8046fd70 nt!HalPrivateDispatchTable+0xc38 FOLLOWUP_IP: i8042prt+1dc3 eb081dc3 5e pop esi SYMBOL_STACK_INDEX: 0 FOLLOWUP_NAME: MachineOwner SYMBOL_NAME: i8042prt+1dc3 MODULE_NAME: i8042prt IMAGE_NAME: i8042prt.sys DEBUG_FLR_IMAGE_TIMESTAMP: 3e25b9e5 STACK_COMMAND: kb BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner ----- |
|
| 分類 | FAQ |
| 説明 | |
