Caution while xcopying IIS 7.0 config files

Metabase.xml is the central store where IIS 6.0 stores most of its configuration information. Its a plain text file and stores all the information in a simple XML format. The XML format naturally raised a notion of being able to XCOPY the config file to another server and transferring the settings with it. But if you copy over a metabase.xml file from another server your IIS admin service will no longer start. This happens because the metabase.xml file contains ACLs that control access to any metabase key. Stored under the AdminACL tag these keys are encoded based on the machinekeys of the server. When you move the metabase.xml to another server the keys can no longer be decoded and hence your IIS Admin service will not be able to start.

With IIS 7.0 we moved to a new XML based configuration store that is modeled after ASP.NET. It is no longer centralized into a single file. The hierarchical store starts with the applicationHost.config file and can be distributed among web.config files under your application.

This move also enables the long lasting idea of xcopy-deployment. You can now have all the settings in a web.config along with your application content and move it around. 

Another change that was made is that the local accounts/groups that IIS 6.0 used (IUSR_MACHINENAME / IIS_WPG) were replaced by built-in accounts (IUSR / IIS_IUSRS). The built-in accounts have the same SID across Windows 2008 servers and are not machine specific.

So technically you now have an IIS configuration store that is virtually machine independent and you can just copy your applicationHost.config from one server to another and IIS will pick up the settings and just work.

But there is a catch. Try this.

On an IIS 7.0 server change the application pool identity (for the DefaultAppPool)  to a custom domain identity. (Advanced Settings > Application Pool Identity > Custom Account)

Then move the applicationHost.config to a different IIS 7.0 server.

When you try to run a website using the DefaultAppPool you will find that the Application will get disabled with the following error in the event log.

So lets try to change the application pool identity to another domain account or reset the password for that account.

You type in the username and password and hit OK and you will get the following error message

Any username / password will not work. (You can however set the identity of the application pool to one of the built in accounts.)

Wondering what’s going on ? Initially when you set the application pool identity to a domain account IIS has to keep a local copy of the username and password. So it stores a copy in its applicationHost.config and since it is not advisable to keep the password in clear text format it goes ahead an encrypts it. You will see something like this in the config file.

For the encryption it uses machine specific keys in the iisConfiguration and iisWasKey containers. When the applicationHost.config is moved to a different server IIS can no longer decrypt the settings.

To get this working you can export and import the keys from the original server.

Export using the following commands

And for the import use

So whenever you are trying to xcopy-deploy your application on multiple servers you need to check if there are any encrypted sections and if you do ensure you port the iisConfigurationKey and the iisWasKey as well.

Also I would recommend using the Web Deployment Tool ( MSDeploy ) which makes deployment a lot easier. You can create a package (settings and content)  of the whole server / specific application and use it to deploy. But the tool is in BETA still.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS