Search results matching tag 'IIS Topics'

Using URL Rewrite with Web Site Testing

Anonymous — Tue, 13 Oct 2009 22:49:00 GMT

Recently I ran into an interesting situation when I was rolling out a new web-based application. I had tested it on my development server, and because it was a rather complex application I wanted to test it on my production server before making it live. I had already set up a placeholder web site with a home page that announced the new site as "Coming Soon," and I had some of the supporting infrastructure configured for the placeholder site: database connections, permissions, FTP bindings, etc.

In order to test the new site, I could have set up a temporary web site by duplicating the placeholder web site, running my tests, and then deleting the temporary site after I was comfortable that everything was working in production. Or I could simply remove the placeholder web site and replace it with the temporary web site once the testing phase was over. I didn't like either of those ideas, so I came up with much easier solution using URL Rewrite. Here are the details:

First, I added an additional host header binding to the placeholder web site with a temporary name that only I knew about. Since I use a wildcard A record for my DNS, I can add any additional prefixes to my domain name without registering those as CNAME records in DNS. (This makes the temporary name more difficult to discover.) For example, if I created an A record for "*.example.com," then I could use "temp.example.com" without any changes to DNS.

Second, I added a URL Rewrite rule that checked all inbound requests by using the following logic:

If the request was for "temp.example.com", then URL Rewrite would allow regular access the web site.
If the request was for any other domain name and any web page other than "ComingSoon.htm", then URL Rewrite would redirect those requests to "/ComingSoon.htm".

Here's what the URL Rewrite rule looked like in my web.config file:

<system.webServer>
  <rewrite>
    <rules>
      <clear />
      <rule name="Temporary Redirect"
          patternSyntax="Wildcard"
          stopProcessing="true">
        <match url="ComingSoon.htm"
          negate="true" />
        <conditions>
          <add input="{HTTP_HOST}"
            negate="true"
            pattern="temp.example.com" />
        </conditions>
        <action type="Redirect"
          url="/ComingSoon.htm"
          appendQueryString="false"
          redirectType="Found" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

This allowed me to test the web site on my production server by using a temporary domain name that no one else knew about, and sending every other HTTP request to the "Coming Soon" announcement page. After a few days of putting the web site through some test passes, all that I needed to do was to remove the URL Rewrite rule and the site was officially live.

Creating a Microsoft Access Provider for IIS Database Manager

Anonymous — Fri, 25 Sep 2009 22:22:00 GMT

Following up on my last blog post about the API set for the IIS Database Manager, I have something of a secret to let you in on - you can use the code samples in several of those API documents to create a fully functional provider for Microsoft Access databases. I would never use an Access database in a production environment, but having an Access provider has had some great benefits for me from a test perspective. I often use Access databases for test projects, and using the IIS Database Manager to manage the Access databases on my test systems means that I don't need to install Microsoft Access on any of my test servers.

That being said, as I was writing the API documentation I needed to create something of value to test my code samples. Since the Database Manager feature team was already creating database providers for SQL Server and MySQL, it seemed to me like Microsoft Access was the only other readily-accessible database that I could use for my samples. I mentioned in my last post that Saad Ladki was the Program Manager for Database Manager; Saad had started work on an Access provider at one point, but he abandoned the provider as his schedule grew tighter, so I took over that project so I could use it for the API samples.

With that in mind, here's what you need to do to create a Microsoft Access provider for the IIS Database Manager:

Create a new class project named "AccessDatabase" in Visual Studio
Add project references for:
- System.Configuration
- Microsoft.Web.Management.DatabaseManager
  Note: This may require adding a reference path for your project, such as "C:\Windows\assembly\GAC_MSIL\Microsoft.Web.Management.DatabaseManager\1.0.1.0__31bf3856ad364e35", where "C:" is your operating system drive.

Open the class in the editor, remove the existing code, and insert the following empty class:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Configuration.Provider;
using System.Data;
using System.Data.Common;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Data.OleDb;
using Microsoft.Web.Management.DatabaseManager;

namespace AccessDatabase
{
    public class AccessProvider :
        DatabaseProvider,
        IDbTableManager,
        IDbTableDataManager,
        IDbViewManager,
        IDbBackupManager,
        IDbRestoreManager
    {

    }
}

Copy the code samples from the following MSDN topics into the class; note that some of the utility methods in the code samples will be duplicated so you'll have to remove the duplicate methods:
- DatabaseProvider
- IDbTableManager
- IDbTableDataManager
- IDbViewManager
- IDbBackupManager
  - CreateBackup Method
- IDbRestoreManager
  - RestoreBackup Method
Save, compile, sign, and GAC the provider. For more information about using the Gacutil.exe tool, see the following topic on Microsoft the MSDN Web site:
Global Assembly Cache Tool (Gacutil.exe)

Follow the instructions in the Microsoft.Web.Management.DatabaseManager Namespace topic to add the following entry to your administration.config file, which will register the provider for IIS Manager:

