VIEW SERVER STATE Permission

This is high level server-level privilege which must not be granted to everybody. Only administrators must have privilege to use view server state permission but we can assign this permission to some users who want to see server level state of your SQL Server instance. Once you will grant this access to any login, he can see result of all DMVs.

Solution – ( Microsoft SQL Server, Error 300 )

We got SQL Server error 300 ( VIEW SERVER STATE permission was denied ) because the login you are using to execute the script doesn’t have this permission. To fix this issue we will grant view server state permission to the login name. This section will explain how to grant view server state permission to a login.

Grant VIEW SERVER STATE Permission

We can assign this permission either using GUI in SQL Server Management Studio or we can simply execute a T-SQL command to get this done. I will explain both ways to assign this permission.

Using GUI in SQL Server Management Studio

Follow below steps to do it using GUI.

1. Launch SQL Server Management Studio.
2. Connect to the SQL Server Instance.
3. Navigate to Security folder then expand Logins
4. Right Click at your login name and choose Properties
5. Click at Securables tab from left side pane.
6. In the bottom pane, scroll to the bottom and click at Grant option for View Server State value.
7. Now click on apply to close the window. You can now ask your user to test the script again. This time it will work.

Using T-SQL statement in SQL Server Management Studio

1. Launch SQL Server Management Studio. Connect to the SQL Server Instance.
2. Open New Query window
3. Run below T-SQL statement

USE master
GO
GRANT VIEW SERVER STATE TO "LoginName"

Once you execute above command, you will have view server state permission on your login name. You can resolve SQL Server error 300 VIEW SERVER STATE permission was denied on object ‘server’, database ‘master issue by following above steps given in this article.

Revoke VIEW SERVER STATE Permission

If you have identified anyone who must not have this permission then you can go ahead and revoke his access post getting proper approvals. Make sure that identified login does not have any business justification before revoking his access. Once you have decided to go ahead to remove view server state permission then you should run below T-SQL statement to get this done. Below steps will tell you how to revoke view server state permission of any login.

USE master

REVOKE VIEW SERVER STATE TO “LoginName”

GO

View SERVER STATE permission has been revoked for identified login post successful execution of above statement.

I hope you like this article. Please follow our facebook page and Twitter handle to get latest updates.

Read More:

• SQL Server AlwaysON Interview Questions & Answers
• SQL Server DBA Interview Questions & Answers
• Understanding Enhanced Database Failover in Always on Availability Group
• SQL Server Replication Interview Questions & Answers

The post Fix:VIEW SERVER STATE permission was denied on object ‘server’, database ‘master’ appeared first on Techyaz.com.

Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver
There are still remote logins for the server ‘DBSERVER’.

Error 15190 – Root Cause

As we know we need to first drop the existing details of SQL Server instance name from metadata system table sys.servers and then add new instance name in order to change the instance name. I was doing the same and running below command to drop the old instance name.

sp_dropserver <old_Name>; 
GO

I had received this error 15190 while executing above command and that is because of some remote logins present of the SQL Server instance.

If your database server has any remote login that you use for linked servers or some other purposes then you will get such issues. We need to drop all the remote logins to fix this issue and execute above command successfully.

Solution

To fix this issue we need to identify remote logins and drop them before changing the SQL Server instance name. We will be using a system stored procedure sp_dropremotelogin to drop all remote logins from our SQL Server instance. Run below command to drop all remote logins from a default instance of SQL Server.

sp_dropremotelogin old_name; 
GO

If you have named instance running on your database server then you can run below command. Make sure to change the name of server in place of Old_DBSERVER\Instancename.

sp_dropremotelogin Old_DBSERVER\Instancename; 
GO

Once all remote logins have been dropped you can go ahead and perform your SQL Server Instance name change operation. Make sure to create remote logins for your linked servers or alias post changing the instance name.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Change SQL Server Instance Name?
• How to Rename SQL Server Instance that is running with SQL Server Reporting Services?
• Fix Error 15434: Could not drop login “domain\loginname” as the user is currently logged in
• Fix Error 15174: Login owns one or more databases. Change the owner of database before dropping the login.
• How to Change Hostname of RHEL system?

The post Fix Error 15190: There are still remote logins for the server ‘DBSERVER’. appeared first on Techyaz.com.

There are many ways to check SQL Server installation date on your machine. Here i am going to discuss two popular methods that we can use easily to get install date of SQL Server. Let’s go one by one in step by step process.

Method 1

As we know whenever we install SQL Server, a SQL Server Agent job named “syspolicy_purge_history” got created. The install date of SQL Server instance will be same as the create date of this job because this job was created during SQL Server installation. So, if you need to find when SQL Server was installed on your database server then you can get it by create date info of above job. Follow below steps to get the details.

You can expand SQL Server Agent folder in SSMS and then Jobs folder. Here you can see this job. We can launch Properties window of job “syspolicy_purge_history” or you can query msdb database to get the details of this job. Here, I have launched Properties windows of this job and we can see the create date of this job is below screenshot. It means this SQL Server Instance was installed on 27^th July 2017 as showing as create date of below job.

