Check if a windows/nt user account exists

I have some script which creates/grant priveleges to windows/nt users to DB but i frequently get the message below:

Windows NT user or group '<user or group>' not found. Check the name again.

I understand that this is because the said user/group is indeed not present in the environment I'm running the script (ie. testing and production environment).

But is it possible to have some sort of checking whether the user/group exists in the environment so that I could determine whether or not to call some lines of code?

Not sure if this is possible so i had to ask. c",)

SELECT *

FROM sysusers

will show the users from the current database. There are columns like isntname and isntgroup that will tell you if it is an NT user name or group. There are more than just the normal users, so take a look at what is in that table.

|||

If i'm not mistaken that will only show users already registered for the current database.

I needed to check if a NT user name/group is valid/exists in the environment rather than if it is registered for the current database.

Appreciate your help but i think i need something else or could you expound how would that apply for my objective?

Thanks in advance

|||

What version of SQL Server are you using? You could use SUSER_SID('<your_windows_login_name>' and check for non-null value. But this method depends on your configuration - the SQL Server service account, member server or standalone server etc. So there is no easy way to do this from the database engine.

You could use the ADSI OLEDB provider and perform distributed queries but this depends on your network configuration & whether LDAP is allowed and so on. In SQL Server 2005, you can write SQLCLR function to perform the check but this requires enabling CLR on the server, creating assembly with possibly UNSAFE or minimum of EXTERNAL_ACCESS permissions.

Best is to perform the check outside of the database, filter the list of users and create the logins. Or you can simply perform the error check in TSQL. This is also easier with TRY..CATCH in SQL Server 2005.

|||Thanks, will definitely try to look into these.|||I think i'll just go for the try-catch. Thanks|||Try catch should be fine, but be careful that you don't need speed. Performance will be a bigger concern just catching the error instead of checking for it first.