<provider name="Access Provider"
   providerName="System.Data.OleDb"
   type="AccessDatabase.AccessProvider,AccessDatabase,Version=1.0.0.0,Culture=neutral,PublicKeyToken=426f62526f636b73" >
   <databaseBackup
      backupEnabled="true"
      restoreEnabled="true"
      backupPath="C:\backups" />
</provider>

Note: You will need to update the PublicKeyToken with the public key token from your assembly.

Add an OLEDB connection string for your Access database; the following web.config sample shows what that might look like:

<configuration>
  <connectionStrings>
    <add name="Northwind"
      providerName="System.Data.OleDb"
      connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\inetpub\wwwroot\App_Data\Northwind.mdb;" />
  </connectionStrings>
</configuration>

Note: Since the code samples were all written using OLEDB, not ODBC, you will need to make sure that you use an OLEDB connection string like my example.

Open the IIS Manager and open the Database Manager for the site where you added the connection string. You should now be able to manage the tables and views for your Access database, as well as backing up and restoring your database.

Additional Notes

Creating Database Backups

Even though I wrote my provider to implement backing up and restoring databases, this functionality is purely optional - you could easily remove the IDbBackupManager and IDbRestoreManager implementations from the class and remove the <databaseBackup> element from administration.config.

OLEDB Errors When Saving JOIN/ORDER BY Views (Queries)

Unfortunately, there is one unexpected OLEDB problem with Microsoft Access databases that I ran into that I could not work around. When you attempt to save a view (query) that contains both JOIN statements and ORDER BY statements, you will receive an error that states "Only simple SELECT queries are allowed in VIEWS."

As long as the SQL code is syntactically correct you can execute the query, but you cannot save it. If a query that contains both JOIN statements and ORDER BY statements has already been created in Microsoft Access, you can open it and make changes, but you will not be able to save those changes back to the database.

For example, the following SQL code will cause the error to occur:

SELECT Categories.CategoryName, Products.ProductName
FROM Products INNER JOIN Categories ON Products.CategoryID = Categories.CategoryID
ORDER BY Categories.CategoryName, Products.ProductName;

While the following code will not cause the error:

SELECT Categories.CategoryName, Products.ProductName
FROM Products INNER JOIN Categories ON Products.CategoryID = Categories.CategoryID;

Even though the SQL code is syntactically correct and will execute without any problems, the error occurs at the OLEDB layer when the provider executes the CREATE VIEW statement to save the view to the database. This appears to be an unfortunate and irresolvable OLEDB limitation when you are using an Access database. When you are faced with such a situation, you will need to open the database in Microsoft Access to save the query.

Database Manager API Topics on MSDN

Anonymous — Thu, 24 Sep 2009 18:16:00 GMT