Method 2

Another method to get SQL Server install date on your database server is by using SQL Server system logins. These system logins get created when we install SQL Server. Some of the system logins are NT SERVICE\SQLWriter, NT Service\MSSQLSERVER, NT AUTHORITY\SYSTEM and NT AUTHORITY\NETWORK SERVICE. You can also see some of the system logins that starts with hash # like ##MS_Policy***** etc. As I said these logins get created during SQL Server installation so to get SQL Server installation date we can check the create date of any such logins.

You can run below commands to check the create date of any of system logins. I have executed below commands to check create date of three system logins.

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT SERVICE\SQLWriter'
GO

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT Service\MSSQLSERVER'
GO

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT AUTHORITY\SYSTEM'
GO

We can see create date of all above SQL Server system logins are same as the create date of system job “syspolicy_purge_history” that is described in method 1. So, SQL Server install date on this database server was 27^th July 2017 as shown in below image.

You can also get SQL Server install date by getting update date of system account sa. As we have disabled sa account as part of SQL Server hardening so last update was captured when we disabled this account. But this does not show correct info always because if anybody has enabled this account and again disabled it then this will give you inaccurate information but you can use this information to compare the update date information with the create date of other logins and jobs. This will help you in identifying the install date of SQL Server in more accurate manner.

SELECT *
FROM syslogins
WHERE name='sa'
GO

SELECT *
FROM sys.server_principals
WHERE name='NT AUTHORITY\SYSTEM'
GO

You can see the update date of sa account and create date of the another system login shows same date that is also the SQL Server Installation date.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• SQL Server Evaluation Period has Expired and How to Upgrade it?
• Create a Logon Trigger to Restrict sysadmin logins to Connect to SQL Server during a given time Interval
• SQL Server Interview Questions & Answers

The post How to Find When SQL Server was Installed? appeared first on Techyaz.com.

Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

You can see the screenshot of the error 18452 in below image.

Error 18452 – Root Cause

Reason behind error 18452 is because of wrong security authentication mode configuration. SQL Server is set to accept only windows logins to connect to database instance.

As we know SQL Server uses two authentication modes to accept database connections. One is Windows Authentication mode and another one is SQL Server and Windows Authentication mode. We also call it Mixed Authentication mode.

Sometimes, SQL Server authentication mode is set to SQL Server and Windows Authentication mode to accept SQL as well as windows connections but still you will face this issue. That might be because you try to connect to a server that has Always on Availability Group configuration or database mirroring configuration.

Suppose you have AOAG configuration and you are connecting to database using primary replica name not listener name using a login for which default database is set as availability database. If failover got happen during your activity or you are connecting to secondary replica using a login for which default database is set as availability database then also you will get this error 18452 along with some SSPI context error that I have given below.

Error: 17806, Severity: 20, State: 14.
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed 

SSPI handshake errors comes because of Kerberos failure, which would most likely be related to non-existent SPN or bad SPN for SQL Server.

Solution

To fix this issue first we need to check the authentication mode set for your SQL Server Instance. If your SQL Server instance is running with windows authentication mode then you must change it to Mixed mode so that windows and SQL both type of logins can be authenticated.

To check the configured authentication mode for your SQL Server Instance, we need to launch SQL Server Instance property window. Right click at the instance node and click at the properties option as shown in below screenshot.

Once you will click at Properties option, you will be getting below SQL Server instance property window. Click at Security option from left side pane. You can see current Server Authentication configuration is set to Windows Authentication mode in below screenshot.

Now we will change it to SQL Server and Windows Authentication mode. Select the radio button for SQL Server and Windows Authentication mode option and click ok button to proceed. You can see that I have selected above mode to apply the changes.

Restart SQL Server services to apply the changes.

If your SQL Server Instance is already set with SQL Server and Windows Authentication mode then you should fix this issue in separate way. As I described above that one of the probable reason to get this error 18452 is because you might use AOAG replica server name to connect to the database with the login for which default database is set as the AOAG availability database.

If failover will happen then you would not be able to access the database because it will become secondary. Error 18452 will be generated along with SSPI handshake errors because same database is set as default database for your login that has become inaccessible now because of acting secondary database in AOAG. Failover will not happen for you because you are using replica server name to make database connection.

Possible solution to fix this issue is failback the AOAG to your earlier primary replica or you should use AOAG Listener name to make database connection. Also, to avoid this error during failover you should set default database for your login to master rather than availability database.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 18456: Login failed for user “User_Name”
• Fix Error 4064: Cannot open user default database. Login failed
• Error 53: Could not open a connection on SQL Server
• AOAG Listener Error 19471: The handle is Invalid

The post Fix Error 18452: Login failed. The login is from an untrusted domain appeared first on Techyaz.com.

Related Articles:

• Fix 15170: Logins owns one or more Agent Jobs
• How to fix error 15434: Could not drop login as the user is currently logged in
• Error Code 15174: Login ‘xxx\yyy’ Owns one or more databases(s). Change the owner of database(s) before dropping the login.

