Named Pipes vs. TCP/IP connectivity issue using SQL Server 2014 on Windows Server 2008

I have a client that I recently developed a program for who was forced (economic reasons) to install SQL Server 2014.  All my prior experience has been with SQL Server 2008 R2.  I downloaded the new Native Drivers (SQLNCLI11) for this deployment and am currently encountering issues connecting from a workstation to the server (Window Server 2008, NOT R2!).  Program runs fine on their server itself but attempting to run the program from any of their workstations returns:
Named Pipes Error (53)
I've set up Windows Firewall rules for Ports 1433 and 1434, disabled Named Pipes and enabled TCP/IP using SQL Server Configuration Manager on their server, but I'm still getting the same error message.  Can anyone think of something else I need to do that I haven't already done to make this work?
Jim KlocksinOwner, Data ArchitectsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dave BaldwinFixer of ProblemsCommented:
The "Named Pipes" error is apparently the last thing the driver tries when it can't make a connection so I would ignore the "Named Pipes" part.  Check with the SQL Server Configuration Manager to make sure the ports you want to use are actually assigned / enabled.  When I installed SQL Server Express, port 1057 was the only port originally assigned.   Port 1434 is usually assigned to 'sqlbrowser.exe' which on my machines is running automatically as a service.  'sqlbrowser.exe' is what allows you to connect to an 'instance' of SQL Server.
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
Dave, on my server, I have opened port 1433 for TCP and 1434 for UDP.  Not sure where I got that info, but it works for me.  This particular installation is using the "default" instance (I do have other clients who run with "named instances") so I may not have to worry about port 1434.  Frankly, I've been emailing the setup information to this client's most knowledgeable computer person, but he really only knows basic stuff.  I'll have to make the trip and check this out for myself.  thanks for the response!
Jerry_JusticeCommented:
Some suggestions:

Add an inbound exception for sqlservr.exe in the 2014's Binn folder

And, in  SQL Server Configuration Manager, go to Protocols, then TCP/IP.  Then to the "IP Addresses" tab.

Scroll all the way down to "IP All"

If the port is assigned to TCP Dynamic Port, copy the number down and erase it.  Now re-enter that number in TCP Port.

For some reason, and I have not been able to determine why, some networks/servers do not allow the link from remote workstations when SQL Server is set to use Dynamic Ports.  Move that port # to the static port line, and it will work fine (sometimes).

Last - run cliconfg  (START/Run/Cliconfg) on the workstation and make sure TCP/IP protocol is enabled.

OK.. one more last..  Make sure an antivirus/protection programming running on the workstation isn't blocking TCP/IP to your SQL Server.  Unlikely, so try the other stuff first.  

Good luck!
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Dave BaldwinFixer of ProblemsCommented:
I never heard of using UDP to connect to SQL Server or any other database server.  On this machine and another one here, port 1434 is open on TCP/IP for 'sqlbrowser.exe'.  

Oops! I just checked with TCPView and it is UDP on 1434 for 'sqlbrowser.exe'.  'sqlserver.exe' is listening on 1057 and 1433 on TCP/IP.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
That's correct. udp/1434 is used for SqlBrowser, and required if the connection string uses a named instance (no port). The default, unnamed instance does not need the browser, and if you provide the port with the connection string it isn't asked either.

But that does not help here. The unnamed instance listens on port 1433, unless that port is occupied already by other services.
Sometimes it happens that SQL Server does not correctly bind to all (virtual) network interfaces, or uses a different port on each. As stated above, the "IP All" setting should be used to pin a port.
Deepak ChauhanSQL Server DBACommented:
Check TCP/IP protocol should be enabled in sql configuration manager.
TCP Port 1433 should be open in firewall and you can add sqlservr.exe in Advance firwall setting exception list.
"Allow Remot connection" should be checked in server property.

Additionally you can try to connecting sql server by ip address.
Vitor MontalvãoMSSQL Senior EngineerCommented:
By default MSSQL 2014 uses dynamic port so there's a big chance that isn't listening on 1433. Use Configuration Manager to confirm is which port the SQL Server instance is listening to.
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
I appreciate all of your suggestions and have gone thru and checked each one.  Log files proved that SQL Server is listening on Port 1433 for TCP and 1434 for UDP....the TCP/IP IP address tab confirmed that this version of SQL Server was set up to listen on port 1433 in all cases.  I added the exceptions for the "sqlservr.exe" program in their Windows Firewall setup.  Unfortunately, all to no avail.  What I did discover (but was never told by this client) is that they have an additional firewall security through some type of Comcast router that they didn't have the access information for.  They are a non-profit dealing with sensitive information so they're going to have the same company that set up this firewall come in to, hopefully, open up the necessary ports/programs so the network can communicate with the SQL Server.  

Bottom line is that, at this point, my role has been reduced to simply waiting for them to get this company in to attempt to fix the issue.  Since this was a project I took on for free as "volunteer work" (with the hope of future "paid" opportunities based on recommendations), I have to yield to their wishes and hope that their "network company" gets things working.  Fortunately, this was a relatively small project and, as stated above, my role is being kept separate and apart from the network setup so I have no further responsibility in this (other than my desire to see this work, both for their sake and for any potential future opportunities that may arise from this project).

So, I'm going to close out this question since it's no longer an issue that I can pursue myself.  Thanks again for all the posts and suggestions!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
Since I bear no further responsibility for resolving this issue, there's really no point in keeping this question open!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.