Cannot generate SSPI Context error

I have a recurring problem with the "Cannot generate SSPI context" error. It
works fine for some time, but then it stops working. Generally after half an
hour - two hours time. A logoff/logon always fixes the problem.
I have reviewed the 811889 article, but this doesn't help me. The connection
to the SQL server works fine, but at some time it is like the user looses hi
s
credentials and then can't connect and SSPI won't reconnect him.
Some basic info:
Server is Windows 2000 server SP1 with AD. (was SP4 earlier, with the same
problem, so upgrading to SP4 will not solve the problem by itself. The serve
r
has just been reinstalled from scratch, not finished SPs and updates yet)
SQL Server is MSDE, client logging on with NT security, SQL Server is
installed on the same physical server as the domain controller (only one
domain controller exists)
Client is XP PRO, same problem with SP2 or without SP2
User on client is logged on to domain with Admin+Domain admin privileges
Problem does not exist if client does not log on to domain
Anybody got any ideas on how to solve this problem?
PeterPeter
Where did it happen in an application or when you log in in EM/QA?
If it happend on ther client side , so perhaps some piece of code closes
connection. Can you run SQL Server Profiler to capture what is going on
during a half-two hours?
"Peter B.L. Rasmussen" <PeterBLRasmussen@.discussions.microsoft.com> wrote in
message news:8C22E3CE-23E5-48AB-A30B-22A0506829E2@.microsoft.com...
> I have a recurring problem with the "Cannot generate SSPI context" error.
It
> works fine for some time, but then it stops working. Generally after half
an
> hour - two hours time. A logoff/logon always fixes the problem.
> I have reviewed the 811889 article, but this doesn't help me. The
connection
> to the SQL server works fine, but at some time it is like the user looses
his
> credentials and then can't connect and SSPI won't reconnect him.
> Some basic info:
> Server is Windows 2000 server SP1 with AD. (was SP4 earlier, with the
same
> problem, so upgrading to SP4 will not solve the problem by itself. The
server
> has just been reinstalled from scratch, not finished SPs and updates yet)
> SQL Server is MSDE, client logging on with NT security, SQL Server is
> installed on the same physical server as the domain controller (only one
> domain controller exists)
> Client is XP PRO, same problem with SP2 or without SP2
> User on client is logged on to domain with Admin+Domain admin privileges
> Problem does not exist if client does not log on to domain
> Anybody got any ideas on how to solve this problem?
> Peter
>|||It happens Client-Side, in my application (VB.NET), when I am not working in
the application for some time. Then when the application (or the IDE) tries
to open a connection, it happens. If I keep the connection "alive" by workin
g
in the application (or in the development IDE), it does not happen.
Peter
"Uri Dimant" wrote:

> Peter
> Where did it happen in an application or when you log in in EM/QA?
> If it happend on ther client side , so perhaps some piece of code closes
> connection. Can you run SQL Server Profiler to capture what is going on
> during a half-two hours?
>
>
> "Peter B.L. Rasmussen" <PeterBLRasmussen@.discussions.microsoft.com> wrote
in
> message news:8C22E3CE-23E5-48AB-A30B-22A0506829E2@.microsoft.com...
> It
> an
> connection
> his
> same
> server
>
>|||Peter
Perhaps it is because ADO.NET keeps pool connection by default. Have you ran
SQL Server Profiler?
"Peter B.L. Rasmussen" <PeterBLRasmussen@.discussions.microsoft.com> wrote in
message news:422DFB2A-B95E-4309-B43A-5BD64EBDC093@.microsoft.com...
> It happens Client-Side, in my application (VB.NET), when I am not working
in
> the application for some time. Then when the application (or the IDE)
tries
> to open a connection, it happens. If I keep the connection "alive" by
working[vbcol=seagreen]
> in the application (or in the development IDE), it does not happen.
> Peter
> "Uri Dimant" wrote:
>
closes[vbcol=seagreen]
wrote in[vbcol=seagreen]
error.[vbcol=seagreen]
half[vbcol=seagreen]
looses[vbcol=seagreen]
yet)[vbcol=seagreen]
one[vbcol=seagreen]
privileges[vbcol=seagreen]|||No, I haven't run SQL Server Profiler. Do I have it on MDSE?
"Uri Dimant" wrote:

