DiscountASP.net who has been a very close partner of the IIS Team leading several offerings of our platform - including IIS Manager Remote Delegated Access to the Web Site and many other cool tools - has just built and released yet another cool module that extends the IIS Manager capabilities by having a GAC Viewer for their customers.

The GAC Viewer is still in Beta but I think it showcases some of the cool stuff that IIS 7.0 platform brings to the table providing extensibility from end-to-end, whether its Runtime, Configuration, IIS Manager, etc.

This is the way their GAC Viewer looks like:

And when you connect to their site and you don't have it installed our infrastructure will automatically download it as needed when the user accepts it:

Note that DiscountASP.net also offers other modules, including some of our recent modules like Database Manager, Request Filtering and others (I already had some of them installed and that is why it doesn't show in this list) and their own Web.config Backup and a Feedback Module.

All I can say is that it makes me extremely happy anytime I see someone take advantage of the platform in such interesting ways.

Keep up the good work!

In my previous post I mentioned that IIS Manager (more specifically Microsoft.Web.Administration) has two algorithms for assigning a Site ID when no ID is specified.

The two algorithms are:

1. Incremental Site ID. When this algorithm is configured we will assign the first consecutive number available, for example, if you have Site ID's 1,2,3,5,6,8 the next time you add a Site in the UI (or using ServerManager.Sites.Add friendly overloads), you will get Site ID = 4, next will be 7, and next will be 9. The side effect of this is that you will get different Site ID's depending on the sites that are available which might complicate things in certain scenarios when provisioning the same site in multiple machines. The good news is that in IIS 7.0 the Side ID is not so important in terms of the configuration system since now all the configuration is stored using the Site Name instead. (Exceptions apply, for example when using the Metabase compatibility (customMetadata) or when you are using things like Session State in ASP.NET)
2. Site Name Hash. In this case we will calculate a Hash of the Site Name and use that number for the Site ID. This will end up using some funky numbers that will be impossible to remember but that "can work" in different machines. Technically we use the .NET implementation of "String.GetHashCode()" which you can read the remarks "The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode."
   

In either case we will ensure that whatever ID we generate it will not collide with any existing Site.

These algorithms are configured using the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters

In there you will find a DWORD attribute called IncrementalSiteIDCreation when set to 1 we will use the Incremental algorithm (1), otherwise we will use the Site name hash.

Bottom line if you really care about the Site ID and are provisioning the sites using Microsoft.Web.Administration you are better off having your own deterministsic algorithm for assigning the Site ID yourself and it will actually be considerably faster.

If you are using the UI chances are you really don't care about the Site ID, cause you would never have to interact with it (again might need changes when using certain ASP.NET features).

Yesterday I got an email about some performance numbers that one of our customers were running into when creating remotely Web Sites, Applications, Application Pools and other tasks in IIS using Microsoft.Web.Administration. In case you don't know Microsoft.Web.Administration is a .NET library that exposes the IIS Configuration System.

The code was using Microsoft.Web.Administration from PowerShell to create a single Application Pool, a new Web Site, and finally assign the Root Application to the new Application Pool, and it was measuring each of the tasks. The application then was called continually till 10,000 sites were created. They then created a very nice Excel Spreadsheet that had a chart with how long it took when performing each operation that clearly show how fast (or slow) things were depending on the existing number of sites in IIS.

Funny enough the code was doing almost exactly what we use to measure in IIS 7.0 performance while provisioning. And that we ran into very similar numbers back a couple of years ago but we probably never share them. The results back in the day were showing a trend like the one below, where the Creation of the AppPool was quite fast (less than 400ms once you had 10,000 sites), the Application Pool assignment was taking almost 10 times more (almost 4 seconds) and the creation of the Sites was taking almost 20 times more (up to 8 seconds).

Our test code looked something like this (removing all the Timing code):

Back in those days (2005) the numbers were even worst, you would have to wait literally minutes to get a site created but we profiled it and understood exactly what the performance behavior was and we made it better.

Here is how to make it faster

1. Most importantly batch as many changes you need to do to our configuration system so that you only CommitChanges once, for example, creating the 10,000 sites and only Committing once will probably average 1,000 sites per second. More importantly you will reduce the load on the server since every time the configuration is changed our server has to process its changes and that incurs in other CPU cycles in WAS and W3SVC.
2. The reason we noticed Application Pools was being slower at the beginning when using ServerManager locally was just an artifact of the fact that it’s the first operation being done in our Test Script. The reason is that when you create a ServerManager in reality nothing interesting happens other than we activate a COM object that parses the schema, however whenever you request a section that is when the real XML parsing of files happens. This means that the first operation (in this case accessing the AppPool collection) pays the price of parsing machine.config, root web.config and ApplicationHost.config, which is the file that grows considerably as new sites/pools are added.
3. Definitely using ServerManager remotely (OpenRemote) will be several times slower because every time property is set or anything is changed the code actually hits the network to set the values in the remote objects, since on the client there are only client proxies. This means that setting appPool.Name actually goes through the network to set the values on the dllhost.exe hosting DCOM.
4. Finally the most important one, the reason the Site creation is extremely slow is because the way our test code was creating the site and the application, in particular we are using the method m.Sites.Add() which has several overloads, where most of them provide a set of "friendly-non-performant” combinations. This is due to the fact that none of them receives a Site ID which forces us to automatically calculate one every time a Site will be added. We have implemented two algorithms for this (depending on a registry key called IncrementalSiteIDCreation) and both have the issue that we need to read all the sites first to make sure we don’t generate an ID that is already in use. This means that if you have 4,000 sites we have to read all 4,000 sites and that of course over the network translates to literally thousands of round trips.
   So bottom line use the m.Sites.CreateElement() followed by a m.Sites.Add(newSite) which will not create an ID for the Site that will not incur in the costs mentioned. Something like the snippet below. Notice that there is a little bit more code since you also need to create the Root Application and set the bindings, but this will proof useful since setting the AppPoolName requires the App anyway and you save all the Lookups on the Sites list as well.
using(ServerManager m = new ServerManager()) {
    ApplicationPool pool = m.ApplicationPools.Add("MyPool");

    Site site = m.Sites.CreateElement("site");
    site.Name = "MySite"
    site.ID = "MySite".GetHashCode();

    Application app = site.Applications.Add("/", "d:\inetp...");
    app.AppPoolName = "MyPool";
    
    m.CommitChanges();
}

After all that story, what is important to realize is that there are ways to make this way faster and that you should use them if you are going to do any sort of massive creation of sites. With the two changes outlined above (Specify the Site ID yourself and don't lookup the Site again to get the App) the results were incredible we were back to under 350ms for all the tasks.

Today I was going to post about extending the IIS Configuration, in particular about a feature that not everybody knows that allows you to extend the IIS Configuration System using dynamic code. What this means is that instead of hard-coding the configuration using XML in a .config file, your configuration can be provided by a COM object that implements IAppHostPropertyExtension, IAppHostElementExtension and IAppHostMethodExtension.

Then, just to make sure I was not repeating what somebody else already said I searched for this in live.com (Worth to say, excellent results, first hit is the documentation of the interface, second hit is an excellent article in iis.net).

So instead of repeating what you can already find in those places in IIS.NET I decided to not blog about it in details, but instead mention some of the things that are not specified in these places.

This dynamic configuration is great and offers lots of interesting features since it allows you to expose any random code that can immediately be accessed through all of our configuration API's, including Microsoft.Web.Administration, AHADMIN, etc, giving your end-user a common programming paradigm, in fact this also means that its immediately accessible to the UI API's and even to the new Configuration Editor in the Admin Pack.

Another interesting benefit is that through these API's your code can be called remotely so that it can be scripted to manage the machines remotely without the need to write any serialization or complex remote infrastructure (restrictions might apply).

However, one thing that is also important to mention is that these dynamic configuration extensions are only available for administration tools, meaning you cannot access this extensions from the worker process by default. To clarify, you cannot use the Worker Process configuration instance to invoke these extensions since the worker process specifically disables the ability to call them in its configuration instance. However, if you create your own instance of Microsoft.Web.Administration.ServerManager (which requires you to be running in Full Trust) you will be able. You can also create your own instance of Microsoft.ApplicationHost.AdminManager and you will be able to access them. However in both cases this will only work if your an Administrator in the machine or have read ACL's for ApplicationHost.config file (which by default is only readable by Administrators). This is why methods like Microsoft.Web.Administration.WebConfiigrationManager::GetSection (and CoGetObject for AHADMIN) are provided so you don't run into these issues when developing Web Applications and are still able to read configuration sections for your worker process without requiring administrative privileges (in MWA provided you are either are in Full Trust or the section definition marks it as requirePermission=false).

To understand better some scenarios its worth to mention that In IIS 7.0 we actually use these API's to provide access to runtime information in an easy way and other tasks, for example, to query the state of a Site, to Recycle an Application Pool, to assign an SSL certificate to a binding, to stop a Site, are all provided through this mechanism. If you want to see all the things we do this way just open %windir%\System32\Inetsrv\config\schema\rscaext.xml where all of our Web Server extensions are declared. Our own FTP Server for IIS 7.0 uses the same mechanism for things like querying Sessions, and other cool stuff.

Anyway, feel free to give the IIS.NET article a good read, its quite good.

http://www.iis.net/articles/view.aspx/IIS7/Extending-IIS7/Extending-IIS7-Configuration/Configuration-Extensibility

OK, this blog entry sat in my drafts for more than a month now, but finally today I will be talking about another cool feature of the IIS Admin Pack, Database Manager.

Database Manager allows you to easily manage a SQL Server Database from within the IIS Manager User Interface. Now, why would you need another UI for managing a database? Here are some of the facts that make Database Manager interesting:

1. No additional components are required in the machine, just by installing the IIS Admin Pack you get a UI with support for remote management, and many more features (with TP2 it will install SQL Server Management Objects).
2. Allows you to manage both local and remote database from your machine.
3. By using the Remote Management capabilities of IIS provides a clean firewall-friendly option for managing a remote SQL Server.
4. Exposes a public extensibility platform with support for other databases.

Features

The version included in the Admin Pack Technical Preview 2 includes the following features:

1. Add/Rename/Drop and Edit Tables
2. Primary Key/Indexes and Foreign Keys management
3. Query Analyzer like function
4. Data Editing
5. View/Drop Store Procedures

The only permissions you need to get all the functionality in the database are "db_databreader, db_datawriter and db_ddladmin", where db_ddladmin is only required if the schema manipulation such as adding tables, deleting tables, etc, is needed.

Database Manager automatically reads the list of Connection Strings stored in the configuration system of the selected object, for example a specific site's config, or a specific application, and they will be automatically pre-loaded in the Database Manager connections tree view where you can just expand any of them and you will get the tables and all the functionality. This option makes it really convenient for querying data and allows server administrators to maintain control on what databases can be managed using this feature making it a really nice option for developers building Data Driven applications. It additionally allows users to specify their own connections that are not stored in configuration files and still get all the functionality.

This means that if you are like many of the web sites running in hosted environments (or are a hoster that provisions a single user/database in advance for users) and you only get a single database user for accessing the data as well as doing all the database maintenance, then you can live with the connection strings approach. This provides a convenient way to provide delegation in a secure way, by adding the connectionString in the root web.config with a locationPath for that particular web site and being able to lock them prevents them from uploading new connectionStrings that could be just trying to fish for users/passwords in your server. As a Server Administrator, you can enforce this functionality by specifying allowClientConnectionStrings="false" in administration.config.

Remote Administration

Arguably what makes IIS Database Manager really interesting is that it uses the IIS Manager Remote Administration infrastructure, allowing it to work remotely using nothing but HTTPS to communicate to the server. This way the server does not require to open any additional ports, all the communication happens over the IIS Remote Management HTTPS protocol. It also means that the server is the only one that requires connectivity with the Database Server, making this ideal for hosting environments because the Clients does not require any software installed on their machines, no SQL libraries or anything, just IIS Manager which can be run in Windows Server 2008, Windows Vista, Windows 2003 and Windows XP.

Note that when using IIS Manager locally such as when using Windows Vista or Windows 2008 to manage "localhost" then IIS Manager will connect directly to SQL so no additional jump through HTTPS.

To try to explain this using a picture:

Extensibility

Another very interesting feature of Database Manager is that it was conceived as an easy way to expose different databases (not only SQL Server) to Web Developers, IT-Pro's and Hosters. This means that we created it following a Provider model where all you need to do is implement a single class in C# called DatabaseProvider, register it in the Server and now you can manage your own database. We have implemented the SQL Server functionality on top of this provider model and are working on other providers that you should soon hear from.

Andrew Birck, who is a Developer in my team wrote a very nice blog entry on how to extend the functionality. To keep it simple he implemented a DataSet provider that allows you to manage an XML as if it was a real database, allowing you to use the same features (Create Table, Edit Data, etc), make sure to check it out at: http://blogs.msdn.com/andrewbi/archive/2008/05/21/writing-a-databaseprovider.aspx

Gurpreet Singh who is a developer in my team published last week a couple of articles on how to extend IIS Manager 7:

1) The first one talks about how to write an IIS Manager extension in general and walks you through the process using Visual Studio: http://learn.iis.net/page.aspx/441/understanding-ui-extension-authoring/

2) The second one shows how to extend the IIS Reports feature in Admin Pack to add your own report to it and shows this using Log Parser: http://learn.iis.net/page.aspx/464/walkthrough-for-creating-an-iis-report/

