Event ID: 1006 and multiple login screens

[tomisf...@gmail.com]

Hi all

Does anyone have any insight into what triggers Event ID 1006 and if
there is a way to turn this feature off?

I've set up a couple of Windows Terminal Services 2003 environments
using Sun Ray thin clients and rdesktop. The nature of the Sun Ray
architecture is that the thin clients are just dumb graphics and I/O
devices for the central Sun Ray server. This means that from the
Windows point of view, the Sun Ray server is making multiple RDP
connections from the same IP address.

It all works fine except for the "Event ID: 1006" problem. This occurs
when I attempt to have multiple thin clients showing the
username/password login screen at the same time. On the attempt to show
the 46th simultaneous username/password screen, Windows kills that RDP
connection and records Event ID 1006 in the system log. Further
attempts to connect using RDP fail for the next 60 seconds or so. The
rdesktop error is "Connection reset by peer".

"The terminal server received large number of incomplete connections.
The system may be under attack."

Interestingly, the number of successfully logged-in connections is
irrelevant. The only thing that seems to be counted is the number of
simultaneous username/password login screens. That is, I can have e.g.
5 users logged in, and 45 thin clients showing the login screen, and
then the attempt to bring up a 46th login screen fails.

This is not an rdesktop problem - I have reproduced this problem using
the Windows Remote Desktop client as well. The error is "The client
could not establish a connection to the remote computer. Attempting to
connect to 46 username/password login screens from the same Windows
machine - 45 are successful, the 46th attempt fails. Once again,
successfully logged-in sessions don't seem to count towards this
figure.

This is not a licensing problem - one environment I've set up is using
per-device licenses, the other is using per-user licenses. The licenses
are valid and there are enough of them.There are no licensing errors in
the Windows event log.

It is unlikely that I will have 45 users simultaneously trying to type
in their username and password, but it's a potential issue and I'd like
to know if my analysis of what triggers it is correct or not. Anyone
know some details on this?

Regards
Tom Shaw

[Vera Noest [MVP]]

I think that your analysis of the situation is correct. It is more
or less identical with the description on EventID.net:

http://www.eventid.net/display.asp?eventid=1006&eventno=1361
&source=TermService&phase=1

I don't know if there's anything you can do to get rid of the
warning.

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
*----------- Please reply in newsgroup -------------*

[Tom Shaw]

Hi Vera

Thanks for your reply. I had read that entry on EventID.net before, but
I was a bit confused about what the phrase "connected with a session"
meant in the Terminal Services world.

My understanding now is that a session is established only once the
user logs in correctly.
TCP/IP Connect -> Login screen -> Success -> Session Established.

The problem is that Event ID 1006 is more than just a warning - it
signifies a hard limit on the number of connections wanting to login
simultaneously. I haven't been able to find a way to alter the limit or
turn it off, and your reply confirms this.

Thanks
Tom

[matty...@gmail.com]

Vera,

The Event 1006 seems to be more than just a warning: it locks out any
further connection attempts for 60 seconds or so (as if a DoS attack
was taking place). Is there a way of disabling this behaviour (with or
without suppressing the warning)?

Regards,
Matt

[Vera Noest [MVP]]

I'm sorry, not that I know off.

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net

___ please respond in newsgroup, NOT by private email ___

matty...@gmail.com wrote on 02 dec 2005 in
microsoft.public.windows.terminal_services: