Active Directory サービスと Windows 2000 または Windows Server 2003 のドメイン (第 1 部)

文書翻訳 文書翻訳
文書番号: 310996 - 対象製品
すべて展開する | すべて折りたたむ

目次

概要

この資料に記載されている情報の一部は、マイクロソフトプレスの提供によるものです。

この資料は、Active Directory サービスと、Windows 2000 または Windows Server 2003 のドメインについて説明した 2 部構成の資料の第 1 部です。第 2 部を参照するには、次のリンクをクリックしてください。
310997 Active Directory サービスと Windows 2000 または Windows Server 2003 のドメイン (第 2 部)
第 1 部では、以下のトピックについて説明します。
  • ドメインの階層構造
    • Windows 2000 および Windows Server 2003 のドメイン
      • ドメイン
      • ツリー
      • フォレスト
  • 信頼関係
    • 推移性の信頼関係
    • 一方向の信頼関係
    • クロスリンクの信頼関係
第 2 部では、以下のトピックについて説明されています。
  • 管理的な境界線
    • ドメイン
    • 組織単位
  • Active Directory サービスの相互運用性
    • ドメイン階層のエミュレート
    • ドメイン カタログ化 (ディレクトリ パーティション)
    • ディレクトリの分割
    • 異なるドメインのオブジェクトに関する情報の取得
      • ディレクトリの分散
      • ディレクトリの複製
    • 企業のカタログ化 (グローバル カタログ)
  • まとめ
この資料の内容は、『Microsoft Windows 2000 テクニカル リファレンス Active Directory 導入ガイド』の「第 3 章 Windows 2000 ドメインと Active Directory サービス」からの抜粋です。詳細については、『Microsoft Windows 2000 テクニカル リファレンス Active Directory 導入ガイド』を参照してください。 . この資料では、Microsoft Windows Server 2003 についての情報が更新されています。

詳細

Microsoft Windows 2000 または Windows Server 2003 のドメイン構造と関連するオブジェクトは、Windows 2000 や Windows Server 2003 で Active Directory サービスが果たす中心的役割と、スケーラブルでエンタープライズ クラスのディレクトリ サービスにするという設計要求を反映して、Windows NT 4 での姿から大きく変わりました。これらの変更には、推移性の信頼関係モデルへの移行のように明白なものもあれば、組織単位 (OU) の導入のように目立たないものもあります。変更が明白であるか目立たないものであるかにかかわらず、これらについて説明することは、Windows 2000 や Windows Server 2003 のドメインと Active Directory サービスとの相互作用および依存関係を理解するうえで重要です。Active Directory は、Windows 2000 および Windows Server 2003 のドメイン モデルをエミュレートするものであり、見方を変えれば、その逆であるともいえます。いずれにしても、Windows 2000 や Windows Server 2003 のドメインと Active Directory サービスは、相互に依存し、さらには互いの特性によって定義されています。ドメインと Active Directory サービスとの間にある密接で不可分な関係を知るには、Windows 2000 や Windows Server 2003 のドメイン モデルと、それがどのように Active Directory サービスと相互作用するのかの説明が必要になります。そのため、Windows 2000 および Windows Server 2003 のドメイン モデルの説明から始め、そのドメイン モデルが Windows NT ドメイン モデルと大きく変わっている理由を確認します。

Windows 2000 および Windows Server 2003 のドメイン

Windows NT 4 のドメイン モデルは、あまりスケーラブルなものではありませんでした。うわべをよく説明する方法もありますが、単純な事実は、(信頼関係が一方向で推移性のない) Windows NT 4 ドメイン モデルを使用した場合、巨大なエンタープライズでの実装には多くの管理オーバーヘッドが必要になるということです。主に信頼関係に対する新しいアプローチにより、 また、LDAP (Lightweight Directory Access Protocol) や DNS (ドメイン ネーム システム) などの業界標準に合わせて全体的なドメインの概念が刷新されたことにより、Windows 2000 や Windows Server 2003 のドメイン モデルでは、この問題が解消されています。

ドメインの階層構造

