I recently wrote some code to automate the updating of the supported domain name bindings of an existing IIS website.  I wanted to use WMI for this because WMI is the standard interface for controlling the various servers from Microsoft and many other companies.  You can do many powerful things with just a few WMI calls.  We are using this feature in Syrinx Community Server to allow an admin to set the domain names the web site should support, which would then update the IIS web site.  Here is the fun we went through to get this working.

 Issue 1: There are two levels of WMI support for IIS.  IIS6 and below have a different set of WMI classes than IIS7 and above.  If you use the IIS6 WMI classes, you would have to install "legacy IIS6 support" in IIS7 to make it work.  IIS6 WMI is also buggy, so given that we are on Windows Server 2008 for this, we choose to use the IIS7 WMI.  Syrinx Community Server will run on IIS6, but the feature to automatically update the IIS website with the new domain names supported wont work with it.  I guess I could have used the ADSI library, but I really want to stick with WMI for this.

Issue 2: There is very little documentation online about how to truly manage IIS with WMI.  Sure there are examples that show how to list the domain name bindings of a site, or to list the sites in IIS, but that is of little value for how to actually manipulate settings in IIS.  You really need to understand how the general WMI libraries work in order to go at a fresh start with controlling a server with WMI.  This is one reason why I am writing this thread.

Issue 3: I developed the code on windows 7, which actually uses IIS 7.5.  The following code snippet works great on Windows 7:

ManagementObjectSearcher iisSites = new ManagementObjectSearcher(
	@"\root\WebAdministration", string.Format("Select * From Site where Name = '{0}'", webSiteName));
foreach (ManagementObject site in iisSites.Get())
{
	ManagementBaseObject[] newbind = new ManagementBaseObject[dns.Count];
	for (int p = 0; p < dns.Count; p++)
	{
		string[] parts = dns[p].Split(':');
		string host = parts[0];
		string port = "80";
		if (parts.Length > 1)
			port = parts[1];
		ManagementClass newOne = new ManagementClass(@"\root\WebAdministration:BindingElement");
		newbind[p] = newOne;
		newOne["BindingInformation"] = string.Format("*:{0}:{1}", port, host);
		newOne["Protocol"] = "http";
	}
	site["Bindings"] = newbind;
	site.Put();
}

The variable name dns is a List<string> type.  Each string in the list is a domain name that is expected to be supported.  The code assumes that the list of domain names is the only domain names the site should be supporting.  This code also does not support https right now.

So, assuming that the code was solid and ready to go on a Windows 2008 server, I deployed to a server for more testing.  Here is where I found the BIG BUG in IIS7 WMI support. 

With Windows 7 using IIS 7.5, if the site was support the domain names a.com, b.com and c.com and the code above was changing that list to just a.com and x.com, the iis site would show bindings of only a.com and x.com as expected. HOWEVER, With windows server 2008, the site would show a.com, b.com, c.com and x.com.  In other words, server 2008 with IIS 7 was not removing the entries that were no longer in my list like Windows 7 with IIS 7.5.   This was going to be a big problem.

I searched the web and found one other guy mentioning the same bug.  A developer from the IIS team said he saw the bug and went and fixed it.  the IIS team developer said he wasnt sure how the bug fix would be released.  I went and updated my server 2008 with SP2, and the bug was still there.  I search the web for fixes to IIS to resolve it - no fix was found.

My dedicated server hosting provide was able to provide a new server with Windows Server 2008 R2, which is running IIS 7.5.  I put the site on the new server and sure enough the code above was doing the work as expected, exactly like II 7.5 on Windows 7.

Issue 4: In order for the above code to actually work, it needs elevated privileges.  It wont work with the standard app pool identity created for ASP.NET web sites.  The last thing I wanted to do was to require the Syrinx Community Server web sites to run with elevated privileges.  So, I created a new "Syrinx Community Server Site Management" windows service that runs the above code.  The code in the ASP.NET web site uses binary .NET remoting to talk to the windows service which does that actual work of updating IIS.

The windows service is a new base for other such functionality, such as doing backups and restores of sql server databases, updating DNS entries in the DNS server, and creating new web sites in IIS.  We use SVN for our source control for our client's web sites, and are working on a new feature that will automatically get latest from SVN, create a new web site, create a new sql server db and hook up everything to work properly.  That way we can deploy a web site by checking in our work in SVN and then let the windows service do all the work.

So, all is well that ended well so to speak.  It was a long and windy road, but we now have a nice new level of functionality that also builds for the future.  The down side is that this new code support requires no less than IIS 7.5, but the core Syrinx Community Server will still work on older IIS servers.