現在オフラインです。再接続するためにインターネットの接続を待っています

ADPREP/FORESTPREP を実行するか、新しい OS のバージョンのドメイン コント ローラーをインストールするときに、「同じリンクの識別子の属性が既に存在」エラー

Windows Server 2003 のサポートは 2015 年 7 月 14 日で終了しています

Windows Server 2003 のサポートは 2015 年 7 月 14 日で終了しています。この変更は、ソフトウェアの更新プログラムおよびセキュリティ オプションに影響しています。 この変更の意味および保護された状態を維持する方法について説明します。

重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。

英語版 KB:969307
現象
Windows Server 2003 ベースのコンピューターに、フォレストのスキーマを拡張するには、ADPREP/FORESTPREPコマンドを実行するコマンドが失敗し、次のエラー メッセージが表示されます。

"<host name="" of="" schema="" master="">"への接続
SSPI を使って現在のユーザーとしてログインします。
ファイル"C:\WINDOWS\system32\sch44.ldf"からディレクトリをインポートします。
エントリを読み込んでいます.
43 行目でエラーを追加します実行するしたくない。
サーバー側のエラーは「スキーマ更新の失敗:、同じ linkidentifier を持つ属性が既に存在します。」
7 のエントリを正しく修正しました。
プログラムでエラーが発生します。
エラー: ファイルからのインポート、C:\WINDOWS\system32\sch44.ldf でした。エラー ファイルは、ldif.err.44 に保存されます。</host>

さらに、Ldif.err.44 エラー ファイルを開くには、次のようなエラー メッセージが表示されます。

エントリの DN: CNms-DS-ブリッジヘッドにサーバーの使用CN = スキーマ、CN = 構成、DC = = 43 行目でエラーを<forest root="" domain="">追加: したくないを実行するサーバー側のエラーは」スキーマ更新の失敗: 同じリンクの識別子を持つ属性が既に存在します」。エラーが発生して、プログラムで</forest>

の他の属性もこのエラーが発生します。たとえば、 camDBSignonRefオブジェクトにスキーマの変更がリンク Id 2046 を割り当てるエラーが発生します。マイクロソフト、属性ms-PKI-DPAPIMasterKeysは、この更新では、Windows Server 2008 のスキーマの linkID を持っています。
原因
ADPREP/FORESTPREPコマンドでスキーマ パーティションをリンク、スキーマ パーティションには、既存のオブジェクトに既に割り当てられている Id を使用して新しいオブジェクトを追加しようとしたときに、このエラーが発生します。

重要: フォレストには、スキーマの拡張が失敗した時点で、重大な問題がない破損した状態ではない前の状態にリセットする必要があります。ただし、お勧めに従うこと問題に迅速に。次に、いる場合は、フォレストの回復を実行するには、いない変更は失われます多くフォレストの巻き戻しと。
解決方法
少なくとも、このセクションに記載されている修復手順を実行する必要があります Windows Server 2003 スキーマ マスター上で。プロシージャは、他の属性にも適用できます。

動作の Active Directory のレプリケーションでスキーマの不一致エラーが発生することができます可能性があるため、スキーマ パーティションは、既存のオブジェクトのリンク Id は変更されません。

重要: この問題を解決するために、Microsoft カスタマー サポート サービスに連絡することを強くお勧めします。フォレストはない回復不可能な状態にこの時点では、自分で修復を続行する場合知らない可能性があります別と誤って認識を行い、フォレストのフォレスト回復を実行する必要があること多くの損傷します。したがってが有効なシステム状態のバックアップを 2 つ以上のドメイン コント ローラーから、フォレスト内のすべてのドメインで続行する前にする必要があります。