Windows 2000 や Windows Server 2003 のネットワークでは、ドメインが階層で管理されます。このドメインへの階層構造による新しいアプローチの中で、フォレストとツリーという概念が作り出されました。既にあるドメインの概念に加えて、これらの新しい概念を使用することで、組織は効果的に Windows 2000 や Windows Server 2003 のネットワーク構造を管理できるようになります。

ドメイン

Windows 2000 や Windows Server 2003 のドメイン モデルでも、ドメインという基本単位に変わりはありません。ドメインは管理上の境界であり、Windows 2000 や Windows Server 2003 では、DNS のドメインに対応する名前空間を表します (詳細については、「第 4 章」を参照してください)。Active Directory サービスと DNS との相互作用の詳細については「第 6 章 Active Directory サービスと DNS」を参照してください。

Windows 2000 や Windows Server 2003 の導入で最初に作成されるドメインは、ドメイン ツリーに作成される他のすべてのドメインのルートにあるという意味で、ルート ドメインと呼ばれます (ドメイン ツリーについては、次の「ツリー」を参照してください)。Windows 2000 や Windows Server 2003 のドメイン構造は DNS のドメイン階層に統合されており、その構造は、よく知られた DNS ドメイン階層の構造に似ています。ルート ドメインは microsoft.com や iseminger.com などのドメインで、これらは、該当する DNS 階層のルートであると同時に、Windows 2000 や Windows Server 2003 のドメイン構造のルートにもなっています。

Windows 2000 や Windows Server 2003 のドメイン階層に、その後作成されるドメインは、ルート ドメインの子ドメインになります。たとえば、msdn が microsoft.com の子ドメインの場合、msdn ドメインは msdn.microsoft.com になります。

おわかりのように、Windows 2000 や Windows Server 2003 では、ドメインがドメイン階層内のルート ドメインか子ドメインのどちらかになる必要があります。また、ドメイン名は指定された親ドメインの中で一意なものにする必要もあります。たとえば、ルート ドメイン microsoft.com の直接の子ドメインとして、msdn という名前のドメインを 2 つ定義することはできません。ただし、ドメインの階層全体では msdn というドメインを 2 つ定義できます。たとえば、msdn.devprods.microsoft.com と msdn.microsoft.com を定義できます。この場合、microsoft.com 名前空間に msdn という子ドメインが 1 つだけあり、devprods.microsoft.com 名前空間にも msdn という子ドメインが 1 つだけあります。

ドメインの背景には、論理分割の考え方があります。Windows 2000 や Windows Server 2003 のドメインを複数必要とするような大きな組織は、責任を分担したり作業を専門化する論理的な構造を持っています。組織を複数の単位 (部署) に分割することにより、その管理が容易になります。実際の組織は、より論理的な構造を提供すること、そしておそらくは組織の異なる部門間で作業を分担することを目的として分割されます。別の見方をすると、論理的なビジネス単位 (部署) が、より大きな傘 (多くの場合は企業) の下に 1 つにまとめられると、これらの論理的に異なる部分によって、より大きなエンティティが作り出されます。別々の部署の作業は分化され大きく異なるものであっても、各部署が全体として、より大きく、しかし論理的には完全なエンティティを形成します。この考え方は、Windows 2000 や Windows Server 2003 のドメインを、ツリーとして知られる、より大きな連続した名前空間のエンティティに集約するプロセスにも適用されます。

ツリー

ツリー (ドメイン ツリーと呼ばれることもあります) は、連続する名前空間を形成する Windows 2000 や Windows Server 2003 のドメインの集合体です。子ドメインを作成するとすぐにドメイン ツリーが形成され、指定したルート ドメインに関連付けられます。技術的な定義としては、ツリーは連続する DNS の名前付けの階層です。概念的なイメージとしては、ドメイン ツリーは、下に伸びる枝 (子ドメイン) を持つ上下を反転した (ルート ドメインを一番上にした) 木に似ています。

ドメイン ツリーの作成により、組織は内部にドメインの論理構造を作り、DNS の名前空間が反映されるように、その構造を適合させることができます。たとえば、David Iseminger and Company という会社が、micromingers.iseminger.com というドメインを持ち、営業、経理、製造など、さまざまな論理部門が社内にあるとします。この場合、ドメイン ツリーは、図 3-1 のようになると考えられます。

元に戻す画像を拡大する
micromingers.iseminger.com ドメイン ツリーの図

