SQL Server 2008R2エイリアスが機能しない
ここで私は興味深い状況にあります。基本的に、SQL Serverインフラストラクチャを新しいハードウェアに移行することを試みており、ボックス（シングルインスタンス、2ノードクラスタ）の1つが2008R2を実行しています。その他は2012と2014ですが、これらはこの問題を示していません。
たとえば「OLD-SQL」という名前のサーバーに接続するアプリがあります。 IPが11.22.33.44であるとします。これは、デフォルトのインスタンス、SQL 2008R2、およびWindows Server 2008R2を実行しているレガシーSQLボックスの名前です。現在、アプリの接続設定/構成/文字列/何も変更できません。
これを置き換えるように設定された新しいSQLボックスは、たとえば「NEW-SQL」という名前になります。 IPが11.22.33.55だとしましょう。 SQL 2008R2（同じSQLビルド）も実行しています。 OSはWindows Server 2012 R2（新しいOS）です。どちらのボックスも、実際にはそれぞれ2ノードのクラスター化されたインスタンスです（旧式のフェールオーバークラスタリング、豪華なものはありません）。
したがって、移行を支援するために、現時点ではテスト/ QAの目的で、次のことを行いました。1.クライアントのQAを実行するマシンでHostsファイルを設定して、「OLD-SQL」という名前を11.22.33.55にリダイレクトします（新規サーバ）。 2. NEW-SQLサーバーにSQLサーバーエイリアスを作成し（SQL構成マネージャーを使用）、「OLD-SQL」という名前でitselfをポイントします。ポート1433、プロトコルTCP/IP。
テストするには、SSMS経由で接続してみます。接続するサーバー名として「OLD-SQL」と入力します。悪名高い「SSPIコンテキスト」エラー（ https://support.Microsoft.com/en-us/kb/811889 ）で失敗します。テスト中のアプリケーションでも同じことが起こります。 cmd-lineからのpingは問題なく解決されます。Hostsファイルに基づいて、「OLD-SQL」が新しいIP 11.22.33.55に解決されることがわかります。
今、実際にレンチを投げます。サーバーNEW-SQLに戻り、anotherエイリアスを追加しますが、パラメータは同じですが、「OLD-SQL2」という名前です。この名前はドメインネットワーク内で一意です。私は自分のボックスに戻り、Hostsファイルをその名前からIP（11.22.33.55）を指すように変更し、SSMSに移動して再度接続を試みます。 これは機能します！
私はSELECT @@SERVERNAMEを実行して、「正しいサーバー」にいることを確認します。見れば、「NEW-SQL」と表示されます。しかし、もちろんこれは私が本当に望んでいるエイリアスではありません。 「OLD-SQL」というエイリアスを付けて、HostsエントリとSQLエイリアスを介して「NEW-SQL」にアプリをリダイレクトできるようにしたいと思います。
では、最初のエイリアスで何が問題になっていますか？ 2008R2では、ネットワーク上の既存のサーバーと同じ名前を使用できないだけですか？
SOの同様の投稿： https://stackoverflow.com/questions/6406811/alias-not-working-on-sql-server-2008-r2 （問題は解決しませんでした）
PS：「2008R2を使用して」と具体的に言います。2012-2014ボックスで同じ設定（ホスト、SQLエイリアス）を試すと、最初の方法で問題なく動作するためです。 （つまり、「NEW-SQL2012」ボックスのエイリアスは「OLD-SQL2012」にすることができます。これは既存のサーバーと同じで、接続やその他の問題はありません。）
PPS：私はこれらのエイリアスがクライアント側のものであることについて読んだことがありますが、それがHostsファイルトリックを使用している理由です。 「実際の」移行の準備ができたら、DNS（およびSysEngのドメイン）以外のトリックを使用して、クライアント（アプリ/コンピューター）を新しいサーバーにリダイレクトしますが、今のところテストには、Hostsファイルを使用するのが適切です。
更新：SQL Serverのバージョンに加えて、「機能する」セットアップと「機能しない」セットアップの主な違いは、古い2008R2インスタンス「SQL-OLD」は、「手付かずの」設定を使用して接続すると（エイリアスまたはhosts-file-redirなし）、Kerberos認証を使用します。 「OLD-SQL2」などの一意のエイリアスまたはリダイレクトを介して接続すると、NTLMとして登録されます。 ALL OTHER動作する接続方法では、これもNTLMです。ケルベロスは私に何をしているのですか？
チャットで発見したことを要約します。
WindowsサーバーがActive Directory（AD）にサービスプリンシパル名（SPN）で登録されている場合、ネットワーク経由で接続すると、統合認証で接続しようとするクライアントは、サーバー名と一致するADオブジェクトのKerberosトークンをADから取得します認証に添付します。接続されているサーバーにSPNがないか、SQL認証を使用して接続されている場合、Kerberosは使用されません。
この場合、「OLD-SQL」はまだADに登録されており、SPNに登録されたスプーフィングがあるため、返されるトークンを調整するものがないため、ローカルホストファイルのDNSは統合/ Windows認証を使用すると機能しません/ ADから使用されます。 ADから「OLD-SQL」SPNを削除する以外は、クライアントが「NEW-SQL」にKerberosトークンを使用して、元の「OLD-SQL」サーバーがまだ稼働していることを認識させる方法がないようです。認証を強制的にNTLMにフォールバックします。 DNSのスプーフィングは、ADに登録されている実際のコンピューター名ではない、またはSPNが登録されていないエイリアスに対して機能します。ADはそれらのトークンを返さないため、認証はNTLMの使用にフォールバックします。
参照