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.

  • 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

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).

  • Thanks. This seems to be the best alternative to the problem. – Tim Gabrhel May 17 '11 at 16:45

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

  • 1
    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. – Eric Alexander 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

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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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