I am working on a project which utilizes the IIscnfg.vbs script to backup and restore the IIS 6.0 metabase file. Here's the situation: I have several web sites that multiple developers are working on. I plan to use a script to call the export feature to create one xml file per web site, then store those files in source safe along with a script for developers to initially import, and then re-export those metabase backup web site configuration files as needed. I don't want to do the entire IIs config at the root "/lm/w3svc" because it may overwrite existing web sites that are not standard issue for the developers. There have been a few issues that I've run into: 1) When attempting to use the export feature for a specific IIsWebServer, you must know the name of the IIsWebServer metabase path. This appears to be a non-conflicting numeric value generated at random by both the MMC snap in and the IIsWeb.vbs script. I don't mind this fact alone, but none of the administration scripts allow for you to specify the web server by name, so you must first manually use the /query command in IIsWeb.vbs (thus defeating automated scripts) or roll your own function to query the numeric value based on the server comments. A little annoying that this functionality was not addressed for the scripts as a flag allowing you to specify optionally the webserver by name, but whatever--I wrote my own script to do this, and I understand that the server comments are not unique so I had to go out of my way to flag an error when multiple webservers were returned--OK. 2) When attempting to use the import feature, you need to know both the source and destination metabase paths. If I have just created a webserver with IIsWeb.vbs, my own function, or even used my function to query for the numeric value, I am fine on the destination path, but what about the source path? Apparently, if my source webservers were initially created with a random number, I'll need to now write another function to scan the XML file to obtain its numeric value for the webserver... then supply that to the script that is running the import. This seems like quite a bit of extra work, and I have to wonder why this wasn't built into the import script. Now what is the problem with this scenario? Allowing the random metabase paths to be created on multiple computers then restored back onto multiple computers seems like it could result in conflicts where one webserver is restored on top of an existing webserver by accident because the numeric webserver metabase path is not utilizing something like a GUID. What alternatives do I have? I could choose static numbers for my "standard issue" webservers to be distributed, but this assumes that no server has already generated any webservers with the numbers before the script is run to create the webservers I am deploying. In all likelihood, if I choose #'s 10-100 for my webservers those numbers will probably not already be taken, and any additional sites that other people create will likely be in the xxxxxxxxxx range. Also, my scripts will need to be hard-coded to always import/restore based on static webserver numbers. I just wonder if anyone has come across any of these dilemmas and has either worked out some more elegant solutions and/or knows some additional information about the metabase naming schematics that would help simplify things a bit. Thanks, Svendre