Access 2013 - Your network access was interrupted w/Windows 10

Question

I'm having a problem w/Windows 10 and Access 2013 (via Office 365) with network disconnects, although I really don't believe there to be a network problem.  Figured I'd start here, since the Windows 10 forum will most likely try to tell me this is an Access problem.

First off, we only have about 7 computers connected to a server, these same computers have been running Windows 7/Access 2010 for years without any disconnect problems.  Even the past few months ago we switched to Access 2013 via Office 365 and didn't have any issues.  It's only as I started to upgrade a few machines to Windows 10 that this problem started cropping up and it is only happening on the Windows 10 machines. 

Basically everything works fine until you let the computer sit idle for anywhere from 5-20 minutes and it will mysteriously disconnect itself.  The DB is a FE/BE DB.  I've tried running the FE DB locally and it still does it.  On my desktop, which I use for development, I tested by running various VM's w/Access 2003, 2013, etc.  The only one that disconnected was the Windows 10 VM running Access 2013.  We had a drive mapped to a SBS 2011 server and so I loaded up a new 2012 server and created a mapped drive to that to see if it was something w/Server 2008.  While it was just me doing development for a week on the new server I never had a disconnect.  So this past weekend I figured 2012 server must fix the problem and so I moved our DB to that server.  Now that everyone is on it, now the disconnects have come back, but again, only with the two machines running Windows 10.

I've looked at various options for power management on the NIC's, tried disabling everything possible related to that with no avail.  Nothing else gets disconnected and again, these are the exact same machines that running windows 7 and Access 2013 worked just fine for months/years.  The same Windows 10 machines don't disconnect from Remote desktop services or anything else, just a blip that seems to kill the access connection.

I don't know if it's some weird SMB problem or what, but if I can't get this figured out I'm going to have to go back to windows 7 because I can't have it constantly disconnecting throughout the day.

Answer 1

I believe the root problem is Windows 8 and Windows 10 now do asynchronous policy application.  The GPP drive mapping with the option of replace instead of update, which has it's own issues because it doesn't disconnect the drive if the GPP no longer applies, actually disconnects and reconnects the drive as part of GPP application every so often.  Windows 7 didn't do this.

For more info you can see these various articles...

https://community.spiceworks.com/topic/478226-gp-preferences-drive-mapping-with-replace-issue-on-windows-8-1

http://community.spiceworks.com/topic/489005-windows-8-1-drive-maps-disappearing

https://technet.microsoft.com/en-us/library/cc940895.aspx?f=255&MSPPError=-2147217396

http://www.grouppolicy.biz/2013/07/new-background-drive-mappings-in-windows-8-1/

Luckily we're small enough that Update works just fine and seems to have solved the problem so far.

Answer 2

>How large is your network? Are you sure its not due to Windows going to sleep? Does the problem only happen when the app is idle? 

In this instance 8 computers and 1 server.  The server is running Server 2012 R2 Hyper V w/a SBS 2011 VM server that used to do the file share.  Now I have the file share moved to a different VM server running 2012 R2.  Windows is not going to sleep.  I have all the WIndows 10 machines set to not go to sleep and it'll happen right while you're using the computer (such as web browser) but access sitting idle.

Yes, the problem only happens when the app is idle.  We've had it happen as quickly as 5 minutes, as long as 15 or 20.

> Its probably not a good idea to leave an Access FE open and idle at any time.

It's not feasible to have my users shut down the app any time they are going to be idle for more than 5 minutes.  Our application is based on inventorying items that we might not have any idea what they are, so it's necessary to go browse the web for a while to look up information and then come back to it.

>Also you said; "I've tried running the FE DB locally and it still does it." Does this mean you are using a shared FE, because that is not the way to go.

I understand "this is not the way to go" as has been said for years and years, however as I said in previous reply I've got dozens of DB's running at various clients and I share the FE all the time without any problems.  It's easier to update one copy then try to maintain a separate copy on each client.  I also use readonly and runtime switches at most clients, however this gets off topic as I have no problem copying down the FE to each workstation in this instance (as I already have) and it still does the same thing.  So the shared FE is not the problem.

I can take a workstation with Windows 7 and Office 2013 and put it in the same network jack and it will run just fine.  I can leave the front end open over an entire weekend and not get disconnected.  But with windows 10, that doesn't happen.  I know this is weird and believe me, years and years of doing DB's and troubleshooting without ever posting something here because I can always come up with a solution/fix.  In this case, I am at a loss.  

There used to be a thing way back in the day on Windows File servers and older clients (i.e. WFW 3.11, Win 95) called Opportunistic locking that caused HEAPS of problems with ISAM databases such as Access/B tree/C tree and other FILE based databases.  The only solution was to disable that function on the server.  This problem seems similar and it feels like there should be some setting in Win 10 to stop this, but I've not been able to find it.  I was suspicious of SMB settings and have not tried changing those yet.  

As I also said, the exact same workstation (my development one) running various VM's all at the same time and none of them disconnected, except the host Windows 10 environment.  If it was truly a network blip, then all the VM's would have experienced it.

I left 4 Windows 10 machines connected and open last night.  At lunchtime today I will go see if any of them stayed connected.

Answer 3

>I'm assuming this is a typo and you meant both FE and BE are local as well in this scenario.

No, I typically run the FE and BE from the same shared network location.  I know this isn't the preferred method and everyone says to run the FE locally, but I've done this with dozens of DB's over the past 15 years with no problems.  Just to troubleshoot I tried moving the FE locally and it still disconnects.  Running both locally would make it single user defeating the purpose.  I will however copy both down and attach and I doubt it will disconnect since the network layer is gone at that point.

What happens is if the DB is open to a bound form and you walk away or move over and do web browsing, TS or whatever else within 15 minutes or so it pops up the dialog saying your network access was interrupted.  All bound fields bring up #name or whatever it is.  I'm actually off site today at another location, but I can remote in and do other tests.  I can post a screenshot of the app when it does this if it would help.

I actually have another laptop I borrowed that has Windows 10 on it and another machine that I started to reload w/Windows 10 that i was going to test as well.  Can report back later the results on those.  As I said, these are the same machines that worked for along time just fine w/WIndows 7 and Access 2010 and for the last few months w/Access 2013 without these problems.

I like your idea of splitting the NW DB and testing that.  My feeling is it will probably happen.  It's obviously some type of actual 'network disconnect'.  However, the physical network is not disconnecting, since I can stay connected to other persistent connections as well, such as Remote Desktop, etc.  it seems to be something WIndows 10 is doing to cause it.

Answer 4

How large is your network? Are you sure its not due to Windows going to sleep? Does the problem only happen when the app is idle? 

Its probably not a good idea to leave an Access FE open and idle at any time. Also you said; "I've tried running the FE DB locally and it still does it." Does this mean you are using a shared FE, because that is not the way to go.

Access is very sensitive to network fluctuations. have you tried maintaining a Persistent Connection?

Answer 5

> I've tried running the FE DB locally and it still does it.

I'm assuming this is a typo and you meant both FE and BE are local as well in this scenario.

This is what I want to focus on, because it very much simplifies the scenario. No more nics, server os, etc.

Are you really sure it happens in this scenario?

What exactly happens? IOW, what are the symptoms of the disconnect?

If it really, really happens, can you do this: split the Northwind sample application, and try to reproduce.