SQLAgentReaderRole and SQL AD ID login case affecting ability to edit jobs I have AD ID users on a SQL 2008 server that can't edit their own jobs.  They can create them, but in order to edit them, they have to delete them and then re-add them.  The issue is explained here: http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/08/owner-of-the-job-will-not-be-able-to-modify-edit-the-job-in-sql-server.aspx

I did further research and figured out in my particular case it's because I added AD ID users using the CREATE LOGIN [domain\user] syntax.  Using that method, the case of the AD ID is what you specify in the brackets.

Is there anyway to create users with the correct Windows AD ID cases so that I'm not having to figure it out then modify the logins for each AD ID user?

Furthermore, I was using this script to get the correct casing for a particular user:

execute as login = 'usa\johndoe'
SELECT SUSER_SNAME()
revert;


But it was returning all lowercase for me, yet all uppercase when I asked the user to run SELECT SUSER_SNAME() and give me the result.  The correct is all uppercase (well, in order for that user to be able to edit jobs).

I'm at a loss and very frustrated.

-- 
I've found the best (only?) way to get the correct case is using the SQL interface to add a user, clicking search, typing the AD ID, then clicking check names.  For the example above, it returns all uppercase, despite that script example returning all lowercase.
Is there anyway to create users with the correct Windows AD ID cases
  so that I'm not having to figure it out then modify the logins for
  each AD ID user?


Built in, you already found it -- use the directory searching interface in the GUI. Alternatively, you could use SQL CLR (as mentioned), or write a PowerShell script. You could certainly write a routine to clean up an instance using either method.

Note that the GUI rewrites the domain name, even if it's incorrectly cased when entered, but not the login name itself. (You can see this by manually typing something in, then hitting the Script button.)


  But it was returning all lowercase for me, yet all uppercase when I
  asked the user to run SELECT SUSER_SNAME() and give me the result. The
  correct is all uppercase (...).


Under impersonation, SUSER_SNAME() returns the principal name as entered. If you try the test again with a different casing, it will return the exact name you typed in. The only reason the impersonation works using an incorrectly-cased name is because the Windows collation says the comparison of the two is a match.

Not under impersonation, there are two cases: (a) group login: the principal name is returned from what Windows supplies, which is always correctly-cased, and (b) individual login: the principal name is returned from what is entered for the name in SQL Server (it doesn't go out to Windows to double-check).



Now, having said all that, try as I might, I cannot replicate this problem using 2008 R2 management tools. If you're still running 2008 (non-R2) management tools, one option would be to try upgrading the tools, because this appears to be a bug in Management Studio itself.