Microsoft SQL Server Error 4064

SQL Server Error 4064 generates because the default database set for your login has been dropped or becomes inaccessible by any reason. Whenever we create any SQL Server or windows login, we mention a default database. If you don’t mention any database during login creation then SQL Server set default database as master database.

You might also get this error on secondary replica of AlwaysON Availability Group because that database on secondary replica remains into inaccessible mode. So, don’t do any changes if you are getting this error in AOAG environment. You just need to connect to the primary replica because it is designed to keep secondary replica database into inaccessible mode.

Here, we had a database named “TechyazDB” that was set as default database for my login techyaz. This database was dropped by someone and when I tried to connect to SQL Server, it gave me below Microsoft SQL Server error 4064 because database was not there on SQL Server instance. Below is the screenshot of Microsoft SQL Server error 4064 that is clearly saying “Cannot open user default database. Login failed.”

Solution

There are two solutions to fix this issue. Either make your database online by restoring it or by anyway or change the default database of this login to master or any other database that is online on the instance. As you cannot bring your database online because you can’t connect to the instance so your first option is to connect to the instance.

If you have other DBAs or sysadmin accounts, you can connect using those accounts to SQL Server and change the default database for your login to master and then you can make database connection.

Let’s consider only you are the admin on this instance so how will you fix it. Follow below steps:

Launch SSMS and click on connect to database engine. Enter server name and login details for which you are facing issue.

Now click on Options tab of above image. You will get below screenshot.

You can see Connect to Database option is set to default database that was TechyazDB for this login. Now we need to change this default to any accessible database. It will not allow you to select from drop down. If you will browse the database it will give you same error. You need to enter or type the database name. I typed as master database as shown in below image.

Now click on connect button to establish the database connection. This time you can connect to your SQL Server instance.

Now, it’s your wish whether you want to bring your database online first or you want to change the default database of your login. Generally, if database has been dropped as a planned activity then you need to change the default database of your login. Read below section to know how to change default database of your login.

Change default database of Login Name

There are two options to change the default database set to any login. One is by using T-SQL code and another is by using GUI. Let’s start with GUI method.

As you have connected to your SQL Server Instance. Expand Security Folder followed by Logins folder. Now double click on your login name or right click on login and choose properties tab. You will get below property window.

You can see default database is showing as blank. This was the main issue because your database has dropped from the instance. Now change it to master database and click on OK button to proceed.

Second method is T-SQL method. Run below ALTER command to set the default database of your login.

--Change techyaz with your login name.
ALTER LOGIN [techyaz] WITH DEFAULT_DATABASE = master

Below is the screenshot of this command.

Related Articles:

• Fix Error 15173: Revoke the permission(s) before dropping the login
• How to fix error 15141: The Server Principal owns one or more endpoints.
• How to fix error 15138 and Error 3729

Here, I have explained step by step solution to fix SQL Server error 4064: Cannot open user default database. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Fix SQL Server Error 4064: Cannot open user default database. Login failed. appeared first on Techyaz.com.

Microsoft SQL Server Error 35250

We generally get this error whenever there is a communication issue between endpoints of both replicas or any replica unable to connect to the endpoints cause this error to generate. You will see below error texts if you are getting this issue.

Alwayson Error 35250
Failed to Join the database ‘DBName’ to the availability group ‘AOAG-Name’ on the availability replica ‘Availability Replica Name’

There are many reasons behind this error that we will discuss in next section. You might also get below text if you are using T-SQL.

Below is the screenshot of this error.

Solution

You should check below points based on attached article MSDN link whenever you get this error.

• Inbound Port 5022 Traffic is Blocked
• Endpoint is not created or started
• Endpoint permissions
• SQL Server is not listening on port 5022

But if everything is ok and you are still not able to diagnose this issue, then you should keep reading this article.

I checked everything and all was well on both replicas.  As we know that there should be Grant CONNECT permission on Always On endpoint. I was reassigning GRANT CONNECT on the endpoint and came to know that the SQL Server service account was not added to the SQL Server instance of secondary replica. That is why we faced this error. Let’s first get the endpoint and then we will run Grant connect on endpoint to see the issue. Run below command to get the name of endpoint that is using in this alwayson configuration.

We can see endpoint name is hadr_endpoint. Now run below command to grant connect permission on endpoint hadr_endpoint. The login name is the service account that is used to run SQL Server services.

You can see, error is saying that the account doesn’t exist on SQL Server.

Although you can directly check this step in SSMS as a prerequisite once error is reported. The SQL Server service accounts should be added to SQL Server Instances. I checked this account on both replica and found that it was very much there on primary replica but it was not created on secondary replica. That was the missing point which caused this issue.

Now create this service account on secondary replica as well or where it was missing on any of the replica then you can try to re-add the database to the AOAG configuration. This time your database will be added to the AOAG configuration. If you are facing issue during joining database to the AOAG configuration then you can remove the existing AOAG and reconfigure it.

