Several months ago a second exchange server was installed in our domain at a data center, wear-as the first server is located at the local office location.
Both Servers are exchange 2010 SP2 and everybody user outlook 2010 and both have a separate UCC SSL certificate for their own domain.
Both servers have CAS, Hub and Mailbox server roles.
Half of the existing staff members were moved to the new server and are sending and receiving emails via the new server (trusted domain).
The biggest issue for the staff members on the new server is that the shared calendars work very slow. often when opening a shared calendar or setting up a meeting outlook just gets stuck and after half a minute or so and pops up a message "Outlook is trying to retrieve data from Microsoft Exchange server server name.domain." - this mainly happens when attempting to add rooms from the address book and then pops up an error "the operation failed".
Sometimes a message that pops up is:
The address list cannot be displayed.
The connection to Microsoft exchange is unavailable.
Outlook must be online or connected to complete this action.
This is an issue that everybody experiences from the new exchange server. when comparing the the configurations of the two servers noticed that the local auto-discover url of the original EXCH SRV was https://mail.domain.com/Autodiscover/Autodiscover.xml and not https://'netbiosname'/Autodiscover/Autodiscover.xml.
After changing the internal URL for the new server to be the same as the external the performance improved a lot, but there are still many of those popup messages and "spinning wheels". And it seems like lately the problem is just getting as bad as it was before the change.
There are no errors or warnings in event viewer.
I have setup fiddler on my pc and i noticed a number of errors:
There are many 401's when connecting to /ews/exchange.asmx. After several 401, there is a 200.
Outlook connects to the EXCHserver1 autodiscover and not EXCHserverNew - and also gets several 401's before getting to the 200.
When working on an account that is located on EXCHserver1 in fiddler you can just see direct tunnels to mail.domain.com.
When I loaded a mailbox at the data center where the EXCHserverNew is located the performance was much faster but still not 100%, and there were still the same errors showing in fiddler.
But when I tried a EXCHserver1 account at the data center, everything worked just fine.
My last resort to solve this is to move the New exchange server to the local office, which I want to avoid since it wont solve the problem 100%.
I ended up opening a case with Microsoft, and after two weeks of tests with them several things were done to improve the severity of the issue:
Increased the ThrottlingPolicy for the EXCHserverNew cmdlet in EMS
Disabled TCP/IP metrics 'TCP Chimney', 'RSS', 'Autotuning' & ‘NetDMA'
Disabled IPv4 Checksum Offload", "Large Send Offload Version 2 (IPv4)", "Large Send Offload Version 2 (IPv6)", "TCP Checksum Offload (IPv4)", "TCP Checksum Offload (IPv6)", "UDP Checksum Offload (IPv4)", "UDP Checksum Offload (IPv6)", on the NIC card level of the EXCHserverNew
Changed the Hosts file on the clients machines to point ot the local IP on the exchange server.
This improved the issue a lot, but outlook client calender still takes a second or two to load or open the OAB.
Related
I am attempting to set up a communication between Labview and Microsoft SQL Server, on two separate devices, in order to send and receive information about the database from both labview to SQL Server and SQL Server to labview. However, when I reach the "Data Link Properties" menu, I get the same "unable to log in" error upon attempting to log into the server. The server name comes up, however, an error occurs once I move on to select the database on that server. Is there any solution or tutorial to this problem that can allow me to successfully communicate back and forth from labview and smss on separate devices?
I've opened up various ports to allow a connection, even disabled the firewalls on both devices. The devices are connected via an Ethernet cable and I AM able to ping the devices to each other. However, in regards to being unable to log into the server in ssms, I have created new users, adjusted the login properties, tried changing permissions, but anything I try doesn't seem to solve my issue.
Can't really help much without seeing the error or some of the code of what you are trying to do.
That being said, if you go to the menu and select Help>Find Examples... and search for database, you should see a bunch of different things related to database connections. You may find the Database Connection.vi one helpful.
More info on the Database Connectivity Toolkit in LabVIEW can be found here
I see there can be one of the 2 issues
1) Inbound/Outbound port rules not set, Remote connection to server is not allowed.
2) If the server has multiple instances then you need to provide full host name of the instance you are trying to connect.
*Please refer to the below link to configure firewall rules.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-2017
Machine 1
Windows Server 2008
SQL Server 2008
The database. Contains all the information our sites use.
Machine 2
Windows Server 2012
IIS 8
The webserver. Uses IIS to host two sites:
Production site: (default) Has the most up-to-date UI and features
Backup site: Older UI, but still using the latest data from Machine 1
Here's how it works:
User goes to one of the sites hosted on Machine 2 and enters their company information
Machine 1 is queried for that company's connection string.
The site uses the connection string to connect to the correct database on Machine 1.
The problem is that about 1/3 of the connection strings use the network name (e.g. "Data Source='Machine1';") while the other 2/3 use the IP address (e.g. "Data Source=192.168.1.200;"). When connecting via the Production site, a timeout occurs if uses a connection string with a network name. However if the same user, using the same credentials, logs in to the Backup site, everything works fine regardless of which 'Data Source' is used.
I created a simple Powershell script to test the connection from Machine 2; network names and ip addresses both work, which makes me suspect it is an IIS or web.config issue. I've gone through both extensively, and these are the only differences I've noted:
Different Application Pools in IIS: However when I ran "Get-CimInstance Win32_Process" it showed both instances of w3wp.exe had been started with the same command and arguments (with the exception of different pipes)
Slightly different web.config. The Backup site has an entirely self-contained web.config, while the Production on stores its connection strings is a separate file.
Been banging my head against this for several days. Very limited in the steps I can take considering this a production website and
Database. Any advice is appreciated.
Try putting the network-library in the connection string to force tcp.
see connectionstrings.com/define-sql-server-network-protocol
;Network Library=DBMSSOCN;
PS
Yep. Been there, done that. 4 days of "on site" client visit.......and it was the protocol.. Thus how I learned to force it via the connection string. You can also try this:
Create a (temporary) System DSN (ODBC in Control Panel) with a weird name like "peanutbutter". There is a client connection button in there somewhere. Force it to tcp. Then search your registry for peanut butter and find out how the network library gets stored.
A picture is worth a thousand words. See left side of image below. (a random image from the old interweb)
I've recently moved a classic ASP site from a single-server IIS6 (Window Server 2003) and SQL Server 2005 setup, to a Hyper-V setup running Windows Server 2012 on the host and two VMs (single machine).
Here is a diagram of the current setup:
My problem is that I am getting the following error intermittently:
Named Pipes Provider: Could not open a connection to SQL Server [53].
I've been told and was able to prove that the web-to-DB traffic never uses the physical NIC, so that should rule out any issues w/ the NIC or its drivers/configuration.
I've also made sure that there are no IP conflicts (the host and VM IPs are all different).
The only pattern I can detect is that it seems more likely to happen during peak periods. The odd thing is it can go 7 days without an error, and then on a single day, the error will happen on 50-100 requests, often within the same 30 seconds, or in groups of 30-second intervals.
I've been trying to figure this out for weeks -- since migrating to the new server over 3 weeks ago. If no one here can help, my last resort is to open a ticket with Microsoft. However, I'm not optimistic they will be able to help as I'm not able to reproduce it.
As a last resort, I'm considering moving them back to a single instance, which I'm trying my best to avoid.
Update:
Here is the connection string I'm using:
Provider=SQLNCLI11;Server=[my DB VM IP address];Integrated Security=SSPI;"
Not sure if this is the correct forum for this, but here goes.
Im looking for any suggestions as to what I can try to reslove this...
I have an Access 2003 front end (on each client) with SQL 2008 database. Ive went round each user and set up the odbc connection on each pc.
for most users its fine and been working well for a year, but for a few every now and then when running a query (either an update or a select when opening a form) the SQL connection seems to have been dropped and they cant go any further.
I cant think of any glaring difference between those who have it working and those who dont.
Any idea's where I should start with this?
thanks
I've had such cases before: Access frontend, SQL Server backend. On one or some of the customer's PCs, the connection suddenly drops (throwing some ODBC or SQL Server connection error). Happens randomly and rarely (e.g. once per hour/day/week), and the Access application needs to be restarted to continue working.
In all of these cases, one of the following was the culprit:
Broken network cable
Broken network card
Buggy network card driver
Unstable network protocol (yes, this one was in the old days of NetBIOS)
The thing is: Access is extremely sensitive to network errors. A simple glitch in the network, a few seconds of lost connectivity -- something which you won't even notice with other applications -- will cause an Access frontend application to lose its database connection and crash horribly. It's very frustrating, because the customer will say "I don't experience any network trouble with Word/Windows Explorer/etc., so my network is fine, and it's your application that's broken." It's not true. If Access experiences sporadic and unpredictabe network errors, it's usually really a network problem.
So, the first thing I'd do is to replace (a) the network card, (b) the network cable and (c) use another switch port for one of the machines experiencing problems. If the problems are gone on that machine, you know that one of these components was the faulty one.
For some time now our flagship application has been having mysterious errors. The error message is the generic
[DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.
This is reliably reproduced by leaving the app open for the night and resuming work in the morning. Since it's a backend server app this is a normal scenario.
The funny thing is - we've migrated from SQL Server 7 to 2000 to 2008 and the issue is present on all of them. But what seems to matter is the OS on which we run the app. On WinXP it works fine, on Vista/7 it fails. So the problem is at the client end.
The results of Google on the error message cover a very wide spectrum of different causes (since this is a very generic error) and none of the scenarios found there are similar to ours.
So perhaps someone around here will know what the problem is in our case?
You should be able to reproduce this error condition on demand by:
1. Opening a database connection (in your client application)
2. Unplugging the network cable
3. Plugging network cable back in (wait until the network connection is restored)
4. Using the previously opened connection to query the database
As far as I can tell from experience, client side ADO code is not able to consistently determine if an underlying network connection is actually valid or not. Checking if the database connection is open (in the client code) returns true. However, performing any operations on that connection results in a General network error.
The connection pool appears to be able to determine when a connection goes 'bad' so it never returns a bad connection to the application. It simply opens a new connection instead.
So, if a database connection is kept alive for a long time (used or unused) by the application, the underlying TCP/IP connectivity can get broken.
The bottom line is that database connections should be closed and returned back to the connection pool when not in use.
Edit
Also, depending on the number of clients connecting to the db, not using the connection pool can cause another issue. You may hit the maximum number of sockets open on the server side. This is from memory. Once a connection is closed on the client side, the connection on the server goes into a TIME_WAIT state. By default, the server socket takes about 4 minutes to close, so it is not available to other clients during that time. The bottom line is that there is a limited number of available sockets on the server. Keeping too many connections open can create a problem.
One project I worked on easily hit this socket limit with around 120 users. A new 'feature' was added that absolutely hammered the server, and after a few hours of using the app, things would suddenly slow to a crawl for everyone. SQL server was not closing enough sockets in time for new connection requests. Although there are 65K sockets altogether, only the first 5000 are made available to the ADO (this is a default registry setting thing, so can be changed).
The number of sockets in TIME_WAIT state would slowly build up until the OS would not allocate any more. So clients had to wait until server side sockets closed and a new connection could then be created.
Have you tried disabling SNP/TCP Chimneying?
Had a similar error. For me it was indirectly caused by mismatched calls to WSACleanup and WSAStartup.
The program called WSACleanup more times than WSAStartup. This would cause a reference counter (somewhere in the sockets library) to reach zero too early.
I think effectively from that moment on all sockets owned by the process are broken.
And this would also kill the SQL client since it uses sockets to 'talk' to the SQL server as well.