Working with Aliases for Windows Azure SQL Databases in SQL Server Management Studio

re: Working with Aliases for Windows Azure SQL Databases in SQL Server Management Studio

Martyn Jones — Wed, 23 Jan 2013 11:40:57 GMT

This is a great post, it's going to save me a lot of time looking up each alias against which client is which.

Looking forward to how to push it out the rest of my domain too!

Thanks very much.

re: Working with Aliases for Windows Azure SQL Databases in SQL Server Management Studio

retracement — Sat, 26 Jan 2013 08:55:30 GMT

Hi Greg thanks for a useful post. I am presuming you are talking about using group policy to push out the client alias registry entries which is something I first mentioned on my blog in 2009 http://bit.ly/9BXhDm and demoed at SQLBits 7 -video can be found here http://bit.ly/XCpnTF

I most recently discussed it during my PASS summit presentation on upgrading to SQL 2012, and I always find it amusing since until now 4 years later I have never heared any one else mention it.

Looking forward to seeing whether there are any differences or considerations with respect to SQL Azure database instances.

re: Working with Aliases for Windows Azure SQL Databases in SQL Server Management Studio

Greg Low — Sat, 26 Jan 2013 09:27:10 GMT

Yes, indeed. I'm surprised you haven't heard it mentioned before. That's how I've always done it. I used to teach the folk in the SQL Masters program about it back when the course ran in Redmond. I think it's a very straightforward way to deal with the issues.

After all, an alias is just a registry entry and so it can be pushed out by group policy like any other registry entry.

re: Working with Aliases for Windows Azure SQL Databases in SQL Server Management Studio

Ken Abrams — Mon, 28 Jan 2013 02:32:38 GMT

Alternatively, you could just store the connection information as a registered server in SSMS. Personally, I do not store passwords in my connection information, but it enables you to have a user defined display name for the server.