tenants.json disappearing in Azure app_data

[thatplatypus]

Hello,

Hoping we can get some community advice/insights for a weird situation we've been noticing.

My team has been running Orchard Core (v 1.5, hoping to upgrade everything to .net 8 and deps this summer) through a fairly normal environment setup in an azure (hosted dev, test, and prod) app service. We've observed 3 times (once a few months ago, and twice this week, Monday and Tuesday) where the App_Data is being inexplicably sort of reset such that tenants.json gets deleted and each tenant's individual appsettings.json is deleted too. So basically we log in in the morning and our normal tenants all 404 trying to access them, and the default tenant thinks we should reset up the site. I've been (mostly) been able to fix this by copying in a back I had of the app_data's tenants.json and putting back each tenant's appsettings.json.

We fortunately haven't seen this in our prod environment yet, but we are getting pretty worried and are exploring alternatives. So the first part to the question, has anyone encountered something like this before with Azure? If so, what was the resolution/issue? We haven't noticed any weird logs or errors that would indicate something triggering this on the app service, or from the app itself.

As far as potentially not using app_data for orchard core, is https://docs.orchardcore.net/en/main/reference/core/Shells/ still the right way to go about this? Offloading the configuration to an azure provider instead so it isn't directly in the app_data? The docs would indicate this should work and even let us safely migrate the tenants.json and all the other appsettings.json with it?

Thank you
Tom

[Piedone]

Do you sometimes do clean deployments by chance? I.e. a deployment that wipes everything on the server. WebDeploy can do this too. Because otherwise, OC doesn't delete the App_Data folder.

Yes, I'd recommend putting shell settings in the DB. When in a production app, I really don't see any reason not to do that.

[thatplatypus]

Hi Piedone,

Thank you for the response. I tried digging into that more and couldn't really find any indication that might have happened. The only thing that ended up sticking out was a landing zone policy trying to apply some log analytics diagnostic settings, so my leading theory is that could have triggered something, but we don't have follow up deployment logs after that action so haven't been able to completely confirm that. It's good to know OC wouldn't have touched it though so likely still something weird on on Azure side.

And that sounds good regarding the settings. we're going to do that, and just proceed with migrating it into a db as suggested.

Much appreciated,
Tom

[Piedone]

Great then!