Your issue will be fixed if you check and follow all above suggested points including the one mentioned in MSDN link. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Fix AOAG Error 976:Cannot Connect to Secondary Replica
• How to fix AOAG Listener Issue 19471: The handle is Invalid
• Fix Listener Issue that came during AOAG Configuration
• How to fix Error 15141: The Server Principal owns one or more endpoints
• Fixing Application connectivity Issue after AOAG automatic failover

The post SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error appeared first on Techyaz.com.

Cannot connect to ‘Secondary Replica Server’.
ADDITIONAL INFORMATION:
The target database, ‘SDGC’, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.  For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online. (Microsoft SQL Server, Error: 976)

The screenshot of this error is given below.

Solution

Before going ahead let me give you a background about SQL Server configurations.

• We have two SQL Servers Server A & Server B and there is an user database SDGC is hosted on both SQL Server Instances.
• AOAG is configured between both servers in Automatic failover mode for database SDGC.
• Availability database SDGC hosted on instance B is inaccessible because it was restored in no recovery mode and not set in read only mode for AOAG configuration.
• User’s login was created on both SQL Server instances with having default database as SDGC that are participating in AOAG.

Now, the problem is whenever user tries to connect to the secondary replica whether AOAG is active from instance A or instance B, he is not able to connect to the SQL Server Instance and getting given SQL Server error 976. I analyzed this issue and found two solutions to fix this issue:

• Change Connect to database value in SSMS while establishing the connection.
• Change default database value of your Login in Login Property window.

Change Connect to database value in SSMS

Launch SQL Server Management Studio. Click on Options tab of connection details window in SSMS as shown in below image.

You can see, Connect to database value showing as default that means it is connecting to the database that is set as default database for user’s login. Remember, default database for user’s login is set as SDGC that is running in norecovery mode.

Now, we just need to change the connect to database value from default to master or some other database. As default database for user’s login was set to SDGC, so change it master to make database engine to read an accessible database.

Once you make changes, hit the connect button and establish a database connection. This time you will be able to establish database connection to secondary replica.

Change default database value of your Login

If default database of your login is not mandatory to set to availability database then you can change it to master and remove this issue permanently. Otherwise, you need to change default database every time you make a connection to secondary replica as discussed in above section.
You can connect to your secondary replica or to the server where you are facing this issue using different admin or security admin account. If you have such account and password, you don’t need to logoff and relogin. You can just right click on SSMS icon while pressing SHIFT button to logged in using different user to the SQL Server instance. You can see that option in below image.

Click on “Run as different user” option. It will display below login screen to enter your new login and password. Enter the credentials.

Once your new account will be authenticated, SSMS will be launched and show you the details as shown in below image. Click on Connect button to establish the connection.

Expand Security folder. Identify your login for which you have to change the default database setting. Right click and choose properties on this login to launch properties window. You can double click on this login as well to launch this properties window. Below window will come to your screen where you can see the default database set for this login.

You can see default database is set as SDGC in above screenshot. Now we need to change it to master or any accessible database. Do the changes, you can see i have changed it to master in our screenshot. Once you make changes, click on Ok button to proceed.

NOTE: If you need to change default database back to availability database due to some application dependencies then you need to first make your availability database accessible. You can perform failover to make secondary replica as primary then you can make changes and then you can failback. If you don’t want to perform failover/failback, then you can do this by changing the availability database from norecovery to read only mode.

Now your issue is fixed. You would be able to connect to the SQL Server Instance that are running as secondary replica in AOAG configuration.  You can see, i have connected to secondary replica using same account with whom i was facing issue.

Related Articles:

• • Fix Error 19471: Listener Issue during Configuring AOAG
  • How to Fix SAP connectivity issue after AOAG failover
  • Fix: Secondary Replica is showing in Resolving state
  • Fix SQL Server Error 15141: Server Principal owns one or more endpoints

Please comment us to give your feedback. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group appeared first on Techyaz.com.

Linux Error: User is not in the sudoers file. This incident will be reported.

Sudoers file determines which users can run administrative tasks, those requiring superuser privileges. I was failed to perform certain tasks because my username was not part of this file and returned with below error.

Linux Error: User is not in the sudoers file. This incident will be reported.

Someone who has super user (su) access can fix this issue by adding the impacted user to the Wheel group. The wheel group is a special user group used on Linux systems to control access to the sudo command, which allows a user to behave as super user. Once we will add our user into this group, we will be able to use sudo command.

Adding a Linux User to Sudoers File

Connect to your Linux server using superuser account.

#Connect using su
su

We have now connected to Linux server using superuser account. Now we can add our username to the Wheel group.

#Add your user to the Wheel group. 
#Change techyaz to your user name.
usermod -G wheel techyaz

Now we see that command executed successfully. If you attempt to execute the sudo command now, you might get the same error message unless you completely logout your user and re-login again. Next you can exit from superuser account by typing exit on the prompt.

#Exit su account
exit

