SQL2005: Cannot connect error 11001

Hello,

within my network, one laptop get installed MSSQL2005, all services are
activated, network configuration as follows:

shared memory -- enabled
named pipes -- disabled
TCP/IP -- enabled
VIA -- disabled


For TCP/IP:
Protocol: yes

IP Adresses:
========
IP1 :

enabled = yes
IP address: the one of the laptop
TCP dynamic ports: (blank)
TCP port: I have given a port number

IP2:
besides IP address -- same settings like IP1.
IP address: 127.0.0.1 (local loop)

IP all:
dynamic ports -- (blank)
TCP port: I have given a port number (differnt to the others above)

All services restarted in order to activate the settings.

If I use know a second laptop where SQL Server Management Studio is installed,
I try to connect as follows:

Login -> Database Engine (server type),
Servername: <IP address of MSSQL laptop above)>,<Portnumber of
IP ALL>

Connection properties: connect to database (default), network protocol
(TCP/IP)

If I press now the button Connect, the error message appears:
Cannot connect to tcp:<Ip address of MSSQL laptop>,<Portnumber of IP ALL>

An error has occured while establishing a connection to the server. When
connecting to SQL server,2005, the failure may be caused by the fact that
under the default settings SQL Server does not allow remote connection.
(provider: tcp provider, error: 0 - not such host is known). (MS SQL error:
11001)

I have sent a ping to the MSSQL laptop -- ping is responding.
Trying to check with TELNET <IP address of MSSQL laptop>:<Portnumber of IP
ALL>, the telnet will fail.

I don't know why the host is unknown.
On the MSSQL laptop, SQLexpress and MSSQLSERVER are running as instances.
Is there a special settings necessary because of having a named instance
"MSSQLSERVER" ?

What can be the reason for this?

Firewall is deactivated (windows firewall as well as F-Secure firewall).
nethertheless, in Windows firewall an exception rule already exists for
MSSQLSERVER and the port I'm using in IP ALL. The port number is not the
standard number 1433.

Thanks for any help.
Stephan Hofmann.

.