エラー：SSPIコンテキストを生成できません
誰かがSQL Serverインスタンスに接続しようとすると、エラーが表示されます。
SSPIコンテキストを生成することはできません。
昨日、停電があり（この表現を英語でどう言うかわからない）、サーバーをシャットダウンする必要がありました。
答えを探して、私はこれを見つけました：
SQL Server 2008の接続の問題：SSPIコンテキストを生成できません
しかし、彼らは昨日まで問題なく働いているので、私には役に立ちません。何も変えたくない。しかし、もし必要なら、私はそれを変えます。
Obs：サーバーを再起動できません。
編集：私の回答以来、エラーは発生していません。
SQL SERVICE userは "Domain Admin "。
これがなぜ起こるのかを知るためにいくつかの調査を行いました。それはあなたがサービスをシャットダウンするとき、あなたは特権を持つアカウントが必要です（それが再びオンになるとき）新しいSPNを作成することを言います。それなしでサービスを開始すると、CANNOT GENERATE SSPI CONTEXTに表示されます。
システムアカウントの権限を変更しています。
それが誰かを助けることを願っています。
「SSPIコンテキストを生成できません」は一般的なエラーです。これは、古いパスワード、時計のずれ、Active Directoryアクセス許可、SPNの登録の失敗など、多くの問題が原因で発生する可能性があります。
この問題に対する解決策はありません。唯一の「解決策」は、 KB811889 および/または トラブルシューティングKerberosに従って、原因をinvestigateにすることです。エラー 。原因を理解せずに、ランダムなインターネットリソースから1つのソリューションまたは別のソリューションを適用すると、問題が解決する場合としない場合があり、不満を引き起こす場合とそうでない場合があり、取り返しのつかない損傷を引き起こす場合とそうでない場合があります。
PRODからデータベースを取得してQAで復元したところ、この問題が発生しました。私たちのアプリケーションは3つのサーバー上の3つのデータベースを呼び出しましたが、それ以外は複雑ではありませんでした。
偽のSPN（サービスプリンシパル名）が、接続が実行されているはずのサービスアカウントを妨害していることがわかりました。これは、Program Files> Microsoft Kerberos Config Managerを使用して発見しました。
短期的な修正は、SQL Server構成マネージャーを使用し、SQL ServerとSQL Serverエージェントの接続をサービスアカウントから[Use BuiltIn Account]の[LocalSystem]に変更することでした。
SSPIコンテキストを生成できないことは、まさにそれを意味する可能性があります。クライアントがSQLサーバーに接続するとき、クライアントはサービスタイプ（MsSQLsvr）サーバーのFQDNとポートを含む生成方法を使用します。 DNSを使用してサーバー名を生成するため、CNAMEやホストファイルなどが原因で名前が正しく解決されない場合、生成は失敗します。目的のサーバーに対してpingを実行し、返される応答を確認します。 SQLサーバーのFQDNでない場合、SPNが正しく生成されず、このエラーが発生します。
状況によっては、SPN設定が原因でこのエラーが発生します。たとえば、新しいサーバーに対して災害復旧テストを行っている場合、SQL Serverへの接続中にSSPIエラーが発生する可能性があります。さらに奇妙なのは、SQL Server Management Studioを使用して接続できる可能性があるが、ODBCまたはOLEDBを介して接続できないことです。一時的な回避策がおそらくデータベースにアクセスできます。
回避策：SQL Serverに接続しようとしている各クライアントコンピューターで、各ワークステーションのHostファイルにエントリを作成します。これが問題の修正に使用する正確なメカニズムは確認されていませんが、それを使用するとSPNの必要性が無効になる可能性があります。
これがすべてのケースで修正されることは保証されていませんが、ほとんどの場合、復旧して実行されます。これは永続的な修正とは見なされません。理想的な状況では、SPNまたはその他の問題を解決する必要があります。ただし、サポートされていないオペレーティングシステムを実行している古いWindowsマシンで問題が発生している場合、または概念実証の災害復旧テストを実行している場合は、ライトをオンにしておくか、運用環境を継続して稼働させる必要があります。
この問題が発生し、サーバーのADのコンピューターアカウントの属性にあるSPNエントリを削除することで解決しました
ADユーザーとコンピューターでコンピューターアカウントを検索する（詳細ビュー）
次に、MSSQLSvcのservicePrincipalNameの2つのエントリを削除します。
最近この問題を経験しました。 NTサービスアカウントとして実行していて、サービスアカウントを使用するように切り替えたときに、SSMSを使用してマシン名またはFQDNで接続できなくなりました。 IPアドレスで接続できました。掘り下げてみると、SQLインスタンスのActive DirectoryのSPNがマシンに登録されていることがわかりました。これを削除してサービスアカウントに追加し、SQLマシンを再起動すると、すべてが正常に機能しました。必要に応じて詳細をお知らせいたします。
私にとっての解決策は、次のコマンドを使用してSQL Studioをドメインユーザーとして実行することでした。
runas/user：OtherDomain\User SSMS.exe
同様の問題がありました。 ADSIEditでコンピューターアカウントのSPN情報からエントリを削除する必要がありました。
エントリを削除した後、SQLサービスを再起動し、作成したドメインリソースアカウントでSPNを登録しました。その後、SQL Serverにリモートでアクセスできました。