DHCPの冗長構成を考える～その３～

3件の返信

DHCPサーバーからDNSの動的更新を行う場合考慮しなくてはいけないポイントがあります。

まずは、DNSの動的更新とはどのような動作なのかを理解する必要があります。

以前はDNSのレコードは管理者が登録するものでした。しかし、昨今の環境ではクライアントの名前解決においてもDNSを使用することが一般的になることによって管理者がクライアントのレコードを登録するというのは難しくなってきました。またDHCPを使用している場合動的にIPアドレスが変更されるため尚更難しいということになります。

そこで考え出されたのがDNSの動的更新になります。

まず、クライアントの一般的な動作から考えます。

前提としてTCP/IPの詳細設定において「□この接続のアドレスをDNSに登録する」にチェックが入っていることになります。デフォルトではチェックが入っているので通常は気にしませんね。

tcpip詳細設定

ここで２つのパターンがあります。それは静的IPアドレスと動的IPアドレスの場合です。

静的IPアドレスの場合はクライアントが直接DNSサーバーにAレコードとPTRレコードの登録を行います。

動的IPアドレスの場合（DHCPからIPアドレスを取得した場合）

ここの動作はちょっと解説が必要になります。まず、前提としてDHCPのDNSタブの設定が絡んでくるんです。

DHCP-DNSタブ

デフォルトの状態では「以下の設定に基づいて、DNS動的更新を有効にする」にチェックが入っています。そして「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」にチェックが入っています。

さて、ここでDHCPクライアントから要求～とありますがどういうことかというと、DHCP オプションであるクライアント FQDN オプション (オプション 81) を考慮する必要があるんです。

Windows Server 2003 で DNS 動的更新を構成する方法

以下参考リンクより抜粋～～

このオプションを使用すると、クライアントから FQDN を DHCPREQUEST パケットで DHCP サーバーに送信することができます。これで、クライアントは必要なサービス レベルを DHCP サーバーに通知できます。

FQDN オプションには、次の 6 つのフィールドがあります。

  • Code
    このオプションのコード (81) を指定します。
  • Len
    このオプションの長さ (4 以上) を指定します。
  • Flags
    サービスの種類を指定します。

    • 0
      クライアントが “A” (ホスト) レコードを登録します。
    • 1
      クライアントが DHCP に “A” (ホスト) レコードを登録させます。
    • 3
      クライアントの要求にかかわらず、DHCP が “A” (ホスト) レコードを登録します。
  • RCODE1
    サーバーがクライアントに送信する応答コードを指定します。
  • RCODE2
    RCODE1 の追加記述を指定します。
  • Domain Name
    クライアントの FQDN を指定します。

クライアントがリソース レコードを DNS に登録するよう要求した場合、クライアントは、RFC (Request for Comments) 2136 に従って、動的 UPDATE 要求を生成します。すると、DHCP サーバーが PTR (ポインタ) レコードを登録します。
このオプション 81 が、Windows Server 2003、Microsoft Windows 2000、または Microsoft Windows XP を実行する DHCP が利用できるコンピュータなどの有効な DHCP クライアントによって発行されたものであるとします。この場合、Windows Server 2003 ベースの DHCP サーバーによってオプションが処理および解釈されて、サーバーがクライアントのために更新をどのように開始するかが判断されます。

ここまで～～

ここで重要なのはクライアントからのオプション81のデフォルトはFlagsが0ということです。通常この設定を変えることはありません。

では話は戻って、DHCPサーバーの設定は「DHCPクライアントから要求があったときのみDNSのAレコードおよびPTRレコードを動的に更新する」になっています。そしてクライアントはFlagsが0なのでクライアントが “A” (ホスト) レコードを登録します。

ということで、デフォルトの動作ではクライアントがAレコード、DHCPサーバーがPTRレコードを登録するということになります。

そして、DHCPサーバーの設定を「DNSのAおよびPTRレコードを常に動的に更新する」にチェックを入れると、DHCPサーバーがクライアントのA、PTRレコードを登録するという動作になります。

ここで冗長構成の動作を考えると問題になることがあります。

それは次回に・・・

DHCPの冗長構成を考える～その２～