図 3-1 : micromingers.iseminger.com のドメイン ツリー

: ここまで、iseminger.com があちこちで使用されていることに気が付かれたでしょう。これは別に筆者の自慢ではありません。出版元が強く主張した法的な考慮 ("少しでも問題になりそうなドメインは避け、著者が所有しているものか、それ以外では絶対にだれも使用しないようなもの" にしたい) によるものです。筆者は www.iseminger.com というサイトを運営しているため、このドメインが本のどこでも使用されることになりました。本当はもっと独創的な名前を考えていたのですが、残念ながら、弁護士を困らせるわけにはいきません。

社内に論理的な部署を設けるこうした組織構成は、1 つの DNS ドメインを持つ会社では非常にうまく機能します。しかし、内部に複数の "会社" を持つ大企業の問題にも対処する必要があります。この問題は、Windows 2000 および Windows Server 2003 のフォレストによって解決されます。

フォレスト

組織によっては、それ自体は単一のエンティティであっても、iseminger.com と microsoft.com など、複数のルート ドメインを持つものがあります (例として、ここでは David Iseminger and Company という架空の会社を考えます)。このような場合、複数のドメイン ツリーで、フォレストと呼ばれる不連続な名前空間を形成できます。フォレストとは、指定した企業を形成する、1 つ以上の連続したドメインのツリー階層です。論理的には、ドメイン ツリーに 1 つのドメインしか含まれない組織もフォレストと見なされます。この違い、この章の後半の Active Directory がどのようにして Windows 2000 や Windows Server 2003 のドメインやフォレストと連携するのかの説明で、より重要になります。

フォレスト モデルを使用すると、連続した名前空間を形成しない組織が、集約されたドメイン構造で組織全体としての連続性を維持できます。たとえば、David Iseminger and Company 社 (iseminger.com) が、独自のディレクトリ構造を持つ Microsoft という別の会社を買収するだけの資金を工面できたとします。この場合、2 つのエンティティのドメイン構造は、1 つのフォレストに結合できます。1 つのフォレストにまとめることには、3 つのメリットがあります。第 1 に、より簡単に信頼関係を管理できるようになります (一方のドメイン ツリーのユーザーが他方のツリーにあるリソースにアクセスできます)。第 2 に、グローバル カタログにフォレスト全体のオブジェクト情報が収容されるため、企業全体の検索が可能になります。第 3 に、Active Directory のスキーマがフォレスト全体に適用されます (スキーマの技術的な詳細については、「第 10 章」を参照してください)。図 3-2 は、iseminger.com と microsoft.com のドメイン構造の結合を示したものです。ルート ドメインの間の線は、両者の間に存在し、フォレストを確立している Kerberos の信頼関係を示しています (Kerberos プロトコルの詳細については、「第 8 章」を参照してください)。

フォレストには、複数のドメイン ツリーを含めることができますが、それが表すものは 1 つの企業です。フォレストを作成することで、ドメインのすべてのメンバが (グローバル カタログを利用できるため) 情報を共有できます。次の疑問は、フォレスト内のドメイン ツリーは、(フォレストによって表される) 企業全体が 1 つの単位として機能するための関係をどのようにして確立するのか、ということです。この疑問に対する答えは、信頼関係の説明で提供されます。

信頼関係

Windows NT 4 ドメインと Windows 2000 や Windows Server 2003 のドメインとの最も重要な違いは、おそらく同じ組織内のドメイン間における信頼関係の適用と構成です。Windows 2000 や Windows Server 2003 では、(Windows NT 4 のような) 一方向の信頼関係を網の目状に確立するのではなく、(新しい) ドメイン ツリー構造を上下に流れる推移性の信頼関係が導入されます。このモデルによって、多くの例で説明するとおり、Windows のネットワーク管理が単純化されます。これを数字で示します。次の 2 つの数式 (この数式は説明用であって、苦労して暗記するものではありませんので、いま少しお付き合いください) は、各アプローチで発生する管理上のオーバーヘッドを示したものです。数式は、それぞれの信頼アプローチで必要となる信頼関係の数を表しています。ここで、n はドメインの数です。
Windows NT 4 ドメイン -- (n * (n-1))
Windows 2000 または Windows Server 2003 ドメイン --(n-1)
具体的な例として、少数のドメインがあるネットワークを取り上げ、ドメイン モデルによる違いを確認することにします。(ドメイン数を 5 とすれば、次の数式で n= 5 となります)。
Windows NT 4.0 ドメイン : (5 * (5-1)) = 20 信頼関係
Windows 2000 または Windows Server 2003 ドメイン : (5 - 1) = 4 信頼関係
元に戻す画像を拡大する
ドメイン ツリー (Iseminger.com と microsoft.com) 結合の図

