Notification Services のインスタンスの Windows アカウントの構成

更新 : 2006 年 4 月 14 日

Notification Services エンジンは、Notification Services 操作にとって重要です。このエンジンは、イベントの送信、通知の生成、および結果のメッセージの配布に使用される、ホストされるイベント プロバイダ、ジェネレータ、およびディストリビュータを実行します。エンジンは通常、NS$instanceName Microsoft Windows サービスで実行されますが、別のアプリケーションまたはプロセスでホストすることもできます。

エンジンは Windows アカウントのコンテキスト内で実行されます。NS$intanceName Windows サービスを使用する場合は、Notification Services のインスタンスを登録するときにサービスの実行に使用するアカウントを指定します。他のアプリケーションまたはプロセスでエンジンをホストしている場合は、アプリケーションまたはプロセスの Windows 権限を構成する必要があります。

エンジンに必要な Windows 権限

エンジンを実行するアカウントには、次の権限が必要です。

  • Notification Services フォルダ (%ProgramFiles%\Microsoft SQL Server\90\NotificationServices\n.n.nnn) とサブフォルダの読み取りおよび実行権限。既定では、ローカルの Administrators グループと Power Users グループのメンバのみが、これらのフォルダ内のファイルにアクセスできます。Notification Services は、インスタンスを登録するときに、サービス アカウントを Windows グループ SQLServer2005NotificationServicesUser$ComputerName に追加し、これらの権限を許可します。
  • レジストリの場所 HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Services\NotificationServices および HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services にあるレジストリ キーの読み取りと書き込み権限。この権限は、インスタンスの登録中にサービスを作成するときに Windows サービス アカウントに対して許可されます。
  • Windows アプリケーション ログへの書き込み権限
  • ファイル システム監視イベント プロバイダを使用しているアプリケーションの場合、イベント プロバイダは、イベントが削除されるフォルダ内のファイルを読み取って名前を変更できること、およびイベント スキーマ ファイル (.xsd) への読み取りアクセス権が必要です。
  • 通知の送信に File 配信プロトコルを使用するアプリケーションの場合、ディストリビュータには、通知が書き込まれるフォルダの書き込み権限が必要です。
  • XSLT コンテンツ フォーマッタを使用しているアプリケーションの場合、ディストリビュータには、XSLT ファイルが含まれるフォルダの読み取り権限が必要です。詳細については、「XSLT ファイルの場所」を参照してください。

また、エンジン アカウントには、ローカル Administrators グループのメンバシップが必要です。インスタンスがホストするアプリケーションがローカルのインターネット インフォメーション サービス (IIS) SMTP (Simple Mail Transfer Protocol) サービスを使用して通知を送信する場合、ディストリビュータは管理者のコンテキスト内でそれらの通知を送信する必要があります。

ms172585.note(ja-jp,SQL.90).gif重要 :
エンジンには、インスタンスによって使用される SQL Server データベースの権限も必要です。詳細については、「Notification Services のインスタンスの SQL Server 権限の構成」を参照してください。

Windows サービス アカウントの種類

Notification Services のインスタンスのエンジンが、別のアプリケーションまたはプロセスでホストされない場合、インスタンスは Windows サービスとして実行されます。Windows サービスは次の種類のアカウントで実行できますが、一部の種類は管理が難しいため、それらの使用は推奨されません。

  • **ドメイン ユーザー アカウント。**ドメイン アカウントを使用すると、アカウントに必要な正確な権限を指定できるため、ネットワーク リソースやデータベースへのアクセスを制御しやすくなります。サービスに許可されている権限を正しく制御するために、ドメイン管理者が Notification Services のインスタンスの新しいアカウントを作成できます。
  • **ローカル ユーザー アカウント。**ローカル コンピュータでユーザー アカウントを作成し、そのアカウントで NS$intanceName サービスを実行できます。このアカウントは、computer\username の形式を使用します。データベースが同一のサーバーに存在する場合は、このユーザー アカウントにもデータベース権限を許可できます。リモート コンピュータにデータベースがある場合は、Notification Services のインスタンスの SQL Server ログイン アカウントを構成する必要があります。
  • **NT AUTHORITY\Local Service アカウント。**これは、Microsoft Windows XP と Microsoft Windows Server 2003 で使用できるビルトイン アカウントです。Local Service アカウントは、リソースおよびオブジェクトへのアクセスについて Users グループのメンバと同じレベルの権限を持っています。このアカウントは、資格情報のない NULL セッションとしてネットワーク リソースにアクセスします。データベースが同一のサーバーに存在する場合は、このユーザー アカウントにデータベース権限を許可できます。ただし、Microsoft では、NS$intanceName サービスでのローカル サービス アカウントの使用をお勧めしていません。複数のサービスがこのアカウントを使用できるので、どのサービスが SQL Server データベースへのアクセス権を持っているかを制御するのは困難です。
  • NT AUTHORITY\Network Service アカウント。 これは、Windows XP と Windows Server 2003 で使用できるビルトイン アカウントです。Microsoft では、NS$intanceName サービスでのネットワーク サービス アカウントの使用はお勧めしていません。Network Service アカウントで実行しているすべてのサービスは、ネットワーク リソースにアクセスするときに、domain\remotecomputername$ アカウントにマップされます。複数のサービスがこのアカウントを使用できるので、どのサービスがネットワーク リソースへのアクセス権を持っていて、どのサービスが SQL Server データベースへのアクセス権を持っているのかを制御するのが困難です。
  • **Local System アカウント。**これはビルトイン アカウントです。このアカウントはすべてのローカル リソースに無制限にアクセスできるため、Microsoft では、NS$intanceName サービスでの Local System アカウントの使用をお勧めしていません。また、Local System アカウントで実行しているすべてのサービスは、ネットワーク リソースにアクセスするときに、domain\remotecomputername$ アカウントにマップされます。複数のサービスがこのアカウントを使用できるので、どのサービスがネットワーク リソースや SQL Server データベースへのアクセス権を持っているのかを制御するのが困難です。

Windows サービスのアカウントの指定

サービスの作成時に NS$intanceName Windows サービスの Windows アカウントを設定します。インスタンスを登録するときにサービスを作成します。アカウントを更新するには、インスタンスを再登録するか、Windows サービス マネージャでアカウントを変更します。

参照

概念

Notification Services エンジンのホスト
Notification Services Windows サービスの構成
Notification Services のインスタンスの SQL Server 権限の構成

その他の技術情報

Windows サービス アカウントの設定

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース 履歴

2006 年 4 月 14 日

変更内容 :
  • レジストリ キーの場所が更新されました。