1件のフィードバック

前回は同一セグメントにDHCPサーバーを複数台おいて冗長構成するお話をしましたが、こんな構成もありますね～

DHCP冗長化1

1台は同一セグメントにDHCPサーバーをたてて、それがダウンしたらリレーエージェントで別セグメントにあるDHCPサーバーに飛ばす方法。別セグメントには元のセグメントと同じアドレス範囲のスコープを設定しておく。クライアントがDHCPに問い合わせする際にアドレス情報を持っているので適切なスコープからアドレスをもらうことができます。

他にはこんな感じ

DHCP冗長化2

クライアントが存在するセグメントにはDHCPサーバーはなく、リレーエージェントを設置するか、ルーターにDHCPパケットを転送させるかしてDHCPサーバーが存在するセグメントにパケットを飛ばす方法。

なんか、こっちのほうがいいかも

そもそも、ネットワーク設計をする際にはセグメントは小さいほうが効率よくネットワークを使用することができます。ですのでL3スイッチを使用して社内ネットワークを分割している企業は多いはず。その際に各セグメントにDHCPサーバーを置くのは大変だし非効率的になります。この構成を使えば複数のセグメントのDHCPとして使用できるし、冗長化にもなる。

ということで、私の考える冗長構成のベストプラクティスは後者になります。

DHCPの冗長構成を考える

1件のフィードバック

さて、かなり枯れた技術としてDHCPサービスがあります。このDHCPサービスですが、私の今までの経験ではDHCPデータベースが壊れるという事態に遭遇したことはありません。かなり安定しているサービスではないでしょうか？

そうはいってもDHCPサーバーを提供しているサーバーがダウンすることはあります。

そのような事態に対応するにはDHCPの冗長構成を考慮する必要があります。

ではDHCPの冗長構成を考える場合どのような構成があるのでしょうか？思い浮かぶ所で３つの方法があります。

  • スコープの分割
  • DHCPのクラスタ構成
  • コールドサーバーの用意

でしょうか？

DHCPのクラスタ構成ですが、コストが高すぎてあまり現実的ではありませんね。そして、コールドサーバーの用意ですが運用中のDHCPサーバーがダウンしたら用意しておいたサーバーにDHCPサービスをインストールして運用する。これはこれでありですが、若干の問題を抱えます。それは今まで配布していたアドレス情報を持っていないのでIPアドレスのバッティングが発生する可能性があるということです。しかし、これはDHCPサーバーの設定画面で「検出の試行回数」の項目を２あたりにすることによって回避は可能になります。

DHCP

この「検出の試行回数」を入力する数字によって、DHCPサーバーがクライアントにIPアドレスをリースする前に、そのアドレスでpingを使用して既存端末が存在するかを確認します。この数字は２を超えない値が推奨されています。

そして最も現実的な冗長構成としてはスコープの分割があります。

これは複数のサーバーをDHCPサーバーとして構成します。その際のスコープ構成として除外範囲を利用します。

DHCP冗長化

アドレス範囲は同じですがそれぞれ除外範囲はことなるのでバッティングすることはありません。

ただし注意点としては予約をしている際にはすべてのDHCPサーバーで同じ設定をする必要があります。

次回はDHCPとDNSとの連携について考えてみます。

DNSのフォワーダ

コメントを残す

DNS設定でフォワーダの構成を行う際の注意点があります。

ではそもそも、フォワーダの動作はどのようになるのか？

フォワーダの仕組み

通常DNSの動作としては、クライアントから再帰クエリとしてDNSサーバーが受け取ります。そして、DNSサーバーは目的のホストが見つかるまで反復クエリを繰り返して、最終的に権限のある応答として目的のホストアドレスを受け取ります。そしてクライアントへの応答してアドレスを返答します。

フォワーダの設定を行うと、DNSがクライアントと同じ動作を行います。よって、クライアントから再帰クエリを受け取り、それを再度DNSサーバーに再帰クエリとして送信します。

これは外部DNSと内部DNSを分離して、内部DNSにフォワーダの設定をするシナリオによく使用されます。

では設定画面を確認します。

フォワーダのプロパティ設定

