Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA Dev
Hi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/default...b;en-us;287932
http://support.microsoft.com/kb/269882/EN-US/
http://msdn.microsoft.com/library/de...setup_77g3.asp
Regards
Mike
"SA Development" wrote:

> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>
|||Hi Mike,

> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Dev

Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA DevHi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/default.aspx?scid=kb;en-us;287932
http://support.microsoft.com/kb/269882/EN-US
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_runsetup_77g3.asp
Regards
Mike
"SA Development" wrote:
> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>|||Hi Mike,
> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Dev

Do Named Pipes work across a WAN?

Hi,
Do Named Pipes work across a WAN?
Are they carried on TCP/IP? What ports?
Thanks,
SA DevHi
Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
packets. Named pipes is not efficient on slow connections.
Your best option is to use TCP/IP sockets.
Once you have firewalls in place, TCP/IP sockets is your only option.
http://support.microsoft.com/defaul...kb;en-us;287932
http://support.microsoft.com/kb/269882/EN-US/
http://msdn.microsoft.com/library/d.../>
up_77g3.asp
Regards
Mike
"SA Development" wrote:

> Hi,
> Do Named Pipes work across a WAN?
> Are they carried on TCP/IP? What ports?
> Thanks,
> SA Dev
>
>|||Hi Mike,

> Windows 2000 and 2003 encapsulate the data in networking layer TCP/IP
> packets. Named pipes is not efficient on slow connections.
> Your best option is to use TCP/IP sockets.
> Once you have firewalls in place, TCP/IP sockets is your only option.
Can you use windows authentication with TCP/IP or does it support SQL auth
only?
Does Named Pipes support both windows and sql auth?
Thanks,
SA Devsql

Distributed Transaction Over TCP/IP

I don't know to which discussion group this question is relevant, so I'll as
k
here.
I have two SQL Server servers A and B that are not on the same network. They
are both Windows Server 2003 servers. They communicate only using TCP/IP.
Using Query Analyzer, I connect to A and execute the following SQL statement
to add B as a linked server:
sp_addlinkedserver 'MyServerB.MyDomain.com'
This works fine and B is added as a linked server to A. I then execute the
following SQL statement:
select * from [MyServerB.MyDomain.com].[MyDatabase].[Dbo].[MyTable]
This too works fine and I get a list of the rows in the specified table.
Then I execute the following SQL statements:
begin transaction
select * from [MyServerB.MyDomain.com].[MyDatabase].[Dbo].[Mytable]
And after a minute or two I receive the following error:
Server: Msg 7391, Level 16, State 1, Line 1
The operation could not be performed because the OLE DB provider 'SQLOLEDB'
was unable to begin a distributed transaction. [OLE/DB provider returned
message: New transaction cannot enlist in the specified transaction
coordinator. ] OLE DB error trace [OLE/DB Provider 'SQLOLEDB'
ITransactionJoin::JoinTransaction returned 0x8004d00a].
I have tried executing 'begin distributed transaction' instead of 'begin
transaction'. That doesn't help.
The Distributed Transaction Coordinator is running on both servers.
TurnOffRpcSecurity is set to 1 on both servers. Both servers have SQL Server
SP4 (version 8.00.2039).
I cannot figure out what to do to be able to perform a distributed
transaction between these two machines. Any assistance on this issue would b
e
greatly appreciated!
Corey Young
Software Engineer
LANDesk SoftwareI had this same problem a few months ago, and the following support
article helped me resolve it:
http://support.microsoft.com/defaul...kb;en-us;839279
Stu|||Thanks for the quick response!
I have gone through the steps outlined on that web page with no success. Any
other ideas?
Corey Young
Software Engineer
LANDesk Software
"Stu" wrote:

> I had this same problem a few months ago, and the following support
> article helped me resolve it:
> http://support.microsoft.com/defaul...kb;en-us;839279
> Stu
>|||I found the problem!
I had to go to Local Security Settings, IP Security Policies on Local
Computer, Packet Filter, and uncheck Block All. I suspect this makes the
server much more vulnerable to attacks, but it wasn't working with Block All
checked even if I had a "permit" on port 135.
Anyway, at least now I have something working and can go from there to lock
things down more tightly.
Corey Young
Software Engineer
LANDesk Software
"Stu" wrote:

> I had this same problem a few months ago, and the following support
> article helped me resolve it:
> http://support.microsoft.com/defaul...kb;en-us;839279
> Stu
>|||"Young, Corey" <YoungCorey@.discussions.microsoft.com> wrote in message
news:7603CD79-0C56-4BF4-A301-3BB9CB4F8365@.microsoft.com...
> Thanks for the quick response!
> I have gone through the steps outlined on that web page with no success.
> Any
> other ideas?
> --
> Corey Young
> Software Engineer
> LANDesk Software
>
> "Stu" wrote:
>|||I too have got the same problem. I have run all the steps said in msdn.
microsoft.com. Still i'm getting the same error.Young, Corey, Can u explain
where to change the security settings you have told. Please reply me.Its
urgent.