SQL Server Image http://www.Oostdam.Info General pictureMicrosoft SQL Server is a great product to work with. Especially from the release of version 2005 and now 2008. For me, it is the standard for all kinds of databases. The Object explorer, Tuning Advisor, the Query Analyser and T-SQL statements work great, and are a joy to work with. When it goes wrong somewhere, it is mostly a syntax error, program(bug) error or a user error that causes the problem. Stable as it is, I can recomment the use of it to anyone. In this articles I like to share with you, some errors and "best practices" that came up during my work several times. So, initially set up was for my own references, now I share it with you. Enjoy these articles!! Due to the fact that a big percentage of visitors of this page are international based, this article is in the english language.


Error message 8198:
This is a common error, mostly occurs on older systems, ( SQL 2000) or systems that are still having connections with older clients. The error can occur when you are trying to resolve the credentials of a Microsoft Windows NT domain user account, into a SQL Server instance. You can get the following error messages in this case:

  • 1   Server: Msg 8198, Level 16, State XX, Procedure <Stored Procedure Name>, Line <line Number>
           Could not obtain information about Windows NT group/user '<Domain\Account Name>'.
  • 2   ODBC error 8198 (42000) Could not obtain information about Windows NT group/user '<Domain\Account Name>'.
  • 3  The job failed. Unable to determine if the owner (<Domain\Account Name>) of job <job name> has server access 
           (reason: Could not obtain information about Windows NT group/user '<Domain\Account Name>'. [SQLSTATE 42000] (Error 8198)).

To resolve the (users) credentials of a Windows NT domain user account, SQL Server uses the xp_logininfo system stored procedure. Mostly it is caused  by 3 common scenarios where you may notice that the xp_logininfo system stored procedure fails and causes the 8198 error.

  • When you use an xp_sendmail extended stored procedure.
  • When you set up replication.
  • When you run a SQL Server Agent job.

Now this is something to explain again. Xp_logininfo is a system stored procedure. The xp_logininfo system stored procedure is not a SQL Server extended stored procedure, contrary to its name. The xp_logininfo system stored procedure invokes multiple and several Microsoft Windows API calls procedures to retrieve information about the Windows domains and the Windows user accounts, based on the Active Directory account information. Now, based on the Windows API call that caused the failure, the xp_logininfo system stored procedure may return the 8198 error with a relevant SQL Server state value. The SQL Server state value indicates the nature of the failure. That where we can find the correct information for the solution. SQL Server may run the xp_logininfo system stored procedure to retrieve information about the Windows domains and the user accounts, even if the user does not do so explicitly. Therefore, if you receive an 8198 error message and the error message mentions the xp_logininfo system stored procedure as the procedure, you can and will be able to use the SQL Profiler to trace and to troubleshoot the exact point of failure. Why? Every time that the xp_logininfo system stored procedure fails, the 8198 error is logged with the relevant SQL Server state. Even if the user does not run the xp_logininfo system stored procedure explicitly,...  ( they run a NT client perhaps )  SQL Server may use the xp_logininfo system stored procedure to retrieve information about the Windows domains and the user accounts when it is required. In the following error message, the XX value indicates the SQL Server state at the time when the failure occurred. This is simular to one of my other article about login failures. The "State" value says it all. In this case let say you have a logging which says:


Server: Msg 8198, Level 16, State XX, Procedure <Stored Procedure Name>, Line <line Number>
Could not obtain information about Windows NT group/user '<Domain\Account Name>'.


In the following table you can see some state values that can occur in the (logging)error message when you are having an 8198 error.

