Projects opening extremely slowly after network drive removed

HollyTorpey_LSA

Hi all, I'm hoping someone here has dealt with this issue and can provide some guidance.

We recently migrated from one cloud data storage solution to another. We have kept the same file structure, but it's not on different servers mapped to the save drive letters as before. However, in an effort to improve performance in the past, we had used UNC paths for folder connections in the project template we all use for starting new projects. Thanks to that unfortunate choice, now every project that was created prior to our recent server migration has broken links. And for some reason, those projects are taking up to two hours to open. They sit on "Opening Project" for eons.

They all open eventually (with broken links, as expected), but even after fixing the data sources for all folder connections, geodatabases, styles, and toolboxes, and checking all links in the Options dialog to make sure that all paths are valid, the projects continue to open very slowly each time we open them. It's as if there are still invalid paths in there somewhere and Pro is scanning our entire network looking for them before opening. Once they're open, performance is normal.

Other users have reported similar issues, but I'm not seeing any resolution:
https://community.esri.com/t5/arcgis-pro-questions/local-server-taken-offline-issue-with-pro-project...
https://community.esri.com/t5/arcgis-pro-ideas/there-should-be-an-option-for-setting-maximal/idc-p/1...

New projects created after the migration using a new project template with only mapped drives open normally. The problem only occurs with projects created prior to the migration.

Saving these older projects under a new name or in a new location (even locally) does not make any difference. We are only experiencing this problem with Pro; none of our other applications are struggling.

Has anyone else overcome this issue? We have hundreds of projects, most with multiple layouts within them, so we really don't want to have to recreate them from scratch. I feel like there must still be an invalid path hiding somewhere within the project, but I can't find it. I've even tried unzipping the .aprx files and searching their contents for the old server name, but to no avail.

Any suggestions are welcome. I've been on hours of calls with support and so far they have been unable to resolve the problem. Thanks in advance!

- Holly

HollyTorpey_LSA

Update:

TLDR - Pro is still looking for the template project's annoying default GDB even though it was removed from the project. The fix is to create a project package, unpack it, and use it to overwrite the original project.

Long version - If you've ever used a project template, you know that projects created from the template include their own default GDB plus the default GDB from the project used to create the template (an annoying behavior to many). In our template, that .gdb is named junk.gdb, and users are encouraged to remove it from new projects started from our standard template.

Well, our template project and its default GDB were located on a network server that was recently retired. All the files on that server were migrated to a new server, including the template, the template project, and the template project's default GDB (junk.gdb). Unfortunately, we had deliberately inlcuded UNC paths in our template in an effort to stop Pro from duplicating data. That meant that old projects created from the template would now have broken links even though the new server was mapped to the same drive letter as the original server. We expected this to be a pain in the neck but we did not expect it to take two hours to open these projects after the migration, even after repairing broken links for all visible data sources.

To figure out what was slowing down the opening process, we used ProcMon to monitor all the activity as the project opens. We discovered that every two minutes, Pro was making a call to the junk.gdb file on the removed fileshare, even though junk.gdb had been removed from the project. This was repeated about 20 times and then the project finally gave up and opened. However, since junk.gdb had been removed from the project, it was not possible for me to fix its missing data source. The good news is, we discovered that if we create a project package from the slow-opening project, declining to save toolboxes and history, and then unpack that package, the project opens immediately and is good as new. We can then overwrite the original project file with the new one and move on with our lives. The bad news is that this is a time-consuming process and we have hundreds of slow-opening projects now.

So that's the issue and I hope Esri will look into why Pro continues to call the default GDB from the template project used to create them even after the GDB has been removed from the project. This needs to be fixed because the issue is baffling and the workaround is time-consuming.

For anyone in the same boat, here are the steps I wrote up for our Pro users to fix their slow-opening projects:

First, make sure you have selected “Ask where to save before unpacking” in the Unpacking section of the Share and Download settings in the Pro Options dialog.
In File Explorer, create a new “Package” folder within the project folder.
Open the slow-opening project in Pro. Hopefully you'll only have to do this once per project.
In the Share ribbon, click “Project” to create a project package. Select the option to save the package to a file and uncheck the options to include toolboxes and history items. In the Name field, choose the Package folder you created in step 2.
Click Analyze. Pro will identify any remaining broken links/missing data sources, so re-path or remove any remaining items with missing data sources.
When you no longer have any errors (red circle with white x), click the Package button to create the project package in the Package folder.
In File Explorer, double click the project package .ppkx file to unpack it, and unpack it to your new Package folder. The new project should unpack and open quickly.
In the new project, change the default folder location to the original project’s default folder. This is important because if you leave the Package folder as the default, it will keep recreating it after you delete it every time you open the project.
Remove the Package folder from your list of Folder Connections.
Do the same steps for the default project toolbox (make the original project toolbox--or some other toolbox--the default and remove the new one that was created for this project).
In File Explorer, add "_archive" to the name of the original project's .aprx file.
In Pro, save the new project to the old project location with the original name (select the old project file and remove the "_archive" from the name before hitting save).
Delete the Package folder (if this makes you nervous, you can rename it first and try reopening your project as a test... if the project isn't looking for the Package folder, it's safe to delete it).

Hopefully this helps someone so they don't have to spend weeks wracking their brains, waiting hours for projects to open, and going back and forth with Support to fix this issue.

- Holly

View solution in original post

RhettZufelt

Suspect you have already checked this, but just in case. Once the project eventually opens, have you opened a Catalog View, selected data sources and then looked at both the Item and workspace toggles?

You may see a path/URL on the list that stands out as an offender.

R_

HollyTorpey_LSA