Today we are releasing a very cool feature that lots of customers have really been asking for, URL Rewrite Module is now available for download at:

Download the x86 CTP version for IIS 7.0: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1691

Download the x64 CTP version for IIS 7.0: http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1692

I'm pretty happy about this release not only because its a great feature that many of us have been waiting for, but also because I personally got to work quite a bit on it, helping with the Configuration Design, my team (Gurpreet Singh) built the UI, my good friend Daniel built the runtime module and I actually got to write some code and built the apache mod_rewrite translation feature.

To learn more about it and see all the cool documentation and walkthroughs:

http://learn.iis.net/page.aspx/460/using-url-rewrite-module/

So please keep the feedback coming: URL Rewrite Forum: http://forums.iis.net/1152.aspx

Today we are releasing the Technical Preview 2 of the IIS Admin Pack, it is an update of the release we made on February.

Install the Admin Pack and Database Manager today!

Admin Pack (x86):  http://www.iis.net/downloads/default.aspx?tabid=34&i=1682&g=6

Database Manager (x86):  http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1684

Admin Pack (x64): http://www.iis.net/downloads/default.aspx?tabid=34&i=1683&g=6

Database Manager (x64):  http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1685

New Features:

There are a lot of interesting features we've added to almost every component for this release:

Database Manager

