This project is read-only.

Orchard data deleted after azure re-deployment

Topics: Customizing Orchard, Troubleshooting, Writing modules
Nov 1, 2013 at 4:05 AM
Edited Nov 1, 2013 at 4:06 AM
I'm deploying to an azure web role cloud service. First deployment went fine, brought up the Orchard setup. I completed the setup and enabled all azure features. After later reading that the only way to deploy modules to azure cloud services is to perform a complete re-deployment (which seems a bit overkill to me) I added my custom modules to the azure package and re-deployed.

However after the deployment completed, to my surprise the Orchard setup came up after refreshing the page, and it appears that everything I had just done had been erased. It was my assumption that enabling the azure features would move the orchard settings and everything to the specified storage account.

What am I doing wrong? How can I re-deploy without losing all the data?
Nov 1, 2013 at 11:44 AM
You have to store your data in a database outside the web role, otherwise it gets wiped - not only at re-deployment but also if the Azure fabric controller should decide to reimage your role instance. Create a SQL Azure database and then when going through setup select SqlServer as your database engine and set the connection string to your SQL Azure database.

Instructions and more information here:
By default, Orchard uses a local file-based SQL Server CE database. This database won't suffice when running in a Windows Azure Cloud Service, because the Windows Azure fabric controller may decide to reimage your role instance at any time, without warning. When that happens, anything that has been written to the local hard drive in your role instance VM since it was created is lost, which means any changes made to the site since it was first deployed will be lost.
Obviously that's not acceptable, so we need to instead store the data in a shared database that will not be affected by role instance reimaging. To do this you need to create a Windows Azure SQL database that will be used to store Orchard data. You will configure Orchard to use this database later during setup.
Nov 1, 2013 at 5:37 PM
I'm sorry, I should have specified. I've already done that and are using a SQL Azure database.
Nov 1, 2013 at 5:38 PM
I've gone through the deployment setup's multiple times. Everything is working correctly, it's running off the Azure fabric, storing the media in blob, and database in a SQL Azure database. Yet, when I do a deploy from VS and I refresh the page it brings up the setup again. The data isn't necessarily wiped from the database I suppose but Orchard thinks it reset, and there isn't an option of "Use an already existing database [and data]".
Nov 1, 2013 at 5:54 PM
Edited Nov 1, 2013 at 5:56 PM
I see. Well then it sounds as though the new deployment is picking up the value State=Uninitialized from Settings.txt. This makes Orchard enter setup mode on the first request.

After you deploy the site, can you verify in your storage account that the Settings.txt (located under the "sites" container and the "Default" folder) contains the value State=Running and the correct connection string? Also that the RequestUrlHost and RequestUrlPrefix values are null.
Nov 1, 2013 at 6:12 PM
Hmm there doesn't appear to be a "sites" container or "default" folder on the storage account - the only thing I have is a "media" container on the storage account.

As a disclaimer: I did not start from the "Orchard.Azure.Web" project so I may be missing a setting? I'm coming from an existing solution and the compiled Orchard src and created my own cloud project in the solution to publish from. I tried copying over all necessary settings I saw from the Orchard.Azure.Web solution but I may have missed something that is also not listed in the walk-through?
Nov 1, 2013 at 6:15 PM
I see (again). Then you're most likely missing the necessary configuration to enable ShellSettings to be stored in blob storage.

There are instructions for enabling it here:

Start at the paragraph that begins with "It is also possible to use this feature is any other hosting environment where you have a server farm with multiple nodes but no shared file system".
Marked as answer by projectionsapp on 11/1/2013 at 2:18 PM
Nov 1, 2013 at 10:21 PM
Thanks Decorum, that did it! I was missing the web.config setting that told autofac to load from azure blog storage. Once I did that, performed a publish, it kicked in the setup again. After running through it and setting everything up (luckily I was porting over an extremely small site [SPA]) I refreshed the blob storage and low and behold there's the containers. I performed another deploy to test and after that was successful I refreshed. Everything was as I left it! Thanks so much for your help. I typically go through those guides like a hawk and go to the CP as last resort but I guess I missed it.
Nov 1, 2013 at 10:22 PM
Any time, glad I could help.