手動でこの問題を解決するには、以下の手順を実行します。
  1. 追加されている、競合する linkID を識別します。これには、スキーマ定義ファイルでは、Ldif.err を確認します。<Number></Number>ファイルです。この場合が表示される属性 CN = ms-DS-ブリッジヘッドにサーバーの使用、CN スキーマ、CN = 構成、DC = =<forest name=""></forest>sch44.ldf では 2160年のリンク Id が割り当てられます。
  2. 競合の linkID を現在所有しているスキーマ パーティション内のオブジェクトを識別します。確認する既存のオブジェクトは、Sch<xx>内のオブジェクトと競合する linkID を割り当てられたターゲット スキーマ マスターでスキーマを検索することができます .ldf ファイル。これを行うには、REPADMIN、LDIFDE、LDP を使用します。EXE、または同等のツールは。いくつかの例を次にします。

    REPADMIN 検索します。
    </xx>
    repadmin /showattr fsmo_schema: ncobj:schema: /filter:"(linkid=2160)" /subtree


    LDIFDE を検索。
    LDIFDE /f <filename> /d "CN=Schema,CN=Configuration,DC=<forest root domain>" /r (linkid=2160) 


    LDP を検索。
    BaseDN: CN=Schema,CN=Configuration,DC=<forest name>Scope : SubtreeFilter: (linkid=2160)
  3. Ms-DS-ブリッジヘッドにサーバーの使用またはms-PKI の DPAPIMasterKeysなどの影響を受ける属性に含まれているスキーマ ファイルを検索します。スキーマ ファイルは \support\adprep にあります。ファイルが競合している属性を検索します。たとえば、次のコマンドを使用します。
    Findstr の ms-DS-ブリッジヘッドにサーバーの使用 d:\support\adprep\sch*.ldf
  4. テキスト エディターでファイルを検索するを開きます。
  5. スキーマ パーティションは、既存のオブジェクトの Linkid と競合する .ldf ファイル、Sch<xx>内の前方リンクのオブジェクトに新規リンク Id を割り当てます。既知のオブジェクト識別子 (OID とも呼ばれます)、割り当てを割り当てることによってこれを実現する「1.2.840.113556.1.2.50」、SCH<xx>内すべての前方リンク属性の linkID フィールドをターゲット フォレスト内の既存のオブジェクトと競合している Linkid .ldf です。「1.2.840.113556.1.2.50」は、オブジェクト識別子は、ターゲット スキーマ独自リンク自動的に生成された Id を割り当てます。

    Linkid 2160 の Sch44.ldf で定義されている、たとえば、この問題を解決するのにはCN = ms-DS-ブリッジヘッドにサーバーの使用、これらの手順に従います。</xx></xx>
    1. Sch44.ldf ファイルを開きます。、次のテキストを参照してくださいCN = ms-DS-ブリッジヘッドにサーバーの使用、CN スキーマ、CN = 構成、DC = =<forest name=""></forest>
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsSchemaAddadminDescription: List of bridge head servers used by KCC in the previous run.adminDisplayName: ms-DS-BridgeHead-Servers-UsedattributeID: 1.2.840.113556.1.4.2049attributeSyntax: 2.5.5.7cn: ms-DS-BridgeHead-Servers-UsedinstanceType: 4isSingleValued: FALSElDAPDisplayName: msDS-BridgeHeadServersUsedlinkID: 2160objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=XobjectClass: attributeSchemaoMObjectClass:: KoZIhvcUAQEBCw==oMSyntax: 127schemaFlagsEx: 1schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg==searchFlags: 0showInAdvancedViewOnly: TRUEsystemFlags: 25
    2. 新しい txt ファイルでは、このテキストをコピーし、新しい名前を使用して、ファイルを保存します。たとえば、「新規-BridgeHeadServersUsed.ldf」としてファイルを保存

      注: <b>既存のスキーマ ファイルを変更します。
    3. LinkID フィールド「2160」から「1.2.840.113556.1.2.50」Windows Server スキーマ操作マスターで Linkid を独自の自動生成をトリガーするを変更します。Sch44.ldf ファイルには、次のテキストを表示するCN = ms-DS-ブリッジヘッドにサーバーの使用、CN スキーマ、CN = 構成、DC = =<DC></DC>
      dn: CN=ms-DS-BridgeHead-Servers-Used,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsSchemaAddadminDescription: List of bridge head servers used by KCC in the previous run.adminDisplayName: ms-DS-BridgeHead-Servers-UsedattributeID: 1.2.840.113556.1.4.2049attributeSyntax: 2.5.5.7cn: ms-DS-BridgeHead-Servers-UsedinstanceType: 4isSingleValued: FALSElDAPDisplayName: msDS-BridgeHeadServersUsedlinkID: 1.2.840.113556.1.2.50objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=XobjectClass: attributeSchemaoMObjectClass:: KoZIhvcUAQEBCw==oMSyntax: 127schemaFlagsEx: 1schemaIDGUID:: ZRTtPHF7QSWHgB4epiQ6gg==searchFlags: 0showInAdvancedViewOnly: TRUEsystemFlags: 25
    4. 修正後の属性の定義をする前に、次のセクションを追加します。
      dn: changetype: modifyadd: schemaupgradeinprogressschemaupgradeinprogress: 1-

      ハイフン (-) のみが含まれている行を次の空行は重要です。
  6. Linkid を前方リンク属性を変更した場合は、後方リンク属性の Linkid を更新します。Active Directory 内のオブジェクトによって、後方リンク属性. その他のオブジェクトではないです。この例で使用されているms DS-ブリッジヘッド-サーバーで使用されるオブジェクトの後方リンクの属性がありません。変更されるオブジェクトが、後方リンクの属性が別のオブジェクトを使用するかどうかを確認するがあります。場合は、影響を受けるオブジェクトの後方リンクのオブジェクトには、後方リンク オブジェクトと同じ方法で変更しなければなりません。

    スキーマ定義ファイルで、次の奇数番号 linkID を探すことにより、後方リンク属性を検索できます。通常、後方リンク属性は、次の属性で、スキーマ ファイルに記載されています。しかし、別のファイル内にある場合があります。たとえば、問題、linkID を識別するまたは2050年として属性とCN = ms-DFSR-ComputerReference, CN スキーマ、CN = 構成、DC = =<forest name=""></forest>、後方リンクは havelinkID 2051。リンク ID 2051 を検索するには、次のコマンドを実行します。

    Findstr /c:"linkid: 2051" d:\support\adprep\sch*.ldf
    後方リンクが見つかった場合、コピー、属性定義スキーマ インポート ファイルから新しいインポート ファイルに、前方リンク属性をコピーするのと同じ方法で。

    注: <b>後方リンク オブジェクトの linkID 定義は、ハード コード (数値) id です。定義を変更する必要があります-[戻る] リンクを自動的に生成するオブジェクトのオブジェクト識別子を有効にします。

    このシナリオでは、および前方リンク オブジェクトの ldapDisplayName を後方リンク オブジェクトの linkID を設定することによってこの前方リンクの後方リンクが作成されます。MsDS BridgeHeadServersUsed、後方リンク属性の場合は、linkID 行は、次のようになります。

    linkID: msDS-BridgeHeadServersUsed
  7. 要約すると、スキーマのインポート ファイル新規 BridgeHeadServersUsed.ldfnow が最大で 4 つのコマンドです。コマンドは次の順序で表示されます。
    1. スキーマ インポート モード (schemaupgradeinprogress) を有効にします。
    2. 前方リンク属性の定義を修正しました。
    3. スキーマ キャッシュをリロードする命令
    4. オプション: 後方リンク属性の定義を修正します。
  8. 保存し、closethe、作成したカスタム属性のスキーマの更新プログラム ファイルです。
  9. スキーマに新しいユーザー設定の変更をインポートします。たとえば、次のコマンドを使用します。
    LDIFDE/i の/f - BridgeHeadServersUsed.ldf 新しい/j。

    Ldif.err と Ldif.log ファイルのエラーを検査します。エラーがある場合は、この時点で Microsoft カスタマー サポート サービスに問い合わせてください。
  10. スキーマの更新処理を再度実行します。スキーマ拡張ツール ADPREP を実行する場合は、/forestprepパラメーターを使用してツールを再実行します。ドライブのインストールにサーバー マネージャーを使用していたかどうかは最初上位レベル、ドメイン コント ローラーのサーバー マネージャーからインストール プロセスを繰り返す必要があります。
  11. LDIF インポート Ldif.err.44 新規 BridgeHeadServersUsed.ldf の属性が既に存在しているという事実についての警告を含めることがなどを記録します。ただし、スキーマの更新が正常に完了された今は、期待します。

    エラーがある場合は、この時点で Microsoft カスタマー サポート サービスに問い合わせてください。

詳細
リンク Id を取得する方法の詳細については、次の Microsoft Developer Network (MSDN) web サイトを参照してください。詳細については、自動生成された linkID、次の MSDN web サイトを参照してください。LinkID 属性の詳細については、次の MSDN web サイトを参照してください。

警告: この記事は自動翻訳されています

プロパティ

文書番号:969307 - 最終更新日: 05/07/2015 07:21:00 - リビジョン: 7.0

Windows Server 2012 R2 Standard, Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows Server 2008 R2 Service Pack 1, Windows Server 2008 Service Pack 2, Microsoft Windows Server 2003 Service Pack 2

  • kbexpertiseadvanced kbsurveynew kbtshoot kbmt KB969307 KbMtja
フィードバック