Condividi tramite

IIS 7.0 Site ID Computation

  • Articolo

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).

Comments