Joel's SharePoint Architect Blog

This happened to me on a client site. In slow motion. One of those “noooooooo……!” moments. “Not *that* one!!!!!”

“Stop and start the W3SVC.” That’s what I meant. I’m sure that’s what I said. But my colleague stopped and started the Windows SharePoint Services Web Application service instead.

Popular Misconception #1: I can stop and start the Windows SharePoint Services Web Application without any severe implications.

If you backup your IIS metabase, then yes. You *do* do that, don’t you? No? Damn. We’ve got some work to do then. Here’s what happens.

This is IIS before stopping the WAS. Note a healthy sufficiency of IIS Sites to host my manifold Web Applications:

So, let’s try this out. I’m going to navigate to Central Administration –> Operations –> Services On Server. Now I’ll find the Web Application Service and click “Stop”.

Note how it asks me to confirm that is what I want it to do:

So, I hit “OK” and sit back and await the carnage. Here’s what’s left in IIS when the service stops.

Which brings me to other misconceptions:

Popular Misconception #2: The Windows SharePoint Services Web Application is just a normal service, I can surely just hit “Start” and everything will be back to normal?

and

Popular Misconception #3: SharePoint memorises all my web.config changes when it backs up and timestamps them…?

Alas, no. SharePoint can only restore things that it configured in the first place. So when you edit settings in Central Administration, and configure Authentication Providers, yes. It can restore those. But for other things. like custom web.config edits, custom permissions, or virtual directories, you have to create those yourself.

Popular Misconception #4: So, the Web Application Service is a complete liability then?

No. Not at all.

The Web Application Service has a purpose. This is to allow all your front-end web servers to maintain the same collection of IIS Sites to host their SharePoint Web Applications extended into their corresponding Zones. When a new Web Application is created, or one is extended on one of your Web Front End servers, the Web Application Service running on all the others in the farm make sure the IIS Sites are mirrored across the whole farm.

It’s just not designed to take your customisations with them. (So try really hard not to make any!)

So, given this is so significant, why doesn’t SharePoint warn your more insistently?

Here’s a more suitably worded dialog you get when doing something similar in IIS – this time I’m restoring the IIS Metabase over the top of any existing IIS Sites:

Something along those lines would help enormously.

So, as an alternative to having to figure out yourself what to recreate, I highly recommend backing up not just the whole metabase, but individual IIS Sites. This can be done painlessly through IIS Manager, by right-clicking a Site and choosing All Tasks –> Save Configuration to a File…

Popular Misconception #5: I get the picture – I should never touch the Web Application Service then?

When you install SharePoint on a server as a Complete Install, it won’t start this service by default. You’ll have to decide to do that. You don’t need it for SSPs and Central Administration sites. And sometimes you want to change the role of one of your servers. Or sometimes you want to consolidate your usage of Application Pools among your Web Applications. So
then you may want to stop the service… but tread carefully.

Lastly, check the IIS Metabase Backup and Restore history before you write it all off. If you’re very, very lucky you could have an Automatic Backup just before you hit the switch. :)

There is a moral to this story: back up your stuff. All of it. Always.

Thanks for reading!

Technorati Tags: IIS, Metabase, SharePoint, SharePoint Administration, Web Application Service