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.

[bsanders69]

We have the same issue with connectivity continuity for file geodatabases getting dropped (maybe a tiny network drop), but it loses the connection and you lose whatever you have not saved.  I am not sure what settings in group policy may help, but would like to know if there's anything we can do here at the City. We have resorted to creating FGDB local because we cannot rely on a basically very robust and new network/all flash, UPS, all new Citrix server hardware, etc.

[LearnThenShare]

Hi @bsanders69 : It has been a while since your post.  Have you found a cause and solution?  Thanks!

[MattHowe]

We had the same problem and was incredibly frustrating. Once we switched from mapped drives to unc paths for folder connections and data sources, it seemed to fix the issue.

[LearnThenShare]

Hi @MattHowe :  This is promising. However I do not see an option to Map Drives in file explorer without choosing a Letter.   I have established UNC paths to the folder/directory where the file geodatabases (FGDB) are located on shared file servers within ArcMap Catalog and Pro Catalog.  I have used these UNC Paths to add FGDB data to ArcMap MXD's and Pro Projects.  I also only use UNC paths in shortcuts to the MXDs.  I have still found that the FGDB data drops connection for unknown reasons.  One interesting observation is that the Shapefiles located at the same UNC path do not drop their connectivity.  What is it with the FGDB that disconnects during this unknown LAN/WAN Network activity?  

[bsanders69]

I have not tried to gelook into this in some time as I have been working in different areas that all are referencing SQL Server SDE geodatabase for quite some time now and not editing FGDBs, so I can't help you there.  There is another way to give you a starting point in Windows other than mapping a drive is to "Add Network Location".  Maybe this is closer to providing a UNC path as you are asked for a UNC to create a network location and it is stored differently than a mapped drive.  Maybe worth a shot?  I've got nothing from ESRI.  Nor can I say that there may have been something addressed in version 11.x.

[MattHowe]

Yeah we saw exactly the same thing. SDE and SHPs worked fine but the problem was FGDBs. If you open the cmd prompt from the start menu and type; net use. This will give you the unc root paths of your mapped drives that you can copy. Then you can use this for your connections and data sources in Pro. Be careful mixing and matching mapped and unc paths though, you might run into some funky errors.