File Geodatabases Made Read-Only in 10.1 with Microsoft Forefront/System Center 2012

[NathanHeick]

Is anyone else out there experiencing issues with ArcGIS 10.1 and Microsoft Forefront/System Center 2012?  Based on the last few months of testing, we have had file geodatabases get made read-only during geoprocessing operations, importing XML, and editing in ArcMap.  We have been able to solve the problem by disabling Behavior Monitoring in the antivirus software.  The problem does not happen with ArcSDE or personal geodatabases.  It also appears to be related to the shared locks users open.  For example, when viewing a feature class in ArcCatalog, the shared lock conflicted with running a geoprocessing tool on the same feature class.  This was never a problem previously within the same ArcCatalog session.  The software always resolved a lock held by the same process.

Please reply back if you are having similar issues.  I would like this to be fixed sooner versus later.

[DavidBrandt]

We've been experiencing a similar issue on a file GDB checkout from an SDE database. Edits sometimes will not be accepted with a message that the GDB is read only.
Did you find a solution?

[NathanHeick]

Not yet.  I need to follow up with someone on the database team I talked to at the Dev Summit.  No update from Tech Support.

[StevePeaslee]

Hi,

I just started seeing similar issues when running an ArcSDE-to-FGDB export script. I hadn't run it for a couple of months, but yesterday I was running a small export of about 60 tables and 5 featureclasses from our ArcSDE 10.1 database (SQL Server 2008R2). Usually the failure was during the Copy_managent command.

There was a strange pattern.

I first experienced the problem when running it on my laptop. When exporting to a FGDB under a folder on my C drive, it would fail at different times, copying different tables. When I changed my output location to another (slower) internal drive C: it would work every time. The failure was during Copy_management and the error message was not helpful. After each failure I would check the input table and output geodatabase and could find no problems, everything seemed to be fine and I could manually use Copy_management without problem. My laptop drives are C: Micron SSD and 😧 Hitachi TravelStar ATA 500GB

Next I moved operations to another higher performance desktop computer. I saw very similar problems, except that the first failure to export to a FGDB under C:\Geodata occurred near the end of the process. All of the tables and featureclasses were successfully copied and the script was in the process of recreating the relationshipclasses. The error message indicated that the output FGDB was read-only. Subsequent attempts to export to c:\Geodata failed after a couple of minutes while copying tables. It did not fail on the same table each time. As on my laptop, I tried changing my output location to another internal E: drive and it worked perfectly every time. Both my C and E drives are Intel 300GB SSDs.

About 5 months ago I ran all of these exports hundreds of times for terabytes of data without seeing any issues like this. My current theory is MS Endpoint Protection or a Windows 7 update. We didn't have EndPoint 5 months ago. The C:\Geodata folder is a location that supposed to be excluded from scanning so my results are opposite of what I would have expected, but I'm not sure if the folder exclusions apply to the 'Real time protection' process. We don't have any FGDB file extensions or SQL server database file extensions in our exclusion list. I've been trying to get IT to add those but no luck so far. Next step is ESRI support.

It would be helpful if ESRI would put out a white paper or technical bulletin on the subject of virus scan exclusions. An official document would smooth the way tremendously.


-Steve