Hi,

I'm migrating a mojoPortal site that I created 2 extensions for. Unfortunately there are a few complications. I have the site now on a webhost that I use for staging and testing my projects. Therefore the mojoPortal site is deployed there to a subfolder, not to the root web folder for the site. The other issue is that my client went and entered their production data into the staging version of the site (and they want it preserved in their new site), so it is now in the database that is deployed in staging.  Furthermore, I set up the site in staging to have encrypted passwords in order to test and learn how to use this feature. This project was spread over 1 1/2 years (!) so I don't remember everything, but my guess is that I generated a new machine key and then switched over to encrypted passwords. I am assuming this because the keys in the web.config of the staging site are not the same as the keys in the original files that were downloaded from this site. Here are my questions:

1. I used the Web Deploy publish feature in Visual Studio 2010 (set up to include all files in the Web project) to deploy my project to my staging site and it worked with no complications. What I'm getting at is that I published to a subfolder for the staging site. Now I'm reading in the documentation that to move a site from 1 server to another it is recommended to simply ftp the files over, but if you make the mistake of deploying to server A in a subdirectory and want to move to server B deploying to the root folder you will have problems with links and have to fix them manually. Therefore I am wondering about using the Web Deploy publish feature to deploy my local development files I have in Visual Studio to the new server to the root folder this time. In other words I'm asking if there would be any issues with links if I publish the original development files to the root folder of the new site I am creating in a different web host? Shouldn't the publish feature work no matter what directory on the server you publish the site?

2. A related question is I know there have been changes to the site since I deployed it to staging, but shouldn't the files be the same as the ones I published to staging? Changes have been made such as adding content and changing to encrypted passwords, but shouldn't all of these changes be in the database only - except the generation of a new machine key?...(my 3rd question below relates to the encrypted passwords and new machine key). Therefore any reason I couldn't get away with just publishing the original files to the new site (in the root folder this time), which would hopefully avoid the bad links problems, and restore the database from a backup from the staging site (which would preserve all the data changes make on the staging site after deployment there)??

3. Regarding the encryption/machine key issue....I'm wondering if my passwords would still work on the new site if after I publish the old development files to the new server (to the root), I copy the machine key from the web.config in the staging site to the web.config in the new site? Since I am planning on using the database from the staging site in the new site, the new site would already be set in administration to use encrypted passwords and they would be encrypted. If I copy the staging site's machine key to the web.config of the new site, when someone tries to login, the decryption would work because the correct machine key is there and the password was encrypted with the same key on the staging site originally. Any issue here?

I have been trying to publish the original files to the new host, but the publishing feature is not working on the new host. Their support is working on it. But meanwhile I just thought I would ask you guys if you see any holes in my thinking and game plan...  

Thanks for any help,

Dan

Hi Joe,

Thanks for your answer. I followed your advise and ftped the files over from staging to production. The database was also brought over from staging. Then the site came up with no problems! No bad links or broken images. I checked the page source and and compared the source from production vs from staging.  Some of the links are document relative - so those are the same. Some were root relative and for these links: in the staging pages, the subfolder is there, but in the production pages, the staging subfolder is not there. So everything is as it should be regarding links.

So now I just want to get my security in better shape. I checked and it turned out I never pasted a new machine key in the web.config, but I did enable encryption. So now I decided to try to get a new machine key and to try this on my staging site first. So I changed the password setting to plain text. This worked fine and both my authenticated user and admin was able to login and access their areas. Then I generated the new machine key using your tool in the Security Advisor, downloaded web.config, pasted the new code in, and then ftped back and overlayed with the new one. My administrator was kicked out - as expected. Now both authenticated user and administrator can login and get around as normal, except the administrator cannot access Site Setting! Here is the error I'm getting:

We're sorry but a server error has occurred while trying to process your request.

The error has been logged and will be reviewed by our staff as soon as possible. It is possible that the error was just a momentary hiccup and you may wish to use the back button and try again or go back to the home page.

Note the passwords are still in clear text (not encrypted) and I confirmed they are this way in the DB using Management Studio. I checked the system log (in Advanced Tools) and don't see anything from these attempts.

Any ideas what might be going on? Is there another log I should check?

Thanks

Dan

Hi Jamie,

Thank you very much for your reply. It turned out it was because I had web.config set to configure my mail settings in admin and I forgot to clear them before changing the machine key. Since Joe wrote about that in the docs it was obvious once I got the stack trace.

Thanks again,

Dan