I have never, ever had a DNN upgrade run without site destroying errors. My recent migration from 3.x to 4.02 is no exception. This is the one thing that concerns me about deploying dnn in an enterprise environment. I am very nervous that I will have to upgrade the system someday and it will take me a few days to migrate all of the data from the old site to the new one after I give up and just install the new version from scratch.

This is a HUGE problem for DNN. Until an upgrade can proceed smoothly there will be hesitation from people like me to deploy for anything much other than my own personal site.

My most recent upgrade went more smoothly than all the rest. The first problem was that after the database update was performed, I kept getting the page that says "nothing to install at this time" when I tried to hit the site. It turns out that I had to manually enter an install date element into the web.config file. !! BAD BAD BAD !!

Now, after getting the site to run, I can't log in. No accounts of any kind can log in.

I dug around and found this...

"To fix the login problem, copy from the <system.web> section of the original web.config file the <machineKey ...> into the new web.config"

But the old (3.x) machine key looks like this....

      <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" />

and the new (4.x) version looks like this...

    <!-- machineKey validationKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902"      decryptionKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC"
      decryption="3DES"
      validation="SHA1"/  -->

Obviously the old key is not a satisfactory replacement for the new one. and as expected. it doesn't work. I get the following error when I attempt to log in.

You must specify a non-autogenerated machine key to store passwords in the encrypted format. Either specify a different passwordFormat, or change the machineKey configuration to use a non-autogenerated decryption key.

Guys. This is ridiculous. There is no way that any self respecting IT guy could possibly approach an upgrade of DNN without fear and trepidation - nay - sheer terror.

How the *HELL* do I get this damned thing ficksed now?

I'm not sure how the original poster got those strange encryption keys, my guess is that he, or someone for him, changed some crucial lines in the web.config file. Ever since dnn 3.0 times, the machine validation en encryption looked something like this:

all dnn 3.x versions:

  <add key="MachineValidationKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902" />
  <add key="MachineDecryptionKey" value="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC" />
  <add key="MachineValidationMode" value="SHA1" />

al dnn 4.x versions:

  <machineKey
        validationKey="88274583C0B0FA57D5E12D4096F109E769E1391B"
        decryptionKey="FB33DE7F5C36906AA094F8FA486DE3E4CB7BAE5D58AC793B"
        decryption="3DES"
        validation="SHA1" />

The dnn masters membership module has nothing to do with this AFAIK.. that is a module you can use to mass import users.

---

Erik van Ballegoij, Former DNN Corp. Employee and DNN Expert

DNN Blog | Twitter: @erikvb | LinkedIn:

Sorry, i didnt understand your original post i think. When i look at this again, it seems like you mixed up 2 sections in the web.config. In AppSettings, there are  some keys (MachineValidationKey, MachineDecryptionKey, MachineValidationMode), and in the system.web section there is:    <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" />

During upgrade, you should copy the MachineValidationKey, MachineDecryptionKey, MachineValidationMode from the old web.config to the new, the line <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" /> should not be touched....

---

Erik van Ballegoij, Former DNN Corp. Employee and DNN Expert

DNN Blog | Twitter: @erikvb | LinkedIn: