I did the dumbest thing ever this morning by trying a direct upgrade of my Umbraco Installation on my production site. I did this many times before, always without incident.
It's the website of our uni research group and I'm doing this "on the side" so I'm always short on time with no resources to maintain testing servers etc...
Anyway here it goes:
the previous version was 4.0.4.2.
I made a backup of the folder containing my installation
I added the correct db connection string to the config file of 4.5.2 for 3.5 that I downloaded from codeplex
I copied the contents of the 4.5.2 build folder onto my folder at the webserver
I navigated to my website
As expected, the installer ran
The installer crashed when trying to update the db giving me an "Line 1: Incorrect syntax near '('." error.
Stupidly I closed the window containing the rest of the error info.
I restarted the installer and this time it told me "Your db is up to date, version 4_1"
The installer finishes
Upon navigating my website, the main page loads but the template is completely empty, i.e. there is no content.
Logging into my admin account is impossible, it refuses to accept my credentials
When I clear my folder and put my backup in place, the website starts working again (there is content) and I can magically login to Umbraco again
All this makes me think that somehow the upgrade process of the db went horribly wrong. 4.5.2 installer thinks it is up to date during install while in fact it is not and that this is why 4.5.2 cannot serve my pages.
Could this be? If so, how can I rectify this (basically force the db upgrade to run again).
You are allowed to give me a hard time for making these mistakes as long as you also provide some useful tips ;)
In your Web.config, find the "<membership>" section and check what the "passwordFormat" is for the "UsersMembershipProvider" provider. This might be different than your previous version. Try changing it to "Clear", then try logging into the back-office again.
Open your /config/umbracoSettings.config file. Take a look at the "UseLegacyXmlSchema" value - is it true or false? Try setting it to "true".
If you can get into your Umbraco back-office - then republish all your content nodes (not just a "republish all", but right-click on the first node and Publish + publish child nodes).
Ah yes, I looked at the settings for the password in web.config and remember them being set to "hashed" while they are all clear text in the db (I checked).
I'll try changing the setting in the morning and let you know.
In any case, it seems like a lot of the default settings changed in the transition to 4.5.x. Is there a good overview of changes? Maybe this issue is something that should be added to the upgrade manual (because if I remember well it only mentions the legacy xml schema issue).
Just to let you know I managed to find a terminal server that I could use to access my work network drives and make the changes you suggested and it all runs smoothly now.
Tomorrow I'll have a go at upgrading my xslt files to the new schema!
One other thing, yesterday, when I was trying to find the reason for not being able to login to the backend I looked at the db tables for the first time (there never was any real need) and to my surprise I found the passwords to be stored in plain text in there... The users of our site are all co-workers and you can bet your sweet behind that many of them will have used their "main" password for logging in, the one that also gives access to their private accounts and such.
I have some problems with that from an ethical point of view so I would like to prevent something like this in the future because now I have to go out and tell everybody to change their pwds etc...
Are there standardized ways to switch to hashed storage of this data? Or does this mean I would have to invest in the db management tool that Umbraco sells?
I agree, it's not ideal to store plain-text passwords in the database ... I'm not justifying the reason behind the Core team's original decision to do that - I believe the thinking was - if the wrong person has access to your database tables, then you've got bigger problems! or so it goes.
For a workaround, I'd suggest the following...
Log in to the back-office as the primary admin user. Once logged in, change the "passwordFormat" over to "Hashed" - this will re-start the web-app, but you should still be logged into the back-office. Next change all the user's passwords, to something 'default'. This will store them in the database as hashed/encrypted.
After that, ask everyone to log-in and change their passwords to whatever they like!
I bet they end up using the same passwords though! LOL! Best of luck!
Botched upgrade to 4.5.2 for .NET 3.5
Hi guys,
I did the dumbest thing ever this morning by trying a direct upgrade of my Umbraco Installation on my production site. I did this many times before, always without incident.
It's the website of our uni research group and I'm doing this "on the side" so I'm always short on time with no resources to maintain testing servers etc...
Anyway here it goes:
Hi Kris,
Few things to check...
Good luck!
Cheers, Lee.
Ah yes, I looked at the settings for the password in web.config and remember them being set to "hashed" while they are all clear text in the db (I checked).
I'll try changing the setting in the morning and let you know.
In any case, it seems like a lot of the default settings changed in the transition to 4.5.x. Is there a good overview of changes? Maybe this issue is something that should be added to the upgrade manual (because if I remember well it only mentions the legacy xml schema issue).
Just to let you know I managed to find a terminal server that I could use to access my work network drives and make the changes you suggested and it all runs smoothly now.
Tomorrow I'll have a go at upgrading my xslt files to the new schema!
Thanks!
Hi Kris, glad that you got it back up-and-running!
The only article I've seen about upgrading to v4.5 is on the wiki: http://our.umbraco.org/wiki/about/roadmap/umbraco-45/upgrading-to-umbraco-45
Cheers, Lee.
One other thing, yesterday, when I was trying to find the reason for not being able to login to the backend I looked at the db tables for the first time (there never was any real need) and to my surprise I found the passwords to be stored in plain text in there... The users of our site are all co-workers and you can bet your sweet behind that many of them will have used their "main" password for logging in, the one that also gives access to their private accounts and such.
I have some problems with that from an ethical point of view so I would like to prevent something like this in the future because now I have to go out and tell everybody to change their pwds etc...
Are there standardized ways to switch to hashed storage of this data? Or does this mean I would have to invest in the db management tool that Umbraco sells?
Cheers, K.
Hi Kris,
I agree, it's not ideal to store plain-text passwords in the database ... I'm not justifying the reason behind the Core team's original decision to do that - I believe the thinking was - if the wrong person has access to your database tables, then you've got bigger problems! or so it goes.
For a workaround, I'd suggest the following...
Log in to the back-office as the primary admin user. Once logged in, change the "passwordFormat" over to "Hashed" - this will re-start the web-app, but you should still be logged into the back-office. Next change all the user's passwords, to something 'default'. This will store them in the database as hashed/encrypted.
After that, ask everyone to log-in and change their passwords to whatever they like!
I bet they end up using the same passwords though! LOL! Best of luck!
Cheers, Lee.
Hello
I'm getting the same error while trying to upgrade from 4.0.3 to 4.5.2.
I have set the UseLegacyXmlSchema to True and the passwordFormat is set to hashed in both the old and the new web.config.
I've also run through the steps in this guide: http://our.umbraco.org/wiki/about/roadmap/umbraco-45/upgrading-to-umbraco-45
Any other suggestions where I need to check up?
Thanks. Lars.
is working on a reply...