図 3-2 : ドメイン ツリー (Iseminger.com と microsoft.com) の結合

管理が必要な信頼関係の数に大きな違いが見られますがこの減少だけが、ドメインに対する新しいアプローチの最も注目すべき利点というわけではありません。Windows 2000 や Windows Server 2003 のドメインでは、デフォルトで信頼関係の作成と導入が行われます。管理者がドメイン コントローラをインストールする以外に何もしなくても、信頼関係は既に存在します。信頼関係の自動作成は、(Windows NT 4 ドメインとは異なり) Windows 2000 や Windows Server 2003 のドメインが階層的に作成されているという事実に結びついています。つまり、特定のドメイン ツリーには、1 つのルート ドメインと子ドメインがある他には何もありません。これにより、Windows 2000 や Windows Server 2003 は、指定されたドメイン ツリーにどのドメインが含まれているのかを自動的に認識し、ルート ドメイン間に信頼関係が確立されれば、フォレストにどのドメイン ツリーが含まれるのかを自動的に認識することができます。

対照的に、Windows NT 4 ドメインの場合、管理者はドメイン間に信頼関係を作成し、どの方向に信頼関係が流れているか、そしてどのように両ドメインのユーザー権利に影響するかを別に管理する必要があります。この違いは重要です。前に説明したとおり、Windows 2000 や Windows Server 2003 のドメインでは、信頼関係の実装がより直感的になるため管理者の負荷は軽減されます。これらすべては、新しい信頼関係モデルとドメインやドメイン ツリーに対する階層的なアプローチによるものです。

Windows 2000 および Windows Server 2003 には、3 種類の信頼関係があります。それぞれは、ドメイン構造内での特定の必要性を満たしています。Windows 2000 や Windows Server 2003 のドメインで利用可能な信頼関係を次に示します。
  • 推移性の信頼関係
  • 一方向の信頼関係
  • クロスリンクの信頼関係

推移性の信頼関係

推移性の信頼関係では、他のドメインを経由して流れることができる信頼関係が 2 つのドメイン間で確立されます。図 3-3 に示すように、ドメイン A がドメイン B を信頼し、ドメイン B がドメイン C を信頼している場合、本質的にドメイン A はドメイン C を信頼することになります。

元に戻す画像を拡大する
3 つのドメイン間での推移性の信頼関係の図

図 3-3 : 3 つのドメイン間での推移性の信頼関係

推移性の信頼関係により、一方向で推移性を持たない網の目状の信頼関係の管理がなくなるため、ドメイン間の信頼関係の維持にかかる管理オーバーヘッドが大幅に軽減されます。Windows 2000 および Windows Server 2003 では、親ドメインと子ドメイン間の推移性の信頼関係は、ドメイン ツリーに新しいドメインが作成されると自動的に確立されます。推移性の信頼関係は、Windows 2000 または Windows Server 2003 のドメイン、および同じドメイン ツリーまたはフォレスト内のドメインに限定されます。下位レベル (Windows NT 4 以前) のドメインとの間で推移性の信頼関係は作成できません。また、Windows 2000 や Windows Server 2003 の 2 つのドメインが別々のフォレストに存在している場合、それらの間に推移性の信頼関係は作成できません。

一方向の信頼関係

一方向の信頼関係は推移性でないため、関連するドメインの間だけで信頼関係が定義され、双方向でもありません。しかし、(互いに反対向きの) 独立した一方向の信頼関係を 2 つ作成して、2 方向の信頼関係を作成することはできます。これはちょうど、純粋な Windows NT 環境での方法と同じです。ただし、このように一方向の信頼関係が両方向にあったとしても、推移性の信頼関係と等価にはならないことに注意してください。一方向の信頼関係は、関連する 2 つのドメインの間でしか有効ではありません。Windows 2000 や Windows Server 2003 の一方向の信頼関係は、Windows NT 4 の信頼関係とまったく同じもので、使用される状況は限られています。最も一般的な状況を 2 つ以下に示します。

