venerdì 28 gennaio 2011 19:27
I am struggling to determine the cause of a random network connectivity drop and made a post about it on the Windows Server 2008 forums but they told me it sounded like a sql or dynamics issue so I'm cross posting in an attempt to get my issue in front of the eyes of someone who can help me.
I was told I put too much info in my thread, i'll try not to do that here but here's the important stuff you should know:
- We purchased a new server to run Microsoft Dynamics (HP Proliant DL380 G7 with windows server 2008 R2 x64)
- We upgrade dynamics from GP8 to GP9 and then to GP2010 and when we did so we did not have sql 2008 licenses available so we installed sql 2005 x86 version (all I had available..) and set the databases to that level of compatibility.
- I upgraded all dynamics client pcs (windows XP) to the new version. Everything worked fine. No network failure issues.
- One month later I was able to purchase a sql 2008 license so I uninstalled sql 2005 x86 and installed sql 2008 x64. Changed the compatibility level to the 2008 version and restored the databases. I also purchased a windows 7 workstation to install dynamics onto because I needed to test that everything would work correctly for when we phased out the XP machines.
...and this is where my problems began happening
So my current situation is that the windows 7 workstation, and only this workstation has network connection issues when using Dynamics and using a program which reads from an access 2000 database stored on a network share (but also ties into dynamics through a second odbc connection). It will randomly pop up "disk or network error" messages and when it does so it closes my odbc connection to the server. I can still ping the server, but to open back up the odbc pipe I must close and restart the problem application. When all of this happens no event log network up/network down messages are logged, only an application hang error message with no detail data or error code.
To prove out that this was not a hardware issue i've ran another network drop to the office which this workstation lives in. I also replaced the network switch which was common to the workstation and the two servers which host the dynamics databases and the access database. I also added another nic to the client workstation and also swapped to another nic in the dynamics server. The issue disappears for a short while but always reappears.
None of the windows xp dynamics workstations have this issue. Only the one with windows 7 is doing this, and it's the only one like it in the building. To rule out an issue with a 64 bit os I rebuilt the machine to run a 32 bit windows 7 version and the problem still persists.
Since the application that works with the access database (Parts and Vendors 5.0) uses an odbc connection that points at my 2008 sql server and Microsoft Dynamics uses an odbc connection that points at the 2008 sql server I feel inclined to think that the issue is a sql related issue because of this. However since the windows XP machines are not affected by this I find it hard to believe that something is wrong with sql server. Since I replaced the primary network switch I definitely feel that it's not a network issue.
I just don't know if this issue is a dynamics issue or a sql issue. From a windows 7 standpoint, what would be different that would prevent this stuff from working? The problem is intermittent, sometimes taking up to 6 hours to happen but sometimes it's with 15 minutes of starting work in the morning.
Ok that's all I have. Hopefully those of you still reading can point me to an answer. I've got to get back to writing code, not chasing these issues. So any help at all will be very much appreciated.
Tutte le risposte
lunedì 31 gennaio 2011 19:14Intermittent errors can be tough. Since you seem willing to test a lot of stuff, some suggestions: You didn't mention if there was heavy network traffic during the problem times. It might be something that affects IPv6 instead of IPv4. Try disabling IPv6 on the Windows 7 client and Windows Server 2008 R2. (I'm actually thinking of the loose source mapping change in Win 6 due to having multiple IP addresses on the server, but I wouldn't expect that to be intermittent. http://technet.microsoft.com/en-us/library/ms190181.aspx )
Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
mercoledì 2 febbraio 2011 21:47
Thanks for the comments.
Network traffic was a possible cause for concern as we recently moved a lot of directories around and mozy was spinning its wheels to stay caught up. However my issue has been going much longer than the last couple of weeks so I do not think this is the issue.
As far as ipv6, dhcp server isn't handing out any of those addresses because I only configured an ipv4 scope. I will review the steps needed to disable it and let you know what happens.
Anyone else have any suggestions? I'm definitely not afraid to test to find the source of the issue.
I'm actually going to crawl up in the ceiling this week to make sure that the network drop for the office in question does not run perpendicular across a power wire or ballast or anything that could induce interference. I might pull a new drop for sanity's sake.
I'd love to find the source of the issue so I can get back to my winforms->wpf software conversions.
mercoledì 2 febbraio 2011 23:56This isn't really a suggestion, more like food for thought. Thinking of errors that happen for Windows 7 client but not older clients got me thinking about OS settings. For example look at http://msdn.microsoft.com/en-us/library/ms187005.aspx and http://blogs.msdn.com/b/sql_protocols/archive/2008/04/08/understanding-connection-forcibly-closed-by-remote-host-errors-caused-by-toe-chimney.aspx I know you haven't seen any connection forcibly closed errors, but maybe some are getting swallowed somewhere. I guess my point is that Windows 7 clients might have included some new feature in their network layer that coordinates with Windows Server 2008 to prevent some sort of hack that older clients can't protect from. Extended protection http://msdn.microsoft.com/en-us/library/ff487261.aspx is another example of settings that only apply to a newer OS. So my advice, is keep looking for errors related to the OS. The connection forcibly closed example could be intermittent at periods of high volume.
Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
venerdì 4 febbraio 2011 19:22
Thanks rick for the suggestion.
There's a feature included in win 7 called data execution protection that I felt might be reponsible for something like this...
but I disabled ipv6 on the client entirely and disabled data execution protection and still see the same stuff.
edit: [2/4/11 02:15PM]
I might have just been able to rule out a sql server problem with this....
I have two win 7 users affected by these network issues described in my post. One user uses MS Dynamics and a special odbc pipe to "look up" data from our access database and they also use the parts&vendors application to directly work with the data in that database. The other win 7 user simply uses the parts & vendors application and directly connects to the access database across the network, using oledb (I assume this since I see Jet related errors).
Both users get the same error messages. But only one is using the custom odbc connection. So between the two users the only common configuration is windows 7 professional and the access 2000 backend database.
This leads me to believe that I may need to dig around and see if access 2000 or the protocol which I use to talk to it is actually my issue.
venerdì 4 febbraio 2011 19:43
My first guess would be the Access2000/Windows7 Compatibility. Not compatible: http://social.answers.microsoft.com/Forums/en-US/w7programs/thread/73b6f2a0-4b22-42a1-aa3b-70e88e002628
- Contrassegnato come risposta Ai-hua QiuModerator giovedì 10 febbraio 2011 09:10
venerdì 4 febbraio 2011 19:46
Try upgrading your Access database and see if that resolves the issue with your Windows7 users.
lunedì 7 febbraio 2011 22:05You bring up a good point. I will look into what I can do to upgrade.
mercoledì 4 aprile 2012 21:12
I just realized I never came back to update the fix to my problem.
The issues I was having in the odbc pipeline between my Parts And Vendors application and MS Dynamics was fixed my one of the many network patches included in the win7/server 2008 R2 SP1 iso that I got from msdn. The server that hosted the dynamics db was patched and rebooted and I've not seen the same issue once since.
Thanks to everyone that tried to help. I luckily just found the SP fixed my issue after the fact.
- Contrassegnato come risposta Tanner Wood mercoledì 4 aprile 2012 21:12