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.

Cross posted from Vijay’s Blog ( https://blogs.msdn.com/vijaysk/archive/2009/03/14/caution-while-xcopying-iis-7-0-config-files.aspx )

Comments

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

• Anonymous
  April 20, 2009
  Any idea how to fix this if you don't have your old server any longer. I made backups for all the config files (or at least I thought I did <g>). I copied them to the new server (actually, the old server, except reformatted), and I am getting this error.

• Anonymous
  May 06, 2009
  Thanks for the recommendation it helped me out!

• Anonymous
  July 24, 2009
  Jon, Did you ever get an answer to this?  Because I am in the same boat. Thanks, Ken

• Anonymous
  December 20, 2009
  I tried doing this, but it errors when I try and run the command to export the WasKey (says that's not an acceptable command). I tried doing it with just the first key, but no dice. Still get the error for any encrypted login info. Any advice? I am running Windows 2008 R2 Web Edition with IIS 7.

• Anonymous
  January 20, 2010
  Thank you. This helped me. But Iam facing an issue when Iam trying to export the keys on the new server on which I imported the keys earlier from an old server.

• Anonymous
  March 03, 2010
  Exporting the RSA key's is possible. also on w2k8 R2 just remove the extra space for the -pri command. like: aspnet_regiis -px "iisConfigurationKey" "D:iisConfigurationKey.xml"-pri aspnet_regiis -px "iisWasKey" "D:iisWasKey.xml"–pri This works :-)

• Anonymous
  May 11, 2010
  Yes, but this actually names the file "D:iisWasKey.xml–pri" So you might as well remove "-pri" alltogether. /M

• Anonymous
  September 21, 2011
  We resolved this issue by re-installing IIS, but only uninstalling IIS dint help us as it will not delete the inetserv folder , so we uninstalled Windows process activation service and installed both wondows process activation service and IIS7

• Anonymous
  March 29, 2012
  Excellent article and solved my issues in minutes.

• Anonymous
  September 08, 2014
  Thank you for this gread guide. Helped a lot!

• aspnet_regiis.exe is located in %windir%Microsoft.NETFrameworkversion
• aspnet_regiis.exe has to be executed with an admin account. It is sufficient to start cmd with admin rights.