第 1 に、Windows NT 4 ドメインなどの下位レベルのドメインと新しい信頼関係を確立する必要がある場合に、一方向の信頼関係を使用することがよくあります。下位レベルのドメインは、Windows 2000 や Windows Server 2003 の推移性の信頼関係環境 (ツリーやフォレストなど) には参加できないため、Windows 2000 または Windows Server 2003 のドメインと下位の Windows NT ドメインとの間で信頼関係を結べるようにするには、一方向の信頼関係を確立する必要があります。

: 一方向の信頼関係に関するこうした状況は、移行プロセス (既存の Windows NT 4 ドメイン モデルを Windows 2000 や Windows Server 2003 のドメイン、ツリー、フォレストのモデルにアップグレードする場合など) には当てはまりません。Windows NT 4 から Windows 2000 または Windows Server 2003 への移行全体で、すべてのドメインが Windows 2000 または Windows Server 2003 になり、推移性の信頼関係の環境が確立されるまで、元の確立された信頼関係は、移行プロセスが完了しても維持されます。移行プロセスの詳細については、「第 11 章 Active Directory サービスへの移行」を参照してください。

第 2 に、同一の Windows 2000 または Windows Server 2003 フォレスト内にないドメイン間で信頼関係を確立する必要がある場合に、一方向の信頼関係を使用できます。異なる Windows 2000 または Windows Server 2003 フォレスト内にあるドメイン間で一方向の信頼関係を使用すると、フォレスト全体に影響する信頼関係を作成するのではなく、特定のドメインに対する信頼関係だけを作成して維持できます。具体的な例で説明します。

ある組織に製造部門と営業部門があると仮定します。製造部門では、いくつかのプロセス情報 (Windows 2000 または Windows Server 2003 のドメインにあるサーバーに保存されている) をある標準化団体と共有したいと考えています。しかし、営業部門は、自分たちのドメインのサーバーに保管されている売上やマーケティングに関する重要な情報は、標準化団体に非公開とすることを求めています (売上があまりにも好調で、標準化団体に公開してしまうと "独占状態" として営業活動を妨害されかねない、というシナリオが考えられます)。一方向の信頼関係を使用すれば、営業情報は安全です。必要なアクセスを業界団体に提供するには、製造部門のドメインと標準化団体のドメイン間に一方向の信頼関係を確立します。一方向の信頼関係には推移性がないため、信頼関係は関係する 2 つのドメイン間だけで確立されます。また、製造部門のドメインは信頼する側のドメインであるため、標準化団体のドメインにあるリソースを製造部門のドメインのユーザーが利用することはできません。

もちろん、ここで説明したどちらのシナリオでも、一方向の信頼関係を 2 つ別個に用意すれば、双方向の信頼関係を作成できます。

クロスリンクの信頼関係

クロスリンクの信頼関係は、パフォーマンス向上の目的で使用されます。クロスリンクの信頼関係を使用すると、信頼関係を確認するための仮想的なパスがツリーやフォレストの階層内に作成され、信頼関係の確認 (または否認) をすばやく行えるようになります。短い説明としてはこれでよいとしても、クロスリンクの信頼関係が使用される方法と理由を本当に理解するには、まず Windows 2000 や Windows Server 2003 のドメイン間で認証がどのように処理されるのかを理解する必要があります。

Windows 2000 や Windows Server 2003 のドメインが、自分のドメインにないリソースに対してユーザーを認証する (または認証要求を検証する) 必要がある場合、DNS のクエリと似た方法を取ります。Windows 2000 や Windows Server 2003 は、最初に、要求を発行しているドメインにそのリソースがあるかどうかを確認します。リソースがローカル ドメインにない場合、ドメイン コントローラ (具体的には、ドメイン コントローラ上のキー配布センター [KDC]) は、階層構造で次のドメイン (必要に応じて上下どちらか) にあるドメイン コントローラへの参照をクライアントに渡します。次のドメイン コントローラでも、そのリソースが存在するドメインに到達するまで、この "ローカル リソース" のチェックが続行されます (このクエリ プロセスの詳細については、「第 8 章」を参照してください)。

