• [アーティクル]

Microsoft® Systems Management Server 2.0 の復旧計画

最終更新日: 2002 年 4 月 10 日

トピック

はじめに
概要
復旧計画
障害を減少させる戦略の実装
データのバックアップ
復旧
最善のテクニック
標準以下のテクニック
復旧ツール

はじめに

本ガイドは Microsoft® Systems Management Server 2.0 (SMS) の管理者向けに作成されたものです。管理者には SMS データの安全を守り、SMS 操作の使用可能時間を最大化する責任があり、障害発生後の SMS サイトを平常操作に戻す必要があります。

  • 警告
    一般にクライアント/サーバー アプリケーションの復旧および特に SMS 復旧は、通常のアプリケーションやオペレーティング システムでのデータ回復と大変違っていて、はるかに複雑です。本資料の概念と手続きを熟知する必要があります、そうでないと障害を受けたサイトの復旧は成功しません。
    条件が理想的で万全な準備であっても、障害を受けたサイトを復旧する作業は困難で時間を費やし、間違いをおかすきっかけに満ちており、間違いの多くは回復不能な損害を招きかねません。現在ガイドを読んで準備している時間は、後にサイトを障害から復旧させるときに非常に貴重になります。

ページのトップへ

概要

サイト復旧の定義

Systems Management Server (SMS) のサイト復旧は、SMS 階層において使用済みのサイト コードまたはサイト サーバー名をインストールすると発生します。 サイト復旧の中心的なタスクはデータの修復と再同期であり、これは操作中断やデータ破壊を防止するために必要です。シリアル番号の再同期は、サイトの再インストール時の最も重要なタスクです。サイトを再インストールするときには、必ずこの再同期タスクを実行する必要があります。

サイトを再インストールしている場合、再インストールをサイト復旧操作の一環として実行する必要があります。階層内のほかの SMS サイトは、再インストールされたサイトが前と同じ状態になるように期待しています。階層内の操作トラブルを防止するため、再インストールを復旧として処理する必要があります。

  • 注
    これらの復旧要件の無理解や誤解は、サイト復旧失敗の最も一般的な原因です。

概念

SMS 復旧がほかのクライアント/サーバー アプリケーションの復旧と大きく違うのは、次の理由からです。

**分散データ。**SMS サイトの完全なデータ セットはいくつかの違った場所に保存されていて、その一部はサイト サーバー上にありません。完全なデータ セットがないと、完全な復旧は不可能です。

**分散タスク。**SMS はタスクを実行するため複数のプロセス インスタンスを使用し、タスク命令とデータ用に複数の保存場所を使用しますが、これはサイトの障害があると孤立する可能性があります。孤立したデータはサイト障害後に一掃する必要がありますが、それは階層内ではスタンドアロン サイトでより大きな問題になります。ディスク空間の浪費は大きな問題ではありません。障害の程度やバックアップ データの古さによりますが、大きな問題はデータとタスクのバージョンが混合することです。

**非トランザクションベースのタスク。**SMS は一連の操作を確実に完了させるため、トランザクションを使用します。トランザクション完了が失敗すると、SMS は操作を戻します。すべての SMS タスクがトランザクションに基づいているわけではないので、サイト障害後に日常操作を再開するため、一部しか完了しなかったタスクを一掃する必要があります。また非トランザクション タスクは、Backup SMS Site Server タスクでは問題です。バックアップ中はサイトをシャットダウンする必要があります、そうでないとバックアップそのものがリレーショナルな整合性に問題を引き起こします。

**シリアル番号。**SMS は順番に発行されたシリアル番号に基づいて、オブジェクトとタスクを追跡します。バックアップ データは古いので、残りのサイトや階層との同期はずれています。そのためシリアル番号を再同期させる必要があります。スタンド アロンのサイトはクライアントとの関係においてシリアル番号を使用するので、これはスタンド アロンのサイトにも適用されます。コンポーネントによりますが、シリアル番号に問題があると全新規データが拒否されるか、全新規データはオリジナル オブジェクトと競合する複製オブジェクトを作成します。

**サイト操作用の複数アカウント。**シングル アカウントのセキュリティが破られた場合の損失を抑えるため、SMS セキュリティは細分化されています。個々のプロセスは、権限の限定されたそれぞれのアカウントを使用します。これは、復旧操作中にミスがあると、SMS プロセス、とりわけ SMS クライアント プロセスがロックアウトされる危険があるということを意味します。すべてのアカウントとパスワードは、復旧前と復旧後で正確に一致する必要があります。

**オブジェクトレベルのセキュリティ。**SMS は共有セキュリティではなく、オブジェクト レベルのセキュリティに基づいて、レジストリとファイル データを保護します。SMSLOGON 共有以外の全 SMS 共有は、Everyone グループに共有へのフル アクセス許可を与えます。サイトの障害後機密データを保護するため、明示的アクセス許可を復元する必要がありますが、権限の少ないプロセスでもそのタスクの遂行には正確な読み取り、実行、書き込みのアクセス許可が必要です。1000 以上のレジストリ キーとディレクトリがあり、それぞれにはアクセス制御リスト (ACL) があり、それぞれのリストには複数のアクセス制御エントリがあって、各エントリには複数のプロパティがあります。キー グループまたはディレクトリ グループがすべて同じ権限を持つ場合は定義されたゾーンがないので、すべての個々のプロパティは一意です。

**クライアントサイトおよびセカンダリサイトの制御回復。**サイト障害は、クライアント サイトおよびセカンダリ サイトから障害を受けたサイトを切り離します。バックアップが利用できなくても、障害をうたサイトの復旧はローカルな SMS クライアント サイトおよびセカンダリ サイトの制御回復のために利用できます。この時、障害を受けたサイトの子であるすべてのクライアント サイトおよびセカンダリ サイトを一掃して再構築する必要はありません。

復旧サイクル

次のグラフは、SMS サイトの全復旧サイクルを表示します。

SMS のメンテナンスおよび復旧手続きに必要なスキル

SMS のメンテナンスおよび復旧手続きの完了には、管理者がローカルおよびリモートのコンピュータ上の詳細な手動によるタスク実行を熟知している必要があります。このタスクは時に、オペレーティング システムのリソース キットツール、Systems Management Server、および Microsoft SQL Server を使用します。多くの場合管理者は、ライブ サイト上の重要データを直接操作します。

これには、次のタスクが含まれます。

  • オペレーティング システムの構成、ファイル システムの処理、およびレジストリの編集。
  • アカウント、サービス、共有、信頼関係、アクセス許可、権利、組織単位 (OU)、ドメイン、フォレスト、ポリシー テンプレートなどオペレーティング システムのセキュリティの構成。
  • SQL Server の構成、データベースの復元、および SQL Server テーブルと問合わせの更新。
    • 警告
      手続きが完了できないとサイト操作の失敗を引起こしたり、サイト データを破壊したり、複数サイトでサイト データを破壊したりもします。SMS 管理者のスキル レベルに疑問があれば、より経験をつんだ管理者がメンテナンスと復旧手続きを管理する必要があります。熟練した管理者が利用できない場合、製品サポート サービスに連絡して、管理者がひとりで管理できるようになるまで、手続き中に管理者を指導してもらう必要があります。

ページのトップへ

復旧計画

障害は阻止できませんが、その準備は可能です。SMS サイト システム (SMS サイトのサービスを提供するコンピュータ) の障害に備えるため、サイト システムを障害前と同一に再構築するのに必要な全構成データを収集します。

Microsoft は、必要な情報の一部を収集する 2 つのバッチ ファイルを提供しています。それはすべてのサイト システム用の Machinfo.bat と、SMS サイト データベース システム用の SMSSQLinfo.bat です。既定ではこの バッチ ファイルは、Backup SMS Site Server タスクが実行されるときに実行されますが、手動で実行することもできます。これらのバッチ ファイルはデータをさまざまな出力ファイルに書き出しますが、ディスクがクラッシュするかほかの磁気メディアが故障すると、その出力ファイルにアクセスできません。そのためこの出力ファイルをバックアップするか、データを構成ワークシートに記録するようにしてください。

復旧を簡略化するテクニック

