How can I make the Active Server Pages (ASP) files on my server unreadable to those who might gain access to the script?
As you probably know, if a user can access the ASP script files that run on a server, that person can determine the software, variables in use, paths to calling programs, database connections, and even embedded passwords or authentication schemes. If IIS is working properly, users should see only the result of running the script; however, various vulnerabilities have enabled users to access ASP source code. (See the Microsoft articles "Malformed HTR Request Returns Source Code for ASP Scripting Files" at http:// support.microsoft.com/support/kb/ articles/q260/0/69.asp and "Virtual Directory Mapped to UNC Returns Server-Side Script Code When URL Contains Additional Characters at the End of the Request" at http://support .microsoft.com/support/kb/articles/ q249/5/99.asp.) Note that Windows 2000 Service Pack 1 (SP1) fixed the Server-Side Script Code bug but not the Malformed .htr Request bug. In addition, anyone who can access the IIS server files with Read permissions by any means other than Microsoft Internet Explorer (IE) can peruse the source code.
These vulnerabilities represent serious security problems. Some administrators don't use scripting on their sites, insisting on the harder-to-develop, faster-to-execute, and harder-to-read compiled code in the form of isapi.dll or custom COM objects. To solve this ASP-related problem, Microsoft released Windows Script Encoder, which is available at no cost as part of the updated Windows Script (WS) engine at http://msdn.microsoft.com/ scripting. The encoder takes readable ASP and obscures it so that it makes no sense to the viewer looking at the script.
The encoder is fairly straightforward, but there are a few important items to note. First, you use the encoder only on your final code. Error messages reporting problems in encoded script tend not to be as useful as error messages in unencoded script. For example, the line numbers indicating where the error occurred can be wrong, which makes it harder to identify the problem. Second, the encoding is a one-way process. So, when your script is debugged and you use the command
to encode the script, .html file, .txt file, or scriptlet, users can't decode the encoded file to yield your source.
The encoder lets you encode all your ASP files at one time and place them in a target directory. For example, to encode all ASP files and place them in a directory called aspencoded, you use the command
You use a special marker to indicate where encoding begins in your script, as Listing 1 shows. Anything above the **Start Encode** marker isn't encoded. During encoding, the scripting language reference changes to indicate that the script is encoded. For VBScript, here's how the change appears:
Finally, note that the encoded script won't work unless you update your WS engine to version 5.5. This update applies to Win2K, Windows NT, Windows 98, and Win95 OEM Service Release 2 (OSR2).
I'm running IIS 4.0 on NT 4.0 with SP6a. I'm using a host header for my Web site. Whenever I try to execute a search against my Web site, I receive the error message The template file can not be found in the location specified by 'CiTemplate=' in file \index.idq. I'm using the HTML/IDQ/HTX approach for searching Web pages under Microsoft Index Server 2.0. I've set the variable CiTemplate in query.idq to CiTemplate=/Search/index .htx. Is using the HTML/IDQ/HTX approach on a Web site that uses host headers a problem?
Several ways exist to make inquiries to Index Server. The HTML/ IDQ/HTX method is perhaps the most laborious, but it yields the fastest results. The .html file holds the form that creates the query through an Internet Data Query script (the .idq file), which Index Server processes. The results go to the specified HTX (i.e., extended HTML template) file, which formats the file for presentation.
Host headers aren't a problem. Verify that the index.htx file is present and has proper permissions. More important, check the .htx files for Include files, which must also exist and be accessible. If these files aren't present or accessible, you'll receive the error message you describe. See the Microsoft article "Err Msg: The Template File Cannot Be Found in the Location Specified" at http://support.microsoft .com/support/kb/articles/q183/7/24 .asp. (Thanks to reader Gregory Toland for this question.)
Some of my Microsoft FrontPage 98 users have starting documents named index.htm. When those users publish their sites, FrontPage renames their starting documents to default.htm, even though the users have specified index.htm in their Web site properties as the starting document. How can I prevent this renaming?
Oh, the wonders of FrontPage administration! Indeed, FrontPage performs this renaming because it can use only the default document that you specify in the Web server's Master properties. Furthermore, FrontPage uses only the first default document listed on the Documents property page for the Web. This problem isn't present in FrontPage 2000.
Although you could specify index .htm as the default document in the Master properties, this fix will cause the reverse problem for those users who use default.htm as their starting document. So, to fix this problem, you must either standardize on a default document name or upgrade to FrontPage 2000 Server Extensions. To change the default document of the Master properties, follow these steps:
- Start Internet Service Manager (ISM) in Microsoft Management Console (MMC).
- Click the plus sign (+) next to Internet Information Server.
- Right-click the server name, then select Properties.
- In the Master Properties drop-down list, select WWW Service.
- Click Edit beside WWW Service, as Figure 1 shows.
- On the Documents tab, add the document name you want to use (e.g., index.html), as Figure 2 shows.
- Click OK three times.
I'm an MCSE, an MCP+I, and almost an MCSE+I; I've been in the industry for a little more than a year and am an IT director/systems engineer. Which scripting language would you recommend that I learn?
In my opinion, you'll get the most leverage for your technical skills as an administrator/engineer by knowing how to automate processes. This skill is particularly useful with IIS, where you might want to create a virtual directory for 100 Web sites, create 100 Web sites, or create users on the fly. You can automate all these tasks with scripting.
The key to most IIS administration with scripts is Microsoft Active Directory Service Interfaces. ADSI lets you manipulate directory objects in the computer. For example, you can determine the files in a folder, the users in a group, the role the computer is serving (e.g., PDC, Flexible Single Master of Operations—FSMO), and the services running. In addition, you can edit and modify the IIS metabase as well as Win2K Active Directory (AD). ADSI isn't a scripting language but rather a scripting technology that lets you manipulate objects in a namespace. You can use a scripting language such as VBScript with Windows Script Host (WSH) or ASP to access ADSI.
ADSI has a unique syntax. The best way to quickly learn this syntax is to study the administrative scripts that Microsoft provides with IIS. Many IIS 4.0 administrators don't realize that IIS includes a \winnt\system32\inetsrvadminsamples folder containing .vbs scripts with names such as pauseftp .vbs, startweb.vbs, and stopsrv.vbs. (Figure 3, page 6, shows some of the administrative scripts that you can access.) For Win2K/IIS 5.0, you can find these scripts in the \inetpub folder. These scripts can easily serve as a foundation for customized tools. The Microsoft Windows Internet Information Server Resource Kit and the Microsoft Windows 2000 Resource Kit provide many more scripts.
In this column, I usually discuss practical how-to concerns. I'm taking time to write a bit about ADSI because I'm getting more and more requests such as "How can I script the creation of a Web site?" and "How can I add IP addresses to the restricted list programmatically?" ADSI is a central player in NT and even more important in Win2K. Consequently, IIS administrators can't consider ADSI an optional technical skill anymore. To help you get started or to supplement what you already know, the sidebar "For More ADSI Information," page 6, provides a list of ADSI resources on the Web and in print.
When I install IIS 5.0, no prompt appears asking me where I want to install the Web server. IIS 4.0 conveniently asked me where I wanted the \inetpub folders to reside. Can I install IIS 5.0 where I want it to be?
This question is commonly asked regarding IIS 5.0. Having previously installed IIS 4.0, most administrators expect this prompt and are surprised when IIS 5.0 installation whirs along to completion with everything installed on your C drive.
When I asked Microsoft experts about this difference from IIS 4.0 at a recent TechNet chat, the story they provided was that, during Win2K development, the law of the land was to eliminate every nonessential user prompt during installation. Although many people would argue that this user prompt is essential, the ugly truth is that you can't direct the installation target during an attended installation. You can, however, direct the installation to a different location by using an unattended installation.
An attended installation is the standard method most people use. The method is called attended because a user is usually standing around attending to the process, answering prompts, and completing forms. This method works well for one or a few servers, but if you're installing a few hundred servers, you're likely to employ Win2K's unattended installation option. In this method, you create an answer file that contains the information the installation program requires. In this way, the installation proceeds without prompting the user for setup parameters. For general information about unattended installations, go to http://www.microsoft.com/windows 2000/library/planning/default.asp. For more information about installing IIS 5.0 unattended, see my article "Upgrading to IIS 5: Installing IIS 5 to a Custom Location" (http://www.iisanswers.com/articles/upgrading_to_iis5/ changing_iis5_install_location.htm).
I'm having a problem with IIS 5.0 displaying the error message 1747 The authentication service is unknown. Why am I receiving this error message?
This error occurs when you haven't selected an authentication method in IIS. You must permit one or more of these authentication methods: Anonymous, Basic, Certificates, Windows/Integrated, or Digest.
In your answer to the question "Does an easy way exist to duplicate IIS on a new system," February 2000, you spoke highly about iisexport.exe. I'm new to managing and administering IIS, so I wanted to run by you what my organization is attempting to do to make sure this tool is appropriate.
I plan to replace the server that runs the organization's intranet. Server B will replace Server A. The iisexport.exe documentation leads me to believe that both servers can't be operational at the same time. I want to have both servers running at the same time so I can have more time during business hours to test the Web sites on the new server. I'm experiencing some problems on Server A that I don't want to migrate to Server B. Is iisexport.exe the appropriate tool for my organization?
As I reported in February, iisexport .exe is a decent tool suitable for migrating basic Web servers to new servers. IISExport was recently upgraded to include IIS 5.0 and IIS 4.0 migration, file migration, and NTFS permissions. This tool doesn't manage Microsoft Transaction Server (MTS) objects. (You can download IISExport from http://www.adsonline-co.uk/iisexport/.)
Another migration option is MetaEdit 2.1, Microsoft's new metabase editor. Originally released as MetaEdit 2.0, which Microsoft still includes in the Microsoft Windows 2000 Resource Kit, Microsoft reissued MetaEdit to fix a major bug that incorrectly writes hexadecimal values to the metabase if the metabase changes. MetaEdit 2.1 supports both IIS 5.0 and IIS 4.0. You can obtain MetaEdit 2.1 from http://support.microsoft.com/support/kb/articles/q232/0/68.asp. One key feature of the tool lets you export a metabase and import that metabase to a new server.
Another major new tool is the IIS Migration Wizard—another resource kit goodie. This tool supports migrating a Web server from IIS 5.0, IIS 4.0, Apache HTTP Server, or Netscape Enterprise Server to a target IIS 5.0 server, including content and NTFS permissions. The IIS 5.0 Migration Tool has some oddities (e.g., renaming the migrated Web sites, transferring the source system IP addresses, placing the content in folders named after the migrated Web site), but it can take you pretty far down the road to migration. You can find a demonstration of this tool at http://www.iis answers.com in the article "Upgrading to IIS 5." (Thanks to reader Terri Tarzi for this question.)