1. Specify your own Connections. We heard during TP1 that it was a very important feature to specify your own database connection information without us automatically reading them from Connection Strings, with TP2 now you can do it. We've also added a switch that allows administrators the ability to disable this feature in case they have concerns and want to still enforce the "only read the connectionStrings from config" functionality and prevent users from trying to add their own.
2. Extensibility. In these release we are making the API's public to write your own Database Provider that allows you to plugin your own database and reuse all of our UI and remoting, all you need to do is implement a few functions (CreateTable, DeleteTable, InsertRow, DeleteRow, etc) and your provider will be ready to use remotely over HTTPS to manage your own DB.
3. Support for MySQL. In the upcoming weeks we will be releasing support for MySQL using the extensibility model mentioned above.
4. Small things. New Toolbar in the Connections Panel to simplify discovery of commands
5. Use of SMO. In this release we are using SQL Server Management Objects for all the schema manipulation, this means that things like "scripts exported from SQL inluding 'GO statements' and others will work in the Query window"

Configuration Editor

1. Choose where Configuration is read: now allows you to specify where you want to read and write your configuration from. This feature is great for advanced users that really understand the inheritance of our distributed configuration system and want to take advantage of it. Now ehen you go to a site, application or anywhere else, you will by default have the same experience where we read configuration from the deepest configuration path, however, now you can use the "From:" Combo box and tell us where you really want to read the configuration from, for example the following image shows how the options look like for a folder underneath Default Web Site. As you can see now you can choose if you want to use locationPath's or go directly to the web.config. This plays really nice with locking allowing you to lock items for delegated users, but still be able to change things yourself pretty easily. This change also works with script generation so now when you generate your scripts you can customize where to read/write configuration.
2. Lots of small things:Now, all the changes you perform will be show bolded untill you commit them. Enhanced the locking functionality to better reflect when attributes/elements are locked. Several minor bug fixes for script generation, collections without keys, etc.

