Listen portは動的に割り当てられる
また、固定することも可能
その場合、portはインスタンス毎に変える必要ある

「Force Encryption」オプションを「Yes」に設定すると、すべてのデータ通信が暗号化される
SQL Serverとクライアントアプリケーション間のすべての通信が自己署名証明書を使用して暗号化される¹⁾

設定が有効になっているかどうかを確認するには、以下のSQLコマンドでできるらしい

SELECT session_id, connect_time, net_transport, encrypt_option, auth_scheme, client_net_address FROM sys.dm_exec_connections

バックアップからリストアするときに表示される

webなどでは

• 「既存のデータベースを上書きする」チェックを入れる
• mdf,ldfファイルのパスが間違ってる

などがあるが、それでも解消できなかった場合、以下のSQLでリストアできた

RESTORE DATABASE kingdb -- 復元対象DB
FROM DISK = 'D:/DATA/kingdb.bak'
WITH REPLACE,
MOVE 'test1' TO 'D:/DATA/test1.mdf', -- 復元対象DB名を変更する可能性がある
MOVE 'test1_log' TO 'D:/DATA/test1_log.ldf' -- 復元対象DB名を変更する可能性がある

これは、いずれかのスキーマを所有しているため削除できませんという意味です。

• そのユーザでテーブルを作成した
• そのユーザでViewを作成した
• 権限スキーマの所有者になってる

等の原因が考えられます。解決法としては以下のようなものになります

-- いったん、ユーザーと、そのユーザー名と同名のスキーマを明示的に関連付け、
ALTER USER ユーザ名 WITH DEFAULT_SCHEMA = ユーザ名
-- そのスキーマを明示的に削除してから、
DROP SCHEMA ユーザ名
-- ユーザーを削除。
DROP USER ユーザ名
GO

1. データベース→スキーマ→db_owner²⁾の所有者を確認
2. 該当ユーザが所有者にになっていたら、ほかの所有者に変更
3. たぶんこれで削除できるはず

SQL Server 2012以前では、SQL Serverのデータベースエンジンのインスタンス間でデータベースを移行または復旧すると、データベースユーザーに関連付けられたサーバログインは、移行先／復旧先のインスタンスに自動でコピーされない。

そのため、孤立したユーザーが生まれ、移行直後のデータベースは機能しない。