views:

159

answers:

3

We have a long-lived ASP.NET 3.5 application we are moving from a physical server running Windows 2005+IIS 6 to a virtual one running Windows 2008+IIS7. The new machine will assume the identify of the old one - IP's, DNS, etc.

Our clients keep our site up for hours - sometimes even days. My fear is that when we make this switch-over, suddenly all thier viewstates will fail to validate because the MachineKey will have changed.

Is this kind of disruption avoidable? Can I 'set' the new server's machineKey to be the same as the one in use now? I think it is autogenerated - can I find out what it is?

Or, is this even worth it - is this a suck-it-up situation where users shouldn't expect to be able to hit a website for that long?

+3  A: 
<system.web>
    <machineKey validationKey="Generate on your own" decryptionKey="Generate on your own" validation="3DES"/>
</system.web>

You are correct, moving will invalidate all Authorization Cookies. I believe, unless you have viewstate encryption turned on, viewstate will be fine.

If you add the machinekey attribute, then it doesn't matter where the site is hosted, as long as that machine key is the same, encryption and decryption will be fine. Additionally, you will need to/should use this if your site is hosted in a load balanced environment.

msdn.microsoft.com/en-us/library/ms998288.aspx

andrewWinn
+2  A: 

Typically a migration like this would be a full outage. Most sites announce this, and put up a temporary outage page during the cutover. Also, I imagine that there will be a time when neither machine is available, so regardless of the machine key and viewstate, requests will fail. I would recommend that you force a full outage. This would also allow you to test the new server before it goes live.

Alternatively, you could give the new machine new IP's, and slowly force new traffic to the new one, while existing connections would remain on the old one. This would require some kind of device (router, content switch, etc) to manage this. Not sure if your server is behind a device like that.

But back to you question, yes, you can manually set the machine key. This is in the machine.config. Take this section from your old machine and copy it over:

<machineKey  
validationKey="..."           
decryptionKey="..."
...
/>

It is usually located here: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config

Here is an article about using the same machine Key.

Mike Ohlsen
Thanks for this - it ocurred to me that setting the key NOW would simply MAKE the problem I'm worried about happen sooner. That is, the migration would go fine but requests on the existing server would fail.
n8wrl
+2  A: 

You can explictly set the machineKey, in fact, this is done quite commonly when you're using different session state models with web farms. Here's a link on how to do it (near the bottom of the article).

Unfortunately if you haven't manually generated your current machineKey already, then it will be randomly generated every time the application domain restarts (which means you're vulnerable to validation problems right now if your server ever hiccuped).

However, you can discover the current machineKey that is in use by looking in the registry at

HKU\SID\Software\Microsoft\ASP.NET\2.0.50727.0

(if you're using IIS6). If you're careful, you may be able to set up the new box with the same key, migrate over, and having nothing go wrong. But those are famous last words ;)

womp