クライアントの接続アカウント管理

サイトが障害を受ける前に、クライアントの接続アカウントを、既定の SMSClient_<SiteCode> とは違う名前で追加作成してください。

クライアントのロックアウトを防止するため、SMS クライアントの接続アカウントのパスワードは決して変更しないでください。旧サイトが既定のアカウント名を使用している場合、復旧中にフレッシュ サイト インストールを実行すると、基本的にこの事態が発生します。その代わり、サイトが障害を受ける前に新規パスワードで、SMS クライアントの新規接続アカウントを作成してください。新規アカウント情報が全ドメイン コントローラ、クライアント アクセス ポイント (CAP)、クライアントに通知されると、古いアカウントを変更または削除できます。

Windows® NT User Manager for Domains ではアカウントのロックアウトが可能で、ある SMS クライアントが無効のパスワードを使用してアカウントにアクセスして、間違ったログオンを設定された回数だけ行なうと、そのアカウントはロックアウトされます。SMS クライアントはいろいろなクライアント接続アカウントを使用しているので、これは SMS クライアントにとって意味があります。たとえば長期間オフラインだった SMS クライアントは、クライアントの接続アカウントの全パスワードの有効期間が切れたために、ロックアウトを引き起こすことがあります。SMS クライアントが古い無効なアカウント パスワードを使ってオンラインに復帰すると、クライアントの接続アカウントはロックアウトされます。

アカウントのロックアウトについてより詳しくは、 「Systems Management Server 2.0 Security Essentials」という技術資料の「アカウントのロックアウト」を参照してください。そのガイドは、Systems Management Server の Web サイトで利用できます。

サーバーの接続アカウント管理

サイトのセットアップ時には SMSServer_<SiteCode> という形式の既定のサーバー接続アカウントが作成され、無作為なパスワードが割り当てられます。復旧中にフレッシュ サイト インストールを実行すると、別のパスワードが作成されます。サイト リセットを実行して、新しいサーバー接続アカウントのパスワードを、サイト内の全リモート サイト システムに通知する必要があります。ログオン サーバーが多数あると、全ログオン ポイントを更新するサイクルを実行するには、長い時間がかかります。この場合は、SMSAccountSetup.ini ファイルの使用を検討するか、サーバー接続アカウントのパスワードを指定するコマンドライン パラメータの設定を検討してください。サイト リセットを実行してリモート サイト システムによるサイト サーバーへのアクセスを再度可能にする事態を避けるため、 このパスワードを文書化して、サイト復旧中に再利用することができます。

復旧に必要なデータの収集

Machinfo.bat

サイト システムの構成ワークシートに記入する必要情報の一部は、バックアップされている各サイト システムで Machinfo.bat を実行すると提供されます。Machinfo.bat は手動で実行できますが、Backup SMS Site Server タスクにより自動的に実行されます。Machinfo.bat は出力を次の既定ファイルに書き込みます。

サイトサーバー上:
\%SITE_SERVER_DEST %\SMSbkSiteConfigNT*.txt\%SITE_SERVER_DEST %\SMSbkSiteConfigNT*.txt

SMS サイト データベース サーバー上:
\%SITE_DB_SERVER_DEST%\SMSbkSQLConfigNT*.txt

Machinfo.bat では、次の Windows NT リソース キット ツールがパス上に存在する必要があります。

  • now.exe
  • srvinfo.exe
  • tlist.exe

構文

\SMS\bin\i386\machinfo.bat  SiteSystem  Folder\  FilePrefix

SiteSystem
情報を収集するサイト システムを指定します。Machinfo.bat を実行するコンピュータです。

Folder\
出力ファイルを書き込むフォルダを指定します。これは C:\SMS\bin\i386\temp\ のような絶対パス、..\temp\ などの相対パス、\\server\share\ のような UNC パスを指定できますが、末尾は \ で終わる必要があります。

FilePrefix
各出力ファイル名の先頭文字列です。2 つの出力ファイルがあります。

FilePrefixData.txt

Srvinfo -D、Net View、Srvinfo -NS、Net Share、Ipconfig、および Tlist より提供された情報が含まれています。

FilePrefixWinMSD.txt

Winmsd.exe より提供された情報が含まれています。

例

machinfo.bat  Serv1 \\Serv1\Public\  Serv1_

セキュリティ
Machinfo.bat が実行されるセキュリティ コンテキストは、SiteSystem 上とドメインで管理者の権限を持つ必要があり、Folder にファイルを書き込む権限が必要です。

制限 Machinfo.bat からパーティション情報が出力されますが、Machinfo.bat はリモート コンピュータ上の共有ドライブ位置を記録していません。必要ならこの情報を手動で収集する必要があります。

Smssqlinfo.bat SMS サイト データベース システムの構成データ ワークシートに記入する情報の一部は、各 SMS サイト データベース システム 上で Smssqlinfo.bat を実行して、各ソフトウェア メータリング データベース システムがバックアップされると、 Smssqlinfo.bat により提供されます。Smssqlinfo.bat は手動で実行できますが、Backup SMS Site Server タスクにより自動的に実行されます。Smssqlinfo.bat は出力を次の既定ファイルに書き込みます。

\%SITE_DB_SERVER_DEST%\SMSbkSQLConfigSQL*.txt

Smssqlinfo.bat では、SQL Server ユーティリティの Isql.exe がパス上に存在していて、また SQL スクリプトの Smssqlinfo.sql が Smssqlinfo.bat と同じフォルダに存在する必要がありますが、移動させたのでなければそのフォルダにあるはずです。

構文

\SMS\bin\i386\smssqlinfo.bat  SiteSystem  DBname  Folder\  FilePrefix

SiteSystem
情報を収集する SMS サイト データベース システムまたはソフトウェア メータリングデータベース システムを指定します。Smssqlinfo.bat を実行するコンピュータです。

DBname
SQL Server データベース名です。SQL Server Enterprise Manager を実行して、Databases フォルダを調べると見つかります。

Console Root
    Microsoft SQL Servers
     SQL Server Group
      SiteSystem
       Databases

Folder\
出力ファイルを書き込むフォルダを指定します。これは C:\SMS\bin\i386\temp\ のような絶対パス、..\temp\ などの相対パス、\\server\share\ のような UNC パスを指定できますが、末尾は \ で終わる必要があります。

FilePrefix

各出力ファイル名の先頭文字列です。4 つの出力ファイルがあります。

FilePrefixData.txt

SQL Server 構成情報が含まれています。

FilePrefixdboption.txt

SQL Server のオプション情報が含まれています。

FilePrefixhelpdb.txt

サイズ、所有者、ログ ファイルなどのデータベース情報が含まれています。

FilePrefixrevdatabase.txt

データベースのバックアップを復元する前に、SQL Server 6.5 データベース内のリッジ セグメント構造を作成し直すのに必要な SQL Server スクリプトが含まれています。SQL Server 7.0 はリッジ セグメント構造を使用しないため、作成し直す必要はありません。

例

smssqlinfo.bat  Serv2  SMS  \\Serv2\Public\  Serv2_ 
smssqlinfo.bat  Serv3  SMS_LICDB  ..\Temp\  Serv3_

セキュリティ
Smssqlinfo.bat が実行されるセキュリティ コンテキストは、SiteSystem 上とドメインで管理者の権限を持つ必要があり、Folder にファイルを書き込む権限が必要です。

構成ワークシート
サイト システムを正しく復旧するため、全サーバーの構成データを利用可能にする必要があります。オリジナルのサーバー構成と復旧されたサーバー構成の間に多くの不一致があると復旧は失敗しますし、このデータがないと復旧が失敗した理由を解明するのは困難です。サイトが障害した後は、この情報を故障したシステムから獲得できませんから、その前に各 SMS サイト システムのサーバー構成データを収集するのは賢明なことです。

次のワークシートには、SMS サイト システム復旧に必要なデータが含まれています。正確にサイトを再構成できるように、カスタム構成について必ず十分な情報を記録してください。このワークシートをコピーおよび印刷して、各サイト システムの個々のワークシートを維持することができます。次のオブジェクトには、構成データのワークシートがあります:

  • サイト システム
  • SMS サイト データベース システム
  • SMS セットアップおよびサイト オプション
  • SMS アカウントおよびパスワード

