Дано. SQL SERVER 2016
Дефолтный инстанс, крутится под учёткой доменного пользователя. Эта учетка явно прописана в логины инстанса и является членом роли SysAdmin

По всем компам домена размотан алиас через TCP\IP на порт 1433 этого сервера.

Есть консольное приложение, собранное под .NET Framework 2 и под .NET Framework 4.0 (можно и 4.5 -- ничего не меняется).
В приложении ConnectionString написан через этот alias.
С одного и того же компа обе версии этого приложения под моей учеткой SQL-админа нормально работают,
а если запускать от учетки, с которой запускается инстанс SQL, то только версия для .NET 2
Для 4.0 версии -- не соединяется с сервером. Сообщение об ошибке буква в букву совпадает с сообщением, как при неправильно прописанном порту в Alias. Исправление Connection String на имя хоста вместо алиаса решает проблему.

Как такое вообще может быть? Почему конкретно одно сочетание Учётка/Фреймворк из 4 возможных может оказаться "проклятым"?
На одном и том же клиентском компьютере, обе учетки -- локальный админ.

Изначально проблема всплыла в зашедуленном в агенте джобе прямо на хосте с SQL. Одно приложение через алиас работает, второе -- нет. Разница по большому счету лишь в версиях фреймворка этих приложений.

Все, разобрался. Виноваты не алиасы как таковые, а то, что приложение "втихаря" запускалось с правами на код не FullTrust, хотя должно бы было.
В ограниченные полномочия оно сваливалось из-за того, что у учётки, которая его запускала, не было прав на доступ (хотя бы на чтение) в одну из вышележащих по сетевому пути папок. Такое поведение оказалось характерно для четвёртой версии фреймворка на Windows 10 и на Windows Server 2016. Ровно в таких же условиях, но на Windows Server 2012 этой проблемы не возникало.

Хотя, в целом всё равно странно. Пусть "в песочнице", но раз права на подключение к SQL у приложения сохранены, то почему через alias то его не пускают?