ここで着目してほしい場所があります。それは「フォワーダが利用可能な場合にルートヒントを使用する」というチェックボックスになります。では、ここで英語版の設定画面を見ます。

フォワーダのプロパティ英語

原文では「Use root hints if no forwarders are available」になっています。

ん！これは・・・本当なら「フォワーダが利用不能な場合にルートヒントを使用する」が正しい翻訳になるぞ

ということで、日本語の意味が全く逆になります。

では、このチェックの利用方法は？

そもそも、これはDNSの排他モードと非排他モードの設定になります。

  • 排他モード
    フォワーダがDNSクエリを解決できない場合、フォワーダーを利用する側のDNSサーバーは元のDNSクエリの発行者にクエリの失敗を返します。その際、DNSサーバーは自分でDNSクエリを解決しようとはしません
  • 非排他モード
    フォワーダがDNSクエリを解決できない場合、フォワーダを利用する側のDNSサーバーがDNSクエリを解決しようとします。

ということで、正しい翻訳を元に考えると「排他モード」はチェックオフで、「非排他モード」はチェックオンになります。

2009年2月4日追記

実機検証した結果、どうやらチェックオンが「排他モード」になりました。ということは英文が間違っているということになるようです。実際には、[Don’t use root hints if no forwarders are available]になり、[フォワーダが利用不能な場合でもルートヒントは使用しない]になりますね～

この結果を踏まえて現在マイクロソフトに問い合わせ中ですので詳細が分かり次第追記します。

2009年2月25日追記

マイクロソフトからの正式回答が来ました。

ここから～

– 動作について

「フォワーダが利用可能な場合にルートヒントを使用する」および、「Use root hints if no forwarders are available」 共にチェックの ON、OFF では下記の動作となります。

※ 結果として、Windows Server 2008 においても、Windows Server 2003 と同様の動作となります。

– チェックが有効 (ON) な場合

フォワーダのみでルートヒントは利用しない (排他モード)

– チェックが無効 (OFF) な場合

フォワーダに問い合わせて応答が無いとルートヒントに問い合わせる (非排他モード)

上記動作について、弊社上位部署に確認させていただきましたところ、今回の現象は、2 重の問題が関係していることが判明致しました。

1. 英語版の UI の表記が実際の動作とは、反対の動作になっている

2. 日本語版の UI の表記が英語版の UI を誤訳している

本件につきましては、上位部署に報告させていただいており、公開情報の作成を検討しております。

しかしながら、現時点では具体的な公開日については、明確となっておらず、公開日についてご案内することができません。

ここまで～

どうやらKB化されるようです。

まとめ

フォワーダの設定を行う場合は、一般的な環境では「フォワーダが利用可能な場合にルートヒントを使用する」チェックボックスをオフ「オン」にする「排他モード」にします。なぜ排他モードにするかというと、フォワーダによるDNSクエリが失敗した際に、フォワーダを利用する側のDNSサーバーが反復クエリを行い「再帰の処理」を実行したところで、結果はフォワーダと同様に失敗すると考えられるからになります。

所属グループを調べる

2件の返信

ユーザーが所属しているグループを調べることがありますが、一般的な方法として「ADユーザーとコンピュータ」スナップインを使用して、対象ユーザーのプロパティから「所属するグループ」をみて確認すると思われます。

しかし、この方法ではビルトインのグループや、ネストして参加しているグループは解りません。

その際に便利なコマンドがあります。

whoami /groups

になります。

このコマンドを使用すると、現在ログインしているユーザーが所属している直接、間接的なグループが表示されます。他にもスイッチがあり意外と便利なコマンドになります。

ただし、テストしてみるとなぜか「Domain Users」は表示されませんでした・・・なぜだろう？仕様かな～

ちなみにXPにはこのコマンドはありません。

デフォルトではWindows Server 2003,2008,Vistaで使えます。

セキュリティの構成ウィザード（SCW）

コメントを残す

セキュリティの構成ウィザード（SCW）の考察

セキュリティの構成ウィザードはWindows Server 2003 SP1より搭載された機能になります。ただしSP1を導入したらすぐに使えるわけではなく自分で追加インストールする必要があることから以外に使われていなかったりするんですよね～