サイトシステムの構成ワークシート

Machinfo.bat はこのワークシートの記入に必要なデータを収集します。

データ収集日 =

サーバー名 =

ドメイン名 =

サーバーのドメインでの役割 (PDC、BDC、メンバー) =

Windows NT の種類 (WinNT、LanmanNT など) =

OS バージョン (4.0、5.0 など) =

OS の service pack =

OS のビルド番号 =

OS のカーネルの種類 (Uni または MP) =

OS 製品の種類 (Enterprise、Standard など) =

OS のリリース言語の種類 (US、German など) =

OS の一覧コード ページ =

CPU の種類 (x86 または Alpha) =

IP アドレス =

HEALTHMON バージョン =

HEALTHMON の service pack =

IE のバージョン =

IE の service pack =

MMC バージョン =

MMC の service pack =

NETMON バージョン =

NETMON の service pack =

WMI バージョン =

WMI の service pack =

WMI のビルド番号 =

ユーザーコンポーネント

サーバーにインストールされたカスタム コンポーネントはどれで、既定の設定のどれが変更されていますか。

セキュリティ

どのドメインがこのサーバーのドメインを信頼していますか。

このサーバーのドメインはどのドメインを信頼していますか。

SMS サイトデータベースシステムの構成ワークシート

Smssqlinfo.bat は、このワークシートの記入に必要なほとんどのデータを収集します。

SMS サイト データベース サーバーがサイト サーバーでない場合、代わって全ワークシートのコピーに記入する必要があります。ソフトウェア メータリングデータベースがサイト サーバーまたは SMS サイト データベース サーバー上にない場合、代わって全ワークシートのコピーに記入する必要があります。

データ収集日 =

SQLSERVER.exe バージョン番号およびビルド番号 =

SQL Server バージョンの種類 (Enterprise、Standard など) =

SQL Server のリリース言語の種類 (US、German など) =

SQL Server 既定の言語 =

SQL Server の代替言語 =

SQL Server Unicode 照合 ID (7.0 のみ) =

SQL Server Unicode 照合比較スタイル (7.0 のみ) =

SQL Server の文字セット =

SQL Server のソート順 =

SQL Server ファイルの場所 =

SQL Server マスタ データベースの場所 =

SQL Server の tempdb データの場所 =

SQL Server の tempdb ログの場所 =

SQL Server SMS サイト データベースのデータの場所 =

SQL Server SMS サイト データベースのログの場所 =

SQL Server SMS_LicDB データベースのデータの場所 =

SQL Server SMS_LicDB データベースのログの場所 =

セキュリティ

どのドメインがこのサーバーのドメインを信頼していますか。

このサーバーのドメインはどのドメインを信頼していますか。

SMS セットアップおよびサイトオプションの構成ワークシート

サイトを復旧するため SMS を再インストールするとき、セットアップ オプションおよびサイト構成がオリジナルのインストールと正確に同じであることが重要です。

データ収集日 =

サイト コード =

サイト名 =

Alpha と x86 のコンポーネントが両方インストールされていますか。

どのオプションの SMS ソフトウェアがサイトにインストールされているか入力してください。

  • ソフトウェア メータリング___
  • ソフトウェア メータリングコンソール___
  • リモート ツール___
  • SMS インストーラ___
  • ネットワーク モニタ___
  • パッケージ自動化スクリプト___
  • SMS 用 Crystal Info___
  • NetWare バインダリ サポート___
  • NetWare NDS サポート___
  • 製品準拠データベース___

サイト ディレクトリ名およびドライブの場所 =

SQL Server へのアクセス時に統合セキュリティを実行しているか =

SMS サイトのデータベース名 =

SMS サイトのデータベース デバイス =

サイトのログ デバイス =

SMS サイト データベースのデバイス パス =

ソフトウェア メータリングデータベース名 =

ソフトウェア メータリングデータベース デバイス =

ソフトウェア メータリングログ デバイス =

ソフトウェア メータリングデータベースのデバイス パス =

SMS サイトデータベースがサイトサーバー上にない場合:

SMS Provider をインストールした場所はどこですか、サイト サーバーですか、あるいはサイト データベース サーバーですか。

SMS 管理コンソールは SMS サイト データベース サーバー上にインストールされていますか。

バージョン

SMS バージョン =

SMS の service pack =

SMS ホットフィックス レベル =

SMS のリリース言語の種類 (US、German など) =

SMS コード ページ =

SMS International Client Pack のバージョン =

SMS パッケージのアクセス許可

次のアイテムの既定値を入力してください:

パッケージ共有 =

パッケージの共有ディレクトリ =

パッケージのルート ディレクトリ =

  • Administrators: フル コントロール (すべて) (すべて)
  • Guests: 読み取り (読み取り、実行) (読み取り、実行)
  • 一般利用者: 読み取り (読み取り、実行) (読み取り、実行)

パッケージ共有またはパッケージのセキュリティの一部がカスタマイズされた場合は、記録に残す必要があります。

SMS アカウントおよびパスワードの構成ワークシート

  • 警告
    パスワードの記録は、大切に機密保護する必要があります。このワークシートは機密保護された場所に保管し、このワークシートの保管場所を人に言及しないでください。

データ収集日 =

サイト サービス アカウント =

サイト サービス アカウントのパスワード =

サイト データベース SQL Server のログイン ID =

SMS サイト データベース SQL Server のログイン ID =

ソフトウェア メータリングデータベース SQL Server のログイン ID =

ソフトウェア メータリングデータベース SQL Server のログイン ID のパスワード =

ページのトップへ

障害を減少させる戦略の実装

コンピュータの障害を防止する方法についてたくさん書かれていますが、それぞれのビジネス ニーズに基づいて、各企業にはさまざまな戦略があります。採用された戦術のすべてを網羅することは、本ガイドの範囲外です。しかし、障害を減少させる方法の検討は復旧サイクルの重要な一部であり、まず障害を防止するあらゆる処置を実行して、障害を減少させるために障害から学ぶことは有益です。

サイトサーバーのハードウェアを障害前に交換する
障害を受ける前にサイト サーバー ハードウェアを交換することは、サイト障害を防止するキー ステップです。サイト サーバーに信頼性に欠ける兆候が見つかったら、ただちに SMS Maintenance and Recovery サイト上で「Swapping Site Hardware」手続き中の手続きを使用して、古いハードウェアを新しいハードウェアで交換します。

ヘルプデスクに冗長性を確保する
ヘルプ デスクが毎日 24 時間のフル サポートを保証することは、大組織ではとても重要なことです。SMS サイトでリモート ツールが継続して動作するよう保証するには、2 つのアプローチがあります。どちらかのソリューション、あるいは両方のソリューションを実装できます。

  • トップレベルの中央サイトの利用
  • ライブ SMS サイト データベースの読み取り専用複製の利用

いずれの場合も定期的に利用するヘルプ デスクには既定サイトがあるため、バックアップがリモート制御セッションのサポートに利用されているか、毎日確認する必要があります。

トップレベルの中央サイトの利用

  • リモート制御はネットワークから直接クライアントにアクセスするので、クライアントのハードウェア インベントリを保有しているサイトは、そのサイトからクライアントに向けてネットワーク接続があれば、リモート制御アクセスが可能です。そのため中央サイトより上に親としてトップレベルの中央サイトがあり、全ハードウェア インベントリが中央サイトに送られる場合、ネットワーク接続可能なデーターベース内の全クライアントに対して、リモート制御がサポートされます。
  • 階層の下に向かうデータ通知の遅延を減らして、ヘルプ デスクが可能な限り最新のインベントリを確実に使用するため、管理やヘルプ デスクのタスクはすべて中央サイトで行なう必要があります。
  • ヘルプ デスクが素早くトップレベルの中央サイトに切り替えられるように、SMS 管理コンソールは両サイトにあわせて構成される必要がありますが、既定では中央サイトを使用する必要があります。