Today Microsoft released version 1.0 of the IIS Database Manager, which enables you to manage local and remote SQL Server or MySQL databases through the IIS Manager. I cannot stress enough how this module has rapidly become one of my favorite extensions for IIS Manager. There are many times when I need to access the data in one of my databases where opening the database management tool would be inconvenient or impossible. (For example, when I am working remotely, or when I don't have the database management tools installed.) In these situations, the Database Manager has been worth its weight in gold.

Another great feature of the IIS Database Manager is that it is extensible, like every other part of IIS these days, meaning that you can create your own database providers. Following up on that thought, in addition to all of the walkthroughs and blog posts that I've been writing about FTP and WebDAV over the past several months, I've also been working on documenting the API set for the IIS Database Manager, and all of those topics have been published on the MSDN Web site under the following URL:

Microsoft.Web.Management.DatabaseManager Namespace

I would be remiss if I didn't give credit where it's due, so my special thanks go to:

The Database Manager Feature Team - the entire team did some great work:
- Saad, Brian, Bob, Tim, Andrew, Nitasha, Richard, Carlos, Madhur, Nazim, Ivan, Crystal, Faith, Diana, Pete, Rich, Raul
- That being said, there are two people that I'd like to call our for their additional assistance:
  - Saad Ladki - Saad was the Program Manager for the Database Manager. I have to give credit where it's due and say that my job would have been a lot harder if Saad hadn't done the initial research for some of my code samples.
  - Brian Delahunty - Brian was my principal contact on the feature team whenever I needed help or backed myself into a corner. Brian was very accommodating when I suggested changes, and he always had great explanations when something needed clarification.
Microsoft Press - I know that it seems like a gratuitous plug, but I spent dozens of hours going through my "Microsoft® OLE DB 2.0 Programmer's Reference and Data Access SDK" book looking up the various parts of the OLEDB schema. That book was simply indispensable while I was writing my API samples.

eWeek Reviews for IIS 7.5 and FTP 7.5

Anonymous — Wed, 23 Sep 2009 22:45:00 GMT

One of my coworkers, Vijay Sen, just forwarded the following eWeek review of IIS 7.5 to me:

http://www.eweek.com/c/a/Windows/REVIEW-Microsoft-IIS-75-Improves-Management-Deployment-Options-822018/

The review was written by Jim Rapoza, and he said some great things about IIS 7.5, which ships with both Windows Server 2008 R2 and Windows 7 client. But what really made my day was the following things that he said about FTP 7.5:

Another welcome change in IIS 7.5 is the elevation of FTP as a full-fledged part of the server. In previous versions, setup and management of an FTP server in IIS were done pretty much separately from Web server management. In IIS 7.5, FTP administration is fully integrated into the IIS Management Console.

I found this to be a very good implementation of FTP, making it possible to quickly set up secure FTP servers and tie them to my Websites. Especially nice was the ability to easily use virtual host names for the FTP sites. All in all, the FTP implementation in IIS 7.5 is one of the best I’ve seen, even when compared with dedicated FTP server products.

It’s great to see all of our hard work being recognized!

My thanks once again to everyone on the FTP and IIS feature teams that helped make this version of the FTP service: Jaroslav, Emily, Daniel, Umer, Suditi, Ciprian, Jeong, Dave, Andrew, Carlos, Brian, Wade, Ulad, Nazim, Reagan, Claudia, Rick, Tim, Tobin, Kern, Jenny, Nitasha, Venkat, Vijay. (I hope that I didn't leave anyone out!)

FTP 7.5 Extensibility and Visual Studio Express Editions

Anonymous — Thu, 17 Sep 2009 18:19:00 GMT

In earlier blog posts I have mentioned that I written the several walkthroughs to help developers get started writing providers for the FTP 7.5 service, all of which available on Microsoft's learn.iis.net Web site under the "Developing for FTP 7.5" section. In each of these walkthroughs I wrote the steps as if you were using Visual Studio 2008.

Following up on that, I received a great question yesterday from a customer, Paul Dowdle, who wondered if it was possible to write an extensibility provider for the FTP 7.5 service using one of the Visual Studio Express Editions. By way of coincidence, I used to install Visual C# Express Edition on my laptop when I was traveling around the world to speak at events like TechEd. I usually did this because the Express Edition took up less hard drive space than a full installation of Visual Studio, and I was only writing code in C# on my laptop.

To answer Paul's question, the short answer is - yes, you can use Visual Studio Express Editions to develop custom providers for the FTP 7.5 service, with perhaps a few small changes from my walkthroughs.

For example, if you look at my "How to Use Managed Code (C#) to Create a Simple FTP Authentication Provider" walkthrough, in the section that is titled "Step 1: Set up the Project Environment", there is an optional step 6 for adding a custom build event to register the DLL automatically in the Global Assembly Cache (GAC) on your development computer.

When I installed Microsoft Visual C# 2008 Express Edition on a new computer, I didn't have the "%VS90COMNTOOLS%" environment variable or the "vsvars32.bat" file, so I had to update the custom build event to the following:

net stop ftpsvc
"%ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /if "$(TargetPath)"
net start ftpsvc

Once I made that change, the rest of the walkthrough worked as written.

So, to reiterate my earlier statement - you can use Visual Studio Express Editions to develop custom providers for the FTP 7.5 service. My thanks to Paul for the great question!

Hiding your FTP Server Type and Preventing Unauthorized Access

Anonymous — Thu, 10 Sep 2009 20:05:00 GMT

As evidenced by my How to Use Managed Code (C#) to Create an FTP Authentication Provider with Dynamic IP Restrictions walkthrough and my other FTP authentication extensibility walkthroughs, I spend a lot of time trying to find ways to prevent unauthorized access to my FTP server while still allowing valid users to have easy access to their site content. Today's blog discusses several of the ideas that I like to use on my FTP servers.

Preventing Unauthorized Access

To start things off, I globally disable FTP Basic Authentication on my server and I only use custom authentication providers. Since my FTP users do not have actual accounts on my server or my domain, that helps prevent access to my physical server. It was for this reason that I wrote the authentication provider that I discuss in my How to Use Managed Code (C#) to Create an FTP Authentication Provider using an XML Database walkthrough; I can hand out accounts with FTP access for sites that are hosted on my servers, but those accounts are stored in an XML file and not in the security accounts database on my server or my domain.

But there are other ways to help secure your FTP server. For example, I wrote an earlier blog post about Creating a Global Listener FTP Site. On my servers I like to create a global listener site and disable all of the built-in authentication methods.

Once that has been completed I add the custom authentication provider from my How to Use Managed Code (C#) to Create an FTP Authentication Provider with Dynamic IP Restrictions walkthrough, but I don't create any accounts in the database - I just want to log and block the IP addresses of would-be attackers that are attempting to brute force their way into my server. Configuring the authentication options is accomplished through the FTP Authentication feature in IIS Manager.

Ever since I wrote and deployed my dynamic IP address restriction authentication provider, it has faithfully blocked dozens of would-be attackers.

Hiding your FTP Server Type

The next approach that I take is "Security through Obscurity", where I hide the easily recognizable signatures that identify my FTP server. The first step is to suppress the default banner and add a custom FTP banner. This is accomplished through the FTP Messages feature in IIS Manager.

Next, switch your directory listing style to Unix format. All FTP clients that I have tested understand this format, but it hides the fact that your server can do MS-DOS listings. Configuring your directory listing style is accomplished through the FTP Directory Browsing feature in IIS Manager.

After implementing these changes, it might now resemble the following example FTP session when you log in with FTP:

CMD>ftp localhost

Connected to DESKTOP.domain.local.
220 Welcome to my server!
User (DESKTOP.domain.local:(none)): foobar
331 Password required for foobar.
Password:
230 User logged in.
ftp> dir
200 EPRT command successful.
125 Data connection already open; Transfer starting.
drwxrwxrwx   1 owner    group               0 Jan 22 11:45 App_Code
drwxrwxrwx   1 owner    group               0 Sep 10 10:32 App_Data
drwxrwxrwx   1 owner    group               0 Aug 17 13:35 bin
-rwxrwxrwx   1 owner    group             689 May  8  2008 iisstart.htm
-rwxrwxrwx   1 owner    group            2714 Jan 22 11:54 web.config
-rwxrwxrwx   1 owner    group          184946 May  8  2008 welcome.png
226 Transfer complete.
ftp: 418 bytes received in 0.02Seconds 83.00Kbytes/sec.
ftp> bye
221 Goodbye.

CMD>

The last step that I take is to block the FTP infrastructure commands SYST and FEAT on the global listener FTP site. These commands respectively display your operating system and list of FTP features. Blocking these commands helps to further obfuscate your server type from attackers.

Note: It is important that you block these two commands only on your global listener FTP site and not on your other FTP sites, because some FTP clients may depend on these commands in order to interact properly with your other FTP sites. That said, if you are working with a small set of FTP clients and none of them seem to have a problem with suppressing the SYST command, you could probably suppress that globally. Most clients that I have tested seem to have no problem with that, especially if you are using Unix directory listings.

In any event, you block the SYST and FEAT commands through the FTP Request Filtering feature in IIS Manager.

Now when you log in with FTP and attempt to use the SYST and FEAT commands, it should look like the following example FTP session:

CMD>ftp localhost

Connected to DESKTOP.domain.local.
220 Welcome to my server!
User (DESKTOP.domain.local:(none)): foobar
331 Password required for foobar.
Password:
230 User logged in.
ftp> quote SYST
500 'SYST': command not allowed.
ftp> quote FEAT
500 'FEAT': command not allowed.
ftp> bye
221 Goodbye.

CMD>

Summary

The steps in this blog are certainly not all-inclusive, and I keep coming up with other ideas as time goes on, but following these steps should help to prevent unauthorized access to your FTP service. All of the normal warnings about using strong passwords, changing your passwords often, using SSL whenever you can, and keeping your hotfixes up-to-date will always apply.

But that being said, one of the ways that I keep finding new things to block is by simply watching my FTP log files to see what attackers are trying to do. By using some of the techniques that I discuss in my Using LogParser with FTP 7.x Sessions blog, you can monitor your FTP log files in order to analyze what would-be attackers are trying to do.

The End of Metabase Corruption (R.I.P.)

Anonymous — Sat, 22 Aug 2009 07:28:00 GMT

Even though IIS 7 with its new XML-based configuration settings has been around for a while, I was going through some old directories on one of my computers the other day and I stumbled across an image that I had labeled "Metabase Corruption." I have kept that image around for the past decade or so because it's one of the few actual examples of metabase corruption that I have actually verified, although there have definitely been more cases than just the ones that I have seen. But I thought that it might make for a good blog entry to explain the origins of the term "Metabase Corruption" and what that means to you if you're using a version of IIS that is earlier than IIS 7.

A brief history of the IIS metabase and metabase editors

Many years ago I was working in the Microsoft Product Support Services (PSS) group, where I provided support for enterprise-level customers that were using IIS versions 1.0 through 6.0. The early versions of IIS, (versions 1.0 through 3.0), stored all of their settings in the registry. This was fine for that period of time, but it didn't scale well and for several other reasons it was cumbersome to deal with. Just to bring back some nightmares, here's an image of the IIS 3.0 manager:

When IIS 4.0 was released, it introduced the "metabase," which was a proprietary database that stored all of the metadata for IIS, and all of that information was physically stored in a file that was named metabase.bin. The metabase scaled considerably better than the registry, but it introduced several other problems. The biggest problem was that the metabase was something of a "black box" for end users - all of your settings were stored in the metabase, and the only way to get to those settings was through the IIS Manager or by using unsupported command-line tools. The next big problem was that the metabase wasn't portable - you couldn't copy the metabase from one computer to another. (If you tried you would quickly realize that you just killed IIS.) When the IIS 4.0 Resource Kit was released it introduced MetaEdit 1.0, which was an editor for the metabase that looked like RegEdit, but it crashed so often that it really wasn't useful.

During the Windows 2000 timeframe I took over the MetaEdit code base and I created MetaEdit 2.0, which was released with the Windows 2000 Resource Kit. I fixed all of the stability problems from MetaEdit 1.0 and I added export/import functionality so that users could copy sections of the metabase between servers. Actually, I wrote MetaEdit before Microsoft stopped adding Easter Eggs to software, so there's a small Easter Egg in the Help::About for MetaEdit that you can find by holding down Shift-Ctrl-Alt and double-clicking the icon - you first see a photo of Bill Gates and then you see a photo of me from the days when I had longer hair...

I released a couple of patches to MetaEdit over the years, and the last version that I released is version 2.2, which you can download through the following URL:

How To Install MetaEdit 2.2 on Windows NT 4.0 or Windows 2000

When Windows Server 2003 was in development, XML had risen within the development community as a great way to store your data, so the IIS team decided to switch from the metabase.bin format to metabase.xml. This allowed for editing the metabase using any XML editor, even Windows Notepad, and IIS added native export and import functionality, so you could migrate settings from one computer to another by using IIS Manager.

It was sometime during the Windows 2003 timeframe that I was working on MetaEdit 3.0 when I heard that someone else was working on Metabase Explorer, and the early versions of Metabase Explorer that I was able to test were really cool, so I ceased work on MetaEdit in favor of Metabase Explorer, which was eventually released with the IIS 6.0 Resource Kit Tools. You can download the IIS 6.0 Resource Kit Tools through the following URL:

Internet Information Services (IIS) 6.0 Resource Kit Tools

Note: MetaEdit should only be used on Windows NT 4.0 with IIS 4.0 or Windows 2000 with IIS 5.0. For IIS 6.0 you should only use Metabase Explorer. (And yes - you can blame me for the totally useless dialog that you get when you try to use MetaEdit with IIS 6.0. Sorry about that. )

What's all this about metabase corruption?

It was shortly after the release of IIS 4.0 that I first heard the term "Metabase Corruption" being used. People were using the term "Metabase Corruption" as a catch-all phrase for "I don't what's broken but reinstalling IIS fixed the problem so it must have been a problem with the metabase." Everyone's general opinion seemed to be that if you couldn't find the problem and you can't look at the metabase, then it must be corruption in the metabase if you can't resolve the issue without reinstalling IIS. To me, this seemed like a cop-out for good troubleshooting, and since I was a technical lead in PSS around the time that IIS 5.0 was being released I would generally refuse to accept anyone's claim when they said that they had a customer with "Metabase Corruption." Instead, I would require them to troubleshoot the problem further, and in nearly 100% of those situations the problem was not caused by the metabase but by some other problem that could be rectified without reinstalling IIS.

Here's a case in point - several years ago I worked on an issue that some of the folks that supported SharePoint Portal Server 2001 on IIS 5.0 were seeing. They first described the problem to me as "IIS was losing settings." What they were actually seeing was that they would make changes in IIS Manager and apply them, but when they would close and reopen IIS Manager they saw that all their settings were gone. They claimed that this was "Metabase Corruption," and because of this they would often make the customer reinstall IIS completely. Needless to say I made them quite angry by stating that "Metabase Corruption" is almost never actual corruption, and that they were wasting the customer's time by making them reinstall IIS. Even though reinstalling IIS made the problem go away, it didn't actually fix the problem and it only hid the actual cause at the customer's expense.

Since I knew a little more than they did about how the metabase worked, I could theorize reasons why that behavior might occur and I asked them to contact me when they had a customer with this problem again. The next time they saw this problem I asked them to follow these steps:

Stop IIS by using "iisreset /stop" from a command-line
Start just the IISADMIN service by using "net start IISADMIN" from a command-line
Open the IIS Manager, make their changes, then close the IIS Manager
Restart IIS by using "iisreset /restart" from a command-line
Open IIS Manager and verify their settings

In 100% of the cases this enabled them to work around the issue, but that was only part of the solution. I theorized that something was causing IIS to crash before the metabase changes were flushed to disk, but the Windows service recovery settings were instructing the server to restart IIS whenever it crashed so it seemed to the customer like nothing had crashed at all. With this in mind, I had them check the Windows System Log in the Event Viewer, and it listed several errors indicating that the IISADMIN service had terminated unexpectedly, which confirmed my suspicions. After some additional troubleshooting I discovered that SharePoint Portal Server 2001 was setting several illegal values in the metabase, and sooner or later that would cause IIS 5.0 to crash. (SharePoint has long since fixed that problem.)

Does metabase corruption actually happen? If so, what can I do about it?

Sadly - yes it does. It doesn't happen as often as some people seem to think that it does, but it is certainly possible. The metabase is simply a file, and file corruption can occur for any number of reasons. In the early days of IIS 5.0 on the Windows 2000 beta I discovered (quite by accident) how I could overwrite one specific value in the metabase and crash IIS so badly that IIS couldn't even be uninstalled. (Don't worry - that problem has long since been fixed.) I have also seen metabase corruption due to hardware failures, like a drive controller that is going bad and the problem is manifesting itself slowly over time.

That being said, there are several methods to check if you actually have metabase corruption:

The first and easiest thing to check is - does IIS start and all of your web sites seem to work?
Can you open up the IIS Manager and see all of your sites?
Can you enumerate the metabase without errors using MetaEdit, Metabase Explorer, or "adsutil.vbs enum_all w3svc" from a command line?

If the answer to any or all of these questions is yes - then chances are good that you do not have metabase corruption, and whatever problem you have is due to misconfiguration or some other issue.

The best way that I can think of to prevent metabase corruption is to avoid using a variety of tools to constantly read and write to the metabase outside of normal IIS operations. I have written scripts that perform literally thousands of metabase operations under a nominal load in a lab environment for testing purposes and never had a problem, but a server under heavy load with thousands of read/write operations per minute could theoretically run into problems if left to run like that for an indefinite length of time. But theoretically the same may be true for any file under heavy read/write load for an indefinite length of time.

Protecting against metabase corruption

The best thing that you can do to prevent against metabase corruption is backup the metabase regularly!!! I cannot count the number of times where having a good backup of the metabase saved me from a myriad of issues. Fortunately, there are several KB articles that describe backing up the metabase:

The last KB article in the above list is based on a script that I wrote for one of my IIS 5.0 on Windows 2000 servers many years ago that I continue to use on any servers that run IIS 6.0 on Windows Server 2003.

Does IIS 7 have metabase corruption?

The quick answer to this is "no", but that answer is a little misleading since IIS 7 doesn't have a metabase!

In IIS 7 we rolled out a brand new XML-based configuration store, and the bulk of your IIS settings are stored in a file named applicationHost.config, which greatly resembles the web.config configuration paradigm that was established with the .NET framework. That being said, applicationHost.config is just another file, and even though its syntax is much easier to understand and manually edit, any file can theoretically become corrupted, so you should always make sure that you backup your applicationHost.config file as well.

With this in mind I wrote the following blog post some time ago where I discuss creating a script to automate backing up your IIS 7 configuration settings:

Automating IIS 7 Backups

(Note: I also wrote another blog post recently about how the script in that blog post saved my day when something did get corrupted on one of my servers.)

Parting thoughts

I started out this blog post by describing an image that I found on one of my computers where actual metabase corruption had occurred, so I thought that a nice way to close out this blog post would be to show you the actual image:

It's been almost ten years now, so I don't remember the root cause anymore, but I remember what it looked like. I had a mixture of sites that were working and others that were not, and when I opened the metabase in MetaEdit I noticed that scattered throughout the metabase were hundreds of values that shouldn't be there or values that did not make sense. MetaEdit was trying its best to show all of the data, but you'll notice in the highlighted areas of the image that several of the values had bad data in them.

A Little Scripting Saved My Day (;-])

Anonymous — Mon, 27 Jul 2009 18:55:00 GMT

I have mentioned in previous blog posts that I tend to write many of my blog posts and walkthroughs for IIS.NET based on code that I’ve written for myself, and today’s blog post is the story of how one of my samples saved my rear over this past weekend.

One of the servers that I manage is used to host web sites for several friends of mine. (It’s their hobby to have a web site and it’s my hobby to host it for them.) Anyway, sometime on Sunday someone let me know that one of my sites didn’t seem to be behaving correctly, so I browsed it with Internet Explorer and saw that I was getting an HTTP 503 error. I’ve seen this error when an application pool goes offline for some reason, so I didn’t panic – yet – because I knew that the web site was in a separate application pool. With that in mind, I browsed to a web site that is in a different application pool. Same thing – HTTP 503 error. This was beginning to concern me.

I logged into the web server and ran iisreset from a command-line – this threw the following error - and now I was really starting to become agitated:

CMD>iisreset Attempting stop... Internet services successfully stopped Attempting start... Restart attempt failed. The IIS Admin Service or the World Wide Web Publishing Service, or a service dependent on them failed to start. The service, or dependent services, may had an error during its startup or may be disabled. CMD>

I knew that the cause of the error should be in the Windows Event Viewer, so I opened the System log in Event Viewer and saw the following error:

Log Name: System

Source: Microsoft-Windows-WAS

Date: 7/26/2009 10:59:52 AM

Event ID: 5172

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: MYSERVER

Description: The Windows Process Activation Service encountered an error trying to read configuration data from file '\\?\C:\Windows\system32\inetsrv\config\applicationHost.config', line number '308'. The error message is: 'Configuration file is not well-formed XML'. The data field contains the error number.

Event Xml:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-WAS" Guid="{4E616D65-6F6E-6D65-6973-526F62657274}" EventSourceName="WAS" /> <EventID Qualifiers="49152">5172</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-07-26T17:59:52.000Z" /> <EventRecordID>32807</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>System</Channel> <Computer>MYSERVER</Computer> <Security /> </System> <EventData> <Data Name="File">\\?\C:\Windows\system32\inetsrv\config\applicationHost.config</Data> <Data Name="LineNumber">308</Data> <Data Name="Error">Configuration file is not well-formed XML</Data> <Binary>0D000780</Binary> </EventData> </Event>

Log Name:	System
Source:	Microsoft-Windows-WAS
Date:	7/26/2009 10:59:52 AM
Event ID:	5172
Task Category:	None
Level:	Error
Keywords:	Classic
User:	N/A
Computer:	MYSERVER
Description:	The Windows Process Activation Service encountered an error trying to read configuration data from file '\\?\C:\Windows\system32\inetsrv\config\applicationHost.config', line number '308'. The error message is: 'Configuration file is not well-formed XML'. The data field contains the error number.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-WAS" Guid="{4E616D65-6F6E-6D65-6973-526F62657274}" EventSourceName="WAS" /> <EventID Qualifiers="49152">5172</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-07-26T17:59:52.000Z" /> <EventRecordID>32807</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>System</Channel> <Computer>MYSERVER</Computer> <Security /> </System> <EventData> <Data Name="File">\\?\C:\Windows\system32\inetsrv\config\applicationHost.config</Data> <Data Name="LineNumber">308</Data> <Data Name="Error">Configuration file is not well-formed XML</Data> <Binary>0D000780</Binary> </EventData> </Event>

Now that I was armed with the file name and line number of the failure in my configuration settings, I was able to go straight to the source of the problem. (I love IIS 7's descriptive error messages - don't you?) Once I opened the file and jumped to the correct location, I saw several lines of unintelligible garbage. For reasons that are still unknown to me – my applicationHost.config file had become corrupted and IIS was dead in the water until I fixed the problem. I looked through the file and removed most of the garbage and saved the edited file to IIS – this got the web sites working, but only partially. Some necessary settings had obviously been removed while I was clearing all of out the unintelligible garbage, and it might take me a long time to discover what those settings were.

The next thing that I did was to take a look in my two readily-accessible backup drives; I have two external hard drives that keep a backup of the web server - one hard drive is directly plugged into the web server via a USB cable, and the other hard drive is plugged into a physically separate server that rotates drives with off-site storage on a monthly basis. The problem is, my weekly backups had just run, so the copy in each backup location had been overwritten with the corrupted version. (I’m going to have to rethink my backup strategy after this – but that’s another story.) The backup copy in my off-site storage location should be intact, but that copy would be a few weeks old so I would be missing some settings, and I would have to drive an hour or so round-trip in order to pick up the drive. This wasn’t an ideal solution – but it was definitely a feasible strategy.

It was at this point that I remembered that I had written following blog post some time ago:

Automating IIS 7 Backups
http://blogs.msdn.com/robert_mcmurray/archive/2008/03/08/automating-iis-7-backups.aspx

I wrote the script in that blog post for the server that I was currently managing, and because of this preventative measure I had dozens of backups going back several weeks to choose from. So I was able to quickly find a copy with no corruption and I restored that copy to my IIS config directory. At this point all of my web sites came online with all of their functionality. Having fixed the major issues, I used WinDiff to verify any settings that might have been changed between the restored copy and the corrupted copy.

So in conclusion, this story had a happy ending, and it left me with a few lessons learned:

You can never have too many backups
I need to rethink how I roll out my backup strategy with regard to using external hard drives
Writing cool scripts to automate your backups can save your rear end

That sums it up for today’s post. ;-]

Using Apple's WebDavFS for Mac OS X with WebDAV on IIS 7

Anonymous — Thu, 02 Jul 2009 02:19:00 GMT

Today's blog post needs to have a disclaimer right up front - I freely admit I'm not a Mac OS X expert, so I may not have everything 100% correct in this post. But I've seen a lot of questions on forums.iis.net that discuss using IIS WebDAV with Mac OS X, so I thought that I'd share a few of the things that I've noticed. Just the same, if I were writing a formal walkthrough I would have said something like, "Microsoft is not responsible for the behavior of Apple's Mac family of products. The information that is provided in this topic is provided to assist Mac OS X users connect to IIS using WebDAV."

All that being said, here are the prerequisites for getting your environment together:

Your server needs to be running Windows Vista, Windows Server 2008, or Windows 7.
Your server needs to have Internet Information Services 7 and the WebDAV module installed. (Note: See the Installing and Configuring WebDAV on IIS 7.0 topic for more information.)
For best results, your Mac client needs to be running OS X version 10.4 or later.

Connecting to a WebDAV server using Mac OS X

In Mac OS X, open Finder.
Choose Go, then Connect To Server.
Enter the URL of the WebDAV server in Server Address. For example:
http://www.example.com/path/
Click Connect.

For more information, please see the following help topics that are available on Apple's Web site:

Troubleshooting WebDAV connections using Mac OS X

These are some of the issues that I've seen:

WebDavFS connections are read-only if WebDAV LOCKs are disabled on the server. Because of this:
- If you are using WebDAV 7.0 on IIS 7 you will not be able write files to the server; this is because WebDAV locks were not available in this release.
- If you are using WebDAV 7.5 on IIS 7 you will need to enable locks before you can write files to the server; this is because WebDAV locks are disabled by default. (Note: See the How to Use WebDAV Locks topic for more information.)
WebDavFS connections attempt to create files that may be blocked by IIS:
- "Desktop Services Store" (.DS_Store) files. (See http://en.wikipedia.org/wiki/.DS_Store for a description.)
- "Resource Fork" (e.g. "._filename.ext") files. (See http://en.wikipedia.org/wiki/Resource_fork for a description.)
Allowing unknown MIME types for WebDAV requests should allow these file types, and that setting is located under Web Settings action for the WebDAV Authoring Rules feature of IIS Manager.

For more information, see the following topics that are available on Apple's Web site:
- Mac OS X 10.4: How to prevent .DS_Store file creation over network connections
- Mac OS X 10.4: Windows Server 2003 IIS Web Server fails GET call on .DS_Store and ._ files

In Closing...

I have to reiterate that I'm not a Mac OS X expert, so this list is probably not all-inclusive, but it's helped to resolve some of the issues that I've seen.

FTP Clients - Part 6: Core FTP LE

Anonymous — Fri, 01 May 2009 23:10:00 GMT

For this installment in my series about FTP Clients, I'd like to take a look at the Core FTP client. For this blog post I used Core FTP Lite Edition (LE) version 1.3c (build 1447) and version 2.1 (build 1603), although all of my screen shots are from version 2.1. Core FTP is available from the following URL:

http://www.coreftp.com/

At the time of this blog post, Core FTP provides the LE for free and charges a small fee for a professional version.

Like most graphical FTP clients, the Core FTP LE user interface is pretty easy to use and rather straight-forward - you have separate windows for your local and remote files/folders, as well as a logging window that lists the FTP commands that are sent and the FTP server's responses:

Core FTP LE has a great Site Manager feature, which allows you to store commonly-used connections to FTP sites:

Clicking on the Advanced button gives you a great deal of additional configuration settings, and I'll say more about that later:

Command-Line Support

This is one of my favorite Core FTP LE features: command-line support. Yes - I'm a geek - and I like being able to script things and run batch jobs to automate whatever I can, so command-line support is always a plus for me. That said, the interface for the Core FTP LE command-line client is not an interactive experience like you get with the built-in Windows FTP.EXE or MOVEit Freely command-line clients. The Core FTP LE command-line client is provided as via the Corecmd.exe file that is installed in the main the Core FTP LE application directory, and is used for a single FTP operation like GET or PUT - although you can pass the name of a script file to execute several commands before/after logging in or before/after a file transfer.

So my final judgment is that the Core FTP LE client doesn't have great command-line support, but it's still really nice to have.

Using FTP over SSL (FTPS)

The Core FTP LE client supports both Implicit and Explicit FTPS, so the choice is up to you which method to use. When creating a connection to a server, Core FTP LE has three FTP options that you can use with FTP7:

AUTH SSL
AUTH TLS
FTPS (SSL DIRECT)

It's important to choose this option correctly, otherwise you will run into problems when trying access a site using FTPS. If you'll recall from my "FTP Clients - Part 2: Explicit FTPS versus Implicit FTPS" and my other FTP client blog posts, Explicit FTPS allows the client to initiate SSL/TLS whenever it wants, but for most FTP clients that will be when logging in to your FTP site, and in that regard it may almost seem like Implicit FTPS, but behind the scenes the FTP client and server are communicating differently.

In the case of FTP7, the following rules apply:

If you enable FTPS in FTP7 and you assign the FTP site to port 990, you are using Implicit FTPS - Core FTP LE refers to this as FTPS (SSL DIRECT). (Note: make sure that you configure your FTP client to connect on port 990.)
If you enable FTPS in FTP7 and you assign the FTP site to any port other than port 990, you are using Explicit FTPS - Core FTP LE allows you to configure your connection to use AUTH SSL or AUTH TLS for the explicit connection.

The type of FTPS is specified on the Connection drop-down menu:

Once you have chosen an FTPS connection, the Core FTP LE client offers you additional options where you can customize which parts of the session will be encrypted:

You can combine the Core FTP SSL options with the advanced SSL policies for your FTP7 sites to customize your security level:

Using FTP Virtual Hosts

Because Core FTP LE's site manager allows you to specify the virtual host name as part of the user credentials, Core FTP LE works great with FTP7's virtual host names. All that you need to do is use the "ftp.example.com|username" syntax when specifying your username, and when you connect to the FTP7 server it will route your requests to the correct FTP virtual host site.

Using True FTP Hosts

A really great feature of Core FTP LE is the ability to send pre-login commands, and since this feature allows you to enter custom commands you can specify the actual FTP HOST command as part of your login:

This is a tremendous feature if you're hosting multiple FTP sites on the same IP address, and gives Core FTP LE some of the best support for true FTP HOSTs.

Scorecard for Core FTP LE

That wraps it up for our quick round-trip for some of Core FTP LE's features, and here's the scorecard results:

Client Name	Directory Browsing	Explicit FTPS	Implicit FTPS	Virtual Hosts	True HOSTs
Core FTP LE 1.3	Rich	Y	Y	Y	Y ¹
Core FTP LE 2.1	Rich	Y	Y	Y	Y ¹
¹ As noted earlier, true FTP HOSTs are available in Site Manager using pre-login commands.

Note: Keeping with my standard disclaimer, there are a great number of additional features that Core FTP LE provides - and I just focused on the topic areas that apply to FTP7.