We run our SQL Server services using a low privileged domain account. That account is NOT a local admin on the OS. Only access I give the user account is assigned during install of SQL: full control over its mount points and then everything else is granted by the SQL Server 2005/2008 installer.
I need to create a linked server in SQL Server 2008 to an ODBC data source. So I remoted into the computer using my domain account, which is part of a group that DOES have local admin privs to the OS. I created a system DSN and configured it to connect to another SQL Server. The DSN works perfectly when I test it. However, when I try to create the linked server, I get an error.
It appears to me that the DSN is invisible to the domain account that SQL Server is running as. It seems that this problem is only happening to me on Windows 2008 servers. Does anybody know whether there's anything that you need to do after creating a DSN to make it visible for other users to access?
You have to explicitly add the user's Windows login (or just DOMAIN\Domain Users if using AD) to SQL as a DBO of each relevant DB. Through Win2K3 server, a DSN-only SQL login was all that was needed, but as of Win2K8, the DSN-only SQL login alone is not enough. Once I added the Windows login for a given (restricted) user (actually DOMAIN\Domain Users in my case - they are all restricted users) to my SQL server, each user could then use the DSN (setup with its own, separate login) as had always been the case before... What a major PITA this was - thanks for the lack of any note, Microshaft!!!!
From what I am reading on google it appears that this behavior is a result of the UAC. You could choose to disable the UAC on that particular server.
I am not sure if there is a way to allow this without disabling the UAC.
Ensure that you're creating 32-bit DSNs when you need to create 32-bit DSNs, and not 64-bit ones. There are two versions of the ODBC tool on a 64-bit system. The 64-bit one opens up by default. Try manually navigating to the C:\Windows\SysWOW64\odbc32ad.exe tool and creating the DSNs there.
The confusion is an unfortunate side-effect of trying to maintain backwards compatibility.