ライブ SMS サイトデータベースの読み取り専用複製の利用
ライブ SMS サイト データベースのコピーを格納する読み取り専用複製サイトが設定できます。そしてヘルプ デスクは、複製サイト上のデータベースのコピーを、ライブ サイトがダウンした場合のリモート ツール サポートのバックアップとして利用できます。これにより階層内の任意のサイトには、クラスタリングでは提供できない真の冗長性が確保されます。複製サイト計画に次の項目を取り入れることにより、安定性が高く冗長性のあるシステムを作成できます。

  • サイト サーバー用の SMS サイト データベースは、複製サイト用の SMS サイト データベースのコピーとは別のコンピュータ上に収納する必要があります。
  • ライブ サイトと複製サイトは、別の無停電電源、ハブ、ルータ上に配置する必要があります。
  • ネットワーク インフラストラクチャの障害に備えて、2 つ以上の複製サイトを作成して、地理的に異なる地域に配置することができます。

複製サイトはヘルプ デスクのリモート ツールのサポートとして使用されるだけなので、複製サイトがフル機能を備えたサイトでないことに注意してください。SMS Provider は、複製サイトとして使用される唯一のサイト コンポーネントです。それは SMS サイト データベースへのアクセスを取得するために使用されます。

ライブ サイトによりデータベースが更新された後、サイト構成の変更または複製サイト上のソフトウェア配布は失われます。サイト「replica」の名前付けと管理者教育が不十分な場合、ヘルプ デスクの担当者が使用するアカウントに読み取り専用のアクセス許可だけを与えるように、複製サイト用の SMS 管理コンソールのセキュリティを設定できます。これにより管理者が不注意に複製サイトを変更し、その後なぜその変更が保存されていないか疑問を感じることはなくなります。

複製サイトの設定

  1. 「Replica Site for Help Desk Backup」その他お好きな名前で、サイトをインストールします。このサイトはライブ サイトと同等のネットワーク接続が必要で、ライブ サイトをバックアップしているので、ヘルプ デスクおよびリモート制御と同等なサポートになります。
  2. 複製サイトを、オプションをできるだけ指定しないスタンドアロンのサイトとしてインストールします。ほかのアプリケーションとヘルプ デスクの間の読み込み衝突をさけるため、SQL Server の専用インスタンスの使用を検討してください。ヘルプ デスクは高速でリアルタイムな応答を必要とします。
  3. セットアップが完了して、複製サイトが初期化を完了するまで待ちます。セットアップが完了して複製サイトが初期化されたか判断するには、クライアント アクセス ポイント上に Clicomp.box ディレクトリが作成されて、SMS 管理コンソールがサイト プロパティを読み込んで表示できるか確認します。
  4. SMS_SITE_COMPONENT_MANAGER、SMS_EXECUTIVE、および SMS_SQL_MONITOR のサイト サービスを停止して無効にします。これは、複製サイトがライブ中央サイト データベース内のデータに干渉しないことを保証するために、ぜひ必要です。

ライブ SMS サイトデータベースの複製

各サイトには、SMS サイト データベースをバックアップするタスクがあります。しかしこのタスクを SQL Server メンテナンス スケジュールにより自動化して、すべての複製プロセスを自動化することをお勧めします。それには次のステップが必要です:

  1. ミッション クリティカルなサイトはデータ ロスを最小化するため、24 時間ごとにバックアップされる必要があります。有効なサイト サーバー バックアップを取得するには、バックアップ実行前にサイトを停止する必要があります。それによりバックアップは、確実にサイト サーバーの正確なスナップショットになります。
  2. サイト サーバー バックアップからのデータベースのバックアップは、複製サイトの更新に使用します。ライブ サイトによる SQL Server の負荷をさけるには、複製サイトに対して別のバックアップを実行するより、このバックアップを利用する方が最善です。
  3. ライブ サイトによる SMS サイト データベース複製は、複製 SMS サイト データベースを置き換えするため、SQL Server のデータベース回復に使用される必要があります。複製は、サイト バックアップの完了後 2、3 時間に予定した SQL Server の自動化タスクとして設定できます。これにより確実にスケジュールの競合はなくなり、複製サイトに最新データを読み込むことができます。

複製サイトを SMS 管理コンソールに指定する

ヘルプ デスクの負荷容量が大きくて、ヘルプ デスクが多少古いデータを処理できる場合、ヘルプ デスク用の SMS 管理コンソールとして、既定で複製サイトを指定できます。しかしヘルプ デスクの SMS 管理コンソールとして既定でライブ サイトを指定でき、それにより最新のデータを処理できると理想的です。いずれの場合も障害の場合は素早く切り替えられるように、 SMS 管理コンソールには両方のデータベースの場所を設定する必要があります。

クライアント操作に冗長性を確保する

サイト操作の分割を SMS に組み込む
クライアント操作に冗長性を確保する方法を理解するには、サイト操作が分割される方法を理解する必要があります。SMS 2.0 は、サイト サーバーとクライアントを直接対話させない設計になっています。唯一の例外はクライアント構成マネージャで、これはサイト サーバー上で実行されて、クライアントと直接交渉します。これは SMS サイトのセキュリティを向上させるため、クライアント アクセス ポイント (CAP) からサイト サーバーに移動されました。それ以外の場合は、SMS_SITE_COMPONENT_MANAGER と SMS_EXECUTIVE の組合せがサイト システムを管理して、サイト システムが SMS クライアントと対話します。管理者にはサイト サーバー上で CAP の実行、配布ポイント、ログオン ポイント、ソフトウェア メータリングサーバーの各オプションがありますが、オプションを実行する必要はありません。SMS は、全サイト システムに対して複数インスタンスをサポートしています。

サイトシステム障害後の SMS クライアント操作の続行
次のようなサイト システムに関連した 2 つの基本的障害シナリオがあります。

  • サイト サーバーがダウンする。
  • リモート サイト システムがダウンする

次のような 3 つの CAP を持ったサイト設計を検討してください。サイト サーバーに CAP を 1 つ設定し、それ以外のコンピュータ上に 2 つの CAP を設定します。

CAP のどれか 1 つがダウンすると、なおクライアント サポート容量の 2/3 が動作しています。クライアントの視点からすると、CAP がサイト サーバー上にあるかどうかは重要ではありません。そのような状況で SMS クライアントの視点から見ると、サイト サーバーがダウンしてもサービスは中断されずに継続しています。この論理は、全タイプのサイト システムに適用されます。クライアントは次の処理が可能です。

  • ログオンして、検出される。
  • 長期の中断の後ログオンして、ファイルを更新する。
  • インベントリを実行して、クライアント アクセス ポイント (CAP) 上でインベントリとステータス ファイルに記入する。
  • スケジュールに基づいて割り当てられたソフトウェア パッケージを処理する。
  • 実行されているアプリケーションを計測する。
  • 冗長性がヘルプ デスクに実装された場合、リモート制御などのヘルプ デスクのサポートを受ける。

サイト サーバーが障害してからファイルのバックログをサイト システムに構築しても、更新されません。そのため、可能な限り早くサイト サーバーを復旧することが重要です。

リモート サイト システムが障害しても素早く修復されないと、ダウンしたコンピュータを置き換えるために、別のコンピュータをサイトに追加できます。サイトは一部のサイト システム向けに通常のリソースの 2/3 で機能を続行できますが、通常レベルのリソースの 1/3 ではきちんと機能できないので、置き換えを素早く実行することが重要です。

サイトサーバーなしのソフトウェア配布続行計画
数週間にわたるソフトウェア配布を計画すると、サイト サーバーが数週間ダウンしていても、スケジュール通りに実行できます。パッケージは該当サイトの該当配布ポイントに配布され、情報提供と割当てが作成されて該当開始時刻に配布できます。これらすべてのことは、サイト サーバーのダウン中も引き続き実行できます。サイト サーバーがふたたび復帰するまで、クライアントのステータスは処理されません。しかし処理停止というトラブルが発生した場合、ヘルプ デスク サポートに冗長性がセットアップされていると、ヘルプ デスクはなお展開に関するトラブルを解決できます。