当然、Windows Server 2008にも搭載されています。これはWindows Server 2008をインストールするとすぐに使えます。

このSCWはセキュリティ ポリシーの作成、編集、適用、またはロールバックを表示される手順に従って行うことができます。要するにこのツールの目的は、役割ベースのセキュリティ管理ツールで自動的に使用されていない役割やサービスを無効にしてセキュリティを高めることになります。特徴として、既に50以上の役割があらかじめ用意されていることも利点になります。

Windows Server 2003環境においてのセキュリティ構成を行う場合は、マイクロソフトが用意したセキュリティテンプレートを使うのが一般的になります。これをベースにカスタマイズして使用することにより企業の負担を減らすことが可能になります。SCWではこれらのテンプレートに相当するものがあらかじめ入っているのはいいところですね～

参考

セキュリティの構成ウィザード

実はWindows Server 2003以前の環境において特にスタンドアロン環境では、「セキュリティの構成と分析」スナップインを使用してセキュリティテンプレートを適用させることが推奨されていました。しかし、これには問題があってロールバックができなかったんです。ということは一旦適用させたセキュリティテンプレートは元に戻すことができないということになります。これを元に戻すにはあらかじめNtbackupツールを使用してシステムをバックアップしておき、それを復元するしかありません。

企業においては、カスタマイズしたセキュリティテンプレートを作成したのちテストを繰り返して本番環境に適用させますがこのテストがやりずらかったというのが現状になります。

通常は、ドメイン環境でテストしたのちスタンドアロン環境に適用させるなどの手段を取っていたのではないでしょうか？ドメイン環境ならばGPOのリンクを外すことにより容易にロールバックができるからです。

そこでWindows Server 2003 SP1よりSCWが追加されました。そしてWindows Server 2008でも機能強化されて搭載されています。

Windows Server 2008においては役割に基づいたサーバーマネージャーにより必要なものだけをインストールするのでそもそもSCWを使用する機会は減るかもしれません。ただし、次のようなことを考える管理者にとっては有用なツールになります。

  • セキュリティに関して重要度が高い
    SCWを使用することによって本当に必要な役割と機能を構成することができる
  • さまざまなコンポーネントの関係を理解する
    SCWは役割、機能、サービス、NWポート間の関係が記載されてxmlファイルを吐き出す

またマイクロソフトの動向を探ってみると、SCWに対応したxmlファイルの配布を行っているので、今後はこのSCWが主流になるような気がします（例えばExchange 2007を導入するとExchange2007.xmlが入っている）。

ではGPOを使用してのセキュリティの割り当ては無くなるのか？これはノーです。どちらかというと、棲み分け的にはドメイン環境では相変わらずGPOを使用し、スタンドアロン環境ではSCWという使い方になると思われます。

さて、ここで問題になってくることは今までGPOを使用してベースラインセキュリティを各サーバーに適用させていた企業があります。当然ながらスタンドアロン環境においてもそのベースラインセキュリティを適用させたいと考えます。その場合は該当するセキュリティテンプレートの.infファイルをSCWに取り込むことができます。

その逆はどうでしょうか？

SCWで作成した.xmlファイルをドメイン環境で使用したいという場合はどうするのか？実はこれもできるんです。SCWで作成した.xmlファイルをGPOに変換することが可能です。

scwcmd transform /p:<ポリシーファイル名>.xml /g:<GPOの表示名>

ただし注意しなくてはいけないのが、SCWとセキュリティテンプレートは完全なイコールではないということです。この点は移行時に考慮する必要があります。

セキュリティ設定の優先順位

では２つ一緒に使用した場合にはどうなるのか？これは次のことを覚えておく必要があります。

  • ADベースのGPOはSCWより優先
  • GPO間の優先順位はscwcmdで設定されたポリシーに依存しない。よって今まで通りL-S-D-OUという順番。
  • SCWのxmlとそれに添付したinfは競合の場合SCWのxmlが優先。
  • SCWのxmlに添付した複数のinfは上位に表示されているものが優先。

まとめ

