適用対象: WindowsのSQL Server
まとめ
この記事は、SQL Server エージェント サービス アカウントをグループ管理サービス アカウント (gMSA) に変更した後に開始されるSQL Server エージェントジョブ ステップエラーのトラブルシューティングに役立ちます。 新しい実行 ID に必要な共有、NTFS、プロキシ、資格情報、またはパッケージのアクセス許可がないために失敗する SQL Server Integration Services (SSIS)、メンテナンス プラン、バックアップ、PowerShell、CmdExec ジョブ ステップについて説明します。
開始する前に、前提条件を確認し、「gMSA を使用したSQL Serverセットアップ、起動、認証エラーのトラブルシューティング」のクイック検証チェックリストを実行します。
Symptoms
- SQL Server エージェントが開始されますが、SSIS、メンテナンス プラン、バックアップ、PowerShell、または CmdExec ジョブ ステップは失敗します。
- SQL Server エージェント サービス アカウントが gMSA に変更された後、ジョブ ステップが失敗し始めました。
- エラーにより、コンポーネント、ファイル、プロキシ、資格情報、共有、または NTFS のアクセス許可が見つかりません。
原因
通常、サービス アカウントの変更に続くジョブ ステップの失敗は、gMSA パスワード管理の問題ではなく、新しい ID のアクセスの問題です。 プロキシを使用しないジョブ ステップは、SQL Server エージェント サービス アカウントとして実行されるため、前のアカウントが持っていたすべての共有、NTFS、および宛先のアクセス許可を gMSA に付与します。
SQL Server エージェント ジョブの失敗を診断する
- 失敗したジョブ ステップ サブシステムと、ジョブ履歴の最初のアクション可能なエラーを特定します。
- SQL Server エージェント サービス アカウントまたはプロキシ アカウントの手順を実際に実行する ID を確認します。 詳細については、「SQL Server エージェント プロキシの作成を参照してください。
- ネットワーク パスと宛先リソースの場合は、末尾のドル記号を含め、
<DomainName>\<GmsaName>$形式で共有アクセス許可と NTFS アクセス許可が gMSA に付与されていることを確認します。<DomainName>と<GmsaName>をドメイン名とアカウント名に置き換えます。 - バックアップ ターゲット、リンク サーバー、ファイル共有など、gMSA に宛先サービスに必要なアクセス許可があることを確認します。
予期される結果: 実行 ID には、ジョブ ステップが使用するすべてのリソースに対する明示的なアクセス許可があります。
SQL Server エージェント ジョブの失敗を解決する
ジョブ履歴の最初のアクション可能エラーと一致するソリューションを使用します。
実行 ID に宛先リソースのアクセス許可を付与する
失敗したジョブ ステップを実行するアカウントを決定します。
- プロキシを指定しない CmdExec ジョブ ステップは、SQL Server エージェント サービス アカウントで実行されます。
- SQL Server エージェント プロキシを指定するジョブ ステップは、プロキシ資格情報に格納されている Windows アカウントの下で実行されます。
- Transact-SQL ジョブ ステップでは、SQL Server エージェント プロキシは使用されません。 ジョブ所有者のセキュリティ コンテキストで実行されます。 ジョブ所有者が
sysadmin固定サーバー ロールのメンバーである場合、別のデータベース ユーザーが指定されていない限り、ステップは SQL Server エージェント サービス アカウントで実行されます。
実行 ID に必要なアクセス許可を付与します。
- ジョブ ステップが SQL Server エージェント サービス アカウントで実行され、そのアカウントが gMSA の場合は、末尾のドル記号 (
$) を含む ID の gMSA コンピューター アカウント形式を指定します。 たとえば、「CONTOSO\SQLAgentSvc$」のように入力します。 - ジョブ ステップでプロキシを使用する場合は、SQL Server エージェント サービス アカウントまたは gMSA に対して自動的にではなく、プロキシ資格情報に関連付けられているWindows アカウントにアクセス許可を付与します。
- ファイル共有の場合は、SMB 共有と基になる NTFS フォルダーの両方の実行 ID に必要なアクセス許可のみを付与します。
- ジョブ ステップが SQL Server エージェント サービス アカウントで実行され、そのアカウントが gMSA の場合は、末尾のドル記号 (
ID を確認し、アクセスを共有するには、CmdExec ジョブ ステップで、失敗したステップと同じ 実行構成 を使用する次のコマンドを一時的に実行します。
whoami dir "\\FileServer\BackupShare"予期される結果:
whoamiコマンドは予想される実行 ID を返し、dirコマンドは共有の内容を一覧表示します。テスト後に一時的な診断手順を削除します。
SQL Server エージェント プロキシ、資格情報、またはジョブ ステップ実行コンテキストを修正する
失敗したジョブ ステップを確認し、そのサブシステムと 実行設定を 確認します。 プロキシをサポートするサブシステムの場合は、次の条件を満たすプロキシを作成または使用します。
- 必要なWindows アカウントの資格情報を参照します。
- ジョブ ステップ サブシステムに対して有効です。
- ジョブを所有または実行するログインロールまたはSQL Server エージェントロールで使用できます。
- ジョブ ステップで必要なアクセス許可を持つアカウントを使用します。
プロキシをジョブ ステップに割り当てます。 プロキシを作成しても、資格情報に格納されているアカウントにリソースのアクセス許可は付与されません。 これらのアクセス許可を個別に付与し、最小特権の原則に従います。 詳細については、「SQL Server エージェント プロキシの作成を参照してください。
SSIS アクセス許可またはパッケージ アクセス エラーを解決する
SSIS ジョブ ステップがアクセス許可エラーまたはパッケージ アクセス エラーで失敗した場合は、SSIS ジョブ ステップを実行しているアカウントが次のリソースにアクセスできることを確認します。
- SSIS パッケージの場所。
- 構成ファイルとコマンド ファイル (使用する場合)。
- パッケージによって参照されるファイルとフォルダー。
- ネットワーク共有。
- データベースとその他のデータ ソース。
- パッケージに必要なその他の外部リソース。
パッケージで SSIS ProtectionLevel 設定によって保護された機密情報が使用されている場合は、実行アカウントが必要な情報を復号化できることを確認します。 SQL Server エージェント実行アカウントを変更すると、新しいアカウントでパッケージ シークレットの暗号化を解除できない場合や、外部リソースにアクセスするアクセス許可がない場合に、SSIS パッケージが失敗する可能性があります。 詳細については、「SQL Server エージェント ジョブ ステップから呼び出されたときに SSIS パッケージが実行されない」を参照してください。
確認済みの不足しているコンポーネントをインストールまたは修復する
確認済みの不足しているコンポーネントのみをインストールまたは修復し、アカウントの変更とは別に SSIS のデプロイまたはランタイムの互換性を修正します。 ジョブ履歴で不足しているコンポーネントが識別される場合は、アクセス許可を変更する前に、コンポーネントがインストールされ、実行 ID で使用できるかどうかを確認します。 その例は次のとおりです。
- SSIS コンポーネント。
- ジョブに必要な PowerShell モジュール。
- CmdExec ジョブ ステップによって参照されるカスタム実行可能ファイルまたはスクリプト。
- 必要なプロバイダーまたは他のランタイム コンポーネント。
コンポーネントまたはランタイムの不足エラーを、アクセス許可エラーとは別に解決します。 コンポーネントがインストールまたは修復されたら、ジョブを再実行します。 それでも失敗する場合は、ジョブ履歴の最初のアクション可能なエラーを確認します。
診断データの収集
これらの手順を完了してもジョブ ステップが失敗する場合は、失敗したジョブ履歴とその他の診断データを同じエラー間隔で収集します。 収集する gMSA 固有の証拠と標準的なSQL Server ログについては、gMSA トラブルシューティングの概要の診断データの収集に関するページを参照してください。 そのデータを使用して調査を続行するか、サポート ケースを開きます。