サイトシステムの複数のリモートインスタンスの利用
クライアント コンピュータ上のパフォーマンスの問題や遅延、スローダウンをさけるため、使用ピーク時に 1 つのサイト システムがダウンしても、ふたたびそのサイト システムが復帰するまで残りのサイト システムがクライアントをサポートできる十分な容量が存在するように、複数のサイト システムのリモート インスタンスを使用します。

複数サイトシステムおよび信頼性のあるサイトサーバーへの投資
サイト サーバーだけがサイト システムを作成できることに留意してください。リモート サイト システムがダウンしたときにサイト サーバーがダウンすると、サイト サーバーが復帰するまで新規サーバーは構築できません。リモート サイト システムはバックアップできますが、大量の定期的オーバーヘッドを引き起こします。サイト システムのバックアップより、一般にサイト サーバーが確実に次の状態にある方が、投資としては優れています。

  • サイト サーバーが高品質で信頼性のあるハードウェアで動作している。
  • サイト サーバーは代替部品の備蓄が利用可能か、バックアップを復帰させる同一の複製が存在する。
  • サイト サーバーは頻繁にバックアップが行なわれている。
  • サイト サーバーにはライブ サイト復旧を実行する訓練をうけた担当者が存在していて、いつもサイト サーバーを素早く確実に再始動できる。

サイトサーバーがオンラインに復帰後
サイト サーバーのダウンの間、すべての探索レコード、インベントリ、ステータス、ソフトウェア メータリング情報は、サイト サーバーがオンラインに復帰するまで、リモート サイト システム上に保存されます。サイト サーバーがオンラインに復帰すると、クライアント情報のバックログが処理され、必要に応じて階層に転送されます。

ページのトップへ

データのバックアップ

コンピュータに保存されたデータのバックアップは障害からの復旧に重要ですが、SMS データのバックアップは障害を受けたサイトの復旧に重要です。SMS がすべての一意のデータを定期バックアップするようスケジュールを立てて、障害したどのサイト システムも完全に復旧することができます。

SMS バックアップ戦略
各 SMS サイト階層はそれぞれ違うため、マイクロソフトは包括的 SMS バックアップ戦略を提供できません。SMS サイトの SMS バックアップ戦略を決定する前に、いくつかの質問に答えてください。

ほかの SMS タスク スケジュールは、Backup SMS Site Server タスクのスケジュールと両立できますか。

データベースの保守やクライアント パッケージのインストールなど完了迄に時間のかかるタスクは、できるだけ中断しないでください。そのタスクは、次の Backup SMS Site Server タスクが開始する前に完了するようスケジュールを立てます。

サイトをシャットダウンする時間を減少させるため、一部のデータを省略したバックアップを希望しますか。

場合によるとバックアップの完全性の代わりにバックアップ速度を選択したり、バックアップ中のサイト停止を最小化したり、あるいは両方とも選ぶことをお勧めします。その場合、バックアップで省略されたデータの損失を補償する回復戦略はありますか。

SMS バックアップには、プロセス間ネットワーク通信がありますか? 通信は低速リンクを通して行なわれますか? リンクの信頼性はどの程度ですか。高速で信頼性のあるリンクだけを使用するようにバックアップを構成するのが最善です。

サイトバックアップ前の推奨タスクの実行
バックアップ データが破損するリスクを減少させるためのサイト バックアップを実行する前に、次のデータベース一貫性チェックのタスクを実行してください。

  • dbcc checkdb
  • dbcc checkcatalog
  • dbcc newalloc (SQL Server 6.5 のみ)
  • dbcc textalloc (SQL Server 6.5 のみ)

階層全体のバックアップ階層全体のバックアップは重要ですが、同時に階層内の全サイトをバックアップするメリットはありません。各サイトは、ほかのサイトから独立してバックアップ、復元できます。

バックアップユーティリティのオプション組込まれている自動サイト バックアップ タスクや、オペレーティング システムのバックアップ ユーティリティ、サード パーティ製のバックアップユーティリティを使用して SMS をバックアップできます。

自動サイト バックアップ タスク以外のバックアップの使用を選択した場合、バックアップ サイクルは SMS バックアップ制御ファイルに一覧された順序を、一覧と同じ順序で実行する必要があります。そうでないとバックアップが有効でない危険性があります。

サイト バックアップを全データのスナップショットにして、データにアクセスする全プロセスは停止させることが重要です。プロセスが停止されない場合、一部しか完了していないタスクは同期できない恐れがあります。これはサイト復旧後に問題を起こす場合があります。そのためサポートされている唯一のサイト バックアップは、データにアクセスする全プロセスが停止された時の全データのスナップショットです。

バックアップを有効にするため、SMS バックアップ制御ファイルと同じタスクを同じ順序で実行する必要があります。最も単純で信頼性のある計画は Backup SMS Site Server タスクを実行することで、バックアップをテープに保存するために、別のバックアップ アプリケーションを使用することです。

バックアップサイトとプライマリサイト
SMS_SITE_BACKUP サービスは、プライマリ サイトのバックアップを実行します。このサービスを可能にして、次のように Database Maintenance、Tasks 内で、SMS 管理コンソールを使用して Backup SMS Site Server タスク向けにセットしたスケジュールにしたがって実行します。

Systems Management Server
    SMS site database (site code - site name)
     Site Hierarchy
      site code - site name
       Site Settings
        Database Maintenance
         Tasks
  • 注
    既定では、SMS_SITE_BACKUP は可能となっていません。SMS_SITE_BACKUP を可能にする前に、SMS バックアップに関する話題とそのトレードオフについてよく理解するため、本項をお読みください。

SMS_SITE_BACKUP は SMS サイト データベース、ソフトウェア メータリングデータベース、サイト サーバーの SMS および NAL レジストリさらにサイト サーバー上の \SMS ディレクトリ ツリーをバックアップします。SMS_SITE_BACKUP は、ほかのサイトやサイト システムにあるデータはバックアップしません。

SMS_SITE_BACKUP の動作は、SMS バックアップ制御ファイルにより制御されます。ファイルはサイト サーバー上にある \SMS\Inboxes\Smsbkup.box\Smsbkup.ctl です。このファイルを編集して、バックアップするデータとしないデータを変更します。SMS バックアップ制御ファイルについて詳しくは、 SMS オンライン ヘルプ トピックの 「SMS バックアップ制御ファイルについて」を参照してください。しかしこのファイルを変更する前に、SMS_SITE_BACKUP についてよく理解するため、本項をお読みください。

SMS_SITE_BACKUP について、とくに注意する必要のある事柄が 3 つあります。

  • SMS_SITE_BACKUP はバックアップ中、SMS サイト サーバーおよび SMS サイト データベース サーバー上の全 SMS サービスを停止します。そのため、階層のサイズ、SMS パッケージの数、ネットワーク スループットについて検討する必要があります。たとえば階層がビジーで、パッケージを配布する SMS サービスが 1 日 22 時間動作していると、1 日 3 時間動作するバックアップ タスクは毎日パッケージ配布に少し遅れて、決して追いつけないことになります。
  • 多数のデータをたまにバックアップするよりは、少数のデータを頻繁にバックアップした方がよいです。多くの SMS データは、クライアント アクセス ポイント、配布ポイント、ログオン ポイントなどサイト システムにコピーされます。これらすべてのサイト システムをバックアップすると復旧はよりすみやかに行なわれますが、SMS サイト サーバーは障害を受けたサイト システムにデータを戻せるので、それらをバックアップする必要はありません。
  • SMS_SITE_BACKUP は主として、SMS サイト内のサイト サーバーおよび SMS サイト データベース サーバーだけをバックアップするように設計されています。SMS_SITE_BACKUP を使用してほかのコンピュータ上のほかのデータをバックアップすることも可能ですが、そのようなバックアップはサイト サーバーおよび SMS サイト データベース サーバーだけをバックアップすることと無関係な危険性と混乱におちいり易いです。

Backup SMS Site Server タスクの有効化、スケジュール化、トラブルシューティングについて、そして SMS バックアップ制御ファイルについては、SMS 管理コンソール内の SMS オンライン ヘルプを参照してください。

既定でバックアップされるデータ
既定の SMS バックアップ制御ファイルは、次のデータをバックアップします。

