Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have an IF site that will be undergoing a fairly large deployment. There will be a few hours of downtime, and I want to put a maintenance page at the front of the site, and prevent any traffic from other pages (bookmarks to site pages).

What is the supported SharePoint way to do this?

Edit: A provided solution could be at the farm or web application level

Edit2: The provided solution should also allow me to be continuing deployment behind the scenes (creating pages, adding user controls, etc)

Edit3: I see a standard asp.net approach is to add a file named 'app_offline.htm' to the root directory of the web app (VirtualDirectories{app}\app_offline.htm). All web requests are redirected here.

share|improve this question
    
Another option we've used before: I can append a user control to the master page that checks your browser for a cookie. If that cookie exists, then you can continue browsing like normal. If it doesn't exist, you'll be redirected to a custom aspx page that will be in the layouts directory for you to enter a password. This will allow me to put up a 'maintenance' page up for users, but allow me to continue deploying & testing the site without taking the contentdb offline, copying/backup & restore, etc. I can also deploy this as a feature to easily turn on/off –  Tim Gabrhel May 17 '11 at 18:18
add comment

3 Answers

up vote 2 down vote accepted

There isn't out of the box functionality to do this. The only way to prevent bookmarks to individual site pages would be either a full DNS redirection or manipulation of the site in IIS. The former wouldn't allow you to continue to use the server, and the latter is not recommended from a best practices model.

The best solution in my mind would be to do all of your development in your staging environment. First, copy the production content DB to staging, mark production as read only. Users are still using production, but the content can't be changed (sort of a hybrid downtime). Install any WSPs on the production farm, detach the old content DB, then simply copy the staging database to production and attach it to the farm. In that scenario, downtime shouldn't be more than a few minutes (just long enough to detach the old content DB and attach the new one). As long as all of your features are installed before you bring the DB over.

As far as your solutions go, they're not going to show broken functionality, because they won't take affect until they're activated. The last step of the process would be to kick off some PowerShell to activate all of the necessary features (though in some scenarios they'll be active in the new DB that you bring over so you may not have to do that).

share|improve this answer
    
Thanks. This seems to be the best alternative to the problem. –  Tim Gabrhel May 17 '11 at 16:45
add comment

If you put the SQL databases in read mode during the maintanence, users will get prompted about it automatically as I recall.

share|improve this answer
    
Read only mode wouldn't be sufficient, because I still need to be making updates behind the scenes. And deploying my feature, user controls would have broken functionality by linking to pages that don't yet exist that will have user controls that were just deployed. –  Tim Gabrhel May 17 '11 at 15:36
    
Ah gotcha, missed Edit 2. –  PirateEric May 17 '11 at 15:44
    
Thanks for the reply. This ended up being a partial answer to the accepted answer. I'd upvote but don't have enough rep. –  Tim Gabrhel May 17 '11 at 16:46
add comment

There isn't really a SharePoint mechanism to do this. You will need to do something outside the scope of SharePoint. This will involve some kind of DNS manipulation, perhaps at the hardware load balancer level with a simple web server that will respond with the maintenance page. Or add an IIS site and temporarily reconfigure its host header after moving the external URLs in SharePoint (Central Administration - alternate access mapping configuration).

One solution to the whole deployment problem, if budget permits, is to have two farms. One is live and the other is used to set up the next release and test it. To go live you just switch the DNS, so you don't need a maintenance page at all. You do need to keep the content in synch. and stop content updates happening during the changeover period though.

share|improve this answer
    
We do something similar to this by setting up a site with a maintenance page on another web server that is not the CA, then we deploy while all traffic is routed to the Maintenance Site. Only done this a few times but its worked well. –  MichaelF May 17 '11 at 16:26
    
@SPDocotor - Thanks for the reply. I'd upvote, but I don't have enough rep. –  Tim Gabrhel May 17 '11 at 16:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.