Windows Server 2008になって少々影が薄くなったSCWですが、これを使用することによってかなりセキュアな環境を簡単に作成することができます。特にすごいのは、サービス関連ですかね～。現在使用しているサービスと使用していないサービスをほとんど正確に導き出してくれるのはGoodです。

管理者でセキュリティを重視した管理を行う方はぜひ一度お試しあれ

RODC設計（その前に知っておきたいこと）

コメントを残す

さまざまなHPやブログでRODCのインストール方法などが紹介されていますが、その前に知っておきたいことがあります。それを知っているとなぜRODCをインストールするべきなのかがわかります。また、設計におけるヒントにもなります。

そもそもRODCとは、その役割は？

Windows Server 2008から新しい形態のドメインコントローラーであるRODCがサポートされました。このRODCとは読み取り専用ドメインコントローラーと呼ばれています。

RODCの利用用途としては、セキュリティに不安があるようなブランチオフィスなどに設置するなどとよく言われています。しかし、そもそもなぜRODCという機能ができたのか？を知ることによって設計手法も導き出せると考えます。

では、RODCがなかったころ・・・要するにWindows Server 2003の頃問題となったのはどういうことか？

それは、支社において管理者や、セキュリティ領域（サーバールームなど）がなく運用管理やセキュリティに不安がある場所においても書き込み可能なドメインコントローラー（DC）を置かないといけない場合があった。そうなるとDCにはドメインの資格情報（パスワードなど）が格納されているのでDCのコンピューター自体が盗まれ、解析されてしまうなどのリスクを持つことになります。

この問題を解決するための手段としてRODCが開発されたと考えます。

では、なぜそのような場所にDCを置かなくてはいけないのか？その大きな一つの要因は

  • クライアントユーザーのログイン速度を上げたい

ということになります。

でも支社にDCを置いたからその支社のユーザーはすべてローカルに存在するDCを使ってログインするのか？実はある仕組みが必要になります。それはADのサイトを本社、支社に分け、支社のサイトに支社で使用するDCを配置します。そうすることによって、クライアントはサイトのサブネット設定により自分のサイトのDCを知ることができるのでログイントラフィックの封じ込めが可能になります。しかし、実はこれだけではありません。それは、サイトごとにGCやDNSを置くべきなんです。それはクライアントのログインプロセスに起因します。クライアントはまずDNSのSRVレコードを参照してDCを探します。そしてDCはGCカタログを参照することによってユニバーサルグループに入っているがどうかを確認します。これらのプロセスも同じサイトにないとログイントラフィックの封じ込めが中途半端になります。そしてサイト内のDCからユーザー情報を取得してログインを行います。

ただし、Windows Server 2003以降からはサイトの設定で、ユニバーサルグループメンバーシップのキャッシュをサポートしているので必ずしもGCをサイト内に設置する必要はありません。

RODCの要件とは

RODCを展開するためにはある一定条件が必要になります。それは

  • フォレストの機能レベルが Windows Server 2003以上にする
  • ドメインの機能レベルを Windows Server 2003以上にする
  • 同一ドメイン内に少なくとも一台以上Windows Server 2008が必要

参考

RODC の展開に必要な前提条件

RODCの利点

RODCの管理にはドメインレベルの権限を一切付与せずにRODC用に委任されたローカル管理者を設定することができる。これにより、支社（RODC）のみの管理を任せることができます。

パスワードレプリケーションポリシーを設定することにより、設定された資格情報のみがRODCに配置される。想定されるのは支社のユーザーの資格情報をRODCに配置することによってログオントラフィックを封じ込めができます。よって、RODC自体が盗まれて解析されてもドメイン全体に影響を及ぼすのではなく、その支社の資格情報が危険にさらされるのみとなります。そのような場合は本社側でRODCの資格情報をリセットすれば支社の資格情報も守られることになります。

想定されるRODCの前提とは（まとめ）

RODCは今までDCを配置してログイントラフィックの封じ込めを行っていた場所に対する代替の方法になる。ということは、サイト設計を行いサイトの分離を行う。そして支社のサイトにはDCは置かずに１台のRODCが配置される。またメンバーサーバーもあるかもしれませんね。さらにRODC上にDNSやGCを配置するのは強い推奨となると思われます。ただし、セキュリティを考慮するとGCを配置するよりもユニバーサルグループメンバーシップのキャッシュを設定するほうがよりセキュリティレベルは高くなるでしょう。そうすればRODCが配置されたサイトで、ユーザーがログインしたときのみキャッシュが登録されるからです。