SMS サイトデータベースおよびソフトウェアメータリングデータベース
既定の SMS バックアップ制御ファイルは、ソフトウェア メータリングデータベースと SMS サイト データベースが SQL Server の同一インスタンスの一部を構成する SMS サイト向けに構成されています。これは、SMS セットアップにより作成される既定の構成です。ソフトウェア メータリングデータベースを SMS サイト データベースとは別の SQL Server インスタンスに移動させた場合、SMS バックアップ制御ファイルの「METERING」で始まる行のコメントを除去して、ソフトウェア メータリングデータベースのサーバーをソフトウェア メータリングデータベースそのものと一緒にバックアップする必要があります。

SQL Server 構成データ

これには、次の SMS サイト データベースおよびソフトウェア メータリングデータベースの全データが含まれます: マスタ DB、MSDB、およびモデル DB。

各サイトサーバー上の SMS ディレクトリツリー

これには各サイト サーバー上の SMS ディレクトリ ツリー内の全ファイルが含まれますが、ほかのサイト システム上のファイルは含まれません。

すべての SMS および NAL レジストリキー

既定でバックアップされないデータ
既定の SMS バックアップ制御ファイルは、次のデータをバックアップしません。しかしバックアップ制御ファイルの Tasks セクションにコマンドを追加して、サイト サーバー上の全ファイルをバックアップしたり、そのファイルを非 SMS ツールでバックアップできます。

サイトサーバーのディレクトリツリー以外のサイトシステム上の SMS ファイル

複数のサイト システムが存在する場合、そのファイルはバックアップされる サイト サーバー上に存在するので、それらのバックアップを省略するとより効率的です。そのためシステム障害により復旧が必要になると、24 時間以内にサイト サーバーは自動的にそのファイルを各サイト システムに戻します。

すべての SMS サイトはサイト システムの機能を果たすコンピュータを 1 台以上所有することが理想で、クライアントの既定サーバーが利用できない場合、クライアントは一覧からその機能を持った別のサイト システムを検索し、既定のサイト システムが復旧されるまでそのサイト システムを使用します。

パッケージソースファイル

たとえば \Smspkg* があります。

既定の場所から移動された SMS 関連ファイル

たとえば Custom MOF ファイルと Health Monitor ファイルがあります。

\SMS ディレクトリツリー内に保存されない SMS 関連ファイル

たとえば Crystal Info for SMS とカスタム Y2K データベース ファイルがあります。

SMS アカウント

SMS アカウント データの安全を保証するため、つぎの操作を行ないます。

  • プライマリ ドメイン コントローラの障害に備えて、SMS アカウントが定義されている各 Windows NT ドメイン内にバックアップ ドメイン コントローラを作成します。
  • SMS アカウントが定義されているドメイン内の全ドメイン コントローラを定期的にバックアップします。
  • SMS アカウントおよび共有ディレクトリの権限に加えた変更を書き留めて保存し、障害後その変更をもう一度実行できるようにします。

カスタム SMS 管理コンソールまたはネットワークモニタファイル

このファイルは \SMS ディレクトリ下に保管して、自動的にバックアップされるようにします。

SMS クライアント

クライアント上の SMS データは定期的にバックアップされるのが理想です。そうでないと、クライアントの障害時に実行済みのプログラムが、障害クライアントが復旧したときにふたたび実行されてしまいます。SMS クライアント データはシステム ディレクトリに保存されるので、そのディレクトリがバックアップされると、SMS クライアント データがバックアップされます。

  • 注
    クライアントがバックアップされても、ディスク上やバックアップ内のクライアント データがこわれるリスクは存在します。

それ以外のデータ

SMS バックアップ制御ファイルにタスクを追加して何でもバックアップできますが、SMS_SITE_BACKUP が実行されると確実にバックアップされるように、ファイルは \SMS ディレクトリ下に置くのが安全で便利です。

あるいは一部のデータは非 SMS バックアップ ツールによりバックアップでき、それは SMS_SITE_BACKUP が動作する時間を減少させます。これはサイトが操作を再開する時に、サイトの中断時間と SMS タスクのバックログを最小化します。

SMS_SITE_BACKUP のスケジュール化
バックアップ内のデータと障害時の現在データが大きく違わないように、SMS_SITE_BACKUP は頻繁に実行する必要があります。たとえば毎時間数個の SMS タスクが遂行される場合、SMS_SITE_BACKUP は毎日実行する必要があります。数個の SMS タスクが毎日遂行される場合は、1 週間に 1、2 回のバックアップが望まれます。

SMS_SITE_BACKUP は、サイト サーバーと SMS サイト データベースの邪魔をしない時に実行する必要があります。SMS_SITE_BACKUP の実行中は、データが壊れないよう、SMS サイト サーバーや SMS サイト データベースにアクセスしてはいけません。これはバックアップの間、パッケージを送信できない、SMS 管理コンソールはサイトにアクセスできない、Crystal Info レポートは実行できないおよびデータは処理できないという意味です。しかしクライアントはクライアント アクセス ポイント、配布ポイント、ログオン ポイントにたえずアクセスし続けます。

SMS_SITE_BACKUP とほかのバックアップツールの調整
SMS_SITE_BACKUP は、企業全体のバックアップ計画の一部として、ほかのバックアップ ツールによりバックアップされる場所にデータを書き込みます。そのため、SMS_SITE_BACKUP を企業のバックアップ ツールと同時刻に実行しないように、両方の動作を必ず調整してください。そうでないと、SMS ファイルは企業のバックアップ ツールによりコピーされなかったり、企業のバックアップ ツールによりコピーされている間 SMS_SITE_BACKUP はそのファイルにデータを書き込めません。

SMS_SITE_BACKUP は、既存の SMS_SITE_BACKUP ファイルを上書きします。そのため、複数の SMS バックアップ コピーを保存する場合、企業のバックアップ ツールは少なくとも SMS_SITE_BACKUP と同じ頻度でコピーするか、別のディレクトリにコピーする必要があります。

SMS_SITE_BACKUP を今実行する
SMS 管理コンソール内でバックアップのスケジュールが構成されると、スケジュールの変更が有効になるまでに 24 時間必要です。サイト サーバー上で SMS_SITE_BACKUP サービスを開始すると、いつでもただちにバックアップを開始できます。バックアップ サイクルが完了すると、サービスは自動的に停止します。これは、最初のバックアップをただちに実行したり、サーバー上で不定期のハードウェア メンテナンスを実行前にスケジュール外のバックアップを実行するのに便利です。

アップグレードはバックアップ制御ファイルを上書きする
カスタマイズしたバックアップ制御ファイルを使用している場合、アップグレード前にそのコピーを保存してください。SMS\inboxes\smsbkup.box\smsbkup.ctl ファイルは、アップグレード中に上書きされます。サイトを更新後、古いバックアップ制御ファイルを新しいファイルに更新するガイドとして使用します。

SMS 2.0 SP1 と SMS 2.0 SP2 のバックアップ制御ファイル (Smsbkup.ctl) には著しい違いがあります。SMS 2.0 SP1 に使用したバックアップ制御ファイルは SMS 2.0 SP2 に使用できないし、アップグレード処理中に上書きされます。バックアップ制御ファイルをカスタマイズしたら、新バージョンのファイルでそのカスタマイズを実行し直す必要があります。

バックアップ制御ファイルの SP1 バージョンは、高速セットアップがインストールした諸機能に基づいているので、カスタム セットアップを使ってサイトにインストールする機能が少ないと、偽のエラーが生成されます。

バックアップ制御ファイルの SP2 バージョンは、SMS の最少インストールに基づいています。オプション コンポーネントのバックアップ タスクはファイルにリストアップされていますが、コメントにして無効になっています。サイトにオプション コンポーネントをインストールしたら、バックアップに加えるため、そのコンポーネントのタスクのコメントを除去する必要があります。

既定のバックアップ制御ファイルと次のコンポーネントを使用している場合は、新しい Smsbkup.ctl ファイルを編集して、そのコンポーネントを参照している行のコメントを除去します。

  • Crystal Info for SMS
  • Network Monitor
  • SNMP Events
  • Software Metering

