Problems with file geodatabases on a network server

[JohnYoung2]

Hello,

I am aware of a known issue that causes frequent errors (General Function failure) when a File GDB is referenced on a Windows 10 server environment. When this occurs the application needs to be restarted to re-establish a connection to the data. We have a small number of ArcGIS users at our site but suffer from this problem several times every day, with both ArcMap and ArcGIS Pro. The established workaround appears to be to change the Windows group policy settings from 'Replace' to 'Update', which sounds simple. Our IT department have ruled this out of hand saying it is against Microsoft recommendations and it is not possible to make a change for the few ArcGIS users because the change would impact all users in the organisation and other applications would not work if we changed the setting. They are implying that changes can only be done globally (per organisation, across multiple servers), not per user, user group, or single server.

Has anyone had first-hand experience of this problem? Did your IT department change the group policy settings to resolve the problem and was this change complex to implement? Has anyone had similar push back from their IT department for group policy changes? We have less than 10 ArcGIS users but 300+ using the network; perhaps the workaround is only feasible for smaller organisations where impact is lower?  

Any insight on the implementation and impact of the group policy changes workaround would be much appreciated.

Thanks.

[JoshuaBixby]

Regarding "a Windows 10 server environment," I am not clear what you are referring to since there is no Windows 10 server operating system.

The issue of mapped drives being interrupted with Group Policy updates isn't unique to Esri or file geodatabases, although ArcGIS doesn't handle them well at all.  I believe the issue started popping up more after Windows 8.1 was released.

The organization I work for encountered large impacts from this issue when it stood up Citrix virtualization in a new data center environment.  The solution we applied was to change the GP from "replace" to "update."

Group Policy is quite flexible, most of the time.  We have applied the "update" change to specific virtual machines used by Citrix in our data center.  We chose machine-level mapping because all users on the machines will want to see the same behavior, but I believe the GPO can be handled at a user level as well.  Anyone who says it can only be applied globally either doesn't understand the question or doesn't understand Group Policy.

[JohnYoung2]

Thanks Joshua, that is very helpful.

The problem appears to have started on migrating from Windows 7 to 10, on a Windows Server 2008 R2 environment. We have since been upgraded to Windows Server 2019.

[JoshuaBixby]

Are you still seeing the issue with Windows 10 clients and Windows Server 2019?  If so, then a Group Policy change is the best (maybe the only) remedy.  At a minimum, such a change can be implemented at a machine-level, and it might even be possible to do it at the user-level by putting the impacted users into an OU and then applying the change to just that OU.

[JohnYoung2]

Yes, the problem persists following the upgrade to Windows Server 2019, so I will have to persuade IT to reconsider their stance.

[MichaelVolz]

John:

Do you see failures when processing data on a file geodatabase on a network share?  Or do you just not get the expected results of the geoprocess?

[JohnYoung2]

Michael,

The problem affects mapping and edit sessions in ArcGIS Desktop (10.x) and ArcGIS Pro (2.x) and occurs at least every 30 minutes. On Desktop there is a General Function Failure message and feature classes in the geodatabases are no longer usable. The geodatabases need to be removed from the Table of Contents and re-added from Catalog. On Pro there is no message; instead, editing and mapping (even with shapefiles) is no longer possible (snapping doesn't work, features disappear completely, or when zooming in or out). With Pro, I usually exit and restart the software to resolve.

I haven't experienced any adverse effects with geoprocessing tools or ModelBuilder, but this could be because most of the processes that I have run have completed within 30 minutes.  

[MichaelVolz]

My issue is different from yours, but file geodatabases on the network are the common denominator.  I have found at least 3 geoprocessing processes (I'm running ArcMap 10.7.1) that when run over the network on a file geodatabase produce different results.  The same process run locally produces the correct results every time.  The processes that produce these erroneous results take less than 10 minutes to run.

Are you using any network auditing tools to determine the root cause of your issue?

[JohnYoung2]

We have not used the network auditing tools because the underlying cause of our problem is already known and there is a workaround (i.e. modifying the Group Policy settings). I had planned to do some testing after our group policies were adjusted but still waiting for approval from our IT department.

If you have a compliant IT team you could re-test the geoprocessing tools with the recommended group policy settings.

Out of interest, which 3 geoprocessing tools are affected by your problem? Are you saying that these tools produce different results each time, using the same inputs? Are you running them as standalone processes, or from ModelBuilder or Python? 

[LearnThenShare]

@JohnYoung2  Hi John: We are experiencing this FGDB interruptions now that our IT is changing VPNs.  The FGDB connection gets "dropped" around the 10 to 15 minute mark.  The Shapefiles at the same file server location does not drop.  We have two GIS data editors and 60+ GIS users.  Everyone will lose connection to the FGDBs located on the file server.  What was your solution?  Thanks!