> Peter
> Perhaps it is because ADO.NET keeps pool connection by default. Have you r
an
> SQL Server Profiler?
> "Peter B.L. Rasmussen" <PeterBLRasmussen@.discussions.microsoft.com> wrote
in
> message news:422DFB2A-B95E-4309-B43A-5BD64EBDC093@.microsoft.com...
> in
> tries
> working
> closes
> wrote in
> error.
> half
> looses
> yet)
> one
> privileges
>
>|||No, I haven't run SQL Server Profiler. Do I have it on MSDE?
"Uri Dimant" wrote:

> Peter
> Perhaps it is because ADO.NET keeps pool connection by default. Have you r
an
> SQL Server Profiler?
> "Peter B.L. Rasmussen" <PeterBLRasmussen@.discussions.microsoft.com> wrote
in
> message news:422DFB2A-B95E-4309-B43A-5BD64EBDC093@.microsoft.com...
> in
> tries
> working
> closes
> wrote in
> error.
> half
> looses
> yet)
> one
> privileges
>
>|||Profiler won't help you tshoot the problem. You need to make network
traces to diagnose where it is failing. An alternative is to change the
client to use Named Pipes to connect. Named Pipes connections are able to
natively impersonate the client without calling the SSPI API.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Hi Kevin,
Yes, changing to Named Pipes will connect. But I would rather solve the
problem than work around it and learn something in the process. As this
problem only occurs on my development platform, and not at the production
site, I am hesitant on changing the program just to accomodate some troubles
on my site.
I don't know how to make a network trace.
Today I cannot connect at all - even after a windows logoff/logon. I have
found out that I have some old ADODB code in my program that actually
connects fine, and the connection problem only lies in .NET code connections
.
If I use ADODB.ConnectionClass
And this connection string:
Provider=SQLOLEDB;Data Source=W2KServer1\VSdotNET;
Initial Catalog=Sugro011104;Integrated Security=SSPI
I can connect without any problems.
If I use System.Data.SqlClient.SqlConnection
And this Connection String:
data source=W2KServer1\VSdotNET;
initial catalog=Sugro011104;
integrated security=SSPI;
persist security info=True;
workstation id=WORKSTATION2;
packet size=4096
I cannot connect.
So maybe the solution to the problem lies somewhere in the .Net framework?
Peter
"Kevin McDonnell [MSFT]" wrote:

> Profiler won't help you tshoot the problem. You need to make network
> traces to diagnose where it is failing. An alternative is to change the
> client to use Named Pipes to connect. Named Pipes connections are able to
> natively impersonate the client without calling the SSPI API.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Hi Peter,
Sorry, looking at your code won't solve the problem. The best tools to
troubleshoot this are:
1. Network traces.
2. Netdiag.exe
To impersonate the client over TCP, we have to establish an additional
session with the DC. This is where it is failing.
It has really nothing to do with SQL or your code per say. Netdiag can be
use to see if there are problems communicating with the DNS server
and/or the Domain Controller. This is where you need to focus.
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Solved.
There was apparently something wrong with my Windows Installation. Stepping
bact two steps with (System Restore? I don't know if that's what it is calle
d
in english-language Windows. The feature that lets you undo installations
etc.) solved the problem.
Peter
"Kevin McDonnell [MSFT]" wrote:

> Hi Peter,
> Sorry, looking at your code won't solve the problem. The best tools to
> troubleshoot this are:
> 1. Network traces.
> 2. Netdiag.exe
> To impersonate the client over TCP, we have to establish an additional
> session with the DC. This is where it is failing.
> It has really nothing to do with SQL or your code per say. Netdiag can be
> use to see if there are problems communicating with the DNS server
> and/or the Domain Controller. This is where you need to focus.
>
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>