RODCを配置する場合の注意事項

  • サイトにRODCを追加（RODCを複数立てると資格情報の不整合が発生する場合がある）
  • サイトにDCを追加（RODCを導入する意味がない）
  • サイトを作らずにRODCの追加（これも意味がない）

今回は技術的な話というよりは、設計を行う上での考慮点ということになりますね～

GPOの基本設定

1件のフィードバック

Windows Server 2008のGPOを眺めていると「基本設定」という項目があります。

今まではスルーしていたんですが、Windows Server 2008 リソースキット＜グループポリシー編＞を読んでいるとこの話が出ていました。実は私が行っているトレーニングではこの話は一切出てこないのでリソキを読むまで知りませんでした。

ちなみにこのリソキの監修はフィールドSEあがりの安納ですでおなじみの安納さんが行っています。

GPO

この基本設定を設定すればいろんなことができるんだ～なんて思っていましたが、大事な前提があります。それは次の通り。

＜グループポリシーの基本設定のCSE＞

W2008では、グループポリシーに「基本設定」という項目群が新設された。

これらの項目の設定内容を受け取って適用するには、クライアント側コンピュータに「基本設定」用のCSE（client-side extensions）がインストールされている必要がある。

・W2008の場合

「基本設定」用CSEはすでにインストールされている。

・Vista、2003sp1、XPsp2の場合

各OSバージョンごとの「基本設定」用CSEをダウンロードし、別途インストールする必要がある。

ダウンロードサイトは下記。

http://support.microsoft.com/kb/943729/en-us

http://support.microsoft.com/kb/943729/ja

なお、グループポリシーの「基本設定」という項目群の設定が行えるのは

W2008またはRSATをインストールしたVistaSP1の、GPMCのグループポリシー管理エディタである。

参考：Windows Server 2008リソースキット グループポリシー編　p331

ということで、この基本設定の機能を使いたい場合にはクライアント側にCSEをインストールする必要があります。

WINSの罠

コメントを残す

Windows Server 2008にも以前と変わらずにWINSが搭載されています。まあ、役割ではなく機能に入っているのは愛嬌ですけどね（笑）

さて、昔からある資源を活用するために（NTの環境を使う）WINSサーバーを活用する企業もあるでしょう。そこで注意しなくてはいけないことがあります。

Windows Server 2008上でWINSを導入してサーバーの「プロパティ」の「間隔」タブを確認すると以下のようになっています。

wins

ここでWINSの管理をしている方は、ピンとくるかもしれません。

実はTechnetなどで確認するとWindows Server 2008のWINSに関するドキュメントはなくWindows Server 2003のドキュメントにリンクされています。ということは、テクノロジの変化はないということになります。

ここで問題になるのは規定値が想定されているものと異なるということです。

参考

WINS サーバーの既定値を変更する

ここで設定されているのは以下の通り

  • 更新間隔 : 40 分
  • 廃棄期間 : 40 分
  • 廃棄タイムアウト : 1 日

このときの該当するレジストリを見ると、値は、0 となっています。

ただ、プロパティを [OK] で閉じると、相当するレジストリが反映されます。

また、”既定値の戻す” をクリックすると、以下になり、レジストリも反映される。

  • 更新間隔 : 6 日
  • 廃棄期間 : 4 日
  • 廃棄タイムアウト : 6 日

これが本来想定される規定値になります。

さて、ここで疑問になるのが一体どの値が採用されて動作するのかということです。

さすがに解らなかったのでマイククロソフトのサポートに連絡して調べてもらいました。

ということでマイクロソフトからの回答がこちら

– 見解

本現象について、エスカレーション部隊とともに調査しました結果、弊社製品の不具合で発生している現象であることがわかりました。

さらに、初期設定されている、[更新間隔] 等の期間においても実際にメモリ上に存在し、動作に依存する値であることがわかりました。

