During an upgrade from ArcGIS Pro 3.3.2 to 3.5.6, we noted an odd behavior during scripted publishing workflows where our .aprx projects began indicating broken data sources and subsequently failing tasks. We investigated and it seems that some data sources were unable to resolve as UNC paths when opened remotely over a network. Testing suggests that ArcGIS Pro is not able to resolve drive paths to UNC paths when opened over the network if the relative path traverses the drive root (C:\ or D:\).
Testing Scenario 1: we created two directories in D:\, each with several nested .aprx projects and each referencing a single .gdb feature class data source saved to directory two. When opened on the hosting VM all data resolves correctly referencing a drive path. When opened remotely only projects in the second directory (that containing the data source) were able to resolve correctly and indicated a UNC path. The other projects referenced a source to D:\ and were marked as broken. For projects saved in 3.3.2, all resolve the single data source correctly.
Testing Scenario 2: in the same directory structure, we created many .gdb feature class data sources and a single .aprx project in each directory. Both projects referenced all data sources including one .gdb saved directly to D:\. Again, on the hosting VM all resolve correctly while in remote contexts data sources outside of the project's parent directory are broken. For projects saved in 3.3.2, all data sources resolve correctly.
Note that in all versions projects are unable to reference data in another drive... e.g. a project saved to C:\ referencing data saved to D:\ works only on the hosting machine.
We've tested this on virtual machines running Windows Server 2019, 2022, and 2025 with projects created in 3.3.2, 3.5.6, and 3.7.0. Projects were accessed across a WAN on a Windows 11 PC running 3.5.6 and a Windows Server 2016 VM running 3.3.2. We also tested different AD accounts and opening projects in admin mode. In all instances behavior was consistent between Pro 3.5.6 and 3.7.0 and differs from 3.3.2.
We've identified two work arounds:
1. Restructure projects and data so that they share the same parent directory under root... i.e. rather than storing projects in D:\Maps and data in D:\Data, they can be placed in D:\Projects\Maps and D:\\Projects\Data.
2. You can reference data using UNC paths to begin with... i.e. on the host VM, data sources point to "\\localhost\D\Data" rather than D:\Data. However, we have found that if the project is modified and saved on that network, when you reopen it on the host VM all data paths will revert to drive paths. Opening the project itself using a UNC path (through file explorer) seems to avoid this issue.
