IIS Informant - 09 May 2000

I'm having trouble sending mail with the IIS SMTP service. Like a lot of sites, my site uses Collaboration Data Objects for Windows NT Server (CDONTS) to send the mail in an Active Server Pages (ASP) script. The messages are being created correctly, but they just sit in the Pickup folder. Why isn't IIS delivering them?

Using CDONTS is a great way to send mail from your IIS server. CDONTS requires that the SMTP service be running, which it evidently is in your case. However, one other component is required—DNS. If you haven't configured your IIS server to access a DNS server, IIS won't have a way to resolve the names for the mail. When you use CDONTS through ASP to create mail, IIS hands the mail off to the SMTP server. So troubleshooting at this point is really about why the SMTP service isn't working. The first thing IIS tries to do is use DNS to resolve the name of the addressee. If IIS can't find the addressee, it will try again 48 times at 1-hour intervals. If the resolution is still unsuccessful after the 48 attempts, IIS puts the undeliverable and nonreturnable mail in the Badmail folder. (You can adjust the retry parameters in the SMTP setup.)

If the IIS server wasn't able to access a DNS server either because IIS wasn't properly configured or because of a firewall or proxy server configuration, the symptoms you're describing might appear. If you aren't familiar with CDONTS, you can find more information about it at http://www.iisanswers.com. Also, see IIS Informant, April 2000.

I'm trying to use the browscap.ini file to determine the browser capabilities of clients accessing my server. The file doesn't seem to support Microsoft Internet Explorer (IE) 5.0. What's the best way to update browscap.ini?

Here's a little background for those administrators unfamiliar with the Browser Capabilities component of ASP. This component provides a way for you to determine the capabilities of a user's browser. When you have that information, you can customize your Web-page presentations to better suit a particular user. For example, you can use this component to determine whether a user is browsing with Netscape or IE so that you can use the appropriate scripting language for that user's browser. The following example script identifies whether a browser can use VBScript by storing the value from the vbscript property in the varVBScriptOK variable:

<% Set objBrowCap = Server.CreateObject('MSWC.Browsertype')varVBScriptOK=objBrowCap.vbscript %>

Now you can use varVBScriptOK to present VBScript-capable browsers with VBScript and all other browsers with JScript.

The point here is that different browsers have different capabilities. Browscap.ini is a text file that contains a list of each browser's capabilities. The component must reside in the same directory as browsercap.dll (e.g., winntsystem32inetsrv). If you've installed IIS 4.0 and haven't updated browscap.ini, the component is probably dated.

To update browscap.ini with IE 5.0 settings, copy the code in Listing 1 and paste it into your existing browscap.ini file. Alternately, a more comprehensive update is available at http://www.cyscape.com/browscap. This site also contains a commercial product called BrowserHawk, which does quite a bit more than the Microsoft-supplied Browser Capabilities component (e.g., lets you detect the user connection speed and what plugins are in use).

I've set up two Web sites—one for public access (http://www.somesite.com) and one for administrative purposes (http://admin.somesite.com). My customers need to access their accounts on the public Web site, so I purchased a Secure Sockets Layer (SSL) certificate from VeriSign to secure their transactions. The administrative Web site is for inhouse use only, and I'd like to secure it without having to buy an SSL key from a Certificate Authority (CA). Is it possible to create a valid certificate for my administrative site?

