\[Author's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month, I show you how to use code to create IIS Web sites. Specifically, I show you two strategies for creating and maintaining IIS sites programmatically: VBScript through WSH and ASP.\]
Recently, some colleagues and I debated an interesting approach for this article. Explaining and providing a piece of code that creates a Web site on an IIS machine is a great topic for an article and a useful tool for readers. However, our debate centered around the implementation details—Windows Script Host (WSH) versus Active Server Pages (ASP).
Large shops usually use WSH scripts to perform Web server maintenance and configuration. WSH scripts don't require installation, nor do they have dependencies that you need to install (such as the Microsoft Visual Basic—VB—runtime files for VB Win32 applications). You can quickly copy in and remove WSH scripts from IIS servers. ASP applications are appealing because you can take advantage of browser capabilities to provide a rich UI.
If you don't have to run COM components in your code, ASP applications have similar benefits to WSH scripts in that they don't require installation and can be quickly copied to and removed from IIS servers. The broad reach of browsers makes executing ASP applications focused on remote IIS administration and maintenance easy, but this method also poses a potentially dangerous security situation. For example, because of the browser's broad reach, users can easily get to your administration applications; if users can get to the applications, they can potentially execute them. For this reason, many shops require WSH rather than ASP for IIS administration and maintenance. (For more information about deploying WSH scripts for IIS administration, see "An Introduction to WMI," October 2000.)
However, what about the ISP and application service provider scenarios that smaller shops often use? Many ISPs and application service providers make Web server maintenance and configuration applications available on the Web so that clients can create custom Web sites. This month, I show you both the enterprise and the small-shop approach and provide code for both the WSH and ASP strategies so that you can choose which strategy best meets the needs of your business.
Creating Web Sites with WSH
MkW3Site.vbs is a WSH script installed by default to the \inetpub\scripts directory when you install Windows 2000. (You can download MkW3Site.vbs from the Code Library on the IIS Administrator Web site at http://www
.iisadministrator.com.) This powerful script, which is compatible with Windows NT 4.0, creates Web sites for you. MkW3Site.vbs takes 10 possible parameters, which Table 1, page 2, lists.
MkW3Site.vbs isn't pathed (i.e., placed in a folder that Windows locates automatically by default), so you need to navigate to the \inetpub\scripts directory to execute it. In addition, creating Web sites requires a security privilege, so make sure you're authenticated as a member of the local administrators group on the server you're using. Alternatively, you can use the command-line utility Runas to impersonate a user when you run the script. Although you can run MkW3Site.vbs in CScript or WScript, I recommend CScript so that all screen output is directed to the command window from which you run the code. WScript initiates a series of pop-up windows that you have to close by clicking OK. I executed the command
CScript mkw3site.vbs —r e:\ _ inetpub\wwwroot\interknowlogy _ —t "InterKnowlogy Site" —h _ interknowlogy.com —n 3 —v
to create a third Web site on my test server. Figure 1 shows the code that created the Web site.
You can easily verify the properties you used MkW3Site.vbs to assign to the new Web site by choosing Start, Programs, Administrative Tools, Internet Services Manager in Win2K. From ISM, locate the site, right-click it, and select Properties.
Creating Web Sites with ASP
Although Microsoft designed MkW3Site.vbs for WSH, you can use it with ASP with few modifications. I decided to make the functionality a bit more robust, so I created a small Web application on which you can build that's made up of four .asp files. Download these files from the Code Library, then create a folder beneath your Default Web site. (This folder can be a virtual directory.) Name the folder whatever you choose, and place the four .asp files in it. You need to apply an authentication to the folder (the pages inherit the security from the folder) so that you run the Web application under a security context that has permissions to create Web sites and the ASP code doesn't run anonymously.
From ISM, right-click the folder, then select Properties. Click the Directory Security tab, then click Edit in the Anonymous Access and Authentication Control section. (In IIS 5.0, you can simply remove Anonymous access so that you run the Web application under Integrated Windows authentication.)
Instead of simply gathering the parameters from the switches in MkW3Site.vbs in an HTML form, I wrote an .asp file that lists all the Web servers currently configured on a machine. I used a piece of WSH code called ListWebApps.asp, which Listing 1 shows. (You can download ListWebApps.asp from the Code Library.) The page that ListWebApps.asp creates, which Figure 2 shows, serves as the home page of the Web application. Notice that each site that ListWebApps.asp lists is hyperlinked. You can click a site and retrieve the properties you set when you created the site, as Figure 3 shows.
If you open the source code for ListWebApps.asp, you'll see that this simple piece of code does the heavy lifting in this application. First, the code at callout A in Listing 1 uses the GetObject command to obtain an object reference to the W3 Service. Next, the code at callout B iterates through each site in the W3 Service with the For Each notation. If you didn't filter on IIsWebServer, you would also get the FTP and SMTP servers in the list. Finally, the code at callout C uses the HREF tag to locate the links with the name and number of the site, then sends the Web site number to ListWebProps.asp, which Listing 2 shows. (You can download ListWebProps.asp from the Code Library.)
You can use similar syntax in the .asp file to retrieve the properties, but unfortunately, ASP doesn't support the For Each syntax because of the different types of data stored in the Web site properties (e.g., multivalued strings, numbers). The good news is that Web site properties are simply object properties of the container object that you reference: for example,
Set objW3Site = GetObject _ ("IIS://LOCALHOST/ _ W3SVC/" & strSiteNum)
Response.Write("<STRONG> _ Site Number: " & _ "</STRONG>" & objW3Site.Name )
You can look up any of these Web site properties on the Microsoft Developer Network (MSDN) Web site (http://msdn.microsoft.com/library/psdk/iisref/aore1p5x.htm) or in the product documentation, but a much better tool for viewing the IIS properties and names is the metabase editor—MetaEdit. (You can download the current version of MetaEdit from http://support.microsoft.com/directory/article.asp?id=kb;en-us;q232068.)
Click Back at the bottom of the ListWebProps.asp page to return to ListWebApps.asp. Notice the Create Web Site button at the bottom of the ListWebApps.asp page. By clicking Create Web Site, you call a page called CreateSite.asp, which is made up of the HTML form that Figure 4 shows. You input all the parameters necessary to create a Web site in this form, which uses an HTML post to call MkW3Site.asp. Fill in the CreateSite.asp values as appropriate, then click Go to create the Web site. Figure 5 shows the results of running MkW3Site.asp to create a Web site.
Completing the Web SiteCreation Process
MkW3Site.asp is MkW3Site.vbs with some minor changes relating to the processing of the parameters and the UI. The script contains 220 lines of code and is heavy on Active Directory Service Interfaces (ADSI); explaining each line is certainly beyond the scope of this article, but I point out a few key areas.
To ensure that the script performs as expected in a variety of conditions or environments, notice that MkW3Site.asp makes extensive use of error checking. For example, if the required parameters, root directory, and server comment aren't available, the code that Listing 3 shows displays an error and ends the script. Next, the script uses the GetObject command to retrieve a reference to the W3 Service, then checks the computer for an existing site at the Web site number it retrieved. If a conflict occurs, the code that Listing 4 shows displays an error message to the user and ends the script. The code
Set NewWebServer = _ w3svc.Create("IIsWebServer", _ ArgSiteNumber) NewWebServer.SetInfo
then creates the Web server.
Now that the Web server exists, the code that Listing 5 shows applies the bindings (i.e., the IP address, port number and host name) and server comment. The script that Listing 6 shows creates the root directory object and applies the home directory path. Finally, if appropriate by the parameter setting, the code
Set NewWebServer = _ GetObject("IIS://" & comp & _ "/w3svc/" & Index) NewWebServer.Start
starts the Web server.
This month, I showed you two distinct coding approaches to remote IIS administration and maintenance—WSH through a .vbs file and a Web application with ASP. Next month, I'll show you how to provide wireless capabilities to your existing IIS applications and Web sites the easy way. I'll introduce you to Wireless Knowledge's Echo, which is an outbound Internet Server API (ISAPI) filter. Echo converts the HTML that IIS sends from the Web server into the wireless formats that the thousands of devices that touch your site use.
In Tim Huckaby, "IIS 5.0's FTP Server Powerhouse," March 2001, the statement that the process by which you can host multiple FTP sites on one Windows 2000 server is identical to the process by which you set up multiple Web sites on IIS was incorrect. Microsoft's FTP server doesn't support the use of host headers. We regret any inconvenience that this error might have caused.