Deleted "Default Web" in IIS, uh oh
- From: admin <admin.26detf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 16 Apr 2006 13:25:43 -0500
OK,
Having just spent the last 10 hours rebuilding a clients Default
Website that was accidentally deleted. I'm wondering if anyone can
shed any light on an 'easy' way to do this? (in my case for future
knowledge, but hopefully for others it will be before the fact).
Regardless I thought I'd post while I'm still awake and remember some
of it so that others can hopefully save some time if it happens to
them, or someone can spot better ways of doing it.
The main challenge of course was rebuilding all of the exchange virtual
directories. Since there are at least half a dozen articles, posts, and
a MS KB article on that (which leaves out a step by the way, have to
reset IIS at the end) I won't go into that. What I will address is the
fact that none of those will actually work in a certain, not uncommon,
instance.
After banging my head on 'why' those steps weren't working, searching
in vain around the internet, etc. I finally figured out the following.
Those steps will work if *only* the virtual directories have been
deleted, not the entire Default website. If you have deleted the
entire Default website, and you make a new one, when you recreate it
the system properly assigns this new website with a *new* site ID.
Unfortunately (or fortunately?) , all of the Microsoft scripts dealing
with the virtual directory creation, including the virtual directory
creation of the new MobileAdmin directory from Exchange Service Pack 2,
use the Site ID apparently and not the name descriptor of the site.
So even if you've created a new 'Default Web' running the different
steps to rebuild the Exchange Virtual Directories will now work, they
will fail due to the fact that they don't 'see' the site.
In my case this rebuild was further complicated by the fact that the
client had all of GFI's mail tools installed (content security, mail
essentials, and archive) so those had to be rebuilt as well but it
turned out that was pretty simple. (for those of you using those tools
you can use the Security products 'Switchboard' to create the virtual
directory, and the other two products, archive and mail essentials,
simply have virtual directories pointing to file directories underneath
the "program files" area of the respective product. I'd name them but
the directory names seem to have changed per version. You'll see them
though at wwwroot, aspnet, etc.)
The only way I knew of to trick the system into recognizing the new
website I had created as the 'true' Default website was to take the
scary step of editing the Metabase. Then modifying the site ID values
for the W3svc sites. As nerve racking as that was, it didn't fully
work. Why? I really can't totally say. The website application ID's
themselves seem to make reference to the site they belong to through a
different key...which I didn't replicate. So more misery.
In the end it was a combination of these metabase edits, virtual
directory recreation, etc. that only got me 'most' of the way there. I
ended us using one of my other clients IIS setup to export the directory
configurations....then importing them into the broken clients new
website...then after the import editing the portions of the imported
configuration that referred to the other clients 'client specific'
directory names. I believe I also had to change a authentication
setting on one but after 51 hours awake it's getting a bit hazy. All
is working now but I'd be lying if I said that I was totally confident
that some future update won't fail because of some wierd metabase
matching issue now.
So, can someone please tell me there is some 'simple' way to recreate
the true 'Default Web' (site ID and all)? As we aren't talking about
general 'data' here restoring from backups, etc. isn't as simple as it
sounds. They were in the middle of completing the Exchange Service
Pack 2 update when this occurred as well so knowing specific stages of
the System State was shaky at best.
This is a critical issue for everyone running Exchange, but for those
of us on SBS it's much, much, more so, given our dependency upon the
services delivered via IIS.
Hope there is a simple answer to this, or if not, that someone saves
some time. At a minimum, I would highly recommend adding a script to
your sites (as I have now done) that regularly exports each site
configuration and each individual virtual directory configuration to
their xml backup files so that those are being backed up on your backup
schedules.
p.s. - some things that I remember doing in this process
Re-ran Exchange SP2 (multiple times) to see if it would recreate the
directories.
Ran Exchange 'Reinstall'
Ran CEICW
Basically anything that I could think of that wouldn't totally hose the
existing SBS installation I did.
p.s.s. - the reason this occurred in the first place was that during
the Exchange SP2 install they said that when they ran the 'MobileAdmin'
install that it created a *new* 'Default Web' site instead of using the
existing one. They were smart enough to find a reference to this on
the web (MS KB I believe or technet) and were in the process of
deleting the unneeded 'Default Web' that had been built.....when they
realized they had just deleted the wrong one. Thus the phonecall to
me in the middle of the night.
Cheers,
Matt Ridings
MSR Consulting
--
admin
.
- Follow-Ups:
- Re: Deleted "Default Web" in IIS, uh oh
- From: Mariette Knap [SBS MVP]
- Re: Deleted "Default Web" in IIS, uh oh
- Prev by Date: Re: System drive restore procedures
- Next by Date: Re: Ctrl+Alt+Del Shutdown option on Win logon...
- Previous by thread: Backing up windows 2003 SBS server
- Next by thread: Re: Deleted "Default Web" in IIS, uh oh
- Index(es):
Relevant Pages
|
