I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.
Related
We recently migrated an application database to a new version from winserv2008/sql2008 to winserv2012R2/Sql2014. A service that pulls on this DB needs to be redesigned to accommodate some minor table/view definition changes.
Running the service code through tests under my personal security context works fine. However, installing and starting the service under .\LocalSystem is problematic. Looking at the service logs in event viewer I see that the service tries to connect to the sql server but gets a ERROR[28000] Login failed for user 'Domain\LocalSystemName$'.
The connection is via ODBC, SQL Server Native Client 11.0. Connection string is like:
"dsn=dsn_name;Driver={SQL Server Native Client 11.0};Database=database_name;Integrated Security=False;uid=accountname;pwd=accountpassword;Connect Timeout=15;ApplicationIntent=ReadOnly;"
Also, through the course of troubleshooting I've discovered/confirmed several things.
The sql server credentials I am using are correct, they are also being used to connect from a SQL2016 instance to the SQL14 server as a linked server.
The original service install on a utility server appears to be hitting the new database fine after the ODBC connection settings were switched.
My questions are:
Have you run into anything like this before?
Am I missing something simple in my connection string?
Are there per machine security settings in sql14 that I'm missing?
Trying to setup an ODBC connection for UPS to access our SQL server, from our shipping client computer.
I have scoured as much as I can an ran across:
runas /netonly /user:domain\account "c:\windows\system32\odbcad32.exe"
Now, using this method, on my current client computer, I was able to setup an odbc connection successfully using SQL Native Client 11 (5058). I am using Win 10. Our shipping computer, with multiple manifest systems on it, is still using Win 7, but otherwise is setup the same on the domain.
Using the same process as above, the connection ultimately times out, and states that the server is not online/not available/not allowing remote connections.
Is there a step I'm missing? Both clients have same rules for firewall, both are using the same user/password in the runas cmd. The only difference between the two clients is Win 10 vs. Win 7, and the current logged in user is different (but that shouldn't matter with the runas cmd?)
Thanks!
So after several days/hours of trying various solutions and suggestions from all over the interwebs, I came across this solution/tips.
In SQL Server Configuration, checking the network configuration protocols/clients/aliases. In my case, there was an aliases established for 32-bit, and not 64-bit. I disabled the 32-bit one.
I then found suggestions to us the ip (which I had tried in the past, with no success), but this time, after ensuring all the tcp/ip protocols were enabled and the 32-bit aliases was disabled, I was able to connect the 32-bit to the 64-bit SQL server, using the xxx.xxx.xxx.xxx address of the server.
Test came back successful!
Has anyone accomplished pushing files to a BOE server using SSIS? I am trying to develop a SQL Server 2008 SSIS package that will push report (Excel) files to our Business Objects Enterprise (BO XI 3.1) server. Via a Script Task, I am using the Business Objects .NET SDK components to authenticate and connect to the BOE Server.
I have a copy of the package deployed to a local instance of SQL Server 2008 running on my Windows XP desktop. The package executes successfully (via a SQL Agent Job) and delivers the file to the designated location on the BOE server.
When I deploy the package to our development SQL server (SQL Server 2008 on Windows Server 2008 64-bit) and attempt to execute the package via a SQL Agent job, I receive the error message "File Repository Server Input is down" when the script task attempts to "Commit" the file to the BOE server. The package is able to open a session with the BOE Server, create a new info object, but fails on the infoStore.Commit command.
I have another SSIS package that executes successfully from our development SQL server - it communicates with the BOE server and searches for user sessions. It does not communicate with the Input File Repository - that seems to be the key distinction.
I have found limited information related to this error that indicates firewalls and ports between the SQL Server and BOE server may be the cause. I have reviewed the BOE Administrator's Guide to no avail (most likely due to my lack of understanding related to firewalls and ports). Both servers are within the same subnet and neither server has the firewall turned on. The ports for the BOE CMS servers and the Input/Output File Repository servers have been set to static port ids. Our network guy indicates there should be nothing preventing communication between the servers based on firewall or port settings.
Any help would be greatly appreciated!
Have you tried all the usual 'run as 32 bit' solutions? I guess yuor SDK is a 32 bit one, not a 64 bit one.
http://www.bidn.com/blogs/ShawnHarrison/ssis/2362/ssis-basics-running-a-package-in-32-bit-mode
However the fact the the SDK works for different services implies that it runs OK in 64 bit. So if you want to troubleshoot ports, I found this link http://scn.sap.com/thread/2027785 which indicates that the BOE ports are 6400 to 6411. To check that a given port is open, you go to a DOS prompt and type
TELNET hostname port
So if your BOE server is BOESERVER then you'd try this:
TELNET BOESERVER 6400
to test port 6400. You should get a black screen to indicate it's connected.
However, again, the fact that you seem to be able to connect and operate but not commit implies there is not a port problem as you can connect, just can't commit.
Are there any logs in the BOE side to give you a better idea of the issue?
A resolution to this issue has been identified and verified. The Windows AD account used by the proxy the SQL Agent job uses to execute the SSIS package did not have sufficient privileges on the network. Our DBA gave the account local Windows administrator privileges on the SQL server and this resolved the "File Repository Server Input is down" error I was receiving.
Thanks to those who responded and gave me other ideas to investigate.
I have done some research, based on the problem that my single server gives me when I try to open a document library in windows explorer from the ribbon menu item "Open in Windows Explorer".
The same problem occurs when I try to map sharepoint to a folder in windows explorer too.
The error is:
Your client does not support opening this list with Windows Explorer
From the net, suggestions are:
(Since I'm trying this operation from server itself) enable Desktop Experience
Install the KB907306 update.
Enable IIS webDav service (Some say, it's just for additional functions from the MS Whitepaper)
(Edit) Started webClient service
I've already done them. Nothing changed. Proper machine restart and iis too have done.
Need some serious advice.
Thanks in advance.
Not sure if we are having exactly the same problem BUT I have had similar problem while accessing SP via Windows Explorer in Windows Server 2k8.
What I done to fix it is following:
Install new server feature called Desktop Experience (it comes with WebDAV redirector, which allows you to connect to WebDAV) - Note: Server will need to be restarted.
In Services start WebClient service (go to properties and make sure it starts automatically)
You will now be able to access your sharepoint via entering network path such as \sharepointhost\application\myawesomeapplication\ etc.
Hope that helps.
If you are trying to do this from the server, test it from a server which is not on the SharePoint farm (or better yet, a client machine). Ensure all of your testing is done from machines which are not on the farm.
Do NOT enable the IIS WebDAV service, as SharePoint provides its own WebDAV service and the IIS one overrides it in the pipeline. Enabling this service is a sure path to breaking WebDAV.
If you have SSL enabled, you may be in for a rough time getting it to work. Start by understanding how to use the 'net use' command, and the #SSL suffix.
make sure your webdav is installed as feature
make the following registry fix (http://support.microsoft.com/kb/841215) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Add a new DWORD "BasicAuthLevel" and change this to "2"
Restart your machine (and make sure it is enabled in IIS)
Make sure that WebClient windows service is running in the server. This shall appear in client operating systems like Windows 7, windows 8 however, on the server operating systems like Windows Server 2008, it shall be installed by enabling the server feature "Desktop experience" using Server Manager
This issue nearly killed me. I found that I was using a 64 bit version of my browser and that is'nt supported. I changed over to the 32 bit and it works.
I have a Delphi application running on SQL Server 2000, but it's taking awfully long to connect to the database!
But when I run this application on my development server it connects pretty fast!
I am running on Windows 2003 server, SQL Server 2k personal edition, when I look on my MDAC version in the registry, I see version 2.8 already installed!
Any ideas why this happens on the production machine but not on the development machine?
There's a reasonable chance that this is down to a network level issue connecting to the database. Depending on whether you're running the application and database on the same box of course.
Try connecting to the database from the same machine using a different tool. You could set up a data source and test it from the control panel as an alternative. If the connection is slow from another tool test the connectivity between the servers for other types of connection (e.g. run a ping). It may be that it's resolving the server via broadcast rather than the domain, for instance. Or any number of other issues - firewall, switch, wins etc.
If you are connecting using integrated authentication also ensure that the database can resolve the application server as well as vice versa. This is part of the authentication process and I've seen it cause slow downs in creating database connections before.
In short, I'd be confident that this isn't a problem specific to delphi / sql, but something in the communications between your production servers.
Good luck!
Keep your connection open once you have established it. This is called connection pooling and will improve performance. I have no clue how to do it with a delphi application.
Your problem most likely is network or transport layer related
Are you connecting through TCP, Named Pipes or another mechanism?
Have you tried tracing opening a connection with Microsoft SQL Profiler?
regards,
Lieven
I had a problem a long time ago like this, and it came down to the workstation section of the connection string. its possible if you've copied the connection string from your dev machine that the workstation parameter is still in the connection string and pointing to your dev machine which probably does not exist on your deployment network.
In this case your connection to the database has to wait until the network tries to connect ot a non-existant machine (which obviously takes time). Remove the workstation cluse and it will speed up no end.