IIS Reports

1. No longer depends on LogParser. TP1 was using LogParser for parsing logs. This version no longer uses LogParser which menas no additional installs for this. We also measured performance and we see an increase of up to 40% which means faster reports. (In my machine for logs of up to 6.4GB or 17 million rows it takes about 2 minutes to generate a report, wee see about 5-7 seconds for 1 million rows)
2. Better Reports. We took a look at the set of reports and we extended the list of reports as well as added new filters for them, for example, the status code report now lets you drill down and see which URL's generated a particular Status code, etc.
3. Export to CSV and XML.
4. Extensibility: For this release just as for DBManager we've made the API's of the UI public so that you can extend and add your own set of reports by writing a class derived from either TableReportDefinition or ChartReportDefinition. This means that just by overriding a method a returning a DataTable, we will take care of the formatting, adding a Chart and letting your users export in HTML, MHTML, CSV, XML, etc.

 UI Extensions

1. Bug fixes for all the features like Request Filtering, FastCGI, ASP.NET Authorization Rules, and ASP.NET Error Pages.

As you can see the extensibility is a big theme now, and in my following posts I will be showing how to extend both IIS Reports as well as DBManager.

Last Monday I gave a presentation at the ASP.NET Connections event in Orlando, the title was IIS 7.0 for ASP.NET Developers. I just wish I had more time to stay at Orlando, weather was great, especially considering that Sunday I was watching Snow in Redmond and then Monday and Tuesday I was around 80 degrees in sunny Orlando.

