Re: Temporarily Make Web Site Completely Inaccessible
From: MWells (outbound__at_sygnal.com)
Date: 01/22/05
- Next message: MWells: "Re: URL checking"
- Previous message: Sankar: "Re: Fatal Execution Engine Error (0 x 7924b50b)"
- In reply to: Juan T. Llibre: "Re: Temporarily Make Web Site Completely Inaccessible"
- Next in thread: Jeremy S.: "Re: Temporarily Make Web Site Completely Inaccessible"
- Reply: Jeremy S.: "Re: Temporarily Make Web Site Completely Inaccessible"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 22 Jan 2005 18:56:07 +1300
My current deployment process works something like this;
1. Make a copy of production for historical purposes; zip it up, store it
in archives
2. Move the contents of production into an emergency restore directory
(uncompressed)
3. Deploy the appropriate files from TEST to PROD (i.e. no .CS files, no
_temp dirs, etc).
4. Overlay PROD-specific files, such as a Web.config that has PROD database
settings and so on
For the same reasons as you, I've been considering a temporary "Web site is
being updated." page, but because the dir is temporarily empty, I'm not fond
of the temporary page idea or Web.config adjustments.
The direction I'm headed is to programmatically modify the website
configuration in IIS to point to a different directory--one that contains a
mini placeholder website, all pure HTML.
My deployments are done using an in-house tool, so the idea would be to
select the project, deploy to TEST, test it thoroughly, deploy to PROD,
which automatically takes PROD "offline". Once I've verified PROD, I click
the Online button to make access available again.
I haven't gone far down that route, or verified that I can make these
changes to IIS from another machine on the same network, but my initial
research was promising regarding Server2003 so you might consider the same
approach.
The second approach I'm considering is to manage production sites using
versioned directories, e.g.;
c:\inetpub\wwwroot\websitedir\1.0.0.38
c:\inetpub\wwwroot\websitedir\1.0.1.21
With a tool (or some tightly managed procedures), you can extract the
assembly version during deployment and make that its directory name. Then
once you've verified the site is working, "click" you programmatically
update IIS to point the site at the new version directory.
The advantage is that the current site is running until the moment you click
"approved", so there's virtually no downtime; however this clearly presents
issues if you've modified a shared resource, such as a database schema. In
that case PROD(current) would break the moment you make the schema change,
and PROD(new) won't work until you make the schema change.
The placeholder site seems to be the best lowest-common-denominator
solution.
Have fun, and please keep me posted on the direction you take.
/// M
"Juan T. Llibre" <nomailreplies@nowhere.com> wrote in message
news:epVWfYBAFHA.3236@TK2MSFTNGP15.phx.gbl...
> I don't know if there's a penalty but perhaps,
> a simple solution -if you use Forms Authentication-
> is to rename login.aspx to login.aspx.bak, and setup
> a customerrors page which explains that the site will
> be back shortly.
>
> When you're done, rename login.aspx.bak back to
> login.aspx, and restore your usual customerrors page.
>
> If it's an open site ( no authentication ), you could simply
> write an httpHandler which redirects all users to another
> Application where you explain what's going on.
>
> You could also do that if you use
> Forms or Windows authetication.
>
>
>
> Juan T. Llibre
> ASP.NET MVP
> ===========
> "Jeremy S." <A@B.COM> wrote in message
> news:uFBd8NBAFHA.1524@TK2MSFTNGP09.phx.gbl...
> > Sounds good. Is there any meaningful/noticeable performance penalty for
> > having this HttpModule?
> >
> > "Jens Hofmann" <spam@dev-com.de> wrote in message
> > news:uEwYUPAAFHA.3528@tk2msftngp13.phx.gbl...
> >> Have a look at HttpModule. You can develope one which
> >> checks a DateRange defined in Web.Config and a URL
> >> defined in Web.Config and if a request comes in between
> >> the DateRange you redirect the request to the defined page.
> >>
> >> This is normal Maintenance-Mechanism.
> >>
> >> Cu Jens
> >>
> >> "Jeremy S." <A@B.COM> schrieb im Newsbeitrag
> >> news:OWcMgEAAFHA.936@TK2MSFTNGP12.phx.gbl...
> >>> Sorry if this is too far OT - I posted this in the IIS group and got
no
> >>> response - so here goes:
> >>> What would be a good or recommended way to make a Web site in IIS6
> >>> inaccessible to users on the Internet. My situation is that I will
> >>> periodically update a ASP.NET Web application. While I am making the
> >>> update (which will take only a couple of minutes, max) and
subsequently
> >>> checking that everything works as planned after the update (which may
> >>> take 5-20 minutes), I don't want any visitors to access *any* pages in
> >>> the site. Rather, they should get some page that tells them what to
> >>> expect (e.g., "please try again later" or whatever).
> >>>
> >>> Thanks!
> >>>
> >>>
> >>
> >>
> >
> >
>
>
- Next message: MWells: "Re: URL checking"
- Previous message: Sankar: "Re: Fatal Execution Engine Error (0 x 7924b50b)"
- In reply to: Juan T. Llibre: "Re: Temporarily Make Web Site Completely Inaccessible"
- Next in thread: Jeremy S.: "Re: Temporarily Make Web Site Completely Inaccessible"
- Reply: Jeremy S.: "Re: Temporarily Make Web Site Completely Inaccessible"
- Messages sorted by: [ date ] [ thread ]