Your account or user added to sudoers file now by adding it to wheel group. You can now connect to Linux server from your PuTTY terminal or on the local server and try to run sudo command post completely logout your user and re-login on the server.

#Connect to Linux server using your user name that was added to wheel group.
#Run sudo su
sudo su

You can see we have access to run anything using sudo command in above screenshot. Now your username is part of sudoers file so you can perform your activities using sudo command now.

Read more:

• How to Install Red Hat Linux 7.3 on Virtual Machine
• Fixing PuTTY connection issue while connecting to Red Hat Linux Server
• Installing SQL Server 2017 on Red Hat Linux Server

Here, we have fixed Linux error “User is not in the sudoers file. This incident will be reported.” I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fixing Error “User is not in the sudoers file. This incident will be reported.” appeared first on Techyaz.com.

Microsoft SQL Server Error 15433, Level 16, State 1: Supplied parameter sid is in use

I have an AOAG configuration having two replicas in my environment which is set for Automatic failover. Last week, we had High Availability testing for all applications. Issue occurred when application team tried to connect to database server after failover. They were failed to connect to the secondary replica using Listener after failover whereas applications were working fine from primary replica. Issue came because SQL login which was used by application has different sid on secondary replica than the primary replica.

During fixing above issue, we came across an error about which we will be discussing in this post. One of the engineer has accidently created a wrong login with the same SID that we were about to use to create the application login to fix above issue. When we have tried to create application login we get below error.

Here i will explain step by step method to fix this SQL Server Error 15433.

Solution

Here i will reproduce this issue and then fix it in a step by step manner. So, final objective is to create a login with same name, password & sid on secondary replica to sync the login details of associated application. Let us first check the login sid of identified login on primary replica. Run below code to get it.

SELECT name, SID, createdate from syslogins
WHERE name='xyz'

Copy the SID of this login from above screen for further uses. Now connect to secondary replica and run below command to create same login with same password & sid. You can remove Check_Policy option if your login has password policy applied.

CREATE Login xyz WITH password = 'techy@z@123', Check_Policy=off, SID = 0x03981anjkhdvehh73964jbdbj783

Here we got the issue because someone has already created another login with same SID. Now our next step is to check that login which was created with this SID. Run below command on secondary replica to get this done.

SELECT name, SID, createdate from sysloginswhere SID = 0x0398manjkhdvehh73964jbdbj783

We can see the login name which was created under given SID. We have to created application login with same SID to establish application connectivity to database after failover so we will drop this Login and recreate application login with this SID. Later we can create deleted login which will have different SID. If not needed you should not create unwanted logins on SQL Server. Run below command to drop this login.

--Change login name with login.
DROP Login login

SSMS way to drop a login is given in below steps:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

You might get multiple dependency errors during dropping this login because there is possibility this login might own few objects, agent jobs or databases on this instance if it was created long before. You can read below articles to fix such kind of issues if you will face any.

• How to fix Error 15174: Login owns one or more databases.
• How to fix  Error 15173: Revoke the permissions before dropping the login.
• Fixing error 15138 & Error 3729: DROP login failed
• Error 15141: The server principal owns one or more endpoint(s) and cannot be dropped
• How to fix error 15170: Login owns one or more SQL Agent Jobs.

Now once this login will be dropped, you will be able to create your application login with required SID. You can see that in below screen.

CREATE Login xyz WITH password = 'techy@z@123', Check_Policy=off, SID = 0x03981anjkhdvehh73964jbdbj783

We can see command executed successfully. Now issue is fixed here.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 15433, Level 16, State 1: Supplied parameter sid is in use appeared first on Techyaz.com.

Logon trigger Overview

Logon Triggers fire in response to a LOGON event. It fires after the authentication phase of logging in finishes, but before the user session is actually established. Logon Triggers are very useful in tracking and restricting login events.

Sometimes few applications require sysadmin privilege to run and if you downgrade this access, application stops working. So, we cannot restrict sysadmin logins of such applications. There is always a scope of security breach if another login has sysadmin access except DBAs on SQL Server Instance.

To fix this issue, I have created a logon trigger that will restrict access of such application logins who are sysadmin on your SQL Server Instance.  We can restrict them to access SQL Server directly through SSMS or any other medium. You need to pass that medium into code just like I have passed Management studio.

Logon Trigger T-SQL Code

Below is the Logon Trigger T-SQL code which will be used to restrict any login for given time frame.

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE trigger [logon_rest]
on all server for logon
as begin
declare @Program varchar(128)
declare @systemname varchar(128)
select @Program =PROGRAM_NAME,@systemname=HOST_NAME from sys.dm_exec_sessions as A
where a.session_id=@@SPID
if ORIGINAL_LOGIN() in('sa') /**Login For Which Access Need to restricted **/
and @Program like'%Management%studio' /** Program via access restricted **/
and
(GETDATE()>(dateadd(day, datediff(day, 0, getdate()), 0) + '18:00') /**Last time till access allowed **/
or
GETDATE()<(dateadd(day, datediff(day, 0, getdate()), 0) + '09:00')) /**Start time from access allowed **/
begin
Raiserror ('This is out of office hour',1,1)
rollback;
end
end;
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
ENABLE TRIGGER [logon_rest] ON ALL SERVER
GO