バックアップサイトとセカンダリサイト
SMS_SITE_BACKUP は、すでにプライマリ サイトの SMS サイト データベースにあるものをのぞき、セカンダリ サイトのデータをバックアップしません。しかし復元に役立つデータはセカンダリ サイト サーバーにもあります。そのためセカンダリ サイト サーバーの定期的バックアップを検討してください。

Backup SMS Site Server タスクは、セカンダリ サイトをサポートしません。プライマリ サイト上のバックアップ制御ファイルをテンプレートとして使用して、セカンダリ サイトをバックアップするスクリプトを作成する必要があります。セカンダリ サイトには SMS サイト データベースがなく、リモート SQL Server がありませんから、セカンダリ サイトをバックアップするときには、SQL Server との対話あるいはリモート サイト システムとの対話はありません。これによりセカンダリ サイトのバックアップは、大いに単純化されます。

セカンダリサイトバックアップ要件の評価
各セカンダリ サイトのバックアップ要件を評価する必要があります。バックアップ要件は、次の事項に基づいています。

  • サイト サーバーの場所でのバックアップ サポートの利用可能性
  • サイトのミッション クリティカル性
  • 費用のトレードオフ

たとえば次のシナリオでは、バックアップに違ったアプローチができます。

  • 推奨バックアップ: 非常勤のサーバー管理者を含む多数のローカル ユーザーの存在するミッション クリティカル サイト、サイトにはローカル ネットワーク上にテープ バックアップ ユニットがあります。
  • 不要なバックアップ: 4 人の常勤スタッフしかいない重要でないリモート オフィス、サイトにはローカル テープ バックアップ ユニットがありません。

バックアップは定期的なオーバーヘッド費用で、信頼性のあるハードウェアと機密保護されたサーバーの場所があれば、障害はほとんど起こりません。総合的目標はデスクトップ管理の費用を削減して、合理的に使用可能時間を維持することです。

クライアント アクセス ポイント (CAP)、ログオン ポイントおよび配布ポイントが 1 つ以上あれば、サイト サーバーがダウンしても、クライアントはなおソフトウェアのインストールとインベントリの通知を続行します。サイトでクライアントにすぐれたサポートを提供するため、追加されたサーバーに 2 台目の CAP、ログオン ポイント、配布ポイントを設置すると、サイト サーバー上で定期的にバックアップを実行するより費用は効果的です。

サイトサーバーのクライアントファイルのバックアップ
バックアップと復元は SMS クライアントには利用できません。現在 SMS はクライアント プロセスの停止と再開をサポートしていません。プロセスがアクティブの間にクライアント データをバックアップすると、ディスクのデータとバックアップ内のデータを破壊するおそれがあります。

サイトシステムのバックアップ
クライアント アクセス ポイント (CAP) やログオン ポイントが障害した場合、最も容易な復旧方法は、CAP を削除してからログオンし、サイト サーバー上に保存されたデータからサイトを再構成することです。これにより、サイトは確実に同期されます。しかし CAP 上に多数のファイルがあって CAP も多数あり、そしてネットワークが低速な場合、すべての再構築には時間がかかります。

アカウントデータのバックアップ
セキュリティ向上のため、多数のアカウントを使用するように SMS を構成できます。サイトがそのように構成されると、全アカウント名とパスワードを記録していたとしても全アカウントとパスワードの再現に時間がかかります。それがなければ、初めからやり直す必要があります。

最善の戦略は、複数のドメイン コントローラを使用することで、それによりアカウント データをバックアップする必要はなくなります。サイトにドメイン コントローラが 1 つしかないかドメイン コントローラが存在しない場合、\%SYSDIR%\System32\Config\Sam のアカウント情報をバックアップしてください。

ページのトップへ

復旧

サイト復旧には 2 つの基本手続きがあります。

バックアップ付きのサイト復旧

  1. レジストリ キー、ファイル、そして適切なら SMS サイト データベースをバックアップします。
  2. バックアップをテープにコピーし、テープを保存します。
  3. サイト障害後、バックアップを復元して再同期し、サイトを修復します。

バックアップなしのサイト復旧

  1. サイト障害後、再同期してサイトを修復します。
  2. パッケージと情報提供を作成し直して再配布します。

バックアップと復旧のキーポイント

  • サイトはバックアップでき、復元が可能です。
  • 障害を受けたサイトと同じサイト コードを使用すると、サイトはバックアップがなくても復旧できますが、バックアップを使用して復旧したときより紛失データは多くなります。
  • サイト復旧後、データ紛失から復旧する手続きが存在します。
  • データをバックアップする頻度が多いと、一部のデータは必ず失われますが、サイト障害によるデータ ロスは少なくなります。サイトに対して責任のある管理者は、バックアップ上のリソース消費対サイト障害後の一部データ ロスのあるリソース分配の損益分岐点を判断する必要があります。これは SMS サイト システムすべてに適用されます。

ページのトップへ

最善のテクニック

以下に、本ガイドで説明された最善のテクニックを説明します。

  • 以前に使用したサイト サーバー名またはサイト コードを使用してサイトをインストールするときに、必ずサイト復旧のフル操作を実行します。

  • SMS、 SQL Server、またはオペレーティング システムをアップグレードの前後は、必ずバックアップします。

  • アカウントの変更後は、必ずバックアップします。

  • 最新のバックアップがない限り、SMS サイト データベースは復元できません。バックアップを復元しなくてもサイトの機能は復旧できます。しかし全インベントリおよびステータス情報は失われ、全データのほとんどは失われます。

  • データのバックアップを頻繁に実行すると、サイト障害によるデータ ロスは減少します。

  • SMS サイト バックアップをテープにバックアップし、一部のバックアップ テープはオフサイトに保存します。

  • サイトをスナップショットとしてバックアップします。

    SMS データはいくつかの場所に保存されます。サイトをバックアップしているときは、必ず SMS サイト サービスを停止して次のアイテムをバックアップすると、スナップショットとして復元できます。一般にこの手続きを守れないとたいていバックアップの失敗を引き起こし、また失敗したバックアップを復元しようとしても、サイト復旧は失敗します。次の場所の全 SMS データは、SMS サイトが正しく機能するため、復元する必要があります。

    • サイトの SQL Server データベース
    • サイト ディレクトリのサイト サーバー ファイル (共有 SMS_<site code> から)
    • SMS および NAL レジストリ キー
    • Microsoft Windows NT および SQL Server を動作させているコンピュータの構成情報

  • 階層の記録

    • 名前の衝突を避けるため、サイト コード、サイト名、サイト サーバー名を記録します。
    • サイト階層構造をグラフ化すると、ネットワークの帯域幅を最高に使用するソフトウェア配布計画を立案しやすくし、階層フローを追って問題をトラブルシュートすることを容易にします。

  • カスタマイズした OS セキュリティを記録します。

    • ローカル グループに配布されたドメイン アカウント、または配布されなかったドメイン アカウント
    • 実装された監査、アカウントおよびシステム ポリシー
    • 変更されたアカウント権限またはアクセス許可
    • カスタム SMS アカウント名は、名前から自明です。そうでない場合は、アカウント名に使用方法を記録します。

  • バックアップ制御ファイルがサイト構成に適しているか確認します。

    SP1 ではバックアップ制御は全コンポーネントのフル インストールに基づいていて、ソフトウェア メータリングや Crystal Reports がインストールされないと、バックアップの実行時毎にエラー メッセージを表示します。

    SP2 ではエラー メッセージをさけるため、バックアップ制御ファイルの一部の行がコメントになっており、完全なバックアップのためにその行が必要なら、コメントのマークを削除する必要があります。

ページのトップへ

