Nice article.  We only use SA for database ownership and sometimes for SQL Job

ownership.  It is never used for connecting to the server because no one knows what

the password is.  We use a simpler routine to generate a random 72 character value

for it.

DECLARE @pwd char(72)

SELECT @pwd=convert(char(36),newid())+convert(char(36),newid())

EXECUTE master..sp_password null,@pwd,'sa'

Sample value:

0A8A24E8-A728-4DCF-B561-179511138895AAB9C183-BC26-49B3-BDC5-009AFFA5B83B

You are right about SQL ids not going away. Many developed and purchased applications

 use them for simplicity and to reuse execution plan

"Only query plans with the same user ID are candidates for reuse." 

See http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx

There are times when we DBA's need to use a SQL id. 

1. Domain is having issues.
2. IT is changing domains.
3. Remote access to an instance located at another company

To accomplish this we still don't use SA, instead we have a SQL Id with system

administration authority and assign it a complex password.

Thanks for giving me the opportunity to spout off about not using SA and having to

use mix mode