Testing

For the testing purpose, I have taken sa account as a potential application login. You can use your identified login which are running with sysadmin rights. Even we can restrict such logins to connect to SQL Server during given time frame.

Here we have disabled sa server level login to connect through SSMS Before 9:00 AM and Post 6:00 PM. That means server login sa cannot connect to SQL Server Instance between given time slot. You can alter the time slot as per your convenience.

Just for example we have tried to login on SQL server through SSMS between given time frame and here you can see the output. I am not able to connect to SQL Server anymore. You can see this in below screenshot. But at the same time you can login to the same SQL Server Instance using other sysadmin or normal login accounts which is available in sys.syslogins.

Even we can track the failed login attempt made on this SQL Server Instance once you can make a database connection using another login. You can check the SQL Server error logs or you can just run sp_readerrorlog stored procedure to display errors. You can see our test login attempt is showing in below screenshot on the server.

Read more about SQL Server Login Issue related Articles:

• How to fix Error 15173: Revoke the permissions before dropping the login.
• Fix error 15138 & Error 3729: DROP login failed
• How to fix error 15434: Could not drop login as the user is currently logged in
• Fixing error 15170: Login owns one or more SQL Agent Jobs

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Create a Logon Trigger to Restrict sysadmin logins to connect to SQL Server for given Time Interval appeared first on Techyaz.com.

Automatic Failover Worked Well but Application failed to connect

I have an AOAG configuration with Automatic failover between two replicas in my environment.  Last week, we had High Availability testing for all applications. Everything was working fine if we were doing failover from Management Studio. Databases were failing over and failing back successfully.

Issue occurred when application team tried to connect to database server after failover. They were failed to connect to the secondary replica after every failover but applications were working fine from primary replica. Below are the error details that are coming to application team during establishing database connection post failover to current primary replica (earlier secondary replica).

When we saw at the database level, everything was working fine. Secondary replica was successfully transitioning as primary replica after failover and databases were accessible from failover node but application was not able to connect to this replica. We checked all respective logins associated with the application and everything was there on secondary replica.

One thing we have noticed during troubleshooting that SQL login was became orphaned after each failover and we did resolved orphaned user issue manually post each failover. But there is no benefit of automatic failover if you need to establish database connection manually after each failover.

After spending some time, we fixed this issue. Application was not able to connect to database post failover because one of the SQL login which was used by application has different SID on secondary replica than its primary replica. I recreated this login on secondary replica with same SID which was in primary replica and this has fixed the issue. Here, I will explain step by step method to make you understand the issue and its solution.

Resync the SID from Primary Replica

First check the current configuration of this AOAG. Run below command to get the AOAG details. We can see the configuration is running into automatic failover mode along with replica names.

SELECT replica_server_name, availability_mode_desc, failover_mode_desc
FROM sys.availability_replicas

If you do failover between replicas then it will not throw any error in SSMS or database level. But if you will ask application team to connect to database server using Listener post failover, you will get error.

You will face error because SID of the login used by application is different on both replica servers. You can also get the error when the login used by application to establish database connection is not present on secondary replica. You need to sync the login, password and SID of this login to the secondary replica. Follow this tip to fix the issue that are coming due to any of the given reason.

The SID identifies the security context of the login and is unique within the server instance. If the login is created from a Windows user or group, it is given the Windows SID of the source principle; the Windows SID is unique within the domain. If the login is created as a legacy-style SQL Server login that requires a password, the server will generate a SID. Now check the SID of the login which is used to connect to database on primary replica.

--Replace your identified login with xyz.
select name,sid from syslogins
where name='xyz'

Now run same command on secondary replica. You can see SID is different on both replicas for same login. Ideally everything should be same and in sync with primary replica that are associated with AOAG.

Now we need to delete this login from secondary replica and recreate it using same SID which is present on primary replica. Next, drop the login either using SSMS or T-SQL. SSMS way is given below:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

If you want to drop this login using T-SQL command then open a query window and execute below command.

--change the name of xyz with your login name which you want to delete.
DROP Login 'xyz'

You might get multiple dependency errors during dropping this login because there is possibility, this login might own few objects, agent jobs or databases on this instance. I got Error 15170 during dropping this login which i fixed in attached tip to remove this login. You can also read below articles if you are getting different kind of DROP Login failed issues:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped
• How to fix error 15434: Could not drop login as the user is currently logged in

Once login will be dropped, go ahead and create same login with same password and SID which are used on primary replica. Copy the SID from image 2 when you check the SID for this login on primary replica and use that during CREATE Login statement. If you don’t have this login on secondary replica yet then also you can follow same process to create the login.

--copy the SID from primary replica.
CREATE Login xyz WITH password = 'password@123', CHECK_Policy=Off, SID = 0xC2Cabcdefghijk123hghj6C3