恐れ入りますが、Windows Server 2008 にて WINS サービスを実行する際にはプロパティ画面より、[既定値に戻す] ボタンをクリックし、Windows Server 2003 と同様の初期値に設定いただきますようお願いいたします。

– ここまで

この数値で運用を行うと、クライアントからのトラフィックが頻発することになりますね～

ということで、Windows Server 2008でWINSを使用する場合は必ず、[既定値に戻す] ボタンをクリックして数値を適切な値にしてから使用することが必要になります。

まあ、次回のサービスパックで直っていると良いですね。

2011年4月18日　追記

残念なことにWindows Server 2008 R2 でも症状は同じでした・・・

Windows回復環境(WindowsRE)に関して

1件のフィードバック

Windows回復環境とは？

Windows回復環境（WindowsRE）とはWindows Server 2008オペレーティングシステムに組み込まれているツールであり、Windows Server 2008を正常に起動できない時にエラーを診断し、エラーから回復できるようにするテクノロジーになります。

しかし通常インストールを行ってもWindows回復環境はインストールされません。

ではこのWindows回復環境を使用するにはどうすればいいのか？2つのパターンが想定されます。

  1. インストールメディアから起動してWindows回復環境を起動する
  2. ハードディスクへのWindows回復環境のインストール

になります。（Windows回復環境＝WinREと表記します）

Windows Server 2008のWinREはWindows Vistaと同じバイナリを使用します。ただし、クライアントモードとサーバーモードがあり、Windows Vistaではクライアントモード、Windows Server 2008ではサーバーモードで動作します。よって、Windows VistaのWinREではOSに問題がある場合、自動的に修復を行いますが、Windows Server 2008のWinREのサーバーモードでは問題を自動的に検出および修正は行いません。ただし、Windows Server 2008のWinREをクライアントモードで動作させることもできます。この場合、WinREがサーバーをさらに破損させることはないと予想されますが、問題を修正できない可能性があります。

Vista Windows RE

Windows Vista（クライアントモード）のWinRE

2008 Windows RE

Windows Server 2008（サーバーモード）のWinRE

ハードディスクへのWinREインストール方法

要件（最低限の要件になります。場合によっては他の用件も出る可能性あり）

  • WinREはOSとは別のパーティションにインストールする必要があります
  • パーティションのサイズは1.5GB以上必要です
  • パーティションはNTFSフォーマットにする必要があります

フェーズ１：WindowsREイメージの作成

Windows 自動インストール キット (Windows AIK)をマイクロソフトのHPより入手する

＊現在はWindows Vista SP1 および Windows Server 2008 用の自動インストール キットが最新となっています。

Windows 自動インストール キット (Windows AIK)のインストールを行う

１．スタートメニュー＞すべてのプログラム＞Microsoft Windows AIK＞Windows PE Tools コマンドプロンプトで、下記を行う。

  1. copype x86 c:winre_x86
  2. imagex /export /boot d:sourcesboot.wim 2 c:winre_x86winre.wim “Windows Recovery Environment”
  3. imagex.exe /mountrw c:winre_x86winre.wim 1 c:winre_x86mount

解説

  1. c:winre_x86 にWindows PE ビルド環境をセットアップしています。
  2. Windows Server 2008インストールメディアに入っているboot.wimよりWinREを取り出しています。
  3. これからカスタマイズするために2で作成したwinre.wimを展開しています。

＊メディアによってはboot.wimの内容が異なっていることがあり、3でwinre.wimを展開してもsourcesなどの他フォルダができないものがあります。筆者はこれではまりました（マイクロソフトのHPで提供されているisoファイルなど）ボリュームライセンスで提供されているメディアでは想定のフォルダができました。

２．下記の内容のテキストファイルを作り、c:winre_x86mountwindowssystem32フォルダに、winpeshl.iniの名前で保存。
[LaunchApp]
AppPath=x:sourcesrecoveryrecenv.exe

解説

WinRE起動時にシステム回復オプション画面が上がる設定を行っている

３．c:winre_x86mountsourcesrecoveryフォルダにToolsサブフォルダを作る。
下記の内容のテキストファイルを作り、このToolsフォルダに、WinREConfig.xmlの名前で保存。
<Recovery>
<Server/>
</Recovery>

