You might think that your only role in implementing the Microsoft Web Admin tool is to set up the IIS server to host the application—that configuring the tool and its customer organizations is a domain administrator's responsibility. However, provisioning tools such as Web Admin make it difficult to draw distinct lines between tasks that relate to full implementation. As an IIS administrator, you'll need to support the application even though the services that the tool provides fall into the realm of the domain administrator. In a sense, the domain administrator is one of your customers.
You can break Web Admin's setup process into two components: tasks that you must perform and tasks that a domain administrator can perform. However, setup can involve certain complications, and segmenting the installation process can make troubleshooting such problems difficult. In addition to installing Web Admin and configuring your IIS server to run the tool, you might want to test the tool before handing it off to a domain administrator or opening it up to other users. In that case, you need to configure the tool itself, a process that might include setting up customer organizations. At the least, you need to be on hand to work with the domain administrator to make certain that the tool's final configuration operates appropriately and that no problems can be traced back to the IIS configuration. If you serve as both IIS administrator and domain administrator, you'll obviously need to do all the work.
For all these reasons, you need a fundamental understanding of Web Admin's organizational structure and how that structure integrates with Windows 2000 and Active Directory (AD). After all, you might be the only person who has a big picture of how the tool works.