Yes, you can use Microsoft Certificate Server to generate your own certificate. You can find step-by-step instructions for this process in the Microsoft article "How to Configure Certificate Server for Use with SSL on IIS" (http://support.microsoft.com/support/kb/articles/q218/4/45.asp). If you install a self-signed certificate and use that certificate to create a secure connection through HTTP over SSL (HTTPS), clients' browsers might receive a message similar to the one that Screen 1 shows, which IE 5.0 generated. The exact wording and appearance of this message is different for each browser, but the intent is the same. The message will scare away most uninformed consumers.

The browser in every client computer maintains what is called a certificate store. This store is a collection of certificates that the client trusts. Most browser installations include a variety of preinstalled certificates from CAs that the client system trusts. To view the list of trusted CAs in IE 5.0 and launch Certificate Manager, choose Tools, Internet Options, Content, Certificates.

Click the Trusted Root Certification Authorities tab, and you'll see a list similar to the one that Screen 2 shows. This list can contain some surprises. For example, on my system, I was surprised that I trusted GTE, Equifax, and others I'd never even heard of as root CAs. I have to admit that this is a pet peeve of mine. If I create a self-signed certificate in Certificate Server and use that certificate to enable SSL connections to my Web server, a message similar to that in Screen 1 appears informing clients that they're accessing a site they haven't chosen to trust.

Now, this is really annoying. You won't get this message if you connect to a site that uses a certificate from VeriSign, Thawte, Microsoft, or GTE. Why? Because they're pretrusted. In other words, certificates from those well-known CAs install when you install IE, which raises the frequently asked question, "Is there any difference in the encryption between my computer and a trusted site and my computer and an untrusted site?" The answer is no: Both sites are equally secure. The warning message is really saying, "Do you want to create a secure connection to this site even though I (i.e., IE) don't know who issued this certificate?" The SSL connection is the same whether you're talking to a trusted or untrusted site. The only difference is the warning message.

To avoid the message without paying for a certificate, you have two choices:

Conveniently, when you install Certificate Server, Windows creates a virtual directory called certsrv under the default Web site. This directory contains a Web page that installs your CA's root certificate as a trusted authority for the client browser. After this installation, any certificate your Certificate Server issues will be acceptable to the client browser, thereby avoiding the warning message. To access the Certificate Server Web page, go to http://yourhostname/certsrv, then choose Certificate Enrollment Tools, Install Certificate Authorities Certificates. Select the certificate for the server. When the File Download dialog box appears, select Open this file from its current location, and click OK. What happens next depends on whether you've installed Service Pack 4 (SP4) or later. If you have, select Install Certificate in the Certificate dialog box, then follow the prompts to store the certificate in the Trusted Root Certificate Authorities store. If you've installed SP3 or earlier, click OK and answer Yes to Do you want to ADD the following certificate to the Root Store? in the New Site Certificate dialog box. Restart your computer to ensure that Windows recognizes the new certificate. Note that the Windows 2000 (Win2K)/IIS 5.0 version of Certificate Server has the same functions, but the choices (i.e., screens) present differently.

I have a busy site that uses Microsoft Index Server. I frequently have many users queued to submit queries on the same catalog. What settings can I use to improve performance? Is Index Server single threaded? Also, can I increase the number of catalogs Index Server creates?

If you aren't familiar with Index Server, this program is part of the NT 4.0 Option Pack; you can also install it with IIS. The server indexes file content into a searchable database that users can query. Users can access Index Server from within IIS, which lets Web administrators index Web site content and provide pages for users to search that content.

Index Server is a straightforward feature to install and use. The server is easy to set up, and the installed demonstration pages make it easy to get a query page online quickly. Index Server is largely self-tuning and works in the background to index any new content that appears. However, Index Server is resource intensive and doesn't provide many options for administrators to tune the process.

When you start Index Server, it begins to index Web sites for which you've selected the Index this Directory check box on the Home Directory page of the Web site's properties. You can control this setting for virtual directories and regular directories as well as for Web sites. The final result of the indexing is called a catalog. When users query the index, it's really the contents of the catalog that they're searching.

One way to divide information is to have catalogs on different topics or Web sites. However, Index Server 2.0 or earlier can't work with a lot of catalogs; for example, it allows a maximum of only 26 catalogs on IIS 4.0. You can set Index Server 3.0 and later to 100 catalogs, but the product has a limit of 33 catalogs by default.

Other than startup and shutdown, Index Server is multithreaded (i.e., it can run multiple processes simultaneously). As a result, it can benefit from multiple CPUs. You can configure the number of query and request threads per catalog (e.g., Max-ActiveQueryThreads, MaxActiveRequestThreads), but this number is set during the installation based on the number of CPUs. (This number generally doesn't require further management.)

The best performance improvement adjustment is to modify the size of the caches that Index Server uses so that the entire cache is held in RAM. The two relevant entries are the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlcontentindexPropertyStoreMappedCache Registry key and the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlcontentindexSecPropertyStoreMappedCache Registry key. (Be sure to use extreme caution when making changes to the Registry.)

After Index Server has built the catalogs, look in catalog.wci and see how much disk space the .ps1 and .ps2 directories take up. (PropertyStoreMappedCache corresponds to .ps1, and SecPropertyStoreMappedCache corresponds to .ps2.) Set the value of these keys to (2 x sizeof folders)/65536. For more information about Index Server, see Marnie Hutcheson, "Index Server and the FrontPage WAIS Search Engine" and the Registry parameter guidelines at http://www.microsoft.com/technet/iis/technote/indexgd/administration/admin4.asp.