解説

WinREをサーバーモードに設定している

参考

Windows RE エクスペリエンスをカスタマイズする

４．Windows PE Tools コマンドプロンプトで、下記を行う。
imagex /unmount /commit c:winre_x86mount

解説

カスタマイズが完了したのでwinre.wimを固めている

５．WinREインストール用のモジュールをWinREフォルダを作りコピーしておく

  • c:winre_x86winre.wim
  • c:program fileswindows aiktoolspetoolsx86bootboot.sdi
  • c:program fileswindows aikrecoverysetautofailover.cmd

６．WinREのブータブルCD作成（※オプション）

  1. copy c:winre_x86winre.wim c:winre_x86isosourcesboot.wim
  2. oscdimg -n -bc:win_x86etfsboot.com c:winre_x86ISO c:winre_x86winre.iso

解説

  1. boot.wimをwinre.wimで上書き
  2. winreのISOイメージを作成

フェーズ２：WindowsREイメージのインストール

DiskPartツールを使用してWindowsREパーティションを作成してからWindows Server 2008をインストールします。Windows Server 2008インストール後にWindowsREのインストールを行います。

Windows Server 2008のインストールメディアより起動し、「コンピュータの修復」から「コマンドプロンプト」をクリックしてコマンドプロンプトウインドウを開きます。

  1. Diskpart
  2. sel disk 0
  3. clean
  4. Create Partition Primary Size=1500
  5. Create Partition Primary
  6. sel part 1
  7. Format FS=NTFS Label=”Recovery” Quick
  8. sel part 2
  9. Format FS=NTFS Label=”Windows” Quick
  10. Active
  11. Exit

パーティションの設定ができたら先ほど作成したWindowsボリュームにWindows Server 2008をインストールします。

７．c:winreフォルダを作り、５で作成した下記の3つのファイルをc:winreフォルダへコピーする。
winre.wim
boot.sdi
setautofailover.cmd

８．D:ドライブにWinREのインストールを行う。

  1. copy c:winrewinre.wim d:
  2. copy c:winreboot.sdi d:
  3. copy c:winresetautofailover.cmd d:
  4. d:setautofailover.cmd /target d: /disk 0 /partition 1 /wim

これでドライブ文字は外されインストール終了

＊マニュアルにはドライブの先頭にWindowsREを入れないといけないと書いてあります。実際にWindowsAIKの初期バージョンでは先頭パーティションにインストールしないと起動しませんでした。そこで試しに最新バージョンのWindowsAIKを使用して後ろのパーティションにWindowsREをインストールしてみました。

d:setautofailover.cmd /target d: /disk 0 /partition 2 /wim

結果から申しますとうまくいきました～

ということは、運用後にWindows回復環境（WindowsRE）を導入することができるということですね。

フェーズ３：エラーから回復できるようにするには

System File Checkerを使用することによりエラーから回復処理を行います。

sfc /scannow
全ての保護されたシステムファイルの整合性をスキャン + 可能な場合には問題のあるファイルを修復

sfc /scanfile
完全パスを指定されたファイルの整合性をスキャン + 問題が識別された場合は修復

sfc /verifyonly
全ての保護されたシステムファイルの整合性をスキャン（修復なし）

sfc /verifyfile
完全パスを指定されたファイルの整合性をスキャン（修復なし）

sfc /offbootdir
オフライン修復の場合は、オフライン起動ディレクトリの場所を指定

sfc /offwindir
オフライン修復の場合は、オフラインWindows ディレクトリの場所を指定

例

  • sfc /verifyonly
  • sfc /verifyonly /offbootdir=c: /offwindir=c:windows
  • sfc /scannow /offbootdir=c: /offwindir=c:windows

このようにWinRE環境上でコマンドを実行することによりエラーからの回復を行います。

余談ですが、この設定ではエラーが出ると自動的にWinREが起動してしまいます。ということは、エラーのダンプなどが取れないということになります。サーバーなどではなぜエラーになったのか？などを追求しなくてはいけない場合がありますが、それができないということになります。はたしてサーバー環境でこのWinREを使うことがいいのか悩むところですね