標準以下のテクニック

  • 子サイトを障害を受けたサイトから切断しても、そのサイトをダメージや破壊から守りません。

    • 子サイトを障害を受けたサイトから切断しても、すでに発生したダメージから守らず、ダメージを一掃しません。
    • 子サイトを障害を受けたサイトから切断しても、復旧中にミスがあると保護できないし、階層内の障害を受けたサイトより下位のサイトが後で再接続します。 子サイトを保護するには、必ず新しい親サイトで障害を受けたサイトの復旧をチェックし、子サイトを新しい親サイトに接続する前に、より上位の全サイトをチェックします。障害からの復旧のチェックは、接続しているサイトとそのすべての子サイトで、こわれたソフトウェア配布オブジェクトを回避するのに役立ちます。
    • 注
      一般に正しく修復されていないサイトに接続すると、階層全体に破損したソフトウェア データを配布する原因となります。

  • 有効なバックアップなしにサイトを修復する

    有効なバックアップなしにサイトを修復するとそれ以上のデータ ロスを引き起こし、正常な操作の再構築のために有効なバックアップによりサイトを修復する以上の時間がかかります。

  • SMS サイトが動作中にバックアップを実行する

    サイト バックアップ内でリレーショナルな整合性のトラブルを避けるため、バックアップの実行前にサイト サービスを停止してからバックアップを実行します。Backup SMS Site Server タスクは、自動的にサービスを停止させます。

  • SMS サイト データベースまたはサイト サーバー ファイルだけバックアップする

    サイト データの一部だけ復元すると、サイトは完全に損傷した状態になります。

  • サイト障害前のアカウント パスワードやサーバー構成情報の記録に失敗する

    アカウント パスワードやサーバー構成情報がないと、サイト障害はさらに破滅的で、その情報が存在する場合と比較して復旧はより不確かになります。

  • サイトの再インストール後、シリアル番号の同期が正しくない

    ソフトウェア配布オブジェクトに関してシリアル番号のトラブルから帰結する最悪のケースは、全ソフトウェア配布パッケージと情報提供ファイル、記録を手動で全サイト サーバー、サイト システム、障害サイト下位のクライアントから削除しなければならないことです。

  • 親サイト上のバックアップ タスクを使用してセカンダリ サイトをバックアップする

    通常セカンダリ サイトは、低品質のネットワーク接続を通して親サイトに接続されています、そうでない場合セカンダリ サイトのクライアントは通常親サイトのメンバーにだけ登録されています。

    バックアップ タスクはローカル データのバックアップ用に設計されているので、低品質のネットワーク接続が引き起こす問題を補うことはできません。低品質のネットワーク接続はバックアップの破損を引き起こすことがあり、それがサイト復旧を失敗させることがあります。

    バックアップ タスクを調節するサポートはないので、それが長期間低速リンクのネットワーク接続を飽和させることがあります。

    複数のバックアップが実行されていると全サイトが停止状態になることがありますが、それが多数のセカンダリ サイトを所有する親サイトにとって重大問題になることがあります。またそれは負荷の消化が限界に近いサイトと、可能な限り長期の操作可能時間を必要とするサイトにとっては、問題になることがあります。

  • SMS クライアントのバックアップ

    クライアントが動作中にクライアントをバックアップするとデータを破損する恐れがあり、そしてクライアントを停止させる試みもデータを破損する恐れがあるので、その時間にはクライアントをバックアップする必要はありません。

  • バックアップの宛先名にはスペースを使用しないでください。

    SP1 ではサイト ディレクトリが「D:\SMS」で、バックアップ先の名前が「D:\SMS Backup」であると、バックアップは古いバックアップを整理する時にサイトを削除します。

    SP2 では、古いバックアップが削除されないようにバックアップ先の名前を二重引用符で囲みます。これは SP1 のトラブルを修正します。しかし構成情報の多くはコマンド ライン ツールを使用して収集され、その一部は宛先名にスペースを入れたものを受け付けないため、宛先名にスペースが入っていると一部の構成情報はバックアップされません。

ページのトップへ

復旧ツール

SMS 復旧エキスパートは SMS 保守と復旧の Web サイトに組み込まれていて、それ以外のツールは 復旧エツールに含まれています。

SMS 復旧エキスパート
SMS 復旧エキスパートは、障害した SMS サイトの復旧に必要なタスクの完全リストを、それぞれのサイトのシナリオと構成に基づいて作成します。この一覧は、次のフェーズに区分されています。

  • 準備
  • 再構築
  • 復元
  • 修復

SMS 復旧エキスパートは必ず実行してください。SMS 復旧ウィザードが利用可能な場合、SMS 復旧エキスパートが作成するタスク リストには SMS 復旧ウィザードを実行する時期が指定されています。

復旧シナリオの全事例を説明するのは文書の範囲外のため、復旧タスクは SMS 復旧エキスパートにだけ含まれています。しかし SMS 復旧エキスパートの画面の See all possible SMS recovery tasks リンクを使用して全タスクを印刷すると、個々の復旧タスクの説明を読むことができます。

障害した SMS サイトが Microsoft.com Web サイト上の回復ページへのアクセスを持たない機密保護されたネットワーク上にある場合は、復旧ツールとマニュアルを Web ページから取り外し可能なメディアにダウンロードして復旧タスクを印刷し、それからメディアを機密保護されたネットワークに移動します。PSS に電話してサポートを求めることもできます。

SMS 復旧ウィザード
SMS 復旧ウィザードは、復旧完了に必要な修復と再同期のタスクの一部を自動化します。また手動では不可能な修復の一部も行ないます。SMS 復旧ウィザードの実行はオプションですが、それを実行しない場合は SMS 復旧エキスパートの実行後に SMS 復旧ウィザードを実行する必要があります。

ACL リセットツール (ACLreset.exe)
SMS サーバー接続アカウントが使用したアクセス制御リストをリセットするには、ACL リセットを使用します。同じ名前で再作成した場合を含めて、新しく SMS サーバー接続アカウントを作成したら、そのたびに ACL リセットを実行します。しかし最初にサイトをセットアップする場合は、このツールを使用する必要はありません。

階層保守ユーティリティ (Preinst.exe)
以前はサイト ユーティリティ ツールと呼ばれていた階層保守ユーティリティ (Preinst.exe) は、階層マネージャの実行中に 階層マネージャにコマンドを渡します。サイトの問題を診断したり、サイトを修復したり、サイトの全 SMS サービスを停止するには、Preinst.exe を使用します。たとえば最初に親サイトから接続解除しないで子サイトを親サイトから削除して、SMS サイトを間違って削除したと仮定します。Preinst.exe を使用すると SMS 管理をバイパスして、間違って削除されたサイトを親の SMS サイト データベースから削除できます。

ソフトウェアメータリングの無効化ツール (Unenforce.exe)
ソフトウェア メータリングの実行を無効にするには、ソフトウェア メータリングの無効化ツール (Unenforce.exe) を使用します。通常、これは SMS 管理コンソール内の ソフトウェア メータリング管理ツールを通して実行すると最善です。しかしソフトウェア メータリング実行が有効のときにサイト サーバーが障害を受けると、Unenforce.exe を使用して素早くソフトウェア メータリング実行を無効にできます。これは、ライセンス バランスのエラーのため、利用者がアプリケーションへのアクセスを拒否される事態を防ぎます。ソフトウェア メータリング サーバー上の Microsoft Visual FoxPro® データベース内の BIPASSIVE フラグを 1 に設定すると、Unenforce.exe は動作します。

本ドキュメントの情報は、URL やインターネット Web サイトの参照を含めて、予告なしに変更されることがあります。特に断らない限り、例に挙げた企業、組織、製品、人物、およびイベントは、すべて架空のものです。実在の企業、組織、製品、人物、およびイベントとの関連は一切ありません。お客様は、すべての適用可能な著作権法に従う義務を負います。著作権で保証される権利を制限しない限り、Microsoft 社からの書面による明確な許可なしに、このドキュメントのいかなる部分についても、複製、検索システムへの格納または導入、およびいかなる形式、いかなる手段 (電気的または機械的送信、複写、録音など)、いかなる目的による送信もできません。

このドキュメントの内容にかかわる特許、特許出願、商標、著作権、またはその他の知的所有権については、Microsoft 社が保有する可能性があります。マイクロソフト社からの書面による使用許諾に明確に記述されている場合を除き、このドキュメントはお客様に対してこれらの特許、商標、著作権、またはその他の知的所有権についてのいかなる使用許諾も与えません。

© 2000 Microsoft Corporation. All rights reserved.

Microsoft、MS-DOS、Windows、Windows NT は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名、製品名は、各社の商標または登録商標です。

ページのトップへ