Sorry I missed this on Tuesday! Yes, this is my go-to method for finding and fixing broken links in bulk. It's great advice! Sadly, even after I fix all the broken links that show up in the catalog view, the projects continue to open slowly.

- Holly

HollyTorpey_LSA

A couple of new possible clues:

Publishing to ArcGIS Online from one of these slow-opening projects is also very slow. Like up to two hours for a dataset with a couple of polygons. We've confirmed that our staging locations are local.
Older projects that were not created using our standard project template are unaffected even if they contain broken links. They do what we thought all the projects would do: open in the normal amount of time with a bunch of broken links that we can then fix.

So my current suspicion is that it has something to do with the project template file that was used to create the projects. That file and its project components were housed on the drive that was removed. I'm trying to figure out of these projects are still pointing to that location somewhere under the hood. I can't find any more paths to fix, but they are clearly still hung up on something.

- Holly

HollyTorpey_LSA

Update:

TLDR - Pro is still looking for the template project's annoying default GDB even though it was removed from the project. The fix is to create a project package, unpack it, and use it to overwrite the original project.

Long version - If you've ever used a project template, you know that projects created from the template include their own default GDB plus the default GDB from the project used to create the template (an annoying behavior to many). In our template, that .gdb is named junk.gdb, and users are encouraged to remove it from new projects started from our standard template.

Well, our template project and its default GDB were located on a network server that was recently retired. All the files on that server were migrated to a new server, including the template, the template project, and the template project's default GDB (junk.gdb). Unfortunately, we had deliberately inlcuded UNC paths in our template in an effort to stop Pro from duplicating data. That meant that old projects created from the template would now have broken links even though the new server was mapped to the same drive letter as the original server. We expected this to be a pain in the neck but we did not expect it to take two hours to open these projects after the migration, even after repairing broken links for all visible data sources.

To figure out what was slowing down the opening process, we used ProcMon to monitor all the activity as the project opens. We discovered that every two minutes, Pro was making a call to the junk.gdb file on the removed fileshare, even though junk.gdb had been removed from the project. This was repeated about 20 times and then the project finally gave up and opened. However, since junk.gdb had been removed from the project, it was not possible for me to fix its missing data source. The good news is, we discovered that if we create a project package from the slow-opening project, declining to save toolboxes and history, and then unpack that package, the project opens immediately and is good as new. We can then overwrite the original project file with the new one and move on with our lives. The bad news is that this is a time-consuming process and we have hundreds of slow-opening projects now.

So that's the issue and I hope Esri will look into why Pro continues to call the default GDB from the template project used to create them even after the GDB has been removed from the project. This needs to be fixed because the issue is baffling and the workaround is time-consuming.

For anyone in the same boat, here are the steps I wrote up for our Pro users to fix their slow-opening projects:

First, make sure you have selected “Ask where to save before unpacking” in the Unpacking section of the Share and Download settings in the Pro Options dialog.
In File Explorer, create a new “Package” folder within the project folder.
Open the slow-opening project in Pro. Hopefully you'll only have to do this once per project.
In the Share ribbon, click “Project” to create a project package. Select the option to save the package to a file and uncheck the options to include toolboxes and history items. In the Name field, choose the Package folder you created in step 2.
Click Analyze. Pro will identify any remaining broken links/missing data sources, so re-path or remove any remaining items with missing data sources.
When you no longer have any errors (red circle with white x), click the Package button to create the project package in the Package folder.
In File Explorer, double click the project package .ppkx file to unpack it, and unpack it to your new Package folder. The new project should unpack and open quickly.
In the new project, change the default folder location to the original project’s default folder. This is important because if you leave the Package folder as the default, it will keep recreating it after you delete it every time you open the project.
Remove the Package folder from your list of Folder Connections.
Do the same steps for the default project toolbox (make the original project toolbox--or some other toolbox--the default and remove the new one that was created for this project).
In File Explorer, add "_archive" to the name of the original project's .aprx file.
In Pro, save the new project to the old project location with the original name (select the old project file and remove the "_archive" from the name before hitting save).
Delete the Package folder (if this makes you nervous, you can rename it first and try reopening your project as a test... if the project isn't looking for the Package folder, it's safe to delete it).

Hopefully this helps someone so they don't have to spend weeks wracking their brains, waiting hours for projects to open, and going back and forth with Support to fix this issue.

- Holly

DHighness

We ran into this problem this week after trashing an old Azure Files drive. It turned out that we had logo images in our layouts that were pathed to the old Azure Files drive and after that drive went away the APRX Projects would take forever to load. If you are listening Esri, it seems like that shouldn't be a problem, just put a big red exclamation mark where the image is normally located or something like that and don't have it hang while loading the document. The APRX would eventually load after several hours.

I tried using the map package fix but that didn't do anything to the inserted image paths, they remained in the packaged APRX and the packaged project still wouldn't load.

My second attempt was to save the layouts to layout files (PAGX). I did this from a Catalog view. These are just JSON text files so I was then able to open them in Notepad++ search for and fix the old paths and save. Then I created a new Pro Project (APRX) and imported the layout files into the project. That project was now good to go!

After considering this fix I thought about what I learned at the Dev Summit a couple years ago, the APRX file is just a zipped up bunch of text files. So, I renamed a copy of the broken APRX file to ZIP and unzipped it into a folder. Using Notepad++ again I searched for all occurrences of the bad path in the folder files. I fixed the paths in all the found locations, saved the files and then rezipped the files in the folder. Then I renamed the new zip file with a APRX suffix. Now the fixed original Pro Doc (APRX) opens like normal. This is obviously the Pro fix!

Hope this help someone!