この "ドメイン ツリー内を歩き回る" 機能は非常に優れたものですが、実際にドメインの階層全体を "歩く" には時間がかかり、問い合わせに応答するまでのパフォーマンスに影響を与えます。これをわかりやすく説明する例として、次のような状況を考えます。

ターミナル ウィングが 2 つある V 字形の空港にいるとします。ターミナル A は V 字形の左側、ターミナル B は V 字型の右側にあります。ゲートには順番に番号が付けられていて、ターミナル A とターミナル B の 1 番ゲートは、V 字型の元近くにあり (そこで 2 つのターミナルは接続されています)、15 番ゲートは V 字の元から一番離れたところにあります。そして、すべてのゲートは V 字の内側で接続されています。今、フライトに間に合うように、急いでターミナル A の 15 番ゲート (V 字の末端にあります) に到着しましたが、搭乗する飛行機が実際はターミナル B の 15 番ゲートから離陸することに気が付きます。窓の外を見ると、ターミナル B の 15 番ゲートに飛行機が見えましたが、このゲートに行き着くには、ターミナル A を V 字の元まで戻るために全行程を走り、ターミナル B の 15 番ゲートまで向かわなければなりません。しかし、飛行機を見つけたちょうどそのとき、飛行機は飛び去ってしてしまいました。待合室に座って、次の飛行機に乗るまでの 2 時間をそこで過ごしているとき、ターミナルの端と端を結ぶスカイブリッジがあれば、ターミナル A の 15 番ゲートから、ターミナル B の 15 番ゲートまですばやく行き着くことができたのに、と思うはずです。これは、各ターミナルの 15 番ゲート間を多くの人が行き交うならとても意味があるものになります。

同様に、クロスリンクの信頼関係は、フォレストまたはツリーの階層構造内で論理的に離れており、大量の認証トラフィックがあるドメイン間の認証ブリッジとして機能することができます。大量の認証トラフィックとは何でしょうか。Windows 2000 または Windows Server 2003 のドメイン ツリーの 2 つのブランチ考えてみます。最初のブランチには、ドメイン A、B、C、D があります。A は B の親で、B は C の親です。C は D の親です。2 つ目のブランチには、ドメイン A、M、N、P があります。A は M の親で、M は N の親です。N は P の親です。この構造を図 3-4 に示します。

元に戻す画像を拡大する
ドメインの階層例の図

図 3-4 : ドメインの階層の例

ドメイン D には、なんらかの理由でドメイン P のリソースを定期的に使用するユーザーが存在します。ドメイン D のユーザーがドメイン P にあるリソースを使用する場合、Windows 2000 および Windows Server 2003 では、参照パスのツリーの元 (この場合ドメイン A) まで上に戻り、ドメイン P に着くまでドメイン ツリーの該当するブランチを下ることによって、その要求を解決します。これらの認証が進行中の場合、このアプローチは大量のトラフィックを発生させます。これを解決するには、ドメイン D と P の間にクロスリンクの信頼関係を作成します。これによって、ドメイン間の認証は、ドメイン ツリーを元 (またはツリーが枝分かれしているベース ドメイン) まで戻らなくても行うことができるようになります。その結果、認証について、より高いパフォーマンスが得られます。

関連情報

この資料の内容は、マイクロソフトプレスの書籍『Microsoft Windows 2000 テクニカル リファレンス Active Directory 導入ガイド』から抜粋したものです。

元に戻す画像を拡大する
Picture of Active Directory Services for Microsoft Windows 2000 Technical Reference book


詳細については、『Microsoft Windows 2000 テクニカル リファレンス Active Directory 導入ガイド』 を参照してください。

本書およびマイクロソフトプレス発行の他の出版物については、 http://www.microsoft.com/japan/info/press/ を参照してださい。

関連情報

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 310996 (最終更新日 2003-12-03) を基に作成したものです。

プロパティ

文書番号: 310996 - 最終更新日: 2007年12月3日 - リビジョン: 5.2
この資料は以下の製品について記述したものです。
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows 2000 Professional
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
キーワード:?
kbinfo KB310996
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com