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.

Application pool TestApplicationPool has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.

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

There was an error while performing this operation.

Details: Bad Data. (Exception from HRESULT: 0x80090005)

 

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.

<processModel identityType="SpecificUser" userName="microsoft\testuser" password="[enc:IISWASOnlyAesProvider:2Woq1XHFmcDxzSEKJe9q1eZsvlUEBcmb0Puy3DzkdWg=:enc]" />

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

aspnet_regiis -px "iisConfigurationKey" "D:\iisConfigurationKey.xml" -pri
aspnet_regiis -px "iisWasKey" "D:\iisWasKey.xml" -pri

And for the import use

aspnet_regiis -pi "iisConfigurationKey" "D:\iisConfigurationKey.xml"
aspnet_regiis -pi "iisWasKey" "D:\iisWasKey.xml"

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.

Comments

• Anonymous
  March 13, 2009
  PingBack from http://www.clickandsolve.com/?p=22971

• Anonymous
  March 14, 2009
  Metabase.xml is the central store where IIS 6.0 stores most of its configuration information. Its a plain

• Anonymous
  March 15, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout

• Anonymous
  March 26, 2009
  Metabase.xml is the central store where IIS 6.0 stores most of its configuration information. Its a plain

• Anonymous
  July 20, 2009
  Is it possible to import an IIS 6 (Windows Server 2003) metabase.xml into IIS 7 (Vista Business)? If so, anyone know any useful urls?

• Anonymous
  December 01, 2009
  Very helpful. Note you need to ensure any IIS role services that are installed on the original machine are also on the new machine when copying the applicationHost.config file. I ran into an issue because dynamic compression had been installed on the old server and not the new, but was able to restore the origingal applicationHost.config, install the required service, then switch the new applicationHost.config file in successfully.

• Anonymous
  December 06, 2009
  So here's a problem I'm running into, I imported the keys into another server, no problem everything works great. However, my original server where the key was exported from died. So thinking "No problem I'll do it from the 2nd node..." on 2008 RTM it works, but on 2008 R2, when I run aspnet_regiis -px it fails with "Key not valid for use in specified state". Any ideas, or did I just lose my key?

• Anonymous
  February 02, 2011
  The comment has been removed

• Anonymous
  January 10, 2014
  We found out the hard way that we needed to add the -exp switch to the end of the import command to mark the key data as exportable: aspnet_regiis -pi "iisConfigurationKey" "D:iisConfigurationKey.xml" -exp aspnet_regiis -pi "iisWasKey" "D:iisWasKey.xml" -exp Otherwise, when we tried to enable IIS Shared Configuration, we got cryptic error messages because the first step of enabling IIS Shared Configuration is to export the data.   Because the previously-imported data was not marked as exportable, shared configuration gave the cryptic error message.