The only problem with the app_offline.htm solution is that it does not protect you from direct links into your site (e.g. via search engines, rss feeds, etc).  If you have control over your environment... there is a way to do this via IIS that works flawlessly (though a bit quirky).  If you have a default site setup that will catch your web requests when the regular site is down... that will provide your failover to the "offline" message.  If you have localhost configured as a portal alias, then all you have to do is bring the site up so that it only answers to localhost (in our case this is via host header, your installation may be different).  Perform your upgrade locally... using localhost... then restore the original settings.  This also works for masked urls, etc (if you can't use localhost) as long as they are in the portalalias list.

It ain't pretty... but it works without the associated complication of your app being called from other places during upgrade.  If the default site is properly configured... the missing addresses (via external url) can all be fed to your default offline page.

Cheers

Scott Willhite, Co-Founder DNN

Carlos, sounds like I may be the one who has missed something... I'll give this another go. Thanks.

However, it does sound like this won't address the issue of ensuring local access to the upgrade page?  That is the case that is most challenging here due to the high level of traffic volume... there's no way to be "first" to upgrade, you have to purposefully exclude other traffic to ensure that. If you have some other thoughts, they would be appreciate.  Cheers.

Scott Willhite, Co-Founder DNN