Connection Timeout

I’ve 2 database servers. These servers communicate with the other’s data
bases
via TCP/IP with SQL authentication using VB, COM+ & ASP applications. Both
servers are running W2k & SQL2k, each with the latest SPs & hot fixes.
Neither server is a domain server. Server A also supports a VB application
the users access through Terminal Services sessions.
Recently we began experiencing a problem on server A. When logged on to the
server with an administrator account the user can connect to the other
server’s database through the VB applications & through SQL Query Analyzer
.
However, when logged on as a user that isn’t an administrator, they cannot
connect to the other server; they get a Timeout Expired error message. This
occurs every time.
From server A when logged on as a standard user we can telnet to server B on
port 1433. We cannot odbcping nor use SQL Query Analyzer to connect to serve
r
B. The IP address & the SQL user /password is included in all connections.
I ran Netmon on server B to see what was coming from server A. I only saw
ack messages. I’m not a Netmon expert, so interpreting these messages is a
little beyond me.
I also suspect the problem is on server A. Why else would one user be able
to connect & another not. Beyond that I’m lost.
The only error I see in any of the Event logs from server A is an error
described by KB 326912.
Thanks in advance for any ideas.You need to make the connections from the client side and review them. See
if the tcp 3 way handshake is completing.
Q169292 The Basics of Reading TCP/IP Traces
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I'm able to see a 3 Way Hand Shake & Graceful Close. There is also some Push
activity in the trace.
Examining this activity is iffy at best, because these are production
servers. My problem only occurs when the user on Server A is not an
administrator. Some of the activity in the capture could be the result of
other user activity. I think the trace I captured was during an isolated
period, but I cannot be assured of this. The Hand Shake & Grageful Close wer
e
the 1st & last events in the capture.
"Kevin McDonnell [MSFT]" wrote:

> You need to make the connections from the client side and review them. Se
e
> if the tcp 3 way handshake is completing.
> Q169292 The Basics of Reading TCP/IP Traces
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Is there a policy defined on the system that might explain why there is a
permission problem?
gpresult.exe will show you if any policies are in place.
Are there any security templates in use?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I'm not aware of a policy that is set to do that.
I ran gpresult without learning much, which didn't surprise me since this is
a stand-alone server.
There are Local Policies, most are default values. I did read through all of
these & nothing stuck out as a possible culprit. Do you have any policies in
mind that may need further scrutiny?
Sam
"Kevin McDonnell [MSFT]" wrote:

> Is there a policy defined on the system that might explain why there is a
> permission problem?
> gpresult.exe will show you if any policies are in place.
> Are there any security templates in use?
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Clients need "access this computer from the network" permission in order to
establish a connection.
Can the same client map a drive to the server?
Does the problem happen with Named Pipes as well as TCP/IP?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I checked the 'Access this computer from the Network' local policy. It
includes Users.
The user connects to Server A through a Terminal Services Connection.
Mapping a drive isn't an option I've pursued.
Since these are standalone servers I don't know how to connect from one to
the other using named pipes. (One is in Atlanta & the other in Washington DC
.
They communicate via Internet. Force Encryption is on.) If I enter the
www.servername.com of Server B, I think that uses TCP/IP. I tried it in Quer
y
Analyzer & got the Timeout message.
I installed FileMon from www.SysInternal.com on Server A. I saw some files
that were not found, but the system reverted to Winnt\system32 for the same
files & was succesful. I didn't see any unsuccessful attempts logged for the
User. This leads me to suppose it isn't a file permission problem.
I restarted Server A last night, but this didn't accompolish anything either
.
Sam
"Kevin McDonnell [MSFT]" wrote:

> Clients need "access this computer from the network" permission in order t
o
> establish a connection.
> Can the same client map a drive to the server?
> Does the problem happen with Named Pipes as well as TCP/IP?
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||I would run Microsoft Network Monitor from the Terminal Server machine to
trace the traffic to SQL.
Compare the admin trace to the user trace.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I have the traces. I was able to run them when there wasn't any other
activity between the systems.
Both traces are escentially the the same except in the admin trace I see
more TDS protocol packets. Both start with the 3 Way Hand Shake & end with
the Graceful Close. The 1st 12 packets of each trace are the same. Then the
admin trace has 12 TDS protocol packets with a description beginning with
'UNKNOWN EPM ACK Len ='. The trace that fails does not have any of these
packets.
The user trace does have some TDS protocol packets, but for some reason that
the trace doesn't show, it doesn't continue with the TDS packets the admin
trace has.
Sam
"Kevin McDonnell [MSFT]" wrote:

> I would run Microsoft Network Monitor from the Terminal Server machine to
> trace the traffic to SQL.
> Compare the admin trace to the user trace.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Hi Sam,
Sounds like you made a good capture. Unfortunately, the best way to
resolve this would be to open a case and have a SQL Engineer review the
traces. It would be too difficult to diagnose the traces in this forum.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.