We can see command executed successfully. Now issue will be fixed if you don’t had this login on secondary replica and you just created it for very first time. But you might get orphaned user issue if you had this login earlier with different SID on this instance. Now we need to fix the orphaned users on the secondary replica.

Fix Orphaned Users

Now you need to run below command to check the orphaned users on your database. Make sure that your database is working as primary otherwise you would not be able to run this command. You can failover and then run this command if database will become primary.

--change the dbname
USE DBNAME
Go
sp_change_users_login 'report'

If you will get your user name which was mapped to the identified login then we need to fix this orphaned user. Run below command to fix this issue.

--change the dbname
--Map database user xyz to login xyz.  
USE DBName;  
GO  
EXEC sp_change_users_login 'Update_One', 'xyz', 'xyz';  
GO  

Now orphaned user issue is also resolved and we have fixed the application connectivity issue that was reported after automatic failover of AOAG. You can do failover testing again to make sure application connectivity is working fine after AOAG failover.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fixing SAP Connectivity issue after AOAG Automatic failover appeared first on Techyaz.com.

If you are facing different kind of DROP login failed errors, you can read below articles where i have demonstrated step by step method to fix the various kind of DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped
• How to fix error 15434: Could not drop login as the user is currently logged in

Microsoft SQL Server Error 15170

I had to remove a SQL login on one of SQL Server instance where AlwaysOn Availability Group is configured and running. We need to remove this login and recreate it with the same SID which are present on primary replica to fix an AOAG Automatic failover issue. Login was failed to drop because of SQL Server error 15170 which suggests that this login owns one or more SQL Server Agent jobs. Error details are given below.

As error clearly says, that one or more Agent jobs are owned by this login so let us check the details about it. Expand SQL Server Agent followed by Jobs folder of your SQL Server Instance connected in SSMS. You can see below jobs were there on SQL Server Instance.

Solution

Now check the properties of these agent jobs to check the job owner. Double click on identified agent job. You will get below image. Here you can see job owner is showing as same account which we are trying to drop. Change it to sa and click on ok button to apply the change. Repeat the same to the all three agent jobs.

Now owner of agent jobs is changed to sa. Next step is to go ahead and drop the login again. you can do it by either SSMS or T-SQL. SSMS way is given below:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

If you want to drop this login using T-SQL command then open a query window and execute below command.

--change the name of Login_name with your login name which you want to delete.
DROP Login 'LOGIN_NAME'

This time your login will be dropped successfully. If you are still facing some another issue during dropping this login, you can read below articles where i have demonstrated step by step method to fix the DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped

Here, we have fixed Microsoft SQL Server error 15170. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 15170: Login owns one or more Agent Jobs appeared first on Techyaz.com.

If you are facing different kind of DROP login failed errors, you can read below articles where i have demonstrated step by step method to fix the various kind of DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix Error 15141: Server principal owns one or more endpoints.

Microsoft SQL Server Error 15434

This error generates when a login has made a connection to the SQL Server Instance and you are trying to drop the same login. Solution to fix this issue is to close all sessions which are opened by this login and then drop it. You can get the details about the sessions which are open using this login id either by sp_who2 or by DMV sys.dm_exec_sessions.

I had to remove a domain login on one of SQL Server instance but login was failed to drop because of SQL Server error 15434 which suggests that the login is currently logged in. Error details are given below.

Drop failed for Login “domain\abc”
Could not drop login ‘domain\abc’ as the user is currently logged in. (Microsoft SQL Server, Error: 15434)

As error clearly says that above login is currently logged in. Run below T-SQL code to get the details about the sessions or connections this login has made to the SQL Server Instance.

SELECT login_name, * FROM sys.dm_exec_sessions
WHERE login_name = 'xyz\abc'
Go

You will see the details for this login along with the session id in below screenshot.

Solution

Now we have identified the session id which are running using this login id which we want to drop. Now next step is to kill this session. Make sure to check the SQL code running behind this session id. If it is not critical go ahead and drop the login or if any DML or other operations are running about which you are not aware of, please contact application owners to get the details about this session id. Don’t kill any session id that you are not aware of. Now go ahead and kill above session which is running using our login id. I am going ahead to kill this session because i know what is running under this session which is not critical.

--Replace the session id 53 with your session id.
Kill 53
GO

We can see command executed successfully. You can recheck whether this session is still open or not by executing same command which we have executed in first section.

We can see, session id 53 is no more active and disappeared from the SQL Server transactions. Next step is go ahead and drop the login again. This time your login will be dropped successfully.

If you are still facing same issue during dropping the login and get this error again then you can check SQL Server services log on accounts. Sometimes if you run SQL Server services using the account which you want to drop throws same error. If this is the case then your next step is to change the logon account to some other domain account to release this login. You can see this in below image. Change the log on account of all SQL Server services if they are running using this account. Once you made the changes to the services, restart SQL Server service to bring new account in use by SQL Server.

Now go ahead and drop the account again. This time it will work and your login will be removed. You will not face Microsoft SQL Server Error 15434 anymore. You can do it by either SSMS or T-SQL. SSMS way is given below:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