SQL Server statePossible cause
21The xp_logininfo extended stored procedure was not run on a computer that is running a Microsoft Windows NT operating system.
The backslash ("\") character that separates the Windows domain name and the account name in the Windows account name is missing.
22An error occurred when SQL Server queried the Windows operating system to retrieve information about a Windows account name.
24When the SQL Server engine queried the Windows operating system to retrieve information about a Windows account name, access was denied.
25An error occurred when the SQL Server engine queried the Windows operating system to retrieve information about a Windows account name.
26An error occurred when the SQL Server engine queried the Windows operating system to retrieve information about a local Windows group where the Windows user is a member. (Windows user refers to the security context account).
27An error occurred when the SQL Server engine queried the Windows operating system to retrieve information about a local Windows group where the Windows user is a member. (Windows user refers to the security context account).


Now, the xp_logininfo system stored procedure does nothing else than resolving the credentials of a Windows NT domain user account. Microsoft itself does recomment that you use SQL Profiler to trace the actual cause of the error message. Some possible causes of the 8198 error are:
  1. Network issues.
  2. An issue with the name of a Windows Local Group or a Windows Global Group.
  3. A conflict with the EVERYONE group.
  4. An xp_sendmail extended stored procedure failure.
  5. A SQL Server Agent Job failure.
  6. A replication configuration failure.

Now, lets discuss a possible solution for every point above mentioned:

  1. Network issues: You can receive the 8198 error if the SQL Server logon account is in an other(different) Windows domain than the Windows account that is used to run the stored procedure. To resolve the problem, make sure that there is a trust relationship between the two Windows domains; and that the TCP/IP ports that are required to establish the trust are enabled on the two Windows domains. ( and are not blocked by any firewall or what so ever).
  2. An issue with the name of a Windows Local Group or a Windows Global Group: You can get error 8198 when you run the stored procedure by using a Windows user of the Windows Local Group or the Windows Global Group if the Windows Local Group or a Windows Global Group has the same name as anyone of the following cases: The Windows domain name is the same, the computer name is the same or another Windows domain that has a trusted relationship with the domain is connected.  Now to resolve this, do and try one of the folowing. First, change the Windows Local Group name or the Windows Global Group name and try login again. Second, remove the user that gets the error from the Windows Local Group or the Windows Global Group that has the same name as the Windows domain. Add the user again, you can test it first with a simular account and it will be solved.
  3. A conflict with the EVERYONE group:  EVERYONE does not appear in the list of groups that is in the User Manager for Domains or in the Computer Management Windows administration tools. However, if you manually create a Local group or a Global Domain group and you name it EVERYONE, the EVERYONE group will be in the list of groups in User Manager for Domains. So they see alike, but they are different!! To resolve this kind of problem, delete the EVERYONE group that you earlier created manually.
  4. An xp_sendmail extended stored procedure failure. This is a simple one. The xp_sendmail extended stored procedure may fail and return the 8198 error if the client computer that is running the xp_sendmail extended stored procedure is not in the same domain as the SQL Server computer, and the two domains do not have a trust relationship. Just create the same user in the other domain, ( with the same credentials ) and add the SQL Server startup account to the Pre-Windows 2000 compatible access groupin t he SQL Server clients Windows domain. This solves it all.
  5. SQL Server Agent Job failure: You can receive the 8198 error if a SQL Server Agent job that is owned by a Microsoft Windows NT authenticated user fails. This problem may occur when SQL Server is running on a Microsoft Windows 2000 operating system computer, and the computer's domain does not have a Pre-Windows 2000 Compatible Access Group.  Now will be strange, but it can happen, as this group is populated by default in Windows Server 2000. Re-adding this group or following MS KB article: 241643  can be a solution for this.
  6. A replication configuration failure: When you have configured a replication on an instance of SQL Server, the replication agent may not start. You may receive the 8198 error here as well. The replication agent does not start etc. etc. etc.. What do you do? First, examine the history of the SQL Server Agent job that was created for the replication agent job that fails. You may be able to find the 8198 error logged in the job history. The error 8198 will be part of the SQl statement. There are 2 possible causes for this problem:
    (A) The SQL Server service uses an account that does not have enough administrative credential rights on the Windows domain. In this case, the xp_logininfo system stored procedure has been is run by using the security context of the SQL Server service. As the account does not have sufficient administrative credentials to enumerate the properties of the user in the domain, obviously, the xp_logininfo system stored procedure fails, and you receive the 8198 error. To resolve this problem, change the startup account of the SQL Server service to a (higher) Windows domain account or another (new) SQL service account, which I personally prefer anyway.
    (B) The SQL Server services and the SQL Server Agent services on the Publisher and on the Subscriber site, use security contexts of different Windows domains. It is obvious that this can cause errors, but,... it can happen,... Now to resolve this kind of problem, use the same Windows domain user account to run the SQL Server services and the SQL Server Agent services; or create a new Windows domain user account on the Publisher as well as on the Subscriber side that both have identical user names and passwords.


Printscreen: Not available.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Ben OostdamBen Oostdam has been working with Windows systems since 1993. Worked for several companies as a system administrator, and is currently a Senior Support Engineer for Qurius Managed Services in the Netherlands specialized in System Center Solutions.

Disclaimer: The information contained in this website/article is for general information purposes only. The information is provided as is, by Ben Oostdam and while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk. In no event will we be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this website. Through this website you are sometimes able to link to other websites which are not under my control. I have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them. Every effort is made to keep the website up and running smoothly. However, I take no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control. All entries in these articles, are my individual opinion, or from co-writers and they don't necessary reflect the opinion of my employer.




 

Wednesday the 17th, July 2019. All rights reserved.. // Oostdam WebDesign