Anyway, thanks for all the people who attended the session, you can download the

Here are some of the things that I demonstrated:

1. First Demo: ApplicationHost.config, Web.config and Tools.
1. Showed the Application Pools list and how Visual Studio 2008 now provides IntelliSense for all the configuration of IIS.
2. Added a new Application Pool using Notepad, and IIS Manager shows it.
3. Showed the Sites section and created a new /Temp Application to my c:\temp directory.
4. Browsed to the application and showed the new detailed error messages that IIS7.0 includes giving you all the details on what     the problem is, and suggestions on how to fix it.
5. Created a new Web.config where I enabled system.webServer/directoryBrowse and showed how this immediately applied the changes.
6. Showed all the new tools that IIS includes for managing web.config, including IIS Manager, AppCmd, Javascript, and the new Configuration Editor included in IIS Admin Pack that will allow you     to generate scripts for all of them.
2. Second Demo: Pipeline Mode and Application Migration
1. Showed the Application Pools created by IIS, explained some of the differences in Classic Mode versus Integrated Mode.
2. Showed how to create a new Application Pool and where to specifythe pipeline modes.
3. Downloaded BlogEngine.net and created an application for it running in Integrated Mode. Showed the detailed errors when IIS detects compatibility issues with the pipeline mode and settings     like <httpModules/httpHandlers>.
4. Showed how assigning it to a Classic Mode immediately makes it run in the same way as before.
5. Then moved it back to Integrated Mode, and showed how to use AppCmd to migrate config (appcmd migrate config "path"), and showed     the changes between the original web.config and the updated one.
6. Explained these differences and how this is the right way to create applications that will run in IIS6, IIS7 classic mode and     IIS7 integrated mode
3. Third Demo: Leveraging the Integrated Pipeline
1. Showed a typical application that was configured using Forms Authentication and ASP.NET Membership and how accessing other content than ASP.NET (i.e. text files, images, classic ASP etc) would not cause authentication to happen.
2. Showed how easy just by changing the FormsAuthentication module and the UrlAuthorization module you were able to easily now authenticate all the requests, including Classic ASP, PHP, static files, etc.
4. Fourth Demo: Output Caching
1. Showed a little performance script using WCAT running against the BlogEngine.net in my laptop (running Windows Vista) gave around 400 requests per second, and made W3WP.exe take about a 100% of CPU, meaning it couldn’t do anything more.
2. Enabled Output Caching using IIS Manager for .aspx pages.
3. Ran the Stress Test again, and this occasion the results were that we got around 1000 requests per second, but more importantly CPU consumed by W3WP.exe was only around 20%. The Stress client was the one taking all the CPU, meaning that the server could easily do more than twice as many request per second if the stress client was done by another machine.
5. Fifth demo: Extensibility
1. Showed how easy it is to extend IIS using Managed code, building a Handler that would translate PNG images to Jpeg images as well as embed a copyright information all dynamically at runtime.
2. Showed another simple example on how to extend using a Module that logged every request to a SQL Server database.

Then I ran out of time :)

Today I was playing a bit with Visual Studio 2008 and was surprised to see that I was not getting IntelliSense in my web.config. As you might already know IntelliSense in Xml in Visual Studio is implemented by using a set of schemas that are stored in a folder inside the VS folder, something like: \Program Files\Microsoft Visual Studio 9.0\Xml\Schemas. After looking to the files it was easy to understand what was going on, turns out I was developing using .NET 2.0 settings and Visual Studio now ships different schemas for Web.config files depending on the settings that you are using: DotNetConfig.xsd, DotNetConfig20.xsd and DotNetConfig30.xsd.

As I imagine I looked into the DotNetConfig.xsd and it indeed has all the definitions for the system.webServer sections as well as the DotNetConfig30.xsd. However, DotNetConfig20.xsd does not include the section details, only its definition, so to fix your IntelliSense you can just open DotNetConfig.xsd, select the entire section from:

<xs:element name="system.webServer" vs:help="configuration/system.webServer">...</xs:element>

and just replace the entry in DotNetConfig20.xsd. You might also want to copy the system.applicationHost section and add it to the DotNetConfig20.xsd since it does not include it as well.