If you want to drop this login using T-SQL command then open a query window and execute below command.

--change the name of Login_name with your login name which you want to delete.
DROP Login 'LOGIN_NAME'

If you are getting some another issue during dropping this login, you can read below articles where i have demonstrated step by step method to fix the DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix Error 15141: Server principal owns one or more endpoints.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 15434: Could not drop login ‘Domain\abc’ as the user is currently logged in appeared first on Techyaz.com.

If you are facing different kind of DROP login failed errors, you can read below articles where i have demonstrated step by step method to fix the various kind of DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed

Microsoft SQL Server Error 15141

I had to remove a domain login on one of SQL Server instance where AlwaysOn is configured and running. Login was failed to drop because of Microsoft SQL Server error 15141 which suggests that this login owns one or more endpoints. Error details are given below:

Drop failed for Login “Login Name”
The server principal owns one or more endpoint(s) and cannot be dropped. (Microsoft SQL Server, Error:15141)

As error clearly says that one or more endpoints are owned by this login so let us check the details about endpoints. Run below T-SQL code to get the details of endpoint.

SELECT n.name, a.*  FROM sys.endpoints a
inner join sys.server_principals n on a.principal_id=n.principal_id
Go

You will see the endpoint details in below screenshot along with the login id who owns the endpoint. I have blured it because of privacy.

Solution

As we can see that endpoint is owned by this login so now we will change the owner of this endpoint to break the dependency which are the main reason behind this SQl Server error 15141. Now next step is to change the owner to some another login. You can also transfer the ownership to system account sa.

We will use ALTER Authorization statement to transfer ownership of this endpoint from existing server level login to some another server level login. We can not set the ownership to database level users. ALTER AUTHORIZATION can be used to change the ownership of any entity that has an owner. Run below command to change the owner of above endpoint to a login Domain\abc5.

--Replace the login id [Domain\abc5] with your login.
ALTER Authorization on endpoint::Hadr_endpoint to [Domain\abc5]
GO

We can see command executed successfully. You can recheck the ownership by executing same command which we have executed in first section. Once change is done. next step is to drop the login.

We can see, now ownership of this endpoint is set to another login. Next step is go ahead and drop the login again. you can do it by either SSMS or T-SQL. SSMS way is given below:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

If you want to drop this login using T-SQL command then open a query window and execute below command.

--change the name of Login_name with your login name which you want to delete.
DROP Login 'LOGIN_NAME'

This time your login will be dropped successfully. If you are still facing some another issue during dropping this login, you can read below articles where i have demonstrated step by step method to fix the DROP login failed errors:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 15141: The server principal owns one or more endpoint(s) and cannot be dropped appeared first on Techyaz.com.

Microsoft SQL Server Error 15173

Login was failed to drop because of SQL Server error 15173. This error comes when a login having server level rights has granted permission to any server principal. The details of Microsoft SQL Server error 15173 is given below.

You can check the details about the grantee by running below command. You will see the grantee_principal_id and grantor_principal_id column along with other details. Grantor_principal_id will be the id of that login which you want to delete. You can see class_desc and permission_name column to see the permission type and permission category.

SELECT * FROM sys.server_permissions
Where grantor_principal_id= (Select principal_id from sys.server_principals where name = 'xyz')

You might get such issues if you have configured AlwaysOn availability group or database mirroring because there might be possibility that your login has granted some permission to endpoint so you need to revoke that permission to fix this issue.

Solution

The solution to fix this issue is to revoke the access which you have granted. Run below command to revoke the access for endpoints. This solution is valid only in case if you have granted access on endpoint. If you have granted access on login then you should keep reading this article.

--Here xyz was grantor.
--Make sure to revoke the access level which you get in the output of above script. 
--You can get this by focusing on permission_name and state_desc column. In my case, it was view definition and state_desc was GRANT.
USE Master
Go
REVOKE CONNECT ON ENDPOINT:: [hadr_endpoint] TO [xyz]

Once command will be executed successfully, you are able to drop that login. Do let me know in comment section if you are still facing the issue. You can try below T-SQL to revoke the access from login if you get an output for logins not endpoint.

If this access is assigned to login and not endpoint then you should run below command to revoke the access. Here we are trying to drop login xyz but it was failed because xyz login has granted access to login abc. So, we will revoke the access to drop the user.

USE master
REVOKE VIEW DEFINITION ON LOGIN:: xyz FROM [abc]

Go ahead and drop the login which you wanted to drop.

--change the name of Login_name with your login name.
DROP Login 'LOGIN_NAME'

You can also revoke this access level using SSMS/GUI as well. Connect to SQL Server Instance in SSMS, Expand security folder followed by logins folder. Double click on the login and go to securables from left side pane. You can uncheck the permissions allocated to this login and click on ok to apply the changes.

You can click on attached link if you want to learn about another Error 15174 which comes during drop Login statement.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 15173: Revoke the permission(s) before dropping the login. appeared first on Techyaz.com.