Tuesday, June 4, 2013
How to Change SQL Server Authentication Mode
I was asked to fix a connectivity problem for SQL Server 2008 deployed to test virtual machine. I was told that nobody was able to connect neither using sql server login nor windows login (neither SA account with generic password nor the local administrator of the windows server)
Since I have seen this in the past and heard about it, I knew what caused this problem. Basically it was the result of not granting access to any log in with right credentials. First thing I tried is to make sure that I am using a log in that has sys admin rights. For this I followed the steps in my earlier blog post (click this link to read that blog). Make sure to use strong password for the sql log in you just created.
Upon restarting SQL Server I attempted to use the new account I just created with no success. I kept getting login failed message. Then I wanted to check the SQL Server error log to see if any error message logged. In my situation I was able to locate the error logs stored at "C:\Program Files\Microsoft SQL Server\MSSQL10.Test01\MSSQL\Log" however in your case it might be different based on installation path and version of the SQL Server. Just by looking at the path you can tell that I am dealing with named instance installation of SQL Server and the name of the instance is 'Test01' and MSSQL10 means it's SQL Server 2008. If you're dealing with another version like SQL 2008 R2 you would see 'MSSQL10_50' and if you're dealing with SQL Server 2012 it would be 'MSSQL11'. And if you're dealing with default instance then instead of 'Test01' you would see 'MSSQLSERVER' in the path.
Anyway, I opened the file named 'errorlog' using notepad and started to scanning the entries. Within seconds I found an error message stating that 'login failed because of server is configured with Windows Authentication mode but the login is sql login'. At this moment I knew that I had to change the authentication mode to 'SQL Server and Windows Authentication mode' to gain access using the sql login I just created.
If you search the Internet you will find how to change the authentication mode during installation or changing the authentication mode using SSMS. However I had no way of connecting to SQL server via SSMS to change the authentication mode. But there is another way that it can be done. Of course this is not documented anywhere in MS knowledge base since it involves registry hacking!!!.
In my case this was a test server and I was OK if I ended up messing up the server and need to rebuilt it. If you're in the same situation and willing to do the same then keep on reading.
Open the command prompt and type "regedit" (without quotation marks) and hit enter. Make sure to backup the registry before making any changes. Then browse to the location for your SQL Server installation on the left pane. In my case it was the named instance of SQL Server which was named 'Test01'.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.Test01\MSSQLServer
And here is the path to default instance:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLServer\MSSQLServer
Then on the right pane find "LoginMode" make a right click and click on 'Modify' then finally change the 'Value data' to 2, click ok and exit the registry editor.
Stop the SQL Server service and then restart it. Now your instance authentication mode has been changed to 'SQL Server and Windows Authentication mode' and you can use the sql login that you created to access and configure the server.
HTH,
Bulent
Friday, February 3, 2012
Dropping Multiple SQL Server Objects in Single Line
As humans we try to find a way to work faster and efficient. As data professionals, typing less probably is another thing we want. My SQL Server tip today is about dropping multiple objects (tables, views, stored procedures, and even databases) in single drop statement. This is powerful but can be dangerous in production so please use caution. Here is a script that creates couple of tables and then drops both tables in single drop statement.
Sincerely,
Bulent
-- CREATE TABLES
USE tempdb
GO
CREATE TABLE dbo.TableT1 (t1c1 TINYINT)
CREATE TABLE dbo.TableT2 (t2c1 TINYINT)
GO
INSERT INTO dbo.TableT1 VALUES(1)
INSERT INTO dbo.TableT2 VALUES(2)
GO
-- CHECK THE TABLES CREATED
SELECT *
FROM sys.tables
WHERE name LIKE 'TableT_'
GO
-- DROP BOTH TABLES IN SINGLE DROP STATEMENT
DROP TABLE dbo.TableT1, dbo.TableT2
GO
-- CHECK THE TABLES DROPPED
SELECT *
FROM sys.tables
WHERE name LIKE 'TableT_'
GO
Friday, January 27, 2012
Cycling SQL Server Error Log
In the environments that I support I change the configuration so that I keep more than 6 files. I set up to store 99 files (which is the max allowed files for the SQL Server error log). Then I create a job that runs every night right after midnight. This way when I come in every morning there is a brand new log file and since the daily log files are much smaller it makes the file easy to open and check. I use the script below to change the number of log files (note you can do this using SSMS GUI and just make a right click on SQL Server Logs under Management folder than click on Configure and change the value to what you need). After the change using second script I create SQL Server Agent Job that is scheduled to run right after midnight to cycle the error log. This make the daily task of checking the error logs easier (at least for me). Use the scripts below in a test environment and once you find out it could add some value to your daily tasks you could use it in your production environment.
HTH,
Bulent
Script 1:
This changes the number of log files stored to a value you set at the end and uses extended stored procedure to update the registry. Remember this can be done through GUI but it does executed the same in the background.
Script 2:
This script creates a job (make sure you sql server agent is running) and schedules it to run at 12:00:01 am everyday.